PSE（Google Professional Security Engineer）が”ざっくり”「スッキリ」分かる講座

Google CloudネットワークはVPCを始めとする各種ネットワーク関連のサービス群です。Google Cloudは文字通りGoogleの地球規模のネットワークをバックボーンに、高速で安定した回線によりグローバルロードバランサに代表されるリージョン間の高速通信が特徴です。またオンプレからの移行にも豊富なオプションを用意し、中でもCloud Interconnectなどによりお客様環境とGoogle間を内部IPにより安定した回線を利用したデータの移行や移行後のオンプレとクラウドのハイブリッド環境構築なども可能となっています。ここではGoogle Cloudのネットワーク関連のサービスについて見ていきたいと思います。

AWSではサブネット単位でセキュリティグループを設定し、そこで通信制御を定義しますが、Google Cloudではそれぞれのインスタンスにタグを付け、その（ネットワーク）タグに対して別途ファイアウォールルールによりインバウンド、アウトバウンドの通信許可もしくは不可を定義します。そしてその定義に名前とは別にターゲットタグを付け、そのターゲットタグとインスタンスに設定したネットワークタグを一致させることによりインスタンスをファイアウォールルールで設定したサブネット環境に属させる事ができます。

質問の中に「会社全体で管理」「組織全体で一元的に…」「社内のすべてのプロジェクトを可視化したい」などの要件があった場合、プロジェクトやサービス単位でロールを設定するのではなく、組織ポリシーを利用することを検討してください。例えば社内で作成されたすべてのプロジェクトを可視化し、さまざまなビジネスユニットに基づいてGoogle Cloud Platform（GCP）プロジェクトを整理したいといった場合、組織ノードを作成し、ビジネスユニットごとにフォルダーを割り当て管理することを検討します。

VPC内部には、コンピュータやデータベースに加えてネットワークも管理対象となります。しかし、場合によってはコンピュータなどの管理とネットワークの管理を別々なチームに任せたい場合があります。ネットワーク管理者はすべてのプロジェクトとプロジェクト間のネットワークトポロジに責任を持つためには、勝手にアプリケーション開発者や開発インフラ担当にネットワークの変更までしてほしくない場合もあります。これをIAM、ロール、サービスアカウントだけで実現することが難しいような場合、この共有VPCネットワークとの併用を検討します。

パロアルトネットワークスなどに代表されるサードパーティ製仮想アプライアンス製品による次世代ファイアウォールを企業ネットワークセキュリティとして導入することにより、これまでのオンプレと同様の境界型防御をGoogle Cloudにも導入することができます。

VPC Service Controls を使用すると、Cloud Storage や BigQuery などの Google Cloud サービスからデータが漏洩するリスクを軽減できます。VPC Service Controls を使用すると、明示的に指定したサービスのリソースとデータを保護する境界を作成できます。

Access Context Managerは、Google Cloudのプロジェクトとリソースに対する、属性ベースのアクセス制御を定義するものになります。例えばアクセス元のデバイスの種類やオペレーティング システム、IPアドレス、ユーザーIDなどの属性によって制御することが可能です。

VPCフローログは、Google Cloud上において、より高度なネットワーク オペレーションを可能にします。ネットワークの透明性を高め、個々の仮想インターフェースまでのネットワークフローをほぼリアルタイム（5秒間隔でログを作成）で追跡するために利用できます。

ネットワークとGoogleCloudの経験に基づいて推奨事項を提供する必要がある場合や、優先度が高いか等しい他のファイアウォールルールの属性と重複するファイアウォールルールを検出する場合にファイアウォール インサイトを使用すると、ファイアウォール ルールについての理解を深めながら、安全に最適化できます。

Cloud Logging では、ログデータを分析するための新しいバージョンのインターフェースであるログ エクスプローラが導入されました。応答性がより向上し、クエリのログをすばやく効率的に取得、表示、分析できる新機能が導入されました。ファイアウォールルールが正しく機能しているかどうかをテストする必要がある場合などに利用可能です。

マイグレーション関連の問題で出題が多いのがDedicated Interconnectです。特に大量のオンプレ内に保存されているデータを、内部IP経由で安全かつ高速に安定したネットワークにより移行する際の選択肢として検討されます。また大量のデータ転送というキーワードでTransfer Applianceとの比較も出題されます。

Partner Interconnectは直接Googleのコロケーションに接続するのではなく、指定のパートナーが提供するサービスプロバイダーネットワークを一旦介してGoogleのネットワークに接続します。

VMインスタンスに外部IPを設定したくない場合、基本的にはGoogle APIなどのGoogle Cloudサービスを利用することはできません。そのような場合にこの限定公開のGoogleアクセスを有効化することにより、外部IPを持たないVMやオンプレなどからCloud StorageやBigQueryなどのGoogle Cloudサービスはもちろん、 Google Map,、Google WorkspaceなどへGoogle API経由でのアクセスが可能になります。

