G-gen の杉村です。当記事では Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) においてアクセス制御のために利用する Cloud Firewall について徹底解説します。

概要

Cloud Firewall とは

Cloud Firewall とは、Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) に備え付きのファイアウォール機能です。

Cloud Firewall は一般的なファイアウォールアプライアンスのイメージとは異なり、フルマネージドの分散システムで構成されているので、インフラの管理を考える必要がありません。ユーザは Google Cloud コンソールや gcloud コマンドラインでルールを追加するだけで、VPC 内の通信に対してアクセス制御をかけることができます。

なお他クラウドサービスと並べると、Amazon Web Services (AWS) のセキュリティグループや AWS Network Firewall、Microsoft Azure のネットワークセキュリティグループに相当する機能です。

参考 : Cloud Firewall overview

2つの設定スコープ・3つの料金ティア

Cloud Firewall の設定スコープには、単一 VPC に対して設定するための VPC ファイアウォールルール と、複数プロジェクト・複数 VPC に対する設定を統合管理可能な ファイアウォールポリシー の2種類があります。

また、それぞれに料金ティアとして Essentials、Standard、Plus の3ティア（ティア = 階層）があります。Essentials のみ無償で、後者は一部通信に対して有償 (データ処理量に応じた従量課金) です。

Essentials は IP アドレスやプロトコルとポート番号などの L3/L4 レベルの制御のみを提供し、Standard は FQDN ベースの制御や地理情報に基づいた制御など、高度なルールが利用可能です。Plus は不審なトラフィックを検知してブロックする IPS (Intrusion Prevention Service) 機能を提供します。

「VPC ファイアウォールルール」では Essentials ティアの機能しか使えず、「ファイアウォールポリシー」では Essentials ティアと Standard ティアの両方の機能が使えます。また Plus ティアはこのいずれでもなく、VPC に作成されたファイアウォール・エンドポイントを介して提供されるため、さらに別軸です。

Cloud Firewall の設定方法とルール機能を整理すると、以下の表のようになります。

設定スコープ	適用範囲	利用可能なティア
VPC ファイアウォールルール	単一 VPC	Essentials ティア (L3/L4 レベル制御。無償)
ファイアウォールポリシー	単一 VPC または複数プロジェクト・複数 VPC	Essentials・Standard ティア (FQDN オブジェクト等の高度な制御)
VPC 内に作成するファイアウォール・エンドポイント	単一 VPC (ゾーン単位)	Plus ティア (IPS 機能)

この関係性は、以下の図のように表現できます。

料金

料金ティア

Essentials ティアのルールは無償であり、Standard ティアのルールは有償です。

Standard ルールを使用したファイアウォールポリシーがインターネットと VM 間で発生したトラフィックを評価すると、GB 数に応じて料金が発生します。課金対象は以下のトラフィックです。

インターネットから VM への通信
VM からインターネットへの通信

反対に、以下のトラフィックは課金対象になりません。

インターネットと VM 間の通信のうち、プロキシ型の Cloud Load Balancing で中継される通信
Google Cloud 内に閉じる通信

Plus ティアも有償です。エンドポイントを作成後、存在した時間に応じての課金と、処理したトラフィックの GB 数に応じて課金されます。ただし2023年11月現在では Plus 機能は Preview 中のため、無料となっています。

参考 : Cloud Firewall pricing

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

利用するポリシーのスコープによっても、料金の有無が異なります。

VPC ファイアウォールルールは無料です。一方のファイアウォールポリシーはさらに「階層型」「グローバル」「リージョン」の3種類に分けられますが、そのうち「階層型ファイアウォールポリシー」のみが有償です。

階層型ファイアウォールポリシーでは、ポリシーが適用される VM の数に応じて課金が発生します。対象 VM が500台以下の場合は VM 1台あたり $1 が、501台以上の場合は VM 1台あたり $1.5 が課金されます (2023年6月現在)。

参考 : Cloud Firewall pricing - Hierarchical firewall policies and rules

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

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

VPC ファイアウォールルール は VPC を通過するトラフィックに対し「接続元・接続先・プロトコル・ポート番号」による通信制御を提供します。いわゆる L3/L4 レイヤのトラフィック制御を行うファイアウォールです。

パケットの評価は ステートフルインスペクション 形式です。これは、通信の行きと戻りをファイアウォールが紐づけて評価することを意味しています。

例えば「自社オフィスの固定 IP アドレス "xx.xx.xx.xx" から VM (A) に対する SSH ログインの通信を許可したい」場合は、ファイアウォールルールとして「方向は Ingress (上り) 」「接続元は "xx.xx.xx.xx" 」「ターゲットは VM (A) 」「プロトコルは TCP 、ポート番号は 22 」「アクションは "許可" 」を一つだけ作ればいいのです。 TCP 通信は必ず "行き" と "戻り" がありますが、ステートフルインスペクションのファイアウォールは行きのパケットと戻りのパケットを自動的に紐づけて評価してくれるので、戻りのパケットを許可するルールを作る必要がありません。

