Section 3: セキュリティとコンプライアンス — 🔧 応用編

対象: 実務 3-5 年・GCP 経験あり / 設計判断・トレードオフ・規制対応の設計パターン を体系化したい人。 目標: 試験で問われる「正しいセキュリティ選択」を高精度で出せるようになる。

1. IAM 設計の応用

IAM 設計の 4 つの原則

グループベース 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 は許可ベース（許可がなければアクセス不可）ですが、明示的に拒否 することも可能。

Allow ロールを継承していても、Deny Policy がある場合は拒否される
   ↓
組織レベルで「全員に projects.delete を deny」など強制

Deny は Allow より優先。Org Policy と組合せて統制を強化。

IAM のロール選定（最頻出）

2. リソース階層の設計パターン

パターン A: 環境別 Folder（一般的）

Organization (example.com)
  ├── Folder: production
  │   ├── Project: prod-app-001
  │   ├── Project: prod-db-001
  │   └── Project: prod-network-001
  ├── Folder: staging
  │   └── Project: staging-app-001
  └── Folder: development
      └── Project: dev-app-001

利点：環境ごとの Org Policy（例：prod でのみ Confidential VM 強制）

パターン B: 部門別 Folder（大企業向け）

Organization
  ├── Folder: department-A
  │   ├── Folder: prod / dev / qa
  ├── Folder: department-B
  └── Folder: shared-services（共通インフラ）

利点：部門ごとの請求分離、独立した管理権限

パターン C: 規制対応の隔離 Folder

Organization
  ├── Folder: regulated-hipaa（Assured Workloads）
  ├── Folder: regulated-pci（Assured Workloads）
  └── Folder: general

利点：規制対応プロジェクトをロックダウン、誤って他環境と混ざらない

3. Organization Policy の設計

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

よく使う Org Policy 制約（必須暗記）

試験頻出パターン

4. 暗号化設計の選定（最頻出）

CMEK / EKM / HSM の判断フロー

鍵管理の要件は？
  顧客側で鍵を完全管理したい？
    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（デフォルト）

CMEK 対応サービスの整理（重要）

Cloud KMS 鍵ライフサイクル

[作成]
  ↓ 自動ローテーション設定（例: 90 日）
[使用中]
  ↓ ローテーション
[新バージョン]（古いバージョンも併存）
  ↓ 古いバージョン無効化
[Disabled]（破壊予約）
  ↓ 24 時間〜30 日の猶予
[Destroyed]（破壊、復旧不可）

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

CMEK で得られる主な利点

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

5. 職務分離（Separation of Duties）

「1 人で全工程をできないようにする」設計。

典型的な職務分離パターン

KMS の職務分離例

[KMS Admin]                [Application]
  権限: 鍵の作成・削除・     権限: 暗号化・復号のみ
       ローテーション
       
  ⇒ 互いに独立、相互の権限を持たない

これにより、アプリ管理者が誤って鍵を削除する事故 や、KMS 管理者がアプリデータを覗き見 することを防ぐ。

6. VPC Service Controls の応用

Perimeter の構造

[Service Perimeter]
  ├── Projects（複数 Project を 1 つの境界に包含）
  ├── Restricted Services（保護対象サービス）
  ├── VPC Accessible Services（境界内で使えるサービス）
  ├── Access Levels（境界外からの例外許可ルール）
  └── Ingress / Egress Rules（最新の細粒度ルール）

Ingress / Egress Rules（最新・推奨）

旧来の Access Level だけでは表現できない、細かい入出方向のルール を定義。

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 モード

試験パターン

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

詳細選定表

Workload Identity for GKE と Workload Identity Federation の違い

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

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]

Binary Authorization のポリシー設計

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

Break-Glass デプロイ（緊急時の例外）

緊急対応で署名なしのイメージをデプロイしたいケース。

[Binary Authorization Break-Glass]
  ↓ アノテーション付きでデプロイ
