🐯

Professional Cloud Security Engineer 完全攻略ガイド2022

2023/01/04に公開1件

GCP

Security

資格

idea

はじめに

こんにちは、クラウドエースで SRE ディビジョンに所属している Shanks と申します。

この記事を書き始めたころ、年の瀬を迎えてクラウドエースでも資格取得ラッシュの慌ただしい日々が続いていました。
そんな駆け込みのタイミングで、11月に筆者も Professional Cloud Security Engineer を取得して無事に新年を迎えられました。

本日は年のはじめに 「Professional Cloud Security Engineer 完全攻略ガイド2022」 と題して、合格体験記＋攻略記事を投稿したいと思います。
おそらく 2023 年で最初に投稿されるであろう Professional Cloud Security Engineer の最新情報です。
新年早々 Google Cloud の資格取得を目指す人に有益な情報となれば幸いです。

ターゲットとなる読者層

Professional Cloud Security Engineer をこれから受験しようとしている人
2年ほど前に受験し、有効期限が近づいている再受験予定の人
Associate Cloud Engineer 取得済みの人（受験要項としては必須でなくても、知識としては必須）
Professional Cloud Architect 取得済みの人（強く推奨）
Google Cloud を利用したセキュアなインフラ開発経験（少なくとも1〜2年は推奨）

この記事でやること・やらないこと

やること

公開されている範囲の傾向と出題範囲の解説
学習しておくべきコンテンツ（必須・推奨含む）
合格に役立つ資料や学習コンテンツの紹介

やらないこと

試験内容のリークにつながる情報公開
- どこがでるか、どういう問題がでるかの情報は非公開

注意事項

試験を知る

出題背景

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

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

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

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

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

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

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

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

出題範囲

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

アクセス制御は、IAM や GCDS といったアカウント管理（制御/認証認可）の理解を深めておくとよいでしょう。
また、あわせて VPC ネットワークの接続に関する知識や、セキュアな通信経路の確保についても知っておきましょう。

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

アクセス制御

アクセス制御に関しては、大まかに以下の点を理解しておくとよいでしょう。

IAM の基本
Cloud Identity と Google Cloud Directory Sync（GCDS）を使ったアカウント管理（LDAP/AD）
SAML の基本
2 要素認証プロセス
VPC ネットワークの接続構成
IAP、Cloud Armor、ファイアウォールルールを使ったネットワークアクセス制御
ロードバランシングの基本
プライベートアクセスを実現する方法

データ保護

データ保護に関しては、大まかに以下の点を理解しておくとよいでしょう。

個人情報（PII）を Google Cloud で取り扱う方法
VPC Service Controls 概要
Secret Manager 概要
Cloud Data Loss Prevention 概要
Security Command Center 概要
Cloud KMS 概要

出題傾向

出題傾向は人それぞれのため正確にお伝えすることはできません。
そして、模擬試験の傾向がそっくりそのまま出るわけでもありません。

また、Google Cloud の試験は過去問や点数を公開しておらず、「Google Cloud テクノロジーを使用した特定の職務の遂行能力を評価する」のが目的です。
そのため試験に合格するのが目的ではなくスキルの証明として考え、ここで解説しているものを吸収していただければと思っています。

試験の対策

勉強方法

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

関連するプロダクトの公式ドキュメントを確認する
- 概要、クイックスタート、注意事項、料金、既知の問題や制限事項をよく読む
- ベストプラクティスが紹介されていれば、ほとんど理解できるまで熟読する
プロダクトの事例を確認する
- どのようなアーキテクチャで使われたのか理解する
- プロダクトの選定理由などもわかれば注視する
手元で試せるプロダクトはまず触れてみる
- クイックスタート等を通じて実際に触れることでプロダクトのイメージを具体化させる
Coursera の公式トレーニングを受講する

参考資料

Coursera：Security Best Practices in Google Cloud

Coursera：Managing Security in Google Cloud

