G-gen の杉村です。当記事では、Google Cloud の認定資格である Professional Cloud Security Engineer 試験の出題傾向や対策、知っておくべき技術領域などについて紹介します。

概要

Professional Cloud Security Engineer とは

Professional Cloud Security Engineer は、Google Cloud（旧称 GCP）のセキュリティ関連の知識と実務能力を問う認定資格です。

試験時間は120分、出題は50問〜60問の多肢選択式です。問題文はそこまで長くないため、落ち着いて解ければ十分な余裕があります。

なお、当試験は2022年2月までは英語版のみの提供でしたが、2022年3月より日本語での提供が開始されました。

参考 : Professional Cloud Security Engineer

当記事では、Professional Cloud Security Engineer 試験の出題傾向について紹介します。当記事で学習の方向性を決定し、実務にも応用可能な知識を習得してください。

難易度

当試験の難易度は、中程度〜比較的高いと言えます。「応用情報技術者試験」程度の IT 基礎知識があり、かつ Google Cloud をある程度業務で使用した経験がベースとしてあることが望ましいです。

これに加えて、ネットワークセキュリティや Web アプリケーションセキュリティに関する基本知識を持っていることが望ましいです。IPA のネットワークスペシャリストや、情報処理安全確保支援士（旧セキュリティスペシャリスト）の知識も役立ちます。

なお Associate Cloud Engineer や Professional Cloud Architect 試験を先に取得しておくと、Google Cloud の基本知識が事前に習得できるため、学習コストが下がります。逆にいうと、これらの資格を既に取得済みの方であれば、あとは当記事を参考にして知識をアドオンしていけば、合格は難しくありません。

推奨の勉強法

Associate Cloud Engineer を取得する
- ただし Professional Cloud Security Engineer の受験手続きにあたっての必須要件ではありません
書籍、各社のブログ記事、公式ドキュメント等で Google Cloud のセキュリティ関係サービスの概要を理解する。特に以下のサービスに着目する
- IAM、組織（Organization）、組織のポリシー、VPC、Cloud Identity、Cloud KMS、Cloud DLP
試験ガイドを読み、出題範囲を理解
当記事を読み、出題傾向を把握
把握した試験範囲・出題傾向をもとに勉強
Google Cloud に限らない一般的なセキュリティ系知識（暗号化、ネットワーク、 Web アプリセキュリティ等）もこれを機に勉強し、理解する
模擬試験を受け、足りない知識を認識して、ギャップを埋める勉強をする

出題傾向

当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるだけでなく、実践的な知識となるでしょう。

また、責任共有モデルや最小権限の原則をはじめ、多くのセキュリティの概念は、 Google Cloud に限らず情報セキュリティにおける一般的な知識です。この試験勉強を機に、セキュリティの基本的な知識を身につけ、実践できるようにしていくことが重要です。

なお、当記事の内容は2026年1月時点の、G-gen 従業員の受験体験に基づいています。

責任共有モデル

クラウドユーザーが意識しておくべき最も重要なセキュリティの考え方として、 責任共有モデル があります。

どこまでがクラウド提供事業者（Google）の責任で、どこからが私たちクラウド利用者の責任なのか、自分の言葉で人に説明できるまで理解している必要があります。以下に、参考となるドキュメントへのリンクを記載します。

参考 : Google Cloud における責任と運命の共有
参考 : AWS クラウドセキュリティ - 責任共有モデル

責任共有モデルを理解しておけば、例えば Web アプリを Google Kubernetes Engine（GKE）などにホストした際に、私たちクラウド利用者がどの部分のセキュリティに責任を持つべきか、という問いに答えられるようになります。

簡単に言うと、「データセンターの物理機器の管理は Google の責任」「マネージドサービスであれば概ね OS レイヤまでが Google の責任」であり、それ以外は私たちユーザーの責任です。つまり、Web アプリケーションのセキュリティ、すなわちセキュアコーディングであったり、 WAF（Web Application Firewall）がカバーすべきL7レイヤの脅威への対処は、私たちユーザーの責任です。

