セクション 3：
セキュリティとコンプライアンスの設計

試験全体の約 1/6 を占めるセキュリティ設計セクション。IAM 階層、暗号化（CMEK / HSM / EKM）、VPC Service Controls、Workload Identity Federation、Model Armor、HIPAA / PCI DSS / GDPR の規制対応まで体系的に学びます。多層防御と職務分離が設計の核です。

📊 出題 17.5% 🛡️ 多層防御 🔐 IAM + 暗号化 + VPC SC + WIF 📜 HIPAA / PCI DSS / GDPR / FedRAMP

📘 基礎 🔧 応用 🎯 要点と暗記

🔑 TL;DR — このセクションの要約セキュリティは多層防御：Org Policy（強制統制）→ IAM（最小権限）→ ネットワーク境界（VPC SC + Hierarchical FW）→ アプリ認証（IAP / Chrome Enterprise Premium）→ 暗号化（Google / CMEK / HSM / EKM）→ 監査（Audit Logs）。鍵は 「顧客管理 + GCP 外部」なら EKM、「FIPS 140-2 Level 3」なら HSM、それ以外は CMEK。Service Account キーは Workload Identity Federation で排除。AI/LLM は Model Armor + Sensitive Data Protection + Confidential VM。規制対応は Assured Workloads。

🎯 学習目標

🛡️ 多層防御（Defense in Depth）

セキュリティは 1 つの層で完結しない。複数のレイヤーで重ねるのが原則。試験では「最も安全な構成は？」と問われたら多層を組み合わせた選択肢が正解。

レイヤー 1: 組織ポリシー（Org Policy） ← 強制統制 ↓ レイヤー 2: IAM（誰が何にアクセスできるか） ↓ レイヤー 3: ネットワーク境界（VPC SC、ファイアウォール） ↓ レイヤー 4: アプリ認証（IAP、OAuth、Chrome Enterprise Premium） ↓ レイヤー 5: データ暗号化（保管時 / 転送時 / 使用時） ↓ レイヤー 6: 監査（Audit Logs / Access Transparency / SCC）

責任共有モデル（Shared Responsibility）

サービスの抽象度が上がるほど、Google が多くを担当します。顧客は常にデータと IAM に責任を持つのが試験の前提。

層	IaaS (GCE)	PaaS (Cloud Run)	SaaS (Workspace)
データ	顧客	顧客	顧客
アプリ	顧客	顧客	Google
ランタイム	顧客	Google	Google
OS	顧客	Google	Google
ハードウェア	Google	Google	Google
物理セキュリティ	Google	Google	Google

🏛️ IAM リソース階層図（Organization → Folder → Project → Resource）

GCP のリソースは 4 層の階層 で管理。上位のポリシーは下位に継承されます。

Organization（組織、最上位 / 1 つだけ） │ ├── Folder（フォルダ、複数階層可） │ │ │ ├── Folder（例: production） │ │ └── Project（例: prod-app-001） │ │ └── Resource（GCE VM, GCS Bucket, etc.） │ │ │ └── Folder（例: development） │ └── Project（例: dev-app-001） │ └── Project（直下、フォルダなし） [IAM 継承の挙動] 組織で roles/viewer 付与 ↓ 継承全 Folder / Project / Resource で viewer ↓ 追加 Folder で roles/editor 付与 ↓ そのフォルダ内で editor 追加 ↓ リソースで roles/storage.objectAdmin 付与 ↓ そのリソースでさらに権限拡大 ※ IAM は加算（denial がない限り権限が拡大） ※ Deny Policy は Allow より優先

各層の役割

Organization

最上位、組織全体のルート。組織全体の Org Policy、課金、ID 管理。1 組織につき 1 つだけ。

Folder

部門・環境（prod / dev / qa）単位。部門別の権限分離、環境別ポリシー。

Project

実際のワークロード単位。リソース・課金・API の境界。環境ごとに分離するのが基本。

Resource

個別の GCE / GCS / BigQuery 等。リソース単位の IAM 付与（最小権限）。

3.1 セキュリティ設計（IAM / 暗号化 / VPC SC / 認証）

IAM の構成要素

誰が（Member / Principal） → Google Account / Service Account / Group 何の権限を（Role） → roles/viewer, roles/editor, roles/owner ... どのリソースに（Resource） → Org / Folder / Project / Resource 持つか（Binding） Binding = (Member + Role + Resource) の組合せ

Member の種類

種類	例
Google Account	`user:alice@example.com`
Service Account	`serviceAccount:app@project.iam.gserviceaccount.com`
Google Group	`group:dev-team@example.com`
Cloud Identity / Workspace Domain	`domain:example.com`
Workforce Pool	Okta / Azure AD のユーザー
All Authenticated Users	`allAuthenticatedUsers`
All Users（要注意）	`allUsers`

ロールの 3 種類

