Google Cloud Armor と他の Google プロダクトの統合

以下のセクションでは、Google Cloud Armor が他の Google Cloud の機能やプロダクトとどのように連携するかを説明します。

Google Cloud Armor と VPC のファイアウォール ルール

Google Cloud Armor のセキュリティ ポリシーと VPC ファイアウォール ルールには異なる機能があります。

  • Google Cloud Armor のセキュリティ ポリシーでは、エッジ セキュリティを提供し、Google Front End(GFE)へのクライアント トラフィックを処理します。
  • VPC ファイアウォール ルールは、バックエンドとの間のトラフィックを許可または拒否します。ターゲットが負荷分散されたバックエンド VM で、ソースが外部 HTTP(S) ロードバランサによって使用される IP 範囲である上り(内向き)許可ファイアウォール ルールを作成する必要があります。これらのルールにより、GFE とヘルスチェック システムがバックエンド VM と通信できるようになります。

たとえば、CIDR 範囲 100.1.1.0/24 と CIDR 範囲 100.1.2.0/24 からのトラフィックのみが外部 HTTP(S) ロードバランサにアクセスできるようにするシナリオを考えてみましょう。目標は、トラフィックがバックエンドの負荷分散インスタンスに直接到達できないようにすることです。つまり、関連するセキュリティ ポリシーを持つ外部 HTTP(S) ロードバランサ経由でプロキシされた外部トラフィックのみがインスタンスに到達する必要があります。

Google Cloud Armor セキュリティ ポリシーと上り(内向き)ファイアウォールを使用してアクセスを制限する。
Google Cloud Armor セキュリティ ポリシーと上り(内向き)ファイアウォールを使用してアクセスを制限する(クリックして拡大)

上の図では、Google Cloud のデプロイを次のように構成することで、セキュリティ目標を達成しています。

  1. 2 つのインスタンス グループを作成します。1 つは us-west1 リージョンに、もう 1 つは europe-west1 リージョンに作成します。
  2. バックエンド アプリケーション インスタンスをインスタンス グループの VM にデプロイします。
  3. プレミアム ティアで外部 HTTP(S) ロードバランサを作成します。シンプルな URL マップと、前の手順で作成した 2 つのインスタンス グループをバックエンドとする単一のバックエンド サービスを構成します。ロードバランサの転送ルールが 120.1.1.1 外部 IP アドレスを使用していることを確認してください。
  4. 100.1.1.0/24 および 100.1.2.0/24 からのトラフィックを許可し、他のすべてのトラフィックを拒否する Google Cloud Armor セキュリティ ポリシーを構成します。
  5. このポリシーをロードバランサのバックエンド サービスに関連付けます。手順については、セキュリティ ポリシーの構成をご覧ください。より複雑な URL マップを持つ外部 HTTP(S) ロードバランサは、複数のバックエンド サービスを参照できます。必要に応じて、セキュリティ ポリシーを 1 つ以上のバックエンド サービスに関連付けることができます。
  6. 上り(内向き)許可ファイアウォール ルールを構成して、外部 HTTP(S) ロードバランサからのトラフィックを許可します。詳細については、ファイアウォール ルールをご覧ください。

Google Cloud Armor と HTTP(S) 負荷分散および IAP

Identity-Aware Proxy(IAP)は、ユーザーの ID を検証し、そのユーザーにアプリケーションへのアクセスを許可するかどうかを決定します。外部 HTTP(S) ロードバランサの IAP を有効にするには、ロードバランサのバックエンド サービスで有効にします。同様に、エッジ Google Cloud Armor のセキュリティ ポリシーは、外部 HTTP(S) ロードバランサのバックエンド サービスに接続されます。

Google Cloud Armor セキュリティ ポリシーと IAP の両方が外部 HTTP(S) ロードバランサのバックエンド サービスに対して有効になっている場合、IAP による評価が最初に行われます。IAP がリクエストをブロックした場合、Google Cloud Armor はリクエストを評価しません。IAP がリクエストを正常に認証した場合、Google Cloud Armor はリクエストを評価します。Google Cloud Armor セキュリティ ポリシーによって拒否の判断が下された場合、リクエストはブロックされます。

IAP で IP アドレスの拒否リストと許可リストを使用する。
IAP で IP アドレスの拒否リストと許可リストを使用する(クリックして拡大)

IAP と関連する構成の詳細については、Identity-Aware Proxy のドキュメントをご覧ください。

ハイブリッド デプロイの Google Cloud Armor

ハイブリッド デプロイでは、外部 HTTP(S) ロードバランサが別のクラウド プロバイダのインフラストラクチャなど、Google Cloud の外部で実行されるアプリケーションまたはコンテンツ ソースにアクセスする必要があります。Google Cloud Armor を使用すると、このようなデプロイを保護できます。

