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

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

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 セキュリティ ポリシーと上り（内向き）ファイアウォールを使用してアクセスを制限する（クリックして拡大）

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

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

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 のセキュリティ ポリシーはバイパスされます。この問題に対処するには、 Cloud de Confiance 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 でレート制限を構成するをご覧ください。

次のステップ