PCSE 合格対策
S5 コンプライアンス対応 🎯 Deep Dive 出題 ~11%

Compliance & Sovereignty
公式ドキュメント深掘り

責任共有モデル / Assured Workloads / Access Transparency / Access Approval / Sovereign Cloud / 規制別対応（HIPAA / PCI-DSS / GDPR / FedRAMP）/ 組織ポリシー強制 / 監査文書化を、公式情報・運用フロー・落とし穴まで深掘り。

中堅〜シニア向け Assured Workloads 公式 Access Transparency / Approval Compliance Reports

このページの目次

  1. 1. 責任共有モデル詳細
  2. 2. Assured Workloads
  3. 3. Compliance タイプ一覧
  4. 4. Access Transparency
  5. 5. Access Approval
  6. 6. Sovereign Cloud / EU Sovereign Controls
  7. 7. HIPAA 対応
  8. 8. PCI-DSS 対応
  9. 9. GDPR 対応
  10. 10. FedRAMP / IL 対応
  11. 11. コンプライアンス系組織ポリシー
  12. 12. Compliance Reports Manager
  13. 13. 監査ドキュメンテーション
  14. 14. リスク・落とし穴総まとめ
  15. 15. 設計チェックリスト

1. 責任共有モデル詳細

"Shared Fate" のもとで Google と顧客の責任を分担。サービスモデルによって境界がスライドするのが核心。公式

レイヤIaaS (GCE)PaaS (Cloud Run / GAE)SaaS (Workspace)BaaS (BigQuery / Spanner)
データ分類 / IAM 設定 / アクセス制御顧客顧客顧客顧客
アプリケーションコード顧客顧客Google
ランタイム / ライブラリ顧客GoogleGoogleGoogle
OS / コンテナイメージ顧客GoogleGoogleGoogle
ネットワーク制御（VPC / FW）顧客Google
ハイパーバイザ / カーネルGoogleGoogleGoogleGoogle
物理データセンタ / 電源 / 物理セキュリティGoogleGoogleGoogleGoogle

Shared Fate（共有運命）

2021 年以降 Google は Shared Fate という概念を提唱。「責任を切り分ける」だけでなく、Google も顧客の成功にコミットする思想。具体的には：

2. Assured Workloads

規制対応ワークロードを 専用フォルダ に分離し、利用可能サービス / リージョン / サポート人員を制約する仕組み。公式

仕組みの 4 つの制約

  1. データ所在地：指定リージョンに固定（保存 / 処理）
  2. サポート人員：適格な人員（FedRAMP High なら米国市民、IL5 なら米国市民 + 機密区分）
  3. 利用可能サービス：規制対応済みサービスのみ（一部 GA が制限される）
  4. 鍵管理：CMEK 強制（オプション、規制により必須）

違反操作のモード

⚠️ Assured Workloads の制約事項

3. Compliance タイプ一覧

Assured Workloads がサポートする主要規制とその概要。

米国系

タイプ規制サポート人員主な制約
FedRAMP Moderate米国連邦 中レベル米国市民（任意）米国リージョン、FedRAMP 認証サービスのみ
FedRAMP High米国連邦 高レベル米国市民必須同上、より厳格
IL2 / IL4 / IL5米国国防（DoD CC SRG）米国市民、機密区分GovCloud リージョン、限定サービス
HIPAA米国医療プライバシーBAA カバー範囲のみBAA 締結必須、HIPAA 認証サービス
HITRUST医療横断フレームワークHITRUST 認証スコープ―
CJIS米国司法（Criminal Justice Info）CJIS 適格人員―
ITAR米国国際武器取引規制米国市民必須限定リージョン

地域系（リージョン + サポート人員）

タイプリージョンサポート人員
EU Regions and SupportEU 内EU 居住者
EU Sovereign ControlsEU 内EU 居住者 + Transparency/Approval
Canada Regions and SupportCanada 内Canada 居住者
Saudi Arabia Regions and SupportSaudi Arabia 内適格人員
Israel Regions and SupportIsrael 内適格人員
Japan Regions and SupportJapan 内（東京 / 大阪）日本居住者
gcloud Assured Workloads（HIPAA）の作成
gcloud assured workloads create \
    --location=us-central1 \
    --organization=ORG_ID \
    --display-name="hipaa-prod" \
    --compliance-regime=HIPAA \
    --billing-account=billingAccounts/BILLING_ID \
    --resource-settings=consumer-project-id=hipaa-prod-001

# 結果: 専用フォルダが作成され、配下にプロジェクトが作られる
# 配下プロジェクトでは HIPAA 認証されたサービス + 米国リージョンのみ利用可

4. Access Transparency

Google サポート / オペレーター / SRE が顧客データにアクセスする際、誰が・なぜ・何にアクセスしたかをログに残す。公式

仕組み

Justification Reason の主な区分

対応サービス

BigQuery / Cloud Storage / Compute Engine / Cloud SQL / Spanner / Cloud Logging / IAM ほか。対応リスト

5. Access Approval

Access Transparency が「ログとして記録」なら、Access Approval は 「顧客の承認なしには許可しない」 能動的なゲート。公式

