🛡 Deep Dive — Cloud Armor / Cloud NGFW / Secure Web Proxy 運用

セキュリティは「効きすぎ」と「効かなさすぎ」の両方が事故になる。本物の SRE/SecOps が踏むパターンを集約。

🚨 重大事故ケース 10 件

#1 「Cloud Armor の Adaptive Protection が誤検知で本物 traffic を block」

状況: EC サイトでセール開始時に Adaptive Protection が「DDoS 検知」を発動、suggested rule を auto-enforce する設定でユーザを大量 block。

原因: Adaptive Protection は training data 期間中の baseline を異常と判定。セール開始の急増を異常と判断。

影響: 1 時間で売上 3000 万円損失。

復旧: auto-enforce を disable、suggested rule を preview に変更。

再発防止:

Adaptive Protection は suggested rule の human reviewを挟む
セール/イベント期間は事前に traffic spike を Adaptive Protection に学習させる (manual baseline)
ビジネスチームと SRE で「予測可能イベント」のカレンダー共有

#2 「Cloud NGFW Enterprise の TLS inspection で証明書エラー」

状況: Cloud NGFW Enterprise の L7 inspection を有効化。一部の OAuth ID プロバイダ向け HTTPS 通信で TLS handshake failure。

原因: Cloud NGFW Enterprise の TLS inspection は 中間 CA で再暗号化するため、Certificate Pinning 実装のクライアントで失敗。

影響: 認証 fail で全ユーザログイン不可。

復旧: 該当 destination (OAuth プロバイダ FQDN) を TLS inspection から除外 (exclude rule)。

再発防止:

TLS inspection 対象は 事前に互換性検証 (mobile app, certificate pinning, 自社製 SDK)
中間 CA 証明書を全クライアントに配布
金融/医療系 SaaS は inspection 例外リスト管理

#3 「Hierarchical firewall policy が org level で deny、配下で override 不可」

状況: Org 管理者が「外部 IP からの SSH (22) deny」を hierarchical で設定。GKE 一部 Pod の internal SSH も巻き添えで block (誤って ingress 0.0.0.0/0 deny を作っていた)。

原因: Hierarchical policy は 配下プロジェクトで override 不可 (goto_next を設定しない限り)。

影響: GKE ノードへの IAP SSH も deny、debug 不能で復旧遅延。

復旧: Hierarchical policy に IAP source range (35.235.240.0/20) の allow rule を追加。

再発防止:

Hierarchical 設定前に 影響範囲を Connectivity Tests でシミュレーション
"goto_next" を活用し、配下に裁量を残す層を作る
IAP/HC source range は常に allow リストに

#4 「Secure Web Proxy の URL filter で社内 SaaS 不到達」 — FQDN 漏れ

状況: SWP に *.googleapis.com, github.com を allow list 化。後で Notion (notion.so) や Datadog (datadoghq.com) からのアクセスが切れて業務停止。

原因: SWP は default deny。事前に 業務で使う FQDN を網羅していなかった。

影響: 30 人の開発チームが半日業務停止。

復旧: 漏れた FQDN を即追加、SWP の policy 再 deploy。

再発防止:

SWP 採用前は 2-4 週間の monitor mode で実 traffic を観察
Allowed FQDN list は IT/Compliance チームと協議
新規業務ツール追加時に SWP 更新を プロセスに組込む

#5 「Cloud Armor rate limit が同一 NAT IP に集中、企業ユーザを block」

状況: Cloud Armor で 1 IP あたり 100 req/min rate limit。大企業の corporate NAT 経由ユーザは全社で 1 IP に集約されており、すぐ block。

原因: Rate limit の enforcement key を IP のみにしたため、CGNAT/corporate NAT 越しのユーザが巻き添え。

影響: 大手顧客から「サービス使えない」と苦情。

復旧: rate limit の key を HTTP_HEADER (X-API-Key, X-User-Id) や ALL + cookie に変更。

再発防止:

Rate limit は authentication identifier ベース を第一選択
IP-based は anonymous endpoint のみに限定
"throttled requests" メトリクスを企業顧客視点で観察

#6 「VPC Service Controls が dry-run のまま放置」 — Enforce 漏れ

状況: VPC-SC を 3 ヶ月前に dry-run mode で導入、本番 enforce を忘れていた。実際は外部 IAM principal が BigQuery を leak しており、SOC2 監査で指摘。

原因: dry-run は violation を log するだけで 実際の block はしない。enforce 切替が必要。

影響: Compliance 違反、データ exfiltration の可能性 (実害は調査の結果ゼロ)。

復旧: dry-run logs を分析、false positive がないことを確認し enforce mode 切替。

再発防止:

dry-run mode の 導入時に enforce 移行期日を設定 (デッドライン化)
dry-run の violation logs を定期 review
Security Command Center で VPC-SC mode を monitoring

#7 「Cloud Armor の preview rule が enforce と矛盾」 — Rule priority の混乱

状況: 既存 enforce rule (priority 1000) と新 preview rule (priority 500) が同じ traffic を異なる方法で扱う。preview rule が先に評価され、enforce が効かない traffic 発生。

原因: Cloud Armor は priority 順 (小さい順) で評価。preview rule でも先に match すれば log + 通過、後段 enforce は無視される。

影響: WAF 守れていない traffic が運用中、SOC 検出。

復旧: preview rule の priority を enforce より大きく (e.g., 1500)。

再発防止:

Cloud Armor rule priority は 区分ごとに rangeを確保 (例: enforce 1000-1999, preview 2000-2999, exception 100-199)
新 rule 追加時の priority allocation を IaC で強制

#8 「Cloud NGFW Standard の FQDN object が DNS 変化に追随せず block」

状況: NGFW Standard で api.example.com を allow。Example 社が CDN を変更し A record の IP が変わったが、NGFW の FQDN object キャッシュが古い IP のままで通信不可。

原因: FQDN object は DNS TTL に従ってキャッシュ更新される。TTL が長い (1 day) と切替遅延。

影響: 外部 API 呼出が断続的に失敗、SLA 違反。

復旧: NGFW policy を一旦削除→再作成 (cache flush)。

再発防止:

FQDN object に依存する外部 API は TTL の短い DNS を確認
Mission-critical な外部 API は IP/CIDR allow と FQDN allow を併用
外部 API 失敗時の Runbook に "FQDN cache flush" を含める

#9 「Cloud Armor reCAPTCHA Enterprise の token validation 失敗」 — bot management の事故

状況: Cloud Armor + reCAPTCHA Enterprise で bot management 構築。本物ユーザに challenge が出て体験悪化、離脱率 +20%。

原因: reCAPTCHA の risk score 閾値が厳しく (0.7 で challenge)、Safari ITP や VPN 利用ユーザが疑われた。

影響: UX 悪化でコンバージョン低下。

復旧: 閾値を 0.3 に緩和、score 0.3-0.5 は "monitor" のみ。

再発防止:

reCAPTCHA score 閾値は A/B test で調整
離脱率 / コンバージョンを SLI に追加
score 分布を可視化、外れ値分析

#10 「Cloud NAT IP が SaaS 側で IP block」 — Reputation の事故

状況: Cloud NAT の自動 IP を使用。ある日 SaaS 側 (Sendgrid 等) が「Reputation 低 IP」として block。

原因: Cloud NAT 自動 IP は他 GCP ユーザと共有プール。誰かの abuse で Reputation 落ちる可能性。

影響: メール送信不可、ビジネス影響。

復旧: Cloud NAT を manual IP (専用 static IP) に切替え、SaaS 側に whitelist 申請。

再発防止:

外部 SaaS 連携には 必ず manual IP pool を使う
Reputation を IP reputation service で定期チェック
BYOIP も検討 (固定 IP 持ち込み)

💰 セキュリティサービスのコスト構造

Cloud Armor

