Zenn
🧱

Google Cloud における Firewall 系サービスの違いまとめ (2023年末版)

2023/12/15に公開2件
Google Cloud
アドベントカレンダー
Cloud Armor
VPC Service Controls
Cloud Firewall
tech

こんにちは、クラウドエースの阿部です。
この記事は、Google Cloud Champion Innovators Advent Calendar 2023 の15日目です。

最近の Google Cloud って Firewall っぽいサービス多いよね

私が Google Cloud に入門したのは 2017年10月頃ですが、その頃の Google Cloud における Firewall と言えるサービスは VPC ファイアウォールルールと Cloud SQL の承認済みネットワークくらいだったと思います。
その後、 Cloud Armor や VPC Service Controls、ファイアウォールポリシーといった、Google Cloud のセキュリティをより強固にするためのサービスが年々追加されています。
一方で、利用者からすると「どのサービスを使うのがベスプラですか？」「このサービスとあのサービスの違いは何？」といった状況に陥りがちかと思います。そこで、Firewall っぽい使い方をするサービスや機能を列挙して、どういったケースで使うのかを紹介したいと思います。

以前、社内でも「VPC Service Controls と Cloud Firewall って結局何が違うんですか？」という質問を受けたことがあり、確かに似たような機能がたくさんあって初見だとわかりにくいよなと思い、本記事を書こうと思いました。

Firewall っぽいサービスの定義

とはいえ、「Firewall っぽいサービス」とは何かを定義しないと、どの範囲で書かれた記事なのかがわかりにくいと思います。
この記事では、「Firewall っぽいサービス」を以下のように定義します。

  1. 特定のエンドポイント(IPアドレスや FQDN)を防御する目的
  2. 主にレイヤ3/4の情報(IPアドレス等)を元にしたネットワーク境界のセキュリティサービス (Cloud IAM や Firebase Auth 等に代表される認証・認可系のセキュリティは対象外とする)

なお、筆者の主観に基づく分類ですので、抜け漏れ異論等はあるかと思いますが、ご容赦頂けますと幸いです。

Firewall っぽいサービスの一覧

今回紹介する Firewall っぽいサービスは以下の通りです。

  • Cloud Firewall
    • VPC ファイアウォールルール
    • 階層型ファイアウォールポリシー
    • グローバルネットワークファイアウォールポリシー
    • リージョンネットワークファイアウォールポリシー
  • Cloud Armor
  • App Engine ファイアウォールルール
  • 承認済みネットワーク
  • VPC Service Controls
  • BeyondCorp Enterprise

Cloud Firewall

Cloud Firewall は VPC ネットワーク上のリソース(GCE インスタンス等)を保護するファイアウォールサービスです。
元々 Google Cloud のファイアウォールサービスと言えば VPC ファイアウォールルールのみでしたが、現在は4種類のファイアウォールサービスが提供されています。
それらを総称して Cloud Firewall と呼んでいるようです。

VPC ファイアウォールルール

VPC ファイアウォールルールは、 Google Compute Engine (以降、GCE と表記)における VPC ネットワークの機能の1つとして提供されたサービスです。
ネットワークタグやサービスアカウントを使って、ルールとVPC ネットワーク内のリソースを関連付けを行い、送信元の IP アドレスやネットワークポートを条件に通信の許可または拒否を行います。
VPC ファイアウォールルールは、ルール1つに対して1つの VPC ネットワークのみ有効する仕様であるため、1つのプロジェクト内で複数の VPC ネットワークを使用している場合、同じようなルールであっても VPC ネットワーク毎に作成する必要があります。
例えば、全ての GCE インスタンスで SSH を使うため、 TCP22番ポートを許可したいとします。
1つのプロジェクト内で VPC ネットワークが3つあり、それぞれで同じ許可ルールを設定したい場合でも、必ず VPC ネットワーク毎に作成する必要があります。

VPC ファイアウォールルールは、後述する3つのファイアウォールポリシーと比較するとやや古いです。

