Zenn
🐯

Professional Cloud Security Engineer 試験 完全攻略ガイド2025

2024/11/08に公開
Security
Google Cloud
資格
Google Cloud認定資格
google認定資格
idea

2024 年 11 月 更新

こんにちは、クラウドエース所属、Partner Top Engineer で\textcolor{red}{赤髪}がトレードマークの Shanks です。

2年前に Professional Cloud Security Engineer を取得した際の学習ポイントをまとめた記事として本記事は公開されました。
ありがたいことに社内外から数多くの参考情報としてご紹介いただき人気（？）記事となりました。

2024/11 に再受験をして無事に更新することができましたので、「Professional Cloud Security Engineer 完全攻略ガイド2025」 と題して、合格体験記＋攻略記事を更新いたします。

certified-badge

注意事項

試験を知る

出題背景

まず、認定試験ガイドを確認すると、大きく5つのセクションに分類されていることがわかります。

  1. クラウド ソリューション環境内のアクセスの構成
  2. ネットワーク セキュリティの構成
  3. データ保護の確保
  4. クラウド ソリューション環境内のオペレーションの管理
  5. コンプライアンスの確保

これらを更におおざっぱに見ていくと、2つの観点が重要視されていることがわかります。

  • Google Cloud の境界セキュリティ
  • 個人情報など重要データの保護

前者は「誰が」「どのデータやサービスに」「どんなアクションを行えるのか」という IAM の概念やそれらの管理手法、そしてネットワーク的なアクセス経路の制御方法を問われる内容です。

後者は「どんなデータが」「どんな方法で保護/秘匿/管理されているのか」というデータそのものを守る方法を問われる内容です。

大きく上記2つの背景と観点を理解しておけば、Google Cloud のプロダクトだからといって身構える必要はありません。

基本知識としてのセキュリティ用語

出題範囲

出題範囲をもう少し細かく見ていきましょう。
アクセス制御とデータ保護の観点でそれぞれポイントとなる点や背景が異なります。

アクセス制御は、IAM や GCDS といったアカウント管理（制御/認証認可）の理解を深めておくとよいでしょう。

データ保護は、個人情報など機密データとして扱うべきデータの取り扱いや、データの種別・形式・目的によって異なる管理方法を学んでおく必要があります。

アクセス制御 データ保護
・IAM の基本
・アカウント管理（LDAP / AD / IdP / IDaaS）
・SAML の基本
・VPC ネットワークの接続構成
・ファイアウォール
・プライベートアクセスを実現する方法		 ・個人情報（PII）を Google Cloud で取り扱う方法
・VPC Service Controls 概要
・Cloud Data Loss Prevention 概要
・Security Command Center 概要
・Cloud KMS 概要

試験の対策

勉強方法

基本的に Google Cloud の試験には以下の方法が有効だと筆者は考えています。
既にいくつかのGoogle Cloud 資格（特に Professional Cloud Architect）を取得していればハードルはかなり下がります。

一問一答プロダクト概要

試験要項として公表されている Google Cloud のプロダクトについて、要点のみ解説していきます。
すべて問われるというわけではなく、どの内容が問われるかはランダムです。
可能なかぎり、「IdP」と「組織のコンプライアンス準拠」の観点は理解を深め、Google Cloud でどのように要件へ対応していくかを理解しておきましょう。

IAM【重要！】

IAM は「だれが」「何に」「どんなことを行うのか」を認証認可によって許可します。
言い換えると「どのIdentity（Google アカウント）が」「どのリソースに」「どんな操作を実行するのか」ということです。

例えば、「ユーザ Hoge が GCS バケット内のオブジェクトへの管理を行う」のであれば、プロジェクトの IAM でユーザ Hoge に ストレージ オブジェクト管理者（roles/storage.objectAdmin）を付与します。

ロール

ロールには大きく分けて3種類存在します。
後述する IAM のベストプラクティス「最小権限の原則」に大きく関わるため、十分理解しておきましょう。

  1. 基本ロール
  2. 事前定義ロール
  3. カスタムロール