種類	説明	推奨度
基本ロール（Basic）	Owner / Editor / Viewer。広範な権限	本番は避ける
事前定義ロール（Predefined）	サービス別の具体的ロール	推奨
カスタムロール（Custom）	必要な権限のみ束ねた独自ロール	細かい統制が必要な場合

Service Account

人間ではないアプリ・ワークロードのアイデンティティ。

[GCE VM] ─attached─→ [Service Account] ─has─→ [IAM Role] ↓ GCP API にアクセス

⚠️ 重要Service Account キー（JSON）は漏洩リスクが高い。Workload Identity / Workload Identity Federation での代替が推奨。

3 つの状態の暗号化

状態	例	デフォルト
At Rest（保管時）	GCS のオブジェクト、PD のディスク	AES-256 で自動暗号化
In Transit（転送時）	クライアント ↔ GCP、GCP 内部通信	TLS で自動暗号化
In Use（使用時）	メモリ内の処理中データ	Confidential VM（AMD SEV / Intel TDX）

Secret Manager

API キー、パスワード、証明書などのシークレットを安全に保管・配布。

暗号化: 自動で Google-managed、CMEK も使える
アクセス制御: IAM ロール（roles/secretmanager.secretAccessor）
バージョン管理: 旧バージョンを保持、ロールバック可能
監査ログ: Cloud Audit Logs に記録
ローテーション: スケジュール通知 + 自動ローテーション（Pub/Sub 連携）
Secret Manager Regional: リージョン内に閉じた保管（データ主権対応）

🔧 IAM 設計の 4 つの原則

① 最小権限

必要最小限の権限のみ付与。基本ロール（Owner/Editor/Viewer）は本番では避ける。

② 職務分離

1 人で全工程を完結できない設計。KMS 管理者と KMS 利用者を分けるなど。

③ グループベース付与

個人ではなく Google Group に付与。異動・退職時の管理が容易。

④ 継続的レビュー

Policy Analyzer / Recommender で定期見直し。

🔧 グループベース IAM の実装パターン

組織構造 ├── Google Group: gcp-admins@example.com → roles/owner（Project レベル） ├── Google Group: gcp-developers@example.com → roles/editor（dev Folder） ├── Google Group: gcp-data-scientists@example.com → roles/bigquery.user（特定 dataset） ├── Google Group: gcp-finance@example.com → roles/billing.viewer └── Google Group: gcp-auditors@example.com → roles/logging.viewer + roles/iam.securityReviewer 人事異動で個人を group に追加/削除するだけで権限が変わる

🔧 Conditional IAM（条件付き IAM）

権限付与に条件式（CEL: Common Expression Language）を追加できる。

例 1: 時刻制限（営業時間のみ）
  request.time.getHours("Asia/Tokyo") >= 9 &&
  request.time.getHours("Asia/Tokyo") < 18

例 2: リソース名による制限
  resource.name.startsWith("projects/prod-")

例 3: タイトル/タグによる制限
  resource.matchTag("env", "production")

例 4: IP 範囲制限
  inIpRange(origin.ip, "10.0.0.0/8")

🔧 IAM Deny Policy（拒否ポリシー、新機能）

通常の IAM は許可ベースですが、明示的に拒否することも可能。Deny は Allow より優先。

🔧 必ず覚えるロール

用途	ロール
Bucket 内オブジェクトのみ読込	`roles/storage.objectViewer`
BigQuery でクエリ実行	`roles/bigquery.jobUser` + `roles/bigquery.dataViewer`
Cloud SQL の DB 接続	`roles/cloudsql.client`
Secret 取得	`roles/secretmanager.secretAccessor`
KMS 鍵で暗号化 / 復号	`roles/cloudkms.cryptoKeyEncrypterDecrypter`
IAM 確認のみ	`roles/iam.securityReviewer`
ログ閲覧	`roles/logging.viewer`
SA 偽装	`roles/iam.serviceAccountTokenCreator`

🔧 職務分離（Separation of Duties）の典型パターン

役割	権限の範囲
Developer	コード書く、PR、dev デプロイ：`roles/editor`（dev のみ）
DevOps Engineer	本番デプロイ、インフラ：`roles/compute.admin`（prod）
Security Engineer	IAM 設計、Org Policy：`roles/iam.securityAdmin`
Network Engineer	VPC、Interconnect：`roles/compute.networkAdmin`
Audit / Compliance	ログ閲覧のみ：`roles/logging.viewer` + `roles/iam.securityReviewer`
Billing Admin	課金管理のみ：`roles/billing.admin`
Cloud KMS Admin	鍵作成・管理：`roles/cloudkms.admin`
Cloud KMS User	暗号化 / 復号のみ：`roles/cloudkms.cryptoKeyEncrypterDecrypter`

💡 KMS の職務分離「KMS Admin」と「Application」を分離することで、アプリ管理者が誤って鍵を削除する事故や、KMS 管理者がアプリデータを覗き見することを防ぐ。

🎯 IAM 即答

