たろログ2

実験的運用により、記事品質が乱高下することがあります。予めご了承ください。

2022-06-22 Google Cloud Professional Cloud Security Engineer 模擬試験の解説

Google Cloud Professional Cloud Security Engineer 模擬試験の解説

Google Cloud Professional Cloud Security Engineer の模擬試験を解いた。その後、その解説を確認し、掘り下げを行った。

その内容について、以下にまとめていく。

既存の IdP の利用

問題

あるお客様が、Google Cloud でソリューションを開発する際に、ネイティブ認証の要件がある既存のユーザー ディレクトリを使用したいと考えています。また、既存のツールと機能を利用して、使い慣れたインターフェースからユーザーのアクションに関する分析情報を収集したいと考えています。このお客様の要件を満たすためには、どうすればよいですか?

(A customer needs to rely on their existing user directory with the requirements of native authentication when developing solutions in Google Cloud. They want to leverage their existing tooling and functionality to gather insight on user activity from a familiar interface. Which action should you take to meet the customer's requirements?)

回答

お客様のユーザー ディレクトリを ID プロバイダとして使用し、Cloud Identity を SAML 2.0 サービス プロバイダに設定する。

解説

問題文を分解する。

  1. 「ネイティブ認証の要件がある既存のユーザーディレクトリ」を使用したい
  2. 「ユーザーのアクションに関する分析情報を収集」したい

重要なのはこの二つ。

「ネイティブ認証の要件がある既存のユーザディレクトリを使用したい」というのは、GCPGoogle Identity を利用したり、他の IdP を新規にセットアップして認証を行ったりしたくはないということ。

その要望は、顧客の既存のユーザディレクトリを IdP として使用することで叶えられる。

「ユーザのアクションに関する分析情報を収集したい」というのはドキュメントに記載がなかったが、 OpenLDAP などはユーザのログイン / ログアウトについてログを吐いたりするそうなので、顧客の既存のユーザディレクトリを使うことでその要望は叶えられるということではないかと解釈した。

あまり後者については回答の選択に関わってこない。

ユーザディレクト

ユーザやグループの情報を格納しておくところ。アクティブディレクトリのようなもの。

アクティブディレクト

ディレクトリサービスの一種。 Windows 端末をドメインコントローラによって一括管理する。

ディレクトリサービス

コンピュータネットワーク上のリソース(資源)とその所在や属性、設定などの情報を収集・記録し、検索できるようにしたサービス。

AD や LDAP の他、 DNS もおそらく該当する。

ネイティブ認証

おそらく、外部サービスに依存せず自身で認証を行うことを、 Native Authentication と呼称しているのではないかと理解した。

mysql であれば MySQL :: Security in MySQL :: 6.1.1 Native Pluggable Authentication に「Native Pluggable Authentication」というのが記載されており、それはユーザ名およびパスワードの組によって、自データベースで認証を行うものだった。

また、 ORACLE にも Using NATIVE authentication (oracle.com) というのがあり、これもまたユーザ名およびパスワードによって自データベースにユーザ名とパスワードを保存、自ら認証を行うものだった。自分自身で完結する認証。

ここでは、 Google Cloud の IdP を利用するのではなく、既存のユーザディレクトリ自身の認証機能を用いて認証を行うことを指しているのだろうと思う。

Google Cloud Directory Sync

LDAP 系のシステムから Cloud Identity に対して定期的に Identity を同期するツール。クライアントソフトのようなものが用意されているらしい。

同期元の LDAP 系のシステムの Identity のデータは変更されず、 Google Identity 側が同期される形で変更される。

Third-party IdP connector

SAML SSO というものを使って、 third-party 製のアプリから LDAP のユーザやグループ情報を GCP に同期する。

この場合、 GCP の console にログインする際の認証についてもその LDAP の認証によって行われるようになる。

SAML SSO

SAML SSO を設定すると、GCP のリソースにアクセスした際は GCP がページを連携先の IdP にリダイレクトする。

このリダイレクト先の URL を Admin Console から指定することで、 SAML SSO の設定が行える。

サービスアカウントの利用

問題

あるお客様が、Compute Engine で実行されているアプリケーションにアクセス権を付与し、書き込み対象を特定の Cloud Storage バケットに限定したいと考えています。どのようにアクセス権を付与すればよいですか?

回答

そのアプリケーション用のサービス アカウントを作成し、バケットレベルで Storage オブジェクト作成者のロールを付与する。

解説

Compute Engine にリソースへのアクセス権を割り当てる際は、ユーザアカウントでなくサービスアカウントに割り当てることが適切である。

Compute Engine とサービスアカウント

Compute Engine のインスタンスに、それぞれサービスアカウントを割り当てることができる。

割り当てるサービスアカウントは後からでも変更することができる。

ファイアウォール利用の制限

問題

あなたのチームが、自社の IP 範囲内から、Compute Engine 上の特定の踏み台インスタンスへの SSH アクセスを許可するため、上り(内向き)ファイアウォール ルールを作成しています。あなたのチームは、未承認のエンジニアは、このファイアウォール ルールを使用できないようにしたいと考えています。そうしないと、未承認のエンジニアが開発環境内で VM を管理するアクセス権を取得する可能性があるからです。この要件を満たすためには、どうすればよいですか?

回答

サービス アカウントをターゲットに設定してファイアウォール ルールを作成し、そのサービス アカウントへのアクセスを一元管理する。

解説

B が正解です。サービス アカウントをターゲットに設定したファイアウォール ルールを使用するためには、サービス アカウントへのアクセスが必要になるからです。

承認済みのエンジニアに対して、サービスアカウントをターゲットとしたアクセスの許可を設定する。

ファイアウォールルールについてそのサービスアカウントを割り当てることによって、承認済みのエンジニアがファイアウォールルールを閲覧、編集できるようにする。

サービスアカウントに対する閲覧の権限を持たない未承認のエンジニアは、ファイアウォールルールにアクセスできず使用できない状態となる。

サービスアカウント vs ネットワークタグ

今回のようなファイアウォールルール含むインスタンスへのアクセス制御については、サービスアカウントによって実現する方法と、ネットワークタグによって実現する方法がある。

結論として、サービスアカウントを利用するほうがよい。

ネットワークタグは、インスタンスのタグの編集権限を持っている人であればどのタグでも付与できてしまうという問題があるからである。

インスタンスが、サービスアカウントを利用するように構成する。そして、そのサービスアカウントへのアクセス権限をユーザアカウントに割り当てることで、そのインスタンスファイアウォールルールに対するアクセスを制御することができる。

今回であれば、「特定の踏み台インスタンス」がサービスアカウントを利用するように構成する。

そして、承認されたエンジニアのグループに対してこのサービスアカウントへのアクセスを許可する。