このページでは、 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 が認証と認可のチェックを行います。
認証
リソースへのリクエストは、Cloud Run、App Engine、Cloud Load Balancing（外部および内部 HTTP(S) ロード バランシング）経由で送信されます。 Google Cloud これらのサービスの処理インフラストラクチャ コードは、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 を使用している場合は、次の方法で IAP を有効にできます。
- Cloud Run サービスに直接設定します。これにより、IAP は、自動割り当て URL や構成されたロードバランサ URL など、Cloud Run へのすべての上り（内向き）パスを保護できます。この構成は、IAP を有効にする Cloud Run サービスが 1 つある場合に便利です。
- Cloud Run バックエンドを使用するロードバランサを介してアクセスします。この構成は、1 つのグローバル ロードバランサの背後に異なるリージョンに複数の Cloud Run サービスがある場合に便利です。この構成では、自動割り当てられた URL は IAP で保護されていないため、直接アクセスされる可能性があります。セキュリティを確保するには、ユーザーの責務をご覧ください。
Cloud Run サービスがロードバランサの背後にある場合は、ロードバランサと Cloud Run サービスの両方で IAP を有効にしないでください。
承認
認証後、IAP は関連する IAM ポリシーを適用して、ユーザーがリクエストされたリソースにアクセスする権限を持っているかどうかをチェックします。リソースが存在するGoogle Cloud コンソール プロジェクトの IAP で保護されたウェブアプリ ユーザーのロールを持っているユーザーは、アプリケーションにアクセスする権限があります。IAP で保護されたウェブアプリ ユーザーのロールリストを管理するには、コンソールの IAP パネル Google Cloud を使用します。
リソースの IAP を有効にすると、OAuth 2.0 クライアント ID とシークレットが自動的に作成されます。自動的に生成された OAuth 2.0 認証情報を削除すると、IAP が正しく機能しなくなります。OAuth 2.0 認証情報は、Google Cloud コンソールの [API とサービス] で表示および管理できます。
コンテキストアウェア アクセス
認可ステップの一環として、コンテキスト対応アクセスを使用して、次のタイプのリソースへの安全なアクセスを提供できます。
Google Cloud コンソールと API
- Google Cloudへのインフラストラクチャ アクセスを保護する最初の防衛レイヤ。
- 高度なコンテキストアウェア Google Cloud ユーザー アクセス。
仮想マシン（VM）
- Google Cloud や他のクラウドの VM への管理 SSH/RDP アクセスを有効にします。
- 堅牢なコンテキスト認識制御を実装して、指定された管理者のみにアクセスを制限できます。
ウェブ アプリケーション
- Google Cloud などのクラウドでホストされているウェブ アプリケーションの認可と認証を提供します。
- 不正アクセスとデータ損失を防ぐために、継続的な認可を提供します。
ユーザーの責務
IAP は、Cloud Run、App Engine、Cloud Load Balancing（HTTPS）、内部 HTTP ロード バランシングに対するすべてのリクエストの認証と承認を保護します。
セキュリティを確保するには、次の予防措置を講じる必要があります。
- ロードバランサで IAP を有効にする場合は、バックエンド リソースに直接アクセスできるかどうかを確認します。
- バックエンド リソースが VM の場合は、ロードバランサを経由しないトラフィックを防御するようにファイアウォール ルールを構成します。IAP は、プロジェクト内の別の VM など、プロジェクト内のアクティビティを防御しません。
- バックエンド リソースが Cloud Run サービスの場合は、run.app URL を無効にして、すべての上り（内向き）がロードバランサ経由で確実に送信されるようにできます。run.app URL を有効にしたままにする場合は、上り（内向き）制御を使用して、ネットワーク外からのトラフィックをブロックする必要があります。
- 署名付きヘッダーを使用するようにアプリを更新するか、App Engine スタンダード環境の Users API を使用します。
次のステップ
- 次のいずれかのタスクを行うことにより、IAP の使用を開始する。
- IAP を Cloud Run サービスで直接有効にするか、Cloud Run バックエンドを使用するロードバランサで有効にします。
- Google アカウントでアクセスを管理するための App Engine のクイックスタートを完了する
- Compute Engine の IAP を有効にする
- GKE の IAP を有効にする
- オンプレミス アプリの IAP を有効にする
- 詳細: