Google Cloud の VPC ファイアウォールを安全に運用するには、「暗黙の拒否を前提に必要な通信だけを許可する」「対象はネットワークタグよりサービスアカウントで指定する」「SSH/RDP は IAP 経由にしてインターネットに開かない」「ルールのログと分析機能で使われていない許可を洗い出す」「変更はコード（IaC）で管理する」の5点が軸になります。この記事では、Compute Engine 上で WordPress などを動かすプロジェクトを想定し、評価の仕組みから日常の見直しまでを説明します。
評価の仕組みを押さえる
VPC ファイアウォールルールは VPC ネットワーク単位で定義し、そのネットワーク内の VM（正確にはネットワークインターフェース）に適用されます。ステートフルなので、許可した通信の戻りのパケットは別途許可する必要がありません。
ルールには 0〜65535 の優先度があり、数値が小さいほど優先 されます。作成時に指定しなければ 1000 になります。同じ優先度で許可と拒否が両方一致した場合は拒否が優先されます。
すべての VPC ネットワークには、表示されない「暗黙のルール」が最も低い優先度（65535）で存在します。
- 上り（ingress）はすべて拒否
- 下り（egress）はすべて許可
自動作成される default ネットワークには、これに加えて default-allow-internal、default-allow-ssh、default-allow-rdp、default-allow-icmp といった広い許可ルールがあらかじめ入っています。特に SSH と RDP のルールは送信元が 0.0.0.0/0 なので、本番では default ネットワークを使わずカスタムモードの VPC を作るか、少なくともこれらのルールを削除・制限することが第一歩です。
ファイアウォールポリシーとの関係
組織やフォルダ単位で一括適用する 階層型ファイアウォールポリシー、ネットワーク単位の グローバル／リージョンのネットワークファイアウォールポリシー を使っている場合、評価はおおむね「階層型ポリシー（組織 → フォルダ）→ VPC ファイアウォールルールとネットワークファイアウォールポリシー → 暗黙のルール」の順に進みます。VPC ルールとネットワークポリシーのどちらを先に評価するかはネットワークの設定で変えられます。ポリシーでは、判断を下位に委ねる「次へ進む（goto_next）」動作も使えるため、組織側で「例外なく止めたい通信」だけを拒否し、残りはプロジェクトに任せる、という分担ができます（2026年10月現在）。機能名や提供範囲は Cloud NGFW の階層によって異なるため、公式ドキュメントで確認してください。
ターゲットはサービスアカウントで指定する
ルールの適用先（ターゲット）は「ネットワーク内のすべてのインスタンス」「ネットワークタグ」「サービスアカウント」から選べます。
ネットワークタグは手軽ですが、インスタンスを編集できる権限を持つ人なら誰でもタグを付け外しできます。たとえば allow-db というタグが付いた VM にだけデータベースへの接続を許可していても、別の担当者が任意の VM にそのタグを付けると、その VM からも接続できてしまいます。
サービスアカウントでターゲットや送信元を指定すると、VM にそのサービスアカウントを割り当てる操作に IAM の権限（サービスアカウントの利用権限）が必要になるため、意図しない適用が起きにくくなります。役割ごとに専用のサービスアカウントを作り、それをファイアウォールの単位にするのが推奨される設計です。ネットワークファイアウォールポリシーでは、IAM で管理できる セキュアタグ（Resource Manager のタグ）も使えます。
# Webサーバー用サービスアカウントを持つVMにだけHTTPSを許可する例
gcloud compute firewall-rules create allow-https-web \
--network=prod-vpc --direction=INGRESS --action=ALLOW \
--rules=tcp:443 --source-ranges=0.0.0.0/0 \
--target-service-accounts=web-sa@PROJECT_ID.iam.gserviceaccount.com \
--priority=1000 --enable-loggingロードバランサーの背後に VM を置く場合は、0.0.0.0/0 ではなくロードバランサーとヘルスチェックの送信元範囲（多くのロードバランサーでは 130.211.0.0/22 と 35.191.0.0/16）からだけ許可します。ロードバランサーの種類によって範囲が異なるため、使っている種類のドキュメントで確認してください。
SSH/RDP は IAP 経由にする
管理用の SSH（22番）や RDP（3389番）をインターネットに開くと、常に総当たりの試行を受けることになります。Identity-Aware Proxy（IAP）の TCP 転送を使うと、外部 IP を持たない VM にも、IAM で許可された利用者だけが接続できます。ファイアウォール側では、IAP の送信元範囲 35.235.240.0/20 からの接続だけを許可します。
gcloud compute firewall-rules create allow-iap-ssh \
--network=prod-vpc --direction=INGRESS --action=ALLOW \
--rules=tcp:22 --source-ranges=35.235.240.0/20 \
--target-service-accounts=web-sa@PROJECT_ID.iam.gserviceaccount.com \
--enable-logging
# 接続（利用者側）
gcloud compute ssh web-1 --zone=asia-northeast1-b --tunnel-through-iapIAP 経由の接続が使えることを確かめてから、0.0.0.0/0 からの SSH 許可ルールを削除します。順番を逆にすると、自分で管理接続を失うことがあります。万一の場合に備え、シリアルコンソールへの接続方法と、その利用権限を持つ担当者を事前に決めておきます。
下り（egress）も必要に応じて絞る
暗黙のルールで下りはすべて許可されているため、侵害された VM から外部へデータを送られる経路が残ります。重要なサーバーでは、低い優先度（例: 65000）で下りをすべて拒否し、それより高い優先度で必要な宛先だけを許可する構成が考えられます。ただし、OS の更新、Google API への接続（限定公開の Google アクセスなど）、外部 API、メール送信など必要な通信の洗い出しが欠かせません。まず下りのログを有効にして実際の通信を観察し、ステージング環境で試してから本番に適用します。
ログと分析で「使われていない許可」を見つける
ファイアウォールルールのログはルール単位で有効にでき、Cloud Logging に一致した接続の記録が残ります。ログ量に応じて費用が発生するため、すべてのルールで常時有効にするより、拒否ルールと重要な許可ルールを優先し、メタデータを含めるかどうかも用途に合わせて選びます。
Network Intelligence Center の Firewall Insights を使うと、一定期間ヒットしていないルール、上位のルールに隠れて効かないシャドウルール、必要以上に広い許可などを確認できます。また 接続テスト（Connectivity Tests） では、送信元と宛先を指定して、どのルールで許可・拒否されるかを実際の通信なしに調べられます。ルールを変更する前後に接続テストを実行しておくと、意図しない遮断を事前に見つけられます。
# 優先度順に一覧化して棚卸しする
gcloud compute firewall-rules list --filter="network:prod-vpc" --sort-by=priority
# 用途不明のルールは削除前に無効化して様子を見る
gcloud compute firewall-rules update legacy-allow-8080 --disabled変更はコードで管理する
コンソールでの手作業は、誰がいつ何を変えたかが分かりにくくなります。Terraform の google_compute_firewall リソースなどでルールをコード化し、レビューを経て適用する運用にすると、変更履歴が残り、元に戻すのも容易です。手作業での変更が混ざると差分が生まれるため、コンソールでの変更を IAM で制限するか、定期的に差分を確認します。監査ログ（Cloud Audit Logs）の管理アクティビティログでも、ファイアウォールの作成・変更・削除の記録を確認できます。
定期点検のチェックリスト
0.0.0.0/0を送信元とする許可ルールが、公開が必要なポートだけになっているか- default ネットワークや初期ルールが本番に残っていないか
- ターゲットがネットワークタグのままの重要なルールがないか
- Firewall Insights で未使用・シャドウと判定されたルールを確認したか
- IaC の定義と実際の設定に差分がないか
まとめ
- 優先度は数値が小さいほど優先され、最下位に「上りは拒否・下りは許可」の暗黙ルールがある
- default ネットワークの広い許可ルールは本番で使わない
- ターゲットはネットワークタグよりサービスアカウント（またはセキュアタグ）で指定する
- SSH/RDP は IAP（
35.235.240.0/20）経由にし、確認後に公開ルールを削除する - ログ、Firewall Insights、接続テストで不要な許可と意図しない遮断を見つける
- ルールは Terraform などでコード管理し、変更はステージングで試してから適用する