階層型ファイアウォールポリシー

階層型ファイアウォールポリシーは2021年2月26日に一般提供されたファイアウォールサービスです。
VPC ファイアウォールルールとは異なり、 Google Cloud 組織やフォルダに対してファイアウォールルールを適用することが可能です。
そのため、 VPC ファイアウォールルールのときのように VPC ネットワーク毎に1つ1つルールを作成する必要はなく、組織やフォルダでまとめて適用することが可能になりました。
なお、ルール単体で作成するわけではなく、まず「階層型ファイアウォールポリシー」リソースを作成し、ポリシーリソースの中でファイアウォールルールを追加していく、という作成手順です。

この機能は、単に設定の利便性が向上するだけでなく、「送信方向の通信はデフォルト拒否する」「TCP22番ポートは会社所有の外部アドレスのみ許可する」といったセキュリティ基準を組織全体で強制することができ、企業のセキュリティを強化することが可能です。

グローバルネットワークファイアウォールポリシー

グローバルネットワークファイアウォールポリシーは、2022年8月5日に一般提供されたファイアウォールサービスです。
階層型ファイアウォールポリシーとは異なり、グローバルネットワークファイアウォールポリシーは1つの Google Cloud プロジェクトでのみ有効なファイアウォールポリシーを作成することが可能です。
グローバルネットワークファイアウォールポリシーは VPC ファイアウォールルールの欠点であった、 1つのルールは1つの VPC ネットワークでのみ使用可能という制限がなくなり、1つのポリシーを複数の VPC ネットワークに関連付けることが可能になりました。
階層型ファイアウォールポリシーをプロジェクト単位でより扱いやすくしたサービスがグローバルネットワークファイアウォールポリシーと言えます。

リージョンネットワークファイアウォールポリシー

リージョンネットワークファイアウォールポリシーは、2022年8月5日に一般提供されたファイアウォールサービスです。
時期としてはグローバルネットワークファイアウォールポリシーと同日にリリースされました。
設定対象や手順はグローバルネットワークファイアウォールポリシーとほぼ同一ですが、こちらは特定のリージョンでのみ有効にしたい場合に使用する機能です。

リージョンネットワークファイアウォールポリシーの使いどころとしては、公式のサンプルにもあるようなグローバルネットワークファイアウォールポリシーで拒否したルールに、特定リージョンのみ例外的に穴開けするようなケースになると思います。例えば、Cloud VPN や Interconnect を利用してる場合、通信量課金や経路の都合から オンプレミスネットワークからは特定リージョンからのみアクセスさせたい、といったことが考えられます。

下記は、グローバルネットワークファイアウォールポリシーとリージョンネットワークファイアウォールポリシーを組み合わせる場合の公式サンプルです。

https://cloud.google.com/firewall/docs/network-firewall-policy-examples#deny-all-external-connections-except-to-specific-ports

今はどの Cloud Firewall サービスを使えばいいの？

基本的には「階層型ファイアウォールポリシー」と「グローバルネットワークファイアウォールポリシー」を組み合わせて使用することをおすすめします。
階層型ファイアウォールポリシーを使う事で、組織全体で共通のネットワークポリシー（例えば、 SSH 通信は会社のパブリック IP アドレスからのみ許可や、 インターネットの送信方向アクセスは、TCP 80 と 443 のみを許可する、といったもの）を強制することが可能です。
グローバルファイアウォールポリシーは VPC ネットワークルールの上位互換であり、 IP アドレスやネットワークタグによる通信制御の他、 後述する Standard Tier や Premium Tier の機能も使用可能です。
ファイアウォールポリシー系のサービスを総称して「Cloud NGFW」として打ち出していることもあり、今後も新しい機能はファイアウォールポリシー系サービスで充実していくことでしょう。

Google Cloud 公式ブログでも、ファイアウォールポリシー系サービスへの移行を推奨しています。詳しくは下記をご覧ください。

https://cloud.google.com/blog/ja/products/identity-security/best-practices-for-migrating-to-network-firewall-policies

