PCSE 合格対策
S3 データ保護 🎯 Deep Dive 出題 ~23%

Data Protection
公式ドキュメント深掘り

暗号化の 3 層(at rest / in transit / in use)、CMEK / Cloud HSM / Cloud EKM、Sensitive Data Protection、Secret Manager、Confidential Computing、Vertex AI セキュリティを、公式仕様・鍵管理運用・FIPS 認証・落とし穴まで深掘り。

このページの目次

  1. 1. 暗号化の 3 層
  2. 2. Google 既定暗号化(DEK/KEK)
  3. 3. CMEK 詳細
  4. 4. Cloud HSM (FIPS 140-2 L3)
  5. 5. Cloud EKM 詳細
  6. 6. 鍵ローテーション / 失効
  7. 7. Confidential Computing
  8. 8. Sensitive Data Protection
  9. 9. Secret Manager
  10. 10. BigQuery 列/行レベル保護
  11. 11. Vertex AI セキュリティ
  12. 12. Cloud Storage 保護機能
  13. 13. OS Login / Shielded VM
  14. 14. リスク・落とし穴総まとめ
  15. 15. 設計チェックリスト

1. 暗号化の 3 層

PCSE で必ず問われる 3 層。保存中(at rest)と転送中(in transit)は Google が既定で自動暗号化。使用中(in use)は Confidential Computing でオプトイン。

暗号化の 3 層と既定の対応 at rest(保存中) 既定: AES-256 / KMS DEK&KEK 階層 in transit(転送中) 既定: TLS 1.3 / 内部は ALTS in use(使用中) オプトイン: Confidential VM / Space
図 1: 3 層と既定の対応。in use のみ顧客側でオプトイン。

2. Google 既定暗号化(DEK / KEK 階層)

公式仕様:データは DEK(Data Encryption Key) で暗号化、DEK は KEK(Key Encryption Key) で暗号化されて格納される。公式 既定暗号化

既定暗号化の階層 プレーンデータ DEK AES-256-GCM / chunk 単位で生成 KEK 既定では KEK は Google が管理(Workspace / Google Key Service) CMEK = KEK を Cloud KMS の鍵に切り替える EKM = KEK を顧客が外部に持つ(GCP は復号 API を呼ぶだけ) DEK は数 GB ごとに新規生成。鍵自体の漏洩リスクを最小化
図 2: DEK / KEK 階層。CMEK / EKM は KEK の所有権を変更する仕組み。

3. CMEK 詳細

Cloud KMS の鍵を KEK として使う方式。鍵のライフサイクル(作成 / ローテーション / 失効)を顧客が制御。公式 CMEK

Cloud KMS の階層

Cloud KMS └── KeyRing(リージョン or global) └── CryptoKey ├── purpose: ENCRYPT_DECRYPT / ASYMMETRIC_SIGN / VERIFY / MAC ├── algorithm: GOOGLE_SYMMETRIC_ENCRYPTION / RSA_SIGN_PSS_xxx 等 ├── protectionLevel: SOFTWARE / HSM / EXTERNAL / EXTERNAL_VPC ├── rotationPeriod: 例 P90D └── CryptoKeyVersion(v1, v2, ...) └── state: ENABLED / DISABLED / DESTROY_SCHEDULED / DESTROYED

Protection Level 4 種

Level鍵の場所認証使いどころ
SOFTWARECloud KMS(ソフトウェア)FIPS 140-2 Level 1一般的な要件
HSMCloud HSM(GCP 内 HSM)FIPS 140-2 Level 3金融 / 規制要件
EXTERNAL顧客の外部 KMS(インターネット経由)外部 KMS 次第鍵を GCP に預けない
EXTERNAL_VPC顧客の外部 KMS(プライベート経路)外部 KMS 次第+ プライベート接続要件

CMEK 対応の主要サービス

gcloud CMEK 鍵の作成と BigQuery への適用
# 1. KeyRing 作成(asia-northeast1 リージョン)
gcloud kms keyrings create finance-kr \
    --location=asia-northeast1

# 2. CryptoKey 作成、90 日でローテーション
gcloud kms keys create finance-key \
    --location=asia-northeast1 --keyring=finance-kr \
    --purpose=encryption \
    --protection-level=hsm \
    --rotation-period=90d \
    --next-rotation-time=2026-08-01T00:00:00Z

# 3. BigQuery service account に Encrypt/Decrypt 権限を付与
gcloud kms keys add-iam-policy-binding finance-key \
    --location=asia-northeast1 --keyring=finance-kr \
    --member=serviceAccount:bq-PROJECT@bigquery-encryption.iam.gserviceaccount.com \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

# 4. BigQuery テーブルを CMEK で作成
bq mk --table \
    --destination_kms_key=projects/PROJECT/locations/asia-northeast1/keyRings/finance-kr/cryptoKeys/finance-key \
    DATASET.TABLE
