Identity-Aware Proxy の概要

このページでは、Google Cloud のグローバル サービスである Identity-Aware Proxy(IAP)の基本コンセプトについて説明します。

IAP を使用すると、HTTPS によってアクセスされるアプリケーションの一元的な承認レイヤを確立できるため、ネットワーク レベルのファイアウォールに頼らずに、アプリケーション レベルのアクセス制御モデルを使用できます。

IAP のポリシーは組織全体に拡張されます。アクセス ポリシーを一元的に定義し、それをすべてのアプリケーションとリソースに適用できます。ポリシーを作成して適用する専門チームを割り当てると、アプリケーション内の誤ったポリシーの定義や実装からプロジェクトが保護されます。

IAP を使用する場合

IAP は、アプリケーションとリソースに対してアクセス制御ポリシーを適用する際に使用します。IAP は、署名付きヘッダーまたは App Engine スタンダード環境の Users API と連携してアプリを保護します。IAP を使用すると、グループベースのアプリケーション アクセスを設定できます。あるリソースについて、従業員にはアクセスを許可し、請負業者には許可しないように設定できます。また、特定の部門のみがアクセスできるようにすることもできます。

IAP の仕組み

IAP によって保護されているアプリケーションまたはリソースには、適切な Identity Access Management(IAM)役割を持つプリンシパル(ユーザーとも呼びます)がプロキシ経由でのみアクセスできます。IAP によってアプリケーションまたはリソースへのアクセスをユーザーに許可すると、使用中のプロダクトによって実装されたきめ細かいアクセス制御が適用され、VPN を使用する必要がなくなります。ユーザーが IAP で保護されたリソースにアクセスしようとすると、IAP が認証と認可のチェックを行います。

App Engine
Cloud IAP 使用時の App Engine へのリクエストパスの図
Cloud Run
Cloud IAP 使用時の Cloud Run へのリクエストパスの図
Compute Engine
Cloud IAP 使用時の Compute Engine と Kubernetes Engine へのリクエストパスの図
GKE
Cloud IAP 使用時の Compute Engine と Kubernetes Engine へのリクエストパスの図
オンプレミス
Cloud IAP 使用時のオンプレミス アプリへのリクエストパスの図

認証

Google Cloud リソースへのリクエストは、App Engine、Cloud Load Balancing(外部および内部 HTTP(S) 負荷分散)経由で送信されます。これらのサービスの処理インフラストラクチャ コードは、IAP がアプリまたはバックエンド サービスに対して有効になっているかどうかを確認します。IAP が有効になっている場合は、保護されたリソースに関する情報が IAP 認証サーバーに送信されます。これには、Google Cloud プロジェクト番号、リクエスト URL、リクエスト ヘッダー、Cookie 内の IAP 認証情報などの情報が含まれます。

次に、IAP はユーザーのブラウザ認証情報をチェックします。それらが存在しない場合、ユーザーは OAuth 2.0 の Google アカウント ログインフローにリダイレクトされ、トークンが今後のログインのためにブラウザの Cookie に保存されます。既存のユーザー用の Google アカウントを作成する必要がある場合は、Google Cloud Directory Sync を使用して Active Directory または LDAP サーバーと同期できます。

リクエストされた認証情報が有効である場合、認証サーバーはこれらの認証情報を使用してユーザーの ID(メールアドレスとユーザー ID)を取得します。認証サーバーは、この ID を使用してユーザーの IAM ロールをチェックし、ユーザーがリソースにアクセスする権限を持っているどうかをチェックします。

Compute Engine または Google Kubernetes Engine を使用している場合、仮想マシン(VM)のアプリケーション処理ポートにアクセスできるユーザーは IAP 認証をバイパスできます。Compute Engine と GKE のファイアウォール ルールは、IAP で保護されたアプリケーションと同じ VM 上で実行されているコードからのアクセスを防ぐことはできません。ファイアウォール ルールは別の VM からのアクセスを防ぐことはできますが、適切に構成されている場合に限ります。セキュリティを確保するには、ユーザーの責務をご覧ください。

Cloud Run を使用している場合、自動的に割り当てられた URL にアクセスできるユーザーは IAP 認証をバイパスできます。上り(内向き)の制御は、ロード バランシングを使用するために制限できますが、適切に構成されている場合に限られます。セキュリティを確保するには、ユーザーの責務をご覧ください。

承認

認証後、IAP は関連する IAM ポリシーを適用して、ユーザーがリクエストされたリソースにアクセスする権限を持っているかどうかをチェックします。リソースが存在する Google Cloud コンソール プロジェクトの IAP で保護されたウェブアプリ ユーザーの役割を持っているユーザーは、アプリケーションにアクセスする権限があります。IAP で保護されたウェブアプリ ユーザーのロールリストを管理するには、Google Cloud コンソールの IAP パネルを使用します。

リソースの IAP を有効にすると、OAuth 2.0 クライアント ID とシークレットが自動的に作成されます。自動的に生成された OAuth 2.0 認証情報を削除すると、IAP が正しく機能しなくなります。OAuth 2.0 認証情報は、Google Cloud コンソールの [API とサービス] で表示および管理できます。

ユーザーの責務

IAP は、App Engine、Cloud Load Balancing(HTTPS)、または内部 HTTP 負荷分散に対するすべてのリクエストの認証と承認を保護します。IAP は、プロジェクト内の別の VM など、プロジェクト内のアクティビティを防御しません。

セキュリティを確保するには、次の予防措置を講じる必要があります。

  • 処理インフラストラクチャを経由しないトラフィックを防御するように、ファイアウォールとロードバランサを構成します。
    • 代替手法として、Cloud Run を使用している場合は、上り(内向き)制御を使用してアクセスを制限することもできます。
  • 署名付きヘッダーまたは App Engine スタンダード環境の Users API を使用します。

次のステップ