一方で、App Engine や Cloud Run のようなマネージドサービスでは、OS レイヤ以下は、Google の責任となります。

組織のポリシー

基本的な知識

当試験では、組織のポリシーについての問題が頻繁に出題されます。

blog.g-gen.co.jp

以下のようなキーワードで、理解を深めてください。

制約、ブール型とリスト型
継承（API パラメータとしては inheritFromParent : true または false）
代表的な組織ポリシー（制約）の使い方

把握しておくべき制約

以下のような代表的な制約について、概要を把握してください。

Cloud Identity と ID 連携

アカウントとグループの管理

Cloud Identity（または Google Workspace）によるアカウントやグループの管理手法に関する質問に答えられるようにしてください。

あまり知られていない事実として、Cloud Identity のグループメンバーは、Cloud Identity の管理コンソールだけでなく、Google Cloud コンソールの「IAM と管理 > グループ」画面でも編集できます。操作者がグループ内で「マネージャー」や「オーナー」のロールを持っていれば、Cloud Identity 管理コンソールにアクセスすることなく、Google Cloud コンソール上でグループメンバーの追加や削除が可能です。セキュリティ維持のため、組織外部のユーザーをグループに追加できないようにするには、Cloud Identity 管理コンソールで「グループオーナーは外部メンバーを許可できる」のチェックボックスを外しておくことで禁止できます。また、グループごとに設定を変更することも可能です。

参考 : グループを使用するための組織全体のポリシーを設定する

またアカウントのログインパスワードのポリシーに関する理解も必要です。Cloud Identity（または Google Workspace）では、脆弱なパスワードを使用できないようにパスワード要件を設定できます。「次回ログイン時にパスワードポリシーを適用する」のチェックボックスをオンにすることで、安全にポリシーを適用できます。

参考 : ユーザーのパスワード要件を適用、モニタリングする

アカウント連携（プロビジョニング）

当試験では、Active Directory や Microsoft Entra ID と、Cloud Identity（または Google Workspace）の間でアカウントを同期する（プロビジョニングする）方法について、十分に理解しておく必要があります。

オンプレミスやクラウドの VM 上の Active Directory（AD）から Cloud Identity へアカウントをプロビジョニングするには、Google Cloud Directory Sync（略称 GCDS）が使用できます。GCDS はサーバーにインストールするタイプのソフトウェアで、AD のアカウントを Cloud Identity に自動プロビジョニングできます。

参考 : Google Cloud Directory Sync について

またクラウド型の Directory Sync 機能を使うと、GDCS と同様に、AD から Cloud Identity へアカウントをプロビジョニングできます。Directory Sync は、Entra ID にも対応しています。

参考 : Directory Sync のスタートガイド

Entra ID の場合は、上記の Directory Sync を使う方法のほか、Entra ID に備わっている自動プロビジョニング機能を用いることができます。

参考 : Microsoft Entra ID（旧 Azure AD）のユーザープロビジョニングとシングルサインオン

Workload Identity

Active Directory や Entra ID を始めとする外部の Identity Provider（IdP）から Google Cloud へシングルサインオン（SSO）する方法を、十分に理解してください。SAML や OAuth 2.0（OIDC）といった仕組みを使ったシングルサインオンについての一般的な知識が無い方は、まずはそちらを調べて、概要を理解したほうが良いでしょう。

そのうえで、SAML や OAuth 2.0（OIDC）に準拠した権限連携の仕組みである Workload Identity を理解してください。Workload Identity は、外部 IdP のアカウントを Cloud Identity にプロビジョニングすることなく、外部 IdP のアカウントに Google Cloud の IAM 権限を付与できる仕組みです。

Workload Identity を使うことで、例えば Entra ID（Active Directory）などの外部 IdP のユーザーに、Google Cloud 上で開発を行う権限を付与できます。こうしておけば、アカウントの管理自体は外部 IdP で行われるため、退職者等の権限は外部 IdP 側でアカウントが削除された時点で消失します。これで Google Cloud 側で権限を変更する必要がなく、運用が簡素になります。