参考 : VPC firewall rules

ルールの仕様

ルールテーブル

VPC ファイアウォールルールでは VPC ごとに一つのファイアウォールルールのテーブルを持ちます。

ルールテーブルは例えば以下のようになります。

ルール名	タイプ	ターゲット	フィルタ	プロトコル:ポート	アクション	優先度
allow-icmp	Ingress	全インスタンス	IP ranges: 0.0.0.0/0	icmp	Allow	1000
allow-rdp-from-myoffice	Ingress	全インスタンス	IP ranges: a.b.c.0/24	tcp:3389, udp:3389	Allow	1010
allow-ssh-from-partneroffice	Ingress	全インスタンス	IP ranges: x.y.z.0/23	tcp:22	Allow	1020
deny-internet-from-prod	Egress	tags: prod	IP ranges: 0.0.0.0/0	全プロトコル	Deny	500

上り (Ingress) と下り (Egress)

ルールには上り (Ingress) と下り (Egress) の タイプ があります。 VM 側を上 (Internal) と見て、そこから外に出ていく通信を下り (Egress) と呼び、その逆を上り (Ingress) と呼びます。

ターゲット

ターゲット はルールが適用される VM です。「IP アドレス帯」「ネットワークタグ」「サービスアカウント」などの方法でルールの対象とする VM を限定できます。この条件に当てはまる VM のトラフィックだけにルールが適用されます。

少々分かりづらいのですが、パケットの観点だと、上り (Ingress) ルールではターゲットは 接続先 であり、下り (Egress) ルールでは 接続元 を指すことになります。

フィルタ

フィルタ はルール適用対象のパケットをフィルタする設定です。これも分かりづらいですが、パケットの観点だと、上り (Ingress) ルールではフィルタは 接続元 であり、下り (Egress) ルールでは 接続先 を意味します。ターゲットの反対と理解すればよいでしょう。

ターゲットやフィルタに VPC 上の VM インスタンスを指定する際は、 IP アドレス帯 (CIDR 形式) での指定のほか VM の ネットワークタグ や サービスアカウント で指定することができます。

プロトコル・ポート

プロトコル・ポート は読んで字のごとくです。「 TCP: 443」「 UDP:53 」「 ICMP 」のように指定ができます。

アクション

ルールには許可 (Allow) または拒否 (Deny) の アクション があります。パケットがルールに合致するとこのアクションが適用されます。

優先度

各ルールには 優先度 があります。 0 から 65535 の整数で指定し、より小さい数字が先に評価されます。パケットがいずれかのルールに合致して Allow または Deny されるとそれ以降の優先度のルールは無視されます。

暗黙のルール

重要な留意点として、明示的にファイアウォールルールを作成していなくても必ず適用され、ルールを一覧表示しても表示されない 暗黙のルール が存在します。それは、以下の 2 つです。

暗黙の下り (Egress) 許可
暗黙の上り (Ingress) 拒否

1. は方向が 下り (Egress) 、宛先が 0.0.0.0/0 、優先度が 65535 、アクションが allow のルールです。つまり、どのファイアウォールルールにも合致しなかった下り (Egress) パケットは 自動的に許可 されます。これは、例えば VM からインターネット上のソフトウェアレポジトリへ通信するパケットなどが自動的に許可されることを意味しています。これを防ぎたい場合は、明示的に拒否ルールを追加する必要があります。

2. は方向が 上り (Ingress) 、送信元が 0.0.0.0/0 、優先度が 65535 、アクションが deny のルールです。つまり、どのファイアウォールルールにも合致しなかった上り (Ingress) パケットは 自動的に拒否 されます。これは、インターネット上からいかなる VM へのパケットも拒否することを意味しています。つまり、デフォルトでは VM への HTTPS 通信や SSH 通信も到達しません。明示的に許可ルールを追加することでこれを許可します。

対象 VM の指定方法

前述のように、接続元/接続先 VM を指定する際には「IP アドレス帯」「ネットワークタグ」「サービスアカウント」が選択可能と記載しました。

ネットワークタグ は VM に設定可能なタグです。文字列として指定可能で、一つの VM に複数のネットワークタグを設定することができます。

例として AP サーバーに app というネットワークタグを指定し、 DB サーバーに db というタグを指定したうえで、以下のようなルールを作成することで AP ・ DB 間の通信を許可することができます。

ルール名	タイプ	ターゲット	フィルタ	プロトコル:ポート	アクション	優先度
allow-ap-db-access	Ingress	network tag: `db`	network tag: `app`	tcp: 5432	Allow	1000