ロール種別 設定単位 説明
基本ロール 組織
フォルダ
プロジェクト		 オーナー、編集者、閲覧者、参照者の4つが用意されており、組織を除くほとんどのサービスに対する非常に広域な権限を含むため本番環境では非推奨。
（例：編集者はリソース自体に対して編集権限を有する、等）
事前定義ロール 組織
フォルダ
プロジェクト
リソース（例外アリ）
データセットやテーブル等（例外アリ）		 Google Cloud によって管理・提供されている、特定のサービスへのアクセスを細かく制御する事前定義された権限セット。
例として、上述したストレージ オブジェクト管理者が該当する。
カスタムロール 組織
フォルダ
プロジェクト
リソース（例外アリ）
データセットやテーブル等（例外アリ）		 事前定義ロールよりも細かく権限を定義したい場合、ユーザ自身で権限を取捨選択しカスタマイズしたロールを新規に定義することが可能。

Cloud Identity

Cloud Identity は、Google Cloud が提供する IDaaS（Identity as a Service） ソリューションです。
Google Cloud では Gmail のメールアドレスや Google Workspace 等、いくつかのアカウント作成方法が提供されていますが、Cloud Identity もその1つです。
Google Workspace との差別化については下記の記事も参考になります。

Cloud Identity を利用することで、Google Cloud にアクセスするアカウントを一元管理するだけでなく、多要素認証（MFA）やシングル サインオン（SSO）機能も提供します。
企業で Google Cloud を利用する場合、Cloud Identity or Google Workspace によるアカウント管理と、組織ノードによるプロジェクト管理が必須と言えるでしょう。

Google Cloud Directory Sync（GCDS）

GCDS は Microsoft Active Directory または LDAP サーバと Cloud Identity との間で、アカウント情報を連携・同期するためのサービスです。

ポイントとなるのは以下の点となります。

  • Google アカウントに "統合" はされない
  • MS AD / LDAP ➜ GCDS の一方向同期のみ
  • GCDS に Googleアカウント/既存の非Googleアカウントを混在して管理可能
    • 除外することも可能

GCDS
https://tools.google.com/dlpage/dirsync

他の IdP と接続する際のベストプラクティス

ベストプラクティスのうち主要な点を抑えます。
gcds-bestpractice
図：他の IdP との接続

  • 一方向の同期を自動化する
    • 同期する特定のソース（MS AD / LDAP）を信頼するよう指定する
  • シングルサインオンの発行者を google.com に指定する
    • この設定はドメイン固有のものであり、 google.com はデフォルト値
  • 管理者ユーザの設定
    • SSO を無効化することを推奨
    • 2段階認証の利用を推奨
    • 多要素認証の利用を推奨
  • Workspace 全体の委任は非常に強力な権限を必要とするため、可能な限り OAuth の利用を推奨

Cloud Data Loss Prevention（Cloud DLP）【重要！】

Cloud DLP は特に機密性の高いデータを検出、分類、保護するためのフルマネージドサービスです。
特に機密性の高いデータとは、主に個人情報（PII）等が含まれます。
氏名、住所、生年月日、電話番号、メールアドレス、カード番号等、多くの機密データが取り扱われる現代のシステムでは非常に重要なプロダクトとなっています。
dlp-encrypted
図：Cloud DLP の処理フロー

Cloud DLP ができることは大きく2つに分類できます。

  1. PII の自動検知・分類
  2. PII の保護（匿名化/伏字化）

「PII の自動検知・分類」は 氏名/住所/電話番号 といった PII を自動で検知する機能です。
検知対象は以下のリソースに格納されたデータが対象となります。
Cloud Spanner や Cloud SQL 等は対象とならない点に注意してください。

  • Cloud Storage
  • BigQuery
  • Cloud Datastore

検知可能なファイル対象は以下の通りです。
あまり奇特なファイル形式でなければ検知可能と考えてよいと思います。

  • Text
  • Image
  • バイナリ
  • Word/Excel/PowerPoint
  • PDF
  • Apache Avro

PII の保護方法

「PII の保護（匿名化/伏字化）」を実現するには、大きく3つの暗号化方式が提供されています。
それぞれの特徴を見ていきましょう。

