WAFは不要

セキュリティチームから深刻なサイバー脅威の現状を聞かされ、自社のWebアプリケーションが脆弱性だらけだと気づく——。修正には永遠とも思える時間がかかりそうで、途方に暮れている方も多いのではないでしょうか。

WAFは期待外れ

そこに救世主のように現れるのが、Webアプリケーションファイアウォール(WAF)です。インジェクション攻撃や分散型サービス拒否(DDoS)といった代表的な脆弱性をブロックしてくれて、コーディングも一切不要。Webトラフィックをすべてまず WAF に流せば、HTTPSリクエストを検査し、危険なものを遮断してくれる——というわけです。

WAFは、Webアプリケーションへ向かうすべてのHTTPSリクエストを検査し、危険と判定したものを遮断します。HTTPSリクエストを復号し、ヘッダーとボディをスキャンしたうえで、コンテンツ・IPアドレス・リクエストパターンに基づいて潜在的な脅威をブロックする仕組みです。

さらにWAFは、トラフィックの急増を遮断することでDDoS攻撃からも保護します。リクエストレートや送信元IPアドレスといった単純なルールで実現できるほか、AIを使ってDDoS攻撃に特有のアクセスパターンを検出し、ブロックする方式もあります。

でも、やめておきましょう。

WAFの導入は、誤った判断です。理由をいくつか挙げます。

自分のアプリ自身を遮断してしまう

WAFは正常な動作を攻撃と誤認し、正規ユーザーのアクセスを阻んでしまうことがあります。実際、Webアプリには「疑わしげに見える」文字列を含む入力が必要となる場面が少なくなく、正規表現がそれを誤検知してしまうのです。たとえば技術系顧客向けのサービスでは、攻撃に見えるJavaScriptのスニペットを扱うことも珍しくありません。さらに厄介なのは、アプリ自体が本質的に危険な入力を必要とするケースです。たとえばリッチテキストエディタ・コンポーネントから受け取ったHTMLをそのままレンダリングするような場合がそうです。本来は文字列をエスケープすべきで、攻撃と等価な内容をそのまま受け渡すべきではない——それはあなた自身がいちばんよくご存じでしょう。しかし、いったん作り込んでしまった弱点を根本から取り除くのは大変な作業で、それに人員を割けるようになるまでの間、WAFはあなたのWebアプリを使い物にならなくしてしまいます。

DDoS対策においても、WAFはトラフィックの急増をブロックしますが、これは最悪の誤検知を招きます。アプリがバズって急にアクセスが集中したとき、訪問者が誰一人使えなくなる、という事態です。だからこそ、機械学習(ML)を活用した高度なフィルタリングが役立ちます。完璧ではありませんが、多くのWAFが採用するパターンベースの方式よりはマシです。

個別のIPアドレス単位でのブロックは粒度が細かすぎるため、次の手段は国単位での遮断、つまりある国の顧客を丸ごと締め出すことになります。今はその国に顧客がいないかもしれません。しかしWAFを使うことで、新たな潜在市場を発見する可能性まで自ら閉ざしてしまうのです。

誤検知への推奨アプローチは、WAFをドライランモードで運用することです。本来ならブロックする場面で、疑わしい入力をログに書き出すだけに留めます。そのうえでログを分析し、誤検知があればルールを緩める(ただし本物の攻撃を見逃すリスクが生じる)か、自分たちのコードを修正する(でもそれは何年も先送りにしてきたはずです)、という流れです。私は、自社アプリの機能を壊すことを正当に恐れて、2年間ずっとWAFをドライランで運用し続けている組織を見たことがあります。結果、アプリのレスポンスは落ち、セキュリティ上のメリットはゼロ——それでもライセンス料として数万ドルを支払い続け、何の効果も得られていませんでした。

攻撃をすり抜けさせてしまう

新たな攻撃のバリエーションは、WAF設計者の想像も、あなたの想像も超えます——しかしハッカーの想像は超えません。その結果、誤検知の裏返しである「見逃し(フォルスネガティブ)」が起こります。本物の攻撃が素通りしてしまうのです。

テキストフィルタリングで最もよく使われる正規表現には、検出能力に限界があります。特定の攻撃に合わせて事前定義しておく必要があり、高速処理のためにシンプルに保たなければなりません。処理速度を確保するため、HTTPヘッダーとボディの先頭数キロバイトしかスキャンされず、その範囲を広げたとしても必ずどこかに上限があり、それ以降は素通りしてしまいます。

IPアドレスのブロックも見逃しの温床です。攻撃者はプロキシを使って簡単に新しいIPアドレスへ切り替えられるからです。