用途	ロール
Bucket オブジェクト読	`roles/storage.objectViewer`
BigQuery クエリ	`roles/bigquery.jobUser` + `roles/bigquery.dataViewer`
Cloud SQL 接続	`roles/cloudsql.client`
Secret 取得	`roles/secretmanager.secretAccessor`
KMS 暗号化 / 復号	`roles/cloudkms.cryptoKeyEncrypterDecrypter`
IAM 確認のみ	`roles/iam.securityReviewer`
ログ閲覧	`roles/logging.viewer`
SA 偽装	`roles/iam.serviceAccountTokenCreator`

🔐 暗号化キーの選択フロー

試験で最頻出のトピック。「FIPS 140-2 Level 3」→ HSM、「鍵を GCP 外に保持」→ EKM、それ以外は CMEK で十分、と覚えます。

鍵管理の要件は？顧客側で鍵を完全管理したい？ YES ↓ 鍵を GCP 外部に置きたい？ YES → Cloud EKM（外部 HSM 連携） NO ↓ FIPS 140-2 Level 3 が必要？ YES → Cloud HSM（または Cloud KMS with HSM backend） NO → Cloud KMS（CMEK、ソフトウェア鍵） NO → Google-managed encryption keys（デフォルト）

5 つの暗号化方式の比較

方式	鍵の所有	鍵の場所	用途
Google-managed（デフォルト）	Google	Google	一般
CMEK (Cloud KMS)	顧客	GCP 内 KMS	規制対応、監査
Cloud HSM	顧客	GCP 内 HSM	FIPS 140-2 Level 3 要件
CMEK with HSM	顧客	GCP 内 HSM	同上、Cloud KMS 経由
CSEK（限定機能）	顧客	顧客（API 呼出時送信）	レガシー、機能限定
Cloud EKM	顧客	顧客側 HSM（オンプレ / サードパーティ）	完全外部鍵管理

Cloud KMS の構造

[Key Ring] ─contains─→ [Key] ─version─→ [Key Version (v1, v2, ...)] ↑ リージョン or グローバルローテーション: 自動（推奨 90 日）無効化 → 24 時間〜30 日後に破壊（復元不可）

CMEK 対応サービスの整理

サービス	CMEK	CSEK	EKM
Cloud Storage	✓	✓	✓
Cloud SQL	✓	—	✓
BigQuery	✓	—	✓
Compute Engine (PD)	✓	✓	✓
GKE (etcd, PD)	✓	—	✓
Spanner	✓	—	—
Pub/Sub	✓	—	—
Secret Manager	✓	—	—
Dataflow	✓	—	—
Vertex AI	✓	—	—

CMEK で得られる主な利点

鍵の無効化により全データを瞬時にロック（消去なしで「クリプトシュレディング」）
鍵アクセスログ取得
規制要件（鍵管理の証跡）
鍵の場所制御（リージョン指定）

⚠️ 破壊期間に注意鍵の破壊後は復元不可 = 暗号化済みデータが復号不能になる。設計時に破壊期間の猶予を慎重に検討。

🛡️ VPC Service Controls 境界設計

「データの境界（Service Perimeter）」を作る機能。リソース内のデータが外部にコピーされるのを防ぐ。IAM の補完（独立した境界） として機能。

┌─── VPC SC Perimeter ───────────────────────────┐ │ │ │ ┌──── Project A ────┐ ┌──── Project B ────┐ │ │ │ GCS / BigQuery │ │ Pub/Sub / KMS │ │ │ └───────────────────┘ └───────────────────┘ │ │ │ │ Restricted Services: GCS, BigQuery, Pub/Sub │ │ VPC Accessible Services: 上記 │ │ Access Levels: 例外許可ルール（IP / Device等） │ │ Ingress / Egress Rules: 細粒度ルール │ │ │ └──────────────────────────────────────────────────┘ → Perimeter 外から内部へのアクセス: 拒否 → Perimeter 内から外部へのコピー: 拒否（exfiltration 防止） → Perimeter 内通信: 許可 [サンプル境界設計] 本番境界 (prod-perimeter) ├── prod-app-project (GCE / GKE) ├── prod-data-project (BigQuery / GCS) └── prod-ml-project (Vertex AI) ↑ Access Level: corp 社内 IP のみ Ingress Rules: BigQuery への BI ツール接続を許可 Egress Rules: 外部 GCS への書き出しを禁止

主な防御対象

IAM が漏洩しても、データを外に持ち出せない（IAM とは独立の境界）
不正なアプリが盗もうとしても境界外にデータを送れない
規制対応（HIPAA、PCI DSS、GDPR）で必須化されるケース多数

Ingress / Egress Rules（最新・推奨）

Egress Rules: 境界内から外へ
  例: 「BigQuery service account から 特定の Project への BQ クエリは許可」

Ingress Rules: 境界外から内へ
  例: 「特定の IP / SA から GCS bucket への read のみ許可」

Access Context Manager との組合せ

