サービス アカウント キーを管理するためのベスト プラクティス

通常のユーザーとは異なり、サービス アカウントにはパスワードがありません。その代わりに、サービス アカウントは RSA 鍵ペアを使用して認証を行います。サービス アカウントの鍵ペアの秘密鍵がわかっている場合は、秘密鍵を使用して JWT 署名なしトークンを作成し、そのトークンを使ってアクセス トークンをリクエストできます。生成されたアクセス トークンにはサービス アカウントの ID が反映されています。このトークンを使用することで、サービス アカウントに代わって Google Cloud APIs を操作できます。

秘密鍵を使用するとサービス アカウントとして認証できるため、秘密鍵へのアクセスはユーザーのパスワードを知ることと似ています。秘密鍵はサービス アカウント キーと呼ばれています。サービス アカウントで使用される鍵ペアには、Google 管理とユーザー管理の 2 つのカテゴリがあります。

サービス アカウント キーの管理は慎重に行ってください。扱いを誤ると、セキュリティ上のリスクが生じる可能性があります。サービス アカウント キーに関連する主な脅威としては、次のようなものがあります。

  • 認証情報の漏えい: サービス アカウント キーが、本来保管すべきではない場所に誤って保存される可能性があります。漏えいしたサービス アカウント キーが悪用され、ユーザーの環境内に攻撃の足場が作られる可能性があります。
  • 権限昇格: サービス アカウント キーの保護が十分でないと、このような鍵が権限の昇格に利用される可能性があります。
  • 情報開示: サービス アカウント キーにより、機密性のあるメタデータが誤って公開される可能性があります。
  • 否認防止: サービス アカウント キーを使用して認証を行い、サービス アカウントでオペレーションを実行すると、攻撃者が身元を隠して操作を実行する可能性があります。

このような脅威を軽減する最善の方法は、ユーザー管理のサービス アカウント キーを使用せず、可能な限り別の方法でサービス アカウントの認証を行うことです。また、IAM Conditions と VPC Service Controls を使用して、乗っ取られたサービス アカウントでアクセス可能なリソースを制限することもできます。

代替の認証方法を使用できない状況では、このガイドで説明するベスト プラクティスに従ってサービス アカウント キーの管理、使用、保護を行ってください。

認証情報の漏えいを防ぐ

サービス アカウント キーは、ユーザー名やパスワードと同様に認証情報の一つです。有効なサービス アカウント キーにアクセスできるユーザーは、この鍵を使用して認証を行い、サービス アカウントにアクセス権のあるリソースを使用できます。

攻撃者にとっては、漏えいしたパスワードよりもサービス アカウント キーのほうが価値が高い可能性があります。漏えいしたパスワードでログインを試みても、ユーザー アカウントに 2 段階認証プロセスやログイン時の本人確認が構成されていれば、ログインに成功する可能性は低くなります。対照的に、サービス アカウントは追加のログイン検証の対象ではないため、漏えいしたサービス アカウント キーを使用した認証は成功する可能性が高くなります。

攻撃者は、さまざまな場所でサービス アカウント キーを検索しています。たとえば、次のような場所が狙われます。

  • オープンソース プロジェクトのソースコード リポジトリ
  • 一般公開の Cloud Storage バケット
  • 侵害されたサービスについて、一般に公開されているデータダンプ

攻撃者が情報を探すのは公開されている場所だけではありません。非公開の場所に侵入し、サービス アカウント キーを探す可能性もあります。次に例を示します。

  • メール ボックス
  • ファイル共有
  • バックアップ ストレージ
  • 一時ファイル システムのディレクトリ

サービス アカウント キーの漏えいリスクを低減する効果的な方法は、使用されている鍵の数を減らし、新しい鍵が作成されないようにすることです。以降のセクションでは、サービス アカウント キーの数を制限する方法と、サービス アカウントの漏えいリスクを軽減する別の方法について説明します。

ベスト プラクティス:

