【テクニカル・上級編】 Google Cloud ArmorのDDoS保護とレイヤー7セキュリティ – クラウドインフラと仮想化ネットワーク実践ガイド

Google Cloud Armorが守る「境界」の物理学：エッジで完結するDDoS耐性とL7最適化の深淵

クラウドインフラの最前線で戦うアーキテクトにとって、ロードバランサー（LB）は単なるトラフィックの振り分け装置ではない。それは、インターネットという荒野と、我々が守るべき論理的要塞との間に立つ、極めて重要かつ孤独な「検問所」である。

今回は、Google Cloud Armor（以下、Armor）に焦点を当て、単なるWAFの機能説明を超えた、パケットレベルの防御戦略とインフラのパフォーマンス最適化について掘り下げていきたい。

1. パケットが「境界」に達する瞬間：Armorのポジショニング

多くのエンジニアは、WAFをアプリケーションの手前にある「フィルター」と捉えがちだ。しかし、Armorの真の力は、Googleの巨大なグローバルエッジネットワークの最外周、すなわち Maglev（L3/L4分散ロードバランサ）の直近で動作する点にある。

パケットが我々のVPCに到達する前、Googleのフロントエンド（GFE）に突き刺さった瞬間に、Armorのポリシーは評価される。これは重要だ。バックエンドのインスタンスやGKEのPodに攻撃パケットを到達させない。つまり、CPUサイクルやメモリを悪意あるトラフィックの解析に一切消費させないという「リソースの保全」が、ここで行われている。

2. TLSハンドシェイクとRTTの極致：Armorを通じた最適化

Armorを有効化する際、多くのエンジニアが懸念するのは「セキュリティによるレイテンシの増大」だ。しかし、適切に設計されたロードバランサーとArmorの組み合わせは、むしろ通信の効率を高める。

TCP/TLSの終端と最適化

GFEはクライアントからの SYN パケットを受け取った瞬間、Googleの最適化されたTCPスタックでハンドシェイクを行う。ここで、以下のチューニングが効いてくる。

TCP Fast Open (TFO): ハンドシェイクのRTTを削減し、2回目以降の接続を劇的に高速化する。
TLS 1.3の強制: 往復回数を減らし、暗号化のオーバーヘッドを最小化する。

これらはArmorを通した HTTP(S) Load Balancer の設定で透過的に適用される。我々が意識すべきは、バックエンドとの接続だけでなく、クライアントとGFE間の「最初の一往復」がいかにスムーズかという点だ。

3. 実践：ArmorにおけるL7攻撃緩和とレート制限

Armorの真髄は、宣言的なセキュリティポリシーにある。特定のパスやメソッドに対して、厳密なレート制限をかけることは、DDoS攻撃の初期段階における最も安価で効果的な防御だ。

以下は、gcloud コマンドでレート制限ポリシーを適用する際の例である。

# セキュリティポリシーの作成
gcloud compute security-policies create policy-ddos-protection \
    --description="高負荷APIエンドポイント保護ポリシー"

# 特定のパスに対するレート制限（1分間に100リクエストを超えたら429を返す）
gcloud compute security-policies rules create 1000 \
    --security-policy policy-ddos-protection \
    --expression "request.path.matches('/api/v1/heavy-query')" \
    --action "rate-based-ban" \
    --rate-limit-threshold-count 100 \
    --rate-limit-threshold-interval-sec 60 \
    --conform-action "allow" \
    --exceed-action "deny-429" \
    --enforce-on-key "IP" # IPアドレス単位で制限を適用

この設定において重要なのは、--exceed-action に deny-429 を指定している点だ。単に遮断するのではなく、適切に 429 Too Many Requests を返すことで、正規のクライアントに対して「再試行のインターバル（Retry-After）」を促すことが可能になる。

4. SQLiとXSSの深層防御：正規表現の罠を避ける

Armorの事前構成済みルール（Preconfigured Rules）は非常に強力だが、過剰なルール適用は、複雑なWebアプリケーションにおいて「誤検知（False Positive）」を引き起こす。

現場でのコツは、「まずは preview モードで運用し、ログを精査すること」に尽きる。

# ポリシーをプレビューモードで適用する例
gcloud compute security-policies rules update 1000 \
    --security-policy policy-ddos-protection \
    --preview # 実際にブロックせず、ログに記録するのみ

この状態で、Cloud Logging を確認し、jsonPayload.enforcedSecurityPolicy.matched.preconfiguredExprIds の中身を覗く。もし、正当なビジネスロジックが含まれるペイロードが SQLi として誤判定されているなら、特定のルールIDを除外するか、ポリシーのスコープを限定する必要がある。

5. インフラアーキテクトへの提言

ネットワークの脆弱性は、常に「設定の隙間」から忍び込む。Armorを導入する際は、以下の3点を意識してほしい。

1. ヘッダー圧縮とHTTP/2の活用: GFEはHTTP/2をネイティブにサポートしている。ヘッダーの肥大化によるレイテンシを防ぐため、可能な限りクライアントにはHTTP/2以上の通信を促す。
2. CDNとの統合: Armorは Cloud CDN とシームレスに統合される。キャッシュヒット率を高めることで、バックエンドへのリクエスト数そのものを減らすことが、最高のDDoS対策となる。
3. 継続的な監視: Cloud Monitoring で loadbalancing.googleapis.com/https/request_count と loadbalancing.googleapis.com/https/backend_latencies を監視し、Armor適用前後での変化を定点観測する。

Armorは単なる「盾」ではない。それは、エッジでパケットの正当性を判断し、無駄なトラフィックを物理的に排除することで、アプリケーションの「心臓部」であるサーバーを極限まで保護する、動的な防御インフラだ。

ネットワークプロトコルの美しさと、それを守り抜くための泥臭いチューニング。この両輪が揃って初めて、真に堅牢なクラウドアーキテクチャが完成する。さあ、皆さんのVPCにも強固な防壁を築こうではないか。