🔐 セキュリティ全領域
Deep Dive

1️⃣ Zero Trust の原則 — BeyondCorp 思想

Google が 2009 年の Operation Aurora 攻撃を契機に開発した「ネットワーク境界に依存しないセキュリティモデル」。VPN を撤廃し、認証・認可・コンテキストでアクセスを判断します。

Zero Trust の 5 原則

多層防御（Defense in Depth）— GCP マッピング

2️⃣ リソース階層と継承 — Organization → Folder → Project

4 階層モデル

Google Cloud のすべてのリソースは Organization（頂点） → Folder（任意） → Project → Resource の 4 階層に属します。IAM ポリシーと Org Policy はこの階層を下方向に継承します。

各レイヤーの役割

「アクセス制御と組織ポリシーの接続ポイントが提供され、階層全体に流れ下ります」 — Cloud Platform Resource Hierarchy

継承の合成ルール（Effective Policy）

各リソースに到達した有効ポリシー（Effective Policy）は、そのリソース直下のポリシーと祖先から継承されたポリシーの和集合です。子側で親の許可を取り消すことはできません（IAM Allow Policy の制約）。

Organization Policy（組織ポリシー）— ガードレール

IAM が「誰が」を制御するのに対し、Org Policy は「何ができるか」を制御するガードレール。階層に沿って Constraint を適用します。

🎯 試験での出題パターン

3️⃣ IAM 完全解剖 — Principal × Role × Resource

IAM の三要素モデル

3 種類のロール — 詳細比較

「予定義ロール活用で管理簡素化。本番環境では基本ロール使用回避」 — IAM overview

Custom Role の制約

IAM ポリシー評価フロー（Allow / Deny / PAB）

IAM Conditions — 属性ベースアクセス制御（ABAC）

CEL（Common Expression Language）でアクセス条件を記述します。「時間」「リソース名」「リクエスト元」などのコンテキストで動的に判断。

# 1. 営業時間のみ許可（JST 平日 9-18 時）
request.time.getHours("Asia/Tokyo") >= 9 &&
request.time.getHours("Asia/Tokyo") < 18 &&
request.time.getDayOfWeek("Asia/Tokyo") >= 1 &&
request.time.getDayOfWeek("Asia/Tokyo") <= 5

# 2. 特定バケットのオブジェクトのみ
resource.name.startsWith("projects/_/buckets/my-secure-bucket/")

# 3. 特定リソースタイプのみ
resource.type == "compute.googleapis.com/Instance"

# 4. 一時的アクセス（2026-06-30 まで）
request.time < timestamp("2026-06-30T23:59:59Z")

# 5. リソースタグでの判定
resource.matchTag("123456/env", "production")

Deny Policy（v2）

2022 年に GA。Allow ポリシーで広く許可した上で、特定の操作を確実にブロックする「最後の砦」として使います。

• 適用先：Organization / Folder / Project（リソース個別には未対応）
• 優先順位：Deny は Allow より常に優先（評価は階層全体で合成）
• 典型用途：iam.serviceAccounts.actAs を全員から剥奪して特権昇格を遮断

Principal Access Boundary（PAB）— 2024 年新機能

「このプリンシパルがアクセスできるリソース集合」を境界として定義。組織横断の侵害でも被害を限定できます。

🎯 試験での出題パターン

4️⃣ サービスアカウント運用 — SA Impersonation と WIF

サービスアカウント（SA）の基礎

Google Cloud では「人間ユーザー」と「ワークロード」を厳密に分離。ワークロードが API を呼ぶ際は SA を使います。SA は Principal でもあり Resource でもある二面性を持ちます。

SA 認証の 3 方式

SA Impersonation の 2 ロール

Workload Identity Federation の動作フロー

「service account keys are powerful credentials, and can present a security risk if they are not managed correctly. ... Workload Identity Federation eliminates the maintenance and security burden associated with service account keys.」 — Workload Identity Federation

WIF の典型ユースケース

🎯 試験での出題パターン