サービス アカウント キーの作成に代わる方法を用意する。
組織のポリシーの制約を使用して、サービス アカウント キーを作成できるプロジェクトを制限する。
サービス アカウント キーを一時的な場所に残さない。
ユーザー間でサービス アカウント キーの受け渡しを行わない。
サービス アカウント キーをソースコード リポジトリに送信しない。
プログラム バイナリにサービス アカウント キーを埋め込まない。
分析情報と指標を使用して、未使用のサービス アカウント キーを特定する。
鍵の漏えいによるセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションする。
アップロードした鍵を使用して鍵を自動的に期限切れにする。

サービス アカウント キーの作成に代わる方法を用意する

より安全な対策を講じるよりも、新しいサービス アカウント キーを作成するほうが簡単だと考えているユーザーが多い状況では、サービス アカウント キーの数を減らすことは簡単なことではありません。

サービス アカウント キーが安易に作成されないようにするには、サービス アカウント キーに代わる方法をユーザーに認識させ、必要に応じて代替手段を使用できるようにする必要があります。そのためには、次のことを行います。

ユーザーが別の方法でサービス アカウントの認証を行えるようにしたら、組織のポリシーの制約を使用して、サービス アカウント キーの使用を特定のプロジェクトに制限します。

組織のポリシーの制約を使用して、サービス アカウント キーを作成できるプロジェクトを制限する

サービス アカウント キーを作成する必要性を減らすには、サービス アカウントをリソースに関連付ける、Workload Identity を使用する、Workload Identity 連携を使用するなど、いくつかの方法があります。こうした代替手段を用意することで、サービス アカウント キーの使用を標準ではなく、例外とすることをおすすめします。

サービス アカウント キーが安易に使用されないようにするには、組織のポリシーの制約を使用します。

組織のポリシーの制約を変更するには、orgpolicy.policy.set 権限が必要です。この権限はオーナー（roles/owner）ロールにも編集者（roles/editor）ロールにも含まれていないため、一部のプリンシパルしかプロジェクトのオーナー権限または編集者権限を持っていない本番環境以外の環境でも、制約の適用は効果的です。

サービス アカウント キーを一時的な場所に残さない

ほとんどのブラウザでは、Google Cloud Console でサービス アカウント キーを作成するとすぐに新しい鍵がダウンロードされ、パソコンのダウンロード フォルダに保存されます。ダウンロードされた鍵はすぐに所定の保管場所に移動してください。ダウンロード フォルダに鍵のコピーを残してはなりません。また、ごみ箱に誤って移動しないように注意する必要があります。

Google Cloud CLI を使用すると、サービス アカウント キーのコピーを一時的な場所に残すリスクを軽減できます。gcloud iam service-accounts keys create コマンドを使用すると、サービス アカウント キー ファイルを所定の場所に直接書き込むことができます。また、ほとんどのオペレーティング システムでは、gcloud CLI はファイルのアクセス権限を自動的に調整し、本人以外がファイルにアクセスできないようにします。

ユーザー間でサービス アカウント キーの受け渡しを行わない

ユーザーにサービス アカウント キーの作成権限があるとは限りません。サービス アカウント キーを必要とするアプリケーションをデプロイした場合、このようなユーザーが別のユーザーにサービス アカウント キーの作成をリクエストする可能性があります。

サービス アカウント キーの作成とデプロイに複数のユーザーが関与していると、鍵のコピーがメールボックスやチャットの履歴などに残るリスクが高まります。ユーザー間で受け渡しが必要となる場合は、サービス アカウント キーをアップロードするほうが安全です。

  1. アプリケーションをデプロイするユーザーが、ターゲット マシンで RSA 2048 ビットの鍵ペアを使用する自己署名証明書を作成します。証明書の作成には、openssl、certutil、New-SelfSignedCertificate などのオペレーティング システム ツールを使用できます。
  2. 証明書のアップロード権限を持つユーザーに証明書ファイルを渡し、秘密鍵をターゲット マシンに保持します。証明書を渡す際には、証明書の置き換えや改ざんを防ぐ必要がありますが、機密扱いにする必要はありません。
  3. サービス アカウント キーの管理に必要な権限を持つユーザーが証明書をアップロードして、サービス アカウントに関連付けます。

