📚 GCP PCA 学習: 2026-05-12

セクション: 3.2 法令遵守の設計 前回からの繋がり: IAM でアクセス制御を設計したら、次は「誰」「何」だけでなく「どこ」「いつ」といった法令規制要件を組み込んで、全体的なセキュリティ・コンプライアンス体制を完成させる。

① 一言サマリー

法令遵守の設計とは、一言でいうと「GDPR / HIPAA / PCI DSS といった業界・地域の規制要件を、クラウドアーキテクチャに埋め込み、監査・報告できる状態にする」ことです。

② たとえ話

例1: 医療機器製造業（HIPAA 対応） - 医療データ（患者個人情報）は、米国内のみに保存する必要がある - クラウドなら、Google Cloud リージョン選択で「us-central1 のみ」と制限 - バックアップも同じリージョンで自動化 - 第三者監査に「これが証拠」と見せられる

例2: EU 向け SaaS（GDPR） - 欧州ユーザーのデータは、欧州内（europe-west1）にのみ置く - 削除要求（Right to be forgotten）があったら、30 日以内に全削除 - データは暗号化し、鍵は顧客企業ごとに異なる KMS キーで管理 - コンプライアンス監査レポート（四半期ごと）を自動生成

例3: クレジットカード決済（PCI DSS） - カード番号は絶対に GCP ログに記録されない - 決済 API は外部専門業者に委託し、GCP では暗号化されたトークンのみ扱う - Cloud Armor で攻撃検知を記録し、セキュリティ监查人に提出

③ 図解

