以降のセクションでは、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 からのトラフィックのみがグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサにアクセスできるようにするシナリオを考えてみましょう。目標は、トラフィックがバックエンドのロード バランシング インスタンスに直接到達できないようにブロックすることです。つまり、グローバル外部アプリケーション ロードバランサやセキュリティ ポリシーが関連付けられている従来のアプリケーション ロードバランサ経由でプロキシされた外部トラフィックのみがインスタンスに到達できるようにします。
上の図は、次のデプロイ構成を示しています。
- 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 と関連する構成の詳細については、Identity-Aware Proxy のドキュメントをご覧ください。
Cloud Armor とハイブリッド デプロイ
ハイブリッド デプロイでは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサは、 Google Cloudの外部（別のクラウド プロバイダのインフラストラクチャなど）で実行されるアプリケーションやコンテンツ ソースにアクセスする必要があります。Cloud Armor を使用すると、このようなデプロイを保護できます。
次の図では、ロードバランサに 2 つのバックエンド サービスがあります。1 つは、バックエンドとしてインスタンス グループを持っています。もう 1 つのバックエンド サービスには、バックエンドとしてインターネット NEG があり、インターネット NEG は、サードパーティ プロバイダのデータセンターで実行されているアプリケーションに関連付けられています。
インターネット 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 CDN が有効になっているバックエンド サービスに Cloud Armor バックエンド セキュリティ ポリシーを適用すると、これらのポリシーは、バックエンド サービスにルーティングされるリクエストにのみ適用されます。これには、動的コンテンツ リクエストとキャッシュミス（Cloud CDN キャッシュに入らなかったリクエストや、キャッシュをバイパスしたリクエスト）が含まれます。
エッジ セキュリティ ポリシーとバックエンド セキュリティ ポリシーが同じバックエンド サービスに接続されている場合、バックエンド セキュリティ ポリシーは、エッジ セキュリティ ポリシーを通過したキャッシュミス リクエストに対してのみ適用されます。
次の図は、エッジ セキュリティ ポリシーでリクエストが許可された後にバックエンド セキュリティ ポリシーが Cloud CDN オリジンに対して機能する仕組みを示しています。
Cloud CDN の詳細については、Cloud CDN のドキュメントをご覧ください。
Cloud Armor と Cloud Run、App Engine、または Cloud Run functions
Cloud Armor のセキュリティ ポリシーは、Cloud Run、App Engine、Cloud Run functions サービスを参照するサーバーレス NEG バックエンドで使用できます。
ただし、サーバーレス NEG、Cloud Run、または Cloud Run functions とともに Cloud Armor を使用する場合は、サーバーレス エンドポイントに対するすべてのアクセスが Cloud Armor のセキュリティ ポリシーによってフィルタリングされる必要があります。
サーバーレス アプリケーションのデフォルト URL が割り当てられているユーザーは、ロードバランサをバイパスしてサービス URL に直接アクセスできます。このとき、Cloud Armor のセキュリティ ポリシーはバイパスされます。この問題に対処するには、 Google Cloud Cloud Run サービスまたは Cloud Run functions（第 2 世代）の関数に自動的に割り当てられるデフォルトの URL を無効にします。App Engine アプリケーションを保護するには、上り（内向き）制御を使用します。
上り（内向き）制御を使用してすべての受信トラフィックにアクセス制御を適用するには、Cloud Run functions または Cloud Run を構成する際に internal-and-gclb Ingress 設定を使用します。internal-and-gclb Ingress 設定では、内部トラフィックと、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサによって公開された外部 IP アドレスに送信されるトラフィックのみが許可されます。プライベート ネットワークの外部からそれらのデフォルト URL に送信されたトラフィックはブロックされます。これにより、ユーザーは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを介して設定されたアクセス制御（Cloud Armor セキュリティ ポリシーなど）を回避できなくなります。
サーバーレス NEG の詳細については、サーバーレス ネットワーク エンドポイント グループの概要とサーバーレス NEG の設定をご覧ください。
Cloud Armor と Cloud Service Mesh
サービス メッシュの内部サービス セキュリティ ポリシーを構成して、クライアントごとにグローバルなサーバーサイドのレート制限を適用できます。これにより、サービスの使用可能な容量を公平に共有し、悪意のあるクライアントや不正な動作をするクライアントがサービスに過剰な負荷をかけるリスクを軽減できます。Cloud Service Mesh エンドポイント ポリシーにセキュリティ ポリシーを接続して、サーバーサイドでインバウンド トラフィックにレート制限を適用します。ただし、TCP トラフィック ルーティングを使用している場合は、Google Cloud Armor のセキュリティ ポリシーを構成できません。Cloud Service Mesh で Cloud Armor を使用する方法の詳細については、Cloud Armor でレート制限を構成するをご覧ください。