Google Cloudなどのサービスアカウントキーが漏えいした疑いがある時の初動対応を解説。無効化と削除の違い、監査ログ、付与権限、利用先、ローテーション、影響範囲の確認方法を、情シス・開発者・SaaS管理者向けチェックリストと判断基準で整理します。
この記事の目次 14項目から選ぶ
冒頭要約
Google CloudなどのサービスアカウントキーがGitリポジトリ、CI/CDログ、共有ストレージ、チャット、端末から漏えいした疑いがある場合、ファイルを消すだけでは対応完了になりません。秘密鍵を取得した第三者は、人の追加認証を経ずにサービスアカウントとして操作できる可能性があります。
最初に、キーID、対象サービスアカウント、発見時刻、露出場所を記録し、キーを無効化します。続いて、そのサービスアカウントに付与されたIAMロール、アクセス可能なプロジェクトとデータ、監査ログ、課金やリソース作成、利用中のワークロードを確認します。
この記事では、情シス、開発者、SRE、SaaS・クラウド管理者、CSIRTが、検知から最初の15分、影響評価、復旧、再発防止へ進む順番を整理します。秘密鍵の動作確認や侵入再現は行わず、防御・確認・報告に必要な手順だけを扱います。
有効性を確かめる目的でも、露出した秘密鍵をローカル端末や検証環境で使用しないでください。正規のクラウド管理画面で状態を確認し、無効化と監査ログ調査を優先します。
サービスアカウントキーとは
Service Accountは、人ではなくアプリケーション、バッチ、CI/CD、SaaS連携などがクラウドAPIへアクセスするために使うIDです。Google Cloudのユーザー管理サービスアカウントキーでは、クラウド側が公開鍵を保持し、利用者側が秘密鍵を保管します。
サービスアカウントとキーは同じものではありません。
| 対象 | 役割 | 漏えい時の考え方 |
|---|---|---|
| サービスアカウント | ワークロードのID。IAMロールやアクセス権を持つ | 付与権限、利用目的、接続先、他のキーや認証経路も確認する |
| サービスアカウントキー | そのIDとして認証するための長期秘密鍵 | 対象キーを無効化し、依存先を切り替えた後に削除する |
| 短期認証情報 | キーなどを起点に発行される有効期限付きトークン | キー削除だけでは発行済みトークンが直ちに失効しない場合がある |
Google Cloud公式文書は、ユーザー管理キーを強力な認証情報として扱い、可能な限り別の認証方式を使うよう推奨しています。キーを使った操作はサービスアカウント名で記録されますが、共有された同じキーを誰が使ったかを確実に特定できない場合があります。そのため、キーの保管者と利用先を平時から把握することが重要です。
読者別の影響：誰が何を確認するか
| 読者 | 最初に確認すること | 主な責任範囲 |
|---|---|---|
| 開発者・SRE | キーID、利用中のアプリ、CI/CD、Secret Manager、デプロイ先 | キー無効化、依存先切り替え、サービス影響、利用ログの確認 |
| 情シス・クラウド管理者 | サービスアカウントのIAMロール、プロジェクト、組織ポリシー | 権限範囲の特定、封じ込め、監査ログ、再発防止設定 |
| SaaS管理者 | SaaS連携に保存されたキー、同期対象、連携先データ | 連携停止、ベンダー連絡、設定変更・データ操作の確認 |
| CSIRT・SOC | 検知経路、露出期間、証跡、異常操作、他の認証情報 | 優先度判断、調査範囲、関係者招集、経営・法務への報告 |
| 個人開発者 | 個人プロジェクト、課金、公開リポジトリ、ローカル保存先 | キー無効化、権限確認、請求・リソース・ログの確認 |
サービスアカウントが複数プロジェクトや外部SaaSから使われている場合、所有プロジェクトだけを見ても影響範囲を把握できません。IDに付与された権限と、実際にアクセスできるリソースを分けて確認します。
まず確認すること：最初の15分チェックリスト
1. 発見した事実を記録する
- 発見日時、発見者、通知元、チケット番号を記録する。
- 対象キーのキーID、対象サービスアカウント、所属プロジェクトを記録する。
- リポジトリ、ログ、共有ファイル、端末など、露出が疑われる場所を記録する。
- Public、社内限定、特定メンバー限定など、閲覧可能だった範囲を記録する。
- すでに実施した削除、権限変更、キー操作を時系列で残す。
秘密鍵そのものをチケットやチャットへ貼り直してはいけません。必要な識別にはキーID、サービスアカウント名、検知元の参照情報を使い、秘密値を複製しないようにします。
2. 対象キーを特定して無効化する
- 通知や管理画面で、対象がユーザー管理キーかを確認する。
- キーIDとサービスアカウントの組み合わせを照合する。
- 影響を受けるアプリ・ジョブの所有者へ連絡する。
- 権限があれば対象キーを無効化し、実施者と時刻を記録する。
- 無効化後に停止した処理と、継続している処理を記録する。
Google Cloudには、漏えいを検知したサービスアカウントキーを組織ポリシーに基づいて自動無効化する仕組みがあります。ただし、公式文書はすべての漏えい検知を保証していません。通知がない、または自動無効化されていないことを安全の根拠にはできません。
3. キーの利用先を洗い出す
- CI/CDのsecret、環境変数、ビルド設定。
- SaaS連携、データ同期、バックアップ、監視、ジョブ管理。
- VM、コンテナ、オンプレミスサーバー、開発端末。
- Secret Managerや組織で承認された保管庫。
- Gitリポジトリ、Wiki、チケット、チャット、共有ドライブ、メール添付。
- 退役済み環境、複製された設定、個人管理のスクリプト。
利用先が一つ見つかっても、それが唯一とは限りません。キーの作成者、所有チーム、構成管理、デプロイ履歴、SaaS設定を突き合わせます。
4. 権限と到達範囲を確認する
- サービスアカウントに直接付与されたIAMロール。
- グループ、フォルダ、組織、プロジェクト経由で継承する権限。
- 他のサービスアカウントを操作・偽装できる権限。
- ストレージ、データベース、シークレット、ログ、鍵、AI・分析基盤へのアクセス。
- VM、コンテナ、ネットワーク、IAM、請求に関する作成・変更・削除権限。
- 外部SaaSや別クラウドへ連携するための設定・認証情報へのアクセス。
優先度は「キーが漏れた」という事実だけでなく、IAMの権限範囲で決めます。閲覧専用と見えても、個人情報、ソースコード、バックアップ、別の秘密情報へ到達できれば影響は大きくなります。
5. 監査ログと周辺の変化を確認する
- 通常と異なる時刻、地域、送信元、ユーザーエージェントのAPI利用。
- IAMロール、サービスアカウント、キー、組織ポリシーの変更。
- 新しいVM、サービスアカウント、ストレージ、ネットワーク、ジョブの作成。
- データの大量読み取り、エクスポート、権限変更、ログ設定変更。
- 請求額、利用量、クォータ消費の急増。
- Security Command Center、SIEM、Secret Scanningなどの関連アラート。
Audit Logは重要ですが、「該当ログがない」だけで不正利用なしとは判断できません。Data Accessログが有効だったか、保存期間内か、対象サービスのログを見ているか、ログ閲覧権限があるかを確認します。
初動対応：やること、やらないこと、記録すること
やること
- 対象キーを無効化して、新たな認証を止める。
- サービス停止が発生した場合は、承認済みの代替認証または新しいキーへ依存先を切り替える。
- 旧キーがすべての依存先から外れたことを確認する。
- 不要と判断できた旧キーを削除する。
- 付与権限と監査ログを確認し、不審な操作を封じ込める。
- 他のキー、同じ保管場所のsecret、同じデプロイ経路も露出していないか確認する。
Google Cloud公式文書は、キーを削除する前に無効化し、不要であることを確認してから削除することを推奨しています。無効化は再有効化できるため、依存先が不明な初動で影響を観測しやすい一方、漏えいしたキーを恒久的に残す理由にはなりません。
やってはいけないこと
- 漏えいしたキーを使って、有効性や権限を試さない。
- 記録を残さずにキー、ログ、リポジトリ、アカウントを削除しない。
- サービス影響を恐れて、漏えいしたキーを無期限に再有効化しない。
- 露出したファイルを消しただけで、キーを失効せず対応を終えない。
- 監査ログが見つからないことを「利用されていない証明」にしない。
- サービスアカウント全体を不用意に削除し、無関係なワークロードや証跡を壊さない。
- 秘密鍵、顧客情報、内部URLを通常のチャットや公開Issueへ再掲しない。
記録すること
- 検知、無効化、切り替え、削除、復旧の各時刻と実施者。
- キーID、サービスアカウント、プロジェクト、所有者、利用目的。
- 露出場所、閲覧範囲、露出開始時刻の確認状況。
- IAMロール、アクセス可能な主要リソース、他IDへの操作権限。
- ログの確認期間、対象サービス、検索条件、結果、ログ設定の制約。
- 不審なリソース・操作、顧客やデータへの影響、未確認事項。
- エスカレーション先、判断者、次の確認期限、復旧条件。
証跡の取得方法と保管先は、インシデント時の証拠保全に沿って統一します。
無効化と削除の違い：どちらを先に行うか
| 操作 | 主な目的 | 注意点 |
|---|---|---|
| キーを無効化する | 対象キーによる新たな認証を止めつつ、必要なら戻せる状態にする | 依存先の停止を監視し、再有効化は限定的・一時的に判断する |
| キーを削除する | 対象キーを恒久的に認証へ使えなくする | 元に戻せない。先に依存先の切り替えと不要確認を行う |
| サービスアカウントを無効化する | 同じIDを使う複数の認証経路をまとめて止める | 全ワークロードへ影響する。発行済み短期認証情報への対応が必要な場合に検討する |
| サービスアカウントを削除する | ID自体を廃止する | IAMバインディングや復旧への影響が大きく、初動で安易に行わない |
Google Cloud公式文書によると、キーを削除しても、そのキーを基にすでに発行された短期認証情報が直ちに失効するとは限りません。重大な不正利用が進行中で、発行済み認証情報も含めて止める必要がある場合は、サービスアカウント全体の無効化を検討します。ただし影響が大きいため、CSIRT、クラウド管理者、サービス所有者で判断します。
影響確認：監査ログで見る観点
調査では、キーの露出時刻だけに絞りすぎないことが重要です。公開開始時刻が不明な場合は、キー作成日、最後に安全を確認できた時点、ログ保存期間を基準に範囲を決めます。
IAMと認証の変化
- キーの作成、無効化、再有効化、削除。
- サービスアカウントやIAMポリシーの変更。
- 新しいサービスアカウント、キー、ロール、グループ追加。
- アクセストークン、IDトークン、署名処理などの利用。
Service Account Credentials APIのトークン生成や署名操作は、種類によってData Accessログとして扱われます。初動時にログが有効でなかった場合は、過去にさかのぼって取得できないことがあります。「記録なし」と「実行なし」を分けて報告します。
リソースとデータの変化
- 計算リソース、ジョブ、関数、コンテナ、ストレージの新規作成。
- データベース、オブジェクト、ログ、バックアップの大量読み取り。
- ネットワーク、ファイアウォール、外部公開設定の変更。
- Secret Manager、KMS、CI/CD設定へのアクセス。
- ログの無効化、保存先変更、削除、権限変更。
コストと業務影響
- 通常と異なるクラウド利用量や請求額。
- 本番処理、同期、バックアップ、監視の停止。
- 顧客データや社内情報の参照・変更可能性。
- 外部SaaS、別クラウド、取引先環境への波及。
不審なリソースを見つけた場合、すぐ削除すると調査に必要な証跡を失うことがあります。通信や権限を隔離できるかを検討し、組織のインシデント対応手順に従います。
判断基準：危険度とエスカレーション条件
| 優先度 | 条件 | 推奨する判断 |
|---|---|---|
| 緊急 | 組織・フォルダ管理、IAM変更、サービスアカウント偽装、秘密情報アクセスなどの強い権限がある | 即時無効化、サービスアカウント全体の封じ込め検討、CSIRT・責任者招集 |
| 緊急 | 不審なIAM変更、データ取得、リソース作成、ログ変更、課金急増が確認された | 侵害の可能性として証跡保全、影響調査、経営・法務・プライバシー判断へ接続 |
| 高 | Publicリポジトリや不特定多数が閲覧できる場所へ露出した | 利用の有無を問わず失効し、権限・ログ・同時露出secretを拡大確認 |
| 高 | 利用先や所有者が不明、複数環境で共有、長期間ローテーションされていない | 無効化後の影響を監視し、全利用先を特定するまで未確認リスクとして管理 |
| 中 | 閲覧範囲が限定され、権限が小さく、不審な操作が確認されていない | キー更新、判断根拠の記録、関連ログと保管場所の確認を完了する |
| 低 | ダミーであること、無効であること、実リソースへ権限がないことを所有者が確認済み | 根拠を記録し、誤配置の原因と検知ルールを改善する |
次のいずれかに当てはまれば、担当者だけで閉じずにエスカレーションします。
- 顧客・従業員情報、契約上の機密、規制対象データへアクセスできる。
- 影響範囲、露出期間、利用先、付与権限のいずれかを確定できない。
- 不審なリソース、権限変更、データアクセス、課金、ログ欠損がある。
- 同じ場所から複数のキー、APIトークン、証明書、パスワードが見つかった。
- クラウド、SaaS、CI/CD、取引先環境をまたいで影響する。
- サービス継続と封じ込めの判断が衝突している。
記録テンプレート
インシデント番号:
発見日時・発見者:
検知元・露出場所:
閲覧可能だった範囲:
対象キーID:
対象サービスアカウント:
所属プロジェクト・組織:
キー作成日時・作成者:
サービスアカウントの所有者・用途:
利用中のアプリ・CI/CD・SaaS:
付与IAMロール・継承元:
アクセス可能な主要リソース・データ:
無効化日時・実施者:
代替認証への切り替え日時:
削除日時・実施者:
監査ログの確認期間・対象サービス:
不審な操作・リソース・課金:
ログ設定・保存期間による制約:
同時に露出した可能性がある認証情報:
保全した証跡と保管場所:
顧客・業務への影響:
報告先・判断者:
未確認事項・担当者・期限:
復旧条件・再発防止の担当者:「不正利用なし」ではなく、「どのログを、どの期間、どの条件で確認し、何が未確認か」を残します。後から追加情報が出た時に、判断を更新できる記録にします。
よくある誤解
「リポジトリから削除したので安全」
削除前に複製された秘密鍵は使える可能性があります。履歴やキャッシュからの除去と、クラウド側での無効化・削除は別の作業です。まず認証能力を止めます。
「キーを削除すれば、発行済みトークンも必ず失効する」
Google Cloud公式文書は、キー削除だけでは、そのキーを基に発行済みの短期認証情報を失効できない場合があると説明しています。進行中の不正利用が疑われる場合は、サービスアカウント全体の無効化を含めて判断します。
「監査ログに何もないので使われていない」
対象APIのData Accessログが無効、保存期間外、調査対象サービスが不足、閲覧権限が不足している可能性があります。ログ設定と調査範囲を確認し、分からない部分は未確認と記録します。
「ローテーションしたので再発防止も完了」
新しい長期キーを同じリポジトリや同じ共有場所へ置けば、同じ事故が繰り返されます。キーが本当に必要かを見直し、保管、配布、所有者、期限、検知、失効手順まで改善します。
「サービスアカウントは人ではないので、MFAだけ追加すればよい」
長期秘密鍵を使うサービスアカウント認証は、人の対話的なMFAとは仕組みが異なります。重要なのは、キーを持たない認証方式、短期認証情報、最小権限、利用条件、監査ログです。
再発防止：長期キーを持たない設計へ移行する
キーが本当に必要かを見直す
- Google Cloud上のワークロードは、実行環境へサービスアカウントを関連付ける方式を優先する。
- 外部クラウド、オンプレミス、GitHub Actions、GitLabなどはWorkload Identity Federationを検討する。
- 開発者のローカル作業に本番サービスアカウントキーを配布しない。
- 目的ごとに専用サービスアカウントを使い、複数用途で共有しない。
Workload Identity Federationは、外部のIDを使って短期認証情報を取得し、長期サービスアカウントキーの保管を避ける方式です。導入時は、信頼する発行元、リポジトリ、ブランチ、環境、属性条件を必要最小限に絞ります。
キーが残る場合の管理を強化する
- 所有者、用途、利用先、作成日、有効期限、最終確認日を台帳化する。
- 最小権限で専用ロールと対象リソースを限定する。
- キー作成・アップロードを組織ポリシーで原則禁止し、例外を期限付きで管理する。
- 定期ローテーションを自動化し、切り替えと失効をテストする。
- リポジトリ、CI/CD、共有ストレージでSecret Scanningを有効化する。
- 漏えい検知時の自動無効化、通知、担当者招集、復旧手順をテストする。
- 監査ログを必要な範囲で有効化し、保存期間とSIEM連携を確認する。
再発防止の完了条件は「新しいキーを発行した」ではなく、次回は漏えいしにくく、漏えいしても早く止め、影響を説明できる状態になったことです。
関連用語・関連ページ
| 次に確認すること | CyberLensのページ |
|---|---|
| サービスIDと権限を理解する | Service Account、IAM、Non-Human Identity |
| 長期キーを減らす | Workload Identity、Workload Identity Federation |
| 権限と監査を整理する | 最小権限、Audit Log、認証と認可の違い |
| シークレット漏えいを作業化する | GitHub secret leak対応チェックリスト、漏えい疑い初動テンプレート |
| AWSの長期キーを確認する | AWSアクセスキー漏えい時の初動対応 |
| 関連事故を確認する | GitHubリポジトリ誤公開時の初動対応、GitHub Secret Scanningアラート初動対応 |
| 初動と証跡保全を学ぶ | インシデントレスポンス入門、インシデント時の証拠保全 |
| 知識を確認する | セキュリティ用語クイズ |
公式情報・参考情報
- Google Cloud: Handle compromised Google Cloud credentials - 認証情報の失効・再発行、監査ログ、不審なリソース、サービス停止への配慮をまとめた公式ガイド。
- Google Cloud: Best practices for managing service account keys - キーの保管、ローテーション、漏えい検知時の自動無効化、組織ポリシーの公式ベストプラクティス。
- Google Cloud: Create and delete service account keys - 無効化して不要であることを確認してから削除する手順と、削除後の挙動。
- Google Cloud: Disable and enable service account keys - ユーザー管理キーを無効化・再有効化する公式手順。
- Google Cloud: Best practices for using service accounts securely - 専用サービスアカウント、最小権限、監査性、キーを避ける設計。
- Google Cloud: Service Account Credentials audit logging - トークン生成や署名処理の監査ログ種別とData Accessログの要件。
- Google Cloud: Workload Identity Federation - 外部ワークロードが長期サービスアカウントキーを持たずにGoogle Cloudへアクセスする公式方式。
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を組織のサイバーセキュリティリスク管理へ組み込む指針。
まとめ
サービスアカウントキーの漏えいを疑ったら、キーID、対象ID、発見時刻、露出場所を記録し、対象キーを無効化します。次に利用先を切り替え、不要と確認したキーを削除し、サービスアカウントのIAMロール、アクセス可能なデータ、監査ログ、課金、リソース変更を確認します。
ログに記録がないことや、露出ファイルを削除したことだけでは安全と断定できません。確認できた事実、ログ設定の制約、未確認事項を分け、権限とデータの重要性に応じてエスカレーションしてください。復旧後は、Workload Identity Federationなどの短期認証方式へ移行し、長期キーを持たない設計を再発防止の中心に置きます。