[Access Level] IP 範囲: 10.0.0.0/8 デバイスポリシー: 暗号化 ON + 最新 OS 地理: Japan 時刻: 9:00 - 18:00 JST ↓ [VPC SC Perimeter にアクセス]

Dry-Run モード（必修）

本番化前に影響をシミュレートできる。違反ログだけ記録、実際のブロックはしない。

⚠️ 試験頻出「VPC SC を導入したい、業務影響を確認したい」→ Dry-Run モード

🔑 Workload Identity Federation のフロー

外部のワークロード（AWS、Azure、GitHub Actions、Kubernetes 等）が、Service Account キーなしで GCP API にアクセスできる仕組み。

[GitHub Actions / AWS Lambda / Azure Workload] ↓ OIDC/SAML トークン提示 [Workload Identity Pool] ↓ 属性マッピング + 認証 [Service Account に Impersonate] ↓ 短期トークン取得 [GCP API アクセス] → SA キー不要、漏洩リスクゼロ → 短期トークンで自動失効

旧方式 vs WIF

旧方式（SA キー）	Workload Identity Federation
JSON キーをコピー	キー不要
漏洩リスク	短期トークン（漏洩しても短期失効）
ローテーション必要	自動
監査困難	監査ログに連携元の ID 記録

類似機能の使い分け

用途	機能
GitHub Actions → GCP デプロイ	Workload Identity Federation
AWS Lambda → GCS Read	Workload Identity Federation
GKE Pod → GCP API	Workload Identity for GKE
一時的に特権を借りる	Service Account Impersonation
外部 IdP（Okta / Azure AD）で人間がログイン	Workforce Identity Federation

リモートアクセス手法の選定マトリクス

要件	推奨	理由
内部 Web アプリ公開（Google ログイン）	IAP for HTTP(S)	VPN 不要、簡単
内部 VM に SSH（VPN なし）	IAP TCP Forwarding	`gcloud compute ssh --tunnel-through-iap`
委託先 / 取引先のアクセス	Workforce Identity Federation + IAP	外部 IdP 経由
BYOD でアクセス（デバイス検証必須）	Chrome Enterprise Premium	デバイスポスチャ + コンテキスト
AWS Lambda → GCS Read	Workload Identity Federation	SA キー不要
GitHub Actions → GCP デプロイ	Workload Identity Federation	SA キー不要
Kubernetes Pod → GCP API	Workload Identity for GKE	SA キー不要
一時的に特権を借りる	Service Account Impersonation	短期トークン
オンプレ ↔ GCP 全社接続	Cloud Interconnect / HA VPN	大規模 / 暗号化必要

Chrome Enterprise Premium（旧 BeyondCorp Enterprise）

[ユーザー（社内 / BYOD / 外部）] ↓ Chrome / Endpoint Verification [Chrome Enterprise Premium] ├── デバイスポスチャ評価（OS バージョン、暗号化など） ├── ユーザー認証 ├── コンテキストアウェアアクセス（場所 / 時間 / デバイス） └── DLP（データ流出防止） ↓ 条件達成 [内部アプリ / SaaS]

📋 Organization Policy 制約一覧

組織全体に強制可能な制約。Folder / Project へ強制継承。

制約名	効果
`constraints/iam.allowedPolicyMemberDomains`	特定ドメインの ID のみ IAM 付与可（外部ユーザー禁止）
`constraints/compute.requireOsLogin`	SSH キーではなく OS Login を強制
`constraints/compute.vmExternalIpAccess`	VM の外部 IP 付与を制限 / 禁止
`constraints/storage.uniformBucketLevelAccess`	GCS の Uniform IAM 強制（ACL 禁止）
`constraints/storage.publicAccessPrevention`	GCS 公開禁止
`constraints/sql.restrictPublicIp`	Cloud SQL のパブリック IP 禁止
`constraints/gcp.resourceLocations`	リソース作成可能リージョンを制限（データ主権）
`constraints/iam.disableServiceAccountKeyCreation`	SA キー作成禁止
`constraints/iam.disableServiceAccountCreation`	SA 作成禁止
`constraints/serviceuser.services`	有効化できる API を制限
`constraints/compute.trustedImageProjects`	信頼するイメージプロジェクトを制限
`constraints/iam.workloadIdentityPoolProviders`	WIF プロバイダ制限

Hierarchical Firewall Policy

Organization Policy ├── allow: corp_network → all ├── deny: 0.0.0.0/0 → SSH (規制違反防止) ↓ 継承 Folder Policy (prod) └── deny: external → internal_db ↓ 継承 Project の VPC Firewall（規則を追加できるが、上位の deny を覆せない）

📦 ソフトウェアサプライチェーン保護

CI/CD パイプライン保護の全体像