5️⃣ 暗号化の選択フロー — Google-managed / CMEK / HSM / EKM

GCP の暗号化原則

Google Cloud ではすべての保存データが既定で AES-256-GCM で暗号化されます。「鍵をどう管理するか」が選択肢の本質。

Cloud KMS の階層構造

CryptoKeyVersion のライフサイクル

鍵選定の決定ツリー

キーローテーション戦略

「サービスによっては CMEK が無効または利用不可の状態が長く続くと恒久的なデータ喪失を経験することがあります」 — CMEK

CMEK 対応の主要サービス（抜粋）

Cloud HSM の詳細

• 認証：FIPS 140-2 Level 3
• マネージド：Google が HSM クラスタ運用・スケール・パッチ管理
• 暗号化メッセージサイズ制限：8 KiB（Software 鍵は 64 KiB）。大きなデータには Envelope Encryption（KMS で DEK を暗号化、データ本体は DEK で暗号化）。
• 制限：マルチリージョンは未対応（リージョナル / シングル / マルチテナント）
• 料金：1 鍵 1 月あたり最低 $1〜（操作回数で課金）

Cloud EKM の詳細

• パートナー：Fortanix / Futurex / Thales（CipherTrust） / Virtru
• 接続方式：インターネット経由（全リージョン） / VPC 経由（リージョナルのみ）
• 外部鍵素材は GCP に保存されない（最大の特徴）
• 制限：手動鍵は自動ローテーション不可、非対称鍵のアルゴリズム変更不可
• リスク：外部 KMS 障害時は復号不可 → 可用性要件次第で Cloud HSM 併用検討

Confidential Computing（処理中の暗号化）

従来の「保存中 / 転送中」に加え、処理中（メモリ内）のデータも暗号化する技術。CPU 内の TEE（Trusted Execution Environment）で実行。

🎯 試験での出題パターン

6️⃣ VPC Service Controls 完全解剖

VPC SC の本質

IAM は「ID と権限」の境界、VPC SC は「API レベルのネットワーク境界」。両者を組み合わせた多層防御。VPC SC はデータ漏洩防止（Data Exfiltration Prevention）に特化。

「IAM が認証ベースのアクセス制御を提供する一方で、VPC Service Controls はコンテキストベースのペリメータセキュリティを実現」 — VPC Service Controls overview

Service Perimeter の動作

Ingress / Egress Rules の構造

Bridge Perimeter（双方向許可）よりもIngress / Egress Rules（細粒度許可）が推奨。以下の属性で許可条件を定義。

Dry-Run モード — 必須のワークフロー

VPC SC を本番適用する前に必ず Dry-Run で影響を測定。誤適用すると本番が完全停止します。

VPC SC 対象サービス

• 対象：Cloud Storage / BigQuery / Pub/Sub / Bigtable / Dataflow / Dataproc / Cloud Functions / Cloud Run / Vertex AI / Spanner / KMS 等の主要 API
• 非対象：Compute Engine API そのもの（一部）、Cloud Identity、Org Policy 等

Access Levels（Access Context Manager）

VPC SC で「誰が境界に入れるか」の条件をパラメータ化。

🎯 試験での出題パターン

7️⃣ セキュアリモートアクセス — IAP / CAA / Chrome Enterprise Premium

VPN 撤廃と Zero Trust アクセス

従来の VPN ベース「内側は安全」モデルから、「すべて検証」モデルへ。GCP のリモートアクセス手段を整理。

IAP の動作

HTTPS アプリの前段で Google が認証・認可を実施。アプリ側は「ヘッダーに署名付き ID」を受け取るだけ。

IAP TCP Forwarding（旧 IAP Tunnel）

外部 IP を持たない VM への SSH/RDP を、IAM 認証付きで提供。Bastion ホストを撤廃できる。

# IAM 設定
gcloud projects add-iam-policy-binding $PROJECT \
  --member=user:alice@example.com \
  --role=roles/iap.tunnelResourceAccessor

# SSH 接続（外部 IP 不要）
gcloud compute ssh my-vm --tunnel-through-iap