暗号化方式 暗号アルゴリズム 特徴 備考
確定的暗号化方式 AES-SIV ハッシュ値を生成する。
サロゲートアノテーションを付加する。		 暗号化前のフォーマット（文字列長）を保持しない。
要件がマッチするならば最も推奨できる方式。
フォーマット暗号化方式 FPE-FFX サロゲートアノテーションを付加する。 暗号化前のフォーマット（文字列長）を保持する。
暗号ハッシュ HMAC-SHA-256 セキュアハッシュを利用する。 上記2つと異なり再識別不可。
ハッシュ出力長は常に同じ。

データの特性や要件に従い最も推奨できる暗号化方式が選択できるかは、この暗号化方式を理解しているかどうかという点で重要です。
要件から的確に最適な方式を選択できるよう、以下の選択フローは必須で覚えましょう。
dlp-encrypt-flow
図：Cloud DLP の暗号化方式 攻略フロー

Cloud KMS 【重要！】

Cloud KMS は Google Cloud 上で利用する暗号鍵を一元管理するためのサービスです。
AES256、RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384といった代表的なアルゴリズムに対応しています。
対称暗号鍵および非対称暗号鍵にも対応しています。

Cloud KMS の特徴としては、KeyとKeyringの関係性です。
kms-keyring
https://cloud.google.com/kms/docs/envelope-encryption?hl=ja

  • Keyring の中にいくつかの Key が格納されている
  • Key の中にいくつかの Key バージョンが格納されている
  • Key はローテーションされ、Key バージョンとして保存、復号化に用いられる

また、鍵を別の鍵で暗号化する「エンベロープ暗号化」は重要なポイントですのでぜひ理解しておきましょう。
envelope-encryption
図：エンベロープ暗号化

  1. DEK（Data Encrypt Key）を生成
  2. DEK でデータを暗号化
  3. 2 で暗号化したデータと使用した DEK をラップして KEK（Key Encrypt Key）で暗号化
  4. 3 で使用した KEK を Cloud KMS で管理
エンベロープとは

エンベロープは外皮や覆うという意味があるので、暗号化されたデータを外皮と考えると理解しやすいかもしれません。

各プロダクトで使われる鍵の種類

Google Cloud の鍵は大きく3種類あります。
それぞれの特性やユースケースは理解しておきましょう。

鍵の種類 説明
GMEK Google Cloud が鍵を管理する。
Google Cloud がデフォルトで使用する鍵。
全プロダクトに対応。
CMEK ユーザが鍵を Google Cloud 上で管理する。
プロダクトにより対応状況が異なる。
CSEK ユーザが鍵を管理する。
GCE/GCSのみサポートする。

まず、Google Cloud 上で保存される全てのデータはデフォルトで暗号化されます。
その際、通常は Google Cloud 管理の GMEK（Google Managed Encryption Key）が利用されます。
これは全てのプロダクトで利用可能であり、特別な暗号化要件がない限りは GMEK によるデータ暗号化で十分です。

一方、社内のセキュリティポリシーとして、独自の鍵を利用しなければならないときがあります。
このとき、KEK を Cloud KMS で管理してよい場合は CMEK（Customer Managed Encryption Key）が利用できます。

KEK も内部で管理したいといった特殊な要件の場合、CSEK（Customer Supplied Encryption Key）の選択肢があります。
しかし、CSEK は GCE/GCS でしかサポートしていないため注意が必要です。

データ保存時の暗号化

Google Cloud 上で保存されるデータにおいて使用される暗号アルゴリズムは、AES-256 です。
これは2015年ごろまでに作成された一部のリソースを除き、 原則 AES-256 です。

保存データに関する FIPS の遵守

Google の本番環境では、FIPS 140-2 認定取得済みの暗号化モジュールが使用されています。

保護レベル

Cloud KMS では保護する暗号鍵のレベルに応じて、様々な管理方法が提供されています。
ekm
図：Cloud KMS の鍵の管理方法

通常は Software というレベルで管理されています。
（それでも十分強固ではあります）

さらに料金は高くなるものの、Google Cloud 管理の HSM（Hardware Security Module）によって管理することも可能です。

サポートされる外部鍵管理パートナー内で管理する鍵（EKM）を使用して、Google Cloud 内のデータを保護することも可能です。

Secret Manager

Secret Manager は、データベースパスワード、APIキーといった機密情報を暗号化して保存するサービスです。

