はじめに

WAF(Web Application Firewall)はWebサービスのセキュリティを高めるために使用される装置の一般名称です。WAFそのものの説明は割愛します。WAFはトラヒックがアプリケーションに到達する前に既知攻撃、スキャン、異常な入力、過剰なアクセスをドロップすることができる強みがあり、採用事例も多数あります。しかしWAFを導入・運用するときに本当に難しいのは、装置の導入そのものではなく

この遮断ルールは正常なユーザーを止めないのか（誤遮断がないのか）
止めた場合、誰が、どの根拠で、どこまで事業影響を受け入れるのか

ということです。WAF関連の情報は、導入手順やルールセットの説明に寄りやすい傾向があると感じています。市場に薄いのは、WAFを入れた後に残る「説明責任」と「誤遮断時の事業判断」を正面から扱う記事だと考えました。一連の主張はWAFを否定するものではありません。WAFの価値を過小評価せず、同時に「安心を買った」と誤解しないための前提を作り、かつ最も効果的にWAFを活用するためのヒントとして、導入前の意思決定、運用設計、顧客説明、インシデント時の戻し判断の助けになれば幸いです。

次のシナリオを考えてみましょう。

仮想シナリオ： ECサイトのセキュリティを高めたい

WAF導入と検知モード運用
この組織では事業インパクトの大きなECサイトのセキュリティを向上させるためにWAF装置の導入を決定し、具備された推奨セットを最も低い感度で有効化することにしました。
セキュリティ担当に相談したところ「まずは検知モード（遮断実行なしのモード）にて様子を見てから、遮断に切り替えましょう」とアドバイスを受け1か月間様子を見ました。
定常的に検知（遮断候補）が1時間当たり100件ほど発生しているものの、専門家からは「あくまでサービス性質によりますので、システム担当のご判断で。」と言われ、明確な判断根拠が決定できませんでした。
マネージャーはあまり大きな数ではないと主観で判断し、本番環境へWAFの遮断モード切替を実行しました。
念のため監視モニターでHTTPレスポンスステータスコード403の件数を監視することにしました。
定常アクセス件数全量は1時間あたり6万件、検知モードで検知されている件数（遮断候補の件数）が1時間あたりの件数が60件だったので、403件数の閾値にはその5倍の300件を設定しました。
インシデント発生～アクション
このECサイトで最もトラヒックが多くなる年に1度のイベントの日、開始時刻の午前10時を超えてしばらくして監視モニターが鳴り、HTTPレスポンスステータス403件数の異常が検知されました。401（認証エラー）, 404（NotFoundエラー）は正常でした。
確認すると定常値の約100倍ペースである10分あたり6000件のトラヒックがステータスコード403で遮断されていました。
加えてお客様からも「画面に403という文字が表示されている」「スマホアプリが真っ白になっている」「ログインに失敗してマイページに入れない」との申告が発生し、緊急体制の確立が宣言されました。
イベントに備えた体制は確保していたものの、WAFによる遮断が異常値を示すことは想定外だったため、急ぎWAFに詳しいセキュリティ担当の招集を行いました。
セキュリティ専門担当からは以下の見解が示されました。
「システムログからわかることは、ステータスコード403のログ件数が平時より明らかに多いことと、ログに記録された範囲では正常トラヒックと乖離した特徴は見いだせないこと。攻撃を受けているのかもしれないし、誤遮断を起こしているのかもしれない。」
続けて、ネクストアクションとして以下の選択肢が示されました。

選択肢1: 短期のサービス継続性を優先し、WAFの遮断モードを解除する。それによりWAFによる403遮断影響を解消する。
選択肢2: 攻撃を受けている前提でトラヒックの分析を行う。ただしログからは不正アクセスの兆候が見えず、アプリケーションの業務性質と仕様を踏まえた検討をする必要があるため、システム構成図、アプリケーション仕様書等の判断根拠になる資料を準備してほしい。この作業にはお互いに情報共有と議論が必要で、事象収束までには少なくとも3時間はかかる見込み。