項目	単価	備考
Standard tier policy	$5/policy/月 + $0.75/M requests	WAF, basic rate limit
Managed Protection Plus	$3,000/月/org + per-resource	Adaptive Protection, advanced DDoS
reCAPTCHA Enterprise	$1/1K assessment	Bot management 連携
Advanced Network DDoS	Managed Protection Plus に含む

Cloud NGFW

tier	単価
Essentials	無料 (Cloud Firewall 基本機能)
Standard	$0.005/policy/hour + $0.003/policy rule/hour
Enterprise	$1.00/endpoint/hour + $0.10/GB inspected

Enterprise は高い: 1 endpoint 月 $730 + traffic 課金。通常 east-west で 1TB inspect なら +$100/月。

Secure Web Proxy

$0.05/gateway/hour + $0.04/GB processed。中規模 (5GB/day) で月 ~$45 + $40 = $85/gateway。

VPC Service Controls

無料。ただし dry-run logs の Cloud Logging cost が ingestion 量に応じて発生。

📈 コスト肥大化パターン 6 種

Cloud Armor preview rule 放置

preview のまま 100+ rule、無駄な log + rule cost。

NGFW Enterprise endpoint 過剰

各 region に endpoint = 月 $730 × N region。本当に必要な region のみに限定。

WAF rule の sensitivity max

誤検知激増で Cloud Logging が膨らみ、Logging cost 月 $5,000 超。

SWP gateway の region 散在

各 region に gateway、idle なものも料金発生。

reCAPTCHA assessment 過剰

低リスクなページにも reCAPTCHA。月 100M assessment = $100,000。

VPC-SC dry-run logs 肥大

dry-run で全 access を log、Logging cost が ingest base で爆発。

🚀 最適化テクニック 10 選

Cloud Armor は edge + backend 両方で配置、layered defense。
WAF sensitivity は段階導入: 1 → 2 → 3 を 2 週間ずつ。
Adaptive Protection は preview 経由で auto-enforce 禁止。
Cloud NGFW Enterprise は対象 VPC を絞る: 高セキュリティ要件区画のみ。
SWP の URL list は IT 部門とプロセス化、追加リクエストフロー化。
VPC-SC は dry-run → enforce のデッドライン化、SCC でモニタリング。
Cloud NAT は manual IP + Static、外部 SaaS 連携で安定運用。
Rate limit は auth identifier ベース、IP-only は anonymous endpoint のみ。
reCAPTCHA score 閾値を A/B test、UX とのバランスを定量化。
Threat Intelligence の preconfigured listを有効活用 (Tor, malicious IP)。

🔔 監視アラート設計

シグナル	メトリック	閾値
Cloud Armor block rate spike	`armor.googleapis.com/...denied_count`	baseline +200%
WAF false positive	denied logs × 同 user_id 連続	連続 3 deny per user
Adaptive Protection alert	Cloud Logging filter	新規 alert 発生
NGFW policy rule miss	Firewall Insights	新規 shadowed/unused
NGFW Enterprise TLS error	NGFW logs	handshake_failed 連続
SWP block rate	SWP logs	baseline +50%
VPC-SC violation	Audit Logs	新規 violation
Cloud NAT egress reputation	External monitoring	blacklisted
reCAPTCHA score distribution shift	BigQuery export	P50 が低下
Rate limit hit by enterprise customer	logs + customer_id	誤検知の兆候

📖 Runbook: 「Cloud Armor が誤検知で本物ユーザを block」

1. Cloud Armor logs を user_id/cookie 単位で aggregate (3 min)
2. 連続 deny の origin IP/user を特定
3. WAF rule ID を確認 (sqli-stable rule 1234 など)
4. 短期対処:
   - 該当 rule を preview mode に戻す (緊急トラフィック復旧)
   - もしくは exception rule で path/header をホワイトリスト化
5. 中期対処:
   - sensitivity を下げる
   - Adaptive Protection suggested rule の見直し
6. Post-mortem:
   - 本物 traffic vs malicious の判別基準を更新
   - 誤検知率を SLI に追加
   - WAF 投入プロセスに preview 期間義務化