このプロセスを行うことで、秘密鍵の受け渡しを行わず、ユーザー間で公開情報のみを交換することが可能になります。

サービス アカウント キーをソースコード リポジトリに送信しない

サービス アカウント キーは認証情報であり、不正アクセスから保護しなければなりません。サービス アカウント キーをソースコード リポジトリに送信すると、未承認のユーザーや不正なユーザーが鍵にアクセスするリスクが高くなります。

  • 攻撃者が公開のソース リポジトリにあるソースコードをスキャンし、鍵を盗み出す可能性があります。
  • 現在は非公開のソース リポジトリを使用していても、鍵の漏えいをチェックせずに公開リポジトリに切り替えることがないとは言えません。
  • 別のチームのメンバーが自分のワークステーションにソースコードのコピーを保存している可能性もあります。

サービス アカウント キーを使用するコードを扱う場合は、サービス アカウント キーをソースコードとは別に格納し、鍵がソース リポジトリに誤って送信されるリスクを軽減する必要があります。多くの場合、開発中はサービス アカウント キーを使用せず、サービス アカウント キーの代わりに個人の認証情報を使用することで、このリスクをさらに低減できます。

また、サービス アカウント キーの偶発的な送信を検出するようにソースコード管理システムを設定することもできます。

  • Cloud Source Repositories を使用する場合は、鍵検出を有効にして、秘密鍵を含む git push オペレーションをブロックし、ユーザーに通知します。
  • GitHub を使用する場合は、リポジトリでシークレット スキャンを有効にします。
  • Security Command Center の異常検出を使用すると、漏えいした認証情報の情報を確認できます。
  • ソースコード管理システムが自動スキャンに対応していない場合は、truffleHog などのオープンソース ツールを使用します。pre-commit フックを使用するか、継続的インテグレーション パイプラインにステップを追加して、ソースコードに含まれているシークレットを検出します（この両方を実装することも可能です）。

プログラム バイナリにサービス アカウント キーを埋め込まない

サービス アカウント キーは特定のパターンに一致する文字列です。このため、他のファイルやバイナリに埋め込まれている場合でも識別は可能です。攻撃者にとって、バイナリにアクセスできれば、そこに埋め込まれているサービス アカウント キーの抽出はさほど難しい作業ではありません。

サーバーサイド アプリケーションのプログラム バイナリがアーティファクト リポジトリにホストされている可能性があります。また、デバッグ目的でデベロッパーのワークステーションにコピーされることもあります。サービス アカウント キーをプログラム バイナリから分離すれば、バイナリにアクセス可能なユーザーがサービス アカウントの認証情報に暗黙的にアクセスするのを防ぐことができます。

  • ツール、デスクトップ プログラム、モバイルアプリなどのクライアント サイド アプリケーションの場合は、サービス アカウントを使用せず、OAuth 同意フローを使用してユーザーが自分の認証情報で認証できるようにします。
  • サーバーサイド アプリケーションの場合は、サービス アカウント キーをバイナリに埋め込まず、鍵をアプリケーション バイナリから分離して保持します。

分析情報と指標を使用して、未使用のサービス アカウント キーを特定する

使用されている有効なサービス アカウント キーの数を最小限に抑えるには、不要になった鍵を直ちに無効にし、削除することをおすすめします。鍵が使用中かどうかわからない場合は、サービス アカウントの分析情報と認証指標を使用します。

サービス アカウントは Google Cloud プロジェクトに属しているため、分析情報と指標はプロジェクトごとに追跡する必要があります。

鍵の漏えいによるセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションする

