Trust & Security
with Google Cloud

責任共有モデル・ゼロトラスト・IAM・暗号化・ネットワークセキュリティ・コンプライアンス・データプライバシーまで、セキュリティの全体像を初学者向けに詳解します。

Section 5 Overview

Section 5 の全体像と学習ポイント

試験ガイドに基づく出題範囲と、多層防御アーキテクチャの全体像を把握しましょう。

5.1 クラウドセキュリティの基礎
責任共有モデル（Shared Responsibility）・ゼロトラスト / BeyondCorp・CIA トライアド・多層防御（Defense in Depth）の概念。
基礎概念
5.2 IAM とアクセス管理
Identity and Access Management・3 種のロール・最小権限の原則・サービスアカウントの安全管理・Cloud Identity。
IAM
5.3 暗号化とデータ保護
保存中・転送中・使用中の暗号化・Google-Managed Keys / CMEK / CSEK・Cloud KMS・Cloud HSM・Confidential Computing。
暗号化
5.4 ネットワークセキュリティ
Cloud Armor（DDoS/WAF）・Cloud IAP（ゼロトラスト）・VPC Service Controls（データ流出防止）・ファイアウォールルール。
ネットワーク
5.5 脅威検出・セキュリティ監視
Security Command Center・Cloud Audit Logs（4 種類）・Cloud IDS・Chronicle（SIEM）の役割と使い分け。
監視・検出
5.6 コンプライアンス・DLP
GDPR・HIPAA・PCI DSS・Sensitive Data Protection の保護手法（匿名化・仮名化・トークン化）とコンプライアンス認証。
コンプライアンス
📌 試験の重要ポイント：Section 5 は試験全体の約 17% を占めます。「誰が何に責任を持つか（責任共有モデル）」と「各セキュリティサービスの役割の違い」が特に頻出です。
多層防御（Defense in Depth）頻出
8
データ層
AES-256 暗号化（保存中・転送中・使用中）・Cloud KMS・CMEK・Sensitive Data Protection
7
アイデンティティ層
IAM・MFA・Cloud Identity・BeyondCorp・サービスアカウント管理・Workload Identity
6
アプリケーション層
脆弱性スキャン・Web Security Scanner・Binary Authorization（承認済みコンテナのみ実行）
5
エンドポイント層
Chrome Enterprise・BeyondCorp Enterprise・デバイス管理・Endpoint Verification
4
ネットワーク層
VPC・ファイアウォール・Cloud Armor（WAF/DDoS）・VPC Service Controls・Cloud IAP・Cloud NAT
3
インフラ層
Shielded VM・Confidential VM・OS Login・VM Manager（パッチ管理）
2
ストレージ層
保存データの暗号化（デフォルト AES-256）・CMEK・Cloud HSM
1
ハードウェア / DC 層
Titan チップ（改ざん防止）・物理セキュリティ（24/7 監視）・廃棄ドライブの物理破壊
📎 公式ソース
Cloud Digital Leader Exam Guide (Official PDF)https://cloud.google.com/security/overviewhttps://docs.cloud.google.com/docs/security/infrastructure/design
5.1 Shared Responsibility

責任共有モデル

Google とユーザーがセキュリティ責任をどう分担するかを理解します。サービスモデルによって境界線が変わります。

責任領域SaaS（例: Google Workspace）PaaS（例: Cloud SQL）IaaS（例: Compute Engine）
データ・コンテンツユーザーユーザーユーザー
ユーザー管理・IAMユーザーユーザーユーザー
アプリケーションGoogleユーザーユーザー
OS・ランタイムGoogleGoogleユーザー
仮想化・ハイパーバイザーGoogleGoogleGoogle
ネットワーク・ハードウェアGoogleGoogleGoogle
データセンター物理セキュリティGoogleGoogleGoogle

✅ Google が常に守るもの

  • データセンターへの物理的な侵入防止
  • ハードウェアの完全性（Titan チップ）
  • ネットワークインフラへの攻撃対策
  • ハイパーバイザーの脆弱性対応