補足1: Cloud Firewall における Tier の違い

Cloud Firewall のうち、「階層型ファイアウォールポリシー」「グローバルネットワークファイアウォールポリシー」「リージョンネットワークファイアウォールポリシー」の3サービスは Tier (ティア)があり、 Standard Tier の機能が使用可能です。

  • Standard Tier
    • 位置情報オブジェクト
    • 脅威インテリジェンス
    • アドレスグループ
    • FQDN オブジェクト

さらに、「階層型ファイアウォールポリシー」「グローバルネットワークファイアウォールポリシー」の2サービスは Premium Tier の機能が使用可能です。

  • Premium Tier
    • 侵入防止サービス(IPS)
    • TLS インスペクション

上記 Standard Tier や Premium Tier の機能ついては、本記事では詳しく触れませんが、Standard Tier の FQDN オブジェクトと Premium Tier の侵入防止サービス(IPS)については、弊社エンジニアによる紹介記事がございますので、興味のある方は下記をご覧ください。

https://zenn.dev/cloud_ace/articles/cloud-firewall-fqdn-ga

https://zenn.dev/cloud_ace/articles/cloud-firewall-endpoint-about

補足2: Firewall Insights によるルールの適用状況確認

Cloud Firewall は現状4つのサービスによって設定できるため、現在運用中の GCE インスタンスにどのファイアウォールのルールが適用されているかを確認したくなることがしばしば発生します。
例えば AWS の EC2 であれば、セキュリティグループと呼ばれるファイアウォールのルールセットを直接インスタンスに設定するため、インスタンスにどのルールが設定されているかは一目でわかります。
一方で、 Cloud Firewall の場合、インスタンスに直接ルールを付与するのではなく、ネットワークタグやサービスアカウントといったインスタンスの識別子を利用して関連付けます。

GCE には、 Cloud Firewall 特有の設定状態を確認する機能があり、それが Firewall Insights です。
この機能を使うことで「VPC ファイアウォールルールの詳細から適用中のインスタンスの一覧」と「GCE インスタンスの詳細から適用中のファイアウォールのルール(VPC ファイアウォール、各ファイアウォールポリシー含む)」を確認することが可能です。残念ながら、ファイアウォールポリシー系サービスの詳細から、適用中の GCE インスタンスの一覧を参照する機能はないようです。

上記以外に、 Firewall Insights を使う事で「該当するインスタンスがないルール」や「過度に制限が緩いルール」を分析することも可能です。

この機能の詳細は下記のドキュメントをご覧ください。

https://cloud.google.com/network-intelligence-center/docs/firewall-insights/concepts/overview?hl=ja

Cloud Armor

Cloud Armor は Cloud Load Balancing のうち、グローバルアプリケーションロードバランサ(旧称: HTTP(S) ロードバランサ)に適用するファイアウォールであり、IPアドレスや位置情報に基づくルールを作成できる他、いわゆる WAF と呼ばれる Web プロトコルの攻撃から保護する機能も搭載しているサービスです。
さらに、Managed Protection Plus のサブスクリプションを購入することで、レイヤ7の高度な DDoS 攻撃に対して保護する機能を追加できる凄いやつです。

また、アプリケーションロードバランサ以外にも適用できるよう機能拡張しており、現在は以下のような機能を使うことが可能になっています。

エッジセキュリティポリシー

リリース当初の Cloud Armor は HTTP(S) 通信を行うアプリケーションロードバランサのバックエンドサービスに設定するものだったため、バックエンドバケット(Cloud Storage)や TCP/SSL ロードバランサには付与できず、一部のリソースは Cloud Armor で保護できない課題がありました。
エッジセキュリティポリシーは上記の課題を解決するものであり、以下のようなサービスにも適用できるようになりました。

  • バックエンドバケットを含むアプリケーションロードバランサ
  • 従来の外部プロキシロードバランサ (TCP, SSL)