Cloud KMS との違いは、暗号鍵を管理するのが Cloud KMS の目的に対し、Secret Manager は Cloud KMS では管理できないアプリケーション等が使う機密情報（例: データベースパスワード、APIキー等）を保存する目的で利用するのが異なる点です。

  • 暗号鍵を保管したい：Cloud KMS
  • テキスト形式の機密情報を保管したい：Secret Manager

secretmanager-select-flow
図：Secret Manager と Cloud KMS と Cloud DLP の選択フロー

Security Command Center 【重要！】

Security Command Center（SCC）は、Google Cloud 上で使用しているサービスの脆弱性や脅威となりうる設定を検知することができるサービスです。

SCC には、無償版のスタンダードティアと有償版のプレミアムティアがあります。
2つのティアごとの機能の違いについては、弊社エンジニアが投稿している記事が参考になりますので、ぜひご確認ください。

Security Health Analytics

Standard Premium
✅ ✅

Security Health Analytics は Google Cloud 内の脆弱性を検知する、マネージド脆弱性スキャン機能です。
検知可能な対象としては、「一般的な脆弱性」と「明らかな構成ミス（Firewallに過剰な穴がある、IAM権限が余剰である、等）」です。
「一般的な脆弱性」として検知する基準は主に「CIS Benchmark」に基づいています。
対応しているプロダクト は以下のとおりです。

  • Cloud Monitoring/Logging
  • Compute Engine/GKE
  • Cloud Storage
  • Cloud SQL
  • Cloud IAM
  • Cloud KMS
  • Cloud DNS

スキャンモードは3つに分かれており、それぞれ検出機能に応じて自動でスキャンモードを切り替えます。

モード 説明
バッチスキャン 1日に2回以上定期実行する。
12時間毎 or 6時間毎に実行を選択する。
リアルタイムスキャン リソース構成の変更が発生する度にリアルタイムに実行する。
混合モード リアルタイムスキャンでは対応できないリソースの場合、例外的にバッチスキャンを実行する。

Web Security Scanner

Standard Premium
✅ ✅

Web Security Scanner は GKE、GAE、GCE 上に展開された WEB アプリの脆弱性スキャン機能です。
Web Security Scanner は OWASP Top10 に準じた脆弱性評価を行います。

  • XSS
  • SSRF
  • SQLi
  • パスワードの平文公開
  • リポジトリの公開

Web Security Scanner を利用するうえでのベストプラクティスのうち、重要なものを解説します。

  • 本番環境での実行は非推奨、検証環境等の影響がない環境で実施を推奨
  • テスト用のアカウントを作成し利用することを推奨
  • テスト時にクリック等による誤作動や動作をしてほしくないボタンには、CSSクラスの「inq-no-click」を利用すること
  • テスト前に必ずアプリケーションやデータのバックアップを取得したうえで実施すること
  • テストしてほしくないURLがあれば除外指定をすること

Anomaly Detection

Standard Premium
✅ ✅

Anomaly Detection はその名の通り異常検知を目的とした機能です。
具体的には、サービスアカウントの認証情報が漏洩していたり、不正利用の可能性がないか、VMの不正利用の可能性がないかを検知します。

Event Threat Detection

Standard Premium
- ✅

Event Threat Detection は脅威インテリジェンス・機械学習などを使用して、組織ログをモニタリングし、脅威を検出する機能です。
Cloud Logging 等のログベースでデータの不正持出しやマルウェアの攻撃といった脅威を検出することができます。

Container Threat Detection

Standard Premium
- ✅

Container Threat Detection はコンテナ ランタイム攻撃の検出する機能です。
GKE 上に専用ノードを立ち上げ、ノードの意図せぬ変更やコンテナへの攻撃を検出することができます。

Virtual Machine Threat Detection

Standard Premium
- ✅

Virtual Machine Threat Detection は VM インスタンス内で実行されている暗号通貨マイニング アプリケーションを検出する機能です。
具体的にはメモリ内を検査し、暗号通貨マイニング アプリケーションが起動していないかを検出します。

VPC Service Controls（VPCSC） 【重要！】

Google Cloud ではリソースへの操作（編集や閲覧等）を行う際に、API を利用します。
VPCSC とは、この APIを仮想的な境界を用いて保護することで、境界外からの不正なアクセスを防止するとともに、境界外へのデータの漏洩を防ぐことを目的としたサービスです。

  • GCSバケット内にあるデータをコピーされたくない
  • BQデータセット内にあるデータを閲覧されたくない
  • Spannerデータベース内にあるデータを外部に持ち出されたくない