参考 : Workload Identity 連携

Identity and Access Management（IAM）

基本的な知識

Identity and Access Management（IAM）の概念と仕組みを正しく理解しておく必要があります。以下の記事を参照して、IAM の仕組みを詳細に理解してください。

blog.g-gen.co.jp

以下の問いに、自分の言葉で答えられるようになっていれば、IAM の基礎知識が身についているといえます。

IAM 許可ポリシーとは何か
IAM の継承とは何か
プリンシパルにロールを紐づける、とはどういうことか

基本ロールと事前定義ロール

以下の基本ロールや事前定義ロールの仕様は、特に注意して把握しておくべきです。

基本ロール（閲覧者、編集者、オーナー）
Resource Manager（組織、フォルダ関係）
Cloud Logging
Cloud Billing
Cloud Storage

以下の公式ドキュメントを確認したり、あるいは Google Cloud プロダクトごとの IAM 関連のガイドを確認し、事前定義ロールを理解しておきます。

参考 : IAM roles and permissions index
参考 : IAM を使用したプロジェクトのアクセス制御 - Resource Manager
参考 : IAM によるアクセス制御 - Cloud Logging
参考 : Cloud Billing のアクセス制御と権限 - Cloud Billing
参考 : Cloud Storage に適用される IAM のロール - Cloud Storage

コンピュートリソースと IAM

Compute Engine、Cloud Run、Google Kubernetes Engine（GKE）などのコンピュートリソース上のプログラムから、Google Cloud APIs にアクセスするには、サービスアカウントの IAM 権限を使用します。これらの実行環境にサービスアカウントをアタッチすることで、プログラム上から権限を使用できます。サービスアカウントキーを発行することは、ほとんどの場合でベストプラクティスに反しているため、選択肢になりません。

Google Kubernetes Engine（GKE）の Pod からサービスアカウントの権限を使うには、Workload Identity Federation for GKE という仕組みを使い、Kubernetes の世界のサービスアカウントと、Google Cloud の IAM の世界のサービスアカウントをマッピングする手法が一般的に行われます。

参考 : Workload Identity Federation for GKE について

最小権限を維持し、かつ権限を持つ時間を最短にするためには、サービスアカウントの権限借用（impersonation）という手法が使われることもあります。

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

Virtual Private Cloud（VPC）

基本的な Virtual Private Cloud（VPC）の仕組みはもちろん、応用レベルの仕様も理解しておきましょう。例えば、以下のような概念です。

VPC Flow Logs
VPC Peering
共有 VPC
VPC のルーティング（参考）
- 同一 VPC 内のサブネット同士のルート交換の仕様
- VPC ネットワークピアリングを接続した際の VPC 同士のルート交換
VPC ファイアウォール
Cloud NAT

上記の用語の意味を理解したうえで、以下のような少し複雑な VPC の仕様が具体的にイメージでき、設計に活かせるくらいの知識があると、問題にも回答できます。

VPC ネットワーク内に複数サブネットを作成すると、全てのサブネット同士は通信できる（サブネット同士の通信のためのルートは、編集したり削除したりできない）
VPC ネットワーク同士をピアリングすると、 VPC ネットワーク内の全サブネットのルートが自動的に交換される（ルートは編集したり削除したりできない）
VM は複数の VPC ネットワークの複数のサブネットに足を伸ばせる（NIC を作ることができる）
ファイアウォールにおいて、あるパケットが複数のルールに該当する場合、どのルールが適用されるか、優先度を理解する

VPC に関する参考記事

VPC の詳細な仕様については、以下の記事も参照してください。

ハイブリッドネットワーク

ハイブリッドネットワークとは、オンプレミスと Google Cloud の VPC ネットワークを接続して、相互運用を行うようなアーキテクチャのネットワークのことです。Cloud Interconnect、Cloud VPN、限定公開の Google アクセスなどがキーワードとなります。

