この記事でわかること
- シラバス全5セクションの重要ポイントを網羅した解説
- 試験で問われやすい「サービスの使い分け」と「紛らわしい選択肢」の整理
- 各セクションの出題比率と優先度
- 試験直前30分の確認チェックリスト
この記事の使い方
この記事は、Professional Cloud Security Engineer(以降 PCSE)試験の全体像の把握や、試験直前の最終チェックにご利用いただくことを想定しております。本記事と併せて、公式ドキュメントや模擬試験での学習をしていただくことを強く推奨いたします。
試験の基本情報
試験形式
| 項目 | 内容 |
|---|---|
| 問題数 | 60問(多肢選択式・複数選択式) |
| 試験時間 | 120分 |
| 受験料 | $200 USD(税別) |
| 受験方法 | オンライン(遠隔監視)または認定テストセンター |
セクション別出題比率
| セクション | テーマ | 出題比率 |
|---|---|---|
| Section 1 | アクセスの構成 | 約25% |
| Section 2 | 通信のセキュリティと境界保護 | 約20% |
| Section 3 | データ保護 | 約23% |
| Section 4 | 運用管理 | 約20% |
| Section 5 | コンプライアンス要件のサポート | 約12% |
出題比率から見た優先度
Section 1・2・3の合計が約70%を占めます。この3セクションを確実に押さえることが合格への最短経路です。
Section 1:アクセスの構成(約25%)
Section 1は最も出題比率が高いセクションです。IAM・サービスアカウント・ID管理の3本柱を中心に、実際の設定操作に関する問題が頻出します。
1-1. Cloud Identityとアイデンティティの管理
3つのID管理アプローチの使い分け
Google Cloud Directory Sync(GCDS)
オンプレミスのActive DirectoryやLDAPからCloud Identityにユーザー・グループを同期するツールです。同期は**一方向(オンプレミス→Google Cloud)**であり、Cloud Identity側のデータを上書きすることはありません。ユーザーをCloud Identityに「プロビジョニング」したい場合に使います。
Workforce Identity Federation
外部IDプロバイダー(Azure AD、Okta、SAML 2.0対応IdP、OIDC対応IdP)を使い、Cloud Identityへのユーザーの同期なしにGoogle Cloudへの認証を実現します。ユーザーを新たにGoogle Cloudに作成したくない場合、または既存のIdPをそのまま使いたい場合に選択します。
ここが出る
- GCDS:同期あり。Cloud Identityにユーザーが作成される
- Workforce Identity Federation:同期なし。既存のIdPで直接認証
スーパー管理者アカウントの管理
- 通常業務には使用しない(専用の業務アカウントを別途用意する)
- ハードウェアセキュリティキー(Titan Security Keyなど)を使った2段階認証を必須にする
- バックアップの回復用アカウントを複数用意しておく
1-2. サービスアカウントの管理
サービスアカウントのベストプラクティス
デフォルトサービスアカウント
Compute EngineやApp Engineには、プロジェクト作成時にデフォルトのサービスアカウントが自動生成されます。このデフォルトSAにはEditor権限が付与されており、権限が広すぎます。本番環境では必ず権限を削減するか、デフォルトSAの使用自体を無効化することを検討します。
サービスアカウントキーの扱い
サービスアカウントキー(JSON形式)は長期有効な認証情報であり、漏洩リスクが高いです。可能な限り使用を避け、以下の代替手段を選びます。
| ユースケース | 代替手段 |
|---|---|
| GKE上のワークロード | Workload Identity Federation for GKE |
| GCP外部のワークロード(GitHub Actions、AWS、Azureなど) | Workload Identity Federation |
| GCP内のリソース間 | サービスアカウントの権限を直接付与 |
Workload Identity Federation(WIF)
非Googleクラウドのワークロード(オンプレミス、AWS、GitHub Actionsなど)がサービスアカウントキーを使わずにGoogle CloudのAPIを呼び出せる仕組みです。Workload Identity Poolを作成し、外部IdP(OIDC・SAML)からのトークンをGoogle Cloudの認証情報に交換します。
Workload Identity Federation for GKE
GKEのKubernetesサービスアカウントをGoogle Cloudのサービスアカウント(またはIAMプリンシパル)に直接マッピングします。2024年以降のアップデートにより、KubernetesのワークロードをIAMポリシーで直接参照できるようになり、構成がシンプルになりました。
紛らわしいポイント:Workload Identity Federation vs Workload Identity Federation for GKE
- WIF:GCP外部のワークロード向け(AWS、GitHub Actionsなど)
- WIF for GKE:GKEクラスタ内のKubernetesワークロード向け
短期的な認証情報(Short-lived credentials)
サービスアカウントの権限を借用(Impersonation)し、一時的なアクセストークン(有効期限:最大1時間)を発行できます。roles/iam.serviceAccountTokenCreator ロールを付与したプリンシパルが generateAccessToken APIを呼び出すことで取得できます。
1-3. 認証の管理
2段階認証(2SV)の強度
セキュリティの強い順:ハードウェアセキュリティキー > Google Authenticator > SMS(最も弱い)
ハードウェアセキュリティキーはフィッシング耐性があり、フィッシング攻撃によるアカウント乗っ取りを防ぐ観点から最も推奨されます。
SAML vs OAuth 2.0
| プロトコル | 用途 | 役割 |
|---|---|---|
| SAML 2.0 | 認証(Authentication) | IdPがSPに「このユーザーは誰か」を証明 |
| OAuth 2.0 | 認可(Authorization) | 「このアプリが何をできるか」のスコープを定義 |
1-4. 認可コントロールの管理と実装
IAMの基本構造
IAMロールの種類
| 種類 | 説明 | 推奨 |
|---|---|---|
| 基本ロール(Primitive) | Owner / Editor / Viewer。権限が広すぎる | 本番では使用を避ける |
| 事前定義ロール(Predefined) | サービス別の細かいロール | 最小権限の原則に沿った推奨選択肢 |
| カスタムロール(Custom) | プロジェクトまたは組織レベルで作成 | 必要な権限だけを組み合わせる |
IAM Deny ポリシー
DenyポリシーはAllowポリシーより優先して評価されます。Ownerロールを持っていても、Denyポリシーで特定の操作が拒否されていればその操作は実行できません。権限昇格の防止や、特定の操作を組織全体で禁止したい場合に有効です。
IAM Conditions
属性ベースのアクセス制御です。以下の属性に基づいて条件付きでアクセスを許可/拒否できます。
- リソース名・リソースタイプ
- リクエスト時刻(時間帯制限)
- リクエスト元IPアドレス
Access Context Manager
VPC Service Controlsと組み合わせて使うアクセス制御サービスです。以下の属性に基づいて「アクセスレベル」を定義します。
- デバイスの信頼レベル(OSバージョン・パッチ状況・企業管理デバイスかどうか)
- 送信元IPアドレス範囲
- ユーザーのアイデンティティ
Policy Intelligence
IAM設定の分析・最適化ツール群です。
| ツール | 役割 |
|---|---|
| Policy Analyzer | 誰がどのリソースにアクセスできるかを可視化 |
| Policy Troubleshooter | 特定のアクセスが許可/拒否される理由を診断 |
| Policy Simulator | ポリシー変更を適用前にシミュレーション |
| IAM Recommender | 実際の使用状況に基づいた最小権限ロールを推薦 |
Privileged Access Manager(PAM)
Just-in-Time(JIT)型の特権アクセス管理です。
- アクセス時に申請・承認フローを通じて一時的な権限を付与
- 付与は時間制限付き(期限が来ると自動で権限が失効)
- アクセス理由の記録(監査証跡)
1-5. リソース階層の定義
リソース階層と権限継承
組織(Organization)
└─ フォルダ(Folder)
└─ プロジェクト(Project)
└─ リソース(Resource)
IAMポリシーは上位から下位へ継承されます。上位レベルで付与した権限は、下位レベルのすべてのリソースに適用されます。
Orgポリシー(組織ポリシー)
IAMとは異なり、リソースの設定や動作を制限するポリシーです。
- 例:
constraints/compute.requireOsLogin(全VMにOS Login必須) - 例:
constraints/compute.restrictCloudDNSPolicy(外部DNSの制限) - カスタム組織ポリシー:CEL(Common Expression Language)式で独自の制約を作成可能
- ポリシーは下位に継承されるが、特定のフォルダ/プロジェクトでオーバーライドも可能(制約の種類による)
Section 2:通信のセキュリティと境界保護(約20%)
ネットワークセキュリティサービスの使い分けが頻出です。「どのレイヤーで何を守るか」の整理が重要です。
2-1. 境界セキュリティの設計と構成
ネットワークセキュリティサービスの使い分け
Cloud NGFW(Next Generation Firewall)
VPCネットワーク内のトラフィックを制御するファイアウォールです。
- L3/L4:送信元/宛先IP・ポート・プロトコルに基づいたフィルタリング
- L7(アプリケーション層)インスペクション:HTTPSのTLS復号、URLフィルタリング、アプリケーション識別(高度な機能)
- 階層型ファイアウォールポリシー:組織・フォルダレベルで統一ルールを設定可能
- 優先度が低い数値ほど先に評価(例:優先度100は優先度1000より先に評価)
Cloud Armor
HTTP(S)ロードバランサーの前段に配置するWAF(Web Application Firewall)とDDoS対策サービスです。
- IPアドレス・地理情報・カスタム式に基づくルール
- 事前設定済みWAFルール(ModSecurity Core Rule Setベース)でよくある攻撃(SQLi、XSSなど)を防御
- Adaptive Protection:機械学習を用いたDDoS攻撃の自動検出・遮断
紛らわしいポイント:Cloud Armor vs Cloud NGFW
- Cloud Armor:HTTP(S)ロードバランサーレベル(Layer 7)。Webアプリ向け
- Cloud NGFW:VPCレベルのトラフィック制御(Layer 3/4、オプションでLayer 7)
Identity-Aware Proxy(IAP)
VPNを使わずにWebアプリ・SSH/TCPへのゼロトラストアクセスを実現します。すべてのアクセスリクエストに対してGoogleのアイデンティティ確認と認可チェックを行います。社内ツールをパブリックインターネット上に置きながら安全にアクセス制御できます。
Certificate Authority Service(CA Service)
マネージドなプライベートCA(PKI)サービスです。内部サービス間のTLS通信のための証明書を発行・管理します。オンプレミスのプライベートCAをGoogle Cloudに移行するユースケースでも使われます。
Secure Web Proxy
アウトバウンドのWebトラフィック(HTTP/HTTPS)をフィルタリングするプロキシサービスです。VPCから外部へのアクセスを制御したい場合に使用します。
2-2. 境界セグメンテーションの構成
Shared VPC(共有VPC)
ホストプロジェクトがVPCを提供し、複数のサービスプロジェクトが共有して使用します。ネットワーク管理を一元化できます。
- 組織レベルの権限:Shared VPC管理者
- サービスプロジェクトに付与するロール:
compute.networkUser
VPC Peering
2つのVPC間でプライベート接続を確立します。
- 推移的ピアリングは非対応(A-B-Cのピアリングで、AとCは通信できない)
- ピアリングするVPC間でIPアドレス範囲が重複していてはいけない
VPC Service Controls
Google管理サービス(BigQuery、Cloud Storageなど)の周囲にセキュリティ境界(サービス境界)を設けます。有効なGoogle認証情報を持っていても、境界外からはアクセスできません。
| 構成要素 | 説明 |
|---|---|
| サービス境界(Service Perimeter) | どのプロジェクト・サービスを囲むかを定義 |
| アクセスレベル(Access Level) | 境界外から境界内にアクセスできる条件(Access Context Managerで定義) |
| ブリッジ境界 | 2つのサービス境界を接続する |
| ドライランモード | 違反をログに記録するが実際には拒否しない。本番適用前の影響確認に使用 |
紛らわしいポイント:VPC Firewall vs VPC Service Controls
- VPC Firewall:ネットワークトラフィック(IP/ポート)を制御
- VPC Service Controls:Google管理サービスへのAPI呼び出しを制御(認証情報があっても拒否できる)
2-3. プライベート接続の確立
プライベートGoogle API接続の整理
| 接続方式 | 概要 | 特徴 |
|---|---|---|
| Private Google Access | サブネット設定。外部IPなしのVMがGoogle APIにアクセス | サブネットレベルで有効化 |
| Restricted Google Access |
restricted.googleapis.com(199.36.153.4/30)経由 |
VPC Service Controls対応APIのみ。データ持ち出し防止 |
| Private Service Connect | VPC内にプライベートエンドポイントを作成 | 最も細かいアクセス制御が可能 |
HA VPN
サイト間VPN。99.99%のSLAを持つ高可用性VPNです。IKEv2/IPsecで暗号化されます。Google側には2つの外部IPが自動割り当てられ、顧客側も2つの外部IPを持つVPNゲートウェイが必要です。
Cloud Interconnect
物理的な専用線接続です。
| 種類 | 内容 |
|---|---|
| Dedicated Interconnect | 10Gbps/100Gbpsの物理光ファイバー。Googleデータセンターと顧客施設を直結 |
| Partner Interconnect | サービスプロバイダー経由。50Mbps〜10Gbps |
重要:Cloud Interconnectは暗号化なし
Dedicated InterconnectおよびPartner Interconnect自体はデフォルトでは暗号化されません。トラフィックを暗号化したい場合は、InterconnectをトランスポートとしてCloud VPNを重ねて使用するか、MACsecを利用します。
Cloud NAT
外部IPを持たないプライベートVMがアウトバウンドのインターネットアクセスを行うためのNATゲートウェイです。リージョンリソースであり、インバウンドの接続は許可しません。
Section 3:データ保護(約23%)
Section 1と並んで高い出題比率です。暗号化の種類の選択と、SDP(Sensitive Data Protection)の変換方法が特に重要です。
3-1. 機密データの保護とデータ損失の防止
Sensitive Data Protection(SDP)
旧称:Cloud DLP(Data Loss Prevention)。機密データを検出・分類・マスキングするサービスです。
InfoType
SDP組み込みの検出器です。電話番号、メールアドレス、クレジットカード番号、SSNなど、一般的なPIIを自動検出します。カスタムInfoTypeの作成も可能です。
SDPの変換(De-identification)方法の使い分け
| 方法 | 説明 | 可逆性 |
|---|---|---|
| Redaction(削除) | 検出した値を完全に削除 | 不可逆 |
| Masking(マスキング) | 文字を別の文字(例:×)に置換。例:12345678 → XXXXXXXX
|
不可逆 |
| Format-Preserving Encryption(FPE) | 暗号化後も元のデータと同じ形式(桁数・文字種)を保つ | 可逆(鍵あり) |
| Pseudonymization(仮名化) | 暗号鍵を使いトークンに置換。元の値に戻すことができる | 可逆 |
| Tokenization(トークン化) | 乱数トークンに置換。元の値への参照テーブルを別管理 | 可逆(テーブルあり) |
| Date Shifting(日付シフト) | 日付を一定のランダム量だけ移動させる | 不可逆 |
Secret Manager
APIキー、パスワード、証明書などの機密情報を安全に保存・管理するサービスです。
- シークレットはバージョン管理される
-
roles/secretmanager.secretAccessorロールでアクセスを制御 - Cloud Functions・Cloud Run・GKEからPodアノテーションで利用可能
- レプリケーション:自動(Googleが管理)またはユーザー管理(特定リージョンを指定)
3-2. 暗号化の管理
暗号化オプションの選択基準
| 方式 | 鍵管理 | 対応サービス | 特徴 |
|---|---|---|---|
| GMEK(Google-managed) | Googleが管理 | ほぼすべて | 追加コストなし。デフォルト |
| CMEK(Customer-managed) | Cloud KMSで顧客が管理 | BigQuery、Cloud Storage、Compute Engine、Cloud SQLなど幅広い | 鍵の失効でデータアクセス不能 |
| CSEK(Customer-supplied) | 顧客が生の鍵素材を提供 | Cloud StorageとCompute Engineのみ | APIリクエストごとに鍵を提供 |
| EKM(External Key Manager) | 外部キー管理システム(HSMなど) | 限定的 | 鍵がGoogleのインフラ上に存在しない |
紛らわしいポイント:CMEK vs CSEK
- CMEK:Cloud KMS上で鍵を管理。対応サービスの幅が広い
- CSEK:生の鍵素材を毎回提供。Cloud StorageとCompute Engineのみ対応
Cloud KMSの主要概念
- キーリング(Key Ring):鍵の論理的なグループ(リージョン単位)
- 暗号化鍵(CryptoKey):バージョン管理されている
- ソフトウェアキー:ソフトウェアで保護。コスト低
- ハードウェアキー(Cloud HSM):FIPS 140-2 Level 3準拠のHSMで保護。コスト高
- 鍵の状態:
ENABLED→DISABLED→SCHEDULED_FOR_DESTRUCTION→DESTROYED - 鍵のローテーション:自動ローテーション(スケジュール設定)または手動。プライマリバージョンが新規暗号化に使われ、古いバージョンは既存データの復号に使い続けられる
Confidential Computing
メモリ上のデータを暗号化した状態で処理します(「使用中の暗号化」)。
| 種類 | 説明 |
|---|---|
| Confidential VM | AMD SEV(Secure Encrypted Virtualization)またはIntel TDXを使用。VMのメモリが暗号化され、ハイパーバイザーからもアクセス不可 |
| Confidential GKE Node | GKEノードをConfidential VMとして実行 |
ユースケース:規制の厳しいデータ処理、マルチパーティ計算
3-3. AIワークロードのセキュリティ
Vertex AIのセキュリティ
- VPC Service ControlsでVertex AI APIを保護(モデルの学習データやモデル自体の持ち出し防止)
- CMEKでモデルアーティファクトと学習データを暗号化
- プライベートエンドポイントを使用してパブリックインターネットへの露出を排除
- IAMロールでVertex AIリソースへのアクセスを制御
IaaS vs PaaS ホスト型モデルの責任分界
| モデル | インフラ責任 | アプリ・設定責任 |
|---|---|---|
| IaaS(Compute Engine上で学習) | 顧客(OS・ミドルウェアのハードニングも含む) | 顧客 |
| PaaS(Vertex AI) | 顧客(学習データのアクセス制御・モデルの権限管理) |
Section 4:運用管理(約20%)
CI/CDセキュリティ、Binary Authorization、ログ管理、Security Command Centerが頻出です。
4-1. インフラとアプリケーションセキュリティの自動化
Binary Authorization
コンテナイメージのデプロイポリシーを強制するサービスです。
| 構成要素 | 役割 |
|---|---|
| 証明者(Attestor) | イメージが特定のチェック(脆弱性スキャンなど)をパスしたことを証明(Attestation) |
| Attestation | Cloud KMSの非対称鍵で署名される |
| ポリシー(Policy) | どのAttestationが必要かを定義 |
対応プラットフォーム:GKE(Admission Webhook)およびCloud Run
| モード | 動作 |
|---|---|
| 強制(Enforced) | ポリシーを満たさないイメージはデプロイ拒否 |
| ドライラン(Dry-run) | ポリシー違反をログに記録するが拒否しない |
| 監査ログ(Audit Logging) | Cloud Runでの継続的な検証 |
CI/CDパイプラインのセキュリティ
| ツール | 役割 |
|---|---|
| Container Analysis API | Artifact Registryに格納されたコンテナイメージの脆弱性(CVE)スキャン |
| Artifact Registry | コンテナイメージやパッケージのリポジトリ。脆弱性スキャン機能内蔵 |
| SLSA | ソフトウェアサプライチェーンのセキュリティフレームワーク |
VMとコンテナイメージのセキュリティ
| サービス | 機能 |
|---|---|
| Shielded VM | セキュアブート、vTPM(仮想TPM)、整合性モニタリングを提供。ブートプロセスへの不正改ざんを検出 |
| OS Login | VMへのSSHアクセスをIAMで管理(メタデータのSSHキーを使わずに済む)。アクセスの監査証跡が残る |
| OS Config/VMマネージャー | パッチ適用の自動化 |
4-2. ロギング・モニタリング・検出の構成
Cloud Audit Logsの4種類
| ログ種別 | デフォルト状態 | 保存期間 | 備考 |
|---|---|---|---|
| Admin Activity(管理アクティビティ) | 常時有効・無効化不可 | 400日(無料) | IAMポリシーの変更、VMの作成・削除など |
| Data Access(データアクセス) | デフォルト無効(BigQueryを除く) | 30日 | 有効化するとコスト発生の可能性あり |
| System Event(システムイベント) | 常時有効・無効化不可 | 400日(無料) | Googleのシステムによる操作(ライブマイグレーションなど) |
| Policy Denied(ポリシー拒否) | 常時有効・無効化不可 | 30日 | VPC Service ControlsやFirewallポリシーによる拒否ログ。有料(ログ量課金) |
重要な試験ポイント:料金とデフォルト有効か
- 無料(課金免除):Admin Activity、System Event
- 有料・常時有効(無効化不可):Policy Denied
- 有料・デフォルト有効(BigQueryのみ):BigQueryのData Accessログ
- 有料・デフォルト無効(有効化が必要):それ以外のData Accessログ
ログシンク(Log Sinks)
ログをCloud Loggingから外部へエクスポートする設定です。
| エクスポート先 | ユースケース |
|---|---|
| Cloud Storage | 長期アーカイブ |
| BigQuery | 大規模なログ分析 |
| Pub/Sub | リアルタイムでSIEMにストリーミング |
| Cloud Logging ログバケット | 別プロジェクトのバケットに転送 |
集約シンク(Aggregated Sinks):組織またはフォルダレベルで設定し、配下の全プロジェクトのログを一括エクスポートできます。
VPC Flow Logs
VPC内のネットワークトラフィック(TCP/UDP)をサンプリングして記録します。サブネットレベルで有効化。ネットワークフォレンジックや異常トラフィックの調査に使用します。
Packet Mirroring
VPCトラフィックを(サンプリングなしで)完全コピーし、コレクターVMに転送します。IDS/IPSツールやパケット解析に使用します。Cloud IDSはPacket Mirroringを内部で使用しています。
Cloud IDS(Intrusion Detection System)
Palo Alto Networksの脅威防御エンジンを使用したネットワーク型IDSです。マルウェア、スパイウェア、C2攻撃、ネットワーク攻撃を検出します。検出結果はSecurity Command Centerに表示されます。
Security Command Center(SCC)のティア比較
| ティア | 費用 | 主な機能 |
|---|---|---|
| Standard | 無料 | セキュリティ体制の基本把握、Security Health Analytics(基本的な設定ミスの検出)、アセットインベントリ |
| Premium | 有料 | Standardの全機能+Event Threat Detection、Container/VM Threat Detection、Web Security Scanner(マネージド)、Rapid Vulnerability Detection、アタックパス分析、コンプライアンスモニタリング |
| Enterprise | 有料(組織レベルのみ) | Premiumの全機能+マルチクラウド対応(AWS・Azure)、Google Security Operationsとの統合、リスクエンジン |
Section 5:コンプライアンス要件のサポート(約12%)
出題比率は低めですが、Assured WorkloadsとAccess Transparency/Approvalは確実に押さえておきます。
5-1. 規制・業界標準への準拠
共有責任モデル(Shared Responsibility Model)
| サービスモデル | Googleの責任範囲 | 顧客の責任範囲 |
|---|---|---|
| IaaS(Compute Engine) | 物理インフラ・ネットワーク・仮想化 | OS・ミドルウェア・アプリ・データ・アクセス管理 |
| PaaS(Cloud Run、App Engine) | インフラ+ランタイム | アプリケーション・設定・データ |
| SaaS(Google Workspaceなど) | ほぼすべて | データ・アクセス設定 |
Assured Workloads
コンプライアンス要件(FedRAMP、ITARなど)に対応した設定を持つフォルダを作成するサービスです。
- データのリージョン制限(例:米国内のみ)
- アクセス制限(例:米国籍の担当者のみ)
- 組織ポリシーの自動適用
- 対応フレームワーク例:FedRAMP Moderate/High、DoD IL4/IL5、ITAR、CJIS、HIPAA(BAA別途)
Access Transparency
GoogleのSRE・サポートエンジニアが顧客のコンテンツ(データ)にアクセスした際に、ほぼリアルタイムでログを生成します。「誰が・いつ・何に・なぜアクセスしたか」を確認できます(担当者情報は匿名化)。
Access Approval
Googleのサポートエンジニアなどが顧客のデータにアクセスする前に、顧客側の承認(Approval)が必要になるサービスです。承認リクエストにはリソースと理由が含まれ、顧客が明示的に承認または拒否します。
紛らわしいポイント:Access Transparency vs Access Approval
- Access Transparency:Googleがアクセスした後でログが記録される(事後確認)
- Access Approval:Googleがアクセスする前に顧客の承認が必要(事前制御)
主要な規制フレームワークとGoogle Cloudの対応
| 規制 | 概要 | Google Cloudの対応 |
|---|---|---|
| GDPR | 個人データの処理に関するEU規制 | データ処理契約(DPA)、Assured Workloads |
| HIPAA | 医療情報(PHI)の保護 | Business Associate Agreement(BAA)をGoogleと締結 |
| PCI DSS | クレジットカードデータの保護(12の要件) | ネットワーク分離・アクセス制御 |
| FedRAMP | 米国連邦政府向けクラウドサービスの認証フレームワーク | Assured Workloads |
| FIPS 140-2 | 暗号化モジュールの標準 | Cloud HSM(Level 3)が対応 |
試験直前30分チェックリスト
Section 1(25%)確認項目
IDとアクセス
- GCDSはオンプレミス→Cloud Identityの一方向同期
- Workforce Identity FederationはユーザーSync不要、外部IdPで直接認証
- Workload Identity Federation(WIF)はGCP外部ワークロード向け(GitHub ActionsなどSAキー不要)
- WIF for GKEはKubernetesワークロードとIAMの直接マッピング
- デフォルトSAのEditor権限は本番では削除/制限する
- SAキーは避ける。短期的な認証情報かWIFを使う
- IAM DenyポリシーはAllowより優先して評価される
- PAM(Privileged Access Manager)はJIT型の時限付き特権付与
- Access Context ManagerはVPC Service Controlsと組み合わせて使う
- IAM Recommenderは実際の使用パターンに基づく最小権限ロールを提案
Section 2(20%)確認項目
ネットワークセキュリティ
- Cloud Armor:L7 WAF+DDoS対策。HTTP(S) LBの前段
- Cloud NGFW:VPCレベルのL3/L4ファイアウォール。オプションでL7検査
- IAP:VPN不要のゼロトラストアクセス
- VPC Service Controls:APIアクセスを境界で制御。有効な認証情報があっても拒否できる
- VPC Peering:推移的ピアリング非対応
- Dedicated Interconnect:デフォルトでは暗号化なし(HA VPNを重ねるかMACsecが必要)
- Cloud NAT:プライベートVMのアウトバウンド通信専用(インバウンド不可)
- Private Service Connect:VPC内にGoogle APIへのプライベートエンドポイントを作成
-
Restricted Google Access(
restricted.googleapis.com):VPC Service Controls対応APIのみ
Section 3(23%)確認項目
データ保護と暗号化
- SDP(旧DLP):PIIの検出、変換(削除・マスキング・FPE・仮名化)
- CMEK:Cloud KMSで鍵を管理。広いサービス対応
- CSEK:生の鍵素材を提供。Cloud StorageとCompute Engineのみ対応
- EKM:鍵をGoogle外部に保管。暗号化・復号時に外部KMSにAPI呼び出し
- Cloud KMSのソフトウェアキー vs ハードウェアキー(Cloud HSM、FIPS 140-2 Level 3)
- 鍵を無効化→データにアクセス不能(CMEKの場合)
- Confidential VM:AMD SEVでメモリを暗号化。使用中の暗号化
-
Secret Manager:バージョン管理、
secretAccessorロールでアクセス制御
Section 4(20%)確認項目
運用管理
- Binary Authorization:Attestor(証明者)+Attestation(証明)+Policyの3要素
- Binary Authorization:GKEとCloud Runに対応
- Admin Activityログ:常時有効、無効化不可、400日保存、無料(課金免除)
- Policy Deniedログ:常時有効、無効化不可、30日保存、有料(課金免除ではない)
- Data Accessログ:デフォルト無効(BigQueryは例外)、30日保存、有料
- 集約シンク:組織/フォルダレベルで全プロジェクトのログを一括エクスポート
- VPC Flow Logs:サブネット単位で有効化。サンプリングあり
- Packet Mirroring:完全コピー(サンプリングなし)。Cloud IDSが使用
- SCC Standard:無料。Security Health Analytics基本チェック
- SCC Premium:Event Threat Detection、VM/Container Threat Detection
- SCC Enterprise:マルチクラウド(AWS/Azure)対応。組織レベルのみ
Section 5(12%)確認項目
コンプライアンス
- 共有責任モデル:IaaSはOSも顧客責任。PaaS/SaaSはGoogleの責任範囲が広がる
- Assured Workloads:コンプライアンス要件(FedRAMP・ITARなど)に対応したフォルダを作成
- Access Transparency:Googleアクセス後のログ(事後確認)
- Access Approval:Googleアクセス前に顧客の承認が必要(事前制御)
- HIPAA:Google CloudでPHIを扱う場合はBAAの締結が必要
- FIPS 140-2 Level 3 対応:Cloud HSMバックドキー
最後に
この記事は2026年5月時点の公式試験ガイドに基づいて作成しています。Google Cloudのサービスは継続的に更新されるため、受験前に必ず公式の試験ガイドで最新情報を確認してください。
試験に向けて、残りの準備を全力で応援しています。








