目次
1. WAFの位置づけを正しく理解する
- WAFは多層防御の一層であり、万能ではない
- 根本対策（入力検証、プレースホルダ、出力エスケープ、認可チェック）はアプリケーション側で行う
- WAFは「既知の攻撃パターンの遮断」「脆弱性修正までの時間稼ぎ（仮想パッチ）」「攻撃の可視化」に強い
- WAFが苦手な領域
- ビジネスロジックの欠陥（認可不備、IDOR、価格改ざんなど）
- 正常リクエストと見分けがつかない攻撃
- 暗号化・難読化されたペイロード（復号できない位置に置いた場合）
2. 導入形態の選択
| 形態 | 例 | メリット | 注意点 |
|---|---|---|---|
| クラウド/CDN型 | AWS WAF, Cloudflare, Akamai, Azure Front Door WAF | 導入が容易、DDoS対策と統合、スケール | オリジン直アクセスの遮断が必須 |
| アプライアンス/仮想アプライアンス型 | F5 Advanced WAF, FortiWeb | 細かい制御、オンプレ対応 | 運用負荷・コスト |
| ホスト/ソフトウェア型 | ModSecurity, Coraza + OWASP CRS | 柔軟、低コスト | チューニング・保守を自前で行う |
- オリジンへの直接アクセスを防ぐ（WAFを迂回されない構成にする）
- オリジンのセキュリティグループ/FWでWAF・CDNのIPレンジのみ許可
- 共有シークレットヘッダーやmTLSでWAF経由のリクエストのみ受け付ける
- TLS終端の位置を確認し、WAFが復号後の平文を検査できる構成にする
3. ルール設計
3.1 ベースラインとなるルールセット
- マネージドルール（AWS Managed Rules、Cloudflare Managed Ruleset など）や OWASP Core Rule Set (CRS) をベースにする
- 対象とするリスクの目安として OWASP Top 10 を意識する
- SQLインジェクション、XSS、パストラバーサル、コマンドインジェクション、SSRF、XXE など
3.2 アプリケーションに合わせたルール
- 使用している技術スタック（PHP / Java / WordPress / Linux など）に対応したルールのみ有効化し、無関係なルールは無効化して誤検知と負荷を減らす
- ポジティブセキュリティ（許可リスト） を可能な範囲で併用する
- 許可するHTTPメソッド、Content-Type、パス、パラメータ名・型・長さを定義
- 管理画面（
/admin等）はIP制限や追加認証で保護
- リクエストサイズ・ボディ検査上限 を設定し、上限超過時の挙動（遮断 or 検査せず通過）を明確にする
- 上限超過分が検査されずに通過する設定は回避手段になり得るので注意
3.3 ボット・不正アクセス対策
- レートリミット：ログイン、パスワードリセット、OTP検証、検索、APIなどエンドポイント単位で設定
- クレデンシャルスタッフィング / ブルートフォース対策：ログイン試行回数制限、CAPTCHA/チャレンジ
- ボット管理：既知の良性ボット（検索エンジン）は検証付きで許可、悪性ボットは遮断
- IPレピュテーション / 地域制限：業務上不要な国・既知の悪性IP・匿名プロキシを制限（誤遮断に注意）
3.4 仮想パッチ
- 脆弱性が公表された際、アプリ修正までの暫定対策としてWAFルールを即時適用する
- 仮想パッチは恒久対策ではない。修正完了後はルールを見直す（期限を設けて管理）
4. 導入・チューニングの進め方
- 検知（カウント/ログのみ）モードで開始
- 本番トラフィックで一定期間（目安: 1〜4週間、業務サイクルを一巡する期間）観測
- 誤検知（False Positive）の分析
- どのルールが、どのパス・パラメータで発火したかを確認
- 除外設定は最小範囲で
- ルール全体を無効化するのではなく「特定パス × 特定パラメータ × 特定ルール」に絞って除外
- 除外理由をドキュメント化する
- 段階的に遮断モードへ移行
- 影響の小さいルール・パスから順に遮断へ
- CRSの場合はパラノイアレベル（PL）や異常スコア閾値を段階的に厳しくする
- 継続的な見直し
- アプリの機能追加・改修時に再チューニング
5. ログ・監視・アラート
- 全リクエストまたは少なくとも検知・遮断イベントのログを保存し、SIEM等に集約
- ログに含めたい情報：タイムスタンプ、送信元IP、URI、メソッド、発火ルールID、アクション、User-Agent、リクエストID
- 機密情報のマスキング：Cookie、Authorizationヘッダー、パスワード、カード番号等はログからマスク/除外
- アラート設計の例
- 遮断数の急増（攻撃キャンペーンの可能性）
- 特定IPからの大量検知
- 正常系の遮断急増（誤検知・設定ミスの可能性）
- ダッシュボードで遮断率・上位ルール・上位送信元を定常的に可視化
6. 運用・変更管理
- WAF設定をコード化（IaC）：Terraform / CloudFormation 等で管理し、レビュー・履歴・ロールバックを可能にする
- ステージング環境での事前検証：ルール変更はステージングで回帰テスト後に本番反映
- マネージドルールの更新方針：自動更新か、バージョン固定＋計画的更新かを決める
- 緊急時の手順（Runbook） を用意
- 誤検知で業務影響が出た際の一時除外手順
- 攻撃発生時の緊急遮断手順
- 権限管理：WAF設定の変更権限を最小限に、変更は監査ログに残す
- フェイルオープン/フェイルクローズ の方針を決める（WAF障害時に通すか止めるか）
7. テスト・検証
- 定期的に脆弱性診断・ペネトレーションテストを実施し、WAFの有効性を確認
- 診断時はWAFあり/なし両方で行うと、アプリ自体の脆弱性も把握できる
- WAFテストツールで回避耐性を確認（例: GoTestWAF、CRSのテストスイート）
- 回避テクニックへの耐性を確認
- エンコーディング（URL二重エンコード、Unicode）、大文字小文字混在、コメント挿入、HTTPパラメータ汚染、Content-Type偽装、チャンク転送 など
8. API保護
- REST / GraphQL などのAPIもWAFの保護対象に含める
- OpenAPI等のスキーマに基づくリクエスト検証（許可リスト型）を活用
- JSON/XMLボディのパース・検査が有効になっているか確認
- APIキー・トークン単位のレートリミット
- GraphQLではクエリの深さ・複雑度制限、イントロスペクションの本番無効化を検討
9. パフォーマンスと可用性
- ルール数・正規表現の複雑さはレイテンシに影響するため、不要ルールは無効化
- WAF自体の冗長構成・スケーリングを確保
- DDoS対策（L3/L4はネットワーク層の対策、L7はWAF＋レートリミット）を組み合わせる
10. チェックリスト
- オリジンへの直接アクセスを遮断している
- TLS復号後のトラフィックを検査している
- OWASP CRS またはマネージドルールをベースラインとして適用している
- 不要な技術スタック向けルールを無効化している
- 検知モードで観測後、段階的に遮断モードへ移行した
- 誤検知の除外は最小範囲で、理由を記録している
- ログイン等の重要エンドポイントにレートリミットを設定している
- リクエストボディ検査上限と超過時の挙動を把握している
- ログをSIEM等に集約し、機密情報をマスクしている
- アラートとダッシュボードを整備している
- WAF設定をIaCで管理し、変更レビューを行っている
- 誤検知・攻撃発生時のRunbookがある
- 定期的な診断でWAFの有効性・回避耐性を確認している
- APIも保護対象に含めている
- 仮想パッチに期限を設け、根本修正を追跡している