GCPファイアウォール戦略の深淵：タグか、サービスアカウントか、あるいはその先へ
GCPのVPCファイアウォール設計において、単に「なんとなく」ターゲット指定を行っていないだろうか。ネットワークエンジニアやSREにとって、ファイアウォールルールは単なるセキュリティ境界ではなく、パケットの到達性を制御する最もプリミティブなスイッチである。
今回は、GCPにおける「ターゲットタグ」「サービスタグ（ターゲットサービスアカウント）」「ターゲットネットワーク」という3つの指定方式を軸に、現場で遭遇する複雑なトラフィック制御とパフォーマンスの最適化について掘り下げていこう。
1. ターゲット指定の「構造的」違いを理解する
まず、我々がパケットを制御する際、GCPが裏側で何を行っているかを解像度高く理解する必要がある。
ターゲットタグ (Network Tags)
古くから存在するこの方式は、インスタンスのメタデータに文字列を付与するものだ。非常に軽量で直感的だが、管理上の最大の弱点は「誰でも編集できる」ことにある。IAM権限を厳密に絞っていない環境では、攻撃者がインスタンスに侵入し、メタデータを書き換えてファイアウォールのガードレールを突破するリスクがある。
ターゲットサービスアカウント (Service Accounts)
現在、エンタープライズ環境で推奨されるのがこれだ。IAMベースで制御されるため、インスタンスに付与されたサービスアカウントを他人が勝手に変更することはできない。セキュリティコンプライアンスの観点から、ネットワーク設計は「タグ」から「アイデンティティ」へ移行すべきである。
# サービスアカウント指定でのファイアウォール作成例
gcloud compute firewall-rules create allow-http-to-frontend \
--direction=INGRESS \
--priority=1000 \
--network=production-vpc \
--action=ALLOW \
--rules=tcp:443 \
--target-service-accounts=frontend-sa@my-project.iam.gserviceaccount.com \
--source-ranges=0.0.0.0/0
# この設定により、該当SAを持つインスタンスのみが443ポートを解放する2. パケットとカーネル：RTT削減のためのネットワークチューニング
ファイアウォールのルールセットが数千行を超えると、GCPの分散ルーター（Andromeda）へのオフロード処理にも限界が見え始める。パフォーマンスを極限まで引き出すには、ネットワーク層の挙動を意識したチューニングが不可欠だ。
TCPウィンドウサイズの最適化
レイテンシが高い環境下では、デフォルトのTCPウィンドウサイズではスループットが頭打ちになる。Linuxカーネルレベルで以下のチューニングを適用することで、帯域幅遅延積（BDP）を最大限に活用できる。
# sysctlでのバッファ拡張（永続化には /etc/sysctl.conf へ）
# 10Gbps以上の高帯域通信を想定したバッファ確保
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216TLSハンドシェイクの最適化
GCPの Cloud CDN を活用する場合、TLS 1.3 の採用は必須である。TLS 1.3 はハンドシェイクの往復回数が1回に削減されるため、RTT（ラウンドトリップタイム）が支配的なモバイルネットワーク環境では、体感速度に劇的な改善をもたらす。
3. ヘッダー圧縮とセキュリティのトレードオフ
現代のWebアーキテクチャでは、HTTP/2 や HTTP/3 (QUIC) における HPACK/QPACK によるヘッダー圧縮が標準だ。しかし、ここで注意が必要なのが「CRIME攻撃」や「BREACH攻撃」のような、圧縮されたストリームを悪用したサイドチャネル攻撃である。
高セキュリティが求められるAPIエンドポイントでは、機密性の高いトークンやクッキーをヘッダーに含める際、以下のような緩和策を講じることが重要だ。
- ヘッダーのランダム化: セッションIDにパディングを追加し、圧縮効率を意図的に落とす。
- VPCサービスコントロール: ネットワーク境界を厳格化し、データ流出を物理的なネットワークレベルで遮断する。
4. アーキテクトへの提言：静的ルールから動的ポリシーへ
これからのクラウドインフラは、ファイアウォールのルールを「静的に管理する」時代を終えるべきだ。GCPが提供する Hierarchical Firewall Policies を活用し、組織単位で継承可能なルールを定義しよう。
実践的なアーキテクチャ設計の指針
1. 最小特権の原則: 0.0.0.0/0 を指定するルールは、例外なく IAP（Identity-Aware Proxy）や Cloud Armor の背後に隠蔽する。
2. 監視の自動化: ファイアウォールの変更ログを Cloud Logging で収集し、BigQuery でクエリを投げて「意図しない変更」を秒単位で検知するパイプラインを構築すること。
3. パケットの可視化: VPC Flow Logs を活用し、サンプリングレートを調整しながら、不審なパケットの挙動を追跡し続ける。
ネットワークは生き物である。設定が完了した瞬間が、次のトラブルの始まりであるという緊張感を持ち続けよう。タグやサービスアカウントは単なる識別子に過ぎない。その裏側で何万というパケットがどのような TCP シーケンスを刻んでいるか、常にカーネルとパケットの視点を持つことが、真のSREへの第一歩である。
コメント