また、VPCSC を設定することで、IAM 誤設定やサービスアカウントキー漏出による情報漏洩を防ぐことにも繋がります。


VPCSC を構成する主要コンポーネント一覧

コンポーネント名 概要説明
サービス境界 APIを保護するコンポーネント
アクセスレベル Google Cloud へのアクセス制限を行うコンポーネント
境界ブリッジ サービス境界間の通信を許可するコンポーネント、全ての通信を許可する
Ingress/Egress ルール 境界ブリッジよりも細かいメソッド単位のルールを制御する

サービス境界

サービス境界は、Google Cloud のプロジェクト単位で API を保護するための設定です。
service_perimeter
図：サービス境界
サービス境界に含めたプロジェクトは、境界外から境界内への通信はブロックされます。
また、API を使った境界内から境界外への通信もブロックされます。

保護するAPI は、このサービス境界で設定します。
また、サービス境界を作成する際に、作成した任意のアクセスレベルを指定することで、外部からの API アクセスを制御することができます。

アクセスレベル

アクセスレベルは、Google Cloud のサービスであるアクセスコンテキストマネージャで作成する設定です。
access_levels
図：アクセスレベル
アクセスレベルをサービス境界に組み込むことで、IPアドレスやデバイス等の条件により境界外から境界内へのリソース（API）のアクセス許可設定を行うことが可能になります。
アクセスレベルで許可する設定は AND や OR といった条件で複数設定することもできます。

境界ブリッジ

境界ブリッジは、異なるサービス境界のプロジェクト間での通信を可能にするための境界設定です。
perimeter_bridge
図：境界ブリッジ
境界ブリッジを設定する理由として、VPCSCの下記の制約があります。

  • プロジェクトは、複数の異なるサービス境界に設定することができない
    • 1つのプロジェクトは、1つのサービス境界にのみ設定可能

そのため、複数プロジェクト間の通信を設定する場合は、サービス境界のみでは設定できません。
そこで、異なるサービス境界間で設定したプロジェクト同士の通信を許可するために使う設定が、境界ブリッジになります。
境界ブリッジを設定することで、ブロックされているサービス境界の境界外への通信（異なる境界間）を双方向で可能にします。

Ingress/Egress ルール

ingress_egress_rule

Ingress/Egress ルールでは、API のメソッド単位でよりきめ細やかな制御を定義することができます。

Ingress ルールでは、境界外から境界内のリソースに対しての上り（内向き）を定義します。
Egress ルールでは、境界内から境界外に対しての下り（外向き）を定義します。

ルールは from と to のブロックで宛先と通信元を定義して構成されます。

Organization Policy

Organization Policy（組織ポリシー）は、Google Cloud における最上位リソースの「組織」からその配下リソースに特定の設定や制限を強制させることができるサービスです。
これにより、コンプライアンス準拠を徹底することができます。

具体的にどういった制約が設定できるのか、設定方法、継承や違反といった詳細については、弊社エンジニアが投稿している記事が参考になりますので、ぜひご確認ください。

よくあるケースとして特に利用頻度が高いものとしてはこのあたりです。

  • SAや認証認可に関する制約
  • VPC等のネットワーク関連の制約
  • ロケーションなどリソース全体の制約

例えば、以下のようなケースにおいてどのような制約が有効か、指定する値やパラメータはどのようなものか、は理解しておくとよいでしょう。

ユースケース 設定値
SA キーの利用を禁止したい iam.disableServiceAccountKeyCreation
デフォルト SA を無効化したい iam.automaticIamGrantsForDefaultServiceAccounts
VPC Peering の接続を一部に制限したい constraints/compute.restrictVpcPeering
共有 VPC のサブネット払い出しを一部に制限したい constraints/compute.restrictSharedVpcSubnetworks
リソースのロケーションを限定したい constraints/gcp.resourceLocations

Container Analytics 【重要！】

Container Analytics は Artifact Registry に格納されたコンテナの脆弱性スキャンを提供するサービスです。
Google Cloud の DevSevOps への取り組みとして非常に重要なポイントとなります。

