G-gen の杉村です。当記事では、Google Cloud（旧称 GCP）の認定資格である Professional Cloud Security Engineer 試験の対策方法について紹介します。

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

概要

はじめに

当記事では、Google Cloud（旧称 GCP）の認定資格である Professional Cloud Security Engineer 試験の対策方法について紹介します。

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

参考 : Professional Cloud Security Engineer

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 のセキュリティ関係サービスの概要を理解する。特に以下のサービスに着目する
- 組織（Organization）/ 組織のポリシー / 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）がカバーすべきL7レイヤの脅威への対処は、私たちユーザーの責任となります。

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

組織のポリシー

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

blog.g-gen.co.jp

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

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

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

例えば1つ目に挙げた制約 ドメインで制限された共有 で、外部ドメインを許可する際には外部ドメインをルールに追加しますが、ドメイン名ではなく 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 へシングルサインオン（SSO）する方法を十分理解します。SAML や OAuth といった仕組みを使ったシングルサインオンについて、一般的な知識が無い方は、先にそちらを調べて、概要を理解したほうが良いでしょう。

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

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

Identity and Access Management（IAM）

IAM の概念と仕組み（IAM ポリシー、継承、リソースとの紐づけ...）を正しく理解しておく必要があります。以下記事をぜひ参考にしてください。

blog.g-gen.co.jp

また以下のサービスに関連する IAM ロールの仕様は、特に注意して把握しておくべきです。

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

Virtual Private Cloud（VPC）

押さえておくべき概念

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

VPC Flow Logs
- VPC Flow Logs にはどのような情報が記録されるかを把握
VPC Peering
- 基本的な仕組みを、手を動かして検証しながら試してみる
- Peering で交換された経路等、どのような制約があるのか確認
Shared VPC
- どのような機能であり、どのような制約があるのか確認
VPC のルーティング
- 同一 VPC 内のサブネット同士のルート交換の仕様を確認
- VPC ネットワークピアリングを接続した際の VPC 同士のルート交換の仕様
VPC ファイアウォールの仕組み
- Firewall のベストプラクティスを確認
- Firewall rules logging の仕様を確認
Packet Mirroring
Cloud NAT

ポイント

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

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

参考記事

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

Cloud Interconnect、Cloud VPN、限定公開の Google アクセス

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

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

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 関連の以下の単語については、それぞれの違い、役割、仕組みを理解する必要があります。

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 DLP（Cloud Data Loss Prevention）の問題は頻出です。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 Source Repositories へのコミットを Cloud Build で検知して Artifact Registry に格納。ビルド成果物を Google Kubernetes Engine（GKE）にデプロイする」といったようなものが想定できます。

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

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

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

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

Cloud Armor

Google Cloud が提供するフルマネージドな WAF（Web Application Firewall）である 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）の考えや、境界に VPC 内の VM インスタンスを入れるにはどうすればよいかを確認しましょう。またブリッジ境界を使って境界同士を接続する方法なども押さえておきたいポイントです。

Security Command Center

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

blog.g-gen.co.jp

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

Network Intelligence Center

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

Firewall Insights 機能など、ネットワークセキュリティとガバナンスの維持に有用な機能が利用できます。

Firewall Insights ではその Firewall ルールが何回ヒットした（実際に使われた）か、また最後に使われたのはいつか、などを確認することができます。また優先度のせいで別のルールの影に隠れて使われていない Shadowed rules を見つけることもできます。増えすぎたファイアウォールルールを棚卸しするときに便利な機能です。