サービスアカウント は VM にアタッチ可能な IAM リソースです。本来 VM 内で動作するプログラムからの認証・認可に利用されますが、ファイアウォールでも利用可能です。

サービスアカウント vs ネットワークタグ

VM の指定には前述のように「ネットワークタグ」と「サービスアカウント」のいずれかが利用できますが、より厳密にアクセス制御を行う際はサービスアカウントを利用したほうがよいとされています。

VM にアタッチするネットワークタグは、VM 固有の設定であるため、Compute Engine 管理者等のロールを持っている管理者であれば自由に変更可能です。一方でサービスアカウントは Compute Engine VM とは独立したリソースであり、VM にサービスアカウントをアタッチするには当該サービスアカウントに対する「サービスアカウントユーザー」ロール等が必要です。

VM とサービスアカウントの権限体系が別個であるため、VM 管理者とネットワーク管理者の権限分離をするためには、ファイアウォールルールでもサービスアカウントを制御方法として採用したほうが、より強固な権限分離が可能であると言えます。

参考 : Filter by service account versus network tag

ファイアウォールポリシー

ファイアウォールポリシーとは

ファイアウォールポリシー (Firewall policies) は複数のルールをまとめて管理するための仕組みです。

階層型ファイアウォールポリシー、グローバルネットワークファイアウォールポリシー、リージョンネットワークファイアウォールポリシーの3つが存在します。

名称	所属リソース	説明
階層型ファイアウォールポリシー	組織またはフォルダ	組織 / フォルダにアタッチすることで配下の複数 VPC に適用できる。3 種類のポリシーのうち唯一有償 (後述)
グローバルネットワークファイアウォールポリシー	プロジェクト	VPC にアタッチすることでその VPC の全リージョンに適用できる
リージョンネットワークファイアウォールポリシー	プロジェクト	VPC にアタッチすることでその VPC の特定のリージョンに適用できる

またファイアウォールポリシーでは、Cloud Firewall Essentials に加えて Cloud Firewall Standard の機能が利用可能です。Cloud Firewall Standard では FQDN 制御オブジェクトなど、より高度な通信制御を利用することができます。

3つのいずれも、複数の VPC に適用することができますが、複数プロジェクトに適用できるのは「階層型ファイアウォールポリシー」のみです。残りの2つは、ポリシーが所属するプロジェクト内の VPC にのみアタッチ可能です。

参考 : Firewall policies

ルールの仕様

基本的な考え方

各種ファイアウォールポリシーは複数のルールをグループするための入れ物であり、中に制御ルールを追加することができます。

ルール評価はステートフルインスペクションである点や、ターゲット・フィルタ・上り・下りの考え方などは、ほとんど VPC ファイアウォールルールと同一です。

ただし、次の項に記載するような相違点には注意が必要です。

VPC ファイアウォールルールとの相違点

VPC ファイアウォールルールとファイアウォールポリシーの基本的な相違点は、以下のとおりです。

比較点	VPC ファイアウォールルール	ファイアウォールポリシー
性質	VPC ごとに個別にルールテーブルを持つ	ルールのコンテナ (入れ物) であり複数 VPC に再利用可能
更新時の挙動	ルールごと (1行ごと) に更新	ポリシー内のルールは (トランザクション的に) まとめて更新可能
適用方法	ルールテーブルにルールを追加すると即時適用	VPC に明示的にアタッチして初めて効果を発揮
Ingress ルールにおけるソース指定方法	IP アドレス / ネットワークタグ / サービスアカウント	IP アドレス / セキュアタグ

ファイアウォールポリシーでは Ingress ルールにおいてソースをサービスアカウントで指定できないため、セキュアタグを用いた制御が重要になってきます。

参考 : Global network firewall policy rule details

セキュアタグ

ファイアウォールポリシーでは、ルール上で対象ノードを特定するためにセキュアタグが用いられます。VPC ファイアウォールで用いられたネットワークタグとは別物であることに注意が必要です。

ネットワークタグはファイアウォールポリシーでは使用不可ですし、逆に VPC ファイアウォールではセキュアタグは使用不可であることに留意してください。

ネットワークタグとセキュアタグの違いは以下のとおりです。

比較点	セキュアタグ	ネットワークタグ
リソース性質	組織リソースまたはプロジェクトリソース	プロジェクトリソース
フォーマット	キー・バリュー	単一文字列
タグ自体のアクセス制御	IAM で制御可能	制御不可
適用方法	ルールテーブルにルールを追加すると即時適用	VPC に明示的にアタッチして初めて効果を発揮
対応する Firewall	グローバル/リージョンファイアウォールポリシーで利用可能 (階層型では利用不可)	VPC ファイアウォールルールでのみ利用可能

