GCP階層型ファイアウォールポリシー：境界防御の「聖域」を組織レベルで統治する
クラウドネイティブな環境において、個々のプロジェクト単位でファイアウォールを管理する時代は終わった。数百のプロジェクトが乱立するエンタープライズ環境で、各開発チームにネットワークセキュリティの責任を委ねれば、高確率で「Shadow IT」ならぬ「Shadow Firewall Rules」が発生する。
私たちが直面するのは、数百のプロジェクトを横断して一貫したセキュリティガードレールをどう敷くかという課題だ。ここで真価を発揮するのが、GCPの階層型ファイアウォールポリシー（Hierarchical Firewall Policies）である。
なぜ「階層」が必要なのか：パケットの運命を決める継承ルール
従来のVPCファイアウォールルールは、いわば「個別の門番」だ。しかし、階層型ポリシーは「組織の憲法」に近い。
このポリシーは、組織（Organization）、フォルダ（Folder）というGCPの階層構造の頂点から定義できる。重要なのは、これらが「継承」されるという点だ。パケットがVMのNICに到達する遥か手前、GoogleのSDN（Software Defined Network）の境界で、以下の順序で評価が下される。
1. 組織レベルポリシー（最上位）
2. フォルダレベルポリシー
3. VPCレベルポリシー（個別のルール）
パケットがイングレス（Ingress）する場合、最も優先度が高いポリシーが先に評価され、allow か deny が確定した時点で評価は終了（Short-circuit）する。つまり、階層の頂点で「SSHのグローバル解放は絶対禁止」と定義すれば、下位のプロジェクトでどれだけ甘い設定をしようが、パケットは容赦なく破棄される。
パフォーマンスとセキュリティの極致：データプレーンでの「断罪」
この階層型ポリシーの真骨頂は、VMのカーネルスタックまでパケットを到達させないことにある。
ネットワークプロトコルの視点で見れば、TCPのSYNパケットが到達した瞬間、あるいはそれ以前の段階で、Googleの分散ファイアウォールアーキテクチャがヘッダーを検査する。ここでdenyされれば、RTT（Round Trip Time）を浪費することなく接続は切断される。
特に、攻撃者によるスキャンやDDoSの初期段階において、このレベルでのフィルタリングは、アプリケーションのTCPバッファを消費させないという点で、極めて効率的な防衛線となる。
階層型ファイアウォールポリシーの構築：実践的アプローチ
まずは、組織レベルでポリシーを作成し、特定のフォルダに紐付ける手順を見ていこう。
# 1. 組織レベルの階層型ファイアウォールポリシーを作成
gcloud compute network-firewall-policies create "global-security-policy" \
--global \
--description="全組織横断の強固なセキュリティポリシー"
# 2. 優先度1000で、特定の管理IPからのトラフィックのみを許可するルールを追加
gcloud compute network-firewall-policies rules create 1000 \
--firewall-policy="global-security-policy" \
--action=allow \
--direction=INGRESS \
--src-ip-ranges="10.0.0.0/8" \
--layer=GLOBAL \
--description="内部管理セグメントからの通信許可"
# 3. 作成したポリシーを特定のフォルダに紐付け（アソシエーション）
gcloud compute network-firewall-policies associations create \
--firewall-policy="global-security-policy" \
--attachment-target="folders/1234567890" \
--name="apply-to-prod-folder"インフラアーキテクトが意識すべき「最適化の罠」
セキュリティを固める一方で、パフォーマンスを犠牲にしてはならない。以下の点には特に注意が必要だ。
- ルール順序の最適化: 評価順序は「優先度（Priority）」で決定される。頻繁にマッチするルール（許可ルール）を上位に持ってくることで、論理演算の回数を最小化できる。
- TLSハンドシェイクとRTT: 階層型ポリシーによるフィルタリングは、TLSハンドシェイクの
ClientHelloを待たずに接続を断つ。これは、不正なIPからのリソース枯渇攻撃を防ぐ上で非常に重要だが、誤って正規のトラフィックをdenyしないよう、ログ（enable-logging）を有効にして、パケットのドロップ理由を詳細に分析する癖をつけてほしい。 - TCPバッファへの影響: もし、ポリシーの評価が複雑になりすぎて、エッジでの処理遅延が発生すれば、それはそのまま接続確立までのレイテンシとして現れる。階層構造は深くしすぎず、3階層程度に留めるのがアーキテクチャ上のセオリーだ。
結論：境界なき時代の「ガードレール」
クラウドのネットワークセキュリティは、もはや「境界の内側」を守るだけの古いファイアウォールではない。Googleの強力なインフラをバックボーンに、組織全体で統一されたルールを、データプレーンの最上流で適用する。これが現代のSREが追求すべき「疎結合かつ堅牢なセキュリティ」の姿だ。
階層型ファイアウォールポリシーは、単なる管理ツールではない。それは、クラウドという巨大な荒野において、貴方のインフラを守るための「憲法」そのものなのだ。設計に迷ったときは、常に「最もシンプルな階層構造で、最も深いレイヤーでパケットを止めるにはどうすべきか」を自問してほしい。
コメント