Context-Aware Access（CAA）

Access Context Manager の Access Levels と IAM / IAP を組み合わせ、コンテキストでアクセス可否を判断。

Chrome Enterprise Premium（旧 BeyondCorp Enterprise）

Chrome ブラウザに DLP・脅威保護・Zero Trust アクセスを統合したエンタープライズ向けプレミアムプラン。

• 脅威検知：リアルタイムでフィッシング・マルウェア・悪意ある URL を遮断
• DLP：コピペ・アップロード・印刷・スクリーンショットの粒度制御
• Zero Trust アクセス：Context-Aware Access を SaaS / オンプレに拡張
• シャドー IT 検知：未承認 SaaS の利用を可視化

🎯 試験での出題パターン

8️⃣ ソフトウェアサプライチェーン — Binary Authorization

SLSA フレームワーク

Supply chain Levels for Software Artifacts。サプライチェーン攻撃（SolarWinds 型）への対策レベル。

Binary Authorization の動作

主要概念

対応プラットフォーム

• GKE（GA）
• Cloud Run（GA）
• Cloud Service Mesh
• Google Distributed Cloud（オンプレ Anthos）

Artifact Registry のセキュリティ機能

• Vulnerability Scanning: コンテナ / Maven / npm パッケージの CVE 検出
• Remote Repositories: 外部レジストリ（Docker Hub 等）をキャッシュ、外部依存を制御
• Virtual Repositories: 複数リポジトリを 1 つに統合、検索順序を制御
• CMEK 対応: 顧客管理鍵で暗号化
• VPC SC 対応: Service Perimeter 内に閉じ込め可能

🎯 試験での出題パターン

9️⃣ Secure AI — Model Armor / DLP / Confidential VM

AI / LLM 時代の新リスク

生成 AI の普及で新たなリスクが顕在化。Prompt Injection / 機密データ漏洩 / モデル盗用 / ハルシネーションへの対策が必須。

Sensitive Data Protection（旧 Cloud DLP）詳細

200+ の組み込み InfoTypeでクレジットカード番号・SSN・電話番号・医療 ID など個人情報を検出。カスタム InfoType（辞書・正規表現・文脈）にも対応。

De-identification（脱識別）の主要手法

再識別リスク分析

• k-Anonymity: 同一の準識別子を共有するレコードが k 件以上
• l-Diversity: k-匿名グループ内で機密属性が l 通り以上
• k-Map / δ-Presence: 母集団に対する識別困難性

Model Armor（2024 年導入）

Vertex AI / 任意の LLM に対して、プロンプトとレスポンスを「セキュリティフィルタ」。

• Prompt Injection の検知
• Jailbreak 試行のブロック
• PII / 機密データの漏洩防止（DLP 連携）
• 有害コンテンツ（暴力・性的・差別）のフィルタ
• 悪意ある URL の検出

Confidential Space — マルチパーティ分析

複数組織のデータを「お互いに見せず」合算分析する仕組み。TEE + アテステーション。

🎯 試験での出題パターン

🔟 監査とログ — Cloud Audit Logs / Access Transparency

Cloud Audit Logs 4 種

「Data Access監査ログはサポートチームがアカウントの問題をトラブルシューティングするのに役立つ」 — Cloud Audit Logs

監査ログの保護

• ログエントリは不変（immutable）、改ざん不能
• _Required Log Bucket は削除・無効化不可（Admin / System Event の最終保存先）
• Log Sink で BigQuery / GCS / Pub/Sub へ転送して長期保管・SIEM 連携
• Aggregated Sink で Organization レベルから集約可能

Access Transparency / Access Approval

SIEM / SOAR 統合

• Log Router で Audit Logs を Pub/Sub に転送 → Splunk / Datadog / Chronicle
• Chronicle Security Operations: Google 純正の SIEM/SOAR、SCC Enterprise に統合
• Security Health Analytics の Finding を SCC で集約管理

ログ保持と長期保管

🎯 試験での出題パターン