Coursera：Hands-On Labs in Google Cloud for Security Engineers

一問一答プロダクト概要

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

IAM

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

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

ここではロールとサービスアカウント（SA）の重点ポイントのみ解説します。

ロール

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

基本ロール
事前定義ロール
カスタムロール

ロール種別	設定単位	説明
基本ロール	組織フォルダプロジェクト	オーナー、編集者、閲覧者、参照者の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つに分類できます。

PII の自動検知・分類
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 の暗号化方式攻略フロー

Google Cloud 公式のデモアプリも公開されていますので、動作の雰囲気を知ることもできます。

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
図：エンベロープ暗号化

DEK（Data Encrypt Key）を生成
DEK でデータを暗号化
2 で暗号化したデータと使用した DEK をラップして KEK（Key Encrypt Key）で暗号化
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 内のデータを保護することも可能です。
ただし、Cloud EKM 特有の考慮事項もありますので、運用の際は細心の注意を払うようご注意ください。

上記の3つが保護レベルの柱となりますので、違いと使い分けを理解しておきましょう。

Secret Manager

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

Cloud KMS との違いは、暗号鍵を管理するのが Cloud KMS の目的に対し、Secret Manager は Cloud KMS では管理できないアプリケーション等が使う機密情報（例: データベースパスワード、APIキー等）を保存する目的で利用するのが異なる点です。
secretmanager-select-flow
図：Secret Manager と Cloud KMS と Cloud DLP の選択フロー
暗号化したデータの復号化に使う 鍵を保管 したいなら Cloud KMS を、
テキスト形式の機密情報を保管 したいなら Secret Manager を、
といったように使い分けてください。

Secret Manager に保管された文字列を復号化して参照する場合、API を用いてアクセスすることで参照できます。
また、Secret Manager を参照した際の転送データは TLS で暗号化され、保存データは AES-256 で暗号化されます。
主に、以下のようなテキスト形式の機密データを保管するのに推奨されます。

パスワード
APIキー
TLS証明書

Secret Manager のベストプラクティスのうち、以下の点が重要です。

保管している機密データへのアクセスは最小権限の原則に従い、IAM の権限管理で不正なアクセスから保護する
IAM だけでなく、VPC Service Controls も利用した多層的な防御を構成する
ファイルシステムや環境変数を利用せず、Secret Manager API を直接使用して保管された機密情報へアクセスする

Security Command Center

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

検知された脆弱性や脅威は、Google Cloud のダッシュボードに表示したり Pub/Sub にメッセージをパブリッシュすることができます。
SCC には、無償版のスタンダードティアと有償版のプレミアムティアがあります。
2つのティアごとの機能の違いについては、弊社エンジニアが投稿している記事が参考になりますので、ぜひご確認ください。

ここでは覚えておくべき以下の機能について解説します。

Security Health Analytics
Web Security Scanner
Anomaly Detection
Event Threat Detection
Container Threat Detection
Virtual Machine Threat Detection
Rapid Vulnerability Detection
VM Manager の脆弱性レポート

Security Health Analytics

Standard	Premium
✅	✅

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

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

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

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

脆弱性に関する検出

Web Security Scanner

Standard	Premium
✅	✅

Web Security Scanner は GKE、GAE、GCE 上に展開された WEB アプリの脆弱性スキャン機能です。
スタンダードティアでは手動実行のみをサポートしますが、プレミアムティアに課金することで週1回のマネージドスキャン（自動実行）を利用することができます。
しかし、独自の認証情報を利用する場合は手動実行のカスタムスキャンでなければなりません。
また、Web Security Scanner は外部に公開された WEB アプリのみをサポートしているため、内部向けのアプリケーションには利用できません。

Web Security Scanner は OWASP Top10 に準じたセキュリティスキャンを実行することが可能ですので、以下のような脆弱性評価を行いたい場合に有用です。

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

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

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

