コンプライアンスとデータ保護

第 13 章では鍵・境界・ゼロトラストという「攻撃から守る」道具を揃えました。この章のテーマは規制と監査です。「HIPAA に対応せよ」「カード情報は PCI DSS 準拠で」「EU 顧客のデータは EU 域内に」——アーキテクトの仕事は、こうした法律・業界基準の言葉を具体的なプロジェクト構成・プロダクト選択・ログ設計に翻訳することです。PCA 試験でもケーススタディ（EHR Healthcare など）でも、この翻訳力がそのまま問われます。

規制をアーキテクチャに翻訳する — 責任共有・HIPAA・PCI DSS・GDPR

コンプライアンスは責任共有 — 認証の調べ方

まず大前提として、クラウドのコンプライアンスは Google と顧客の二階建てです。インフラとマネージドサービスの層は Google が運用し、第三者監査を受けて SOC 1 / SOC 2 / SOC 3、ISO/IEC 27001（情報セキュリティ）・27017（クラウド）・27018（PII 保護）・27701（プライバシー）、PCI DSS などの認証・監査レポートを取得しています。これらのレポートは Compliance Reports Manager から直接ダウンロードでき、自社の監査対応にそのまま利用できます。一覧は公式のコンプライアンス リソースセンターに地域別・業界別で整理されています。

一方、GDPR や HIPAA、COPPA のような法規制そのものについては、公式ページが明言するとおり「クラウド プロバイダは顧客の法令準拠を証明できません」。Google が提供するのはガイダンス文書・コントロールのマッピング・契約上のコミットメントまでで、その上に構築したシステムの準拠性は顧客の責任です。Google はこの協働を「Shared Fate（運命共有）」と呼び、後述の Assured Workloads のような「安全な構成を最初から強制する」仕組みで顧客側の責任範囲を支援します。

HIPAA — BAA を結び、対象サービスだけを使う

米国の医療情報（PHI: Protected Health Information）を扱うシステムでは、HIPAA が求める BAA（Business Associate Agreement、事業提携契約）を Google と締結することが出発点です。締結は公式の手順（Privacy compliance and records ガイド）に従ってレビュー・同意する形で行えます。設計上のポイントは 3 つです。

• BAA の対象は「全インフラ + 明示された 140 以上のプロダクト」（2026-08 時点。対象リストは随時更新される）。Compute Engine・GKE・Cloud Run・BigQuery・Cloud KMS・Sensitive Data Protection など主要プロダクトは対象ですが、対象外のプロダクトと Pre-GA（プレビュー段階）の機能を PHI に使ってはいけません
• HIPAA に「認証」は存在しない。米国 HHS が認める HIPAA 認証制度はなく、BAA を結んだ上で顧客が自らの構成の準拠性を評価します（試験のひっかけ頻出）
• 証跡と衛生の作法: 監査ログは長期保管用に Cloud Storage、分析用に BigQuery へエクスポートすることが強く推奨されています。またリソースのメタデータ・ラベル・指標名・ダッシュボードに PHI を書かない（ログに残るため）、Cloud CDN で PHI をキャッシュしない、といった運用規律が公式ガイダンスに列挙されています

PCI DSS — カード会員データ環境（CDE）をスコープ分離する

Google Cloud は PCI DSS 4.0 の Level 1 サービスプロバイダとして認定されており、要件ごとの責任分担表が公開されています。顧客側の設計の要諦はただひとつ、監査スコープを小さくすることです。公式アーキテクチャガイドは、決済処理環境を本番環境から分離した専用の Google Cloud アカウントに置くことを推奨しており、IAM 構成に慣れたチームであれば専用プロジェクトによる分離でも同等のスコープ削減になるとしています。

• CDE（カード会員データ環境）専用のプロジェクト（または専用アカウント）を作り、アクセス制御と監査を一般本番環境から分離する
• 入口は外部アプリケーション ロードバランサ経由の HTTPS のみ、下り（アウトバウンド）はファイアウォールで決済プロセッサ宛だけを許可する
• 保存する PAN（カード番号）は保存時暗号化に加えてワンウェイハッシュ・切り詰め・トークン化のいずれかで保護する（Google の保存時暗号化だけでは PCI DSS の要件を満たさない）。分析や開発にデータを渡すときは後述の Sensitive Data Protection で無害化してから渡す
• 監査ログは第 8 章のバケットロック（WORM）で改変不能にして保全する

