Google Cloud Armor：ロードバランサーの「門番」を極めるための実戦的ガイド
クラウドのインフラを設計・運用していると、深夜の急なアラート通知ほど心臓に悪いものはありません。特に「負荷が急上昇し、バックエンドのAPIが応答不能になった」という報告を受けた時、我々SREはまず「これが正当なトラフィックか、それとも攻撃か」という判断を瞬時に迫られます。
そんな時、Google Cloudのインフラで我々を救ってくれるのが Google Cloud Armor です。単なる「WAF」と呼ぶにはあまりに強力な、ロードバランサー（GCLB）と完全統合された防御レイヤーについて、現場の視点から紐解いていきましょう。
—
1. なぜCloud Armorは「強い」のか？
多くの人が誤解しているのですが、Cloud Armorは「境界」で戦うだけの存在ではありません。Googleのグローバルネットワーク網、つまりバックボーンの最先端で、エッジにあるロードバランサー（GCLB）の直前でパケットを裁く「超高速なフィルタリングエンジン」です。
L3/L4からL7までの多層防御
- L3/L4防御: Googleの巨大なエッジネットワークが持つキャパシティを活かし、ネットワーク層でのDDoS攻撃をインフラ側で吸収します。
- L7防御: Cloud ArmorのセキュリティポリシーがHTTP(S)ヘッダーやURIパスを解析し、SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）を阻止します。
重要なのは、これが GCLBのホップ内で行われる という点です。バックエンドのサーバーにパケットが届く前に捨てられるため、アプリケーションリソースを攻撃者に一切消費させない——これが最大の強みです。
—
2. セキュリティポリシーの設計と実装
Cloud Armorの核となるのは Security Policy です。これはルール（Rule）の優先順位（Priority）に従って評価されるリストです。
CLIによるルール追加の例
例えば、特定の悪意あるIPレンジからの攻撃を遮断し、かつ特定のパスへのSQLiをブロックするルールは、以下のように設定します。
# 1. セキュリティポリシーを作成
gcloud compute security-policies create my-web-policy \
--description "Web API保護用のポリシー"
# 2. SQLiを検知・拒否するルールを追加（優先度1000）
gcloud compute security-policies rules create 1000 \
--security-policy my-web-policy \
--expression "evaluatePreconfiguredExpr('sqli-stable')" \
--action "deny-403" \
--description "SQLインジェクションをブロック"
# 3. 特定の攻撃的IPを即座に遮断（優先度100）
gcloud compute security-policies rules create 100 \
--security-policy my-web-policy \
--src-ip-ranges "192.0.2.0/24" \
--action "deny-403" \
--description "ブラックリストIPの遮断"—
3. 実践：Web APIを防御する際のTips
Web APIを公開する際、全てのトラフィックを盲目的に許可するのは自殺行為です。開発者が意識すべきは、Cloud Armor の Preview モードの活用です。
開発・検証時の鉄則：まずは「監視」から
いきなり deny アクションを設定すると、正当なユーザーのアクセスまで遮断するリスクがあります。まずは preview オプションを使い、ログを確認します。
# プレビューモードでルールを適用（遮断はせずログのみ出力）
gcloud compute security-policies rules update 1000 \
--security-policy my-web-policy \
--previewPythonで防御をテストする
攻撃者がよく用いるSQLiの文字列（' OR '1'='1）を投げて、Cloud Armorがどう反応するか、requests ライブラリで試してみましょう。
import requests
# 対象のAPIエンドポイント
url = "https://api.example.com/v1/search"
params = {"query": "' OR '1'='1"}
# Cloud Armorが有効な場合、SQLiを検知すれば 403 Forbidden が返る
response = requests.get(url, params=params)
if response.status_code == 403:
print("成功: Cloud ArmorがSQLiをブロックしました！")
else:
print(f"警告: ステータスコード {response.status_code} - ブロックされていません")—
4. トラブルシューティングの極意：ログを読め
運用中、最も重要なのは「なぜこの通信がブロックされたのか？」を即座に特定することです。GCPの Cloud Logging で以下のフィルタをかけるのが現場の定石です。
jsonPayload.enforcedSecurityPolicy.name="my-web-policy"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"このログには、どのルール (ruleId) に抵触したのか、どの preconfiguredExpr が反応したのかが詳細に記録されます。もし「誤検知（False Positive）」が発生した場合は、そのルールを優先度の低い「許可（Allow）」ルールでバイパスするか、ルールの感度を調整してください。
—
まとめ：SREの視点から
Google Cloud Armorは「設定して終わり」の魔法の杖ではありません。攻撃者の手法は日々進化します。
1. ベースラインの策定: まずは標準的な sqli-stable や xss-stable を適用する。
2. レートリミットの活用: APIの /login や /search エンドポイントには、必ずレートリミットをかけ、ブルートフォース攻撃を未然に防ぐ。
3. 継続的な振り返り: 週に一度はログを確認し、不審なIPパターンや異常なリクエストがないか眺める。
ネットワークは生き物です。Cloud Armorという優秀な門番を正しく設定し、アプリケーションそのもののビジネスロジックに集中できる環境を整えていきましょう。それが、我々エンジニアに求められる真のクラウド運用力です。
コメント