Anomaly Detection

Standard	Premium
✅	✅

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

Anomaly Detection は SCC を有効化した時点でティアに関係なく自動的に有効になるデフォルト機能の1つです。
検出結果は SCC のダッシュボードで確認することができます。

この機能の中身については完全ブラックボックスのため細かく指定したりすることは困難ですが、プロジェクトと GCE インスタンスで検出されたセキュリティ異常を検知することができるという点は覚えておきましょう。

異常検出

Event Threat Detection

Standard	Premium
-	✅

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

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を仮想的な境界を用いて保護することで、境界外からの不正なアクセスを防止するとともに、境界外へのデータの漏洩を防ぐことを目的としたサービスです。
また、VPCSC を設定することで、IAM 誤設定やサービスアカウントキー漏出による情報漏洩を防ぐことにも繋がります。

保護の対象となるAPIは、個別に選択可能です。
これにより、選択されたAPIに対する外部からのアクセスを境界で遮断します。

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

VPCSCを構成する主要コンポーネントは以下のとおりです。

サービス境界（Service Perimeter）
- GCPのAPIを保護するコンポーネント
アクセスレベル（Access Levels）
- Google Cloud へのアクセス制限を行うコンポーネント
境界ブリッジ（Perimeter Bridge）
- サービス境界間の通信を許可するコンポーネント

サービス境界

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

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

アクセスレベル

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

境界ブリッジ

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

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

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

Organization Policy

Organization Policy（組織ポリシー）は、Google Cloud における最上位リソースの「組織」からその配下リソースに特定の設定や制限を強制させることができるサービスです。
これにより、組織の運用ルール（社内の Google Cloud 運用ルール）を一元管理/統制することが可能です。

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

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

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

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

SA のキーを払い出せないようにしたい
- ➜ iam.disableServiceAccountKeyCreation
- Type:Bool
デフォルト SA の自動的な権限割当を無効化したい
- ➜ iam.automaticIamGrantsForDefaultServiceAccounts
- Type:Bool
VPC Peering のピア関係を許可された VPC のみに制限したい
- ➜ constraints/compute.restrictVpcPeering
- Type:List
共有 VPC のサブネット払い出しを許可されたプロジェクトのみに制限したい
- ➜ constraints/compute.restrictSharedVpcSubnetworks
- Type:List
リソースロケーションを許可されたロケーションのみに制限したい
- ➜ constraints/gcp.resourceLocations
- Type:List

また、ポリシーを定義して制約を設けている環境では一部のサービスが公式ドキュメントと同様の動きをしない場合もあります。
ポリシーで定義した制約に対してどのような影響があるのか、どのようなトラブルシューティングが役立つのかも確認しておくとよいでしょう。

Container Analytics

Container Analytics はコンテナの脆弱性スキャンとメタデータストレージを提供するサービスです。
脆弱性スキャンを実施できる対象は、Container Registry と Artifact Registry に格納されたコンテナイメージです。
また、スキャンされた結果をメタデータストレージに格納し、API を介して他の Google Cloud サービスやサードパーティアプリがアクセスできるようになります。

例えば、OS パッケージやプログラムが参照してるパッケージといったものを参照する場合も有効です。
Google Cloud の DevSevOps への取り組みとして非常に重要なポイントとなります。
課金額もさほど高額ではないので、可能であれば実際に手を動かして触れてみるとよりイメージしやすいかと思います。

Binary Authorization

Binary Authorization は、Artifact Registry 等がホストするコンテナに署名を付与することで、GKE 等でコンテナアプリケーションを起動する際に読み込むイメージを制御できるサービスです。
例えば、本番環境で不正なコンテナイメージを実行させないようにしたり、単体テストなどをクリアしていないコンテナイメージをデプロイできないようにロックする、といったユースケースが当てはまります。

Binary Authorization は以下のプラットフォームをサポートします。

GKE
Cloud Run
Anthos Cluster on VMware