サービス アカウント キーが誤って漏えいする可能性を減らすことはできますが、そのリスクを完全に排除することはできません。

鍵が漏えいしても、攻撃者が鍵をすぐに検出できるとは限りません。鍵が見つかるまでに数日または数週間かかることもあります。このタイムラグもリスク軽減に役立ちます。サービス アカウント キーを定期的に無効にして、新しい鍵に置き換えましょう。サービス アカウント キーをローテーションする頻度が高いほど、漏えいしたサービス アカウント キーが攻撃者に悪用される可能性は低くなります。

鍵のローテーションには、push または pull ベースのモデルを使用できます。

  • push ベースのモデルでは、一元化されたツールまたはシステムを使用します。これにより、新しいサービス アカウント キーを定期的に作成し、個々のアプリに push して既存の鍵と置き換え、古いサービス アカウント キーを削除します。

    このモデルでは、中央のツールにのみ、新しいサービス アカウント キーの作成またはアップロード権限が必要ですが、これらの権限は管理対象のすべてのサービス アカウントに対して必要になります。

  • pull ベースのモデルでは、各アプリケーションが鍵のローテーションを処理します。アプリケーションは既存の鍵で認証を行いながら、IAM API を使用して新しいサービス アカウント キーを定期的に作成またはアップロードします。新しいサービス アカウント キーを取得した後、アプリケーションは以前の鍵を削除します。

    このモデルでは、各アプリケーションのサービス アカウントに新しいサービス アカウント キーの作成またはアップロードの権限が必要ですが、これらの権限はそのアプリケーションに対してのみ必要になります。

公開鍵と秘密鍵のペアを自分で生成し、ハードウェア セキュリティ モジュール（HSM）に秘密鍵を保存して、Google に公開鍵をアップロードした場合は、鍵のローテーションを定期的に行う必要はありません。その代わりに、鍵が侵害された可能性がある場合に鍵をローテーションします。

有効期限を使用してキーを自動的に期限切れにする

デフォルトでは、IAM で作成してダウンロードしたサービス アカウント キーには有効期限がありません。削除するまで有効です。サービス アカウント キーの有効期限を設定することは、セキュリティ リスクを軽減するだけでなく、鍵のローテーションが失敗した場合のフェイルセーフにもなります。ただし、有効期限を設定すると、鍵の有効期限が切れた場合に、ワークロードが失敗することもあります。

有効期限は、システムに一時的にアクセスする必要がある場合に使用します。特に、システムにサービス アカウント キーが必要な場合などに使用します。たとえば、次のシナリオでは有効期限を設定します。

  • デベロッパーが、サービス アカウント キーを必要とする Codelab を完了する必要がある。
  • デベロッパーが、サービス アカウント キーが必要な CLI ツールを実行する必要がある。
  • インターンや請負業者などの臨時従業員が、新しいアプリケーションの概念実証を作成する。

以下のシナリオでは、有効期限を使用しないでください。

  • 本番環境ワークロード。本番環境では、サービス アカウント キーが期限切れになると、誤ってサービスが停止する可能性があります。代わりに有効期限のない鍵を使用し、鍵のローテーションでライフサイクルを管理します。
  • 継続的インテグレーション（CI）パイプラインなど、永続的にアクセスする必要がある非本番環境ワークロード。
  • 指定した時間の経過後に鍵が使用されないようにする鍵のローテーション システム。有効期限を設定する代わりに、Cloud Asset Inventory を使用して、指定した時間より前に作成されたサービス アカウント キーを検索し、新しい鍵をデプロイして古い鍵を無効にするようオーナーに依頼します。

サービス アカウント キーの有効期限を設定するには、プロジェクト、フォルダ、組織で新しく作成された鍵の有効期限を構成します。有効期限は、既存の鍵には適用されません。

また、サービス アカウント キーをアップロードして、X.509 証明書ファイルで [失効日] を指定することもできます。有効期限が過ぎた鍵は認証に使用できません。ただし、鍵を削除しない限り、鍵はサービス アカウントに関連付けられています。

