Question#4(Professional Cloud Developer)

あなたは Cloud Run にデプロイする予定の Web アプリケーションを開発しています。このアプリケーションは複数のマイクロサービスで構成されており、一部は公開アクセス可能ですが、他の一部は Google ID による認証後のみアクセス可能にする必要があります。

公開サービスへの無制限のアクセスを許可しつつ、制限されたサービスには認証されたユーザーのみがアクセスできるようにする必要があります。管理の手間と複雑さを最小限に抑えながら、最も安全なアプローチを採用したいと考えています。アクセスをどのように構成すべきですか？

A. すべてのマイクロサービスで Identity-Aware Proxy (IAP) を有効にする。各アプリケーションの認証要件をチェックし、それぞれのサービスへのアクセスを制御する新しいマイクロサービスを開発する。
B. すべてのマイクロサービスで Identity-Aware Proxy (IAP) を有効にする。制限されたサービスのアクセス制御リスト (ACL) を管理し、公開サービスには allAuthenticatedUsers アクセスを構成する。
C. すべてのマイクロサービスで Firebase Authentication を備えた Cloud Endpoints を使用する。Firebase ルールを構成して各サービスのアクセス制御リスト (ACL) を管理し、公開サービスへのアクセスを許可する。
D. 公開マイクロサービスと制限付きマイクロサービスに対して、別々の Cloud Run サービスを構成する。制限付きサービスに対してのみ Identity-Aware Proxy (IAP) を有効にし、Cloud Run の内向き（ingress）設定を「内部および Cloud Load Balancing」に構成する。

正解と解説ディスカッション 0

正解：D

この問題のポイントは、Identity-Aware Proxy (IAP) を適切に使い分け、外部公開用と内部用の境界を明確にすることです。

IAP の役割: IAP は、Google Cloud のロードバランサ（HTTPS）と連携して動作し、ユーザーの ID に基づいてアクセスを制御するフルマネージドなサービスです。コードを書き換えることなく認証レイヤーを追加できるため、管理の複雑さを最小限に抑えられます。
Ingress 設定による保護: Cloud Run の ingress 設定を「Internal and Cloud Load Balancing」にすることで、Cloud Run のデフォルトの *.run.app URL への直接アクセスを遮断し、必ずロードバランサ（および IAP）を経由するように強制できます。これが「最も安全なアプローチ」です。
分離によるシンプル化: 公開サービスと制限付きサービスを分けて構成することで、公開サービスには IAP をかけず、機密サービスにだけ強固な認証を適用するという切り分けが最も単純で確実です。

コメント