⚠️ CMEK 設定の落とし穴

4. Cloud HSM(FIPS 140-2 Level 3)

CMEK の Protection Level: HSM で利用できる、FIPS 140-2 Level 3 認証 のハードウェアセキュリティモジュール。鍵は HSM 外に出ない。公式 Cloud HSM

FIPS 認証
140-2 L3
物理的タンパー検知 + アイデンティティベース認証
対応操作
対称/非対称
AES-256-GCM / RSA / ECDSA
レイテンシ
+数ms
SOFTWARE より若干遅い
料金
~$1/key/mo
SOFTWARE の数倍

Cloud HSM の使いどころ

5. Cloud EKM 詳細

鍵を GCP の外(顧客のオンプレ KMS / Thales / Fortanix / Equinix / Futurex 等)に置く方式。GCP は復号 API を呼び出すだけ。公式 EKM

Cloud EKM の信頼チェーン GCP サービス BigQuery / Storage / 等 Cloud KMS プロキシ + 監査 External KMS 顧客 DC / 3rd party EXTERNAL = Public Internet 経由 / EXTERNAL_VPC = Interconnect 経由のプライベート ⚠️ 外部 KMS が落ちれば 全 GCP データが復号不能(DR 必須)
図 3: EKM フロー。外部 KMS が単一障害点になり得るので冗長化と監視が必須。

EKM サポートパートナー(一例)

⚠️ EKM 採用時の必須検討事項

6. 鍵ローテーション / 失効

ローテーション仕様

失効(destroy)のライフサイクル

CryptoKeyVersion のステート遷移 ENABLED DISABLED DESTROY_SCHEDULED 既定 30 日 DESTROYED disable destroy 期限 期限内に restore 可能
図 4: 鍵バージョンのステート遷移。destroy 後 30 日以内なら restore で復元可能。
✅ 鍵ライフサイクル運用

7. Confidential Computing

使用中(in use)暗号化。クラウド運用者・ハイパーバイザ・ホスト OS から VM メモリを保護。公式

3 つの形態

Confidential VM

AMD SEV / SEV-SNP / Intel TDX で VM メモリを暗号化。VM 起動時にチェックボックス 1 つ。性能オーバーヘッドは数%。

対応マシンタイプ:N2D / C2D / C3 / C3D 等

Confidential GKE Nodes

GKE Node Pool を Confidential VM 化。Pod の機密データもメモリ保護。

Confidential Space

TEE + Attestation。複数当事者の 合同計算(federated analytics)で互いの生データを見せずに処理。GA

Attestation の仕組み

Confidential Space の Workload は起動時に Attestation Verifierworkload_image / image_digest / environment を検証 → 信頼できる場合のみ鍵 / データを開放。

CEL Confidential Space + Cloud KMS の Attestation 条件
# 特定の image digest かつ specific service account の Workload のみ KMS 鍵を利用可
resource.type == "cloudkms.googleapis.com/CryptoKey"
&& has(request.auth.claims.google.compute_engine.confidential_space)
&& request.auth.claims.google.compute_engine.confidential_space.image_digest
   == "sha256:abc123def..."
&& request.auth.claims.google.compute_engine.confidential_space.workload_sa
   == "joint-compute@PROJECT.iam.gserviceaccount.com"

8. Sensitive Data Protection(SDP / 旧 Cloud DLP)

機微データの検出・分類・de-identify・再識別リスク解析を行う API/サービス。公式

主要機能

機能役割典型シナリオ
DiscoveryBigQuery / GCS / Cloud SQL を自動スキャン、機微データの所在をマップ化事業全体の PII リスク棚卸し
Inspection提供されたテキスト / 画像 / 構造化データから infoType を検出取り込み時の動的スキャン
De-identificationMask / Replace / Tokenize / FPE / Generalize / Bucketize分析者に PII を見せない
Re-identification risk analysisk-anonymity / l-diversity / t-closeness で再識別リスクを定量研究データ公開前の評価

De-identification 手法詳細

