通常のユーザーとは異なり、サービス アカウントにはパスワードがありません。その代わりに、サービス アカウントは RSA 鍵ペアを使用して認証を行います。サービス アカウントの鍵ペアの秘密鍵がわかっている場合は、秘密鍵を使用して JWT 署名なしトークンを作成し、そのトークンを使ってアクセス トークンをリクエストできます。生成されたアクセス トークンにはサービス アカウントの ID が反映されています。このトークンを使用することで、サービス アカウントに代わって Google Cloud APIs を操作できます。
秘密鍵を使用するとサービス アカウントとして認証できるため、秘密鍵へのアクセスはユーザーのパスワードを知ることと似ています。秘密鍵はサービス アカウント キーと呼ばれています。サービス アカウントで使用される鍵ペアには、Google 管理とユーザー管理の 2 つのカテゴリがあります。
サービス アカウント キーの管理は慎重に行ってください。扱いを誤ると、セキュリティ上のリスクが生じる可能性があります。可能であれば、認証により安全な代替手段を選択してください。サービス アカウント キーに関連する主な脅威としては、次のようなものがあります。
- 認証情報の漏えい: サービス アカウント キーが、本来保管すべきではない場所に誤って保存される可能性があります。漏えいしたサービス アカウント キーが悪用され、ユーザーの環境内に攻撃の足場が作られる可能性があります。
- 権限昇格: サービス アカウント キーの保護が十分でないと、このような鍵が権限の昇格に利用される可能性があります。
- 情報開示: サービス アカウント キーにより、機密性のあるメタデータが誤って公開される可能性があります。
- 否認防止: サービス アカウント キーを使用して認証を行い、サービス アカウントでオペレーションを実行すると、攻撃者が身元を隠して操作を実行する可能性があります。
このような脅威を軽減する最善の方法は、ユーザー管理のサービス アカウント キーを使用せず、可能な限り別の方法でサービス アカウントの認証を行うことです。また、IAM Conditions と VPC Service Controls を使用して、乗っ取られたサービス アカウントでアクセス可能なリソースを制限することもできます。
このガイドでは、サービス アカウント キーよりも安全な代替手段を使用できない場合に、サービス アカウント キーを管理、使用、保護するためのベスト プラクティスを紹介します。
認証情報の漏えいを防ぐ
サービス アカウント キーは、ユーザー名やパスワードと同様に認証情報の一つです。有効なサービス アカウント キーにアクセスできるユーザーは、この鍵を使用して認証を行い、サービス アカウントにアクセス権のあるリソースを使用できます。
攻撃者にとっては、漏えいしたパスワードよりもサービス アカウント キーのほうが価値が高い可能性があります。漏えいしたパスワードでログインを試みても、ユーザー アカウントに 2 段階認証プロセスやログイン時の本人確認が構成されていれば、ログインに成功する可能性は低くなります。対照的に、サービス アカウントは追加のログイン検証の対象ではないため、漏えいしたサービス アカウント キーを使用した認証は成功する可能性が高くなります。
攻撃者は、さまざまな場所でサービス アカウント キーを検索しています。たとえば、次のような場所が狙われます。
- オープンソース プロジェクトのソースコード リポジトリ
- 一般公開の Cloud Storage バケット
- 侵害されたサービスについて、一般に公開されているデータダンプ
攻撃者が情報を探すのは公開されている場所だけではありません。非公開の場所に侵入し、サービス アカウント キーを探す可能性もあります。次に例を示します。
- メール ボックス
- ファイル共有
- バックアップ ストレージ
- 一時ファイル システムのディレクトリ
サービス アカウント キーの漏えいリスクを低減する効果的な方法は、使用されている鍵の数を減らし、新しい鍵が作成されないようにすることです。以降のセクションでは、サービス アカウント キーの数を制限する方法と、サービス アカウントの漏えいリスクを軽減する別の方法について説明します。
ベスト プラクティス:
サービス アカウント キーの作成に代わる方法を用意する。組織のポリシーの制約を使用して、サービス アカウント キーを作成できるプロジェクトを制限する。
サービス アカウント キーを一時的な場所に残さない。
ユーザー間でサービス アカウント キーの受け渡しを行わない。
サービス アカウント キーをソースコード リポジトリに送信しない。
プログラム バイナリにサービス アカウント キーを埋め込まない。
分析情報と指標を使用して、未使用のサービス アカウント キーを特定する。
鍵の漏えいによるセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションする。
有効期限を設定して鍵を自動的に期限切れにする。
組織のポリシーの制約を使用して、漏洩した鍵を自動的に無効にする。
サービス アカウント キーの作成に代わる方法を用意する
組織内のユーザーが代替手段を認識し、サービス アカウント キーの使用に伴うリスクと管理上のオーバーヘッドを説明できるようにします。
- サービス アカウント キーよりも安全な代替手段についてデベロッパーに説明します。
- 新しいサービス アカウント キーを作成する前に、デベロッパーがユースケースに適した認証方法を決定するためのプロセスを確立します。
- 組織のポリシーの制約を使用して新しいサービス アカウント キーの作成を禁止し、より安全な代替手段を使用できないことが判明しているプロジェクトに限り例外を許可します。
組織のポリシーの制約を使用して、サービス アカウント キーを作成できるプロジェクトを制限する
サービス アカウント キーよりも安全な代替手段が指定された場合は、サービス アカウント キーの使用を標準ではなく、例外とみなすことをおすすめします。
サービス アカウント キーが安易に使用されないようにするには、組織のポリシーの制約を使用します。
組織のリソース階層のルートに、サービス アカウント キー作成の無効化とサービス アカウント キー アップロードの無効化の制約を適用し、デフォルトでサービス アカウント キーの使用を禁止します。
必要であれば、選択したプロジェクトの制約の 1 つをオーバーライドし、サービス アカウント キーの作成またはアップロードを許可します。
組織のポリシーの制約を変更するには、orgpolicy.policy.set 権限が必要です。この権限はオーナー（roles/owner）ロールにも編集者（roles/editor）ロールにも含まれていないため、一部のプリンシパルしかプロジェクトのオーナー権限または編集者権限を持っていない本番環境以外の環境でも、制約の適用は効果的です。
サービス アカウント キーを一時的な場所に残さない
ほとんどのブラウザでは、Google Cloud Console でサービス アカウント キーを作成するとすぐに新しい鍵がダウンロードされ、パソコンのダウンロード フォルダに保存されます。ダウンロードされた鍵はすぐに所定の保管場所に移動してください。ダウンロード フォルダに鍵のコピーを残してはなりません。また、ごみ箱に誤って移動しないように注意する必要があります。
Google Cloud CLI を使用すると、サービス アカウント キーのコピーを一時的な場所に残すリスクを軽減できます。gcloud iam service-accounts keys create コマンドを使用すると、サービス アカウント キー ファイルを所定の場所に直接書き込むことができます。また、ほとんどのオペレーティング システムでは、gcloud CLI はファイルのアクセス権限を自動的に調整し、本人以外がファイルにアクセスできないようにします。
ユーザー間でサービス アカウント キーの受け渡しを行わない
ユーザーにサービス アカウント キーの作成権限があるとは限りません。サービス アカウント キーを必要とするアプリケーションをデプロイした場合、このようなユーザーが別のユーザーにサービス アカウント キーの作成をリクエストする可能性があります。
サービス アカウント キーの作成とデプロイに複数のユーザーが関与していると、鍵のコピーがメールボックスやチャットの履歴などに残るリスクが高まります。ユーザー間で受け渡しが必要となる場合は、サービス アカウント キーをアップロードするほうが安全です。
- アプリケーションをデプロイするユーザーが、ターゲット マシンで RSA 2048 ビットの鍵ペアを使用する自己署名証明書を作成します。証明書の作成には、
openssl、certutil、New-SelfSignedCertificateなどのオペレーティング システム ツールを使用できます。 - 証明書のアップロード権限を持つユーザーに証明書ファイルを渡し、秘密鍵をターゲット マシンに保持します。証明書を渡す際には、証明書の置き換えや改ざんを防ぐ必要がありますが、機密扱いにする必要はありません。
- サービス アカウント キーの管理に必要な権限を持つユーザーが証明書をアップロードして、サービス アカウントに関連付けます。
このプロセスを行うことで、秘密鍵の受け渡しを行わず、ユーザー間で公開情報のみを交換することが可能になります。
サービス アカウント キーをソースコード リポジトリに送信しない
サービス アカウント キーは認証情報であり、不正アクセスから保護しなければなりません。サービス アカウント キーをソースコード リポジトリに送信すると、未承認のユーザーや不正なユーザーが鍵にアクセスするリスクが高くなります。
- 攻撃者が公開のソース リポジトリにあるソースコードをスキャンし、鍵を盗み出す可能性があります。
- 現在は非公開のソース リポジトリを使用していても、鍵の漏えいをチェックせずに公開リポジトリに切り替えることがないとは言えません。
- 別のチームのメンバーが自分のワークステーションにソースコードのコピーを保存している可能性もあります。
サービス アカウント キーを使用するコードを扱う場合は、サービス アカウント キーをソースコードとは別に格納し、鍵がソース リポジトリに誤って送信されるリスクを軽減する必要があります。多くの場合、開発中はサービス アカウント キーを使用せず、サービス アカウント キーの代わりに個人の認証情報を使用することで、このリスクをさらに低減できます。
また、サービス アカウント キーの偶発的な送信を検出するようにソースコード管理システムを設定することもできます。
- Cloud Source Repositories を使用する場合は、鍵検出を有効にして、秘密鍵を含む
gitpush オペレーションをブロックし、ユーザーに通知します。 - GitHub を使用する場合は、リポジトリでシークレット スキャンを有効にします。
- Security Command Center の異常検出を使用すると、漏えいした認証情報の情報を確認できます。
- ソースコード管理システムが自動スキャンに対応していない場合は、truffleHog などのオープンソース ツールを使用します。pre-commit フックを使用するか、継続的インテグレーション パイプラインにステップを追加して、ソースコードに含まれているシークレットを検出します（この両方を実装することも可能です）。
プログラム バイナリにサービス アカウント キーを埋め込まない
サービス アカウント キーは特定のパターンに一致する文字列です。このため、他のファイルやバイナリに埋め込まれている場合でも識別は可能です。攻撃者にとって、バイナリにアクセスできれば、そこに埋め込まれているサービス アカウント キーの抽出はさほど難しい作業ではありません。
サーバーサイド アプリケーションのプログラム バイナリがアーティファクト リポジトリにホストされている可能性があります。また、デバッグ目的でデベロッパーのワークステーションにコピーされることもあります。サービス アカウント キーをプログラム バイナリから分離すれば、バイナリにアクセス可能なユーザーがサービス アカウントの認証情報に暗黙的にアクセスするのを防ぐことができます。
- ツール、デスクトップ プログラム、モバイルアプリなどのクライアント サイド アプリケーションの場合は、サービス アカウントを使用せず、OAuth 同意フローを使用してユーザーが自分の認証情報で認証できるようにします。
- サーバーサイド アプリケーションの場合は、サービス アカウント キーをバイナリに埋め込まず、鍵をアプリケーション バイナリから分離して保持します。
分析情報と指標を使用して、未使用のサービス アカウント キーを特定する
使用されている有効なサービス アカウント キーの数を最小限に抑えるには、不要になった鍵を直ちに無効にし、削除することをおすすめします。鍵が使用中かどうかわからない場合は、サービス アカウントの分析情報と認証指標を使用します。
- サービス アカウントの分析情報を使用すると、過去 90 日間に使用されていないサービス アカウントを特定できます。
- 鍵認証イベント指標をモニタリングすると、サービス アカウント キーが最後に使用された日時を特定し、サービス アカウントの認証に使用された頻度を確認できます。
サービス アカウントは Google Cloud プロジェクトに属しているため、分析情報と指標はプロジェクトごとに追跡する必要があります。
鍵の漏えいによるセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションする
サービス アカウント キーが誤って漏えいする可能性を減らすことはできますが、そのリスクを完全に排除することはできません。
鍵のローテーションは、既存の鍵を新しい鍵に置き換えてから、置き換えた鍵を無効にするプロセスです。サービス アカウント キーを含む、管理するすべての鍵を定期的にローテーションすることをおすすめします。
サービス アカウント キーをローテーションすると、鍵の漏洩や盗難のリスクを低減できます。鍵が漏えいした場合、数日から数週間で不正な行為者が鍵を特定してしまう可能性があります。サービス アカウント キーを定期的にローテーションすれば、漏えいした鍵が不正な行為者の手に渡るまでに無効化されている可能性が高くなります。
サービス アカウント キーのローテーション プロセスを確立しておくと、サービス アカウント キーが不正使用された疑いがある場合にも迅速に対応できます。
公開鍵と秘密鍵のペアを自分で生成し、ハードウェア セキュリティ モジュール（HSM）に秘密鍵を保存して、Google に公開鍵をアップロードした場合は、鍵のローテーションを定期的に行う必要はありません。その代わりに、鍵が侵害された可能性がある場合に鍵をローテーションします。
有効期限を設定して鍵を自動的に期限切れにする
デフォルトでは、IAM で作成してダウンロードしたサービス アカウント キーに有効期限はありません。削除するまで有効です。サービス アカウント キーに有効期限を設定すると、永続的な認証情報の存続期間を短くし、セキュリティ リスクを抑えることができます。ただし、有効期限の設定にもリスクがあります。たとえば、有効期限を設定すると、鍵の有効期限が切れたときにワークロードが失敗する可能性があります。
サービス アカウント キーを必要とするシステムに一時的にアクセスする必要がある場合は、有効期限を使用します。たとえば、次のような場合に有効期限を使用します。
- サービス アカウント キーでのみ認証できるアプリケーションのコードを非本番環境で開発する
- サービス アカウント キーでのみ認証できるサードパーティ製ツールを使用する
以下のシナリオでは、有効期限を使用しないでください。
- 本番環境ワークロード。本番環境では、サービス アカウント キーが期限切れになると、誤ってサービスが停止する可能性があります。代わりに有効期限のない鍵を使用し、鍵のローテーションでライフサイクルを管理します。
- 継続的インテグレーション（CI）パイプラインなど、永続的にアクセスする必要がある非本番環境ワークロード。
- 指定した時間の経過後に鍵が使用されないようにする鍵のローテーション システム。推奨の鍵ローテーション戦略については、サービス アカウント キーのローテーションをご覧ください。
サービス アカウント キーの有効期限を設定するには、プロジェクト、フォルダ、組織で新しく作成された鍵に有効期限を構成します。有効期限は、既存の鍵に適用されません。
また、サービス アカウント キーをアップロードして、X.509 証明書ファイルで失効日を指定することもできます。有効期限が過ぎた鍵は認証に使用できません。ただし、鍵を削除しない限り、鍵はサービス アカウントに関連付けられています。
組織のポリシーの制約を使用して漏洩した鍵を自動的に無効にする
サービス アカウント キーに関するすべてのベスト プラクティスに従っていても、サービス アカウント キーは漏洩する可能性があります。
漏洩した認証情報を管理を容易にするために、Service Account Key Exposure Response の制約が DISABLE_KEY に設定されていることを確認してください。制約をこの値に設定すると、Google Cloud は検出した漏洩鍵を自動的に無効にします。
キーが漏洩したために無効になっている場合、次のフィールドがキーのメタデータに追加されます。
"disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": 公開されたためにキーが無効になっていることを示します。"extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": キーが一度公開されたことを示します。この値は、鍵を再度有効にしても保持されます。"extended_status_message": "LINK_TO_EXPOSURE": 利用可能な場合、メタデータには、キーが検出された場所へのリンクが含まれます。このリンクは、修復に使用できます。
これらの鍵は、サービスの停止を軽減するために再度有効にできます。ただし、一度公開された鍵は非公開にしてもセキュリティ リスクとなるため、できるだけ早く無効にすることをおすすめします。
不正使用された認証情報を管理するための他のベスト プラクティスについては、Google Cloud 認証情報の不正使用への対応をご覧ください。
権限昇格からの保護
アクセスを許可するリソースよりもサービス アカウント キーの安全性が低い場合、権限昇格攻撃が発生する可能性があります。
たとえば、攻撃者が環境内にすでに侵入し、特定の 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）で鍵の作成と管理を行うこともできます。
- HSM または TPM を使用して RSA 鍵ペアを生成します。
- 鍵ペアを使用して自己署名証明書を作成します。
- サービス アカウント キーとして証明書をアップロードします。
- アプリケーションで 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 を使用することはおすすめしません。Secret Manager のシークレットにアクセスするには、Google Cloud が認識可能な ID がアプリケーションで必要になるためです。アプリケーションに Google Cloud が認識可能な ID がすでに存在する場合、アプリケーションはサービス アカウント キーではなく、その ID を使用して Google Cloud の認証を行うことができます。
同じことが Azure KeyVault や AWS Secret Manager などの他のクラウドベースのシークレット管理サービスにも当てはまります。これらのクラウド プロバイダが認識可能な ID がアプリケーションにすでに存在する場合、サービス アカウント キーではなく、その ID を使用して Google Cloud の認証を行うことができます。
サービス アカウント キーの作成またはアップロードが許可されているプロジェクトで編集者ロールを使用しない
基本ロールの編集者（roles/editor）とオーナー（roles/owner）の主な違いは、編集者ロールでは IAM のポリシーとロールを変更できない点です。基本的に、編集者のロールでは自分のアクセス権を拡張することや、他のユーザーにプロジェクト リソースへのアクセス権を付与することはできません。
プロジェクトにサービス アカウントが含まれている場合、このような編集者ロールの制限が回避される可能性があります。編集者ロールには、サービス アカウント キーの作成またはアップロードを行う権限が含まれているため、このロールが悪用されると、既存のサービス アカウントに新しい鍵が作成され、これらの鍵により攻撃者の権限昇格が行われる可能性があります。また、この鍵が他のユーザーに配布され、プロジェクト リソースへのアクセスが許可される可能性もあります。
編集者などの基本ロールを使用せずに、より権限が制限された事前定義ロールを使用するか、必要な権限のみを付与するカスタムロールを作成することをおすすめします。
編集者ロールを使用する必要がある場合は、編集者ロールが権限昇格に悪用されないように、組織のポリシーの制約を使用してサービス アカウント キーのアップロードとキーの作成を無効にしてください。
ドメイン全体の委任にサービス アカウント キーを使用しない
ドメイン全体の委任を行うと、ユーザーの権限借用が可能になり、手動による承認を行わずにユーザーのデータにアクセスできるようになります。ドメイン全体の委任を説明する例では、サービス アカウント キーがよく使用されていますが、ドメイン全体の委任にサービス アカウント キーを使用する必要はありません。
ドメイン全体の委任を使用する場合は、サービス アカウント キーではなく、signJwt API を使用してください。
- サービス アカウントの認証には、関連付けられたサービス アカウント、Workload Identity Federation for GKE、または Workload Identity 連携を使用します。
- JWT を作成して
subクレームを使用し、委任アクセスをリクエストするユーザーのメールアドレスを指定します。 signJwtAPI を使用して JWT に署名します。- OAuth2 トークン リソースに署名済みの JWT を渡して、アクセス トークンを取得します。
この方法では、サービス アカウント キーを管理する必要がなくなり、安全性が高まります。
情報漏えいの脅威からの保護
アップロードされる X.509 証明書に機密情報を含めない
IAM では、サービス アカウント キーごとにエンドポイント https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL から X.509 証明書をダウンロードできます。このエンドポイントは一般公開されていて、認証は必要ありません。
Google Cloud コンソールまたは gcloud CLI を使用して作成した Google 管理の鍵とユーザー管理の鍵の場合、X.509 証明書が自動的に作成されます。この証明書には、メールアドレスや有効期限などの基本的なメタデータのみが含まれています。
アップロードされたサービス アカウント キーの場合、パブリック エンドポイントが提供する X.509 証明書はユーザーがアップロードした証明書と同じになります。アップロードした証明書にオプションの属性（共通名に埋め込まれたアドレスや位置情報など）が含まれている場合、これらの情報も一般公開されます。攻撃者がこの情報から環境の詳細を知る可能性があります。
機密情報の開示を防ぐため、アップロードされた X.509 証明書にオプションの属性を追加せず、汎用の Subject を使用してください。
否認防止の脅威からの保護
Google Cloud リソースに影響を与える不審なアクティビティを確認し、その発信元を特定するには、不審なアクティビティにつながる一連のイベントを再構成できるデータが必要です。通常、このような分析では監査ログをデータソースとして利用します。
サービス アカウントが関係する場合は監査ログの分析が難しくなることがあります。アクティビティがサービス アカウントによって開始された場合、ログエントリにはサービス アカウントのメールアドレスが含まれますが、その時点でどのユーザーまたはアプリケーションがサービス アカウントを使用していたのかも突き止める必要があります。
以降のセクションでは、サービス アカウント キーの使用状況を追跡する際のベスト プラクティスについて説明します。
アプリケーションごとに専用のサービス アカウントを使用する
すべての監査ログレコードには principalEmail フィールドが含まれています。このフィールドには、アクティビティを開始したプリンシパルが記録されています。複数のアプリケーションでサービス アカウント キーを共有している場合は、監査ログレコードに同じ principalEmail 値が含まれるため、アクティビティを実行したアプリケーションの特定が難しい場合があります。
複数のアプリケーションで鍵を共有するのではなく、アプリケーションごとに専用のサービス アカウントを作成してください。こうすることで、principalEmail フィールドでサービス アカウントに関連付けられたアプリケーションを識別できるので、不審なアクティビティにつながった一連のイベントの再構成が容易になります。
アプリケーションを実行するマシンごとに専用の鍵を使用する
同じアプリケーションのコピーを複数のマシンで実行している場合は、principalEmail フィールドでアプリケーションを特定できますが、特定のアクティビティの発生源であるマシンが識別できない場合があります。
不審なアクティビティの潜在的な発生源を絞り込むため、アプリケーションのコピーごとに鍵を作成してください。こうすることで、多くのサービスが監査ログレコードに serviceAccountKeyName フィールドを追加し、これによりアクティビティが発生したマシンを識別できます。