VPC Firewall Rulesの特徴と利用時の注意点
はじめに
Google Cloudのようなクラウドサービスを利用する場合であっても、オンプレ環境と同様にネットワークのセキュリティを、利用するユーザー側で確保する必要があります。Google Cloudではネットワークセキュリティを確保するために様々なサービスを利用することが出来ますが、本稿ではその中でも使用頻度が高いと思われる、VPC Firewall Rulesの特徴と利用時の注意点について解説します。
VPC Firewall Rulesとは
VPC Firewall Rulesは、Virtual Private Cloud (VPC)内の仮想マシンインスタンスに対して適用する事が可能なFirewallサービスです。許可または拒否ルールを作成することが出来ます。各ルールには優先度を設定することが出来、該当するルールが複数存在する場合は、最も優先度の高い(最も小さな値の優先度)ルールで通信が許可または拒否されます。
VPC Firewall Rulesの特徴
VPC Firewall Rulesには様々な特徴があります。
暗黙のルール
すべてのVPCには、2つの暗黙のルールがあります。一つは全ての外向き通信許可ルールで、もう一つは全ての内向き通信拒否ルールです。これらの暗黙のルールには最も低い優先度が割り当てられているため、独自のVPC Firewall Rulesを作成することで上書きすることが出来ますが、暗黙のルールそのものを削除することはできません。
これらの暗黙のルールはコンソール上に表示されることがないため、注意が必要です。見落としの防止や、可視性の向上を求められる場合は、同一の設定でVPC Firewall Rulesを作成することが有用である可能性があります。これにより、各仮想マシンに対して適用されているVPC Firewall Rulesの全てをコンソールから確認することが出来ます。
ステートフル
VPC Firewall RulesはステートフルのFirewallです。これにより、いずれかの方向で接続が一度許可されると、戻りの通信も許可されます。このステートフルや戻り通信という単語に聞きなじみがないと勘違いしてしまうことがあるかもしれませんが、戻りの通信が許可されるというだけで、逆向きの通信が許可されるという意味ではありません。
例)仮想マシンAから仮想マシンBに対する通信のみが許可されている場合
戻り通信:許可
逆向き通信:拒否
分散ファイアウォール
VPC Firewall Rulesは、分散ファイアウォールとして機能します。作成時にVPCを指定するため勘違いしてしまうこともあるかもしれませんが、ルールが適用されるのは仮想マシン単位です。ある仮想マシンから別の仮想マシンに通信する必要がある場合は、それぞれの仮想マシンに対して別々に、外向きの通信許可と内向きの通信許可を設定する必要があります。これは、サブネット内であっても同様です。
例)仮想マシンAから仮想マシンBに対して通信をしたい場合
その他にも様々な特徴がありますので、詳細は公式ドキュメント※1をご参照ください。
脚注)※1 Google Cloud, VPC ファイアウォール ルール | Cloud NGFW | Google Cloud, (参照2025年8月21日)
その他Tips
続いて、VPC Firewall Rulesの活用に向けたTipsをいくつか紹介いたします。
Logs
VPC Firewall Rulesでは、ルール単位でログのオンオフを設定することが可能です。オンにすると、ルールにマッチした通信が発生すると、ログが出力されます。(デフォルトでは_Defaultという名前のログバケットに出力されます)
ログの保管に費用が発生することにはなりますが、有効化することでいくつかのメリットを得ることが可能です。
①トラブルシューティング
出力されるログには主に、「通信元IP、通信元ポート番号、通信先IP、通信先ポート番号、VPC Firewall Rules名」が含まれます。そのため、疎通に問題があった場合や、不正な通信があった場合に、ログから確認することが出来ます。ただし、デフォルトでは30日しかログが保存されないため、より過去に遡って確認が必要となる可能性がある場合は事前に保存期間を変更するようにしてください。
②不要なルールの発見
Logsをオンにすることで、Hit countという機能を利用することが出来るようになります。これを利用することで、過去6週間に各ルールが適用された通信の数を特定することが出来るようになります。このHit countは、VPC Firewall Rulesの一覧画面から確認することが可能です。
Hit countが0の場合、過去6週間の間にそのような通信が発生していない(もしくは他のルールでカバーされている)ということになります。これが許可ルールの場合、不必要なルール、もしくは既に不要となったルールを放置してしまっている可能性があります。
Connectivity Tests
VPC Firewall Rulesを作成した後、正しく設定できているか確認したいことがあると思います。その際に、Connectivity Testsを利用することが可能です。Connectivity Testsでは、通信元と通信先を設定することで、通信経路や適用されるVPC Firewall Rulesを確認することが出来ます。VPC Firewall Rulesが正しく設定できていないと、Unreachableといったような結果が表示されます。
ただし、ここでReachableという結果を得られたとしても、確実に意図した通信が保証されるわけではない点にご留意ください。Connectivity TestsはGoogle Cloud内の構成から到達性を確認するサービスであるため、オンプレなどGoogle Cloud外の構成までは確認することができず、また、通信先で実際にそのポート番号でサービスが起動しているかを確認することもできません。あくまで、Google Cloud内において構成に問題がないかを確認するサービスとしてご利用ください。詳細は公式ドキュメント※2をご参照ください。
ヘルスチェック
仮想マシンをバックエンドに持つLoad Balancerを作成する場合、ヘルスチェックを作成する必要があります。このヘルスチェックが成功することでLoad Balancerはパケットをバックエンドへ転送することが出来るのですが、この通信を許可するためのVPC Firewall Rulesを作成する必要があります。
Google CloudではヘルスチェックはLoad Balancerからではなく、Google Cloudプローバーと呼ばれるところから行われます。このプローバーのIPアドレスはLoad Balancerのタイプにより異なりますが、同一のタイプであれば一律同じIPレンジです。詳細は、公式ドキュメントをご参照ください。※3
Firewall policies
VPC Firewall Rulesは通常VPCごとに作成されるため、複数のプロジェクト内でVPCが作成されていたり、同一プロジェクトの中に複数のVPCが作成されていたりすると、ルールの管理が複雑になることがあります。
このFirewall policiesは、複数のルールをグループ化し、複数のプロジェクトやVPCに一括適用することが可能です。たとえば、複数のVPCで利用するルール(RDPやSSHを使ったリモートアクセス、管理サーバとの通信に必要なルールなど)は、このポリシーを利用して全体に適用し、特定のVPCのみで必要なルールは個別に適用するようにすることで、ルールの管理の効率化を図ることが出来ます。詳細は、公式ドキュメントをご参照ください。※4
脚注)※2 Google Cloud, 接続テストの概要 | Connectivity Tests | Google Cloud, (参照2025年8月21日)
脚注)※3 Google Cloud, ヘルスチェックの概要 | Load Balancing | Google Cloud, (参照2025年8月21日)
脚注)※4 Google Cloud, ファイアウォール ポリシー | Cloud NGFW | Google Cloud, (参照2025年8月21日)
まとめ
VPC Firewall Rulesを利用することできめ細やかな通信制御を行うことが出来ます。Google Cloud固有の特徴によりいくつか注意すべき点はありますが、適切に利用することで、ネットワークセキュリティを高めることが出来ます。
執筆者
原田 貴之
デロイト トーマツ コンサルティング合同会社 シニアスペシャリスト
日系SIer企業を経て現職。Google Cloudの中では、特にインフラ領域を得意としている。Google Cloudの資格全13種を保有。
Discussion