従来型 WAF がアプリ保護には不適切な時代遅れの技術である4つの理由

Web アプリケーションファイアウォール (WAF) は、データセンターからクラウド、そしてサーバーレス環境へと長年にわたって受け継がれてきたテクノロジーですが、実際にはあまり効果が無く、多くのユーザーに嫌われる存在となっています。従来型 WAF がいまだに幅広く利用されている本当の理由は、法的基準によって設置が義務付けられているためであり、技術的に優れているからではないということは、Web アプリケーションセキュリティの世界では一般的によく知られています。

従来型 WAF がいまだに幅広く利用されている本当の理由は、法的基準によって設置が義務付けられているためであり、技術的に優れているからではありません。

今回は、セキュリティ対策として不十分な WAF が現在も広く利用されている理由と、それに代わる解決策についてご紹介します。

従来型 WAF : 時代遅れのテクノロジー

ネットワークの境界を保護する従来型の WAF は、アプリケーションの脆弱性の増加に対応し、その膨大な検知数による組織への負担を回避する対策として、今の環境にはそぐわない古い技術を用いて構築されたものです。また、静的・動的分析ツールによって手に負えないほどの大量のバグが特定され、開発チームはその修正に追われていました。

従来型 WAF は大量に発生する SQLiコマンドインジェクション、XSS 攻撃をフィルタリングすることで、開発チームやセキュリティチームへの過剰な負担を軽減する応急措置として導入されるようになりました。アプリケーションのバグやセキュリティ上の欠陥をひとまずトリアージし、最終的には問題の根源であるコードを修正する、というのが従来型 WAF の本来の意図でした。

当時は、このようなドロップイン式の Web アプリのセキュリティフィルターは効果的であるように思えました。正当なトラフィックがブロックされることもありましたが、コンプライアンスにおいて保護対策が特に必要とされていたアプリケーションレイヤーで、ある程度の安全性を確保することができました。そして、PCI (Payment Card Industry) 基準が策定されたことで、セキュリティ対策をめぐる環境が劇的に変わりました。

PCI 要件6.6では、WAF の設置、またはアプリケーションに対するすべての変更における徹底的なコードのレビューが義務付けられています。コードレビューには非常に大きな手間がかかることから、ほとんどの組織が WAF の導入を選択することでこの要件に準拠しています。つまり、セキュリティ担当者はセキュリティ上の価値ではなく、単に PCI 要件を満たすために WAF を導入しているいうことです。そのため、セキュリティ対策のほんの一案であった従来型 WAF が王道のソリューションに成長したのは、PCI のおかげだと言っても過言ではないでしょう。

実用性ではなく、法的必要性に支えられたこの時代遅れのテクノロジーは現在も利用され続け、セキュリティ上の効果が不十分であるにもかかわらず誤った安心感をもたらしています。そこで、従来型 WAF を手放すべきソリューションとして認識していただくために、具体的な理由を4つご紹介します。

1. WAF ルールを最小限に抑えるアプローチは不合理

従来型 WAF における一般的なデメリットは、正当なトラフィックをブロックしてしまうことです。アプリケーションセキュリティの世界では、これを誤検知と呼んでいます。一見無害に思われがちな誤検知ですが、商品の購入や旅行写真のアップロードを妨げるなど、顧客がアプリケーションの機能を利用できなくなるという落とし穴があります。このようなユーザーエクスペリエンスの問題は、顧客の喪失につながります。

従来型 WAF による誤検知を回避するために、多くの企業はルールの設定を最小限に抑えています。

従来型 WAF による誤検知を回避するために、多くの企業はルールの設定を最小限に抑えています。これでは最も目立った攻撃は阻止することができても、それ以外はすべて容易にフィルターを通過してしまいます。ルールを緩めると、攻撃者がルールを回避しやすくなるため、WAF は攻撃に対して効果を発揮することができなくなります。

2. 脅威や開発のペースについていけない学習モード

従来型 WAF による誤検知を回避し、正当なトラフィックのブロックを防ぐためのもう一つの方法は、「学習モード」での運用です。学習モードでは、従来型 WAF は通常のトラフィックと悪質なトラフィックの違いを学び、それに応じてアプリケーションを保護しようとします。学習モードを正しく実行することはただでさえ困難なことですが、本番環境ではその他にも大きな問題が多数見られます。

まず、学習モードでは学習自体に多くの時間がかかります。従来型 WAF が「通常の動作」を見極め、それ以外のトラフィックをブロックできるようになるには、一定の量のトラフィックをレビューする必要があります。WAF がアプリケーションの安全なトラフィックパターンを学ぶまでに数時間かかることがあります。

また、ウォーターフォール式からアジャイル、DevOps 式の開発プロセスへの移行が進むにつれて、デプロイのスピードが加速します。アプリケーションコードは1週間、1日、さらには1時間ごとに変更されるようになります。最先端の開発モデルの頻度でデプロイを行う場合、コード変更の度に従来型 WAF を学習モードで実行するということは、学習モード以外では WAF を使うことができないということになります。つまり、最先端のアプリ開発のペースに学習モードがついていくことは不可能であるということです。

