AWS WAF運用 — 地道な改善で自社運用可能にするプラクティス

登壇者・企業の背景

• 建設プロジェクト管理SaaSを提供するバーティカルSaaS企業
• 「現場の効率化から経営改善まで一元管理」がコンセプト
• 年間2,517件のアップデートを実施（セキュリティ修正・バグ修正除く）
• マルチプロダクト体制で複数サービスを並行開発
• 登壇者はSREからセキュリティグループに転身、クラウドセキュリティとアプリケーションセキュリティを担当

AWS WAFの基本（初心者向け）

AWS WAFはL7（アプリケーションレイヤー）の攻撃を検知・遮断するマネージドサービス。

インターネット → CloudFront / ALB → [AWS WAF] → アプリケーション
                                        ↓
                              SQLi, XSS等をブロック

主な特徴:

• CloudFront、ALBにアタッチして使う
• マネージドルール（セキュリティ専門家が作成した既製ルール）を即座に適用可能
• サーバー管理不要、トラフィックに応じて自動スケーリング
• CloudWatch連携でリアルタイムモニタリング
• ログをS3に出力 → Athenaで検索可能

運用上の注意点:

• 正規ユーザーのリクエストを誤ってブロックする可能性（False Positive）
• リアルタイム対応のための監視体制が必要
• 複雑な攻撃対処には専門知識が必要
• 運用が属人化しやすい

導入状況

• 導入開始: 2019年（ワンプロダクト時代）
• 現在: 本番環境で20個以上のWAFを運用
• デプロイ先: ALB + CloudFront
• ルール構成: AWSマネージドルールをメイン＋カスタムルール
• ログ基盤: WAFログ → S3 → Athena / S3 → Datadog → アラート

4つの課題と解決策

課題1: 環境差分（開発 vs 本番）

症状:

• 開発環境で検証したのに本番でブロックが発生
• コンソールから手動変更が行われ、環境間の差分が蓄積
• IaC未対応のため、差分の検出自体が困難
• 「知らない間に変更が起きても気付かない」状態

解決:

1. 全環境の差分を一旦把握（JSONダウンロード＋比較）
2. Terraform IaCを導入し、全環境をコード管理に統一
3. コンソールからの手動変更を禁止（コードからの反映のみ）
4. 全変更にセキュリティグループのレビューを必須化

効果:

• 環境ルールの確認が即座に可能
• JSONダウンロード・画面比較の手間が消滅
• 「誰が・いつ・何を変えたか」がGit履歴で追跡可能

課題2: Terraform PRの大量diff

症状:

• WAFルールをHCLで記述すると、マネージドルールのバージョン更新だけで膨大なdiffが生成
• レビュアーがdiffを読み切れず「LGTM」が常態化
• 本来確認すべき実質的な変更を見落とすリスク

解決:

WAFルールの管理記述を「ルール定義」→「ルールセット（JSON外出し）」に移行。

従来: Terraform HCLにルール定義を直接記述 → diff爆発
改善: ルール定義をJSONファイルに外出し → Terraformはファイル参照のみ

効果:

• PRの差分が「実質変更のみ」に限定
• レビュアーの負担が大幅低減
• 一目瞭然で何が変わったかわかる

課題3: マネージドルール更新への追従

症状:

• AWSのマネージドルールは頻繁にアップデートされる
• バージョン追従の確認が不足
• 本番環境での動作確認が不十分
• 更新手順が標準化されておらず、アップグレードのハードルが高い

解決:

1. RSS受信の導入: マネージドルールの更新通知を即座に取得
2. カウントルールの活用: 既存ルール（ブロックモード）の優先度の後ろに、最新バージョンをカウントモードで配置
3. カウント期間中にログを分析し、誤検知がないか確認
4. 問題なければ本番ブロックモードに昇格

[既存ルール v3 - Block] 優先度: 高
[新ルール v4 - Count]   優先度: 低（観察用）
  ↓ 2週間後、問題なければ
[新ルール v4 - Block] 優先度: 高（昇格）

効果:

• 2週間程度で最新バージョンへの追従が可能
• 本番に影響を出さずに安全に検証

課題4: 誤検知への対応（顧客影響の事前検知）

症状:

• WAFログが膨大で全件確認は不可能
• 顧客から「使えない」と問い合わせが来て初めて気付く
• False Positiveのリアルタイム検出ができていない

解決:

WAFログではなくALBログからWAFブロック情報を検出する方式を採用。

ALBログ（元々別用途で取り込み済み）
  → Datadog に転送
  → WAFブロック条件でフィルタ
  → 「正規ユーザーがアクセスしそうなパス」のブロックのみSlack通知

工夫:

• WAFログ自体は量が多くDatadog取り込みだとコスト増大
• ALBログは既に取り込み済みだったため追加コストなし
• 攻撃リクエスト（明らかに不正なパス）はアラート対象外にしてノイズを削減
• 顧客が困っている可能性が高いブロックだけを通知

効果:

• 顧客からの問い合わせが来る前に検知・修正できるケースが大幅増
• WAFブロック関連の顧客問い合わせがほぼ消滅

今後の展望

• LLM活用: ログ分析の自動化（ログ検索、クエリ生成）
• ExtraOps エージェント: アラート初期対応の自動化（最近リリース）
• ログ分析の深掘り検討

まとめ

初心者向け補足

WAFのルールモード

• Block: リクエストを遮断する（本番運用モード）
• Count: リクエストは通すがログに記録する（テスト・観察モード）
• Allow: 明示的に許可する

新しいルールを入れる際は必ずCountで様子を見てからBlockに昇格させるのがベストプラクティス。

IaC（Infrastructure as Code）とは

インフラの設定をコードとして管理する手法。Terraform、AWS CDK等のツールを使う。

メリット:

• 設定変更がGitで追跡可能
• 環境間の差分がなくなる
• レビュープロセスを強制できる
• 手動変更（設定ドリフト）を検知・防止できる