権限昇格からの保護

アクセスを許可するリソースよりもサービス アカウント キーの安全性が低い場合、権限昇格攻撃が発生する可能性があります。

たとえば、攻撃者が環境内にすでに侵入し、特定の Google Cloud リソースにアクセスを試みているとします。これらのリソースには権限不足でアクセスできなくても、VM、ファイル共有、他の安全性の低い場所に保存されているサービス アカウント キーにはアクセスできる可能性があります。サービス アカウント キーで認証を行っていると、攻撃者がサービス アカウントの ID を推測し、そのサービス アカウントを利用して、失敗していたリソースへのアクセスに成功する可能性があります（つまり、攻撃者の権限が昇格したことになります）。

サービス アカウント キーは Google Cloud 上のリソースへのアクセスを間接的に許可するため、鍵自体がリソースと同等の価値があり、同等の保護を行う必要があります。

以降のセクションでは、サービス アカウント キーを保護し、不正アクセスと権限昇格のリスクを低減するためのベスト プラクティスについて説明します。

ベスト プラクティス:

鍵をファイル システムに保存しない。
鍵の格納に HSM または TPM を使用する。
ソフトウェア ベースのキーストアを使用する。
Secret Manager やクラウドベースのシークレット ストアに鍵を保存しない。
サービス アカウント キーの作成またはアップロードが許可されているプロジェクトで編集者ロールを使用しない。
ドメイン全体の委任にサービス アカウント キーを使用しない。

鍵をファイル システムに保存しない

Google Cloud Console または gcloud CLI で作成されたサービス アカウント キーは JSON ファイルです。これらのファイルは必要なマシンのファイル システムにコピーできます。ただし、サービス アカウント キーをファイル システムにファイルとして保存すると、次のようなリスクにさらされる可能性があります。

  • NTFS など、一部のファイル システムでは権限の継承がデフォルトで有効になっています。この機能を無効にしていないと、親フォルダの権限により、許可のないユーザーが鍵ファイルにアクセスし、表示してしまう可能性があります。
  • 仮想環境では、基盤となる仮想ディスクにアクセスできれば、ファイル システムのセキュリティが回避される可能性があります。
  • 多くの場合、ファイル システムへのアクセスと権限の変更はログに記録されません。ファイルの権限が誤って変更され、許可のないユーザーに鍵が見えてしまっても、その変更をいつ、だれが行ったのかわからない可能性があります。
  • アクセスに成功した攻撃者はファイルを簡単にコピーし、外部に流出させることができます。

可能な限り、サービス アカウント キーをファイル システムに保存しないようにしてください。鍵をディスクに保存せざるを得ない場合は、鍵ファイルへのアクセスを制限し、ファイル アクセスの監査を構成して、基盤となるディスクを暗号化してください。

鍵の格納に HSM または TPM を使用する

Google Cloud Console または gcloud CLI でサービス アカウント キーを作成すると、Google Cloud によって秘密鍵が生成され、鍵の作成者に公開されます。サービス アカウント キーに関わるセキュリティ リスクの多くは、秘密鍵が一時的または永続的にクリアテキストで利用でき、保護が難しい、という点に起因します。

Google Cloud で鍵ペアを生成する代わりに、次のように、ハードウェア セキュリティ モジュール（HSM）またはトラステッド プラットフォーム モジュール（TPM）で鍵の作成と管理を行うこともできます。

  1. HSM または TPM を使用して RSA 鍵ペアを生成します。
  2. 鍵ペアを使用して自己署名証明書を作成します。
  3. サービス アカウント キーとして証明書をアップロードします。
  4. アプリケーションで HSM または TPM の署名 API を使用して JWT に署名し、サービス アカウントの認証に使用します。

HSM または TPM を使用すると、クリアテキストで公開することなく秘密鍵を使用できます。HSM または TPM を使用してサービス アカウント キーを管理することで、アクセス制御を強化するだけでなく、他のシステムに鍵がコピーされるリスクを軽減できます。