[Cloud Source Repo / GitHub] ↓ Push [Cloud Build] ├── Vulnerability Scanning（Artifact Analysis） ├── SBOM 生成（Software Bill of Materials） ├── 署名 attestation 生成（in-toto / Sigstore） └── SLSA Level 3 適合ビルド ↓ [Artifact Registry]（イメージ保管 + 継続的スキャン） ↓ [Binary Authorization] ├── 署名検証（誰が作ったか） ├── 脆弱性スコア検証 ├── プロビナンス検証（どう作られたか） └── 適合イメージのみデプロイ許可 ↓ [GKE / Cloud Run]

SLSA レベル

レベル	実装要件
SLSA 1	Cloud Build + provenance 生成
SLSA 2	+ GitHub 認証 + ホストビルド
SLSA 3	+ 隔離ビルド環境 + 改竄不可 attestation
SLSA 4	+ 2 人レビュー + 再現可能ビルド

Binary Authorization のポリシー設計

Project レベル: デフォルトポリシー（全て要署名）
  ↓
Cluster レベル: クラスタごとに上書き
  例: dev クラスタ → 緊急用に Break-Glass 許可
      prod クラスタ → 必ず特定の attestor が署名したもののみ

🔑 サプライチェーン保護キーワード「コンテナイメージの信頼性」「コンテナの安全な配布」 → Binary Authorization + SLSA + Artifact Registry

🤖 Secure AI（最新・必須）

LLM や AI モデル特有のリスクへの対策。3 つのリスクと対策サービスを暗記。

入力（プロンプト）保護

Model Armor

Prompt Injection 検出
Jailbreak 検出
機密 / PII 検出
出力フィルタリング

データ保護

Sensitive Data Protection（旧 Cloud DLP）

PII 検出（メール、SSN、クレカ、医療 ID）
マスキング / トークン化
構造化・非構造化データ両対応

モデル保護

Confidential VM + CMEK + VPC SC

Confidential VM（メモリ暗号化）
CMEK でモデル重み暗号化
VPC SC でモデルエクスポート防止
IAM で推論アクセス制限

Model Armor の利用パターン

[ユーザー入力] ↓ [Model Armor] ├── Prompt Injection 検出 ├── Jailbreak 試行検出 ├── 不適切コンテンツフィルタ ├── PII / 機密データ検出 └── ジオロケ・規制ベースのブロック ↓ 安全な入力のみ通過 [LLM（Gemini, Llama, Claude など）] ↓ [Model Armor で出力チェック] ↓ [ユーザー]

Sensitive Data Protection の InfoType（主な例）

データタイプ	InfoType の例
個人識別	`PERSON_NAME`, `EMAIL_ADDRESS`, `PHONE_NUMBER`
米国 PII	`US_SOCIAL_SECURITY_NUMBER`, `US_DRIVERS_LICENSE_NUMBER`
金融	`CREDIT_CARD_NUMBER`, `IBAN_CODE`
医療	`US_HEALTHCARE_NPI`, `MEDICAL_RECORD_NUMBER`
国別 ID	`JAPAN_INDIVIDUAL_NUMBER`（マイナンバー）
認証情報	`GCP_CREDENTIALS`, `AWS_CREDENTIALS`, `JSON_WEB_TOKEN`

モデル盗難対策

[Vertex AI Model Registry] ↓ [CMEK で暗号化された Model] ↓ [VPC SC 内のみアクセス可能] ↓ [IAM で利用者限定] ↓ [Confidential VM 上で推論]

3.2 コンプライアンスの設計

監査ログ（Cloud Audit Logs）4 種類

ログ種類	内容	デフォルト	課金
Admin Activity	管理操作（IAM 変更、VM 作成など）	常時有効	無料
Data Access	データ読み書き（GCS read など）	デフォルト無効（GCS 例外）	有料
System Event	システム発生イベント（メンテ等）	常時有効	無料
Policy Denied	ポリシーで拒否されたアクセス	常時有効	無料

Access Transparency と Access Approval

機能	内容
Access Transparency	Google 内部担当者の顧客データアクセスを記録（誰が、なぜ）
Access Approval	Google 担当者のアクセスに顧客の事前承認を必須化

規制対応（HIPAA / FedRAMP）では両方を有効化するのが一般的。

データ主権（Data Sovereignty / Data Residency）

「データが特定の国・地域から外に出ない」要件。

リージョン指定でリソース作成（例: europe-west1）
Org Policy で使用可能リージョンを制限
VPC Service Controls で境界外への移動を防止
Sovereign Controls / Assured Workloads で GCP 担当者のアクセスも制限

🔧 ログ保管設計

種類	保管先	保管期間（推奨）
Admin Activity	Logging（400 日デフォルト）	規制対応で BigQuery / GCS Archive へエクスポート
Data Access	Logging（30 日デフォルト）	必要なら長期保管へエクスポート（コスト注意）
System Event	Logging（400 日）	エクスポート任意
Policy Denied	Logging（30 日）	セキュリティ調査用

🔧 ログエクスポートの構成（Log Sink）

