セキュリティインシデント事例集
サービス別の典型事故と再発防止

シナリオの再現

運用エンジニアが Terraform で IAM Binding を追加する際、メールアドレスをタイプミス（admin@oursomain.com → 偶然外部実在ドメイン）。許可ドメイン制約がなかったため適用成功。

タイムライン

復旧手順

1. 封じ込め　break-glass Super Admin で対象プリンシパルの全 Binding 削除（gcloud projects remove-iam-policy-binding ... --member=user:bad@external.com を組織横断）
2. 影響評価　Cloud Asset Inventory で対象プリンシパルのアクセス履歴を全期間分検索（iamSearchAllIamPolicies）
3. 追跡　Aggregated Sink → BigQuery で当該プリンシパルの全 API 呼び出しをタイムライン化
4. 根本対策　組織ポリシー iam.allowedPolicyMemberDomains を Enforce、Terraform に policy_validator を入れる

予防策（再発防止）

• 組織ポリシー iam.allowedPolicyMemberDomains を すべての組織・フォルダで Enforce
• Terraform に policy-as-code（Open Policy Agent / Sentinel）で「許可ドメイン以外の binding を CI で reject」
• SetIamPolicy Audit Log を即時 SIEM 連携、Slack へリアルタイム通知
• Super Admin に対し SCC Event Threat Detection の異常検知（impossible travel）を Premium Tier で有効化

予防策

• HR システム → Cloud Identity の自動 SCIM プロビジョニング（OneLogin / Okta / Azure AD）
• 退職トリガで 即時アカウント suspend + 所有していた SA 鍵を全 revoke
• SA 鍵の保有者を Cloud Asset Inventory で定期棚卸し
• そもそも SA 鍵を使わない方針（Workload Identity Federation）

復旧

Super Admin（SSO 適用外）で SAML 設定に新証明書を差し込み復旧。Super Admin が SSO 例外でなかったらロックアウトしていた。

予防策

• IdP 証明書の有効期限を Cloud Monitoring カスタムメトリックで監視、30 / 14 / 7 日前に通知
• IdP の鍵を 2 つ同時並行（dual key）で運用し、無停止でローテーション
• Super Admin は SSO 適用外、緊急時の break-glass 手順書を四半期演習

タイムライン

復旧手順

1. 封じ込め　漏洩 SA を gcloud iam service-accounts disable で即時無効化
2. SA 鍵の全削除　該当 SA の鍵を全 list → 全 delete
3. SA トークンの即時失効　gcloud iam service-accounts keys revoke + 既発行トークンの待機期間が問題なら SA を削除
4. VM の一括削除　Cloud Asset Inventory で対象 SA 起動の VM を抽出 → 一括削除
5. 請求書対応　Google サポートにインシデント詳細を提示し課金調整を申請

予防策

• そもそも SA 鍵を発行しない：組織ポリシー iam.disableServiceAccountKeyCreation
• CI/CD は Workload Identity Federation（GitHub OIDC）
• GitHub Advanced Security の Secret Scanning + Push Protection
• クォータで VM の最大 vCPU 数を組織レベルで制限（Cloud Quotas）
• SCC Premium の VM Threat Detection を組織全体で有効化

復旧

1. WIF Provider を --attribute-condition で repository / ref を絞り更新
2. SA の workloadIdentityUser binding を principalSet://...attribute.repository/特定REPO に限定
3. STS Audit Log を全期間検索し、想定外の impersonate が無いか確認

予防策

• WIF Provider 作成は Terraform module 化し、attribute-condition を必須引数に
• SHA カスタムモジュールで「attribute-condition が空の Provider」を検出し SEV2 通知

復旧

Object Versioning が有効だったため、前バージョンに rollback。Versioning 無しなら不可逆だった。

予防策

• 組織ポリシー iam.automaticIamGrantsForDefaultServiceAccounts Deny
• 本番 GCS は Object Versioning + Object Lifecycle（古いバージョン 30 日保持）
• 本番リソースへのアクセスは 環境分離プロジェクト＋VPC SC でクロスプロジェクト egress 禁止

復旧