一部のプラットフォームでは、TPM を利用できる抽象化が提供されています。このようなプラットフォームでは TPM を直接操作する必要はありません。たとえば、Windows では、CryptoNG API と Microsoft Platform Crypto Provider を使用することで、TPM で保護された鍵を管理できます。

TPM で管理されるサービス アカウント キーは、物理マシンまたは仮想マシンに固有の鍵になります。各マシンの鍵を共通のサービス アカウントに関連付けることで、複数のマシンでサービス アカウントを共有できます。

ソフトウェア ベースのキーストアを使用する

ハードウェア ベースのキーストアを使用できない場合は、ソフトウェア ベースのキーストアでサービス アカウント キーを管理します。ハードウェア ベースの場合と同様に、ソフトウェア ベースのキーストアを使用すると、ユーザーやアプリケーションは秘密鍵を公開せずにサービス アカウント キーを使用できます。ソフトウェアベースのキーストア ソリューションでは、鍵へのアクセスをきめ細かく管理し、鍵へのアクセスをロギングできます。

一般に、ソフトウェア ベースのキーストアのセキュリティはマスターキーの保護方法によって異なります。ソフトウェア ベースのキーストアを使用する前に、次の点を確認してください。

  • 保存時のマスターキーの保護方法
  • シール解除プロセスの仕組みとそれを開始できるユーザー
  • メモリからの鍵の抽出を防ぐ方法
  • 攻撃者が基盤システムへのシェルアクセスまたはハイパーバイザ アクセスを取得した場合に、キーストアへの攻撃を防ぐ方法

Secret Manager やクラウドベースのシークレット ストアに鍵を保存しない

Google Cloud や他のクラウド プロバイダは、さまざまなタイプのシークレットを管理できるマネージド キーストアを提供しています。たとえば、Secret Manager、Azure KeyVault、AWS Secret Manager などが提供されています。これらのキーストアにサービス アカウント キーを保存する場合は、クラウド プロバイダの IAM システムを使用してシークレットへのアクセスを制御する必要があります。IAM を使用してシークレットへのアクセス制御と Google Cloud リソースへのアクセス権の付与を行うのではなく、Workload Identity 連携を使用して、サービス アカウント キーを作成せずにアクセス権を管理してください。

サービス アカウント キーの作成またはアップロードが許可されているプロジェクトで編集者ロールを使用しない

基本ロールの編集者（roles/editor）とオーナー（roles/owner）の主な違いは、編集者ロールでは IAM のポリシーとロールを変更できない点です。基本的に、編集者のロールでは自分のアクセス権を拡張することや、他のユーザーにプロジェクト リソースへのアクセス権を付与することはできません。

プロジェクトにサービス アカウントが含まれている場合、このような編集者ロールの制限が回避される可能性があります。編集者ロールには、サービス アカウント キーの作成またはアップロードを行う権限が含まれているため、このロールが悪用されると、既存のサービス アカウントに新しい鍵が作成され、これらの鍵により攻撃者の権限昇格が行われる可能性があります。また、この鍵が他のユーザーに配布され、プロジェクト リソースへのアクセスが許可される可能性もあります。

編集者などの基本ロールを使用せずに、より権限が制限された事前定義ロールを使用するか、必要な権限のみを付与するカスタムロールを作成することをおすすめします。

編集者ロールを使用する必要がある場合は、編集者ロールが権限昇格に悪用されないように、組織のポリシーの制約を使用してサービス アカウント キーのアップロードとキーの作成を無効にしてください。

ドメイン全体の委任にサービス アカウント キーを使用しない

ドメイン全体の委任を行うと、ユーザーの権限借用が可能になり、手動による承認を行わずにユーザーのデータにアクセスできるようになります。ドメイン全体の委任を説明する例では、サービス アカウント キーがよく使用されていますが、ドメイン全体の委任にサービス アカウント キーを使用する必要はありません。