以下の公式ドキュメントを確認して、オンプレミスと VPC ネットワークを接続する際には、適切なプロダクトを選択できるようにしておきます。

参考 : Network Connectivity プロダクトの選択

これに関連して、限定公開の Google アクセス（Private Google Access）機能を使い、オンプレミスからプライベートネットワーク経由で Google Cloud APIs を利用する方法も理解してください。以下の記事も参考にしてください。

blog.g-gen.co.jp

Cloud Armor、Cloud IDS

Google Cloud が提供するフルマネージドな WAF（Web Application Firewall）である Cloud Armor については、概要を理解してください。

blog.g-gen.co.jp

Cloud IDS は、VPC ネットワーク内のパケットを検査し、マルウェアによる通信、コマンド&コントロール通信等を検知する仕組みです。VM に出入りするパケットの中身を検査することができます。

blog.g-gen.co.jp

もしも「WAF が保護できる対象の脅威（攻撃手法）は何か」「IDS や IPS が保護できる対象の脅威（攻撃手法）は何か」「WAF、IDS、ファイアウォールの守備範囲の違いは何で、それぞれ目的は何か」といった一般的な問いに答えられない場合は、これを機に知識を再確認しておきましょう。

上記は Google Cloud に限定されない一般的な IT セキュリティの知識ですが、これが分かっていれば回答できる問題が、当試験では出題されます。

Cloud Logging と Cloud Audit Logs

Cloud Logging と Cloud Audit Logs の仕組みも頻出です。監査ログを適切に出力し、保存する方法に関係しているためです。

blog.g-gen.co.jp

上記の記事を読み、以下の概念を正確に把握してください。

Cloud Logging のログシンクとログバケット、包含フィルター
Cloud Audit Logs 管理アクティビティ監査ログと、データアクセス監査ログ

暗号化

Cloud KMS（Key Management Service）

当試験でも最も重要なのが、暗号化や鍵情報の扱いです。その中核にあるのが Cloud KMS です。Cloud KMS は FIPS 140-2 と呼ばれる、米国政府により規定されたセキュリティ要件仕様の規格に準拠した Google Cloud サービスです。

参考 : Cloud Key Management Service の概要

Cloud KMS のサービス詳細については以下の記事を参照してください。

blog.g-gen.co.jp

さらに Cloud KMS 関連の以下の単語については、それぞれの違い、役割、仕組みを理解する必要があります。

顧客管理の暗号鍵（CMEK、Customer-Managed Encryption Key）
顧客指定の暗号鍵（CSEK、Customer-Supplied Encryption Key）
Cloud EKM（External Key Manager）
Cloud HSM（Hardware Security Module）

エンベロープ暗号化

エンベロープ暗号化（Envelope Encryption）という仕組みの理解が重要です。エンベロープ暗号化は Google Cloud の KMS に独自の技術というわけではなく、暗号化の世界ではしばしば用いられます。

Envelope Encryption という言葉で検索して解説を読んだり、以下のドキュメントを参考にするなどしてください。

参考 : エンベロープ暗号化 - Google Cloud
参考 : Concepts in the AWS Encryption SDK - Amazon Web Services

デフォルトの暗号化と CMEK 暗号化

Google Cloud ではストレージ上のデータは、デフォルトで透過的に暗号化されているという点も重要です。

データの暗号化の基本的な考え方として at-rest（保存時）の暗号化と in-transit（転送中。in-flight とも）の暗号化に分けることができます。それぞれについて Google Cloud の物理基盤ではどのような実装がされているか、以下のドキュメントを確認してください。

参考 : デフォルトの保存データの暗号化
参考 : Google Cloud の転送中データの暗号化

Google Cloud のデータはデフォルトで暗号化されているのにも関わらず、CMEK（顧客管理鍵での暗号化）が必要になる理由は、鍵の管理に関する要件への対応です。デフォルトの暗号化では、鍵の管理やローテーションは Google によって管理されています。暗号鍵を自組織で管理する要件や、ローテーション日数の厳密な指定がある場合は、Cloud KMS を利用して、CMEK を用います。