[Cloud Logging] ↓ Log Sink ├── BigQuery（分析・SQL クエリ） ├── Cloud Storage（長期保管、Archive クラス） ├── Pub/Sub（リアルタイム連携） └── 別 Project の Logging（集中管理）

🔧 Aggregated Sink（組織横断ログ集約）

[Organization Logging] ↓ Aggregated Sink [Centralized Project (audit-prod)] └── BigQuery dataset + GCS bucket ↓ アクセス [SIEM / Chronicle Security Operations]

🔧 監査ログのフィルタリング例

# 重要操作のフィルタ例（CEL）
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName=~"google.iam.admin.v1.IAM.*"
severity>=ERROR
resource.type="gcs_bucket" AND
  protoPayload.methodName="storage.objects.delete"

🎯 監査ログ即答

Admin Activity: デフォルト有効、無料
Data Access: デフォルト無効（GCS 例外）、有料
System Event: デフォルト有効、無料
Policy Denied: デフォルト有効、無料
Aggregated Sink: 組織横断ログ集約
Access Transparency: Google 担当者のアクセス記録
Access Approval: Google 担当者アクセスに事前承認

📜 規制マッピング表（HIPAA / PCI DSS / GDPR / SOC 2 / FedRAMP）

規制	対象データ	必須サービス・対応
HIPAA	医療情報（米国）	BAA 締結 + 対象サービス + Audit Logs + Assured Workloads + CMEK
PCI DSS	クレジットカード情報	Sensitive Data Protection + Cloud HSM / CMEK + VPC SC + Assured Workloads
GDPR	EU 個人データ	Data Residency（リージョン制限） + Org Policy + Audit Logs + DPA
SOC 2	サービス組織の管理	Compliance Reports Manager で SOC 2 レポート取得
FedRAMP	米国連邦政府	Assured Workloads (FedRAMP High / Moderate) + Cloud HSM + Access Transparency / Approval
COPPA	児童プライバシー（米国）	アクセス管理 + 同意管理
ITAR / EAR	米国輸出規制	Assured Workloads (US Sovereign)

HIPAA 対応の詳細（米国医療）

要件	実装
BAA（Business Associate Agreement）締結	Google Cloud と契約
対象サービス利用	HIPAA Eligible Services のみ
暗号化	CMEK 推奨
監査ログ	Admin / Data Access 両方有効化
アクセス管理	IAM 最小権限 + VPC SC
物理セキュリティ	Google 責任
隔離環境（オプション）	Assured Workloads (HIPAA)

PCI DSS 対応の詳細（クレジットカード）

要件	実装
カード番号保護	Sensitive Data Protection でマスキング、トークン化
暗号化	TLS + CMEK
鍵管理	Cloud HSM または Cloud KMS
ネットワーク隔離	VPC + VPC SC + Hierarchical Firewall
監査ログ	Cloud Audit Logs（全種類）
隔離環境	Assured Workloads (PCI DSS)
脆弱性管理	Container Analysis + Security Command Center

GDPR 対応の詳細（EU 個人データ）

要件	実装
データ主権	リージョン制限（EU リージョン）
Org Policy	`constraints/gcp.resourceLocations` で EU 圏のみ
削除権（Right to be Forgotten）	GCS Lifecycle + BigQuery DELETE
データ転送（EU 外）	SCC（Standard Contractual Clauses）+ Audit
監査	Cloud Audit Logs + Access Transparency
データ処理記録	DPA（Data Processing Agreement）

🏢 Assured Workloads — 規制対応の隔離環境

規制対応のための隔離環境を自動構築するサービス。Folder + Project を規制要件に合わせて作成し、Org Policy を強制適用します。

[Assured Workloads] ↓ Folder + Project を規制要件に合わせて作成 ├── リージョン制限（データ主権） ├── サポート要員のロケーション制限 ├── 暗号化要件（CMEK 強制） ├── 監査ログ強制有効化 └── 規制対応サービスのみ許可

対応規制一覧

医療

HIPAA

決済

PCI DSS

米国連邦

FedRAMP High / Moderate
IL2 / IL4 / IL5（米国国防）
ITAR

国別

Canadian Protected B
EU Sovereign Controls

🔑 Assured Workloads キーワード「HIPAA」「PCI DSS」「FedRAMP」「規制隔離環境」「データ主権 + サポート要員ロケーション制限」 → Assured Workloads

🛡️ Security Command Center (SCC)

GCP のセキュリティ統合ダッシュボード。脆弱性・設定不備・脅威を一元管理。

SCC の主要機能

機能	内容
Security Health Analytics	設定不備の自動検出（公開バケット、弱い IAM 等）
Event Threat Detection	脅威検出（マルウェア、不審アクセス）
Container Threat Detection	GKE 内の脅威（暗号通貨マイナー等）
VM Threat Detection	GCE VM 内の脅威
Web Security Scanner	App Engine / GCE 上の Web アプリの脆弱性
Sensitive Data Protection 連携	データ内 PII 検出
Chronicle Security Operations 連携	SIEM / SOAR 統合

