G-gen の杉村です。Google Cloud (旧称 GCP) 認定資格である Professional Cloud Security Engineer 試験 は、 Google Cloud のセキュリティ関連の知識と実務能力を問う難関試験です。当記事では、試験合格のために何を知っているべきかをご紹介します。この記事で学習の方向性を決めていただき、実務にも応用可能な知識を蓄積していただければと思います。

概要
責任共有モデル
組織のポリシー
Cloud Identity と ID 連携
Identity and Access Management (IAM)
VPC
Cloud Interconnect (Cloud VPN) と Private Google Access
暗号化
個人情報の漏洩防止
- Cloud DLP
- Cloud DLP の匿名化機能
DevSecOps (CI/CD)
その他の押さえておくべきサービス

概要

Professional Cloud Security Engineer 試験の難易度

当試験の難易度としては、 中程度〜比較的高い と言えます。「応用情報技術者試験」程度の IT 基礎知識があり、かつ Google Cloud をある程度業務で使用した経験がベースとしてあることが望ましいです。これに加えて、ネットワークセキュリティや Web アプリケーションセキュリティに関する基本知識があるとなお良いでしょう。IPA のネットワークスペシャリストや、情報処理安全確保支援士 (旧・セキュリティスペシャリスト) の知識も役立ちます。

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

試験時間は 120 分です。問題文はそこまで長くないため、落ち着いて解ければ十分な余裕があります。

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

推奨の勉強法

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

出題傾向

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

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

責任共有モデル

クラウドユーザーが意識しておくべき最も重要なセキュリティの考え方として、 責任共有モデル があります。
我々利用者が責任を持つべきセキュリティとは何なのか、自分の言葉で人に説明できるまで理解している必要があります。
以下に、参考となるドキュメントへのリンクを記載します。

責任共有モデルを理解しておけば、例えば Web アプリを Google Kubernetes Engine (GKE) などにホストした際に、我々は どの部分のセキュリティに責任を持つべきか 、という問いに答えられるようになります。

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

一方で AppEngine のようなマネージドサービスの OS レイヤなどは、 Google の責任 となります。

組織のポリシー

組織のポリシー 機能をしっかり理解する必要があります。

blog.g-gen.co.jp

以下のようなキーワードで、理解を深めましょう。

親子リソース間でのポリシーの継承
公式の How-to guides に記載されている代表的なポリシーの使い方

上記に挙げた3つのポリシーについては、細かい使い方まで理解しておいて損はないです。

例えば1つ目のルール Domain Restricted Sharing で、外部ドメインを許可する際に例外として外部ドメインをルールに追加しますが、ドメイン名などではなく Google Workspace / Cloud Identity の 顧客 ID (英数字) で指定するのだ、といったポイントは理解しておくとよいでしょう。

また2つ目のサービスアカウント関連のルールでは「サービスアカウント自体の作成を制限するルール」と「サービスアカウントのキーの作成 を制限するルール」が別々に存在することも把握しておきましょう。

Cloud Identity と ID 連携

Active Directory と Cloud Identity を同期する方法については、十分に理解しておく必要があります。

まずは Google Cloud Directory Sync を使った Active Directory と Cloud Identity (Google Workspace) のアカウント同期について、概要を把握しましょう。

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

そのうえで、公式ドキュメントの Best practices for federating Google Cloud with an external identity provider は時間をかけて読む価値があります。

この分野については、そこそこの問題数が出題されます。
一般的な Identity Provider (IdP) と Service Provider (SP) の関係性は理解している前提で、前述のベストプラクティスについて問われるのだ、と覚えておくと試験の役に立ちます。
「 Active Directory と Cloud Identity を同期する。同期で作成された Google アカウントにどのような IAM 権限を付与するか」といったシチュエーションを想像し、自信を持って答えられるようにしておきましょう。

繰り返しになりますが、 Best practices はしっかり読んでおきましょう 。

Identity and Access Management (IAM)

IAM の概念と仕組み (IAM Policy 、継承、リソースとの紐づけ ...) を深く理解しておく必要があります。
以下のブログ記事をぜひ参考にしてください。

blog.g-gen.co.jp

また以下のサービスに関連する IAM Role の仕様は、特に注意して把握しておくとよいです。