⚠️ ユーザーが常に守るもの

  • 誰がデータにアクセスできるか（IAM 設定）
  • データの分類と適切な保護設定
  • アプリケーションのセキュリティ
  • エンドユーザーの認証・認可設定
⚠️ 試験頻出の引っかけ：「Google Cloud はセキュアだから、ユーザーは何もしなくていい」→誤り！データへのアクセス制御（IAM）・データの保護設定・アプリのセキュリティは常にユーザーの責任です。 Google はインフラを守りますが、データとアクセス管理はユーザーの責任です。
📎 参考ソース
Shared responsibilities and shared fate on Google Cloud（Cloud Architecture Center）Google Cloud Shared Fate
5.2 Zero Trust / BeyondCorp

ゼロトラストと BeyondCorp

「Never Trust, Always Verify（決して信頼せず、常に検証する）」という現代のセキュリティアーキテクチャの基本思想。

従来の境界型セキュリティ vs ゼロトラスト

❌ 従来の「城とお堀」モデル

  • 社内ネットワーク内にいる = 信頼できる
  • ファイアウォールで外部を遮断
  • 一度侵入されると内部を自由に移動（横移動）
  • テレワーク・クラウド時代には「社内」という概念が崩壊
  • 内部犯行・認証情報窃取に無防備

✅ ゼロトラスト（BeyondCorp）

  • ネットワークの場所は信頼の根拠にならない
  • アクセスのたびに「誰が・どのデバイスで・何に」を検証
  • リソースごとに最小限のアクセス権を付与
  • すべてのアクセスがログ記録される
  • デバイスの健全性・ユーザー認証・コンテキストを総合判断

Google の BeyondCorp 実装サービス

Cloud Identity-Aware Proxy（IAP）

VPN なしで社内アプリへのセキュアなアクセスを実現。アプリ単位でユーザーを認証・認可し、すべてのアクセスをログ記録。
ゼロトラストの中心

Context-Aware Access

場所・デバイス・時間帯などのコンテキストに応じてアクセスを制御。「管理されたデバイスからのみ本番へアクセス可」などを実装。
条件付きアクセス

BeyondCorp Enterprise

企業全体のゼロトラスト導入を支援するマネージドプラットフォーム。デバイス検証・ユーザー認証・アクセスポリシーを統合管理。
エンタープライズ
📎 参考ソース
Google Cloud: BeyondCorpCloud Identity-Aware Proxy (IAP) Documentation
5.3 Identity and Access Management

IAM（アイデンティティとアクセス管理）

「誰が（Who）・何に（Resource）・何ができるか（Permission）」を制御するクラウドセキュリティの中核システム。

PRINCIPAL / 主体（誰が）
  • 👤 Google アカウント（個人ユーザー）
  • 👥 Google グループ推奨
  • 🤖 サービスアカウント（アプリ・VM）
  • 🌐 Cloud Identity ドメイン
  • ⚠️ allUsers / allAuthenticatedUsers（公開設定 — 原則使用禁止）
ROLE / ロール（何ができるか）
非推奨基本ロール — Owner / Editor / Viewer
プロジェクト全体に広すぎる権限。本番環境では使用禁止。
推奨事前定義ロール
特定サービスに最適化。Google が管理・更新。
精密カスタムロール
必要な権限だけを独自に組み合わせ。最小権限の徹底実現。
RESOURCE / リソース（何に対して）
🏢 組織（Organization）— 全体に継承
📁 フォルダ（Folder）— 部門単位
📂 プロジェクト（Project）— アプリ単位
⚙️ 個別リソース（VM・バケット・DB）
⚠️ 権限は上位から下位へ継承。下位では取り消せない。

3 種類のロール詳細比較

