Section 3: セキュリティとコンプライアンス — 📘 基礎編

対象: 実務 1-2 年・GCP 初学者 / クラウドセキュリティを初めて学ぶ人。 目標: IAM・暗号化・VPC SC・IAP の基本概念を理解し、規制要件をサービスに翻訳できる。

1. クラウドセキュリティの考え方

責任共有モデル（Shared Responsibility Model）

クラウド利用では Google と顧客で責任分担 します。サービスの抽象度が上がるほど、Google が多くを担当します。

顧客は常にデータと IAM に責任を持つ。これが試験の前提です。

多層防御（Defense in Depth）

セキュリティは 1 つの層で完結しない。複数のレイヤーで重ねるのが原則です。

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

2. リソース階層

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 の継承

上位で付与したロールは 下位に自動継承。逆方向には継承しません。

例：

• Organization で roles/viewer を付与 → 全 Folder/Project/Resource で閲覧可
• Project で roles/editor を付与 → その Project 内のリソースのみ編集可

3. IAM の基本

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 の種類

ロールの 3 種類

最小権限の原則（Principle of Least Privilege）

「必要最小限の権限のみ付与」 が IAM の鉄則。

悪い例：

alice@example.com に roles/owner を付与（=全権限）

良い例：

alice@example.com に roles/storage.objectViewer を該当バケットのみ付与

Service Account（重要）

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

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

主な用途：

• GCE VM がGCS に書き込む
• Cloud Run が BigQuery を読む
• GKE Pod が Secret Manager にアクセス

⚠️ Service Account キー（JSON）は 漏洩リスクが高い。Workload Identity / Workload Identity Federation での代替が推奨されます（後述）。

4. データの暗号化

3 つの状態の暗号化

鍵管理の選択肢（重要・頻出）

鍵の管理権限
  Google が完全管理（デフォルト）
    → Google-managed encryption keys
  
  顧客が鍵を管理したい
    ├── GCP 内で鍵管理
    │   ├── ソフトウェア鍵: Cloud KMS （CMEK = Customer-Managed Encryption Key）
    │   └── ハードウェア鍵: Cloud HSM（FIPS 140-2 Level 3）
    │
    └── 鍵を GCP 外部で保持
        ├── 暗号化時に持込: CSEK（Customer-Supplied Encryption Key、限定機能）
        └── 外部 HSM で鍵を保持: Cloud EKM（External Key Manager）

4 つの暗号化方式の比較

試験で「顧客が鍵を完全に管理 + GCP 外部に置く」と問われたら Cloud EKM が正解。

Cloud KMS の基本

[Key Ring] ─contains─→ [Key] ─version─→ [Key Version (v1, v2, ...)]
   ↑
リージョン or グローバル

• Key Ring: 鍵を束ねる入れ物（リージョン単位 or グローバル）
• Key: 暗号化鍵（対称/非対称、署名鍵もあり）
• Key Version: 鍵のバージョン（ローテーション時に新バージョン生成）

鍵ローテーション

• 自動ローテーション: 期間を指定すれば自動で新バージョン生成（推奨 90 日）
• 手動ローテーション: 必要に応じて新バージョン作成
• 古いバージョンは無効化可能（破壊は 24 時間後）

5. Secret Manager

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

基本機能

[Secret] ─version─→ [Secret Version (v1, v2, ...)]
   ↓
IAM で誰がアクセス可能か制御
   ↓
バージョン指定でアクセス（latest または特定バージョン）

主な特徴

Secret Manager Regional（最新）

リージョン内に閉じたシークレット保管。データ主権要件 に対応。

6. 監査ログ（Cloud Audit Logs）

「誰が、いつ、何をしたか」を記録するログ。試験頻出。

4 種類のログ

Access Transparency と Access Approval（最新）

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

7. ネットワークセキュリティの基本

VPC ファイアウォール

VPC 内の通信を IP/ポート/タグで制御する基本機能。

Hierarchical Firewall Policy（重要）

組織や Folder 単位で 下位に強制継承 されるファイアウォールルール。

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

VPC Service Controls（VPC SC、重要・頻出）

「データの境界（Service Perimeter）」を作る 機能。リソース内のデータが外部にコピーされるのを防ぐ。

[VPC SC Perimeter]
   ├── Project A
   ├── Project B
   │   └── GCS / BigQuery / Pub/Sub
   └── Service: GCS, BigQuery, ...