手法可逆性形式維持JOIN 維持説明
Redaction×××該当部分を完全削除
Replacement×××定型文字列に置換(例: [PHONE]
Masking××X 文字で置換、一部桁は残す
Crypto Hash××HMAC-SHA-256、決定論的
Crypto Deterministic×AES-SIV、鍵で復号可
FPE (FFX/FF1)形式維持で可逆、PCI-DSS 適合
Date Shift日付を相対オフセットでシフト
Bucketize / Generalize××連続値を範囲化

典型 infoType(一部)

EMAIL_ADDRESS PHONE_NUMBER CREDIT_CARD_NUMBER JAPAN_INDIVIDUAL_NUMBER JAPAN_DRIVERS_LICENSE_NUMBER IP_ADDRESS PERSON_NAME DATE_OF_BIRTH MEDICAL_RECORD_NUMBER US_SOCIAL_SECURITY_NUMBER

JSON Inspection + De-identify(Crypto Deterministic)の API リクエスト例
POST https://dlp.googleapis.com/v2/projects/PROJECT/locations/asia-northeast1/content:deidentify

{
  "item": { "value": "メール: alice@example.com / 電話: 090-1234-5678" },
  "deidentifyConfig": {
    "infoTypeTransformations": {
      "transformations": [{
        "infoTypes": [{"name":"EMAIL_ADDRESS"},{"name":"PHONE_NUMBER"}],
        "primitiveTransformation": {
          "cryptoDeterministicConfig": {
            "cryptoKey": {
              "kmsWrapped": {
                "wrappedKey": "BASE64_WRAPPED_KEY",
                "cryptoKeyName": "projects/.../cryptoKeys/dlp-tokenize"
              }
            },
            "surrogateInfoType": { "name": "TOKENIZED" }
          }
        }
      }]
    }
  },
  "inspectConfig": {
    "infoTypes": [{"name":"EMAIL_ADDRESS"},{"name":"PHONE_NUMBER"}]
  }
}
✅ SDP パイプライン設計の型

9. Secret Manager

パスワード / API キー / トークン / 証明書のマネージド管理。Cloud KMS とは別物(KMS は鍵管理、Secret Manager はシークレット管理)。公式

主要機能

gcloud シークレットの作成・アクセス
# 1. シークレット作成(自社管理レプリケーション)
gcloud secrets create db-password \
    --replication-policy=user-managed \
    --locations=asia-northeast1,us-central1

# 2. バージョン追加
echo -n "S3cure!Pass" | gcloud secrets versions add db-password --data-file=-

# 3. アプリの SA に最小権限付与
gcloud secrets add-iam-policy-binding db-password \
    --member=serviceAccount:app@PROJECT.iam.gserviceaccount.com \
    --role=roles/secretmanager.secretAccessor

# 4. アプリ起動時に取得
gcloud secrets versions access latest --secret=db-password
⚠️ Secret Manager の落とし穴

10. BigQuery 列 / 行レベル保護

列レベル:Policy Tags

  • Data Catalog の Taxonomy で機密度を分類(PII / FINANCIAL / PUBLIC 等)
  • 列に Policy Tag を付与
  • 各 Tag に対し roles/datacatalog.categoryFineGrainedReader を付与した人だけが列を見られる
  • Dynamic Data Masking:マスキング ルール(NULL / HASH / DEFAULT_MASKING_VALUE)を Tag に紐付け

行レベル:Row-Level Security

  • CREATE ROW ACCESS POLICY で SQL ベースのフィルタ条件
  • 例:「営業担当は自分の region の行のみ」
  • Policy 単位で許可ユーザー / グループを定義

Authorized View / Authorized Dataset

元テーブルへの直接権限なしで、ビューの結果のみ参照させる。SDP de-identify + Authorized View の組み合わせが 分析者向け公開 の標準。

11. Vertex AI セキュリティ

AI ワークロード保護は PCSE で新規追加された出題。公式 Vertex AI セキュリティ

セキュリティ機能

AI 固有の脅威と対策

脅威説明対策
学習データ漏洩training データに含まれる PII がモデル出力で再生成SDP で事前 de-identify、Differential Privacy、出力監視
モデル抽出攻撃API を大量呼び出してモデルを複製Cloud Armor で Rate Limit、認証 API 化、Confidence Score の制限
モデル反転攻撃出力から学習データを推定出力に対する SDP スキャン、ノイズ注入
プロンプトインジェクションユーザー入力で system prompt を上書き入力サニタイズ、system prompt と入力の分離、出力検証
データ汚染(poisoning)悪意ある training data を混入training データの整合性確認、ハッシュ検証、専用 SA

12. Cloud Storage 保護機能

Bucket Lock(Retention Policy)

  • バケット単位の保持期間(最長 100 年)
  • ロック後は 削除・短縮不可(延長のみ可)
  • SEC Rule 17a-4(f) / FINRA 4511(c) / CFTC 1.31 などの WORM 要件に対応

Object Holds

  • 個別オブジェクトに hold フラグ(temporary / event-based)
  • hold 解除まで削除不可
  • e-discovery / 訴訟ホールド用途

Object Versioning

  • 上書き / 削除をバージョンとして保持
  • ランサムウェア対策の基本
  • OLM(Object Lifecycle Management)で古いバージョンの自動削除

Signed URL / Signed Policy

  • 有効期限付き URL を発行
  • SA 鍵 ベース or IAM ベース(推奨)
  • HMAC キー ベースも可

13. OS Login / Shielded VM

OS Login

Shielded VM

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

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

15. 設計チェックリスト

📚 関連リソース