Binary Authorization 【重要！】

Binary Authorization は、Artifact Registry がホストするコンテナに署名をすることで、GKE や Cloud Run にデプロイできるコンテナイメージを制御できるサービスです。

  • 本番環境で不正なコンテナイメージを実行させないように制限したい
  • 単体テストなどをクリアしていないコンテナイメージをデプロイできないようにしたい

Container Analytics 同様、Google Cloud の DevSecOps への取り組みとして非常に重要なポイントとなります。

証明書の利用

Cloud Build のビルドステップ中に、管理者（認証者）による署名プロセスを挟むことで正規の承認されたコンテナイメージのみが利用されるように開発フローを統制することができます。

binary-authorization-flow
図：Binary Authorization の利用シーン

Compute Engine

Compute Engine を脅威から保護するためのセキュリティオプションを解説します。
Compute Engine を構築する際、セキュリティ要件が高い場合には、いくつかのセキュリティオプションを利用してセキュアなインスタンスを構築する必要があります。

Confidential VMs

Confidential VMs は Compute Engine VM の一種で、使用中はメモリ内データを常に暗号化し、エンドツーエンドの暗号化とデータの保護を保証します。
そのため、機密データを取り扱うワークロードに最適です。

Shielded VM

Shielded VM は、Compute Engine のセキュリティオプションの1つです。
Shielded VM は、インスタンスがブートレベルまたはカーネルレベルのマルウェアやルートキットによって改ざんされていないことを保証するものです。

  • セキュアブート
  • 仮想トラステッド プラットフォーム モジュール（vTPM）対応のメジャード ブート
  • 整合性モニタリング

VPC ネットワーク

VPC ネットワークまたはそれに関連するリソースやコンポーネントも基礎であるからこそ見直しておきたい点です。
例えば、VPC 同士のセキュアな接続方法から Cloud SQL のような他のリソースへのセキュアな接続方法まで、もう一度おさらいしておきましょう。

VPC Peering

2つの異なる VPC ネットワークのワークロード同士を内部IPアドレスで相互通信させる場合、まず最初に検討すべきは VPC Peering です。
VPC Peering を利用して VPC ネットワーク同士を接続すると、その間のトラフィックは Google Cloud のネットワーク内に留まり、パブリックインターネットに公開されずにアクセス可能となります。
vpc-peering
図：VPC Peering

VPC Peering は同じ組織や同じプロジェクトに互いが属しているかどうかに関わらず、接続できるという便利な点があります。
一方で、推移的ピアリングはサポートしていない という点には注意をしてください。
接続された隣同士の VPC としか疎通できないと覚えましょう。

共有 VPC

共有 VPC は同じ組織に属する複数のプロジェクト間で VPC ネットワークおよびそのコンポーネント（サブネット、FWルール、ルート等）を一元管理したいときに利用します。
共有 VPC は親子構造にも似ていて、共有 VPC を管理するプロジェクトを「ホストプロジェクト」、サブネットなどのリソースを利用するプロジェクトを「サービスプロジェクト」と呼びます。
xpn
図：共有 VPC

「利用者」と「管理者」の責任範囲を明確に分けることができるというのがポイントです。
インスタンスの作成などはサービスプロジェクトの管理者に委任し、組織のネットワーク管理者/セキュリティ管理者はネットワークリソースだけに集中することができます。

例えば、利用者が許可なく FW ルールを変更してしまう、サブネットを無闇に乱立させてしまう、といった状況を防ぐことができます。

VPC Flow Log

VPC Flow Log は、GCE インスタンスによって送受信された VPC ネットワーク フローのサンプルが記録されます。
Flow Log を利用することで、以下の点で役立ちます。

  • ネットワーク モニタリング
  • フォレンジック
  • リアルタイム セキュリティ分析
  • および費用の最適化

vpclog-vs-fwlog
図：VPC Flow ログ と FW ログの違い

ログ種別 記録される内容
FW ログ FW にマッチしたかどうかを記録する
VPC Flow ログ VPC 自体の送受信結果を記録する

Firewall Rules 【重要！】

VPC Firewall Rules

ファイアウォールを構成するうえで重要なのはフィルタリング条件を選定することです。