SCC の 3 ティア

Standard

Security Health Analytics（基本のみ）

Premium

全機能 + Threat Detection + 各種連携

Enterprise（最新）

Chronicle + Mandiant 統合、フルマネージド SecOps

⚖️ 設計判断のトレードオフ

ケース 1：CMEK vs Cloud HSM vs EKM

要件: 「規制対応で顧客が鍵を完全に管理」

選択肢	コスト	運用負担	規制適合
A: CMEK (Cloud KMS)	中	低	HIPAA OK、PCI DSS OK
B: Cloud HSM	高	中	FIPS 140-2 Level 3 OK
C: Cloud EKM	最高	高	鍵を完全外部保持要件

判断軸: 「FIPS 140-2 Level 3」→ Cloud HSM 一択。「鍵を GCP 外で保持」→ Cloud EKM 一択。通常の規制対応 → CMEK で十分。

ケース 2：IAP vs Chrome Enterprise Premium vs VPN

要件: 「リモートワーカーから内部 Web アプリへのアクセス」

選択肢	用途	デバイス制御
A: HA VPN	全 IP 範囲をトンネル経由	デバイス制御なし
B: IAP	個別アプリへの認証付きアクセス	デバイス制御なし
C: Chrome Enterprise Premium	IAP + デバイスポスチャ	デバイス制御 + コンテキスト

判断軸: 「BYOD」「デバイス検証」→ Chrome Enterprise Premium。個別アプリへのアクセスだけ → IAP。全社レベルの IP 接続 → HA VPN。

ケース 3：VPC SC vs IAM のみ

要件: 「規制データの境界保護」

A: IAM のみ（IAM が漏洩したら全データ漏洩）
B: IAM + VPC SC（IAM 漏洩しても境界外には出ない）✅

正解は常に B。VPC SC は IAM の補完（独立した境界）。

ケース 4：Sensitive Data Protection vs Confidential VM

要件: 「処理中の機密データを守る」

観点	Sensitive Data Protection	Confidential VM
対象	データの内容（PII 検出・マスキング）	データの処理場所（メモリ暗号化）
用途	データ前処理・匿名化	処理中の盗み見防止

両方併用 が理想（PII を匿名化したデータを Confidential VM で処理）。

🔄 サービスリネーム最新一覧

旧名	新名
Cloud DLP	Sensitive Data Protection
BeyondCorp Enterprise	Chrome Enterprise Premium
Anthos（一部）	GKE Enterprise
Stratozone	Migration Center

💡 設計判断の必殺フレーズ

状況	即答
「FIPS 140-2 Level 3」	Cloud HSM
「鍵を GCP 外に保持」	Cloud EKM
「Service Account キー漏洩を防ぐ」	Workload Identity Federation
「データを境界外に出さない」	VPC Service Controls
「VPN なし内部 Web」	IAP for HTTP(S)
「VPN なし SSH」	IAP TCP Forwarding
「BYOD ゼロトラスト」	Chrome Enterprise Premium
「HIPAA / PCI DSS 隔離環境」	Assured Workloads
「全社一律 FW」	Hierarchical Firewall Policy
「リソース作成リージョン制限」	Org Policy `gcp.resourceLocations`
「PII 検出・マスキング」	Sensitive Data Protection
「Prompt Injection 防御」	Model Armor
「コンテナイメージ信頼性」	Binary Authorization + SLSA
「組織横断ログ集約」	Aggregated Sink
「Google 担当者アクセス記録」	Access Transparency
「Google 担当者アクセスに事前承認」	Access Approval
「SOC 2 レポート取得」	Compliance Reports Manager
「セキュリティ統合ダッシュボード」	Security Command Center
「メモリ暗号化（規制）」	Confidential VM

試験で問われる「典型 4 問」

問 1: 規制対応の環境設計

Assured Workloads + CMEK / HSM + VPC SC + Audit Logs

問 2: 外部から GCP へのキーなしアクセス

Workload Identity Federation

問 3: コンテナの信頼性デプロイ

Binary Authorization + SLSA + Artifact Registry

問 4: AI / LLM のセキュリティ

Model Armor + Sensitive Data Protection + Confidential VM

ケーススタディの定番セキュリティ解

ケース	セキュリティ要点
EHR Healthcare（医療）	HIPAA + Assured Workloads + CMEK + VPC SC + Cloud Identity + GCDS + Audit Logs
Cymbal Retail（小売）	PCI DSS + Sensitive Data Protection + CMEK + IAP
Altostrat Media（メディア）	Model Armor + Sensitive Data Protection + Binary Authorization
KnightMotives Automotive（製造）	Data Residency + Assured Workloads + VPC SC + Hierarchical FW

📌 セキュリティ設計の判断フロー