Container Analytics 同様、Google Cloud の DevSecOps への取り組みとして非常に重要なポイントとなります。
課金額もさほど高額ではないので、可能であれば実際に手を動かして触れてみるとよりイメージしやすいかと思います。

少し具体的なプロセスを以下で解説します。

証明書の利用

Cloud Build によって「コンテナイメージのビルド」➜「コンテナイメージの単体テスト」➜「Artifact Registryへ格納」といったステップを踏んだとします。
このとき重要なのは Cloud Build で定義した正規の単体テストをクリアしたのか、
つまり Cloud Build によって製造された正規のコンテナイメージなのか、という点です。
認証者（attestor）を作成して、Cloud Build のステップに認証者による署名を行うことを管理者による承認と置き換えると、以下の図のようになります。
binary-authorization-flow
図：Binary Authorization の利用シーン
正規のコンテナイメージかどうかを判定するには、Cloud Build のステップの最後に、コンテナイメージへ署名するプロセスを追加します。
詳細の手順については、公式ドキュメントを確認してください。

これは Container Analysis を用いた場合も同様に、「脆弱性スキャンが実施されたのか」「スキャン結果は正常だったのか」がポイントです。
どちらにも言えるのは、正しいステップを踏んだコンテナイメージにのみ証明書による署名が行われ、そうでない場合はデプロイをすることを禁止する制約を設けられる、ということです。

Compute Engine

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

Confidential VMs

Confidential Computing はハードウェアレベルで保護された環境を提供するサービスです。
ハードウェアレベルでの保護とは、TTE（Trusted Execution Environment）により隔離された安全な環境を指します。
使用中のアプリケーションやデータへの不正アクセスや変更を防ぐ、所謂セキュリティルームと捉えてよいでしょう。
この環境下で実行される Compute Engine インスタンス（あるいはオプション自体）を Confidential VMs といいます。
Confidential VMs は Compute Engine VM の一種で、使用中はメモリ内データを常に暗号化し、エンドツーエンドの暗号化とデータの保護を保証します。
そのため、機密データを取り扱うワークロードに最適です。

また、GCE のみではなく、GKE や Dataproc でも使用することが可能です。
GKE のオプションである「Confidential Google Kubernetes Engine Node」ではすべてのノードに対して Confidential VMs の使用を強制します。

Dataproc では「Dataproc Confidential Compute」が相当し、 Confidential VMs を使用した Dataproc クラスタを作成できます。

Shielded VM

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

Shielded VM の整合性検証機能は、次の機能を使用して実現されています。

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

セキュアブートはブート時にすべてのブートコンポーネントの署名を検証する機能です。
これにより、ブートローダやカーネルに不正なコンポーネントやマルウェアが潜んでいないことを保証します。

vTPM はアクセス時の認証に利用する暗号鍵や証明書を保護するために使われる TPM を仮想化したものです。
初めてインスタンスを起動したときに整合性ポリシーベースラインを生成し、以降インスタンスの起動時に再度測定した値とを比較し、ブートシーケンスが変更されたかどうかを検証します。

整合性モニタリングは、メジャーブートで作成された測定値を利用して整合性ポリシーベースラインと最新のブート測定値とを比較して、一致したかどうかの結果を返します。
つまり、Shielded VM とペアになって利用されるオプションです。

Shielded VM で整合性の判断に必要なデータを収集する
整合性モニタリングで初回起動時と最新起動時のブート測定値を比較し検証する

VPC ネットワーク

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

VPC Peering

