Cloud Run単体からの卒業：IAPで社内限定アクセスを実現
Posted date at 2025-09-28
🚀概要（Exective Summmary）
- ・やったこと
Cloud Run単体構成から、HTTPSロードバランサ（LB）＋IAP＋Cloud Armorを前段に置く構成へ移行し、社内（Google Workspaceドメイン）のみアクセス許可を実現した。
- ・ねらい
Cloud Runのアプリ内OAuthだけに依存せず、アプリの入口で絞る（ゼロトラスト的）ことで、ログイン画面に到達する前にアクセス制御を行う。
- ・想定している効果
セキュリティ向上、公開面の標準化（マネージド証明書、WAF/ACL）、将来の複数サービス統合（同一ドメイン/サブドメイン配下）もしやすい。
- ・コスト
LBや外部IP、転送量、Cloud Armor など新たな課金要素が増える。まずは小さく始めて実測をする
- ・補足
証明書エラー（ERR_CERT_AUTHORITY_INVALID）など、DNS伝播／証明書プロビジョニング待ちや設定の不整合で起こりがち。手順内で回避ポイントを記載
🚀目次
1.背景と課題：Cloud Run単体構成
2.目標と要件：アプリケーション到達前に社内のみ入れる入口を用意
3.全体アーキテクチャ（Before/Afterとデータフロー）
4.使用したGoogleCloudのサービスと役割
5.実装ステップ（コンソールUIベース）
6.Cloud Armorで何が守れる？
7.実装と落としどころ：IAP vs アプリ内OAuth
8.コストの考え方（目安の出し方）
まとめ
🚀1.課題と背景：Cloud Run単体構成の課題
これまではCloud Run単体＋アプリ内のGoogle OAuth（同意画面“内部”）で社内限定っぽくしていた。ただしこの方式だと、
・ログイン画面へは誰でも到達しうる（アプリ側で弾くのは可能でも「入口が開いている」状態）。
・WAFやDDoS緩和、L7制御を前段で標準化しにくい。
・将来、複数バックエンドや複数ドメイン/サブドメインの統合配信を考えると、エッジ側でまとめて制御・最適化したい。
そこで、HTTPS LB（エッジ）＋IAP（入口で認証）に移行して、入口で弾く構成を試みた。
🚀2.目標と要件：アプリケーション到達前に社内のみ入れる入口を用意
以下の要件を満たす構成を用意しました。
・社内Googleアカウント（例：@company.jp）のみ許可。
・社外アカウント（例：@gmail.com）はIAPの画面で拒否。
・L7（HTTP/HTTPS）で証明書・ルーティング・WAF/ACLを共通化。
・既存のCloud Runはそのまま再利用（Serverless NEG経由）。
🚀3.全体アーキテクチャ（Before/After）
🐡Before（Cloud Run単体）
アプリケーションログイン時に検証する。
・Internet → Cloud Run（カスタムドメイン直付け or .run.app）
・アプリ内OAuthで社外を弾く（内部ユーザのみ許可）
🐡After（今回の構成:IAP+LB）
IAPで検証する。
・Internet → HTTPS LB（グローバル）→ IAP（認可）→ Serverless NEG → Cloud Run
・DNSはCloud DNSでA/AAAAをLBのフロントエンドに向ける
・Cloud ArmorでL7ポリシ適用（許可/拒否、レート制御など）
🐡実行結果
IAPでのブロック画面
🚀4.使用したGoogleCloudのサービスと役割
・Cloud Domains：ドメインの取得/管理サービス。
・Cloud DNS：DNSゾーンの権威としてA/AAAA/CNAMEなどを登録。
・外部固定アドレス：グローバル静的IPを発行し、ロードバランサのフロントエンドで割り当てる。
・Cloud Load Balancing（HTTP(S)）：エッジでTLS終端、マネージドSSL、URLマップ、Cloud Armor、・IAP（背後のバックエンドが適合する場合）を提供。
・IAP (Identity-Aware Proxy)：入口で認証・認可し、許可ユーザ以外はアプリのログイン画面に到達不可。
・Cloud Armor：L7レベルのWAF/セキュリティポリシ（IP許可/拒否、国/ASN、カスタムルール、レート制御、Botシグナル連携等）。
・Cloud Run：サーバレス本体。LBからはServerless NEG経由で接続。
🚀5.実装ステップ（コンソールUIベース）
5.1 ドメインとDNS
1.Cloud Domainsでドメイン取得（例：hoge.com）。
2.Cloud DNSで公開ゾーンを作成し、ネームサーバをレジストラ側へ反映。
3.後でLBに指定したグローバル静的IPをA/AAAAへ設定（@、****app. など必要なサブドメイン分）。
5.2 HTTPSロードバランサ（外向き）
1.グローバル静的IPを予約（ネットワーク サービス→IPアドレス）。
2.HTTP(S)ロードバランサを作成：
・フロントエンド：HTTPS、先ほどの静的IP、マネージドSSL証明書（ドメイン：hoge.com, app.hoge.com）
・バックエンド：Serverless NEGを作成→対象はCloud Runサービスを選択
・URLマップ/ホスト＆パスルール：app.hoge.com→該当NEG
※証明書はDNSが正しく向き、Let's Encrypt等の検証が通ると自動発行。通常、数分〜最大1時間ほど。
3.証明書エラー対策：
・A/AAAAがLBのIPを指しているか、伝播完了を確認
・Managed SSLのステータスがActiveになるまで待つ
・早まってアクセスするとERR_CERT_AUTHORITY_INVALIDが出やすい
5.3 IAPを有効化（入口で社内限定）
1.LBのバックエンド セキュリティでIAPを有効化（対象：バックエンド→Serverless NEG）。
2.IAPのOAuthクライアントは自動的に作成される（必要に応じて同意画面の調整）。
3.IAP保護対象へのアクセスに社内Googleグループまたはドメイン単位で許可を付与。
・例：Group: all@company.jp を IAP-secured Web App User に追加。
5.4 Cloud Armor ポリシ適用（任意）
1.Cloud Armorポリシを作成（基本はデフォルト許可＋必要な拒否/レート制御）。
2.LBのフロントエンドまたはバックエンドにポリシをアタッチ。
捕捉：OWASP ModSecurity Core Rule Set (CRS) をベースにした 事前定義済みルールセット が用意されている。
・SQLインジェクション
・クロスサイトスクリプティング (XSS)
・ローカルファイルインクルード (LFI)
・リモートファイルインクルード (RFI)
・その他の代表的なアプリ層攻撃
🚀6.Cloud Armorで何が守れる？
1.不正アクセスや攻撃を事前に遮断
国やIPアドレス単位でアクセス制御ができるため、海外からの不審なアクセスや特定の攻撃元を即座にブロックできる。
2.Webアプリへの脅威からの防御
SQLインジェクションやXSSといった「情報漏えいにつながる攻撃」を、アプリに届く前に食い止められる。
3.DDoS攻撃による業務停止を防ぐ
短時間に大量のリクエストが集中しても、レート制御やGoogleのインフラを活かした自動防御により、サービスを落ちにくくします。これにより「画面が表示されない」「社員が使えない」といった業務停止リスクを減らる。
4.一括でセキュリティポリシーを適用できる
個別のアプリごとに対策するのではなく、ロードバランサにまとめて適用できるので、全サービスで統一されたセキュリティ基準を維持できます。監査や内部統制の観点からも有効である。
5.役割の違い：IAPと併用
・IAP：誰が入れるかを決める「入場ゲート」
・Cloud Armor：入場しようとする人が「攻撃者かどうか」を見極める警備員
→ 両方を併用することで「正しい人だけ、かつ安全に」利用できる環境を作れる。
🚀7.実装と落としどころ：IAP vs アプリ内OAuth
・IAP
LBの直後で認証・認可。非許可ユーザはアプリへ未到達。監査ログが一元化。入口で止めるので表面積が小さい。
・アプリ内OAuth
アプリ到達後に弾く（入口は開く）。アプリのユーザテーブル連携（初回登録やロール付与）はやりやすい。
⇒併用が実務的と考える。IAPで社内限定＋アプリ内でユーザ登録/権限。
🚀8.コストの考え方
厳密な料金は変動し得るため、ここでは算出の枠組みを示します。 グローバル外部IP（LB用）HTTP(S) LBの転送/ルール/リクエスト関連Cloud Armor（ポリシやリクエスト数に応じた従量）Cloud Run（リクエスト数／CPU・メモリ・起動時間・出力帯域）
固定・準固定要素
カスタムドメイン（LB用）
グローバル外部IP（LB用）
HTTP(S) LBの転送/ルール/リクエスト関連
Cloud Armor（ポリシやリクエスト数に応じた従量）
Cloud Run（リクエスト数／CPU・メモリ・起動時間・出力帯域）
シミュレートした結果、現在の想定条件（社内使用）の場合、CloudRun単体+$20～$30で運用できそうです。
🚀まとめ
LBを導入し、IAPで絞る、WAF（Armor）で守る構成を実現しました。コストが増える要素はありますが、セキュリティの強化につながるため、実コストを見ながら継続して運用するかを検討したいと思います。
←ホームに戻る