種類権限の範囲管理主体推奨度使い所
基本ロール
Owner/Editor/Viewer		プロジェクト全体に広範な権限。非常に粗い粒度。Google本番禁止テスト環境・サンドボックスのみ
事前定義ロール
roles/bigquery.dataViewer		特定サービスの特定操作に最適化された細かい権限セットGoogle（自動更新）推奨ほとんどのユースケース
カスタムロールユーザーが個別権限を選んで組み合わせた独自ロールユーザー（手動管理）精密制御特殊なコンプライアンス要件

サービスアカウントの安全管理

❌ サービスアカウントキーの危険性

JSON キーファイルは有効期限なしの認証情報。漏洩すると攻撃者が任意の時間・場所から GCP にアクセス可能。コードリポジトリへの誤コミットが最大リスク。
組織ポリシーで禁止推奨：
constraints/iam.disableServiceAccountKeyCreation

✅ キーなしの代替認証手法

  • ①Application Default Credentials（ADC）
    — VM・Cloud Run は自動認証
  • ②Workload Identity（GKE）
    — Pod に SA を直接紐付け
  • ③Workload Identity Federation
    — AWS・GitHub Actions との連携（短期トークン）

✅ ベストプラクティス：IAM

  • 基本ロール（Owner/Editor/Viewer）は本番環境で絶対に使用しない。事前定義ロールを使う。
  • 個人ではなくグループにロールを付与する（メンバー変更時の管理効率化）。
  • 最小権限の原則：タスクに必要な最小限のロールのみを付与する。
  • IAM Recommender で過剰権限を定期的に検出・削除する。
  • サービスアカウントキーの作成を組織ポリシーで禁止し、ADC / Workload Identity を使用する。
  • Admin Activity 監査ログで権限変更を継続的に監視する。
📎 参考ソース
Cloud IAM overviewIAM best practicesService Accounts overviewWorkload Identity Federation
5.4 Encryption & Data Protection

暗号化とデータ保護

データの 3 つの状態での暗号化と、Cloud KMS による鍵管理オプションを理解します。

データの 3 つの状態と暗号化

①
保存中（Data at Rest）
ストレージ（ディスク・データベース）に保存された状態のデータ。例：Cloud Storage・BigQuery・Persistent Disk のデータ。
Google のデフォルト：AES-256 で全データを自動暗号化（追加設定・費用不要）
②
転送中（Data in Transit）
ネットワーク経由で移動中のデータ。例：ブラウザから Cloud Storage へのアップロード・サービス間 API 通信。
Google のデフォルト：TLS 1.2 以上で全通信を自動暗号化。内部通信は ALTS を使用。
③
使用中（Data in Use）
メモリ（RAM）上で処理されている状態のデータ。従来は平文のままだった唯一の状態。
Confidential VM・Confidential GKE Nodes で AMD SEV 技術を使いメモリも暗号化。
🔑 重要な試験ポイント：Google Cloud は保存中・転送中のデータを追加設定なしでデフォルト暗号化します。 「使用中」のデータを暗号化するのはConfidential VM の特徴です（AMD SEV 技術）。

Cloud KMS：暗号鍵管理の 3 段階

管理方式鍵の管理主体コスト主なユースケース使用例
🔑 Google-Managed Keys
（デフォルト）		Google が自動管理・ローテーション無料一般的なワークロード。追加設定不要。ほとんどのケースで十分
🗝️ CMEK
Customer-Managed Encryption Keys		ユーザーが Cloud KMS で管理。鍵の無効化・削除をユーザーが制御。KMS 利用料規制業界（金融・医療・政府）。鍵を無効化するとデータへのアクセス不可。コンプライアンス必須の場合
🔐 CSEK
Customer-Supplied Encryption Keys		ユーザーが Google Cloud 外で鍵を管理。リクエストのたびに提供。高い管理コスト鍵を Google に一切渡したくない最高セキュリティ要件。極めて機密性の高いデータ

Cloud HSM

FIPS 140-2 Level 3 認証のハードウェアセキュリティモジュール。物理的に改ざん困難なハードウェアで鍵を保護。PCI DSS・HIPAA 等の規制で必要な場合。
最高レベル保護

Confidential VM

