ネットワーク セキュリティの強化と、従来の VPC ファイアウォール ルールから Cloud NGFW への移行

※この投稿は米国時間 2024 年 11 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、この 18 か月でネットワーク セキュリティ サービスを大幅に強化し、Cloud Next-Generation Firewall（NGFW: 旧 Cloud Firewall Plus）をリリースしました。このような進展には、プラットフォームの機能拡張と堅牢なネットワーク保護に向けた Google の取り組みが表れています。Cloud NGFW は、侵入検知および防止システム（IDPS）、TLS インスペクション、FQDN、位置情報フィルタリングなどの高度な機能を備えており、Google のファイアウォール ポリシールールの脅威インテリジェンスと統合されています。

Cloud NGFW Enterprise の一般提供開始に伴い、Google Cloud のお客様には、従来の VPC ファイアウォール ルールから Cloud NGFW の強力で柔軟なファイアウォール ポリシーに移行されることをおすすめします。以前のブログ「VPC ファイアウォール ルールからネットワーク ファイアウォール ポリシーに移行する必要性」で説明したメリットに加えて、新しいポリシーモデルに移行することで、Cloud NGFW のスタンダード ティアとエンタープライズ ティアに含まれる強固なネットワーク セキュリティ管理も利用可能になります。

このプロセスを簡単かつスムーズに行うために、Google では、プロセスの大部分を自動化する移行ツールを開発しました。移行プロセスについて深く掘り下げ、ネットワーク セキュリティ インフラストラクチャをアップグレードする手順を確認し、Google Cloud NGFW の潜在力を最大限に活用しましょう。

ファイアウォール ポリシーへの移行: 簡単なケース

ネットワーク タグやサービス アカウントを含まない VPC ファイアウォール ルールを使用した、簡単な移行シナリオを想定してください。この簡単なユースケースを使用して、ファイアウォール ポリシーへの移行を効率化する自動移行ツールの機能について説明します。

移行プロセスでは、まず構成された VPC ファイアウォール ルールをスキャンしてから、それに対応するルールを持つ同等のファイアウォール ポリシーを生成します。元の VPC ファイアウォール ルール内で優先度が重複して存在する場合、ツールが自動的にルールの優先度を調整し、シームレスで競合のない移行を実現します。

ファイアウォール ポリシーが作成されたらよく確認し、VPC に適用してください。ルールのヒット数をモニタリングするには、ロギングが有効になっていることを確認してください。新しいポリシーを優先させるために適用順序が切り替えられ、従来の VPC ファイアウォール ルールよりもファイアウォール ポリシーのほうが優先されます。ヒット数を継続的にモニタリングすると、徐々に新しいルールに移行していることがわかります。最終的に従来のルールのヒット数はゼロになります。この時点で古いルールを無効にして、考えられる悪影響について検証できるはずです。それを終えたら、従来の古い VPC ファイアウォール ルールを削除してください。

新しいポリシーに満足したら、移行ツールを使用して、このポリシーに対応する Terraform スクリプトを生成できます。

これは重要なポイントです。このベースポリシー オブジェクトには、NGFW の高度な機能（IDPS、TLS インスペクション、地域制限、FQDN ベースのフィルタリング、アドレス グループ、Google が管理する脅威インテリジェンスの IP リストなど）を追加できます。まず、ネットワークに関連付けられているポリシー オブジェクトを直接変更して機能をテストしてください。テストが正常に完了したら、これらの新しいパラメータをベースポリシー用の Terraform スクリプトに手動で追加し、その後、本番環境の CI / CD パイプラインに組み込んでください。

ファイアウォール ポリシーへの移行: 複雑なケース

前のセクションでは、依存関係のない比較的簡単な移行シナリオについて説明しました。しかし、ほとんどの既存の環境には依存関係、つまりネットワーク タグやサービス アカウントを参照する VPC ファイアウォール ルールが含まれています。ファイアウォール ポリシーはネットワーク タグをサポートしていませんが、IAM コントロールを提供するセキュアタグはサポートしています。サービス アカウントは、ルールを適用するターゲットとしてファイアウォール ポリシーでサポートされていますが、ルールそのものを評価するために使用することはできません。従来の VPC ファイアウォール ルールでは、上り（内向き）トラフィックのソースフィルタとしてサービス アカウントを使用できます。ファイアウォール ポリシーでは、代わりにタグをソースフィルタとして使用する必要があります。

このような変更点があるため、移行を成功させるには事前の作業が必要です。まず移行プロセスを使用して、VPC ファイアウォール ルールで参照されているすべてのネットワーク タグやサービス アカウントを特定し、タグマッピング用の JSON ファイルを出力します。

JSON ファイルの出力例は以下のような形式になります。

マッピング ファイルに記述されているネットワーク タグやサービス アカウントのリストに対して、必要なセキュアタグを作成します。JSON ファイルを編集して、ネットワーク タグとサービス アカウントを対応するセキュアタグにマッピングします。

以下は、新しく作成されたタグのタグ値を使用してマッピング ファイルを更新する例です。これにより、ネットワーク タグとサービス アカウントを置き換えられます。