Sensitive Data Protection

Sensitive Data Protection とは

Sensitive Data Protection（旧称 Cloud DLP）の問題は頻出です。Sensitive Data Protection は PII（個人識別情報）等のセンシティブなデータを発見、分類、保護するためのフルマネージドサービスです。

参考 : Sensitive Data Protection の概要

PII の発見と保護

Sensitive Data Protection の主要な機能は、センシティブなデータの「発見」と「保護（de-identification = 匿名化、redaction = 削除）」に大きく分けられます。

前者の「発見」については、 Cloud Storage や BigQuery 内のテキストや画像データの中に PII が含まれていないかどうかをスキャンできます。また、API 経由で Sensitive Data Protection に検査を指示することもできるため、例えば生成 AI の入出力テキストを検査して、PII の入力や出力を防止することもできます（現在では、この機能は Model Armor に統合されています）。

後者の「保護」については、特に匿名化（de-identification）機能の一種である仮名化（pseudonymization）を理解してください。仮名化とは、情報流出を防ぐため、PII を違う文字列に置き換える機能のことです。

参考 : 仮名化

仮名化には AES-SIV を使用した確定的暗号化、フォーマット保持暗号化、暗号ハッシュ という3つの手法があります。それぞれの違いと、ユースケースを把握しておいてください。

方式名	AES-SIV を使用した確定的暗号化	フォーマット保持暗号化	暗号ハッシュ
サロゲートアノテーション	使用可	使用可	非対応
フォーマット保持	いいえ	はい	いいえ
復元可能	はい	はい	いいえ
参照整合性	はい	はい	はい

AES-SIV を使用した確定的暗号化は、特定のアルゴリズムに準じて文字列を変換します。暗号鍵への適切な権限をもっていれば、暗号化後の文字列を復号して元の文字列を得ることもできます。「従業員の個人情報を、人事部署のみが参照できるようにする」などに適しています。

フォーマット保持暗号化は、復号が可能であることに加え、変換後の文字列を、元の文字列と同じ文字セットや長さで出力します。「開発部署がテストのためにユーザーデータを欲しがっている。クレジットカード番号や E メールアドレスは、本物と同じフォーマットにして欲しい。しかし、これらは個人情報であるため、本当の値を渡したくはない」といったユースケースで使用できます。

「暗号ハッシュ」はハッシュ化であるため、一度 PII を変換したら、元に戻すことはできません。ただし、入力が同じであれば出力も一意に決まるため、参照整合性はあります。つまり、仮名化した文字列と他のカラムのデータの関係性が保持されるため、分析用途で使用できます。

DevSecOps（CI/CD）

Google Cloud で CI/CD パイプラインを実装し、パイプライン内にセキュリティを組み込む方法についても把握することが望ましいです。

参考 : Google Cloud 上での DevOps と CI / CD について

フルマネージドのコンテナリポジトリサービスである Artifact Registry には、コンテナスキャン機能があります。コンテナスキャンを有効化すると、サポートされているベースイメー-じの OS やプログラミング言語のパッケージの依存関係をスキャンして、脆弱性を検知してくれます。

参考 : コンテナスキャンの概要

また Binary Authorization を用いると、Google Kubernetes Engine（GKE）や Cloud Run といったコンテナ実行基盤に、証明書（attestations、署名とも訳される）のついた安全なコンテナイメージだけがデプロイされるように制限することができます。

参考 : Binary Authorization の概要

VPC Service Controls

VPC Service Controls の基本については、以下の記事を参照して把握してください。

blog.g-gen.co.jp

境界（perimeter）の考えや、境界の保護下に VPC ネットワーク内の VM インスタンスを組み入れるにはどうすればよいか、などを回答できるようにしてください。

