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

以降のセクションでは、Cloud Armor が Google Cloud の他の機能やプロダクトと連携する方法について説明します。

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

Cloud Armor のセキュリティポリシーと VPC ファイアウォールルールは異なる役割を果たします。

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

たとえば、CIDR の範囲 100.1.1.0/24 と CIDR の範囲 100.1.2.0/24 からのトラフィックのみがグローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサにアクセスできるようにするシナリオを考えてみましょう。目標は、トラフィックがバックエンドのロードバランシングインスタンスに直接到達できないようにブロックすることです。つまり、グローバル外部アプリケーションロードバランサやセキュリティポリシーが関連付けられている従来のアプリケーションロードバランサ経由でプロキシされた外部トラフィックのみがインスタンスに到達できるようにします。

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

上の図は、次のデプロイ構成を示しています。

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

Cloud Armor と外部アプリケーションロードバランサおよび IAP

Identity-Aware Proxy（IAP）は、ユーザーの ID を検証し、そのユーザーがアプリケーションにアクセスできるかどうかを判断します。グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサで IAP を有効にするには、ロードバランサのバックエンドサービスを使用します。同様に、Cloud Armor のエッジセキュリティポリシーは、グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサのバックエンドサービスに接続されます。

Cloud Armor のセキュリティポリシーと IAP の両方がバックエンドサービスで有効になっている場合、評価の順序はロードバランサの種類によって異なります。

グローバル外部アプリケーションロードバランサのバックエンドサービスの場合、Cloud Armor の評価が最初に行われます。Cloud Armor でリクエストがブロックされた場合、IAP はリクエストを評価しません。Cloud Armor でリクエストが許可された場合、IAP はリクエストを評価します。IAP がリクエストを認証しなかった場合、リクエストはブロックされます。
従来のアプリケーションロードバランサのバックエンドサービスの場合、IAP の評価が最初に行われます。IAP がリクエストを認証した場合、Cloud Armor でリクエストが評価されます。IAP によるリクエストの認証が失敗した場合、Cloud Armor でリクエストは評価されません。

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

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

Cloud Armor とハイブリッドデプロイ

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

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

ハイブリッドデプロイ用の Cloud Armor。 — ハイブリッドデプロイ用の Cloud Armor（クリックして拡大）

インターネット NEG をバックエンドとして持つバックエンドサービスに Cloud Armor のセキュリティポリシーを接続すると、グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサに到着した、そのバックエンドサービス宛てのすべてのレイヤ 7 のリクエストが検査されます。

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

Cloud Armor と Google Kubernetes Engine（GKE）

以下のセクションでは、Cloud Armor が GKE と連携する仕組みについて説明します。

GKE Ingress

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 の構成をご覧ください。

GKE Gateway

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

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

サービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

マルチクラスタサービス

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Cloud Armor バックエンドセキュリティポリシーの構成の詳細については、Cloud Armor バックエンドセキュリティポリシーを構成してバックエンドサービスを保護するをご覧ください。

Cloud Armor と Cloud CDN

Cloud CDN と Cloud Armor を併用することで、CDN オリジンサーバーを保護できます。Cloud Armor は、CDN オリジンサーバーをアプリケーション攻撃から確実に保護し、OWASP トップ 10 リスクを軽減して、レイヤ 7 フィルタリングポリシーを適用します。Cloud Armor と Cloud CDN の連携に影響するセキュリティポリシーには、エッジセキュリティポリシーとバックエンドセキュリティポリシーの 2 種類があります。

エッジセキュリティポリシー

グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサの背後にある Cloud CDN 対応バックエンドサービスと Cloud Storage バックエンドバケットには、エッジセキュリティポリシーを使用できます。エッジセキュリティポリシーを使用すると、コンテンツがキャッシュから提供される前にリクエストをフィルタリングできます。

Cloud Armor と他の Google プロダクトの統合 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

Cloud Armor と外部アプリケーション ロードバランサおよび IAP

Cloud Armor とハイブリッド デプロイ