Google CloudのSAキー漏洩対策、止める？止めない？- 組織ポリシー `iam.serviceAccountKeyExposureResponse` の深掘り解説

はじめに

インフラチームのkuribo-です。

「うっかりサービスアカウント（SA）キーをパブリックなGitHubリポジトリにコミットしてしまった…！」
Google Cloudを扱うエンジニアなら、一度はこんな悪夢を想像したことがあるのではないでしょうか。
この小さなミスが大規模なセキュリティインシデントに繋がる可能性を秘めているのですから、考えただけでも冷や汗が出ますよね。

Google Cloudには、幸いにもこうしたキーの漏洩を自動で検知しキーを無効化してくれる素晴らしい仕組みが備わっています。
しかし、ここで1つ新たな問いが生まれます。
もし、その検知が何らかの間違い（誤検知）で、そのSAキーを使っているシステムが業務上絶対に止まってはならないものだったら…？

セキュリティを優先してキーを止めるべきか、それともサービスの可用性を優先して止めないべきか。
これは非常に悩ましい問題です。

実は、Google Cloudにはこうした究極の選択を我々エンジニア自身がコントロールできる少しニッチですが非常に重要な機能が存在します。
それが今回ご紹介する組織ポリシーの「constraints/iam.serviceAccountKeyExposureResponse」です。
（以前この組織ポリシーが強制有効になる前に組織ポリシーを試した記事がありますので、そちらも参照いただけると幸いです。）

この記事では、この組織ポリシーがどのようなものでどのように設定するのか、
そして万が一の事態に備えて通知を確実に受け取るための「Essential Contacts」との連携について、私の経験も交えながら深掘りして解説していきます。
SAキーの運用に一抹の不安を抱えている方、より堅牢なクラウド環境を目指す方のための一歩進んだ内容をお届けします。

SAキー漏洩検知の仕組みとデフォルトの挙動

まず、Google CloudがどのようにしてSAキーの漏洩を検知しているのか、その仕組みから見ていきましょう。
Googleは、GitHubのような公開リポジトリを常にスキャンしており、
そこにGoogle CloudのSAキーと思われる文字列が公開されるとそれを検知する仕組みを持っています。

そして漏洩が検知された場合、Google CloudはデフォルトでそのSAキーを自動的に無効化します。
これは非常に強力な保護機能であり、悪意のある第三者によるキーの悪用を即座に防ぐことができます。
ほとんどのシステムにおいてはこのデフォルトの挙動、つまり「検知したら即無効化（DISABLE_KEY）」が最も安全で推奨される設定であることは間違いありません。

組織ポリシー iam.serviceAccountKeyExposureResponse とは？

それでは、本題の組織ポリシー constraints/iam.serviceAccountKeyExposureResponse について解説します。
これは先ほど説明したSAキー漏洩検知後のレスポンス、つまり「どう対応するか」を組織レベルで一元的に管理・制御するためのポリシーです。
このポリシーを使うことで、我々はGoogle Cloudのデフォルトの挙動を意図的に変更することが可能になります。

このポリシーには主に2つの設定値が用意されています。

DISABLE_KEY:
これがデフォルトの挙動です。
漏洩が検知されると、そのSAキーは即座に自動で無効化されます。
セキュリティを最優先し、インシデントの発生を未然に防ぐための設定です。

WAIT_FOR_ABUSE:
こちらが今回の記事の核心となる設定です。
この値に設定すると、SAキーの漏洩が検知されてもキーはすぐには無効化されません。
その代わり、後述するEssential Contactsに通知が送られ対応は管理者に委ねられます。
ただし、Google Cloudプラットフォーム全体に悪影響を及ぼすような悪用が確認された場合は、この設定に関わらず無効化される可能性があることには注意が必要です。

この WAIT_FOR_ABUSE は、誤検知によるサービス停止が絶対に許されない、極めて高い可用性が求められるシステムを運用している場合にのみ、
慎重に検討すべき選択肢と言えるでしょう。

Essential Contacts との連携の重要性

WAIT_FOR_ABUSE を設定するということは、「自動で止めない」代わりに「人間が迅速に対応する」という責任を負うことを意味します。
そのために不可欠なのが、Google Cloudからの重要な通知を確実に受け取るための仕組み、「Essential Contacts（重要な連絡先）」です。