処理中（メモリ上）のデータも暗号化。AMD SEV（Secure Encrypted Virtualization）技術を使用。Google のハイパーバイザーもメモリを読めない。
使用中も保護

Secret Manager

API キー・パスワード・証明書などの機密情報を安全に管理。コードへのハードコード禁止。バージョン管理・アクセス制御・監査ログ付き。
シークレット管理

✅ ベストプラクティス：暗号化

  • 一般ワークロード → Google-Managed Keys（デフォルト・無料）で十分。
  • 規制対応（金融・医療・GDPR）→ CMEK で Cloud KMS により鍵をユーザー管理する。
  • 鍵を Google に渡したくない極秘要件 → CSEK（管理コストと要件を慎重に評価）。
  • 処理中のデータも保護が必要 → Confidential VM を使用。
  • API キー・パスワードはコードに直書きせず、必ずSecret Manager を使用。
📎 参考ソース
Default encryption at restCloud KMS documentationConfidential VM documentationSecret Manager documentation
5.5 Network Security

ネットワークセキュリティ

Cloud Armor・Cloud IAP・VPC Service Controls の役割の違いを正確に理解することが試験の鍵です。

Cloud Armor

DDoS 防御 + WAF（Web Application Firewall）
グローバルロードバランサーの手前でトラフィックをフィルタリング。Google のグローバルネットワークのエッジで攻撃を遮断。
  • L3/L4 DDoS を自動的に検知・緩和
  • OWASP Top 10 の WAF ルールを適用
  • IP・地域ベースのブロック・レート制限
  • Adaptive Protection（ML で攻撃自動検出）
外部攻撃を防御

Cloud IAP（Identity-Aware Proxy）

VPN 不要のゼロトラストアクセス制御
アプリ単位で認証・認可を実施。すべてのアクセスをログ記録。
  • VPN なしで社内アプリへセキュアアクセス
  • アクセスのたびに Google 認証 + MFA
  • IAM で誰がアクセスできるかを細かく制御
  • SSH・RDP への TCP トンネリングにも対応
ゼロトラスト実装

VPC Service Controls（VPC SC）

データ流出（Exfiltration）防止の境界線
GCP サービスの周囲にセキュリティ境界を作成。たとえ認証情報を盗まれても境界外からのアクセスをブロック。
  • BigQuery・Cloud Storage 等の周りに境界
  • 認証情報盗難後の外部コピーを物理的にブロック
  • 本番適用前に Dry Run モードで影響確認
データ流出防止
⚠️ 試験頻出：3 サービスの役割の違い
Cloud Armor：外部からの攻撃（DDoS・WAF）をブロックする → 外部攻撃防御
Cloud IAP：アクセスのたびに認証・認可する → ゼロトラストアクセス制御
VPC Service Controls：データを境界内に閉じ込める → 内部からのデータ流出防止

✅ ベストプラクティス：ネットワークセキュリティ

  • すべての本番 ALB（Application Load Balancer）にCloud Armor を設定する。
  • SSH・RDP へのアクセスはCloud IAP 経由のみに限定し、VPN・外部 IP を不要にする。
  • 機密データを含む BigQuery・Cloud Storage にはVPC SC を適用する（Dry Run で確認後に本番適用）。
  • VM に外部 IP を付けず、Cloud NAT でアウトバウンドのみを確保する。
  • VPC フローログを有効化してネットワークトラフィックを記録・監査する。
📎 参考ソース
Cloud Armor documentationIdentity-Aware Proxy documentationVPC Service Controls documentation
5.6 Threat Detection & Security Monitoring

脅威検出とセキュリティ監視

Security Command Center・監査ログの 4 種類・Cloud IDS・Chronicle の役割と使い分けを理解します。

Cloud 監査ログの 4 種類最重要