次の図では、ロードバランサに 2 つのバックエンド サービスがあります。1 つは、バックエンドとしてインスタンス グループを持っています。もう 1 つのバックエンド サービスには、バックエンドとしてインターネット NEG があり、インターネット NEG は、サードパーティ プロバイダのデータセンターで実行されているアプリケーションに関連付けられています。

ハイブリッド デプロイ用の Google Cloud Armor。
ハイブリッド デプロイ用の Google Cloud Armor(クリックして拡大)

インターネット NEG をバックエンドとして持つバックエンド サービスに Google Cloud Armor セキュリティ ポリシーを接続すると、Google Cloud Armor は、そのバックエンド サービスを宛先とする外部 HTTP(S) ロードバランサに到着するすべての L7 リクエストを検査します。

ハイブリッド デプロイの Google Cloud Armor 保護には、インターネット NEG に適用されるものと同じ制限が適用されます。

Google Cloud Armor と Google Kubernetes Engine(GKE)Ingress

Google Cloud Armor セキュリティ ポリシーを構成したら、Kubernetes Ingress を使用して GKE でこれを有効にできます。

セキュリティポリシーの名前を BackendConfig に追加することで、セキュリティ ポリシーを BackendConfig で参照できます。次の BackendConfig マニフェストでは、example-security-policy という名前のセキュリティ ポリシーを指定しています。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Ingress 機能の詳細については、Ingress 機能の構成をご覧ください。

Google Cloud Armor と Cloud CDN

Cloud CDN と Google Cloud Armor を併用して、CDN 配信元サーバーを保護できます。Google Cloud Armor は、CDN 配信元サーバーがアプリケーション攻撃から確実に保護されるようにし、OWASP トップ 10 リスクを軽減して、レイヤ 7 フィルタリング ポリシーを適用します。

Google Cloud Armor は、キャッシュミス(Cloud CDN キャッシュを逃すリクエストやバイパスするリクエスト)に対してのみ Cloud CDN を有効にして、バックエンド サービスにセキュリティ ポリシーを適用します。

Cloud CDN 対応のバックエンド サービスにセキュリティ ポリシーが接続されている場合、Google Cloud Armor は、キャッシュから配信できない受信リクエストをセキュリティ ポリシーと比較して評価し、オリジン サーバーに転送する必要があるかどうかを判断します。ルールがリクエストに一致する場合、ルールで構成されているアクションが実行されます。

ただし、Cloud CDN 対応のバックエンド サービスに接続されているセキュリティ ポリシーは、キャッシュ ヒットに対しては適用されません。リクエストがキャッシュから配信できる場合、セキュリティ ポリシーによるそのリクエストへの対応には関係なく、それ以外の場合は有効なクライアントに配信されます。

次の図は、Google Cloud Armor が Cloud CDN オリジンとどのように連携するかを示しています。

Cloud CDN での Google Cloud Armor の使用。
Google Cloud Armor と Cloud CDN(クリックして拡大)

Google Cloud Armor とサーバーレス アプリ

Google Cloud Armor セキュリティ ポリシーは、Cloud RunApp EngineCloud Functions サービスを参照するサーバーレス NEG バックエンドで使用できます。

ただし、サーバーレス NEG と Cloud Functions とともに Google Cloud Armor を使用する場合は、サーバーレス エンドポイントに対するすべてのアクセスが Google Cloud Armor セキュリティ ポリシーによってフィルタリングされるように、特別な手順を行う必要があります。

Cloud Functions サービスのデフォルト URL が割り当てられたユーザーは、ロードバランサをバイパスして、サービス URL に直接アクセスできます。これにより、Google Cloud Armor セキュリティ ポリシーを回避できます。Google Cloud が Cloud Functions サービスに自動的に割り当てる URL は無効にできません。

アクセス制御をすべての受信トラフィックに確実に適用するには、内部トラフィックと外部 HTTP(S) ロードバランサによって公開されるパブリック IP アドレスに送信されるトラフィックのみを許可する Cloud Functions の構成時に internal-and-gclb を使用します。Cloud Functions によって設定された cloudfunctions.net や他のカスタム ドメインに送信されたトラフィックは、ブロックされます。これにより、ユーザーは、外部 HTTP(S) ロードバランサを介して設定されたアクセス制御(Google Cloud Armor セキュリティ ポリシーなど)を回避できなくなります。

サーバーレス NEG の詳細については、サーバーレス ネットワーク エンドポイント グループの概要サーバーレス NEG の設定をご覧ください。

次のステップ