はじめに
WAF導入で最初に決めるべきものは、組織として何を守り、何を許容し、誰が判断するのかです。WAFは前段で通信を捨てる装置であるからこそ設定ミスや過剰防御はそのまま正常ユーザー体験の劣化になります。導入前に運用の前提を決めておかないといざ本番で403が出たときに誰も「これは止めてよい」と言えなくなります。
概要や仮想シナリオについてはこちらを参照ください。
←-- 前の記事
この記事の立場
WAFを導入・運用する際に実務で不足するのは、その前に決めるべき運用判断です。この記事では、WAFを「入れるかどうか」ではなく「入れたあと誰が何を判断できる状態にするか」に置きます。これはWAF製品ベンダの公式ドキュメントだけでは埋まりにくいと考えています。なぜなら、誤遮断の許容度、重要導線、事業側の意思決定、切り戻し権限は、製品仕様ではなく組織ごとの運用設計だからです。WAF導入を任されたセキュリティ担当、SRE、インフラ担当は、設定値そのものより「どこまで強くしてよいか」「本番で止めたら誰が責任を持つか」で詰まりやすいのではと推測しています。この記事は、その詰まりを導入前の確認項目に落とし込みます。
1. 目的を分ける
まず、私はWAF導入の目的を分けました。
| 目的 | 代表的な設定 | 判断の難しさ |
|---|---|---|
| 定常ノイズ削減 | スキャナー検知、低感度の既知攻撃ルール、正規表現手組みのルール | 比較的低い |
| 仮想パッチ | 特定CVE、特定パス、特定ペイロード | 中程度。アプリ仕様の理解が必要 |
| 緊急遮断 | IP、ASN、国、User-Agent、path、rate limit | 高い。正常ユーザ巻き込み遮断の事業判断が必要 |
| コスト防衛 | rate limit、cache key制御 | 中程度。正常スパイクとの衝突に注意 |
| 厳格なアクセス制御 | allowlist、認証連携 | 高い。誤遮断が直接影響する |
「WAFを入れる」では検討の粒度が粗くなりがちです。目的が違えば、許容できる誤遮断や承認基準が変わります。定常スキャンを減らすルールと、申込画面の入力を止める可能性があるルールを同じ承認フローで扱うとどちらかが破綻します。WAF定常ノイズ削減はセキュリティ側で進めやすい一方、ログイン、申込、決済、外部連携に影響するルールはセキュリティだけでは判断できなません。止めるべき攻撃に見えても、止まる正常通信のサービス提供価値が判断に織り込まれていないからです。
2. 適用範囲を分ける
全サービスに同じWAFルールを一律適用するのは危険です。
次のようにサービスの性質ごとに適用方針を分けるのが良いと私は考えています。何が正しい方針かは組織によって変わるはずなのであくまで例です。
| サービス種別 | 方針例 |
|---|---|
| Webアプリフロントエンドなど静的コンテンツ中心 | path、method、queryを狭く定義しやすい。比較的強めの制限を検討できる。 |
| 入力面が小さいAPI | 仕様が明確なら、メソッド、パス、ヘッダー制限が効く。 |
| 自由入力が多いサービス | マネージドWAFルールの誤検知に注意。検知モード運用とチューニング前提。 |
| 決済・申込・ログイン | 誤遮断時の事業影響が大きい。緊急時運用を重視して普段は緩くしておき、セキュリティの本丸はアプリケーション側の実装として投資判断する。 |
| 社内・限定利用 | allowlistや強いルールを適用しやすい。IP制限で正規ユーザを識別できるなら、不正検知シグネチャを利用せずシンプルなIP制限装置として利用する。 |
同じWAFでも、公開画面、認証付き管理画面、API、画像配信、Webhook、決済画面ではリスクが異なります。階層化されたポリシーやサービス単位のポリシーを使う場合もまずこの分類が必要になります。ここで重要なのは強いルールを避けることではなく、強くできる場所と事業影響が大きく強くできない場所を分けること、さらには「守らなくてよい導線に余計なルールを入れない」ことです。
3. 誤遮断の受け入れ基準を決める
WAF運用で最も曖昧になりやすいのが誤遮断です。導入前に最低限次を決めておく必要があると考えます。
- 誤遮断が発生した場合の重大度分類
- どのページ、APIで403が出たら即時切り戻すのか
- どの範囲なら一時的な遮断を許容するのか
- どの指標が閾値を超えたらアラートにするのか（件数、通信全量比、403 deny件数/200 OK件数 の比など）
- どのログを見ればWAF起因と判断できるのか
- ルールを戻す権限を誰が持つのか
- 事業側への連絡文面を誰が出すのか
この基準がないとWAFの効果判定が「攻撃を止めた件数」だけになります。本当に必要なのは、攻撃を止めたことと、正常ユーザーを止めていないこと（技術的にではなく、その組織の運用設計上そういうことに決めている）の両方を説明できる状態です。
4. 検知モード結果をどう評価するか決める
一般的にWAF導入においては検知モードで遮断せずに遮断候補ログを確認してから遮断モードに切り替える運用が推奨されています。ただし検知モード運用は安全証明ではありません。検知モードで見るべきものは単なる件数ではなく「何を確認したら様子を見たことになるのか」「チューニングの要否と導入Go/No Goを誰が何の指標で判断するのか」です。
| 観点 | 見るもの |
|---|---|
| パス | パスごとに提供業務が異なるため評価単位を分ける。意図しない経路の通信が評価されてしまっていないか |
| ルール | 検知されたルールとその意味、その導線のアプリケーションのレスポンスがそのルールで誤検知されやすい性質を持っているか |
| 時間帯網羅性 | 業務ピーク、キャンペーン、バッチ時間を含むか |
| クライアント網羅性 | ブラウザ、モバイル、社内NATを含むか |
| 判断材料取得可能性 | 本番環境の検知モードログだけで攻撃か正常か判断できるか、検証環境で王道ルートを通した結果も材料に加えるか、本番環境を再現したトラヒックをとにかくたくさん検証環境に通してシナリオ網羅性を上げるか |
| チューニング可能性 | 感度設定、除外、パス限定で下げられるか。チューニング後に再度その導線で検知モードを継続するか |
検知モード運用期間は一律ではなく、サービスの重要度とトラフィックの偏りで決めます。平日だけ見ても週末の挙動は分かりません。通常時だけ見てもイベント時の挙動は分かりません。ただしどのようなサービス性質で具体的に何日様子を見ればよいのかという正解は私も持ち合わせていません。検知モード運用の結果として言えるのは、観測できた期間とトラフィックでは大きな問題が見えなかった、もしくはあったのでチューニングしてもう一回見たら問題なくなった、というところまでです。未来の正常通信が止まらないことまでは証明できません。
5. チューニングの責任分界を決める
WAFのチューニングは、セキュリティチームだけでは完結しません。チーム分けは組織によって十人十色だと思うので例ですが、
- セキュリティチーム: そのシグネチャが何を検知しているか、除外のリスクは何か、次のチューニング内容をどうするか。
- アプリチーム: そのパス、パラメータ、Cookieが業務上どう使われるか。どんな文字列が入るか。
- SRE / インフラ: どのポリシーにどう反映し、どう切り戻すか。
- 事業側: 誤遮断とセキュリティリスクをどの程度受け入れるか。例えばお客様申告があるまで普段は対応しない、1件でもログ検知したら分析にはいるなど。
特に、request field exclusionや特定シグネチャのopt-outは便利ですが、あまり除外範囲を広げすぎると防御の意味が薄れます。「このCookieはSQLiらしい値を取ることがある」だけでは足りません。どのパスで、どの入力で、どのルールを、どの理由で、どの期間、どこまで除外するかを記録する必要があります。
6. 緊急時の権限を決める
緊急時には完璧な分析を待てないことがあります。そのとき必要なのはWAF装置への変更適用コマンドを知っている人に加え「どの正常ユーザーの遮断を一時的に諦めるか」を事業判断・技術的判断で決められる体制です。たとえば事前に決めておくべきことは次に挙げられます。
- 攻撃を受けているのであれば、ピンポイントでその攻撃の評価ができ遮断手法を知っているエンジニアがいるか、いないのであればその手札は捨てられるか。
- 全遮断を誰が判断できるか。
- 国、ASN、IPレンジ丸ごとの遮断を判断できるか。
- レートリミットの閾値変更を判断できるか。
- 重要顧客、社内、外形監視SaaSなどの許可ルールをどう扱うか、そもそもその通信経路の存在とペイロード性質を業務知識として知っているか。
- 遮断後に何分ごとにログと事業影響を見直すか。
- アクション条件をどう決めるか。
わかりやすい体制の例では
WAF装置に関する何かしらのモニタアラート発報運用上決めた場所に出し、それを検知する
-> 現場マネージャがエンジニアを招集する
-> 技術的な遮断・誤遮断可能性をエンジニアとディスカッション
-> リスク低減・増大かつ事業インパクトが妥当な範囲内であるアクションを決定する
-> 現場マネージャが統括マネージャとサービス側マネージャへ作業内容とお客様からの見え方の変化、想定影響ユーザ数などを報告して合意する
緊急対応で難しいのは技術的に遮断・解放できるかに加え、その結果どの正常性を捨てるのかをその場で決めることです。
7. 変更管理を軽くしすぎない
変更管理を重くしすぎると緊急対応できませんが、軽くしすぎると正常ユーザーを誤遮断する事故が起こりえます。これを単一の承認フローにするか、緊急時だけ特別扱いにするかは組織次第だと思います。
| 変更種別 | 運用 |
|---|---|
| 平時の恒久ルール | 検知モード導入、ログ確認、レビュー、ホスト・パスごとの段階適用 |
| 緊急時の一時ルール | 事前承認され確立された判断フローと変更適用フロー、緊急適用された設定値の有効期限（何時間後に戻すか）、事後レビューと戻し判断 |
一時ルールは忘れられやすいので、緊急対応で入れたdenyやrate limitは、解除条件と棚卸し日をセットで持ち、忘れないようにすることが重要です。
まとめ
WAF導入時に決めるべきことは技術設定よりも先に
- 漠然と「WAFを入れたい」ではなく具体的に何のリスクを下げるのか。
- どのサービス・パスに適用するのか。しないのか。
- どの誤遮断を許容するのか。
- ログに何が出ていたら即時切り戻しする運用にするのか、もしくは放置してよいのか。
- 検知モード運用のログをどう評価するのか、正規パスでないものは除外（ただのスキャン）とみなし、正規パスは件数や割合でみるなど。
- チューニングを誰が判断するのか。
- 緊急時に誰が遮断・解放できるのか。
- どのルールをいつ戻すのか。ルールの適用・評価・改善の時期感やライフサイクル。
ここを決めずにWAFを入れると導入した瞬間に運用負債になります。逆にここを決めてから入れれば、WAFは強力な前段制御として機能します。
こちらのセルフホストのサイトではWikiライクなUIで最新版を投稿しています。
ブックマークしていただけると幸いです。
参考資料
- Google Cloud Armor: Configure security policies
https://docs.cloud.google.com/armor/docs/configure-security-policies - Google Cloud Armor: Use request logging
https://docs.cloud.google.com/armor/docs/request-logging - Google Cloud Armor: Verbose logging
https://docs.cloud.google.com/armor/docs/verbose-logging - Google Cloud Armor: Tune preconfigured WAF rules
https://docs.cloud.google.com/armor/docs/rule-tuning - OWASP Core Rule Set: False positives and tuning
https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/