GDPR とデータレジデンシー、COPPA

GDPR では顧客が管理者（controller）、Google が処理者（processor）という役割分担になります。Google は Cloud Data Processing Addendum（CDPA、データ処理規約）で「顧客の指示に従ってのみデータを処理する」ことと GDPR 遵守を契約上コミットし、越境移転には EU 標準契約条項（SCC）を用意しています。サブプロセッサの一覧も公開されており、顧客側の処理者評価に使えます。

技術面の主戦場はデータレジデンシー（保存場所の制御）です。打ち手は 3 段階あります。① リージョン選択で保存場所を自分で選ぶ（第 8 章のロケーションタイプ）、② 組織ポリシーのリソース ロケーション制約で「EU 以外にリソースを作れなくする」（第 2 章）、③ 次項の Assured Workloads で残留性・人員アクセスまで含めて強制する、です。

児童のプライバシーを守る米国の COPPA も、公式コンプライアンス一覧に掲載される「法規制」カテゴリのひとつです。前述のとおりプロバイダが顧客の準拠を証明することはできないため、保護者同意の取得や収集最小化はアプリケーション側の設計責務であり、クラウド側では Sensitive Data Protection による検出・削除の仕組みづくりが支援材料になります。

Assured Workloads — 規制要件を「設定で強制する」

ここまでの翻訳作業を人手のレビューだけで守り続けるのは困難です。Assured Workloads は、規制ワークロード向けの制御一式（コントロールパッケージ）を選んで専用フォルダを作ると、配下のすべてのプロジェクト・リソースにガードレールが自動適用されるサービスです。制御は第 2 章で学んだ組織ポリシー制約として実装されるため、後から作るリソースにも漏れなく効きます。

• コントロールパッケージは 3 系統（2026-08 時点）。地域のデータ境界（日本・EU・米国など 19 地域。データレジデンシーと人員アクセス制御が主体）、規制のデータ境界（FedRAMP Moderate / High、CJIS、医療・ライフサイエンス管理策（HIPAA / HITRUST 対応）、IL2 / IL4 / IL5、ITAR、IRS 1075 など）、そしてパートナーが運用・管理する Sovereign Controls by Partners
• データレジデンシー: 指定地域外へのリソース作成を組織ポリシーで禁止する
• 人員アクセス制御: サポート・運用にあたる Google 人員の所在地や身元審査の要件をパッケージに応じて制限する（Assured Support）
• 暗号化要件: パッケージに応じて Google 管理鍵 / CMEK / Cloud EKM / 鍵インポートを規定する（第 13 章）
• 違反モニタリング: 組織ポリシー制約違反とリソース違反を監視し、メール通知できる

Sensitive Data Protection — PII の検出・マスキング・トークン化

Sensitive Data Protection（旧称 Cloud Data Loss Prevention / Cloud DLP。API 名は現在も DLP API）は、機密データを「見つけて、無害化する」ためのサービス群です。機能は 4 つに大別できます。

• 発見（discovery）: 組織・フォルダ・プロジェクト全体をスキャンして「どこに機密データがあるか」のデータプロファイルを継続生成する。大規模な棚卸し向け
• 検査（inspection）: 個々のリソースやテキストを深くスキャンし、一致箇所と件数を報告する。保存データ（Cloud Storage / BigQuery / Datastore）には検査ジョブ、テキストや画像には同期の content.inspect を使う
• 匿名化（de-identification）: マスキング・秘匿化・バケット化・日付シフト・トークン化などの変換で機密データを無害化する（content.deidentify）
• 再識別リスク分析（risk analysis）: BigQuery の構造化データについて、匿名化後も個人が特定されうる度合いを分析する

「何を機密とみなすか」を定義するのが infoType です。メールアドレス・電話番号・クレジットカード番号など多数の組み込み検出器に加え、正規表現や辞書によるカスタム infoType を定義できます。検出は確率的で、結果には likelihood（POSSIBLE / LIKELY / VERY_LIKELY 等の確度）が付き、minLikelihood で閾値を調整します。

匿名化の変換手法は「元に戻せるか（可逆性）」で整理すると選択を誤りません。