2つの異なる VPC ネットワークのワークロード同士を内部IPアドレスで相互通信させる場合、まず最初に検討すべきは VPC Peering です。
VPC Peering を利用して VPC ネットワーク同士を接続すると、その間のトラフィックは Google Cloud のネットワーク内に留まり、パブリックインターネットに公開されずにアクセス可能となります。
vpc-peering
図：VPC Peering
VPC Peering は同じ組織や同じプロジェクトに互いが属しているかどうかに関わらず、接続できるという便利な点があります。
一方で、押さえておきたい注意点もあります。
それは 推移的ピアリングはサポートしていない 、という点です。
これは言い換えると、A ⇔ B ⇔ C のように接続した場合、AとCの VPC 同士は相互に通信することができない、ということです。
隣同士の VPC としか VPC Peering は設定できないので注意してください。

共有 VPC

共有 VPC は同じ組織に属する複数のプロジェクト間で VPC ネットワークおよびそのコンポーネント（サブネット、FWルール、ルート等）を一元管理したいときに利用します。
共有 VPC は親子構造にも似ていて、共有 VPC を管理するプロジェクトを「ホストプロジェクト」、
サブネットなどのリソースを利用するプロジェクトを「サービスプロジェクト」と呼びます。
xpn
図：共有 VPC
管理するプロジェクトと利用するプロジェクトを分けるということは、「利用者」と「管理者」の責任範囲を明確に分けることに繋がります。
インスタンスの作成や管理などの管理責任をサービスプロジェクト管理者に委任し、
組織のネットワーク管理者/セキュリティ管理者/組織管理者といった各管理者はネットワークリソースだけに集中することができます。
例えば、利用者が許可なく FW ルールを変更してしまう、サブネットを無闇に乱立させてしまう、といった状況を防ぐことができます。

VPC Firewall Rules

ファイアウォール（FW）を構成するうえで、意外と見落としがちな点について解説します。
ポイントとしては以下の点を設計/構築時に考慮するとよいでしょう。

フィルタリングの条件を判断する
- SAによるフィルタリング
- ネットワークタグによるフィルタリング
FW ログを設定する
暗黙のルールを理解する

フィルタリング条件において、サービスアカウント（SA）によるフィルタリングを行うのか、ネットワークタグによるフィルタリングを行うのかの判断は重要な点です。
SA は GCE インスタンスにつき1つまでしか設定することができませんが、ネットワークタグは複数設定することができます。
つまり、GCE インスタンスに厳密に適用したい場合、SA によるフィルタリングが推奨できますが、複数の条件でルールを構成したい場合はネットワークタグが有用です。

FW ログはその FW ルールが正しく動作しているか、何件ヒットしたか、といった検証/分析に役立つ機能です。
この機能の目的としては「意図的なヒットを記録するもの」と「想定外のヒットを記録するもの」とがあります。
「意図的なヒットを記録するもの」は FW ルールが正しく動作しているかを検証するのに役立ち、「想定外のヒットを記録するもの」は意図せぬアクセスがどれだけあったのか、どのようなアクセスだったのかを検証するのに役立ちます。

暗黙のルールは、すべての VPC ネットワークに存在する、表示されていない（管理することができない）ルールのことです。
このルールは2つ（IPv6を有効化している場合は4つ）存在します。
これらは Cloud Console やコマンドなどで確認することはできませんが、常に有効となっているため覚えておきましょう。

暗黙の IPv4 の下り（外向き）許可ルール
暗黙の IPv4 上り（内向き）拒否ルール

VPC Flow Log

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

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

vpclog-vs-fwlog
図：VPC Flow ログと FW ログの違い
先に触れた、FW ログとの違いを補足します。

FW ログ：FW にマッチしたかどうかを記録する
VPC Flow ログ：VPC 自体の送受信結果を記録する

可能であれば実際に手を動かして出力されたログに触れてみるとよいでしょう。
また、VPC フローログと FW ルールの関係性も理解しておくとよいかもしれません。

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攻撃やアプリケーションへの攻撃を防ぐのに役立ちます。

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

受験するうえでは詳細まで確認する必要はあまりないかもしれませんが、余裕をもって Managed Protection と Adaptive Protection も理解しておくとよいかもしれません。

Cloud Interconnect

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

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

