以下のセクションでは、Google Cloud Armor が他の Google Cloud の機能やプロダクトとどのように連携するかを説明します。
Google Cloud Armor と VPC のファイアウォール ルール
Google Cloud Armor のセキュリティ ポリシーと VPC ファイアウォール ルールには異なる機能があります。
- Google Cloud Armor のセキュリティ ポリシーでは、エッジ セキュリティを提供し、Google Front End（GFE）へのクライアント トラフィックを処理します。
- VPC ファイアウォール ルールは、バックエンドとの間のトラフィックを許可または拒否します。上り（内向き）許可ファイアウォール ルールを作成する必要があります。そのターゲットは負荷分散されたバックエンド VM で、ソースがグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサで使用される IP 範囲です。これらのルールにより、GFE とヘルスチェック システムがバックエンド VM と通信できるようになります。
たとえば、CIDR 範囲 100.1.1.0/24 と CIDR 範囲 100.1.2.0/24 からのトラフィックのみがグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサにアクセスできるようにするシナリオを考えてみましょう。目標は、トラフィックがバックエンドのロード バランシング インスタンスに直接到達できないようにすることです。つまり、グローバル外部アプリケーション ロードバランサやセキュリティ ポリシーが関連付けられている従来のアプリケーション ロードバランサ経由でプロキシされた外部トラフィックのみがインスタンスに到達する必要があります。
上の図では、Google Cloud のデプロイを次のように構成することで、セキュリティ目標を達成しています。
- 2 つのインスタンス グループを作成します。1 つは
us-west1リージョンに、もう 1 つはeurope-west1リージョンに作成します。 - バックエンド アプリケーション インスタンスをインスタンス グループの VM にデプロイします。
- グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサをプレミアム ティアで作成します。シンプルな URL マップと、前の手順で作成した 2 つのインスタンス グループをバックエンドとする単一のバックエンド サービスを構成します。ロードバランサの転送ルールが
120.1.1.1外部 IP アドレスを使用していることを確認してください。 - 100.1.1.0/24 および 100.1.2.0/24 からのトラフィックを許可し、他のすべてのトラフィックを拒否する Google Cloud Armor セキュリティ ポリシーを構成します。
- このポリシーをロードバランサのバックエンド サービスに関連付けます。手順については、セキュリティ ポリシーの構成をご覧ください。より複雑な URL マップを持つ外部 HTTP(S) ロードバランサは、複数のバックエンド サービスを参照できます。必要に応じて、セキュリティ ポリシーを 1 つ以上のバックエンド サービスに関連付けることができます。
- グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサからのトラフィックを許可するように、上り（内向き）許可ファイアウォール ルールを構成します。詳細については、ファイアウォール ルールをご覧ください。
外部アプリケーション ロードバランサと IAP を備えたGoogle Cloud Armor
Identity-Aware Proxy（IAP）は、ユーザーの ID を検証し、そのユーザーにアプリケーションへのアクセスを許可するかどうかを決定します。グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサで IAP を有効にするには、ロードバランサのバックエンド サービスで有効にします。同様に、エッジ Google Cloud Armor セキュリティ ポリシーは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサのバックエンド サービスに接続されます。
Google Cloud Armor セキュリティ ポリシーと IAP の両方がバックエンド サービスで有効になっている場合、評価の順序はロードバランサの種類によって異なります。
グローバル外部アプリケーション ロードバランサのバックエンド サービスの場合、Google Cloud Armor の評価が最初に行われます。Google Cloud Armor がリクエストをブロックした場合、IAP はリクエストを評価しません。Google Cloud Armor でリクエストが許可されている場合、IAP はリクエストを評価します。IAP がリクエストを認証しなかった場合、リクエストはブロックされます。
従来のアプリケーション ロードバランサのバックエンド サービスの場合、IAP の評価が最初に行われます。IAP がリクエストを認証した場合、Google Cloud Armor はリクエストを評価します。リクエストの IAP 認証が失敗した場合、Google Cloud Armor はリクエストを評価しません。
IAP と関連する構成の詳細については、Identity-Aware Proxy のドキュメントをご覧ください。
ハイブリッド デプロイの Google Cloud Armor
ハイブリッド デプロイでは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサは、別のクラウド プロバイダのインフラストラクチャなど、Google Cloud の外部で実行されるアプリケーションまたはコンテンツ ソースにアクセスする必要があります。Google Cloud Armor を使用すると、このようなデプロイを保護できます。
次の図では、ロードバランサに 2 つのバックエンド サービスがあります。1 つは、バックエンドとしてインスタンス グループを持っています。もう 1 つのバックエンド サービスには、バックエンドとしてインターネット NEG があり、インターネット NEG は、サードパーティ プロバイダのデータセンターで実行されているアプリケーションに関連付けられています。
インターネット NEG をバックエンドとして持つバックエンド サービスに Google Cloud Armor セキュリティ ポリシーを接続すると、Google Cloud Armor は、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサに到着する、そのバックエンドサービス宛てのすべての 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 の連携に影響するセキュリティ ポリシーには、エッジ セキュリティ ポリシーとバックエンド セキュリティ ポリシーの 2 種類があります。
エッジ セキュリティ ポリシー
グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの背後にある Cloud CDN 対応バックエンド サービスと Cloud Storage バックエンド バケットには、エッジ セキュリティ ポリシーを使用できます。エッジ セキュリティ ポリシーを使用すると、コンテンツがキャッシュから提供される前にリクエストをフィルタリングできます。
バックエンド セキュリティ ポリシー
Cloud CDN が有効になっているバックエンド サービスに Google Cloud Armor バックエンド セキュリティ ポリシーを適用すると、これらのポリシーは、バックエンド サービスにルーティングされるリクエストにのみ適用されます。これには、動的コンテンツ リクエストとキャッシュミス（Cloud CDN キャッシュにないリスクストや、このキャッシュをバイパスするリクエスト）が含まれます。
エッジ セキュリティ ポリシーとバックエンド セキュリティ ポリシーが同じバックエンド サービスに接続されている場合、バックエンド セキュリティ ポリシーは、エッジ セキュリティ ポリシーを通過したキャッシュミス リクエストに対してのみ適用されます。
次の図は、エッジ セキュリティ ポリシーでリクエストが許可された後に、Cloud CDN 送信元でバックエンド セキュリティ ポリシーがどのように機能するかを示しています。
Cloud CDN の詳細については、Cloud CDN のドキュメントをご覧ください。
Cloud Run、App Engine、または Cloud Run functions での Google Cloud Armor
Google Cloud Armor セキュリティ ポリシーは、Cloud Run、App Engine、Cloud Run functions のサービスを参照するサーバーレス NEG バックエンドで使用できます。
ただし、サーバーレス NEG、Cloud Run、または Cloud Run functions とともに Google Cloud Armor を使用する場合は、サーバーレス エンドポイントに対するすべてのアクセスが Google Cloud Armor セキュリティ ポリシーによってフィルタリングされるように、特別な手順を行う必要があります。
サーバーレス アプリケーションのデフォルト URL が割り当てられているユーザーは、ロードバランサをバイパスして、サービス URL に直接アクセスできます。これにより、Google Cloud Armor セキュリティ ポリシーを回避できます。この問題に対処するには、Google Cloud が Cloud Run サービスまたは Cloud Run functions（第 2 世代）の関数に自動的に割り当てるデフォルトの URL を無効にします。App Engine アプリケーションを保護するには、上り（内向き）制御を使用します。
上り（内向き）制御を使用して、すべての受信トラフィックにアクセス制御が適用されるようにするには、Cloud Run functions または Cloud Run を構成する際に internal-and-gclb を使用します。これにより、内部トラフィックと、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサによって公開される外部 IP アドレスに送信されるトラフィックのみが許可されます。プライベート ネットワークの外部からこれらのデフォルトの URL に送信されるトラフィックはブロックされます。これにより、ユーザーは、設定されたアクセス制御（Google Cloud Armor セキュリティ ポリシーなど）を回避できなくなります。グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサで使用できます。
サーバーレス NEG の詳細については、サーバーレス ネットワーク エンドポイント グループの概要とサーバーレス NEG の設定をご覧ください。