🛡️

Cloud ArmorとIdentity Aware ProxyでWebアプリを保護する

に公開
Google Cloud
アプリ開発
Identity-Aware Proxy
clouarmor
tech

最近Google Cloudを触る機会が多く、普段は分析環境の運用やデータ分析をすることが多いのですが、Webアプリを開発することもあります。
今回は、Webアプリの開発において、セキュリティ方面でお世話になっているサービスがあるのでその話をしたいと思います。

想定するアプリの全体像

Cloud RunにWebアプリケーションをデプロイし、それをユーザーが利用するような構成です。

簡単に構成内容を説明します。

ユーザーアクセス・セキュリティ層

  • Application Load Balancer (ALB) ：ユーザーからのアクセスを最初に受け付け、適切な宛先（この場合はCloud Run）に振り分ける負荷分散装置です
    • Identity-Aware Proxy (IAP)、Cloud Armor ：後述しますが、共にセキュリティサービスです

アプリケーション実行層

  • Cloud Run (フロントエンド / バックエンド)：コンテナ化されたアプリケーションを実行するサーバーレス環境です。サーバー管理が不要で、アクセス数に応じて自動でスケール（増減）します。図ではフロントエンドとバックエンドが分かれて構成されています

CI/CD（開発・デプロイ）層

  • GitHub ソースコードを管理する場所です。ここへのコードの変更（プッシュなど）がトリガーとなって、自動デプロイのフローが開始されます
  • Cloud Build：Google CloudのCI/CDサービスです。GitHubからコードを取得し、テストやコンテナイメージのビルド、そしてCloud Runへのデプロイを自動で行います
  • Artifact Registry：Cloud Buildによって作成されたコンテナイメージ（アプリの実行パッケージ）を保管・管理する場所です。Cloud Runはここからイメージを取得して起動します

今回はこの図の左側、Application Load Balancerに注目します。具体的にはCloud ArmorとIdentity-Aware Proxyというサービスを使い、比較的手軽な操作でアプリケーションのセキュリティを強化していきます。社内向けのWebアプリ、という想定で記載しています。

Cloud Armorとは

https://docs.cloud.google.com/armor/docs/cloud-armor-overview?hl=ja

Cloud Armor は、分散型サービス拒否（DDoS）攻撃、クロスサイト スクリプティング（XSS）や SQL インジェクション（SQLi）のようなアプリケーション攻撃など、さまざまなタイプの脅威から Google Cloud デプロイを保護するのに役立ちます。

公式から引用しました。セキュリティの脅威となるような攻撃からアプリケーションを保護してくれます。
今回はIP制限をかける目的で設定しました。社内向けのWebアプリなので、社内VPNのIPアドレスからのみアクセスできるようにします。

Identity-Aware Proxyとは

https://docs.cloud.google.com/iap/docs/concepts-overview?hl=ja

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

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

こちらも公式から引用。
特定のユーザーにのみアプリへのアクセス権を与え、それ以外のユーザーからはアクセスできないようにできます。

具体設定

以下の設定では、Cloud ArmorとIdentity-Aware Proxyを用いて、以下のセキュリティを実現しています。

  • 社内VPNのIPアドレスからのみWebアプリにアクセスでき、それ以外のIPアドレスからはアクセスできない
  • （社内の）特定のユーザーのみがWebアプリにアクセスでき、それ以外のユーザーからはアクセスできない

手順書のように細かくは書いていないですが、ポイントを押さえて書いてみたつもりです。Cloud Armorのポリシー設定→ロードバランサーの設定→Identity-Aware Proxyの設定、の順に行います。

実装手順

Cloud Runにアプリケーションをデプロイする部分は省略し、上述したサービス周りの手順だけ記載しています。Cloud Armor、Identity-Aware Proxyはともにロードバランサーにアタッチして使います。

Cloud Armorの設定

Cloud Armorでは要件を満たすポリシーを作成します。これを後述のロードバランサーの設定でアタッチすることで機能するようになります。

この画像のように、二つのルールを設けています。一つは社内VPNに対応するIPアドレスを許可するルール、もう一つは全てのIPアドレスに対して拒否するルールです。許可ルールの優先度を拒否ルールよりも高くすることで、指定されたIPアドレスに対しては優先度の高い許可ルールが適用され、それ以外のIPアドレスに対しては拒否ルールが適用されます。

ロードバランサーの設定

ロードバランサーの設定はフロントエンド、バックエンド、ルーティングルールに分かれます。

  • フロントエンド：インターネットに対してIPアドレスとHTTPSのポートを公開し、ユーザーからの接続を受け付けます
  • バックエンド：Cloud Runのサービスに繋げます。今回の構成ではフロントエンドのCloud Run、バックエンドのCloud Runのそれぞれに対して「バックエンドサービス」を設定しています。Cloud Armor、Identity-Aware Proxyの設定はここで行います
  • ルーティングルール：ユーザーがアクセスしてきたパスやホスト名をみて、どのバックエンドサービスに送るかのルーティングを設定します

バックエンドの設定は、↓のように二つのバックエンドサービスを設定します。フロントエンドのCloud Run、バックエンドのCloud Runに対応しています。

フロントエンドのCloud Runに対応するサービスの設定では、Identity-Aware ProxyとCloud Armorの両方を適用しています。

バックエンドのCloud Runに対応するサービスの設定では、Cloud Armorのみ設定しています。ブラウザからAPIとしてアクセスするため、ログイン画面（IAP）は不要ですが、接続元制限は必要なためCloud Armorのみ適用しています。

適用しているCloud Armorのポリシーはどちらも同じ（社内VPNのIPアドレスのみ許可）です。

Identity-Aware Proxyの設定

ロードバランサーが作成されると、Identity-Aware Proxyのページに表示されます。

フロントエンド用のサービスを選択すると、ロール/プリンシパルの一覧画面が出てきます。この中で「IAP-secured Web App User」に追加されたユーザーは、Webアプリにアクセスできるようになります。

個人のユーザーでも、グループでも追加可能です。

おわりに

Cloud ArmorとIdentity-Aware Proxyを使うことで、IP制限やユーザー認証などのセキュリティを強化することができます。今回はIP制限でCloud Armorを使用しましたが、他にも様々な脅威から保護するように設定できます。

個人的には、業務でAIを扱う中でセキュリティ周りの勉強もしたいなと思っており、基礎的な理解が足りないと思うことが多いので一度本などで体系的に勉強する必要性を感じています。

Discussion