可逆な 2 方式がトークン化（仮名化）です。分析チームにはトークン化済みデータを渡し、正当な業務で元の値が必要になったときだけ content.reidentify と鍵で復元する——という運用ができます。鍵は Cloud KMS でラップした鍵を使うのが本番推奨で、リクエスト限りの一時鍵（transient）や生の鍵（unwrapped）は使い捨て・検証用です。料金は content 系メソッドが検査・変換それぞれ月 1 GB まで無料、以降は検査 US$3.00/GB・変換 US$2.00/GB、保存データの検査ジョブは 1 GB 無料の後 US$1.00/GB です（2026-08 時点）。

Cloud Audit Logs と Google 人員アクセスの透明性

規制対応の最後のピースは「誰が・いつ・何をしたかを証明できること」です。Cloud Audit Logs はほぼすべての Google Cloud サービスに組み込まれた監査証跡で、4 種類に分かれます。

保存の仕組みが規制対応の急所です。管理アクティビティとシステムイベントは _Required ログバケットに書き込まれ、保持 400 日・変更不可・保存無償。データアクセスとポリシー拒否は _Default バケットに入り、既定 30 日（プロジェクトでは 1〜3650 日に変更可）、取り込みは月 50 GiB/プロジェクトの無料枠を超えると US$0.50/GiB です（2026-08 時点）。データアクセスログの閲覧には roles/logging.viewer では足りず、roles/logging.privateLogViewer が必要という点も試験頻出です。400 日を超える保持が必要な規制（PCI DSS の 1 年保持など）では、第 11 章の BigQuery や Cloud Storage への集約シンクを組織レベルで構成し、バケットロックと組み合わせて長期保全します。監査ログのエントリ自体は書き込み後に変更できません。

データアクセスログの有効化は IAM ポリシー内の auditConfigs で行います。サービスごと（例: storage.googleapis.com）または allServices に対して、ADMIN_READ（構成の読み取り）・DATA_READ（データの読み取り）・DATA_WRITE（データの書き込み）の 3 種を個別に有効化でき、特定プリンシパルを除外する exemptedMembers も指定できます。構成は組織 → フォルダ → プロジェクトへ合算で継承され、親で有効化したログを子で無効化することはできません。

Access Transparency と Access Approval — 「Google 側の人」を監査する

Cloud Audit Logs が記録するのは自組織のメンバーの操作です。ではサポート対応などで Google の人員が顧客データにアクセスしたときは？ それを記録するのが Access Transparency です。対象リソースと操作・時刻・アクセス理由（CUSTOMER_INITIATED_SUPPORT のような正当化理由コード）・アクセスした人員の所在地・所属・職種がログに残り、組織レベルで有効化します。

さらに一歩進めて「記録」ではなく「事前承認」にするのが Access Approval です（Access Transparency の有効化が前提）。Google のサポート・エンジニアリング人員がデータへアクセスする前に承認リクエストがメールまたは Pub/Sub で届き、コンソールか API で承認・却下します。重大障害の緊急対応では自動承認（auto approved）になる例外があり、この例外も EU データ境界（Access Justifications 付き）やパートナー主権管理下のワークロードでは無効化されます。金融・政府系の「クラウド事業者の従業員アクセスを統制せよ」という要件は、この 2 つ + Key Access Justifications（第 13 章の EKM と組み合わせる鍵アクセス承認）で応えます。

ハンズオン

Cloud Shell（第 1 章で作成した学習用プロジェクト）で進めます。ローカルの gcloud CLI でも同じ手順で動きます。PROJECT_ID は自分のプロジェクト ID に読み替えてください（gcloud config get-value project で確認できます）。

gcloud services enable dlp.googleapis.com
gcloud config get-value project

cat > inspect-request.json << 'EOF'
{
  "item": {
    "value": "担当: テスト太郎 / test.taro@example.com / 090-1234-5678"
  },
  "inspectConfig": {
    "infoTypes": [
      { "name": "EMAIL_ADDRESS" },
      { "name": "PHONE_NUMBER" }
    ],
    "minLikelihood": "POSSIBLE",
    "includeQuote": true
  }
}
EOF

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d @inspect-request.json \
  "https://dlp.googleapis.com/v2/projects/PROJECT_ID/locations/global/content:inspect"

{
  "result": {
    "findings": [
      {
        "quote": "test.taro@example.com",
        "infoType": { "name": "EMAIL_ADDRESS" },
        "likelihood": "VERY_LIKELY",
        ...
      },
      ...
    ]
  }
}