上記のサービスを Cloud Armor で保護できるようになったことは大きく、Cloud Load Balancing のユースケースが広がったと思います。

ネットワークエッジセキュリティポリシー

さらに、ネットワークエッジセキュリティポリシーにより、以下のサービスやリソースにも Cloud Armor を付与できるようになりました。

  • 外部パススルーネットワークロードバランサ（TCP/UDP）
  • プロトコル転送
  • パブリック IP アドレスを持つ VM

Cloud Firewall との差別点として、ネットワークエッジセキュリティポリシーでは、バイトオフセット（通信内容の一部）を照合してフィルタリングすることが可能な、高度なセキュリティルールを作成することが可能です。
なお、ネットワークエッジセキュリティポリシーは、Managed Protection Plus ティアを購入し、かつ、 Allow List に登録されたユーザーのみが使用可能です。(ちなみに、自分も使ったことがないです。)

ネットワークエッジセキュリティポリシーの詳細は下記のドキュメントをご覧ください。

https://cloud.google.com/armor/docs/network-edge-policies?hl=ja

App Engine ファイアウォールルール

App Engine ファイアウォールルールは、その名の通り App Engine でのみ使用可能なファイアウォールルールです。
設定としては IP アドレスベースの許可・拒否ルールを設定するだけのシンプルなサービスになっています。
現在においては、App Engine をサーバレス NEG で Cloud Load Balancing に組み込んで Cloud Armor の高度なセキュリティポリシーを使う方がよいと思いますが、App Engine 単体で利用する場合は設定してもよいと思います。

詳しくは下記のドキュメントをご覧ください。

https://cloud.google.com/appengine/docs/standard/go/understanding-firewalls?hl=ja

承認済みネットワーク

承認済みネットワークは、一部のマネージドサービスのエンドポイントを保護する簡易的な IP アドレスベースのフィルタリングの機能です。
Google Cloud のマネージドサービスはおおむね *.googleapis.com のような Google Cloud API のエンドポイントを持っています。しかし、OSS のマネージドサービスの場合は互換性の問題からサービスのエンドポイントを *.googleapis.com で公開するわけにもいかず、後述する VPC Service Controls で保護できません。
そうしたマネージドサービスのエンドポイントは、承認済みネットワークで保護することが可能になっています。

承認済みネットワークを持つマネージドサービスは以下のとおりです。

VPC Service Controls

VPC Service Controls (以降、VPCSC と表記)は Google Cloud のマネージドサービスのリソースを包括的に保護するマネージドネットワークサービスです。
VPCSC は、 Cloud Firewall で保護できないマネージドサービス、例えば Cloud Storage や BigQuery、Cloud Spanner といったサービスのリソースをネットワーク境界(IP アドレス)等により制限することが可能です。
VPCSC は Google Cloud 独自の設計思想とも言えるサービスであり、他のクラウドだと同等のサービスはなかなかないと思います。

VPCSC の詳細については、弊社エンジニアによるブログ記事がございますので、下記ブログをご覧ください。

https://zenn.dev/cloud_ace/articles/6a26443b8e7bb4

VPC Service Controls と Cloud Firewall って結局何が違うんですか？

VPCSC と Cloud Firewall は、ネットワーク境界でリソースを保護するという大きな意味では似たような製品ですが、保護する対象が異なります。

  • Cloud Firewall が保護する対象は「VPC ネットワーク上に作成された GCE インスタンス」です。
  • VPCSC が保護する対象は「Google Cloud API で提供されている Google Cloud のリソース全般」です。

ただし、VPCSC の保護対象は「Google Cloud のリソース全般」と表現しましたが、正確には全てのプロダクト・サービスをサポートしているわけではありません。
サポートしているプロダクトについては、下記のドキュメントをご覧ください。

https://cloud.google.com/vpc-service-controls/docs/supported-products?hl=ja

また、 VPCSC は後述の BeyondCorp Enterprise (有償版)と組み合わせることで、 Google Workspace のデバイス管理の仕組みを使ったアクセス保護も可能です。Cloud Firewall ではデバイス管理と組み合わせるルールは作成できません。