Basic roles (viewer, editor, owner)
- 最小権限の原則に従えば、極力使わないのが吉
Resource Manager
Cloud Logging
- どんな役割のチームにはどんなロールが割当たっているべきだろうか、という観点で、ロール一覧を確認
Cloud Billing
- こちらも前述と同様。 Billing Account だけを管理するチームも想定する
- Billing Account の仕組みは G-gen 社ブログを参照

VPC

押さえておくべき概念

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

VPC Flow Logs
- VPC Flow Logs にはどのような情報が記録されるかを把握
VPC Peering
- 基本的な仕組みを、手を動かして検証しながら試してみる
- Peering で交換された経路等、どのような制約があるのか確認
Shared VPC
- どのような機能であり、どのような制約があるのか確認
VPC のルーティング
- VPC 内の Subnet 同士のルート交換の仕様を確認
- VPC Peering を張ったときの VPC 同士のルート交換の仕様を確認
VPC Firewall の仕組み
- Firewall のベストプラクティスを確認
- Firewall rules logging の仕様を確認
Packet Mirroring
Cloud NAT

ポイント

もう少し細かく書くと、以下のような少し込み入った VPC の仕様が具体的にイメージでき、設計に活かせるくらいの知識があるとよいでしょう。

VPC 内に複数サブネットを作成すると 全てのサブネット同士は通信できる (ルートは編集したり削除したりできない)
VPC 同士をピアリングすると、 VPC 内の 全サブネットのルートが自動的に交換される (ルートは編集したり削除したりできない)
VM は複数の VPC の 複数のサブネットに足を伸ばせる (NIC を作ることができる)
Firewall においてあるパケットが複数のルールに該当する場合、どのルールが適用されるか (優先度 の指定方法)

参考記事

VPC の詳細な仕様については、以下の記事もご参考にお願いします。

Cloud Interconnect (Cloud VPN) と Private Google Access

オンプレミスと Google Cloud 環境を接続するネットワーキングについても理解が必要です。
公式ドキュメント Choosing a Network Connectivity product を読み、適切なプロダクトを選択できるようにしておきます。

これに関連して「限定公開の Google アクセス (Private Google Access) 」機能でオンプレミスからプライベートネットワーク経由で Google Cloud API を利用する方法も理解しておいたほうがよいでしょう。
以下のブログを、ぜひ参照してください。

blog.g-gen.co.jp

暗号化

Cloud KMS (Key Management Service)

当試験でも最も重要なのが、暗号化や鍵情報の扱いです。その中核にあるのが Cloud KMS です。

Cloud KMS は FIPS 140-2 と呼ばれる、米国政府により規定されたセキュリティ要件仕様の規格に準拠した Google Cloud サービスです。

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

blog.g-gen.co.jp

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

Cloud KMS (Key Management Service)
CMEK (Customer-Managed Encryption Key)
CSEK (Customer-Supplied Encryption Key)
Cloud EKM (External Key Manager)
Cloud HSM (Hardware Security Module)

エンベロープ暗号化

これらの単語の意味を理解するためには Envelope Encryption (エンベロープ暗号化) という仕組みの理解は大前提です。 Envelope Encryption は Google Cloud の KMS に独自の技術というわけではなく、暗号化の世界ではしばしば用いられます。

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

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

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

データの暗号化の基本的な考え方として at-rest (保存時) の暗号化と in-transit (転送中。in-flight とも) の暗号化に分けることができます。

前者についてはドキュメント Encryption at rest in Google Cloud を、後者についてはドキュメント Encryption in Transit in Google Cloud を参照すると Google Cloud のスタンスを確認することができます。

Confidential Computing

なお近年では at-rest / in-transit のデータ暗号化に加えてメモリ上のデータ暗号化も加える場合があります (Confidential Computing) 。

用語の基本的な意味を押さえておきましょう。

個人情報の漏洩防止

Cloud DLP

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

Cloud DLP の主要な機能は、センシティブなデータの「発見・分類」と「保護 (de-identification = 匿名化や redaction = 伏字化) 」に大きく分けられます。

前者の "発見・分類" については、 Cloud Storage や BigQuery 内のテキストや画像データの中に、 PII が含まれていないかをスキャンすることができます。

Cloud DLP の匿名化機能