→ Perimeter 外から内部へのアクセス: 拒否
→ Perimeter 内から外部へのコピー: 拒否（exfiltration 防止）
→ Perimeter 内通信: 許可

主な防御対象：

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

8. Identity-Aware Proxy（IAP）

「VPN なしで Google アイデンティティベースの安全なアクセス」を実現するサービス。

仕組み

[ユーザー]
   ↓ HTTPS（Google ログイン）
[IAP]
   ↓ ID チェック + IAM 認可
[内部アプリ / GCE VM / SSH]

2 つのユースケース

IAP の利点

• VPN 不要
• Google アカウント（or 外部 IdP）でログイン
• IAM でアクセス制御（roles/iap.tunnelResourceAccessor など）
• アプリ側にコード変更不要

9. リモートアクセス手法の選択肢

10. Service Account Impersonation（重要）

他のサービスアカウントとして一時的に振る舞う。Service Account キー（漏洩リスク）を回避できる。

[ユーザー alice]
   ↓ has roles/iam.serviceAccountTokenCreator
[Service Account A]
   ↓ impersonate（短期トークン取得）
[GCP API にアクセス]

利点：

• キーファイル不要
• アクセス時刻の制限（短期）
• 監査ログに iam.serviceAccounts.getAccessToken として記録

11. 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 アクセス]

利点

試験頻出: 「GitHub Actions / AWS Lambda から GCP にキー無しでアクセス」→ Workload Identity Federation

Workforce Identity Federation（人間用）

ユーザー（人間）が外部 IdP（Okta/Azure AD/Active Directory）の ID で GCP にログインできる仕組み。Cloud Identity の代替として使える。

12. Chrome Enterprise Premium（旧 BeyondCorp Enterprise）

Google のゼロトラスト・エンタープライズ製品。リネームに注意。

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

主な機能：

• デバイスポスチャ評価（社内デバイス・BYOD の安全性チェック）
• コンテキストアウェア アクセス（ロケーション、時刻、デバイス信頼度で制御）
• データ流出防止（DLP、コピペ・印刷ブロック）
• 脅威防御（マルウェア、フィッシング）

試験頻出: 「BYOD で Chrome 経由社内アプリにアクセス」→ Chrome Enterprise Premium

13. ソフトウェアサプライチェーンの保護

ビルド〜デプロイの脅威

[コードリポ] → [ビルド] → [コンテナ Registry] → [デプロイ] → [本番]
   ↑           ↑              ↑                  ↑
脆弱性     ビルド改竄    悪意あるイメージ    認証バイパス
依存攻撃   秘密鍵漏洩    ベース改竄

主要対策サービス

Binary Authorization の流れ

[コード] → [Cloud Build] → [署名 attestation] → [Artifact Registry]
                                                       ↓
                                            [Binary Authorization で検証]
                                                       ↓
                                          検証 OK → デプロイ許可
                                          検証 NG → デプロイ拒否

SLSA レベル

14. Secure AI（最新・頻出）

LLM や AI モデル特有のリスクへの対策。

3 つの主要リスクと対策

Model Armor（最新）

LLM 向けのファイアウォール。プロンプト入力・出力をスクリーニング。

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

Sensitive Data Protection（旧 Cloud DLP）

データ内の PII を 自動検出・マスキング・トークン化。

主な機能：

• 検査（Inspection）: テキスト・画像から PII を検出
• 匿名化（De-identification）: マスキング、ハッシュ化、トークン化
• 再識別リスク評価（k-匿名性、l-多様性）
• 構造化データ / 非構造化データ両対応
• BigQuery / GCS / Datastream と統合

15. 規制対応の基礎

主要な規制とサービスマッピング

Assured Workloads（重要）

規制対応のための 隔離環境を自動構築 するサービス。

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

対応規制：

• HIPAA
• PCI DSS
• FedRAMP High / Moderate
• IL2/IL4/IL5（米国国防）
• ITAR
• Canadian Protected B
• EU Sovereign Controls

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

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

実現方法：

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

16. まとめ — セキュリティ設計の判断フロー

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）

次のステップ

• 中堅レベルへ進む方: 02_応用.md で CMEK 設計・職務分離・サプライチェーン保護・Secure AI を深掘り
• 試験準備中の方: 03_要点と暗記.md で要点を整理
• 演習を始める方: ../../03_問題集/section3_問題集.md