参考 : Tags for firewalls

3種類のファイアウォールポリシー

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

階層型ファイアウォールポリシー (Hierarchical firewall policies) は 「組織」ノードもしくは「フォルダ」ノードにアタッチするポリシーです。階層型ポリシーは、アタッチしたノード配下の全てのプロジェクトに制御が適用されます。

参考として、以下は Google Cloud の組織・フォルダ・プロジェクト構成の図です。 Google Cloud ではリソースは階層構造になっています。

Google Cloud の利用規模が大きくなり、複数のプロジェクトの複数の VPC に対して個別にファイアウォールルールを管理すると、その工数は膨大になってしまいます。

階層型ファイアウォールポリシーを組織 (最上位ノード) やフォルダにアタッチすることで 配下に存在する全 VPC に対して統一したルールを適用できる ことがこの機能の利用価値となります。

参考 : Hierarchical firewall policies

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

グローバルネットワークファイアウォールポリシー (Global network firewall policies) は、単一プロジェクト内の複数リージョンの VPC に対してアクセス制御をかけられるポリシーです。

グローバルネットワークファイアウォールポリシーを使う場面としては、以下のようなことが上げられるでしょう。

プロジェクト内の複数の VPC に対して同じファイアウォールルール群を適用したい
それらのルールを少ない手間・少ないミスで管理したい

なお、一つの VPC は一つのグローバルネットワークファイアウォールポリシーとしか紐づけができません。

参考 : Global network firewall policies

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

リージョンネットワークファイアウォールポリシー (Regional network firewall policies) はグローバルネットワークファイアウォールポリシーとほとんど同じ特徴を持っています。

違いは「ポリシー自体がリージョン単位のリソースであること」「適用対象が単一リージョン内 VM のみに限定されること」です。

ユースケースもグローバルネットワークファイアウォールポリシーと同様です。

参考 : Regional network firewall policies

ルールの評価順

ここまでで「VPC ファイアウォールルール」「ファイアウォールポリシー (階層型 / グローバル / リージョン)」が登場しました。

これらが併用されているとき、所定の優先順位に従ってルールが評価されていきます。

まず階層型ファイアウォールポリシーが上位のノード (組織・フォルダ) から下位のノードに向けて順番に評価されていきます。

ファイアウォールポリシーでは 許可 、 拒否 に加えて goto_next というアクションが存在します。 goto_next アクションは、許可/拒否を決めずに次の評価順のファイアウォールに評価を委ねるアクションです。またどのルールにも合致しなかったパケットも goto_next として扱われます。

階層型ファイアウォールでどのルールにも合致しなかった場合、VPC ファイアウォールルールが評価されます (VPC ファイアウォールでは明示的な goto_next アクションは使えません)。

VPC ファイアウォールでもどのルールにも当てはまらなかった場合、グローバルファイアウォールポリシー、リージョンファイアウォールポリシーの順で評価されていきます。

それでもどのルールにもあてはまらない場合、最終的には暗黙のルール (入ってくる通信は全て Deny、出ていく通信は全て Allow) が適用されます。

なお、VPC の networkFirewallPolicyEnforcementOrder という値を BEFORE_CLASSIC_FIREWALL に設定すると、VPC ファイアウォールの評価順を「グローバルファイアウォールポリシー、リージョンファイアウォールポリシーの後」に変更することが可能です。

参考 : Policy and rule evaluation order

Cloud Firewall Essentials / Standard / Plus

Cloud Firewall Essentials

Cloud Firewall Essentials は無償の機能ティアであり、原則的に L3/L4 レベルのみのアクセス制御を提供します。機能は以下のとおりです。

プロトコル・ポート番号による制御
IP アドレスによる制御 (アドレスグループ機能含む)
サービスアカウントによる制御
ネットワークタグによる制御
セキュアタグによる制御

すなわち、当記事でここまで説明してきたようなアクセス制御は Essentials のみで実装可能です。

比較例として、Amazon Web Services (AWS) の VPC におけるセキュリティグループ機能のような、最低限のネットワークアクセス制御は Essentials 機能でカバーすることが可能です。

参考 : Cloud Firewall Essentials

Cloud Firewall Standard

Cloud Firewall Standard は有償の機能ティアであり、高度な制御ルールを提供します。機能は以下のとおりです。

機能名	概要
脅威インテリジェンス (Threat Intelligence)	Google の持つ脅威情報に基づいたアクセス制御
FQDN オブジェクト	パケットの IP アドレスから名前解決して得られた FQDN (ドメイン名) に基づいたアクセス制御
Geo-location objects	パケットの IP アドレスからマッピングした地理情報に基づいたアクセス制御