SA は GCE インスタンスにつき1つまでしか設定することができませんが、ネットワークタグは複数設定することができます。
つまり、GCE インスタンスに厳密に適用したい場合、SA によるフィルタリングが推奨できますが、複数の条件でルールを構成したい場合はネットワークタグが有用です。

階層型ファイアウォール

また、階層型ファイアウォールについても理解を深めましょう。
ポイントとなるのは評価順序とスコープです。

5

詳しくは弊社エンジニアが投稿している記事が参考になりますので、ぜひご確認ください。

Private Google Access 【重要！】

内部IPアドレスしか持たない GCE インスタンスが Google API へアクセスする場合、Private Google Access を利用することで内部経路を利用したアクセスが可能になります。
他のリソースへのアクセスに必須なサービスなので、これも覚えておきましょう。

Packet Mirroring

Packet Mirroring は VPC ネットワークへ到達したトラフィックを複製し、フォレンジック用に転送するサービスです。
ペイロードとヘッダーを含むすべてのトラフィックとパケットをキャプチャします。

トラフィックを複製することのメリットとして、以下のような点があげられます。

  • IDS等に連携して持続型の脅威を検出する
  • パケットを検査して異常なペイロードや、様々なベクトルの脅威を検出するきっかけを作る

特に PCI DSS 等の高度なエンタープライズセキュリティ要件が問われるような場合、検査・検出・分析で役立つことがあります。

Cloud NAT

Cloud NAT は VPC ネットワークを経由したトラフィックのうち、内部IPアドレスしか持たないホストがパブリックインターネットへアクセスするときに使用するサービスです。

また、Serverless VPC Access を併用すれば、送信元IPアドレスが不定な GAE/Cloud Run/GCF からの通信でも送信元IPアドレスを固定化することは可能です。
宛先が送信元IPアドレスを制限している場合であっても、対応することができます。

Cloud Armor

Cloud Armor は GCLB のバックエンドを保護するための Firewall/WAF サービスです。
DDoS攻撃やアプリケーションへの攻撃を防ぐのに役立ちます。

重要なポイントとしては、セキュリティポリシーの基本とユースケース、ベストプラクティスは目を通しておくことを推奨します。

Cloud Interconnect

Cloud Interconnect はオンプレミスと Google Cloud を閉域網によって物理的に接続するためのサービスです。
オンプレミスと Google Cloud とを機密性と高可用性を保証しながら相互接続する場合に利用される重要なサービスです。
Interconnect を利用することで一度もパブリックインターネットへトラフィックが晒されることなく安全に通信することが可能です。

Cloud Interconnect には3つの契約体系があります。

Partner Interconnect Dedicated Interconnect Cross-Cloud Interconnect
h:300
Cloud Console より引用 		h:300
Cloud Console より引用 		h:300
Cloud Console より引用
・サービスプロバイダを介して接続する
・10Gbps以上の帯域が不要な場合に推奨		 ・Google Cloud と直接接続する
・10Gbps以上の大容量帯域が必要な場合に推奨		 他のクラウドプロバイダと直接接続する
50Mbps 〜 50Gbps 10〜80Gbps or 100〜200Gbps 10〜80Gbps or 100〜200Gbps

Cloud VPN

Cloud VPN はサイト間 VPN をオンプレミスと Google Cloud で構成する VPN ゲートウェイ サービスです。

ここで、先の Cloud Interconnect とユースケースを比較します。
オンプレミスとの相互接続において費用対効果を検討し、Cloud VPN と Cloud Interconnect のどちらを検討すべきか十分に理解しておきましょう。

interconnect-vs-vpn
図：Dedicated Interconnect と Partner Interconnect と Cloud VPN の比較

Certificate Authority Service

Certificate Authority Service（CAS）は プライベート 認証局を Google Cloud 内に構築し、管理と運用の自動化を行うサービスです。

CAS には既存のプライベート認証局と大きく有利な点があります。

  • CA をグループ化できる
  • CA のローテーションが容易
  • エンタープライズのコンプライアンス要件を満たす監査基準
    • ISO 27001、27017、27018、SOC1、SOC2、SOC3、BSI C5、PCI、FedRAMP 監査適合
    • FIPS 140-2 レベル 3 で検証された秘密鍵保護に Google Cloud HSM をデフォルトで使用