マネージャーは選択肢1を採用し、本番環境に対してWAF遮断モードの解除を決定。セキュリティ担当の招集や議論、本番環境への変更適用の手順書準備と承認フローの準備も含め、変更適用が完了したのは事象検知から約3時間後、13:00でした。
これで当日の影響は終息しました。

タネあかし

今回想定したシナリオ

定常的に誤遮断は1時間当たり6件（全体比0.01%）発生していた。発生箇所はログイン認証時のプロキシ機能を提供するマイクロサービスであった。
検知モード運用では不正・正常の区別がつかないためこの少数の誤遮断は検知・考慮されなかった。お客様はリトライによって事象解消し、不具合申告も上がっていなかった。
イベント開始後10分のトラヒックペースは定常時の100倍、10分あたり100万件になり、誤遮断は600件発生していた。件数が増加したこと、イベントに関心を持つユーザが不便を感じたことから申告が初めて発生した。
加えて、イベントに関心を持つ攻撃者がスキャンツールにより10000件ほどのアクセス実行した。認証エンドポイントにPOSTペイロードとして不正値を送信する性質の攻撃で、リクエストURL,ユーザーエージェント,IPアドレスなどログに記録される値に不自然な点はなかった。この多くが検知された結果、アラートが発報した。

対応の問題点

監視モニターが403件数の異常を検知したときにどうするのか、アクションが決まっていなかった。
トラヒックがWAFで遮断されたとしても正常・問題なしとする基準が定められていなかった。少しの誤遮断も許さない空気があった。
実際には攻撃を受けているのに、誤遮断か攻撃かを見抜けずサービス継続を優先した結果、逆に攻撃者に入口を開けてしまった

このシナリオで示したかったことは次のことです。

WAFはシグネチャをある程度チューニングできるものの、ヘッダ・HTTPリクエストのペイロード程度しか見えない通常のシステムログでは、不正かどうかを断定することが困難です。
いざ遮断事象が発生したとしても、それを説明可能にすることは困難です。運よく稚拙な攻撃で明らかな場合は誤遮断なしの判断ができますが、正常リクエストと見分けがつかない場合は判断ができません。
シグネチャの調整には「そのアプリケーションがどんなペイロードを正常通信で受信するか」という業務知識が必須です。
導入支援を外部に委託したとしても、アプリケーションの業務性質、事業インパクトをもとに遮断を許容し、責任をとるのは運用担当になります。

特に大規模なサービスになるほど、組織では「正常なユーザが誤遮断されていないのか」という点が気にされ、なおかつ「不正な攻撃ははじきたい」という要求が発生します。上記のシナリオでお示ししたように、WAFは装置としてネットワーク経路に入っているだけでは全く足りず、組織における事業判断、業務知識、専門スキル、すべてそろってやっと運用のフィジビリティが生まれる、運用ハードルの高いものであるということを前提に置きます。本稿・周辺の稿ではWAF導入を検討されている、もしくは導入済み、どちらの立場の方にも有用な情報となればと思い執筆いたしました。

WAFは業務仕様を知らない

WAFはリクエストを見て、攻撃らしさや異常らしさを判断します。リクエストパス、ヘッダ、Ｃookie、クエリパラメータ、ボディ、IP、国、ASN、TLS fingerprint、振る舞いなどを材料にします。Google CloudのWAF製品であるCloud Armorなら、許可、拒否、リダイレクト、流量制限、レートリミット、事前構成WAFルールなどを利用できます。重要なのはWAFは業務仕様を知らないということです。あるサービスでは、自由入力欄にHTML断片が入ることは攻撃に見えます。一方別のサービスでは、それはCMS、テンプレート編集、教材、コード共有、問い合わせ本文として正常かもしれません。多くのWAF（注1）は「攻撃パターンに似ている」という検知はできますが、「このユーザーがこの画面でこの値を入れることは業務上正当である」という判断はできません。ここに、WAF運用の最初の壁があります。

