Google Cloud Professional Cloud Security Engineer
最終確認：2026年5月
PCSE 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
GKE ワークロードがサービスアカウントキーを管理せずに GCP API にアクセスする必要があります。
GKE クラスタで Workload Identity を有効にし、構成します。Kubernetes Service Accounts (KSA) を Google Service Accounts (GSA) にマッピングします。
理由: KSA トークンから派生した短期間で自動的にローテーションされる認証情報を使用することで、サービスアカウントキーの漏洩リスクを排除します。
VPN を使用せず、ユーザーIDとデバイスの態勢に基づいて、任意のネットワークから内部ウェブアプリへのアクセスを提供します。
Access Context Manager とともに Identity-Aware Proxy (IAP) を使用します。IP、デバイスの状態（Endpoint Verification 経由）、およびユーザーIDに基づいてアクセスレベルを定義します。
理由: アクセス制御をネットワーク境界から個々のユーザーとデバイスに移行させ、ゼロトラストの原則を強制します。
CI/CD パイプライン（例：GitHub Actions、GitLab）が、長期間有効な認証情報なしで GCP リソースにアクセスする必要があります。
Workload Identity Federation を使用します。外部 IdP（例：GitHub OIDC）用のプロバイダープールを作成し、特定のレポジトリやブランチへのアクセスを制限するための属性条件を構成します。
理由: 外部ワークロード向けのキーレス認証。外部システムが自身のトークンを提供し、それが短期間有効な GCP トークンと交換されます。
組織全体で IAM セキュリティポリシーを強制します。例えば、サービスアカウントキーの作成を禁止したり、IAM 付与を特定のドメインに制限したりします。
iam.disableServiceAccountKeyCreation` や `iam.allowedPolicyMemberDomains` のような組織ポリシー制約を使用します。
理由: 組織ポリシーは継承され、プロジェクトオーナーによってオーバーライドできないため、一貫したセキュリティ体制が保証されます。
インシデント対応のため、ユーザーは一時的で監査可能、かつ承認された運用環境への管理アクセスを必要としています。
Just-In-Time (JIT) アクセスのために Privileged Access Manager (PAM) を使用します。ユーザーは限定された期間の特定のロールを要求し、それは承認ワークフローを経ます。
理由: 主要なセキュリティリスクである常時付与される特権を排除します。アクセスは時間制限があり、正当化され、完全に監査されます。
複数のチームが GKE クラスタを共有しています。各チームは自身の名前空間内のリソースのみを管理する必要があります。
プロジェクトレベルで IAM ロール `roles/container.clusterViewer` を付与します。各名前空間内で Kubernetes RBAC の `Role` と `RoleBinding` を使用して、特定の権限（例：編集、表示）を付与します。
理由: クラスタレベルの認証（IAM）と名前空間レベルの認可（Kubernetes RBAC）を分離し、きめ細やかなマルチテナント制御を提供します。
API は静的キーではなく、短期間有効な認証情報を使用して呼び出される必要があります。
サービスアカウントの権限借用を使用します。ターゲットサービスアカウントに対して、プリンシパルに `roles/iam.serviceAccountTokenCreator` ロールを付与し、短期間有効な OAuth 2.0 アクセストークンを生成します。
理由: 長期間有効なキーの配布と管理を回避します。トークンは自動的に期限切れになるため（デフォルト1時間）、侵害された場合のリスクが軽減されます。
請負業者が特定の期間だけリソースにアクセスする必要がありますが、アクセスは30日後に自動的に期限切れになる必要があります。
時間ベースの IAM Condition（例：`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`）を使用して、必要な IAM ロールを付与します。
理由: アクセス失効を自動化し、手動でのクリーンアップを回避し、アクセスが意図せず延長されないようにします。
CI/CD パイプラインによって署名されたコンテナイメージのみを本番 GKE クラスタにデプロイできるようにします。
Binary Authorization を実装します。CI パイプラインでイメージに署名するためのアテステーションを作成します。GKE クラスタ上で、このアテステーションを要求する Binary Authorization ポリシーを構成します。
理由: 未承認または改ざんされたイメージが本番環境で実行されるのを防ぎ、安全なソフトウェアサプライチェーンを強制します。
個々のリソース名ではなく、割り当てられたタグに基づいてリソースへの権限を付与します。
リソースタグ式（例：`resource.matchTag("123456789/env", "prod")`）を使用する IAM Conditions を使用します。
理由: スケーラブルな属性ベースのアクセス制御（ABAC）を可能にします。リソースにタグが付けられると、権限は動的に自動的に適用されます。
サービスプロジェクトが Shared VPC ホストプロジェクトに VM をデプロイすることを許可しますが、ネットワーク管理者権限は付与しません。
ホストプロジェクトで、サービスプロジェクトのサービスアカウントに、使用する必要のある特定のサブネットに対して `roles/compute.networkUser` ロールを付与します。
理由: 最小特権に従います。サービスプロジェクトはネットワークを使用できますが、ネットワークを変更する（例：ファイアウォールルールを変更する）ことはできず、ネットワークは一元的に管理されたままです。
storage.admin` の権限を持つユーザーがバケットを作成できません。根本原因を特定する必要があります。
より上位のレベル（フォルダ、組織）で `storage.buckets.create` 権限を拒否する IAM Deny Policy が存在しないか確認します。
理由: IAM Deny ポリシーは常に許可ポリシーをオーバーライドします。これは、交渉不可能なセキュリティ境界を強制するための強力なツールです。
オンプレミス Active Directory ユーザーが Google Cloud コンソールにアクセスするための SSO を有効にします。
Google Cloud Directory Sync (GCDS) を使用して ID を Cloud Identity に同期します。Cloud Identity と AD FS（または別の IdP）の間でフェデレーション（SAML）を構成します。
理由: AD を ID の信頼できる情報源として維持しつつ、ユーザーにシームレスなフェデレーション SSO エクスペリエンスを提供します。
GCP でデータを暗号化しますが、暗号化キーはオンプレミスの HSM から決して離れてはなりません。
Cloud External Key Manager (EKM) を使用します。これにより、GCP サービスは CMEK 操作のために外部キー管理システムからのキーを使用できます。
理由: キーマテリアルを Google Cloud の外に保持することで、最大限の制御を提供し、厳格なデータ主権要件を満たします。
すべての Cloud Storage および BigQuery アセットで機密データ（PII、PHI）を自動的に検出し、分類します。
Cloud Data Loss Prevention (DLP) の検出スキャンを構成します。結果は Data Catalog にタグとして自動的に入力されます。
理由: データガバナンスおよび保護ポリシーの基盤となる、自動化されたデータインベントリと分類を提供します。
分析チームは PII を含むデータをクエリする必要がありますが、生の機密値を見るべきではありません。参照整合性は維持されなければなりません。
決定論的暗号化または暗号ハッシュ化を使用した Cloud DLP 匿名化テンプレートを使用します。
理由: 機密データを仮名に変換します。決定論的方法は、常に同じ入力から同じ出力が生成されることを保証し、結合や集計を可能にします。
コンプライアンスフレームワーク（例：金融サービス向け）により、暗号化キーが FIPS 140-2 レベル3認定 HSM によって保護されることが求められています。
保護レベルが HSM の Cloud KMS を使用します。これにより、マネージドハードウェアセキュリティモジュール内でキーが作成されます。
理由: 物理的な HSM を管理することなく、キー管理に専用の認定ハードウェアを使用することで、高レベルのコンプライアンス要件を満たします。
新しいリソース（例：GCS バケット、BigQuery データセット）が、Google 管理キーではなく、顧客管理キー（CMEK）で常に暗号化されるようにします。
constraints/gcp.restrictNonCmekServices` 組織ポリシーを適用します。
理由: 指定されたサービスに CMEK の使用を強制する予防的制御を提供し、一貫したデータ保護体制を保証します。
データは、法的またはコンプライアンス上の理由から、特定の保持期間の間、不変（WORM - Write-Once-Read-Many）の状態で保存される必要があります。
保持ポリシーを持つ Cloud Storage バケットを構成し、Bucket Lock を有効にします。
理由: Bucket Lock は保持ポリシーを不可逆なものにし、保持期間が終了するまで、管理者であってもオブジェクトが削除または変更できないことを保証します。
シークレットとして保存されているアプリケーションデータベースの認証情報は、アプリケーションのダウンタイムを引き起こすことなく、自動的にローテーションされる必要があります。
自動ローテーションが構成された Secret Manager を使用します。ローテーションは Cloud Function をトリガーし、データベース内のパスワードを更新し、新しいシークレットバージョンを作成します。
理由: 管理された自動ローテーションにより、認証情報の漏洩リスクが軽減されます。アプリケーションは「latest」バージョンを参照して、新しいシークレットをシームレスに取得します。
ワークロードが非常に機密性の高いデータを処理し、データはメモリ内（使用中）であっても暗号化されたままである必要があります。
Confidential VMs 上にワークロードをデプロイすることで、Confidential Computing を使用します。
理由: ハードウェアベースのメモリ暗号化を提供し、ハイパーバイザーや他の VM からデータを保護します。アテステーションを使用して環境の整合性を検証します。
個別のビューを作成せずに、BigQuery テーブル内の特定の機密列へのアクセスを制限します。
BigQuery の列レベルのセキュリティを使用します。機密列に Data Catalog ポリシータグを適用し、それらのポリシータグに対する「Fine-Grained Reader」ロールを承認されたユーザー/グループに付与します。
理由: テーブルに直接きめ細やかなアクセスを強制します。これは、複数の承認済みビューを維持するよりもスケーラブルで管理しやすい方法です。
IAM 権限が誤って構成され、パブリックアクセスが付与された場合でも、GCS バケット内の機密データを保護します。
顧客管理暗号化キー（CMEK）でオブジェクトを暗号化し、Cloud KMS でそのキーへのアクセスを厳密に制御します。
理由: 二重キーシステムを構築します。攻撃者はデータを復号化するために GCS オブジェクトと KMS キーの両方に対する権限を必要とし、多層防御を提供します。
重要な Cloud KMS キーの偶発的または悪意のある即時削除を防ぎます。
キーを作成する際に、`destroy_scheduled_duration` プロパティを30日などの値に構成します。
理由: キーが永久に破棄される前に待機期間を強制し、偶発的な削除から回復するための期間を提供します。
Cloud Storage 内のファイルがアップロードされてから改ざんされていないことを証明する法的要件があります。
ダウンロード時に、ファイルの MD5 または CRC32C ハッシュを再計算し、Cloud Storage オブジェクトのメタデータに保存されているハッシュと比較します。
理由: オブジェクトの整合性の暗号学的証明を提供します。Cloud Storage はこれらのハッシュをアップロード時に自動的に計算して保存します。
owner` ロールを持つユーザーであっても、機密プロジェクトからパブリックバケットへのデータコピーを防ぎます。
機密プロジェクトを VPC Service Controls ペリメーター内に配置します。これにより、ペリメーター外の他のプロジェクトへのデータ移動が制限されます。
理由: VPC Service Controls は、データ流出に対する強力な防御策として機能し、データ出力のための IAM 権限を上書きするデータ中心のファイアウォールとして機能します。
公開ウェブアプリケーションを大量の DDoS 攻撃や一般的なウェブエクスプロイト（例：SQLi、XSS）から保護します。
アプリケーションをグローバル外部 HTTP(S) ロードバランサの背後に配置し、事前構成された WAF ルールを持つ Cloud Armor セキュリティポリシーをアタッチします。
理由: ロードバランサは Google のエッジで DDoS 攻撃を吸収します。Cloud Armor は、OWASP Top 10 の脅威をブロックするためのマネージド Web Application Firewall を提供します。
オンプレミスから GCP への接続に Dedicated Interconnect が使用されていますが、コンプライアンスのためにトラフィックを暗号化する必要があります。
Cloud Interconnect VLAN アタッチメント上に HA VPN トンネルを構成します。
理由: 専用接続の高い帯域幅と低遅延を、VPN の IPsec 暗号化と組み合わせます。
オンプレミスシステムがパブリックインターネットを経由せずに Google API（例：BigQuery、GCS）を呼び出す必要があります。
オンプレミスホスト向けに Private Google Access を構成します。Cloud Interconnect または VPN を使用し、DNS を構成して `*.googleapis.com` を制限された VIP 範囲に解決します。
理由: Google サービスへのトラフィックを Google のプライベートネットワークに保持し、セキュリティを強化し、潜在的にエグレスコストを削減します。
GKE クラスタ内のすべてのサービス間通信で相互 TLS (mTLS) を強制します。
Anthos Service Mesh（または Istio）をデプロイし、関連する名前空間に対して厳格な mTLS ピア認証を有効にします。
理由: メッシュ内のすべてのトラフィックを自動的に暗号化および認証し、アプリケーションコードの変更なしにゼロトラストネットワークモデルを実現します。
コンシューマ VPC が、ピアリングやパブリック IP を使用せずに、プロデューサ VPC で実行されているサービス（例：内部 API）にプライベートにアクセスする必要があります。
プロデューサは Private Service Connect を使用してサービスを公開します。コンシューマは自身の VPC にエンドポイントを作成し、そのエンドポイントがプライベートにサービスにルーティングします。
理由: ネットワーク接続とサービスアクセスを分離します。これは、VPC と組織を越えてサービスへのプライベートアクセスを提供する、最新でスケーラブルな方法です。
ノードがパブリック IP を持たず、コントロールプレーンがインターネットに公開されていない GKE クラスタをデプロイします。
プライベート GKE クラスタを作成します。GCP API へのノードアクセス用にサブネットで Private Google Access を有効にします。コントロールプレーンへのアクセスを特定の IP（例：企業ネットワーク）に制限するために、マスター承認済みネットワークを構成します。
理由: ノードとコントロールプレーンの両方のパブリックエンドポイントを削除することで、クラスタの攻撃対象領域を大幅に削減します。
GKE クラスタ内で、`frontend` サービスの Pod は `backend` サービスの Pod とのみ通信を許可され、他とは通信してはなりません。
Kubernetes NetworkPolicy リソースを作成します。Pod ラベルに基づいて、`frontend` Pod からのトラフィックのみを許可するイングレスポリシーを `backend` Pod に適用します。
理由: クラスタ内で Pod レベルのファイアウォールを提供し、マイクロサービス向けの最小特権ネットワークモデルを可能にします。
外部 IP を持たない VM がインターネットにアクセスする必要があります。すべてのエグレストラフィックは、サードパーティによる許可リスト作成のために、予測可能な少数の IP アドレスから発信される必要があります。
VM を含むサブネットに対して Cloud NAT を構成します。
理由: プライベートインスタンスからのインターネットへのトラフィックに対して、集中型ロギングと IP 割り当てを伴うマネージドネットワークアドレス変換を提供します。
インターネットからのすべての SSH を拒否するなど、プロジェクトチームによってオーバーライドできない組織全体のベースラインファイアウォールルールを強制します。
組織またはフォルダレベルで階層型ファイアウォールポリシーを作成し、高い優先度で `0.0.0.0/0` からのポート22に対する拒否ルールを設定します。
理由: 階層型ポリシーは VPC レベルのルールよりも前に評価されるため、中央のセキュリティチームが交渉不可能なネットワークセキュリティガードを強制できます。
クエリをパブリック DNS サーバーに漏らすことなく、VPC 内の内部ホスト名を解決します。
内部ドメイン用に Cloud DNS プライベートマネージドゾーンを構成し、それを VPC に関連付けます。
理由: VPC ネットワーク内の内部リソースに対する権威ある DNS を提供し、セキュリティと管理性を向上させます。
Security Command Center が脅威（例：クリプトマイニング）を検出した際に、影響を受ける VM を自動的に隔離します。
SCC が検出結果を Pub/Sub トピックに公開するように構成します。検出結果を受け取り、VM のネットワークタグを変更して事前構成された「隔離」ファイアウォールルールを適用する Cloud Function をトリガーします。
理由: ほぼリアルタイムの自動インシデント対応を可能にし、攻撃者が環境内に滞在する時間を短縮します。
組織内のすべてのプロジェクトから監査ログを収集し、コンプライアンスのために不変形式で7年間保存します。
Cloud Storage バケットへの組織レベルのログシンクを作成します。宛先バケットを7年間の保持ポリシーと Bucket Lock で構成します。
理由: 集約されたシンクはログを一元化します。Bucket Lock は、ログが改ざん防止され、厳格なコンプライアンス保持要件を満たすことを保証します。
VM が侵害された疑いがあります。直ちにオフラインにする必要がありますが、フォレンジック分析のために証拠を保存する必要があります。
VM インスタンスを停止し（アクティビティを停止するため）、直ちにその永続ディスクのスナップショットを作成します。その後、ファイアウォールルールで隔離します。
理由: インスタンスを停止することで脅威を封じ込め、スナップショットは証拠改ざんのリスクなしに分析するためのディスクの特定の時点のコピーを作成します。
サービスアカウントが異常な地理的場所から使用されている、または異常な活動を行っている場合に検出します。
Event Threat Detection を含む Security Command Center Premium ティアを有効にします。このサービスは異常な動作をログから分析します。
理由: Google の脅威インテリジェンスと機械学習を利用して、侵害された認証情報など、ルールベースのアラートでは見つけにくい脅威を検出します。
中央のセキュリティチームが、GCP、AWS、およびオンプレミスシステムからのセキュリティシグナルを単一のプラットフォームで分析および関連付ける必要があります。
関連するすべてのログとテレメトリを Chronicle Security Operations (SIEM) に取り込みます。
理由: Chronicle は、ペタバイト規模の分析のために設計されたクラウドネイティブ SIEM であり、マルチクラウドおよびハイブリッド環境向けの組み込みパーサーと検出ルールを備えています。
Terraform によって管理されている GCP リソースがコンソールを介して手動で変更され、構成ドリフトが発生した場合に検出します。
Cloud Asset Inventory フィードを構成し、リアルタイムのアセット変更通知を Pub/Sub トピックに送信します。その後、サービスはこれらの変更を Terraform の状態と比較できます。
理由: すべてのリソース変更をリアルタイムで可視化し、帯域外変更の自動検出を可能にします。
組織には何千もの SCC 検出結果があり、最も重要なアセットに最も差し迫ったリスクをもたらすものに焦点を当てる必要があります。
SCC Premium の Attack Path Simulation を使用します。高価値のアセットを定義すると、シミュレーションはそれらのアセットへの直接的な経路を形成する検出結果を特定し、優先順位付けします。
理由: 脆弱性ベースからリスクベースの優先順位付けに移行します。攻撃者が悪用できる検出結果の危険な組み合わせを強調表示します。
実行中の GKE コンテナ内部での悪意のあるアクティビティ（予期しないシェルやリバースシェル接続など）を検出します。
Security Command Center で Container Threat Detection を有効にします。
理由: コンテナの動作をランタイムで可視化し、脆弱性スキャン（ランタイム前に発生）では検出できない脅威を検出します。
ネットワークフォレンジック調査では、特定の2つの VM 間のトラフィックの完全なパケットコンテンツをキャプチャして分析する必要があります。
Packet Mirroring を構成して、ソース VM からのトラフィックをクローンし、Wireshark や Zeek などの検査ツールを実行しているコレクタ VM に送信します。
理由: メタデータのみを含む VPC Flow Logs とは異なり、詳細な分析のための完全なパケットキャプチャを提供します。
安全でない Terraform 構成（例：パブリック GCS バケット）がデプロイされるのを防ぎます。
CI/CD パイプラインに `tfsec` や Checkov のような静的解析セキュリティテスト（SAST）ツールを統合します。セキュリティ違反が検出された場合はビルドを失敗させます。
理由: デプロイ前に設定ミスを捕捉することで「シフトレフト」セキュリティを実装し、事後的な修正の必要性を減らします。
企業は、コンプライアンス上の理由から、特定のデータと処理が EU 地域でのみ発生することを保証する必要があります。
gcp.resourceLocations` 組織ポリシー制約を適用し、指定された EU 地域のみを許可します。
理由: これは、GDPR のような規制に必要とされる、リソース作成レベルでデータレジデンシーを強制する技術的、予防的制御です。
金融機関は、Google サポートエンジニアがサポートケースのためにデータにアクセスする前に、明示的で時間制限のある承認を得る必要があると要求しています。
Access Approval を有効にし、承認者を構成します。Google からのすべてのアクセス要求は、承認されなければならないリクエストを生成します。
理由: Google の管理アクセスに対する顧客主導の制御を提供し、高度に規制された業界にとって重要な要件を満たします。
監査人は、Google の担当者が環境へのアクセスを許可された際に、どのようなアクションを実行したかを正確に検証する必要があります。
Access Transparency ログを有効にして確認します。これらのログは、Google スタッフが実行したアクションのほぼリアルタイムのフィードを提供します。
理由: Google 管理者アクションの不変の監査証跡を提供し、可視性を提供し、コンプライアンス要件をサポートします。
GCP 環境を継続的に監視し、PCI DSS や HIPAA などの特定のコンプライアンス基準に違反する構成を検出します。
Security Command Center の Security Health Analytics を使用し、ダッシュボードで関連するコンプライアンス標準を有効にします。
理由: 業界ベンチマークに対するコンプライアンスチェックを自動化し、継続的な可視性を提供し、検出された設定ミスに対して検出結果を生成します。
監査人が Google の SOC 2 Type II レポートおよび PCI DSS 準拠証明書を要求しています。
Google Cloud コンソールの Compliance Reports Manager を使用して、監査レポートと証明書にアクセスし、ダウンロードします。
理由: 顧客が自身の監査プロセスをサポートするために必要なコンプライアンスドキュメントを取得できるセルフサービスポータルを提供します。
米国政府機関が FedRAMP High コンプライアンス要件を満たすワークロードをデプロイする必要があります。
FedRAMP High コンプライアンス体制向けに構成された Assured Workloads 環境内にアプリケーションをデプロイします。
理由: Assured Workloads は、特定のコンプライアンス標準を満たすのに役立つ必要な制御とガードレール（例：データの場所、担当者アクセス制限）を自動的に適用します。