1️⃣1️⃣ コンプライアンス — HIPAA / PCI / GDPR / SOC / FedRAMP

主要規制と GCP 対応マトリクス

Assured Workloads — コンプライアンス自動適用

規制要件に応じた Folder を作成し、内部のすべてのリソースに自動的に制約を適用。手動設定の漏れを防ぐ。

• FedRAMP Moderate / High（米連邦）
• IL2 / IL4 / IL5（米国防総省）
• HIPAA
• EU Sovereign Cloud（欧州データ主権）
• Israeli Landing Zone
• Canada Protected B

Data Residency / Data Sovereignty

「データを物理的にこのリージョン外に出さない」という要件。

HIPAA BAA 対象サービス（抜粋）

🎯 試験での出題パターン

1️⃣2️⃣ Security Command Center — 3 ティア比較

SCC の役割

Google Cloud のセキュリティポスチャ管理（CSPM）+ ワークロード保護（CWPP）+ SIEM/SOARを統合した中央コンソール。

3 ティアの機能比較

主要検知エンジン

SCC Enterprise の SOAR 機能

2024 年に統合された Chronicle Security Operations（旧 Siemplify）の SOAR を SCC に統合。脅威検知 → 自動対応のプレイブック化。

• Finding を自動でチケット化（Jira / ServiceNow）
• 感染した VM を自動で隔離（ファイアウォール変更）
• 漏洩したクレデンシャルを自動で無効化
• Chronicle UDM で複数年ログ検索

🎯 試験での出題パターン

1️⃣3️⃣ 試験頻出パターン — ケーススタディ別構成

ケース別の推奨セキュリティ構成

1️⃣4️⃣ アンチパターン集 — よくある設計ミス

セキュリティ設計の 10 大アンチパターン

1️⃣5️⃣ インシデント対応 — GCP での標準ステップ

セキュリティインシデント発生時の 7 ステップ

各ステップの GCP ツール

封じ込めの実コマンド例

# 1. 侵害された SA の全 Key を無効化（最優先）
gcloud iam service-accounts keys list --iam-account=compromised-sa@PROJECT.iam.gserviceaccount.com
gcloud iam service-accounts keys disable KEY_ID --iam-account=compromised-sa@PROJECT.iam.gserviceaccount.com

# 2. SA 自体を無効化
gcloud iam service-accounts disable compromised-sa@PROJECT.iam.gserviceaccount.com

# 3. 漏洩したアクセストークンを取り消し（OAuth）
gcloud auth revoke

# 4. 侵害 VM のネットワーク隔離（タグ変更で隔離 FW 適用）
gcloud compute instances add-tags VM --tags=quarantine --zone=ZONE
gcloud compute firewall-rules create deny-all-quarantine \
  --action=DENY --rules=all --target-tags=quarantine --priority=0

# 5. Snapshot 取得（証拠保全、PD は破壊しない）
gcloud compute disks snapshot DISK_NAME --snapshot-names=forensic-$(date +%s)

事前準備（インシデント対応プレイブック）

• SCC Finding を Slack / PagerDuty に Pub/Sub 経由で連携
• break-glass account（緊急時の Owner アカウント）を MFA + KMS-protected で保管
• Backup and DR で定期スナップショット、別 Project に Sink
• 四半期ごとにインシデント対応訓練（ChaosEngineering 的）
• Org Policy で resourcemanager.allowedExportDestinations 設定（ログの外部 Sink 先制御）

💡 必殺フレーズ集（試験当日用）

📌 試験中の判断フローチャート（暗記推奨）

🧭 次のステップ

参考公式ドキュメント

• IAM overview
• IAM Roles
• IAM Conditions
• Resource Hierarchy
• Organization Policy
• Cloud KMS
• CMEK
• Cloud EKM
• Cloud HSM
• VPC Service Controls
• Identity-Aware Proxy
• Workload Identity Federation
• Chrome Enterprise Premium
• Binary Authorization
• Sensitive Data Protection
• Cloud Audit Logs
• Security Command Center