VPC内のインスタンスからGCSなどのGoogleが提供するサービスにアクセスする場合、storage.googleapis.comなどのインターネットを経由してアクセスすることになります。安全に内部IP経由でアクセスしたい場合に、このPrivate Service Connectを利用します。

Google Cloud には、HA VPN と Classic VPN の 2 種類の Cloud VPN ゲートウェイがあります。ただし、Classic VPN の特定の機能が 2022 年 3 月 31 日に非推奨となり、Google Cloudの推奨はHA VPNとなるため、ここではCloud VPN=HA VPNとしてお話をします。

インターネット越しに3rdパーティサービスにアクセスするような新しいアプリケーションをホストしたいが会社の規定によりGCEにパブリックIPの付与は禁止されている場合に Cloud NATの利用を検討します。

PSEでは、ネットワークの一部として適切なロードバランサの選択問題も出題されます。以下の表を可能な限り覚えて、出題に際して最適なロードバランサを選択できるようにしておいてください。また、契約に関してもスタンダードティアとプレミアムティアでは利用できるロードバランサに違いがありますので、そちらも合わせて確認しておく必要があります。

Network Service Tiers を使用すると、インターネット上のシステムと Google Cloud インスタンス間の接続を最適化できます。プレミアム ティアは Google のプレミアム バックボーンでトラフィックを配信し、スタンダード ティアは通常の ISP ネットワークを使用します。

Google Cloud Armor セキュリティ ポリシーは、一般的なウェブ攻撃やトラフィックを妨げる可能性のある他のレイヤ 7 属性のリクエストをレイヤ 7 フィルタリングやスクラブによりブロックし、負荷分散されたバックエンド サービスまたはバックエンド バケットに到達させないようにすることで、アプリケーションを保護します。

Google Cloud VPCネットワークピアリングでは、2 つの Virtual Private Cloud（VPC）ネットワークが同じプロジェクトまたは同じ組織に属しているかにかかわらず、内部 IP アドレス接続できます。

DNSSEC（Domain Name System Security Extensions）は、ドメイン名のルックアップに対するレスポンスを認証するドメイン ネーム システム（DNS）の機能です。

Web Security Scanner は、App Engine、Google Kubernetes Engine（GKE）、Compute Engine の各ウェブ アプリケーションにおけるセキュリティの脆弱性を特定します。アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラの処理を試みます。現在、Web Security Scanner は、ファイアウォールの背後にない、公開 URL と IP のみをサポートしています。

パケット ミラーリングでは、Virtual Private Cloud（VPC）ネットワーク内で特定のインスタンスのトラフィックのクローンを作成し、検査用として転送します。パケット ミラーリングでは、ペイロードとヘッダーを含むすべてのトラフィックとパケットデータをキャプチャします。キャプチャは、下り（外向き）トラフィックと上り（内向き）トラフィックの両方、上り（内向き）トラフィックのみ、または下り（外向き）トラフィックのみに対して構成できます。

パブリッククラウドではデータはお客様のものという概念があり、例えCSPが提供する環境であっても、データの管理や責任は基本的に利用者側で担保しなければなりません。厳しい規制下に置かれている業界では、データの暗号化はCSP側が提供する暗号化キーではなく、自分たちの鍵を持ち込んでデータを暗号化することが求められます。また定期的にキーのローテーションを実施することも要求される場合があります。そのような状況に合わせた鍵の管理を可能な限り、マネージドで管理するためのサービスとしてCloud Key ManagementのようなKMSがGoogle Cloudでも利用可能です。

アプリケーションがバックエンドのデータベースなどにアクセスする際に、データベースとの接続にIDとパスワードが必要な場合、直接コードにそのIDとパスワードを記述することはセキュリティ上好ましくありません。もしコードがGitなどに一瞬でも誤って公開されてしまうと、それを悪用してデータベースから機密情報を盗み出すことができてしまいます。

Google の規模でデータを保管および暗号化するには、暗号化データに対して複数レイヤの鍵を使用する一元的な暗号鍵管理サービスが必要です。複数レイヤの鍵の例として、鍵を別の鍵で暗号化するエンベロープ暗号化があります。鍵は、使いやすさを考えて設計された鍵階層に Cloud KMS が保管します。鍵階層内のリソースへのアクセスは、IAMによって管理されます。

暗号化とは別に機密情報を検出、分類、保護するマネージドサービスとしてDLPの出題もPSEでは多くなっています。一方プライバシー規制は、機密データの調査と共有の方法を厳格に管理しています。同時に、ビジネスを停止させることもできません。匿名化の手法は、データの有用性とプライバシーのバランスをとるのに役立ちます。