ログ種別記録内容デフォルト料金保持期間
① Admin Activity
（管理アクティビティ）		リソース作成・削除・IAM 変更・設定変更など「設定を変えた」操作常に有効
無効化不可		無料400 日
② Data Access
（データアクセス）		BigQuery クエリ・Cloud Storage ダウンロードなど「データを読み書きした」操作デフォルト無効
要有効化		有料（大量）30 日
③ System Event
（システムイベント）		Google システムによる自動操作（ライブマイグレーション・自動スケーリング等）常に有効無料400 日
④ Policy Denied
（ポリシー拒否）		VPC Service Controls でブロックされたアクセスの記録要有効化有料30 日
⚠️ 試験頻出の区別：Admin Activity（管理アクティビティ）は「設定を変えた」操作 → 常に有効・無料。Data Access（データアクセス）は「データを読み書きした」操作 → デフォルト無効・有効化が必要・有料。 機密データを扱うサービスでは必ず Data Access ログを有効化する。

Security Command Center（SCC）

🎯 SCC が自動検出するもの

設定ミス（Misconfiguration）
公開されている Cloud Storage バケット・外部 IP の不適切な VM・弱いファイアウォールルール・MFA が未設定の特権ユーザー
アクティブな脅威
マルウェアの実行・異常な API コール（クリプトマイニング）・侵害された認証情報の利用・データ流出の試み
脆弱性
脆弱なソフトウェアバージョン・CVE（既知の脆弱性）・コンテナイメージの脆弱性

🔍 他のセキュリティツールとの違い

SCC
GCP 全体の脅威・設定ミス・脆弱性を一元可視化するダッシュボード。CSPM（Cloud Security Posture Management）。
Cloud IDS
ネットワークトラフィックを監視・検知（アラートのみ）。Palo Alto 脅威インテリジェンス活用。
Chronicle
Google スケールの SIEM / SOAR。ペタバイトのセキュリティログを超高速分析。脅威ハンティング。

✅ ベストプラクティス：セキュリティ監視

  • 機密データを扱うサービスではData Access 監査ログを必ず有効化する。
  • ログシンクで BigQuery へエクスポートして長期保存・SQL 分析を可能にする。
  • Security Command Centerを有効化してセキュリティ状況を継続的に自動スキャンする。
  • SCC の検出結果（Findings）に対するアラートを設定し、高リスク項目を迅速に修正する。
  • Cloud Armor + Cloud IDS の組み合わせで「ブロック」と「監視」の多層防御を構築する。
📎 参考ソース
Security Command Center documentationCloud Audit Logs documentationCloud IDS documentation
5.7 Compliance & Regulations

コンプライアンスと規制対応

GDPR・HIPAA・PCI DSS の要点と、Google Cloud のコンプライアンス認証・支援サービスを理解します。

GDPR
EU 一般データ保護規則
EU 居住者のデータを扱う全企業に適用（EU 外の企業も対象）。
削除権・アクセス権・ポータビリティ権。
違反時は最大 2,000 万ユーロ or 売上の 4%。
EU データ保護
HIPAA
米国医療情報保護法
PHI（医療情報）を扱う米国の医療機関・保険会社に適用。
Google Cloud は BAA（Business Associate Agreement）を提供。
Cloud Healthcare API が HIPAA 対応。
医療情報保護
PCI
DSS
クレジットカード業界基準
カード情報を扱う全企業に適用。Visa / Mastercard 等が策定。
Google Cloud の多くのサービスが PCI DSS Level 1 認定。
暗号化・アクセス制御・監査ログが要件。
決済セキュリティ
ISO
27001
情報セキュリティ管理
情報セキュリティ管理の国際規格。
ISO 27017（クラウドセキュリティ）
ISO 27018（クラウド個人情報保護）
Google Cloud は認証取得済み。
国際規格

📑 Compliance Reports Manager

Google Cloud のコンプライアンス認証文書（SOC レポート・ISO 認証書等）をセルフサービスでダウンロードできるツール。監査担当者への証拠提出が数分で完了。

🔒 Assured Workloads