注1: ここで挙げるWAF運用の難しさにおいては、Google Cloud, AWS, Azure, セルフホストソフトウェア型製品など、比較的一般的かつ安価なWAF製品を指して述べています。
エンタープライズ向けの高度なWAF製品の一部（e.g. Cloudflare, Akamai, radwareが提供するもの）はAIやマネージドルールによる高度な自動シグネチャ調整の機能が具備されており、この課題はライセンス費用とトレードオフで解消されることもあります。ただし本質的な難しさは変わらず、これらエンタープライズ向け製品の導入に当たっても本稿の指摘を踏まえ慎重に検討する必要があります。

誤遮断ゼロを説明するのは難しい

多くのWAF製品では、トラヒック遮断時に適用されたポリシー、ルール、シグネチャ情報が出ます。
それでも

この403は不正な攻撃を止めたのか。
それとも正常ユーザーの正常な入力を止めたのか。

はわからないことが多くあります。なぜなら、通常のシステムログにはリクエストボディの情報が出せず、かつそこを突いた攻撃される場合があるからです。仕様によってはリクエストボディの可視化ができる場合もありますが、顧客情報やパスワード、TOKEN等を含みうる領域のため機密情報保護の観点から推奨されません。つまり、観測できる情報を増やすと公開・保管リスクが増える、情報を絞ると判断文脈が不足するという性質を持ちます。WAFの難しさは、この両方を同時に扱うことにあります。

検知モードは安全証明ではない

検知モード（遮断を実行せず検知したことをログにもに残すモード。Google CloudのCloud Armorにおけるpreviewモード）は有用です。お客様影響を出さず、ログ上で「このルールなら何が遮断候補になるか」を見ることができます。
ただし、検知モードで1か月間問題が見えなかったとしても、それは将来の正常通信が遮断されない証明ではありません。言えるのはせいぜい、

その期間、そのトラフィック、そのログ可視性、その判断体制では、大きな問題が見えなかった。

ということです。本番環境ではお客様の任意入力やランダムなTOKENなど、初めて出る入力があります。イベント時だけ公開されるページのアクセス、本番環境の特定顧客だけが使うパラメータ、外部連携、Webhook、古いクライアントなど、ランダム性の高い挙動は検証環境で再現されないことがあります。
つまり本番環境は入力空間が非常に広く、検証で拾いきることが難しいという性質を持ちます。検知モードは安全証明ではなく、発見手段の一つにすぎません。

WAFルールもアプリケーションも変わる

WAFは一度設定したら終わりではありません。例えばWAF製品の事前構成ルールセットは更新されます。Cloud Armorが使用するOWASP CRSのルールセットも、偽陽性とチューニングを前提にしています。
そのWAF製品のベンダ側のシグネチャ更新により、過去に問題なかった入力が将来も同じとは限りません。同時に、アプリケーションも変わります。新機能やフォーム項目の増加、JSON構造の変更、外部連携が増える、ユーザー生成コンテンツの性質が変わるなどです。その変化のたびに、過去の検証や運用で得られた誤遮断軽減の一定の保証が崩れ、本質的には検証環境での網羅試験、本番環境での検知モードでの運用が必要となります（これは別に述べますが、組織の責任・線引きの問題です）。
業務・セキュリティ知識をもつ人材を常時抱え続け、試験発生時に開発メンバ・統制メンバ含め多数の人員稼働が発生することを踏まえ予算を確保できるのか、というのがサービス運用組織判断になります。
つまり、WAF導入は「設定」ではなく「運用」であるということです。

L7 DDoSでも同じ問題が起きる