Partner Interconnect
- サービスプロバイダを介して接続する
- 常時最低10Gbps以上の帯域が不要な場合に推奨
- コロケーション施設から地理的に離れた場所と接続する場合に推奨
- 最大帯域50Gbps
Dedicated Interconnect
- Google Cloud と直接接続する
- 常時最低10Gbps以上の帯域が必要な場合に推奨
- 最大帯域80Gbps or 200Gbps

Cloud VPN

Cloud VPN はサイト間 VPN をオンプレミスと Google Cloud で構成する VPN ゲートウェイサービスです。
従来、シングルスタック構成も構築することができましたが、これらは Classic VPN と称され現在は非推奨となっています。
Google Cloud の推奨構成としては HA VPN 、つまり冗長構成を実現し動的ルーティング（BGP）を行う構成です。

ここで、先の Cloud Interconnect とユースケースを比較します。
オンプレミスとのハイブリッド接続においてどのユースケースが最適か、試験以外でも実際の設計に大きく関わるため十分に理解しておきましょう。
interconnect-vs-vpn
図：Dedicated Interconnect と Partner Interconnect と Cloud VPN の比較
Cloud VPN

帯域容量：トンネルあたり1.5Gbps（上下の合計で3Gbps）、パブリックインターネットに依存
有利なケース：
- 通信の機密レベルがIPsecで十分要件を満たし閉域網を使用する要件がない場合、Cloud Interconnect よりもはるかに安い料金でオンプレミスネットワークと内部通信することが可能
不利なケース：
- 暗号化されているとはいえパブリックインターネットへトラフィックが送信されるため、機密データを送信するにはリスクがある
- インターネット経由で送受信するため、ネットワーク帯域が保証されない

Partner Interconnect

帯域容量：50Mbps〜50Gbps
有利なケース：
- パブリックインターネットへトラフィックが送信されないためホップ数が減り、パケットのドロップ率が低下するため安定した通信と帯域を確保できる
- 通信帯域の最低要件が10Gbpsよりも低い場合に、Dedicated Interconnect よりも安価に専用線を敷設可能
不利なケース：
- Cloud VPN と比較すると課金が高額になる
- サービスプロバイダとの契約や準備等において構築までにリードタイムが多く発生する

Dedicated Interconnect

帯域容量：10〜80Gbps / 100〜200Gbps
有利なケース：
- Partner Interconnect の有利点に加え、Google Cloud との専用線を物理的に直接接続することが可能
- 通信帯域の最低要件が60Gbpsを超過する場合でも、最大200Gbpsまで帯域確保が可能
不利なケース：
- Partner Interconnect よりもさらに課金が高額になる
- サービスプロバイダとの契約や準備等において構築までにリードタイムが多く発生する

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 にて任意の日時で受験申し込みをし、当日受験をすれば完了です。

筆者は遠隔監視（リモート）受験で自宅から受験しました。
開始時点でうまくカメラが映らなかったりとトラブルもありましたが、なんとか受験までこぎつけることができました。
スムーズに受験したい方はテストセンターまで赴いて受験することをお勧めします。

結果受領

リモート受験/現地受験どちらであっても一時的な合否はすぐ確認できます。
「合格」という文字が表示されたら無事に合格ラインに到達できたという判定です。
この時点で以下のタイトルでメールによる通知があります。
タイトル：Google Cloud Certified 試験の結果通知

しかしこれはあくまで一時的な合否結果であり、最終的な合否は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の理解があれば十分合格ラインを突破できる試験ですので、肩の力を抜いてラフに受験してみることをお勧めいたします。
（少なくとも日本語ローカライズされていない試験と比べれば言語の壁がないため難しくありません）

まとめ

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

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

Discussion

mado 2023/07/17

Professional Cloud Security Engineer を受けようと思ってたのですが、この記事見つけてめちゃくちゃ参考になりました！
合格目指して頑張ります！