1. 規制要件をヒアリング（HIPAA / PCI DSS / GDPR ...） ↓ 2. データ主権要件を整理（どの国・地域に保管？） ↓ 3. リソース階層を設計（Org → Folder → Project） ↓ 4. IAM 設計（最小権限、グループベース、職務分離） ↓ 5. 暗号化方式を選択（Google-managed / CMEK / Cloud HSM / EKM） ↓ 6. ネットワーク境界を設計（VPC SC、Hierarchical FW、Org Policy） ↓ 7. アクセス手法を選択（IAP / Chrome Enterprise Premium / WIF） ↓ 8. 監査ログ・コンプラレポート設定 ↓ 9. サプライチェーン保護（Binary Authorization + SLSA） ↓ 10. AI 利用なら Secure AI（Model Armor + Sensitive Data Protection）

🔑 5 分で復習する箇条書きまとめ

階層: Org → Folder → Project → Resource、IAM / Org Policy は継承
IAM ロール: 基本 / 事前定義 / カスタム、最小権限 + グループベース
暗号化: Google-managed / CMEK / HSM / CSEK / EKM
鍵管理: Cloud KMS（Key Ring → Key → Version）、自動ローテーション
シークレット: Secret Manager、CMEK 対応
データ境界: VPC SC、Dry-Run モード、Ingress / Egress Rules
階層 FW: Hierarchical Firewall Policy（強制継承）
Org Policy: 制約で組織統制（gcp.resourceLocations 等）
リモート: IAP / Chrome Enterprise Premium / WIF / SA Impersonation
監査: Cloud Audit Logs 4 種、Access Transparency / Approval、Aggregated Sink
サプライチェーン: Binary Authorization + SLSA + Artifact Registry
Secure AI: Model Armor + Sensitive Data Protection + Confidential VM
規制: HIPAA / PCI DSS / GDPR / SOC 2 / FedRAMP → Assured Workloads
統合管理: Security Command Center（Standard / Premium / Enterprise）
リネーム: Cloud DLP → Sensitive Data Protection、BeyondCorp → Chrome Enterprise Premium

🧭 次のステップ

← セクション 2 に戻るセクション 4：技術ビジネスプロセス分析 → 📝 問題演習を解く 📖 用語集

セクション 3：セキュリティとコンプライアンスの設計

🎯 学習目標

🛡️ 多層防御（Defense in Depth）

責任共有モデル（Shared Responsibility）

🏛️ IAM リソース階層図（Organization → Folder → Project → Resource）

各層の役割

Organization

Folder

Project

Resource

3.1 セキュリティ設計（IAM / 暗号化 / VPC SC / 認証）

IAM の構成要素

Member の種類

ロールの 3 種類

Service Account

3 つの状態の暗号化

Secret Manager

🔧 IAM 設計の 4 つの原則

① 最小権限

② 職務分離

③ グループベース付与

④ 継続的レビュー

🔧 グループベース IAM の実装パターン

🔧 Conditional IAM（条件付き IAM）

🔧 IAM Deny Policy（拒否ポリシー、新機能）

🔧 必ず覚えるロール

🔧 職務分離（Separation of Duties）の典型パターン

🎯 IAM 即答

🔐 暗号化キーの選択フロー

5 つの暗号化方式の比較

Cloud KMS の構造

CMEK 対応サービスの整理

CMEK で得られる主な利点

🛡️ VPC Service Controls 境界設計

主な防御対象

Ingress / Egress Rules（最新・推奨）

Access Context Manager との組合せ

Dry-Run モード（必修）

🔑 Workload Identity Federation のフロー

旧方式 vs WIF

類似機能の使い分け

リモートアクセス手法の選定マトリクス

Chrome Enterprise Premium（旧 BeyondCorp Enterprise）

📋 Organization Policy 制約一覧

Hierarchical Firewall Policy

📦 ソフトウェアサプライチェーン保護

CI/CD パイプライン保護の全体像

SLSA レベル

Binary Authorization のポリシー設計

🤖 Secure AI（最新・必須）

入力（プロンプト）保護

データ保護

モデル保護

Model Armor の利用パターン

Sensitive Data Protection の InfoType（主な例）

モデル盗難対策

3.2 コンプライアンスの設計

監査ログ（Cloud Audit Logs）4 種類

Access Transparency と Access Approval

データ主権（Data Sovereignty / Data Residency）

🔧 ログ保管設計

🔧 ログエクスポートの構成（Log Sink）

🔧 Aggregated Sink（組織横断ログ集約）

🔧 監査ログのフィルタリング例

🎯 監査ログ即答

📜 規制マッピング表（HIPAA / PCI DSS / GDPR / SOC 2 / FedRAMP）

HIPAA 対応の詳細（米国医療）

PCI DSS 対応の詳細（クレジットカード）

GDPR 対応の詳細（EU 個人データ）

🏢 Assured Workloads — 規制対応の隔離環境

対応規制一覧

医療

決済

米国連邦

国別

🛡️ Security Command Center (SCC)

SCC の主要機能

SCC の 3 ティア

Standard

Premium

セクション 3：
セキュリティとコンプライアンスの設計