1. 境界を一時 Dry Run に変更（影響復旧優先）
2. Policy Denied Audit Log を抽出し、必要な Ingress / Egress Rule をリスト化
3. Ingress Rule（Cloud Build SA / Dataflow worker SA）を追加
4. 再度 Enforce に切替、回復確認

予防策

• VPC SC は 必ず Dry Run 4 週間で違反候補を洗い出してから Enforce
• 典型サービス（Cloud Build / Dataflow / Composer / Vertex AI Training）の Ingress Rule テンプレを保有
• 境界変更前後で dryRunPolicy を一時保持し、ロールバック容易に
• 変更は CI/CD の Change Window 内のみ、24/7 デプロイ禁止

予防策

• Ingress / Egress Rule は identities / operations を必ず限定
• 境界 YAML を peer review必須、CODEOWNERS に SOC を入れる
• VPC SC ポリシーは月次でレビュー（Policy Recommender + 手動）

予防策

• Hierarchical Firewall Policyで組織レベル「外部 SSH/RDP Deny」を強制（プロジェクト個別ルールで上書き不可）
• OS Login + 2FA を組織ポリシーで強制
• 運用上のアクセスは IAP TCP Forwarding 経由のみ
• SHA Finding OPEN_FIREWALL を SEV1 アラート（Cloud Functions で自動 close）

復旧

1. Cloud NAT に外部 IP を 3 つ追加
2. Dynamic port allocation 有効化
3. 該当外部 API への接続を PSC for Google APIsに切替（プライベート消費）

予防策

• port_usage_factor を 70% でアラート
• 大量 egress には PSC / 内部 LB / Cloud Run の sidecar pattern 検討
• NAT Logs + VPC Flow Logs で集約宛先を可視化

予防策

• WAF プリセットは必ず preview: true で 1 週間運用し、誤検知率を計測
• 正規クライアントの IP を allow ルール（優先度低）で先に許可
• 段階的に Sensitivity を上げる（1 → 2 → 3）

復旧

destroy は 30 日の grace period。gcloud kms keys versions restoreで即時復元成功。

予防策

• 本番鍵に IAM Deny ポリシーで cloudkms.cryptoKeyVersions.destroy を運用者から禁止
• Cloud Asset Inventory で「この鍵で暗号化されたリソース」を可視化（Terraform plan で表示）
• 鍵 destroy / restore を SEV1 アラート対象
• 誤って 30 日経過した場合に備え、過去データの cold backup（別鍵で暗号化）を別バケット保持

予防策

• 外部 KMS の SLA を 99.99% 以上で契約、二拠点冗長
• EKM via VPC（プライベート経路）でネットワーク要因を排除
• 外部 KMS 障害シミュレーションを四半期演習
• 非クリティカルなデータは EKM ではなく Cloud HSM（GCP 内）に分離

予防策

• CMEK 鍵作成 Terraform module に サービスエージェントへの自動 bindingを含める
• CMEK 対応サービスごとに必要な service agent をドキュメント化

予防策

• Discovery は scope を機微対象データセットに限定
• サンプリング率を低めに設定（最初は 0.1%）
• SDP の API 使用量 dlp.googleapis.com/quota/processed_bytes を Cloud Monitoring で日次監視
• 大規模スキャンは 事前見積もりを Pricing Calculator で実施

予防策

• SDP 用 KMS 鍵にも Deny ポリシーで destroy 禁止
• SDP の wrappedKey 参照を Cloud Asset Inventory で可視化
• SDP テンプレートと使用 KMS 鍵を マッピング表として運用ドキュメント化

復旧

1. allUsers / allAuthenticatedUsers の Binding を即時削除
2. GCS Access Log + Audit Data Access ログから外部 IP 一覧を抽出
3. 影響対象データの分類 → 規制（HIPAA / GDPR）に基づく報告手順
4. 72 時間以内の規制当局通知（GDPR の場合）

予防策

• 組織ポリシー iam.allowedPolicyMemberDomains に allUsers / allAuthenticatedUsers を含めない
• 組織ポリシー storage.publicAccessPrevention を Enforce（バケット公開を完全禁止）
• SHA Finding PUBLIC_BUCKET_ACL を SEV1、Cloud Functions で自動 close
• Uniform bucket-level access を強制（ACL を完全排除）

復旧

Object Versioning + Object Lifecycle で過去バージョン保持 → rollback。Bucket Lock があれば削除不可でさらに安全。