境界内のリソースと、境界外のリソースが通信する方法も理解してください。境界ブリッジ（perimeter bridges）を使うことで、異なる境界内のリソース同士でデータのやり取りが可能になります。

ただ、一方のリソースが VPC Service Controls の境界を使用していない場合は、境界ブリッジではなく、内向きルールや外向きルールを適切に設定する必要があります。それぞれをどういったときに、どのように設定すべきなのかについて、以下の記事を読み込んで把握してください。

blog.g-gen.co.jp

Security Command Center

Security Command Center（SCC）は、Google Cloud 環境の脆弱性や構成ミス、不審な挙動などを検知してリストアップしたり、通知するサービスです。SCC は複数の機能を擁していますので、どのような機能があるのか、どのように使うべきなのかを、公式ドキュメントや以下の記事を参考に把握してください。

blog.g-gen.co.jp

SCC のどの機能がどのレイヤの脆弱性を検知できるのか、適切に答えられるようにしましょう。

Security Health Analytics は Compute Engine や VPC ファイアウォール、Cloud Storage などの不適切な設定や設定ミスを検知することができます。

Web Security Scanner は Web アプリに対する L7 レベルの脆弱性スキャンを定期的に実行することが可能です。

Virtual Machine Threat Detection は、VM をスキャンしてクリプトマイニング（暗号通貨採掘）、カーネルモードルートキット、マルウェアなどを検出します。VM のゲストメモリからメタデータを読み取って検査するので、エージェントソフトウェアは不要です。

Compute Engine

Confidential Computing

近年では at-rest / in-transit のデータ暗号化に加えて、メモリ上のデータ暗号化も加える場合があります。Google Cloud の Confidential Computing の考え方では、ストレージ上や通信経路上のデータだけでなく、メモリ上のデータも暗号化します。これを実現する VM を、Confidential VM と呼びます。

参考 : Confidential Computing のご紹介
参考 : Confidential Computing の概要

Shielded VM

Shielded VM は、VM がセキュアに起動することを担保するために高度な設定を有効化した Compute Engine VM のことです。

セキュアブート、vTPM、整合性モニタリングといったオプションを有効化して VM を起動することで、ブートレベルやカーネルレベルなど低レイヤで動作するマルウェアやルートキットなどに対処できます。この3つのキーワードを覚えてください。以下のドキュメントや記事も参照してください。

参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog - Shielded VM
参考 : Shielded VM の概要

その他のプロダクト

Network Intelligence Center

Network Intelligence Center の概要を把握しておいてください。

参考 : Network Intelligence Centerを徹底解説！ - G-gen Tech Blog

Firewall Insights 機能など、ネットワークセキュリティとガバナンスの維持に有用な機能が利用できます。Firewall Insights ではその Firewall ルールが何回ヒットした（実際に使われた）か、また最後に使われたのはいつか、などを確認することができます。また優先度のせいで別のルールの影に隠れて使われていない Shadowed rules を見つけることもできます。増えすぎたファイアウォールルールを棚卸しするときに便利な機能です。

Secret Manager

Secret Manager はアプリケーションが利用するパスワード、証明書、 API キーなどの機密情報を格納するためのセキュアなストレージサービスです。

参考 : Secret Manager の概要

API 呼び出しでシークレット（機密情報）を格納したり、取り出したりできるほか、バージョニングやローテーションといった管理機能があります。Secret Manager に格納されたシークレットはデフォルトで暗号化されており、オプションで前述の Cloud KMS の CMEK を利用することもできます。

試験の傾向として、サービスアカウントのシークレットキーを発行して Secret Manager に格納するような選択肢は、ほぼ誤りであると考えてください。なぜなら、Secret Manager にアクセスすること自体に権限が必要になるため、ではその権限はどう管理するのか、という話になるからです。試験の世界においては、サービスアカウントは VM や Cloud Run などの実行環境にアタッチして使うものであり、キーを発行するという選択肢が正答になることはほとんどないといえます。また、それが Google Cloud のベストプラクティスであることを示しています。