rm inspect-request.json

cat > deidentify-request.json << 'EOF'
{
  "item": {
    "value": "My name is Alicia Abernathy, and my email address is aabernathy@example.com."
  },
  "deidentifyConfig": {
    "infoTypeTransformations": {
      "transformations": [
        {
          "infoTypes": [ { "name": "EMAIL_ADDRESS" } ],
          "primitiveTransformation": {
            "characterMaskConfig": {
              "maskingCharacter": "#",
              "reverseOrder": false,
              "charactersToIgnore": [ { "charactersToSkip": ".@" } ]
            }
          }
        }
      ]
    }
  },
  "inspectConfig": {
    "infoTypes": [ { "name": "EMAIL_ADDRESS" } ]
  }
}
EOF

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d @deidentify-request.json \
  "https://dlp.googleapis.com/v2/projects/PROJECT_ID/content:deidentify"

{
  "item": {
    "value": "My name is Alicia Abernathy, and my email address is ##########@#######.###."
  },
  "overview": {
    "transformedBytes": "22",
    "transformationSummaries": [ ... ]
  }
}

rm deidentify-request.json
# 学習用プロジェクトで DLP API をもう使わない場合は無効化してもよい（任意）
gcloud services disable dlp.googleapis.com

gcloud storage buckets create gs://PROJECT_ID-audit-handson \
  --location=asia-northeast1

gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json

{
  "auditConfigs": [
    {
      "service": "storage.googleapis.com",
      "auditLogConfigs": [
        { "logType": "DATA_READ" },
        { "logType": "DATA_WRITE" }
      ]
    }
  ],
  "bindings": [ ...既存のまま... ],
  "etag": "...既存のまま..."
}

gcloud projects set-iam-policy PROJECT_ID policy.json

echo "audit log test" > sample.txt
gcloud storage cp sample.txt gs://PROJECT_ID-audit-handson/
gcloud storage cat gs://PROJECT_ID-audit-handson/sample.txt

gcloud logging read \
  'logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"' \
  --freshness=1h --limit=5 \
  --format="value(protoPayload.methodName, protoPayload.authenticationInfo.principalEmail)"

storage.objects.get        your-name@example.com
storage.objects.create     your-name@example.com

gcloud storage rm --recursive gs://PROJECT_ID-audit-handson
gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json
# エディタで auditConfigs ブロックを丸ごと削除して保存してから:
gcloud projects set-iam-policy PROJECT_ID policy.json
rm sample.txt policy.json

つまずきポイント

理解度チェック

まとめと次章へ

• コンプライアンスは二階建て。Google 層の認証（SOC / ISO / PCI DSS 等）は Compliance Reports Manager で入手し、顧客層の構成は自ら証明する。法規制の準拠をプロバイダは証明できない
• HIPAA は BAA + 対象サービス限定 + Pre-GA 回避。PCI DSS は CDE の専用プロジェクト分離でスコープ最小化。GDPR は CDPA / SCC + データレジデンシーの 3 段階（リージョン選択 → 組織ポリシー → Assured Workloads）
• Assured Workloads はコントロールパッケージを組織ポリシー制約としてフォルダに焼き付け、レジデンシー・人員アクセス・暗号化要件を新規リソースにまで強制する
• Sensitive Data Protection は発見・検査・匿名化・リスク分析の 4 機能。変換は可逆性で選ぶ — 復元不要ならマスキング、分析可能性と復元が要るなら KMS 鍵によるトークン化
• 監査ログは 4 種類。データアクセスだけ既定無効（BigQuery を除く）、_Required は 400 日・無償・変更不可、閲覧は privateLogViewer。Google 人員の側は Access Transparency（記録）と Access Approval（事前承認）で統制する

証跡を「残す」仕組みは整いました。次の第 15 章では、ログ・指標を「観測して信頼性を運用する」側 — Google Cloud Observability と SRE のプラクティス（SLI / SLO / エラーバジェット）に進みます。

参考リンク:

• Sensitive Data Protection overview
• Pseudonymization（トークン化の 3 方式）
• Assured Workloads overview
• Cloud Audit Logs overview
• Enable Data Access audit logs
• Access Transparency overview
• Compliance resource center
• HIPAA compliance on Google Cloud
• PCI DSS compliance on Google Cloud
• Well-Architected Framework: コンプライアンス