graph LR
    A["ビジネス要件
業界・地域規制"] --> B["データ所在地制限
リージョン選択"]
    A --> C["データ主権
暗号化・鍵管理"]
    A --> D["監査証跡
ログ・レポート"]

    B --> B1["Cloud SQL regional endpoints
europe-west1 のみ"]
    B --> B2["Cross-region replication 禁止
単一リージョン"]

    C --> C1["KMS: Customer-managed keys
顧客ごとに異なるキー"]
    C --> C2["Secret Manager
PII・API キー暗号化"]

    D --> D1["Cloud Audit Logs
全 API アクセス記録"]
    D --> D2["Cloud Logging + BQ
コンプライアンスレポート"]
    D --> D3["Security Command Center
Compliance Manager"]

    style A fill:#ffcccc
    style B fill:#cce5ff
    style C fill:#ccffcc
    style D fill:#ffffcc

図の見方： - ビジネス要件（赤）= GDPR / HIPAA / PCI DSS などの規制 - 「とは」：法令遵守とは、業界・地域が定めた「データ保護・アクセス制御・監査」ルール - データ所在地制限（青）= リージョン選択で「どこにデータを置くか」を制御 - 医療機器：米国のみ、EU-SaaS：欧州のみ - データ主権（緑）= 暗号化・鍵管理で「誰がデータを見られるか」を制御 - Customer-managed KMS キーなら、GCP 従業員も見られない - 監査証跡（黄）= ログとレポート生成で「何をしたか」を証明

④ 仕組みの深掘り

4-1. データ所在地（Data Residency）と主権（Data Sovereignty）

データ所在地 = 物理的にどのリージョンにデータが置かれているか - GDPR：EU 市民のデータは EU 内のリージョン（europe-west1 など） - HIPAA：患者情報は米国内のリージョン（us-central1 など） - PCI DSS：カード情報は認定データセンターのみ

GCP での実装：

Cloud SQL（MySQL/PostgreSQL）
├─ リージョン: europe-west1（フランクフルト）
├─ バックアップ: 同じリージョンのみ
├─ Read Replica: 同じリージョンか隣接リージョン（Dual-region 設定時）
└─ 他リージョンへの自動レプリケーション: 厳禁

最新 GA: Cloud SQL regional endpoints（2026 年 5 月現在 Preview → GA 予定） - 従来は Cloud SQL Admin API がグローバルエンドポイント（us-central1）だったが、 - リージョナルエンドポイント（europe-west1 など）で、管理トラフィックもリージョン内に留める - コンプライアンス期待値向け（「データ管理トラフィックが欧州を出ない」と証明できる）

データ主権 = 誰がデータにアクセス・解読できるか - GDPR：顧客は「自分のデータは自分のキーで暗号化」を要求 - HIPAA：患者データキーを医療機関が管理（Google は見られない）

GCP での実装：

Encryption
├─ Google-managed keys（デフォルト）: Google が暗号化・復号化を制御
│  └─ PCA 試験向けでは非推奨（顧客監査時に「Google が見ようと思えば見られる」と指摘される）
│
└─ Customer-managed keys（推奨）: 顧客が KMS キーを管理
   ├─ Customer-supplied keys: リクエストごとに送信（HTTP + HTTPS）
   ├─ Cloud KMS: キーを GCP 内で管理。顧客が Unwrap 権限を制御
   │  └─ Key rotation policies: 自動ローテーション（90 日ごと）
   └─ 効果: Google 従業員は「キーを持たないので復号化できない」と証明できる

4-2. GDPR / HIPAA / PCI DSS の主要要件と GCP 対応

GDPR（EU 一般データ保護規則）

PCA 試験でよく出る GDPR シナリオ：

欧州の SaaS 企業が AWS と GCP のマルチクラウド構成を検討。EU 規制対応として最適な構成は？

正解軸： - AWS us-east-1 は使わない（米国） - GCP も us-central1 は使わない - GCP europe-west1（フランクフルト）+ AWS eu-west-1（アイルランド）で「EU 内に完結」 - ただし「Multi-region Redundancy」なら、バックアップ先も EU 内（eu-central-1）に限定

HIPAA（米国医療情報保護法）

HIPAA-eligible services（PCA 試験で頻出）： - ✅ Cloud SQL（MySQL / PostgreSQL） - ✅ Cloud Storage（GCS） - ✅ BigQuery（新規に HIPAA 対応） - ✅ Cloud KMS - ✅ Compute Engine（シンプル VM） - ❌ Cloud Dataflow（❌ HIPAA 非対応・医療データ禁止） - ❌ BigTable（❌ HIPAA 非対応）

試験でよく引っかかるポイント：「Dataflow は高性能だが、HIPAA 非対応。医療データなら Pub/Sub + Cloud Functions の組み合わせか、Dataproc（Hadoop）を Compute Engine 上で自前構築」

PCI DSS（カード業界データセキュリティ基準）

PCA 試験での常套問題：

「EC2 で決済機能を自前実装。GCP に移管するなら？」

正解軸： - ❌ Cloud SQL に直接カード番号を保存 - ❌ Cloud Run で決済ロジックを実装 - ✅ 決済専門業者（Stripe 等）に API で委託。GCP では暗号化トークン + 注文 ID のみ管理 - ✅ 万一漏洩時は「トークンは無効」で対応可能

4-3. 監査・コンプライアンスレポート設計

監査ログの流れ：

1. Cloud Audit Logs（Admin Activity / Data Access）
   ↓ Cloud Logging Sink で BigQuery に転送
2. BigQuery コンプライアンステーブル
   ↓ Data Studio / Looker で視覚化
3. 四半期・年間レポート（PDF エクスポート）
   ↓ 規制当局・内部監査部門に提出

実装例：

# Cloud Logging Router で BigQuery へのシンク設定
Sink Name: compliance-audit-sink
Filter: resource.type="cloud_sql_database" AND logName=~"projects/.*/logs/cloudaudit.googleapis.com"
Destination: bigquery.dataset.audit_logs

# BigQuery でコンプライアンス分析クエリ
SELECT 
  timestamp,
  protoPayload.authenticationInfo.principalEmail as user,
  protoPayload.resourceName as resource,
  protoPayload.methodName as action,
  protoPayload.status.message as result
FROM `project.dataset.audit_logs`
WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND (
    protoPayload.methodName LIKE 'storage.buckets.delete'
    OR protoPayload.methodName LIKE 'sql.instances.update'
  )
ORDER BY timestamp DESC;

最新 GA: Security Command Center の Compliance Manager（2026 年 5 月現在） - 従来は組織レベルでのみ有効化 - 新機能：単一プロジェクトレベルで有効化可能 - メリット：小規模スタートアップが Compliance Manager を無料で試せるように - 対応フレームワーク：CIS Benchmarks / PCI DSS / HIPAA 等

実装フロー：

1. Security Command Center > Compliance Manager を有効化
2. 対象フレームワーク選択（例：PCI DSS v3.2.1）
3. 自動スキャン開始
4. コンプライアンス違反を「Red / Yellow / Green」で可視化
5. 違反項目ごとに「修復方法」を表示（IAM 権限不足 → Cloud IAM 推奨設定 など）

⑤ 他サービスとの使い分け

Google Cloud サービス内での比較

使い分け軸：

graph LR
    A["監査・証明の目的"] --> B["Cloud Audit Logs へ"]
    C["アプリ性能分析の目的"] --> D["Cloud Logging へ"]
    E["コンプライアンス設定確認"] --> F["Compliance Manager へ"]

外部コンプライアンスツール との比較

PCA 試験での出題：

「中堅企業の SaaS が GDPR / HIPAA 両対応を目指す。Google Cloud ネイティブで最小コストの監査体制は？」

正解軸： - ✅ Security Command Center Compliance Manager（GDPR / HIPAA 両フレームワーク対応） - ✅ Cloud Audit Logs → BigQuery シンク（コスト最適・カスタム分析可） - ✅ Cloud Logging Data Boost で大規模ログ分析（月 $100 追加） - ❌ Splunk / Datadog（過剰・コスト高）

⑥ 実務への応用

6-1. Web 系スタートアップの GDPR 対応例

背景：ユーザー 100 万人の SNS が EU 進出。日本・US・EU 市場ごとに別々のアーキテクチャ。

設計：

┌─────────────────┐
│ 日本ユーザー    │  asia-northeast1
│ データ          │ (Tokyo)
│ 日本サーバー法  │
└─────────────────┘

┌─────────────────┐
│ US ユーザー     │  us-central1
│ データ          │ (Iowa)
│ CCPA対応        │
└─────────────────┘

┌─────────────────────────┐
│ EU ユーザー             │  europe-west1
│ データ                  │ (Frankfurt)
│ GDPR: EU内のみ存在    │
│ Customer-managed KMS   │
│ 削除要求 30日自動化    │
└─────────────────────────┘

実装： 1. リージョン分離 - Cloud SQL インスタンスをリージョンごとに分割 - Cross-region replica は EU 禁止

1. 暗号化鍵の顧客管理
2. KMS キーを顧客企業ごとに作成

3. 顧客のプロジェクトで管理権を保持

4. 削除自動化

5. BigQuery Scheduled Query（日次実行）

   DELETE FROM `project.eu_users.user_data`
   WHERE deletion_requested_at <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY);
   

6. Cloud Storage Lifecycle Policy（30 日後に削除）

7. 監査レポート自動生成

8. Data Studio ダッシュボード「GDPR 月次レポート」
9. メトリクス：削除要求数・処理完了数・違反件数
10. 毎月 1 日に PDF 出力・DPO（Data Protection Officer）に配信

6-2. 医療スタートアップの HIPAA 対応例

背景：患者 50 万人のヘルスケアアプリ。米国市場向け HIPAA 対応。

設計：

User App
  ↓ (HTTPS + mTLS)
┌────────────────────────────┐
│ Cloud Run + Workload Identity
│ (認証・暗号化トークン化)     │ us-central1
├────────────────────────────┤
│ Cloud SQL (HIPAA-eligible)  │
│ Customer-managed KMS        │
│ Automatic Backups           │
├────────────────────────────┤
│ Cloud Storage               │
│ (医療画像・PDF)            │
│ Server-side Encryption      │
└────────────────────────────┘
       ↓
Cloud Audit Logs → BigQuery
       ↓
Security Command Center
(HIPAA Compliance チェック)

実装ポイント： 1. HIPAA-eligible サービスのみ使用 - Cloud Dataflow は ❌（HIPAA 非対応） - 代替：Cloud Functions + Pub/Sub

1. 患者データの暗号化
2. 保存時：Cloud SQL + Customer-managed KMS

3. 転送時：TLS 1.2 以上（Cloud Run デフォルト対応）

4. 監査ログ保持

   # Cloud Audit Logs を 1 年間 Cloud Storage に保存
   gcloud logging sinks create hipaa-audit-sink \
     storage.googleapis.com/audit-logs-bucket \
     --log-filter='resource.type="cloud_sql_database"'
   

5. HIPAA BAA 署名

6. Google Cloud 営業チームに「HIPAA BAA 締結希望」を通知
7. 契約後、Cloud Console で BAA status を確認可能

6-3. 受託開発での PCI DSS 対応例

背景：大手流通グループの EC2 決済系を GCP に移管。PCI DSS 準拠必須。

設計：

顧客 (Browser)
  ↓ (HTTPS)
┌──────────────────────┐
│ Frontend (Cloud Run)  │
│ 決済フォーム        │ Public IP
└──────────────────────┘
  ↓ (API)
┌──────────────────────────────┐
│ Stripe / Square API          │
│ (PCI-DSS 認定)               │
│ ← カード情報は Stripe で処理  │
└──────────────────────────────┘
       ↓ (トークン返却)
┌──────────────────────┐
│ Backend (GKE)         │
│ (トークン + 注文 ID)  │ Private Network
│ Cloud SQL に保存     │
└──────────────────────┘
  ↓ (決済完了)
├── Cloud Logging
├── Cloud Monitoring
└── Cloud Audit Logs
     ↓
Cloud Armor (DDoS 検知)

実装： 1. カード情報の非保存 - GCP 側は「stripe_token」のみ保存 - 支払い実行時：stripe.charges.create(amount=..., source=stripe_token)

1. ネットワーク分離
2. VPC 2 つ：Frontend / Backend

3. Backend から Stripe API への HTTPS only

4. 監査ログ設定

   gcloud logging sinks create pci-dss-sink \
     bigquery.googleapis.com/pci_dss_logs \
     --log-filter='(resource.type="gke_container" OR resource.type="cloud_sql_database") AND severity="ERROR"'
   

5. Cloud Armor でカード盗聴防止

6. SQLi / XSS 検知ルール有効化
7. 月 1 回ペネトレーションテスト（外部委託 or AWS WAF Managed Rules と同等の設定確認）

⑦ よくある誤解・落とし穴

落とし穴 1: 「GDPR = データを EU に置けば OK」

❌ 間違い：

「Cloud Storage に EU データ置いた。これで GDPR OK」

✅ 正解：

「Cloud Storage: europe-west1 ✓
 Cloud Audit Logs: 自動で全コピーが us-central1 に保存される ❌
 → ログもリージョン制限が必要」

PCA 試験での対応： - Cloud Logging Sink で BigQuery（同一リージョン）へ転送 - Cloud Audit Logs は 1 年保持後、GCS（同一リージョン）に自動アーカイブ

落とし穴 2: 「HIPAA = データ暗号化すれば OK」

❌ 間違い：

「Cloud SQL 暗号化有効にした。これで HIPAA OK」

✅ 正解：

「Cloud SQL 暗号化 ✓
 (ただし Google-managed keys では不十分 ❌)
 → Customer-managed KMS で患者情報キーを顧客が管理
 →ネットワーク: VPC + Private IP only
 → ログ: HIPAA-eligible storage に 1 年保持」

PCA 試験での採点軸： - "HIPAA 準拠" = 6 要素：リージョン制限 + 暗号化鍵管理 + 監査ログ + HIPAA-eligible service + ネットワーク分離 + バックアップ保持

落とし穴 3: 「Security Command Center がすべてを検出」

❌ 間違い：

「Compliance Manager を有効化した。
 これでコンプライアンス違反を全自動検出」

✅ 正解：

「Compliance Manager:
 - GCP リソース設定チェック（IAM / Firewall / KMS）のみ
 - アプリケーションロジックの規制違反は検出不可
  例：「削除要求を 35 日で処理（GDPR 30 日超過）」は Cloud Logging で手動確認が必要」

落とし穴 4: 「コンプライアンス=セキュリティ」

❌ 間違い：

「VPC + IAM + KMS 設定した。コンプライアンス達成」
→ でも「何をしたか」の記録がない
→ 監査人に「証拠を見せてくれ」と言われて困る

✅ 正解：

「セキュリティ（アクセス制御） + コンプライアンス（監査証跡）は別
 → VPC（どこからアクセスか）+ IAM（誰がアクセスか）+ Cloud Audit Logs（何をしたか）の 3 点セット」

⑧ 理解度チェック

次のシナリオで最適なアーキテクチャを選んでください：

「欧州の医療機関が、患者データ 100 万レコードを GCP に移管。GDPR と HIPAA 両対応が要件。 - 患者は米国・EU 両地域に分布 - 患者削除要求は 30 日以内に全削除 - カード決済情報は含まない（別業者で処理） - 4 半期ごとにコンプライアンス監査を受ける

最適な構成は？」

• (A) Cloud SQL 単一インスタンス（us-central1）+ Cloud Storage global buckets + Google-managed keys + Cloud Logging
• (B) Cloud SQL 2 つのインスタンス（europe-west1 / us-central1）+ Regional Cloud Storage buckets + Customer-managed KMS（リージョンごと）+ Cloud Logging → BigQuery シンク + Compliance Manager
• (C) Cloud Spanner（複数リージョン自動レプリケーション）+ Firestore（リアルタイム同期）+ Google-managed keys + Data Studio
• (D) BigTable（複数リージョン）+ Cloud Storage archive + Customer-supplied keys + Security Command Center Standard tier

1. Cloud SQL インスタンス 2 つ作成
   - sql-eu（europe-west1）、sql-us（us-central1）

2. Customer-managed KMS キーを「医療機関の GCP プロジェクト」で作成
   - キーA（EU 患者データ用）
   - キーB（US 患者データ用）

3. Cloud SQL で「暗号化キー」を上記キーに指定
   - Cloud SQL は KMS keyを呼び出して復号化
   - Google コンソール上でも「キーなし」で見られない

4. Cloud Logging Sink 設定
   - europe-west1 のすべてのログ → eu_logs dataset（BigQuery）
   - us-central1 のすべてのログ → us_logs dataset（BigQuery）
   - リージョン別に監査証跡を分離

5. BigQuery Scheduled Query（日次実行）
   - SELECT * FROM eu_logs WHERE deletion_requested_at IS NOT NULL
   - 対応する Cloud SQL レコードを DELETE

6. GCS Lifecycle Policy
   - 30 日経過したログオブジェクトを削除

7. Security Command Center Compliance Manager
   - CIS v1.2 + HIPAA フレームワークを有効化
   - 月 1 回自動スキャン
   - IAM / Firewall / KMS 設定の違反を検出

8. 4 半期ごとのレポート生成
   - Data Studio ダッシュボード：違反検出数・修復完了数・削除実行数
   - 監査人に提出

⑨ 深掘り補足（PCA 試験範囲外・応用知識）

Preview 機能: Cloud SQL Regional Endpoints（2026 年 5 月現在 Preview）

⚠️ Preview

何か：Cloud SQL Admin API がグローバルエンドポイント（us-central1）ではなく、リージョナルエンドポイント（eu-west1 など）から管理操作を実行する機能。

メリット： - 医療・金融規制でよく問われる「管理トラフィックもリージョン内に留める」を実現 - 従来：データは europe-west1、管理 API 呼び出しは us-central1 → 規制当局に「EU を出ている」と指摘される - 新機能：--preferred-region=europe-west1 で API 呼び出しもリージョン内に

PCA 試験での出題予想（GA 後）：

「GDPR EU-only 要件で、管理トラフィックも EU を出さない設定は？」 - ❌ Cloud SQL regional endpoint なし（2026 年 Q1 時点では Preview） - ✅ Cloud SQL regional endpoint with --preferred-region 指定

実務トレンド: Zero Trust + コンプライアンス

大企業では「IAM だけでなく、ネットワーク・アプリケーション・監査ログ全体で Zero Trust を実装」という動きが加速。

GCP での実装パターン：

┌────────────────────────────────────────────────┐
│ Zero Trust Compliance Stack                    │
├────────────────────────────────────────────────┤
│ Identity: Service Account + Workload Identity  │
│ Network: VPC Service Controls + Private Google Access │
│ Application: Cloud Armor + Cloud CDN + Mutual TLS │
│ Audit: Cloud Logging + Security Command Center │
│ (CIS Benchmark 自動スキャン)                   │
└────────────────────────────────────────────────┘

このすべてが「GDPR / HIPAA / PCI DSS」要件に対応する最小限の構成。

関連アーキテクチャパターン: マルチテナント SaaS の GDPR

SaaS 企業が「顧客ごとに異なるリージョン」でデータを分離する場合：

顧客A（EU）
  ↓
  Cloud SQL（europe-west1）+ KMS key-eu

顧客B（US）
  ↓
  Cloud SQL（us-central1）+ KMS key-us

顧客C（JP）
  ↓
  Cloud SQL（asia-northeast1）+ KMS key-jp

各顧客が「自分のキーは自分で管理」。SaaS 企業は「キーへのアクセス権」のみを制御。これが「次のステップ」として出題されることが多い（PCA v6.1 試験で実際に出題例あり）。

次回: 4.1 技術プロセスの分析と定義（SDLC / CI-CD）