規制要件（FedRAMP・HIPAA 等）に適合した論理的な境界をクリックで構築。データ保管地域の強制・担当者アクセス制限・暗号化コントロールを自動化。
コンプライアンス自動化
🌏 データ主権とリージョン選択：EU のデータは EU リージョン（europe-west1等）、日本のデータは日本リージョン（asia-northeast1 東京）に保管。 組織ポリシーconstraints/gcp.resourceLocationsで指定リージョン以外でのリソース作成を禁止することで GDPR 等のデータ主権要件に対応できます。
📎 参考ソース
Google Cloud Security & ComplianceGDPR on Google CloudPCI DSS on Google Cloud
5.8 Data Privacy & Sensitive Data Protection

データプライバシーと Sensitive Data Protection

匿名化・仮名化・トークン化の違い（再識別可否・GDPR 適用有無）が試験で最も問われるポイントです。

Sensitive Data Protection（旧 Cloud DLP）とは：テキスト・画像・構造化データ内の機密情報を自動検出・分類・保護するサービス。 150 以上の組み込み情報タイプ（PII・医療情報・認証情報など）に対応。

7 つの保護手法

① 検出
どこに機密データがあるかを発見するだけ。BigQueryの全テーブルをスキャンして PII を含む列を特定。
変更なし → 場所の把握のみ
② マスキング
一部を「*」や「X」で置き換え。末尾のみ表示などで必要最小限を残す。
090-1234-5678 → ***-****-5678
③ 仮名化 ⚠️
識別子を仮の識別子に置換。変換テーブルで元に戻せる（再識別可能）。GDPR 引き続き適用。
田中太郎 → UID-a7f3k
④ 匿名化 ✅
識別情報を完全に除去・元に戻せない。GDPR 規制対象外になる。研究データの公開に最適。
田中太郎・渋谷区 → 30代男性・東京都内
⑤ トークン化
値をランダムなトークンに置換。同じ形式・長さを保つことも可能。PCI DSS のカードデータに最適。
4111-xxxx → TOKEN-ab3f8x
⑥ 暗号化
暗号化キーで暗号化。鍵があれば復号可能。鍵管理が重要。Cloud KMS と組み合わせる。
090-1234-5678 → 3f8a…9d2c
⑦ 日付シフト
日付をランダムにずらす。統計的特性を保ちつつ個人を特定できなくする。医療・研究データに活用。
2024-01-15 → 2024-03-27（±数ヶ月）
⚠️ 試験の超頻出：匿名化 vs 仮名化の違い
匿名化（Anonymization）：再識別不可能 → GDPR 規制対象外。データを公開・共有したい場合。
仮名化（Pseudonymization）：変換テーブルで再識別可能 → GDPR 引き続き適用。開発・テスト環境で本番データを使いたい場合。

開発・テスト環境

本番データを使う必要がある場合 →仮名化
元データへの変換が可能なため、後から正式データでの検証もできる

データの公開・研究利用

外部に公開・第三者と共有する場合 →匿名化
GDPR 対象外になるため、規制の制約なしに活用できる

PCI DSS・決済データ

クレジットカード番号の保護 →トークン化
同じ形式・長さを維持しつつ実際のカード番号を隠蔽
📎 参考ソース
Sensitive Data Protection ドキュメント仮名化（DLP）ガイドGoogle Cloud プライバシーセンター
Exam Preparation

試験直前チェックリスト＆頻出パターン

Section 5 の重要ポイントを確認し、頻出問題パターンで理解を深めましょう。