SAキーの漏洩が検知された際の通知は、Essential Contactsの「セキュリティ」カテゴリに登録されたメールアドレスに送信されます。
もし、このカテゴリに何も設定されていない場合、通知は組織の管理者（resourcemanager.organizationAdmin ロールを持つユーザー）にフォールバックされますが、
これでは担当者が通知を見逃してしまう可能性があります。

人事異動などで担当者が変わることも考慮し、個人のメールアドレスではなく担当チームのメーリングリストなどを登録しておくと、
メンテナンスにかかるコストを減らすことができます。

WAIT_FOR_ABUSE を採用するなら、Essential Contactsの「セキュリティ」カテゴリに、24時間365日いつでも対応できるチームの連絡先を必ず設定しておく。
これはセットで考えるべき非常に重要な運用プラクティスです。

設定方法

では、実際にこの組織ポリシーを設定する方法を見ていきましょう。
設定はGoogle Cloudコンソールから行うことができます。

gcloudコマンドを利用した設定については以下のドキュメントを参照してください。
https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts?hl=ja#disable-exposed-keys

操作には組織レベルでの「組織ポリシー管理者（roles/orgpolicy.policyAdmin）」のIAMロールが必要です。

コンソールから設定する場合は、「IAMと管理」>「組織のポリシー」へ移動し、「iam.serviceAccountKeyExposureResponse」でフィルタリングして設定を編集します。

この設定により、SAキーが漏洩したと検知されても、キーは無効化されず、Essential Contactsへの通知のみが行われるようになります。

「止めない」選択肢とベストプラクティス

WAIT_FOR_ABUSE という選択肢は、一見すると危険に見えるでしょう。
その認識は正しいです。
通知を見逃したり対応が遅れたりすれば、実際の漏洩が発生していた場合に被害が拡大するリスクを直接的に受け入れることになります。

私の経験上もほとんどのプロジェクトではデフォルトの DISABLE_KEY で十分であり、むしろ積極的に推奨すべきです。
しかし、システムによっては停止が許されないものもあります。そうした場合、誤検知を懸念されるお客様からは「強制停止しない設定は可能か？」 と質問をいただくことがあります。
このような要件に対して、WAIT_FOR_ABUSE は最後の砦となり得る選択肢です。

しかし、この設定を検討する前に、我々がまず考えるべきことがあります。
それは、そもそも「SAキーを使わない」アーキテクチャへの移行です。

Google Cloudがベストプラクティスとして推奨しているのが、「Workload Identity Federation」の利用です。
これはAWSやAzure、GitHub Actionsといった外部のIDプロバイダ（IdP）が発行する一時的な認証情報を使い、Google Cloudのリソースにアクセスする仕組みです。

この方法の最大のメリットは、有効期限のない永続的なSAキーファイルを管理・配布する必要がなくなることです。
キーが存在しないのですから漏洩のリスクも根本から排除できます。
SAキーのローテーションや厳重な保管といった、これまで頭を悩ませてきた運用からも解放されます。

iam.serviceAccountKeyExposureResponse の設定を悩む前に、まずはWorkload Identity Federationを導入できないか、徹底的に検討すること。
これが、セキュリティと可用性の両方を高いレベルで実現するための、最も確実な道筋であると私は考えています。

まとめ

今回は、Google Cloudの組織ポリシー constraints/iam.serviceAccountKeyExposureResponse という、
少しニッチながらも重要な機能について深掘りしました。

SAキーが漏洩した際に自動でキーを無効化する DISABLE_KEY が基本であり、ほとんどのケースで推奨される設定です。
一方でシステムの停止が許されない特殊な要件下では、通知のみを行う WAIT_FOR_ABUSE も選択肢となり得ます。
ただし、この設定を選ぶ場合はEssential Contactsで通知先を確実に設定し、迅速に対応できる体制を整えることが絶対条件です。

しかし、最も重要なメッセージはSAキーそのものの利用を減らしていくべきだということです。
Workload Identity Federationを活用し、SAキーの漏洩リスクそのものをなくすアーキテクチャを目指すことがインシデントを減らす肝になるでしょう。

この記事が皆さんのGoogle Cloud環境をより安全で、かつビジネス要件に柔軟に対応できるものにするための一助となれば幸いです。