Identity-Aware Proxy (IAP)

解決する課題

社内アプリや管理用の VM を、ネットワーク境界（VPN・踏み台・ファイアウォール）ではなく「誰がアクセスしているか」で守りたい、というゼロトラストの要求に応えます。

• VPN を張らないと社内アプリに入れない → ブラウザだけで、認証済みユーザーに公開できるようにしたい
• VM に SSH するために踏み台や公開 IP を用意したくない → 外部 IP なしで SSH/RDP したい
• アプリ側に認証コードを実装したくない → 入口（プロキシ）で一括認証し、アプリには本人情報だけ渡したい
• 「正しい人が・正しい状態の端末で」入れているかを確認したい → ID とコンテキスト（端末・場所など）で認可したい

主要概念と用語

• Identity-Aware Proxy（IAP）: アプリや VM の手前に立つ Google 管理のリバースプロキシ。認証されていないリクエストを Google ログインへ誘導し、IAM で認可してから背後へ通す
• IAP-secured Web App User（roles/iap.httpsResourceAccessor）: その IAP リソースへ「入れる人」を表す IAM ロール。このロールを誰に付けるかがアクセス制御の中心
• IAP TCP Forwarding（roles/iap.tunnelResourceAccessor）: SSH/RDP など TCP の転送トンネルを通してよい人を表すロール
• OAuth クライアント / IAP 同意画面: Web アプリ保護で利用者を認証するための OAuth 構成
• シグネチャ付きヘッダー（署名付き JWT）: IAP が背後のアプリへ渡す、改ざん検証可能な本人情報。アプリは x-goog-iap-jwt-assertion を検証して ID を確認する
• コンテキストアウェアアクセス（Access Context Manager のアクセスレベル）: ID に加えて端末状態・IP・地域などの条件で許可を絞る仕組み。BeyondCorp Enterprise の中核
• 背後のリソース: 保護対象。HTTP(S) ロードバランサー配下のバックエンド（App Engine・Cloud Run・GKE・Compute Engine）と、トンネル経由の VM

仕様・制限・クォータ

• 大きく 2 系統ある。**Web アプリ保護（HTTP(S) ロードバランサー前提）**と、TCP 転送（SSH/RDP などをトンネル）
• Web アプリ保護では原則として外部 HTTP(S) ロードバランサーが必要。バックエンドが App Engine・Cloud Run・GKE・Compute Engine いずれでも前段の LB で IAP を有効化する
• 認証は Google アカウント / Cloud Identity / Workspace が基本。外部 ID は Identity Platform などと組み合わせて扱う
• IAP は L7 の入口認可であり、アプリ内部のきめ細かい認可（業務ロール）は別途アプリ側で実装する
• TCP 転送は専用の IP レンジからトンネルされるため、そのレンジを許可するファイアウォールが必要

内部の仕組み

リクエストはアプリに届く前に IAP で認証・認可されます。

1. 未認証のリクエストは Google のログインへリダイレクトされる
2. 認証後、IAP は IAM ポリシーを評価し、対象リソースに対する roles/iap.* を持つユーザーだけを通す
3. コンテキストアウェアアクセスが設定されていれば、端末状態・IP・地域などのアクセスレベルも満たすか確認する
4. 通過したリクエストには、IAP が署名付き JWTなどのヘッダーで本人情報を付与してアプリへ転送する

設計パターン / ベストプラクティス

• VPN/踏み台の置き換え: 社内 Web アプリは IAP + 外部 LB で公開し、VPN なしでブラウザアクセスにする
• 公開 IP なしの SSH/RDP: VM には外部 IP を付けず、IAP TCP 転送で運用アクセスする
• 入口認証 + アプリ内認可の分離: IAP で「入れる人」を絞り、業務上の細かい権限はアプリ側で署名付き JWT の ID を使って判定する
• グループ単位で付与: roles/iap.* は個人ではなく Google グループへ付け、入退社に強くする
• コンテキストで強化: 機微なアプリは ID に加え管理対象端末・社内 IP・地域などのアクセスレベルを必須化する

運用・監視

• Cloud Audit Logs で「誰がいつ IAP 経由でアクセスしたか／拒否されたか」を監査する
• アクセス不可の切り分けは、IAM バインディング（roles/iap.*）→ アクセスレベル（コンテキスト）→ ファイアウォール／経路の順で確認する
• LB のヘルスチェックやバックエンドの公開設定が、IAP の有効化後も成立しているかを点検する
• 端末・地域条件を厳しくしすぎると正規ユーザーが締め出されるため、段階的に締める

コスト

IAP の利用そのものに対する課金は基本的になく、背後で使うロードバランサー・VM・バックエンドサービスなどの通常料金がかかります。なお、コンテキストアウェアアクセス（端末条件などの高度な制御）は BeyondCorp Enterprise の機能として提供され、上位エディションが必要になる場合があります。

セキュリティ

• 最小権限: roles/iap.httpsResourceAccessor / roles/iap.tunnelResourceAccessor を必要なグループだけに付与する
• 迂回経路を塞ぐ: 外部 IP・直接ポートを排除し、バックエンドは IAP（と LB）経由のみ許可する
• ヘッダー検証: アプリは署名付き JWT を検証し、ヘッダーを鵜呑みにしない
• コンテキスト強化: ID に端末・IP・地域条件を重ね、フィッシングで奪われた認証情報だけでは入れないようにする
• 監査: Audit Logs で許可/拒否を継続的に確認する

Well-Architected の観点

• セキュリティ: ネットワーク境界ではなく ID とコンテキストで認可するゼロトラストを実現し、VPN/踏み台という攻撃面を減らす。入口で一括認証し、最小権限のロール付与で「入れる人」を厳密に管理する
• アプリ側は署名付き JWT を検証して多層防御とし、Audit Logs で継続的に可観測性を確保する

試験で問われるポイント

関連サービス・比較

IAP に近い AWS のサービスとして Verified Access があります。どちらも「VPN を張らずに ID とコンテキストでアプリへのアクセスを認可する」発想ですが、構成要素の呼び方が異なります。

ハンズオン / CLI例

# 1) Web アプリ保護: 特定ユーザーに「入れる」ロールを付与
#    （IAP は前段の外部 HTTP(S) ロードバランサーで有効化済みとする）
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=my-backend-service \
  --member="group:app-users@example.com" \
  --role="roles/iap.httpsResourceAccessor"

# 2) TCP 転送: VM へ SSH してよいユーザーにロールを付与
gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/iap.tunnelResourceAccessor"

# 3) 外部 IP なしの VM へ IAP トンネル経由で SSH する
gcloud compute ssh my-vm \
  --zone=asia-northeast1-a \
  --tunnel-through-iap