ドメイン全体の委任を使用する場合は、サービス アカウント キーではなく、signJwt API を使用してください。

  1. サービス アカウントの認証には、関連付けられたサービス アカウント、Workload Identity、または Workload identity 連携を使用します。
  2. JWT を作成して sub クレームを使用し、委任アクセスをリクエストするユーザーのメールアドレスを指定します。
  3. signJwt API を使用して JWT に署名します。
  4. OAuth2 トークン リソースに署名済みの JWT を渡して、アクセス トークンを取得します。

この方法では、サービス アカウント キーを管理する必要がなくなり、安全性が高まります。

情報漏えいの脅威からの保護

ベスト プラクティス:

アップロードする X.509 証明書に機密情報を含めない。

アップロードされる X.509 証明書に機密情報を含めない

IAM では、サービス アカウント キーごとにエンドポイント https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL から X.509 証明書をダウンロードできます。このエンドポイントは一般公開されていて、認証は必要ありません。

Google Cloud Console または gcloud CLI を使用して作成した Google 管理の鍵とユーザー管理の鍵の場合、X.509 証明書が自動的に作成されます。この証明書には、メールアドレスや有効期限などの基本的なメタデータのみが含まれています。

アップロードされたサービス アカウント キーの場合、パブリック エンドポイントが提供する X.509 証明書はユーザーがアップロードした証明書と同じになります。アップロードした証明書にオプションの属性（共通名に埋め込まれたアドレスや位置情報など）が含まれている場合、これらの情報も一般公開されます。攻撃者がこの情報から環境の詳細を知る可能性があります。

機密情報の開示を防ぐため、アップロードされた X.509 証明書にオプションの属性を追加せず、汎用の Subject を使用してください。

否認防止の脅威からの保護

Google Cloud リソースに影響を与える不審なアクティビティを確認し、その発信元を特定するには、不審なアクティビティにつながる一連のイベントを再構成できるデータが必要です。通常、このような分析では監査ログをデータソースとして利用します。

サービス アカウントが関係する場合は監査ログの分析が難しくなることがあります。アクティビティがサービス アカウントによって開始された場合、ログエントリにはサービス アカウントのメールアドレスが含まれますが、その時点でどのユーザーまたはアプリケーションがサービス アカウントを使用していたのかも突き止める必要があります。

以降のセクションでは、サービス アカウント キーの使用状況を追跡する際のベスト プラクティスについて説明します。

ベスト プラクティス:

アプリケーションごとに専用のサービス アカウントを使用する。
アプリケーションを実行するマシンごとに専用の鍵を使用する。

アプリケーションごとに専用のサービス アカウントを使用する

すべての監査ログレコードには principalEmail フィールドが含まれています。このフィールドには、アクティビティを開始したプリンシパルが記録されています。複数のアプリケーションでサービス アカウント キーを共有している場合は、監査ログレコードに同じ principalEmail 値が含まれるため、アクティビティを実行したアプリケーションの特定が難しい場合があります。

複数のアプリケーションで鍵を共有するのではなく、アプリケーションごとに専用のサービス アカウントを作成してください。こうすることで、principalEmail フィールドでサービス アカウントに関連付けられたアプリケーションを識別できるので、不審なアクティビティにつながった一連のイベントの再構成が容易になります。

アプリケーションを実行するマシンごとに専用の鍵を使用する

同じアプリケーションのコピーを複数のマシンで実行している場合は、principalEmail フィールドでアプリケーションを特定できますが、特定のアクティビティの発生源であるマシンが識別できない場合があります。

不審なアクティビティの潜在的な発生源を絞り込むため、アプリケーションのコピーごとに鍵を作成してください。こうすることで、多くのサービスが監査ログレコードに serviceAccountKeyName フィールドを追加し、これによりアクティビティが発生したマシンを識別できます。

次のステップ