Google Cloud Professional Cloud Security Engineer 用語まとめ
2025年9月に受験した経験から、Google Cloud Professional Cloud Security Engineer試験で問われる頻出用語や重要サービスをまとめました。
Table of contents
author: Mami
はじめに
本記事では、Google公式の「Professional Cloud Security Engineer 認定試験ガイド」(日本語PDF版はこちら) の出題範囲に沿って、各セクションを体系的に解説します。
試験情報
項目 | 内容 |
---|---|
試験名 | Professional Cloud Security Engineer |
公式サイト | Google Cloud 認定試験公式ページ(Cloud Security Engineer) |
試験形式 | 多肢選択式・多肢選択複数回答(英語、日本語対応) |
出題数 | 50~60 問の多肢選択(複数選択)式 ※受験時は50問出題 |
試験時間 | 2時間(120分) |
受験方法 | オンライン監督 または テストセンター |
受験料金 | 200 USD(税別) |
合格基準 | 非公開(おおよそ70〜75%が目安) |
有効期限 | 2年間 |
著者の対策方法
模擬試験を一度実施。基本的にはUdemyのGoogle Cloud Professional Cloud Security Engineer | 模擬試験にて対策しました。
次章以降でGoogle公式の「Professional Cloud Security Engineer 認定試験ガイド」(日本語PDF版はこちら)のセクションごとの出題率も記載しておりますが、概ねガイドの配点比率どおりの体感でした。
セクション1:アクセスの構成(試験内容の約25%)
1.1 Cloud Identity を管理する
項目 | 説明 |
---|---|
Cloud Identity | Google Cloud における ID 管理とポリシー管理を統合的に行うためのサービス。 ID プロバイダ(IdP)として、外部アプリやサードパーティのクラウドサービスへのアクセスを SSO (シングルサインオン) で提供できる。SAML 2.0といった標準プロトコルに対応し、gcloud CLI を使って SSO 認証の設定確認も可能。 Active Directory などの外部 ID 管理システムとも統合でき、既存の認証基盤を活かしながらクラウド導入が可能。 |
Google Cloud Directory Sync(GCDS) | オンプレミスの Active Directory や LDAP にあるユーザー・グループ情報を Cloud Identity / IAM と同期させるツール。これにより、既存の認証基盤を活用したままクラウド環境への移行や運用を容易にする。 |
Workforce Identity | 外部委託先など社外ユーザーを IdP 連携で認証する際に利用できる。 |
1.2 サービスアカウントを管理する
項目 | 説明 |
---|---|
サービスアカウント | サービスアカウントキー(JSON形式)を使うと外部システムから認証可能になるが、漏洩リスクが非常に高い。 やむを得ず発行する場合は以下を必ず実施する: ・定期的なローテーション ・Cloud KMS 等での安全な保管 ・Cloud Audit Logs による使用状況監査 |
Workload Identity | GKE や Cloud Run から サービスアカウントキーを使わずに認証できる。 |
Workload Identity Federation | 外部クラウドのワークロードが自身のIDを使用してGoogle Cloudに認証し、一時的で短期間のみ有効なアクセストークンを取得することが可能になる。 |
- Workload IdentityとWorkforce Identityが選択肢に混じっていることもあるのでうっかり間違えないように注意。
1.3 認証を管理する
項目 | 説明 |
---|---|
SAML | IdP から SP へのシングルサインオン (SSO) 用プロトコル。企業ADとのフェデレーションやGoogle CloudのSSO構成で頻出。 |
OAuth 2.0 | 認可用プロトコル。アクセストークンによってアプリがユーザー情報に安全にアクセス可能。Scope設定が重要。 |
OIDC (OpenID Connect) | OAuth2.0に認証機能を加えたプロトコル。IDトークン (JWT) によりユーザーの身元を確認。Googleログインや外部IdP連携に利用。 |
MFA(多要素認証) | パスワードだけでなく、所持情報・生体情報など複数要素で認証を強化。特権アカウントは必須。 |
セキュリティキー(FIDO2 / U2F) | 物理デバイスを用いたMFA手段。フィッシング耐性が高く、最も安全な認証方法として出題頻度が高い。 |
- SAML は「認証」、OAuth 2.0 は「認可」に用いられる。
1.4 認可制御を管理・実装する
項目 | 説明 |
---|---|
IAM | IAM ロールは階層的に継承される:組織 → フォルダ → プロジェクト → リソース。 IAM 条件ポリシー を使うと、IP・デバイス状態・時間帯などの属性でアクセス制御できる。 |
VPC Service Controls | IAM とは異なり「ネットワーク境界」レベルでのアクセス制御を行う。 |
Access Context Manager | IAM条件と VPC Service Controls を組み合わせるためのコンテキスト基盤。 スコープ付きアクセスポリシー を使用すると、Access Context Managerのポリシーをフォルダ単位で分離できる。 |
BeyondCorp Enterprise | ゼロトラストモデル に基づいてアクセス制御を実現できる。 Access Context Manager と連携し、ユーザー ID・デバイス証明書・IP アドレス・デバイス健全性などの条件でアクセスを制御可能。 |
1.5 リソース階層を定義する
組織
└─ フォルダ ← 部門・環境・チームごとの分割に利用
└─ プロジェクト ← リソースの実行単位(VM、Storageなど)
└─ リソース
- 組織ポリシーは上位(組織ノードなど)から下位(フォルダ、プロジェクト)に継承される。
inheritFromParent: false
が設定されている場合、親ポリシーは継承されず、そのリソースに直接設定されたポリシーのみが有効になる。
Cloud Billing の代表的ロール | 説明 |
---|---|
Billing 管理者 (roles/billing.admin ) | 請求先アカウントの作成・管理を行う。支払い方法・エクスポート設定など全体を管理。 |
Billing コスト管理者 (roles/billing.costsManager ) | 予算・費用情報を管理し、コストレポートやエクスポートの操作が可能。 |
Billing 閲覧者 (roles/billing.viewer ) | 請求情報の閲覧・トラッキングのみ可能。費用表示や課金状況の確認用。 |
Billing ユーザー (roles/billing.user ) | プロジェクトに請求先アカウントをリンクする権限のみ。 |
セクション2:通信の保護と境界保護の確立(試験内容の約22%)
2.1 境界セキュリティを設計して構成する
項目 | 説明 |
---|---|
Cloud IDS | ネットワークトラフィックのペイロードを解析して脅威を検出するサービス。 Packet Mirroring は IDS とは異なり、トラフィックをコピーして外部システムで解析する仕組みのこと。 問題に「ペイロード」と出てくれば、Google製品であれば Cloud IDS、仕組みのことであれば Packet Mirroring を選択。 |
Cloud Armor | DDoS対策・WAF(Web Application Firewall) サービス。L3〜L7 の攻撃を防ぎ、悪意あるアクセスからアプリケーションやサービスを保護。 |
Identity-Aware Proxy (IAP) | Google Cloud 上のアプリケーションや VM へのアクセスを ユーザー ID とコンテキストに基づいて制御する仕組み。VPNなしで安全なアクセス制御を実現。IAP 署名付き JWT をバックエンドで検証することによってリクエストの正当性を保証する。 |
Secure Web Proxy | インターネットへの送信トラフィックをセキュアに転送できる。 |
Cloud DNS | 高可用性・スケーラブルなマネージド DNS サービス。DNSSEC やポリシー制御を活用して、ドメイン偽装やキャッシュポイズニングを防止できる。 |
Cloud Next Generation Firewall(NGFW) | アプリケーションレイヤ(L7)での脅威検出や TLS インスペクション(TLS インターセプト)をサポートする。 これにより、暗号化されたトラフィックを復号してマルウェアを検査し、アプリケーションを保護できる。 階層型ファイアウォールポリシーと組み合わせて組織・フォルダ単位で一元管理すると運用効率が高い。 |
ロードバランサ
複数のサーバーやインスタンスにトラフィックを分散し、サービスの可用性・スケーラビリティ・信頼性を高める仕組み。Google Cloudでは、用途に応じて次のように分類されます。
- 外部ロードバランサ:インターネット経由のアクセスを分散(Webサイト・API向け)
- 内部ロードバランサ:VPC内部の通信を分散(マイクロサービス間通信など)
ロードバランサの種類 | 説明 |
---|---|
グローバル外部 HTTP(S) ロードバランサ | 世界中のユーザーからのWebトラフィックを、最寄りのリージョンに自動ルーティング。Webサイトやアプリ向け。 |
SSL プロキシロードバランサ | HTTPS以外のSSL/TLS暗号化されたTCP通信を処理。SSL終端をクラウド側で実施。 |
TCP プロキシロードバランサ | 暗号化を行わないTCPベースのアプリ(例:ゲームサーバーなど)に使用。 |
外部 TCP / UDP ネットワークロードバランサ | L4レベルの高速転送を行うシンプルなロードバランサ。低レイテンシが必要な用途に最適。 |
リージョン外部 HTTP(S) ロードバランサ | 単一リージョン内で完結するWebアプリ向け。小規模構成や内部公開用に適する。 |
内部 TCP / UDP ロードバランサ | VPC 内のバックエンドサービス間で通信を分散。L4ロードバランサ。 |
内部 HTTP(S) ロードバランサ | VPC 内で HTTP / HTTPS 通信を行うアプリケーション向け。L7ロードバランサ。 |
2.2 境界セグメントを構成する
項目 | 説明 |
---|---|
VPC Service Controls | BigQuery や Cloud Storage などのデータアクセスをネットワーク境界で制御できる。 外部ネットワークや不正な API 経由のデータ流出を防止する “セキュリティ境界” を構築する。 |
VPC ピアリング | 2つのVPCネットワーク間を直接接続する仕組み。 相互の内部IPアドレス間で通信できるようになるが、トランジティブ ルーティング(中継経路)はサポートされない。 小規模なネットワーク間接続に適している。 |
Shared VPC | 1つの「ホストプロジェクト」にVPCを集中管理し、複数の「サービスプロジェクト」からそのVPCを共有して利用する仕組み。 ネットワーク・ファイアウォール・サブネットを中央管理でき、大規模組織や権限分離運用に適している。 IAMロールにより、ネットワーク管理者とサービス開発者の責任分担を明確化できる。 |
- VPC ピアリングはGoogle Cloud内の別々のVPCネットワーク同士を直接接続する仕組み。Shared VPCは複数のプロジェクトで1つの共通VPCを共有する仕組み。
- Firewall ルール は
priority
(0〜65535)の値があり、数値が小さいほど優先度が高い。
2.3 プライベート接続を確立する
項目 | 説明 |
---|---|
Cloud NAT | 外部IPを持たないVMがインターネットへ安全にアクセスできる。 この仕組みにより、プライベートVMからのソフトウェアアップデートや外部APIアクセス が可能となる。 |
Private Google Access | プライベートIPのみのVMがインターネットを経由せずに Cloud Storage や BigQuery などの Google API にアクセスできる。 セキュリティを高めつつ、データ転送コストを削減できる。 |
Private Service Connect | Googleや他社サービスに対してプライベート接続を確立できる。 |
セクション3:確実なデータ保護(試験内容の約23%)
3.1 機密データを保護し、データ損失を防止する
項目 | 説明 |
---|---|
Secret Manager | APIキーやパスワードなどのシークレットを安全に保管できる。 |
Sensitive Data Protection(旧: Cloud DLP) | 個人情報(PII)を検出して秘匿化(マスキング、トークン化など)するサービス。 クレジットカード番号(PAN)は フォーマット保持暗号化(FPE) により形式を保ったまま安全に処理でき、テストデータ利用時の漏洩リスクを最小化できます。 日付シフトは分析に必要な期間(例:日数)は維持しつつ、プライバシー保護のために元の日付を難読化します。 不可逆にする必要がある場合は、暗号学的ハッシュ化 を選びます。 |
- BigQuery では、データセットロケーションを指定することで、データを特定のリージョン内に保持できる(データレジデンシー対応)承認済みビュー や 行レベルセキュリティ を活用すると、利用者や地理的条件に応じたアクセス制御を実現できる。
3.2 保存データ、転送中のデータ、使用中のデータの暗号化を管理する
項目 | 説明 |
---|---|
顧客管理の暗号鍵(CMEK) | Cloud Storage、BigQuery、Compute Engine などで利用可能。 Cloud KMS上で鍵を生成・ローテーション・取り消しできる。Cloud Storage の既存データを CMEK に再暗号化するには、 gsutil rewrite を使用する。データを再アップロードせずに内部的に再暗号化でき、コストを抑えて効率的に移行可能。 |
顧客指定暗号鍵(CSEK) | Google Cloud に鍵を保存せず、APIリクエスト時に直接提供する方式。 Google に鍵を預けたくない場合に使用されるが、運用管理コストが高い。 |
External Key Manager(EKM) | 外部HSMを使用して鍵を保管し、Google Cloudから外部の鍵を呼び出して暗号化を実行する。暗号鍵をデータと同じクラウドプロバイダに保存したくない要件を満たしたい時にはこれを選ぶ。 |
エンベロープ暗号化 | データを「データ暗号化キー(DEK)」で暗号化し、そのDEKを「キー暗号化キー(KEK)」で保護する方式。KEKは Cloud KMS によって管理される。DEKやKEKの順番が違うひっかけがあるので注意。 |
Shielded VM | Secure Boot・vTPM・整合性モニタリングにより、ブートレベルやカーネルレベルのマルウェアから VM を保護する。 |
Confidential VM(機密 VM) | VM 上で「使用中」のデータもハードウェアベースで暗号化され、ホストから読み取られない。 “使用中(in-use)暗号化”を問う設問では Confidential VM が正解になりやすい。 |
3.3 AI ワークロードを保護する
- Vertex AIで扱うトレーニングデータやモデルも、顧客管理の暗号鍵(CMEK)で暗号化 できる。
- AIモデルや学習データには機密情報が含まれる可能性があるため、Secret Manager や Cloud Data Loss Prevention API(Cloud DLP) と組み合わせて管理する。
- AI / ML環境では、データアクセス権限(Storage / BigQuery)を細かく制御し、過剰権限のIAMロールを避ける。
- トレーニングジョブの出力(モデルアーティファクト)も Cloud Storage + CMEK を利用して暗号化する。
セクション4:オペレーションの管理(試験内容の約19%)
4.1 インフラストラクチャとアプリケーションのセキュリティを自動化する
項目 | 説明 |
---|---|
VM Manager | Compute Engine インスタンスの OS アップデートを自動化できる。 定期的なパッチ適用や脆弱性管理をスケジュール化して、セキュリティリスクを低減できる。 |
組織ポリシー | constraints/compute.trustedImageProjects を使うと、信頼できるイメージプロジェクトのみから VM を作成するよう制限できる。これにより、社内で承認されたゴールデンイメージ以外の利用を防止できる。 |
Binary Authorization | GKE クラスタや Cloud Run へのデプロイ時に 署名付きコンテナのみを許可する仕組み。 不正なコンテナイメージの実行を防ぎ、ソフトウェアサプライチェーンを保護する。 |
Security Health Analytics | Security Command Center内で脆弱構成やコンプライアンス違反を自動検出する機能。 外部IPを持つVMやパブリックバケットなどを自動的に識別し、ダッシュボードで検出結果を可視化・追跡できる。 |
Cloud Asset Inventory | 外部公開されたIP・ロードバランサ・ファイアウォール設定などを一元的に特定できる。 組織全体のリソース構成を定期的にスナップショット化し、変更追跡にも利用できる。 |
4.2 ロギング、モニタリング、検出を構成する
項目 | 説明 |
---|---|
Security Command Center | Google Cloud 全体の脆弱性と脅威を一元管理するセキュリティ統合プラットフォーム。 Standard 版は構成リスク検出。Premium 版は脅威検知やアラート機能を提供。Compute Engine インスタンス上のマルウェアや暗号通貨マイニングなどを検出する 仮想マシン脅威検出(Virtual Machine Threat Detection) が利用できる。 |
Cloud Audit Logs(監査ログ) | 「Google Cloud 上で誰が・いつ・どのリソースに・何をしたか」を記録するログ。 管理アクティビティログ:構成変更系(常に記録) データアクセスログ:データ読み取り・書き込み系 システムイベントログ:システムによる自動操作の記録 ポリシー拒否ログ:セキュリティポリシー違反による拒否記録 |
- ログシンク を使用して、ログをBigQuery / Pub/Sub / Cloud Storageにエクスポートし、組織単位で分析できる。
- Cloud Monitoring の通知チャネル(Email、Slack、Webhookなど)を設定して、セキュリティイベントを自動通知できる。
セクション5:コンプライアンス要件のサポート(試験内容の約11%)
5.1 クラウドの規制要件と業界標準要件を遵守する
項目 | 説明 |
---|---|
責任共有モデル | 責任共有モデル(Shared Responsibility Model)では、セキュリティの責任が Google(クラウド側)とユーザー(構成側)に分かれる。 ・Google:物理的・基盤的なセキュリティ(データセンター、ハイパーバイザ、ストレージ暗号化など)を担当。 ・顧客:IAM、ネットワーク設定、データ暗号化ポリシーなどの構成責任を持つ。 |
Assured Workloads | 特定の国・地域(例:日本、米国)内でのみデータを処理・保存できる。 政府・金融などの規制産業向けに、リージョン制約 と データアクセス制御 を組み合わせて運用する。 管理者やサポートエンジニアのアクセスを、アクセスの透明性とアクセス承認で制御できる。 |
アクセスの透明性 | Google 社員がユーザー環境にアクセスした際のログを記録する仕組み。 これにより、Google のサポートアクセスや運用アクセスを可視化できる。 |
組織ポリシーとリージョン制約 | 組織ポリシーにより、リージョン制約(constraints/gcp.resourceLocations )を設定し、データとリソースを特定の地域に限定できる。Assured Workloadsと組み合わせることで、規制対応環境を確実に構成できる。 |
Google Cloud の認証 | Google Cloud の各種認証(ISO 27001, SOC 2, GDPR, FedRAMP など)を活用し、組織のコンプライアンス要件に対応させる。 ・FedRAMP要件を満たす場合は Assured Workloads を選択。 ・データ所在の規制(GDPR・FISC・CJISなど)は 組織ポリシー( constraints/gcp.resourceLocations ) で管理。 |
まとめ
出題内容を振り返りながら、今後の学習に役立つキーワードとポイントをまとめました。
※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。
※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。