後者の "保護" については、特に de-identification (匿名化) 機能のうち Pseudonymization (仮名化) 機能の内容は、チェックしておいた方が良いでしょう。

Pseudonymization のドキュメントでは Deterministic encryption using AES-SIV 、 Format preserving encryption 、 Cryptographic hashing という 3 つの手法が紹介されています。

それぞれの手法は「Surrogate annotation (代理アノテーション) を付与できるか」「文字セットや文字長を維持したまま仮名化できるか」「可逆的か (暗号化キーを使って元に戻せるか)」「referential integrity (参照整合性) を維持できるか」などが異なります。どのような場面でどの手法を用いるかを想像しておきましょう。

DevSecOps (CI/CD)

Google Cloud で CI/CD パイプラインを実装し、パイプライン内にセキュリティを組み込む方法についても問われます。

例えば Google Cloud だけでコンテナイメージをビルドしてデプロイする CI/CD パイプラインを実装するなら「 Cloud Code レポジトリへのコミットを Cloud Build で検知して Container Registry (現在では Artifact Registry が推奨) に格納。それを Google Kubernetes Engine (GKE) にデプロイする」といったようなものが想定できます。

そのパイプラインに Container Analysis サービスを用いてコンテナイメージの脆弱性を自動スキャンするよう設定可能です。

また Binary Authorization サービスを用いると Google Kubernetes Engine (GKE) 、 Cloud Run といった基盤に、署名 (Attestations) がついた安全なコンテナイメージだけがデプロイされるように設定することも可能です。

一般的な CI/CD やコンテナアーキテクチャの知識として、イミュータブルなインフラの概念は理解しておく必要があります。

その他の押さえておくべきサービス

Cloud Armor

Google のマネージドな WAF である Cloud Armor については、概要を理解しておくとよいでしょう。
以下の記事をご参考に、どのようなことができるサービスなのかをご確認ください。
実運用をイメージすると、ドライラン機能 ( プレビュー 機能) の重要性が理解できると思います。

blog.g-gen.co.jp

もしも「 WAF が守れる対象の脅威はどういったものか」といった問いに答えられない場合は、これを機に知識を再確認しておきましょう。
これは、 Google Cloud に限らない一般的な IT セキュリティの知識と言えます。

Cloud Load Balancing

要件に応じて適切なロードバランサーを選択することも、セキュリティにおいて重要です。
公式ドキュメント Choosing a load balancer を理解しましょう。

Google Cloud のロードバランサーは種類が多くてややこしいように見えますが、基本は「外部 or 内部」「HTTPS or TCP/UDP」「リージョナル or グローバル」「パススルー or プロキシ」といった軸があり、それを理解すれば大丈夫です。

blog.g-gen.co.jp

VPC Service Controls

VPC Service Controls の基本については、ぜひ以下のブログを参照してください。

blog.g-gen.co.jp

Perimeter の考えや Perimeter に VPC 内の VM インスタンスを入れるにはどうすればよいか、を確認しましょう。
またこのブログに記載していない応用として Bridge を使って perimeter 同士を繋ぐ方法なども押さえておきたいポイントです。

Security Command Center

Security Command Center (SCC) も出題の範囲となります。
複数の機能を擁しているサービスですので、どのような機能があるのか、どのように使うべきなのかを、公式ドキュメントや以下のブログを参考に把握してください。

blog.g-gen.co.jp

SCC には複数の機能がありますが、どの機能がどのレイヤの脆弱性を検知できるのか、適切にイメージして答えられるようにしましょう。
Security Health Analytics は Compute Engine や VPC Firewall の不適切な設定を検知することができます。
一方で Web Security Scanner は Web アプリに対する L7 レベルの脆弱性スキャンを定期的に実行することが可能です。

Network Intelligence Center

Network Intelligence Center の機能も確認しておきましょう。

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

Secret Manager

Secret Manager はアプリケーションが利用するパスワード、証明書、 API キーなどの機密情報を格納するためのストレージサービスです。
API 呼び出しで機密情報 (secret) を格納・取り出しでき、バージョニングやローテーションといった管理が可能です。
secret はデフォルトで暗号化されており、前述の Cloud KMS の CMEK を利用することもできます。

この Secret Manager の最低限の機能を理解しておきましょう。