Access Approval の承認フロー Google オペレーター アクセス要求 Access Approval Queue Pub/Sub 通知 → 顧客の承認チーム 承認 approve / dismiss 実アクセス 承認方式：手動 (UI/API) または自動 (Pre-approved Service Account) 承認の有効期間：1〜30 日（リクエストごとに指定） ⚠️ 承認しないと Google サポートのデバッグ・障害対応が制限される ⚠️ Premium Support 以上の契約が必要な場合あり
図 1: Access Approval の承認フロー。手動承認 or Pre-approved SA による自動承認。

運用設計のポイント

6. Sovereign Cloud / EU Sovereign Controls

国・地域の主権要件（データ主権 / オペレーション主権 / ソフトウェア主権）に対応する Google Cloud のオファリング群。

EU Sovereign Controls の特徴

Sovereign Cloud パートナーモデル

7. HIPAA 対応

米国 医療情報プライバシー規制。Protected Health Information (PHI) を扱う場合の標準対応パターン。公式 HIPAA

HIPAA 対応の必須要素

  1. BAA 締結　Google と Business Associate Agreement を締結。Workspace / GCP の両方で必要なら別途。
  2. Assured Workloads (HIPAA)　HIPAA 認証サービスのみ利用可能な Folder を作成。
  3. 暗号化　CMEK で PHI を暗号化、可能なら Cloud HSM。
  4. 監査ログ　Admin Activity + Data Access ログを全 PHI サービスで有効化、7 年保持。
  5. VPC SC　PHI を含むプロジェクトを境界に含め、egress を制御。
  6. De-identification　可能なら SDP で PHI を de-identify、分析者には Safe Harbor / Expert Determination 適用後のデータのみ提供。
  7. Access Control　ロールベース + Conditions + PAM で最小権限。
  8. Disaster Recovery　別リージョン（HIPAA 認証地域内）への複製。

HIPAA で BAA 対象のサービス（一例）

8. PCI-DSS 対応

カード業界データセキュリティ規格。Cardholder Data Environment (CDE) を最小化する戦略。公式

PCI-DSS 対応の標準パターン

  1. カード番号を保存しない：SDP の FPE で取り込み時にトークン化 → CDE スコープ縮小
  2. 暗号鍵は Cloud HSM（FIPS 140-2 Level 3）または EKM
  3. ネットワーク分離：CDE プロジェクトを別 VPC + VPC SC、Cloud Armor で WAF
  4. Audit Log + Log Bucket Lock：1 年以上の改ざん不可保持
  5. 四半期の脆弱性スキャン：Container Analysis + 外部 ASV スキャン
  6. Penetration Testing：年 1 回（Google への事前通知不要）

Google Cloud の PCI-DSS 認証範囲

9. GDPR 対応

EU 居住者の個人データ保護。Google Cloud は Data Processor（顧客は Controller）。公式

GDPR 対応の核

EU 主権要件（Schrems II 対応）

10. FedRAMP / IL 対応

米国連邦政府向けクラウドセキュリティ認証。Google Cloud は FedRAMP High 認証（IL2/IL4/IL5 も対応）。公式

FedRAMP の 3 階層

階層影響度用途主な制約
Low低パブリック情報―
Moderate中大半の連邦情報米国リージョン
High高法執行 / 緊急対応 / 重要金融米国市民サポート、限定サービス

IL（DoD Impact Level）

11. コンプライアンス系組織ポリシー

Constraint用途規制例
gcp.resourceLocationsリージョン許可リストGDPR / Data Residency
gcp.restrictNonCmekServicesCMEK 必須HIPAA / PCI-DSS
gcp.restrictCmekCryptoKeyProjectsCMEK 鍵プロジェクト制限鍵管理ガバナンス
storage.uniformBucketLevelAccessGCS の Uniform IAM 強制監査強化
storage.retentionPolicySecondsGCS Retention 最低期間WORM 要件
iam.allowedPolicyMemberDomains許可ドメイン以外への IAM 禁止外部漏洩防止
iam.disableServiceAccountKeyCreationSA 鍵作成禁止鍵漏洩防止
compute.requireOsLoginOS Login 強制監査強化
compute.requireShieldedVmShielded VM 強制FedRAMP High 推奨
compute.disableSerialPortAccessシリアルポートアクセス禁止監査強化
compute.vmExternalIpAccess外部 IP 禁止ネットワーク隔離
sql.restrictPublicIpCloud SQL Public IP 禁止HIPAA / PCI-DSS

12. Compliance Reports Manager

Google Cloud の認証 / 証明書を顧客監査の証跡として提供する管理画面。公式

取得可能な主な書類

13. 監査ドキュメンテーション

顧客側で監査人に提示する証跡を体系的に整備する。

顧客側で用意すべき証跡

  1. IaC（Terraform / Config Connector）：すべての構成をコードで管理
  2. 組織ポリシー定義：YAML + 適用範囲
  3. Posture 定義：Security Posture Service の宣言
  4. 監査ログ：規制要件の保持期間 + Bucket Lock
  5. Access Transparency Log：Google アクセスの追跡
  6. Access Approval Decision Log：承認 / 拒否の記録
  7. SCC Findings 履歴：検出 → 対応 → クローズの一連
  8. ペネトレーションテスト報告書：年 1 回
  9. BCP / DR 計画書 + RTO / RPO 文書
  10. 従業員トレーニング記録：HIPAA / PCI-DSS は必須

監査対応の運用化

14. リスク・落とし穴総まとめ

🚨 試験頻出のリスクトピック

15. 設計チェックリスト

📚 関連リソース