少し細かいですが、CAS がサポートする証明書の種類についても理解しておくとユースケースが理解しやすくなります。

  • クライアント証明書
  • サーバ証明書
  • mTLS 証明書
  • Code Sign
  • e-mail Protection

構成コンポーネントは以下の通りです。
cas
図：Certificate Authority Service

  • CA
    • Root CA：Root 認証局（必須）
    • Subordinate CA：中間認証局（任意）
  • CA Pool：CA を束ね、管理し、ローテーション等を行う CA の集合（必須）
  • 証明書：Root CA または Subordinate CA を利用し発行する（必須）

このうち、ポイントとしておさえておきたいのは CA Pool のティアについてです。
CA Pool には DevOps と Enterprise の2つのティアを選択することができます。

ティア 規模 ユースケース 備考
DevOps 小〜中規模向け マイクロサービスやコンテナ等、大量で短期的な利用時に推奨 ・発行された証明書は保存されない
・証明書の失効がサポートされていない
Enterprise 中〜大規模向け ライフサイクル管理が重要なデバイス（IoT）等、少量で長期的な利用時に推奨 CA の QPS クォータが DevOps の1/3程度

Enterprise ティアは以下のメリットがあります。

  • 各CAの証明書を発行できる（AIA）
  • 証明書の失効リストが発行できる（CRL）
    • CRL は Google マネージド/ユーザ指定 の GCS バケットに出力することができる

試験準備

先に取得しておくべき資格

冒頭でも述べたとおり、以下の資格については必須知識と言えるほど基礎的なものです。
まだ取得していない方はまずはこちらを取得して Google Cloud の基礎を学び、そのうえで応用として本試験にチャレンジすることを強く推奨します。

  • Associate Cloud Engineer（ACE）
  • Professional Cloud Architect（CA）

模擬試験

公式案内にもある通り、模擬試験を受験してご自身の理解度をチェックしてみてください。
必ずしも模擬試験の傾向や問題そのものがそっくり出題されるわけではないですが、あくまで参考値として理解度を知ることができます。
（ここで点数が取れなくても落ち込むほどのものではありません）

模擬試験を受けて、Cloud Security Engineer 試験で出題される可能性のある質問の形式と内容を把握します。

試験申し込み

ここまできたら試験を申し込むだけです。
Webassessor にて任意の日時で受験申し込みをし、当日受験をすれば完了です。
資格試験あるあるですが、受験申し込みをするまでに自分を奮い起こすのが1番の難関です。

結果受領

リモート受験/現地受験どちらであっても一時的な合否はすぐ確認できます。
「合格」という文字が表示されたら無事に合格ラインに到達できたという判定です。

筆者の場合は最終的な合否結果を2日ほどで受け取ることができました。

新規取得タイトル：おめでとうございます。Google Cloud Certified として認定されました。
継続更新タイトル：認定資格延長のお知らせ

pse_successfull_mail_noti
SS：合格通知

おわりに

受験した感想（2022/11）

正直な感想として、身構えるほどの難易度ではなかった、というのが結論です。
これは Google Cloud の SIer として従事した経験というのも十分影響を与えていますが、「Associate Cloud Engineer」「Professional Cloud Architect」の2資格に合格できた人であれば正直難易度は高くないと感じると思います。

ACE＋CA＋基本的なDLPとIdPの理解があれば十分合格ラインを突破できる試験ですので、肩の力を抜いてラフに受験してみることをお勧めいたします。
（少なくとも日本語ローカライズされていない試験と比べれば言語の壁がないため難しくありません）

受験した感想（2024/11）

前回の受験時と同様に、ハードルは高くないと感じました。
今回はスケジュールの都合で事前学習0で挑みましたが、全問即答できる程度に余裕をもって合格することができました✌
次回更新もがんばります！

まとめ

書き始め当初よりかなりボリューミーな記事となってしまいましたが、ここまで読んでいただきありがとうございます。
ここまで読破し理解を深めることができたならば、十分合格できる知識量をお持ちのはずです。
よい結果を迎えられることを祈ります。

また、当然試験内容は随時新しいものへ更新されてしまうため、この記事を閲覧された方は可能な限りお早めの受験を推奨します。

Discussion