https://cloud.google.com/vpc-service-controls/docs/access-level-design?hl=ja#caller-device-attributes

BeyondCorp Enterprise

BeyondCorp Enterprise は、Google が提供するゼロトラスト・ソリューションを実現することを目標としており、VPN やネットワーク境界保護(Firewall等)に依存しない安全なアプリケーションへのアクセスを提供するサービスです。
BeyondCorp Enterprise 自体は適用領域が広く、Google Cloud 上のウェブアプリケーション(App Engine や GKE 等)を保護したり、オンプレミス上に構築されたプライベートネットワークのアプリケーションまで保護することが可能です。
BeyondCorp Enterprise の概要は、公式ドキュメントの概要をご覧ください。

https://cloud.google.com/beyondcorp-enterprise/docs/overview?hl=ja

また、非常に分かりやすい解説記事を G-gen 杉村さんにより作成されておりますので、興味のある方はこちらもご覧ください。

https://blog.g-gen.co.jp/entry/beyondcorp-enterprise-explained

Google Cloud Console と Google Cloud APIs へのアクセス保護

BeyondCorp Enterprise が目指しているゼロトラストは、ネットワーク境界の保護に依存しない安全なアクセスであるため、今回の「ネットワーク境界による保護」の題材 (Firewall っぽい) サービスではないと思われたかと思います。
ただ、 BeyondCorp Enterprise の機能の中には「Google Cloud Console と Google Cloud APIs へのアクセス保護」の機能があり、アクセスレベルの設定でネットワーク境界(IP アドレス)によるアクセス制御が可能です。
VPCSC はプロジェクトの Google Cloud API サービス毎にアクセス制御が可能ですが、 BeyondCorp Enterprise の機能であれば一括で制限することが可能です。
ただし、この機能は「特定グループに所属する組織内のユーザー」にのみ有効であり、組織外のユーザーは制限できません。 VPCSC とはユースケースが異なりますのでご注意ください。

BeyondCorp Enterprise による「Google Cloud Console と Google Cloud APIs へのアクセス保護」については、下記のドキュメントをご覧ください。

https://cloud.google.com/beyondcorp-enterprise/docs/securing-console-and-apis?hl=ja

IAP と IAM Conditions によるアクセス保護

この記事では IAM のような認証・認可サービスによる保護は対象外にすると言ったのでは？と思う方もいるかも知れません。
実は BeyondCorp Enterprise の機能の1つとして、 Cloud IAM の IAM Conditions の条件式にアクセスレベルを使用することで、ネットワーク境界(IP アドレス)によるアクセス制御が可能です。
ただし、アクセスレベルによる条件式が使えるのは、 IAP の IAM ポリシーのみです。他のリソースの IAM では使用できません。

https://cloud.google.com/iam/docs/conditions-overview#example-access-level

まとめ

年末大掃除ということで（？）、 2023年12月時点での Firewall っぽいサービスを整理してみました。
これで、ネットワーク境界保護に関する質問が来ても、困らないですね。（しかし、 Google Cloud は日々進化している）
自分としては、今年の Google Cloud Next で Cloud NGFW として発表されたファイアウォールポリシー系のサービスの理解を深めて、今後の提案に生かしていきたいと思っております！
この記事が誰かのお役に立ちましたら幸いです。

Discussion

ほだぎほだぎ

この記事を拝見してPCNE合格しました。ありがとうございます。

上記以外の事例として、Resource Managerによる組織ポリシーの制限として「VPNピアIPの制限」を行うことで、指定された拠点以外のVPN接続をNGとすることもFirewallっぽい挙動をするので、ご参考いただければ幸いです。
https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints?hl=ja

クラウドエース株式会社クラウドエース株式会社

ほだぎ様

ご返信が遅くなり大変申し訳ございませんでした。
PCNE合格おめでとうございます！

参考資料についてもお教えいただき感謝するばかりでございます。