予防策

• 本番バケットは Object Versioning + 90 日保持
• WORM 要件があれば Bucket Lock + Retention
• SA 鍵運用禁止 + Workload Identity
• SHA BUCKET_POLICY_ONLY_DISABLED 検出

予防策

• Policy Tags の削除は Deny ポリシーで SOC グループ以外禁止
• Taxonomy の変更は Terraform 経由のみ、変更レビュー必須
• BigQuery Data Access ログを SIEM で監視、Policy Tag 列への大量 SELECT を異常検知

予防策

• 削除前に Data Catalog / INFORMATION_SCHEMAで依存関係を確認
• 機密 / 共有データセットは 削除前承認フロー（PAM Entitlement）

予防策

• Project / User 単位で Custom Quota（query usage per day）を設定
• BigQuery Editions（Capacity-based）で予算固定
• Cost Control チェック：SELECT * をブロック、partition フィルタ必須を Custom Rule で

復旧

Breakglass モードで一時デプロイ許可（監査ログ警告）→ Attestor 設定修正

予防策

• Attestor 鍵は dual keyでローテーション、古い鍵を 30 日保持
• Breakglass 使用は SEV2 アラート、SOC レビュー必須
• Cloud Build パイプラインで Attestor の health check

復旧

1. 該当 Pod を即時削除、Node を cordon → drain
2. Network Policy で該当 namespace の egress を一時遮断
3. Audit Log + auditd Log でアクティビティ追跡
4. イメージの SBOM を確認、CVE スキャンで侵入経路特定

予防策

• GKE Autopilot or Confidential GKE Nodes でホスト分離強化
• PodSecurity Admission で privileged Pod 禁止
• Network Policy をデフォルト Deny、必要な通信のみ許可
• Workload Identity でメタデータサーバ経由のトークン漏洩防止

予防策

• 本番アプリは 明示的なバージョン参照、デプロイで新バージョンに切替
• ローテーションは blue-greenパターン（古いバージョンと新バージョン同時有効期間あり）
• Pub/Sub 通知 → アプリの hot reload

復旧

1. 該当シークレットを即時ローテーション
2. Cloud Logging から該当ログを削除（exclusion filter + bucket purge）
3. SIEM 経由で外部にエクスポートされていれば連絡

予防策

• シークレットは 環境変数ではなく起動時 API 取得
• エラーログに環境変数を含めない（structured logging の sensitive field 除外）
• SDP Cloud Logging Sink 経由スキャンでシークレットパターン検出
• Secret Manager の annotationで「最終ローテーション日」を記録

予防策

• Data Access は 機微データセットのみ有効化
• Exclusion Filterでヘルスチェック / 内部 SA / 高頻度低リスク操作を除外
• Log Bucket の Retention を短く（30〜90 日）、長期は GCS Coldline へ Sink
• 取り込み量を Cloud Monitoring の logging.googleapis.com/byte_count で日次監視

予防策

• Sink writerIdentity の IAM Binding を Deny ポリシーで改変禁止
• Sink エラーメトリック logging.googleapis.com/exports/error_count を 1 分粒度で監視
• Sink を 2 重化（Pub/Sub + BigQuery 両方）してフェイルセーフ
• Log Bucket への保存も並行、原本は GCS Coldline に残す

予防策

• Severity 別に通知チャネル分離（Critical → PagerDuty / High → Slack / その他 → メール）
• SLO 設定：Critical は 1 時間、High は 4 時間、Medium は 24 時間で対応
• 未対応 Finding を BigQuery でレポート化、週次レビュー
• Cloud Functions で自動エンリッチメント（影響範囲・推奨アクション）

予防策

• Assured Workloads 配下では 許可サービスを Terraform validator で事前 check
• 違反操作モードは初期 Configurable で運用、警告から徐々に Enforce
• サンドボックスの非規制プロジェクトで先に検証

予防策

• Access Approval 有効化前に 24/7 承認体制を構築（時差を考慮）
• Pub/Sub Sink → PagerDuty 連動
• SLA 合意：承認 RTO 1 時間以内
• Pre-approved SA で限定シナリオは自動承認
• 定期演習：「承認しないとどうなるか」のシミュレーション