Cloud Next Generation Firewall (NGFW)

解決する課題

VPC 内外のトラフィックを、IP・ポートだけでなく組織的なポリシーや脅威シグナルに基づいて制御したい、という要件を満たします。

• 多数のプロジェクト・VPC にまたがる共通のセキュリティ方針を、一貫して適用したい
• IP レンジに依存せず、タグやサービスアカウントでワークロード単位に許可・拒否を表現したい
• 単純な L3/L4 の許可だけでなく、侵入防御（IPS）やドメイン・地域フィルタで既知の脅威を遮断したい
• 暗号化トラフィックも含め、証明書を端末に配らずに TLS 検査を行いたい
• ファイアウォールの評価順序と例外を、階層構造で見通しよく管理したい

主要概念と用語

• ネットワークファイアウォールポリシー: 複数のルールをまとめ、VPC ネットワークに関連付ける器。グローバル版とリージョナル版があり、従来の VPC ファイアウォールルールに代わる推奨形態
• 階層型ファイアウォールポリシー: 組織やフォルダのレベルで定義し、配下のプロジェクトへ継承させるポリシー。全社共通のガードレールを上位で強制できる
• ファイアウォールエンドポイント: 侵入防御や TLS 検査などのレイヤー 7 検査を実行するゾーン単位のリソース。組織に作成し、対象 VPC に関連付けて使う
• セキュアタグ（IAM 統制タグ）: リソースに付与してファイアウォールの対象を指定するためのタグ。IAM で付与権限を制御でき、IP やネットワークタグより安全に対象を絞れる
• 侵入防御サービス（IPS）: 既知の攻撃シグネチャに基づき、悪意ある通信を検知・遮断する機能。Cloud NGFW Enterprise ティアで提供
• ルールの方向と評価: ルールには ingress（受信）／egress（送信） の方向があり、優先度（数値が小さいほど先）と上位ポリシーからの順で評価される。明示ルールに合致しなければ既定の動作が適用される

仕様・制限・クォータ

• ティア構成。基本的な L3/L4 制御を行う Essentials と、ファイアウォールエンドポイントによる IPS・TLS 検査・ドメイン/地域フィルタを加える Enterprise に分かれる
• ポリシーのスコープ。階層型は組織・フォルダ、ネットワークポリシーはグローバルまたはリージョン、と適用範囲が異なる。グローバルポリシーはネットワーク全体、リージョナルポリシーは特定リージョンに効く
• 対象の指定は IP レンジに加え、セキュアタグ・サービスアカウント・ネットワークタグで表現できる。IP に依存しない指定が推奨される
• レイヤー 7 検査（IPS や TLS 検査）にはファイアウォールエンドポイントが必要で、これはゾーン単位のリソースを組織に作成して VPC に関連付ける
• ルール数・ポリシー数・エンドポイントのスループットなどには上限があり、具体的な数値は変動するため設計時に公式ドキュメントで最新値を確認する
• TLS 検査には**信頼構成（CA プール）**の準備が要る。検査の対象外にしたい通信は除外リストで指定する

内部の仕組み

Cloud NGFW は VPC に分散的に組み込まれたステートフルなファイアウォールで、専用のチョークポイント機器に全トラフィックを集約する構成ではありません。L3/L4 のフィルタリングは基盤側で各 VM の近くで評価され、レイヤー 7 検査が必要な場合のみファイアウォールエンドポイントへ経路が向けられます。

• ルールは階層型 → グローバル/リージョナルのネットワークポリシー → 既定の順で評価され、上位で許可・拒否が確定すれば下位は参照されない（goto_next で次の層へ委譲する指定もある）
• ステートフルなため、許可された接続の戻りパケットは自動的に通る。明示的な戻りルールは不要
• IPS や TLS 検査では、対象トラフィックがゾーン内のファイアウォールエンドポイントに誘導され、シグネチャ照合や復号・検査が行われる
• セキュアタグは IAM で管理されるため、誰がどのワークロードにどのタグを付けられるかを権限として統制できる

設計パターン / ベストプラクティス

• 全社共通の禁止事項（特定ポートの遮断、既知の悪性レンジの拒否など）は階層型ポリシーで上位に集約し、プロジェクト側で緩められないガードレールにする
• ワークロード固有の許可はネットワークファイアウォールポリシーで表現し、対象はセキュアタグ／サービスアカウントで指定して IP 依存を避ける
• egress を既定で絞り、必要な宛先だけをドメインフィルタや地域フィルタで許可して、データ持ち出し経路を限定する
• 既知の攻撃や C2 通信の遮断が要件なら Enterprise ティアの IPS を有効化し、対象 VPC にファイアウォールエンドポイントを関連付ける
• ルールはまずロギングだけ有効にして観測し、影響範囲を確認してから拒否へ切り替える段階的な適用にする

運用・監視

• ファイアウォールルールロギングを有効化し、どのルールがどの接続を許可・拒否したかを Cloud Logging で確認する。トラブルシュートと棚卸しの基礎になる
• **接続テスト（Network Intelligence Center の Connectivity Tests）**で、特定の送信元・宛先がポリシー上通るかを実機トラフィックなしに検証する
• IPS を使う場合は**検知イベント（脅威ログ）**を監視し、誤検知やブロック状況を継続的に評価する
• ルールの優先度と階層の評価順を意識し、上位ポリシーで意図せず遮断・許可していないかを定期的に点検する
• ロギングは情報量が多くなりやすいため、対象ルールを絞ってログ量とコストのバランスを取る

コスト

課金は「ポリシー/ルールの利用」と、Enterprise 機能の「ファイアウォールエンドポイントの稼働・処理量」が中心です。ロギングの保管・分析コストも考慮します。

セキュリティ

• タグと IAM の統合により、誰がどのワークロードを許可対象にできるかを権限として統制でき、設定ミスや権限逸脱を抑えられる
• 階層型ポリシーで上位の禁止事項を強制し、プロジェクト管理者が共通ガードレールを回避できない構造にする
• IPS により既知の攻撃シグネチャを検知・遮断し、L3/L4 の許可だけでは防げない脅威に対処する
• TLS 検査で暗号化トラフィック内の脅威も検査できる。端末に証明書を配らずに復号できる点が運用上の利点
• egress 制御を既定で絞り、ドメイン・地域フィルタで宛先を限定してデータ持ち出し経路を狭める

関連サービス・比較

L3/L4 の基本制御は **VPC（VPC ファイアウォールルール）**と地続きで、Cloud NGFW はその発展形として階層化とレイヤー 7 検査を加える位置づけです。クラウド横断では AWS の Network Firewall が近い役割を担います。

ハンズオン / CLI例

# グローバルなネットワークファイアウォールポリシーを作成
gcloud compute network-firewall-policies create my-policy \
  --global \
  --description="共通の受信制御ポリシー"

# セキュアタグを対象にした受信許可ルールを追加（HTTPS のみ許可）
gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=my-policy \
  --global-firewall-policy \
  --direction=INGRESS \
  --action=allow \
  --layer4-configs=tcp:443 \
  --target-secure-tags=tagValues/123456789 \
  --enable-logging

# ポリシーを VPC ネットワークに関連付ける
gcloud compute network-firewall-policies associations create \
  --firewall-policy=my-policy \
  --global-firewall-policy \
  --network=my-vpc \
  --name=my-policy-assoc

# ルールの内容を確認
gcloud compute network-firewall-policies describe my-policy \
  --global