そしてWAFがどうにもできない攻撃の主因は、自社アプリケーションのロジックそのものにあります。パスワード保護されているはずのページがそうなっていなかったり、認可設定で読み取り専用であるべきユーザーに書き込みを許してしまっていたり——こうした問題はすべて自分たちの責任です。WAFにそれを見つけてくれと期待する人はいませんが、だからこそWebセキュリティを実装すべき本丸は自分たちのコードの中にある、ということを改めて突きつけられるのです。

柔軟性は?

誤検知や見逃しと格闘するうちに、ルールを細かくチューニングして自社のニーズにぴったり合わせたい、いっそ独自ルールを作りたい——そう思いたくなります。やめましょう。

ハッカーが使う攻撃手法は、すでにセキュリティ専門家が研究し尽くしています。ハッカーがあなたのためにわざわざ特別な攻撃を考案することはありませんし、仮にそうしたとしても、あなたが事前にそれを知る術はありません。あなたのアプリの脆弱性は、ほぼ間違いなく標準ルールセットでカバーされているものと同じです。診断して新しい防御ルールを書かなければならないほど特殊な弱点が本当にアプリに存在するのなら、その開発工数は応急処置にではなく、アプリそのものの改善に充てるべきです。

精度と再現率——見逃しと誤検知——のバランスを取るのは、専門家にとっても極めて困難、ほぼ不可能と言っていい作業です。だからこそ専門家は保護レベルを段階的に定義し、誤検知と見逃しのトレードオフを選べるようにしているのです。将来やってくる何百万ものWebリクエストを相手にこのバランスを細かく調整し続けるだけの価値は、ありません。

新たなリスクの上乗せ

こうした欠点を踏まえると、WAFは差し引きマイナスになるのが普通です。さらに、WAF自体がセキュリティリスクをもたらすこともあります。データを検査するためにHTTPSを復号する必要があり、新たなデータ漏洩ポイントが生まれます。WAFのコード自体に脆弱性が潜んでいる可能性もありますし、すべてのリクエストがWAFを経由するため、通信のレイテンシも増します。

こうした事実をすべて承知のうえで、それでも応急処置としてWAFを追加し、「セキュリティの脆弱性は後で直せばいい」と判断するマネージャーが少なくありません。しかし、いったんWAFが入ると、チームは安心しきってしまい、本来あるべきセキュリティ対策はいつまでたっても採用されません。アプリケーションコードはどんどん脆くなっていきます。その一方で、WAFが思ったほどのセキュリティを提供していない——という現実が残るのです。

こうした欠点はあるものの、WAFの導入が妥当な状況も存在します。ただし、それでもセキュリティ上の効果はあまり期待できません。

WAFが外部要件として求められる場合——顧客のRFP(提案依頼書)や業界規制で、正式なセキュリティ標準への準拠が義務付けられている場合は、当然導入すべきです。WAFは必要です。ただし、それはセキュリティのためではありません。

自社で開発しておらず、自分たちでは修正できないサードパーティ製のWebアプリをデプロイしている場合、WAFは多少なりともセキュリティを上乗せできる唯一の手段かもしれません。真のセキュリティレベルについて慢心してしまうリスクは残りますが、少なくともこのケースでは、自分たちで良い開発プラクティスから遠ざかってしまうわけではありません。

とはいえ、WAFを使うべき正当なセキュリティ上の理由が一つだけあります。DDoS対策です。サービス拒否攻撃で大量のトラフィックが押し寄せたとき、WAFは攻撃を検出してブロックできます。MLによる攻撃パターン検出は、十分に高い精度を発揮します。

さらに踏み込んだDDoS対策としては、Google Cloud Armor Managed ProtectionやAWS Shield Advancedのように、対応可能な人間の専門家チームを擁する体制が、最大規模のWebアプリにとって価値を持ちます。

多くの顧客は、攻撃が始まってから——もう手遅れというタイミングで——WAFや専門家チームによるDDoS対策サービスを慌てて購入しようとします。攻撃を受けてからでは間に合いません。事前に備えておくことをおすすめします。

WAFを使うのであれば、お使いのクラウドプロバイダーが提供するもの——Google Cloud ArmorまたはAWS Shield——を選ぶのが得策です。クラウドサービスなら従量課金で利用でき、実際には使わないかもしれない製品に高額な月額料金を払い続ける必要がありません。データはすでにクラウドを流れており、多くのアーキテクチャではクラウドサービスがいずれにせよデータを復号しているため、クラウドプロバイダーのWAFを使えばパフォーマンス、セキュリティ、プライバシーへの影響を最小限に抑えられます。

本記事の論点に関する技術的な詳細は、Mac Chaffee氏によるこちらの記事とStackExchangeのこちらのスレッドをご覧ください。