最近ではWAF製品にDDoS攻撃対策機能がバンドルされることが増えてきたため、これについても少し触れます。詳細には別のページで述べます。SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）だけでなく、L7 DDoSやHTTP floodでも、同じく前述の問題が出ます。たとえばIPアドレス単位で厳しいレートリミットをかけると、企業NAT、学校、イベント会場、モバイル回線、プロキシ配下の正常ユーザーを巻き込み遮断する事故が発生する可能性があります。
また、JA3/JA4のようなTLS fingerprintもユーザーIDではありません。リクエストパス、ヘッダ、Cookieで絞っても、マルウェアに感染した多数の一般の機器をボットネットとして使用する近年の攻撃では値が分散してしまい、キーとしての意味が薄くなります。
キーごとに一定のリクエスト回数制限を設けるレートリミットは強力ですが、正規ユーザーと攻撃者を業務文脈込みで完全に分けるものではありません。
ボリュームベースで「単一リクエスト元」、もっと言うと「単一ユーザ」を区分することが価値を持つDDoS攻撃遮断の状況において、IPアドレス、JA3フィンガプリントなど、静的なキーをもってこれを特定することが難しい、というのが遮断閾値設定の難所になります。

WAFが有効な場面

WAFが無価値という意味ではありません。むしろ価値がある場面をはっきりさせるために、以下の活用意図を示します。

場面	WAFの価値
既知攻撃やスキャンを減らしたい	説明可能性の高いシグネチャを選べば、定常ノイズを安全に前段で落とせる
緊急時に攻撃の特徴量が掴めた	正常ユーザの巻き込み覚悟で、IP、国、ASN、path、UA、headerで一括遮断できる
低リスク領域に強めのルールを入れたい	誤遮断時の影響が小さい範囲で厚くできる
脆弱性修正まで時間を稼ぎたい	仮想パッチとして使える
バックエンド課金やリソース枯渇を抑えたい(DDoS)	アプリに届く前に落とせる

一方で、次の期待は危ういです。

期待	危うい理由
誤遮断ゼロを保証したい	未来の正常通信を完全には列挙できない
WAFを入れればアプリ脆弱性が解決する	本質対策はアプリ側の入力検証・認可・出力処理
検知モードで問題がなければ将来も安全	検知モードは観測済みトラフィックの確認にすぎない
外注すれば判断責任が消える	業務上の正当性と事業影響の判断は利用組織に残る

導入前チェック

WAFを入れる前に、最低限これを決める必要があるでしょう。

どのパス / API / 資産を守るのか。
誤遮断時の事業影響を誰が判断するのか。
検知モード期間に、重要導線のトラフィックが観測されるのか。
遮断モード切替後に遮断増加が観測された、誰がどのように切り戻し判断するのか。
WAF装置のシグネチャ更新とアプリリリースによる遮断挙動変更のタイミングをどのように追うのか。

まとめ

WAFは魔法ではなく、攻撃者と正規ユーザーを業務文脈込みで完全に見分ける装置ではありません。アプリケーションの前段で大きな粒度で通信を捨てるための強力な制御点です。緊急時の一時緩和、定常スキャンの削減、低リスク領域の防御、バックエンド保護に価値があります。ただし、誤遮断なく、本気のL7 exploitやDDoSだけを都合よく止める装置ではありません。件数はさておき、実務において誤遮断は発生するものととらえて運用するべきです。
重要なのは、WAFをどのリスクを下げるために、どの事業影響を受け入れて、どの範囲に適用するのか。導入によって享受できる攻撃リスク軽減メリットと誤遮断増大リスクを、提供サービス業務・事業インパクトの文脈で評価しを決定することが重要です。

参考資料

Google Cloud Armor: Security policy overview
https://docs.cloud.google.com/armor/docs/security-policy-overview
Google Cloud Armor: Tune preconfigured WAF rules
https://docs.cloud.google.com/armor/docs/rule-tuning
Google Cloud Armor: Verbose logging
https://docs.cloud.google.com/armor/docs/verbose-logging
OWASP Core Rule Set: False positives and tuning
https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/