マッピング ファイルをすべてのセキュアタグのタグ値で手動で更新したら、移行ツールを使用してこれらのタグを関連する VM にバインドする準備が整います。このプロセスでは、タグマッピング ファイルのセキュアタグと一致するネットワーク タグやサービス アカウントを持つインスタンスに、セキュアタグをバインドします。なお、ネットワーク タグを含むマネージド インスタンス グループ（MIG）がある場合は、更新されたセキュアタグを使用するために、それらを手動で更新する必要があります。

これで、タグマッピング ファイルを移行ツールで参照し、すべてのセキュアタグがマッピングされた移行済みファイアウォール ポリシーを生成できます。簡単なユースケースのセクションで説明したように、移行の進め方には以下のとおり 2 つの選択肢があります。1 つはファイアウォール ポリシーの自動作成です。

 2 つめは、Terraform スクリプト出力です。

選択したデプロイによってファイアウォール ポリシーが作成されたら、よく確認してください。VPC ファイアウォール ルールのネットワーク タグやサービス アカウントが、対応するセキュアタグに適切に置き換えられていることを確認します。

その後、準備が整ったらVPC を関連付け、ルールのヒット数をモニタリングするためのロギングが有効になっていることを確認してください。確実に新しいポリシーを優先させるには、適用順序を切り替えて、従来の VPC ファイアウォール ルールよりもファイアウォール ポリシーを優先させてください。ヒット数を継続的にモニタリングすると、徐々に新しいルールに移行していることがわかります。最終的に従来のルールのヒット数はゼロになります。この時点で、VPC ファイアウォール ルールを無効にして考えられる悪影響を検証したら、最終的には VPC ファイアウォール ルールを削除できます。

簡単なユースケースと同様にこれは重要なポイントであり、ファイアウォール ポリシーの拡張機能を活用するとともに、IDPS、TLS インスペクション、地域制限、FQDN ベースのフィルタリング、ネットワークの脅威インテリジェンスなどの高度な機能を統合できます。

高度な移行: GKE VPC ファイアウォール ルール

ほとんどの場合、移行ツールでは既存の VPC ファイアウォール ルールが新しいファイアウォール ポリシールールに移行されますが、例外が 1 つあります。Google Kubernetes Engine によって作成された VPC ファイアウォール ルールは、スキップされます。GKE は独特で、クラスタ、Service、Ingress、ゲートウェイ、HTTPRoutes をデプロイする際に、VPC ファイアウォール ルールを自動的に作成します。

つまり、ノードプールでネットワーク タグを使用する場合は、対応するセキュアタグを使用するためにノードプールの構成を手動で更新する必要があります。

その後、依存関係のない簡単なユースケースの移行手順を続行するか、またはネットワーク タグ / サービス アカウントを使用してファイアウォール ポリシーを移行および作成する複雑なケースの手順に進んでください。

ファイアウォール ポリシーを検証した後、VPC をポリシーに関連付けます。

その後、ファイアウォール ポリシーには GKE の自動生成ルールが含まれていないため、次の 3 つの手順に沿って操作してください。

1. 既存の適用順序を維持し、ユーザー定義の VPC ファイアウォール ルールを無効にします。

2. GKE サービス IP 宛ての上り（内向き）トラフィックを許可 / 検査するためのファイアウォール ポリシールールを、手動で作成します。

3. GKE サービス（移行元: 0.0.0.0/0 移行先: ロードバランサ IP）に対する上り（内向き）VPC ファイアウォール ルールを許可する GKE 自動生成を無効にします。

除外された自動生成の GKE VPC ファイアウォール ルールには、以下の正規表現（regex）が含まれています。

gke-(.+)-ipv6-all

gke-(.+)-(.+)-((master)|(vms)|(all)|(inkubelet)|(exkubelet)|(mcsd))

k8s-fw-(l7-)?(.+)

k8s-(.+)-((node)|(http)|(node-http))-hc

(.+)-hc

k8s2-(.+)-(.+)-(.+)-(.+)(-fw)?

k8s2-(.+)-l4-shared-hc-fw

gke((gw)|(mcg))1-l7-(.+)-(.+)

GKE サービス ファイアウォール ルールを除き、すべての GKE ワークロードは、引き続き VPC ファイアウォール ルールで機能します。GKE 以外のワークロードと GKE サービス トラフィックは、ファイアウォール ポリシールールによって処理されます。

これで、VPC ファイアウォール ルールを新しいネットワーク ファイアウォール ポリシーにアップグレードする方法と、高度な NGFW 機能セットを活用する移行プロジェクトの進め方について、理解が深まったことと思います。

自動移行ツールの詳しい使用方法については、「VPC ファイアウォール ルール移行ツールのデモ」動画でご確認いただけます。ドキュメント サイトでも詳細をご覧ください。

-Google、ネットワーキング スペシャリスト カスタマー エンジニア David Tu

-Google、クラウド カスタマー エンジニアリング部門セキュリティ＆コンプライアンス スペシャリスト Nicolas Bedard