3. モニタリングモードコンプライアンスではない

従来型 WAF が今でも広く利用されている理由は、法的基準によって義務付けられているためであり、技術的に優れているからではない、ということは業界では一般的に知られています。また、ほとんどの企業が従来型 WAF をブロックモードで使用することがないというのもよくある話です。誤検知率の高いブロックモードでは、正当なトラフィックがブロックされ、確実にアプリケーションに悪影響が及んでしまうためです。

そのため従来型 WAF はブロックモードの代わりに、トラフィックを監視し、イベントを攻撃としてログに記録するモニタリングモードで使用されがちです。監査の時期になると従来型 WAF のブロックモードが一時的にオンにされますが、監査が終了するとまたオフにされてしまいます。実際のところ WAF をブロックモードで使用していなくても、WAF が設置されてさえいれば要件を満たしていると考える監査員も少なくありません。

監査の時期になると従来型 WAF のブロックモードが一時的にオンにされますが、監査が終了するとまたオフにされてしまいます。

WAF のモニタリングモードでの使用は、効果的な保護対策ではありません。モニタリングモードは誤った安心感を与えてしまうだけでなく、ログに記録されたイベントのチェックが必要になるため、セキュリティチームのオーバーヘッドの増加につながります。その結果、防御対策としての効果が皆無な上、無駄なコストがかかってしまう可能性があります。

4. 従来型 WAFコストの高いチューニングが不可欠

ネットワークの境界を保護する従来型の WAF を運用する場合に欠かせないのが、誤検知を回避するための膨大なルールのチューニング作業です。チューニングは従来型 WAF にとって必要なメンテナンス作業ですが、ベンダーによっては、アプリや API の保護対策を必要とする顧客に WAF を売りつけるために、このチューニング作業をあたかも WAF 製品の魅力のひとつに見せかけようとする場合があります。例えば、チューニング作業を特別なプレミアムサービスとして扱い、有料の「サービスパッケージ」として提供するベンダーもいます。この場合、ベンダーがチューニングを代行する代わりに、高額なコストが発生します。また、誤検知を回避するためにチューニング作業を行うのは、WAF 運用者として当たり前であると主張するセキュリティベンダーも存在します。

従来型 WAF のルールチューニングのコストは、ベンダーの価格を比較する際に気づかないことが多いため、代行サービスを利用してチューニングを行う場合でも、社内で行う場合でも予期せぬ費用が発生することが多々あります。プロフェッショナルサービスの質も、担当者の能力やチューニングの複雑さによってバラつきがあるほか、時間単位で料金を支払う場合、急激にコストがかさむことがあります。専門知識を持つ社内のスタッフがチューニングを行うことも可能ですが、アプリケーションのコードベースが複雑化し、攻撃対象領域が拡大する場合、スケーラブルな解決策ではありません。

WAF によっては10年以上も前に構築され、古いタイプの管理ユーザーインターフェイスを使用しているものも多く、非常に使いにくい場合がよくあります。さらに、企業の拡大や市場における競争力を高めるために、より多くのアプリや API がデプロイされるようになるにつれ、スタッフは勤務時間のすべてを WAF のチューニング作業に費やさなければならなくなる恐れがあります。そのためだけにスタッフを雇用・教育することで、チームの人員に加え、部署の予算やリソースが WAF の管理に取られてしまうことになります。

解決策 : 現代の Web保護する次世代 WAF

コンプライアンスだけがセキュリティ対策を選ぶ基準であってはなりません。法的要件を満たしつつ、Web アプリケーションレイヤーの保護を強化する新たな方法はいくつかあります。例えば、アプリケーションの特徴に応じて包括的な保護を提供する次世代 WAF (NGWAF) もその一つです。これらの最先端の WAF を使用することで、PCI の要件を満たすだけでなく、正当な顧客のトラフィックを妨げることなく、OWASP Top 10 攻撃やアカウント乗っ取りの阻止、ビジネスロジックの計測、ボットの撃退などを積極的に行うことが可能になります。

Liz Hurder
Product Marketing Manager (セキュリティ)
投稿日

この記事は7分で読めます

興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Liz Hurder
Product Marketing Manager (セキュリティ)

Fastly で Senior Product Marketing Manager を務める Liz は、セキュリティプロダクトを管理しています。Fastly 入社前は Signal Sciences で Product Marketing Manager として活躍し、同社の買収を通じて Fastly の一員となりました。また、SaaS やセキュリティ関連のスタートアップ企業でプロダクトマーケティングやパートナーマーケティングを担当した経験があります。プライベートでは旅行やビデオゲーム、筋トレなどを楽しんでいます。

Fastly試してみませんか ?

アカウントを作成してすぐにご利用いただけます。また、いつでもお気軽にお問い合わせください。