[ログに緊急デプロイ記録]
  ↓ 監査
[後で適切な署名で再デプロイ]

SLSA レベルの実装目安

試験頻出: 「コンテナイメージの信頼性を担保したい」→ Binary Authorization + SLSA

9. Secure AI（最新・必須）

LLM / AI セキュリティの 3 つの軸

入力（プロンプト）保護
   └── Model Armor
       ├── Prompt Injection 検出
       ├── Jailbreak 検出
       ├── 機密 / PII 検出
       └── 出力フィルタリング

データ保護
   └── Sensitive Data Protection（旧 Cloud DLP）
       ├── PII 検出（メール、SSN、クレカ、医療 ID）
       ├── マスキング / トークン化
       └── 構造化・非構造化データ両対応

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

Model Armor の利用パターン

ユーザー入力 → Model Armor（Sanitization）→ Gemini / 自社 LLM
                ↓ blocked
              拒否レスポンス + 監査ログ

主要設定項目：

• プロンプトインジェクション: ON/OFF + 厳しさレベル
• 有害コンテンツ: 暴力/性的/ヘイト/危険なし
• PII: 検出時マスキング or ブロック
• データプライバシー: SSN/クレカ/医療情報の検出
• マルウェア URL: 危険な URL ブロック
• 責任ある AI フィルタ: バイアス、差別

Sensitive Data Protection の検出パターン

モデル盗難対策

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

10. 規制対応の応用

HIPAA 対応（米国医療）

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

GDPR 対応（EU 個人データ）

SOC 2 対応

FedRAMP 対応（米国連邦政府）

11. 監査ログの設計

ログ保管設計

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

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

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

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

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

Organization レベルで Sink を作成し、全 Project のログを 1 か所に集約。

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

12. Security Command Center（SCC）

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

SCC の主要機能

SCC のティア

13. 設計判断のトレードオフ例

ケース 1: CMEK vs Cloud HSM vs EKM

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

判断軸：

• 「FIPS 140-2 Level 3」キーワード → Cloud HSM 一択
• 「鍵を GCP 外で保持したい」→ Cloud EKM 一択
• 通常の規制対応 → CMEK で十分

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

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

判断軸：

• 「BYOD」「デバイス検証」キーワード → Chrome Enterprise Premium
• 個別アプリへのアクセスだけ → IAP
• 全社レベルの IP 接続 → HA VPN

ケース 3: VPC SC vs IAM のみ

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

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

ケース 4: Sensitive Data Protection vs Confidential VM

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

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

14. 試験で問われる「定番のセキュリティ設計問題」

問題パターン 1: 「最も安全な構成は？」

判断軸：

1. 多層防御（複数レイヤー）になっているか
2. 最小権限の原則
3. 監査が可能か
4. キー / 鍵が GCP 内で完結しているか or 顧客管理か

問題パターン 2: 「規制対応の構成は？」

判断軸：

1. 規制を特定（HIPAA / PCI DSS / GDPR / FedRAMP）
2. データ主権要件（リージョン制限）
3. 暗号化方式（CMEK / HSM）
4. 監査ログ・Access Transparency
5. Assured Workloads が使えるか

問題パターン 3: 「キー無しでアクセスしたい」

判断軸：

1. Service Account キーは使うべきではない
2. 外部ワークロード → Workload Identity Federation
3. GKE Pod → Workload Identity for GKE
4. 内部 → Service Account Impersonation

問題パターン 4: 「ML / AI モデルを守りたい」

判断軸：

1. プロンプト保護 → Model Armor
2. データ匿名化 → Sensitive Data Protection
3. モデル盗難防止 → Confidential VM + CMEK + VPC SC

15. 章末まとめ

必ず覚える「サービス対応表」

次のステップ

• 直前確認: 03_要点と暗記.md
• 演習: ../../03_問題集/section3_問題集.md
• 関連セクション: Section 1 (アーキ設計), Section 6 (運用卓越性)