GCPファイアウォール戦略の深淵：ターゲットタグか、サービスアカウントか
クラウドネイティブなネットワーク設計において、VPCファイアウォールルールは「最後にして最強の砦」だ。しかし、多くのエンジニアが最初の数行で陥る罠がある。それが「ネットワークタグ（ターゲットタグ）」と「サービスアカウント」のどちらを採用すべきかという問いだ。
公式ドキュメントには「サービスアカウントの方が安全」と一行で書かれているが、現場のSREとしては、その背後にある制御プレーンの挙動やパケットフィルタリングのレイテンシ、そして運用における「生存バイアス」まで考慮しなければならない。
今日は、単なる使い分けの話を超え、この選択がなぜTCPスタックやセキュリティ監査の質、ひいてはプロダクション環境の信頼性に直結するのかを紐解いていこう。
—
1. ターゲットタグの功罪：高速だが「疎結合」すぎるID
ネットワークタグは、GCPの初期から存在する極めて軽量な識別子だ。これはVMのメタデータに文字列として付与され、GCPのSDN（Software Defined Network）のコントロールプレーンがファイアウォールルールを各ホストのiptablesやnftablesルールへ展開する際、単純な文字列マッチングとして扱われる。
なぜターゲットタグは「危うい」のか
タグはIAMの権限とは完全に独立している。つまり、compute.instances.setTags権限を持つユーザーであれば、誰でも任意のVMに特定のタグを付与し、ファイアウォールの穴を意図的に開けることができてしまう。
- 運用リスク: インフラエンジニアが意図しないうちに、開発者がデバッグ目的で本番用VMにタグを付与し、セグメント制限をバイパスしてしまう事故は後を絶たない。
- スケーラビリティの限界: タグはVMインスタンスにしか紐付かない。GKEノードや、将来的に導入するServerless VPC Accessなど、サービスアカウントが主役となる現代のコンポーネントとの親和性が極めて低いのだ。
—
2. サービスアカウント：IAMという名の「鉄壁の認証レイヤー」
サービスアカウント（SA）によるフィルタリングは、単なるIDの付与ではない。これは、VMのアイデンティティとネットワークアクセス制御を「IAMのガバナンス」という鎖で結びつける行為だ。
パケットフィルタリングの内部挙動
SAベースのルールは、インスタンスが起動する際、GCPのメタデータサーバーを通じて発行されるIDトークンと密接に連携する。ファイアウォールの評価時、GCPのSDNはVMに割り当てられたSAの署名情報を検証した上で、許可リストへ組み込む。
この仕組みの最大の利点は、「誰がそのインスタンスを操作できるか」と「そのインスタンスがどこに通信できるか」を同じガバナンスモデルで制御できる点にある。
# ターゲットタグではなく、サービスアカウントを指定するファイアウォールルールの作成例
gcloud compute firewall-rules create allow-db-access \
--direction=INGRESS \
--priority=1000 \
--network=production-vpc \
--action=ALLOW \
--rules=tcp:5432 \
--source-service-accounts=app-server@project-id.iam.gserviceaccount.com \
--target-service-accounts=db-server@project-id.iam.gserviceaccount.com
# この設定により、app-serverからのみdb-serverへの接続が許可される—
3. パフォーマンスとトランスポート層の最適化
ここで少し視点を変えよう。ファイアウォールルールの定義方法自体は、パケットの伝送速度（スループット）に直接影響を与えない。GCPのAndromeda SDNは、ハードウェアオフロードによって物理NICレベルでフィルタリングを処理しているからだ。
しかし、RTT（Round Trip Time）や接続の安定性を追求するなら、トランスポート層のチューニングが必須となる。
TCPバッファチューニングの重要性
特にリージョンを跨ぐ通信や、Cloud CDNを介したトラフィックでは、カーネルのTCPウィンドウサイズがボトルネックになることが多い。sysctlを通じて以下のパラメータを調整することで、長距離通信時のスループットは劇的に改善する。
# /etc/sysctl.conf への追記例
# 高速なネットワーク環境向けに受信ウィンドウを拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# BBR混雑制御アルゴリズムの有効化（パケットロス時のスループット低下を抑制）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrTLSハンドシェイクの最適化
サービス間でHTTPS通信を行う場合、TLS 1.3の「0-RTT」機能の活用を検討すべきだ。これにより、コネクション再接続時のハンドシェイクを1往復分省略できる。ただし、リプレイ攻撃のリスクがあるため、アプリケーション側で멱等性（Idempotency）を担保した設計が前提となることは忘れてはならない。
—
4. 結論：迷ったらSAを選べ、ただし「タグ」の役割も理解せよ
結論として、現代のGCPネットワークアーキテクチャにおいては、原則としてサービスアカウントを用いた制御をデフォルトにするべきだ。
- タグ（ネットワークタグ）: 一時的なワークロード、あるいはVPCネットワークの全域に適用するような「広域的なトポロジー管理」にはまだ出番がある。
- サービスアカウント: 本番環境のマイクロサービス間通信、機密データへのアクセス制御など、「アイデンティティに基づいた境界線」が必要な箇所では、迷わずこれを選択する。
ネットワーク設計とは、単なるルーティングテーブルの作成ではない。それは、組織の権限管理と、パケットという名の物理的なデータの流れを、高い次元で同期させる作業だ。
もしあなたが今、レガシーなタグ運用に苦しんでいるのなら、少しずつでも「IDベースのセキュリティ」へ移行することを強く推奨する。それは、将来のセキュリティインシデントに対する最も効果的な「保険」となるはずだ。
コメント