基礎・責任共有・ゼロトラスト
✓
責任共有モデルで Google とユーザーがそれぞれ何に責任を持つか説明できる
✓
ゼロトラスト・BeyondCorp の「ネットワーク内でも信頼しない」概念を説明できる
✓
多層防御（Defense in Depth）の 8 層を大まかに説明できる
✓
Cloud IAP が「VPN 不要のゼロトラストアクセス制御」であることを説明できる
IAM
✓
基本ロール（Owner/Editor/Viewer）を本番環境で使ってはいけない理由を説明できる
✓
事前定義ロール・カスタムロールの違いと使い分けを説明できる
✓
サービスアカウントキーのリスクと ADC・Workload Identity の代替手法を説明できる
✓
最小権限の原則の重要性を説明できる
暗号化・ネットワーク
✓
暗号化の 3 状態（保存中・転送中・使用中）と Google のデフォルト対応を説明できる
✓
Google-Managed / CMEK / CSEK の違いと選択基準を説明できる
✓
Confidential VM が「使用中のデータも暗号化」することを説明できる
✓
Cloud Armor・Cloud IAP・VPC SC の役割の違いを即答できる
監視・コンプライアンス・DLP
✓
監査ログの 4 種類（Admin Activity / Data Access / System Event / Policy Denied）を説明できる
✓
Admin Activity（常時有効・無料）と Data Access（要有効化・有料）の違いを説明できる
✓
匿名化（再識別不可・GDPR 対象外）と仮名化（再識別可能・GDPR 対象）の違いを説明できる
✓
GDPR・HIPAA・PCI DSS の概要とそれぞれの適用対象を説明できる

頻出問題パターンと解法

01
責任共有モデル
「Cloud SQL を使用する企業で顧客の個人情報が漏洩した。Google と企業はそれぞれ何に責任を持つか？」
  1. Cloud SQL は PaaS → OS・エンジンは Google が管理
  2. データへのアクセス制御（IAM）はユーザーの責任
  3. 個人情報の内容・アクセス管理はユーザーの責任
Google はインフラ保護、企業はデータとアクセス管理に責任
02
暗号化鍵の選択
「金融機関が GCP に顧客データを保存。規制で『鍵は自社が管理しなければならない』と定められている。」
  1. 「自社が鍵を管理」→ Google-Managed では不可
  2. Cloud KMS でユーザーが鍵を作成・管理 → CMEK が適切
  3. CSEK は管理コストが高い・今回は不要
答え：CMEK（Customer-Managed Encryption Keys）+ Cloud KMS
03
匿名化 vs 仮名化
「医療研究機関が患者データを研究に使用したい。患者を特定できないようにしつつ GDPR 規制対象外にしたい。」
  1. GDPR 対象外にしたい → 再識別不可能であること
  2. 仮名化は再識別可能 → GDPR 引き続き適用される
  3. 匿名化は再識別不可能 → GDPR 対象外になる
答え：匿名化（Anonymization / De-identification）
04
VPC SC の活用
「BigQuery に機密データを保存。社員のアカウントが侵害されても、外部プロジェクトへのデータエクスポートを防ぎたい。」
  1. 認証情報が盗まれても境界外へのデータ移動を防ぎたい
  2. ファイアウォールや IAM だけでは認証情報盗難後は防げない
  3. VPC SC がデータの外部流出を境界で防止する
答え：VPC Service Controls（データ流出防止）

混同しやすいポイントの整理

混同パターン✅ 正しい理解
Cloud Armor = Cloud IAPCloud Armor は外部攻撃（DDoS/WAF）をブロック。Cloud IAP はアクセスのたびに認証・認可するゼロトラスト実装。
CMEK = CSEKCMEK は Cloud KMS に鍵を保管（ユーザーが管理）。CSEK は GCP 外で管理（リクエストのたびにユーザーが提供）。
匿名化 = 仮名化匿名化は再識別不可（GDPR 対象外）。仮名化は変換テーブルで再識別可能（GDPR 引き続き適用）。
Admin Activity = Data Access ログAdmin Activity は「設定変更」（常時有効・無料）。Data Access は「データの読み書き」（デフォルト無効・有料）。
VPC SC = ファイアウォールファイアウォールは L4 の通信制御。VPC SC は認証済みアクセスも含む API アクセスの境界制御（データ流出防止）。
SCC = Cloud LoggingSCC は脅威・設定ミスの可視化と検出。Cloud Logging はログの収集・保存・分析基盤。
Google が全て守るGoogle はインフラを守るが、データとアクセス管理（IAM）はユーザーの責任（責任共有モデル）。