Google Cloudは、本番環境でBoringCrypto（証明書3318）と呼ばれるFIPS（Federal Information Processing Standards連邦情報処理標準）140-2検証済み暗号化モジュールを使用します。これは、顧客への転送中およびデータセンター間でのデータと保存中のデータの両方が、FIPS140-2で検証された暗号化を使用して暗号化されることを意味します。FIPS 140-2検証を達成したモジュール は、BoringSSLライブラリの一部です。

PSEではセキュリティの重要な部分であるアカウントの管理に関しての出題があります。特にパブリッククラウドではオンプレのように物理的なデータセンターやマシンルームを運用管理しなくていい代わりに、契約したパブリッククラウド環境へのログインIDやパスワードなどによる認証が仮想の境界となるためです。これまでのオンプレのような境界防御だけでなく、アカウントやロールの管理を正しく理解することにより、セキュリティを高めることに繋がります。

Google Cloudでは管理すべきサービスはリソースと呼び、GCEやGCSなどは組織、フォルダ、プロジェクトと言ったリソース階層によりアクセス制御する仕組みになっています（リソース階層の例を参照）。例えば会社として統一したポリシーを適用したい場合、組織（Organization）という、通常ドメインといった単位でアクセス制御を行います。更に部署ごとや会社配下の事業部毎に細かく制御したい場合などはフォルダにより管理します。その配下に開発、テスト、本番環境のようにプロジェクト単位でリソースを管理します。ちなみにGoogle Cloudでのベストプラクティスとして、同じアプリケーションやシステムでも開発、テスト、本番環境はプロジェクト単位に分けて管理をします。

Google Cloudにおける権限の管理に関して、各名称や役割に関してしっかりと理解しておきましょう。Google Cloudにおけるアクセス管理モデルはプリンシパル、ロール、ポリシーから構成されています。

Google Cloud におけるID管理にはCloud Identityを検討します。Google Workspace および Cloud Identity は、こうした要件に対応し、ID とポリシーを一元管理できる Google のプロダクトです。

オンプレミスのActiveDirectoryサービスからGCP IAMアクセス許可を一元管理したい場合やADグループメンバーシップによってIAM、グループ権限を管理したい場合にCloud Directory Syncを検討します。また、インフラ環境を既存のオンプレ環境からGCPへ移行期間に既存環境を活かしながら、新しいGoogle Cloud環境でログインやユーザー管理を既存のADもしくはLDAPと同期したい場合にもDirectory Syncにより実現が可能です。

クラウドベースおよびオンプレミスのアプリケーション、Google Cloud 上で稼働している VM へのアクセスを制御します。ユーザー ID を確認し、コンテキストを使用してユーザーにアクセスを許可すべきかどうかを判断します。VPN を使用せずに、信頼できないネットワークから作業することが可能になります。IAP は、アプリケーションとリソースに対してアクセス制御ポリシーを適用する際に使用します。IAP は、署名付きヘッダーまたは App Engine スタンダード環境の Users API と連携してアプリを保護します。IAP を使用すると、グループベースのアプリケーション アクセスを設定できます。あるリソースについて、従業員にはアクセスを許可し、請負業者には許可しないように設定できます。また、特定の部門のみがアクセスできるようにすることもできます。

Google Cloudのアドバンテージの一つであるコンテナ、Kubernatesやアプリケーションモダナイゼーションには必須のCI/CDによるコーディングからデプロイメントまでの自動化に関する出題も多くなってきています。

これまでPaaSのGAE、IaaSのGCEといった２択のコンピュータですが、GKEリリース以降その中間的な位置としてコンテナによるIaaS的なサーバ環境とそれをマネージドのクラスタで運用するインフラ環境が次第に注目されるようなりました。

アジャイル開発にはCI/CDにより、コードを書き（もしくは変更追加を行い）、コード実行に必要となる各種ライブラリやパッケージとともにビルトを行いイメージを作成し、テストし、テストが完了したらイメージ（もしくはアーティファクト）をレジストリに登録し、それをオーケストレータが本番環境にデプロイし、その後の利用状況によりコンテナの追加、削除などの運用までの一連の作業を自動化することが可能です。

Cloud Monitoringは主にアプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性を可視化するためのサービスとなります。GCEにはエージェント（Opsエージェント）が用意されているので、そちらをインストールします。

PSEではログの収集方法に関しての出題が想定されます。セキュリティ担当者がログを収集し、各種のサービスやSEIMなどの外部システムとの連携などにより、アラートを受け取ると行ったケースを想定します。

Google Cloud サービスでは、管理アクティビティと Google Cloud リソース内のアクセスを記録する監査ログを書き込みます。監査ログは、Google Cloud リソース内でオンプレミス環境と同じレベルの透明性を確保しながら「いつ誰がどこで何をしたか」という問いに答えるために役立ちます。

アクセスの透明性ログは、Google Cloud Console で Cloud Audit Logs とともに確認できます。

組織、フォルダ、プロジェクトなどのリソース コンテナを使うことで、他の GCP のリソースをグループ化したり、階層的にまとめたりすることができます。