WAFの役割とは何ですか? – ACROSEC

WAFとは何のために使用されているのですか？

　ウエブアプリケーションファイアウオール（WAF）といったセキュリティソリューションは、通常、アプリケーション層に対する攻撃からWebアプリケーションを保護するために使用され、アプリケーションのプログラミングエラー、アプリケーションの弱点、アプリケーションプラットフォームとシステム上などの脆弱性を悪用したリクエストをフィルタリングしています。

　非ウェブアプリケーション用の他のアプリケーションファイアウォールもあります。しかし、http/httpsのプロトコルレイヤーを使用するものは、Web技術（SOAP/XMLのプロキシなどを含む）を使用するため、WAFと見なされます。WAFはウェブアプリケーションに特化したアプリケーションファイアウォールです。

　非ウェブアプリケーションおよび非ウエブプロトコルのためのアプリケーションファイアウォールは通常セキュリティプロキシと呼ばれ、それはFTPの場合、FTPのセキュリティプロキシと呼ばれます。

　また、多くの非ウエブアプリケーションのプロトコルは複雑ではありません。セキュリティを確保するためのフィルタリングは多くの場合とても簡単です。このようなアプリケーションファイアウォール機能は、通常の次世代ファイアウォールの一部としてもよく見られます。

実装する場所はどこですか？

　WAFは、アプリケーションバンドルの一部として実装することも、アプリケーションの前に独立したリバースプロキシとして実装することもできます。

　リバースプロキシとしてのアプローチは、他のアプリケーションで再利用できるため、事業体にとって付加価値を生み出すものです。このようなリバースプロキシとしてのWAFソリューションは、ネットワーク・ルータと似ていますが、httpプロトコル専用になります。

　ネットワークアプライアンスというハードウエアの形をしたWAF製品が非常に人気を集めているのもその理由かもしれません。しかし、これはスケーラビリティの問題があります。対して、ソフトウェアベースのアプローチでは、スケーラビリティをより柔軟に達成することができます。

最初からセキュアーなアプリケーションを開発した方がよいのではないですか？

　これは非常に的を得た質問です。理想的な世界ではWAFは本質的には必要ないと考えられるからです。

　理想的な世界と言えば：

すべてのアプリケーションは、すべてのセキュリティガイドラインを念頭に置いて開発されています。
セキュリティの品質の承認時、すべてのアプリケーションがテストされ、セキュリティ問題を一つも見逃すことがありません。
関連するすべての運用者と開発者は、メディアに公開されたばかりの新脆弱性を直ちに修正するための十分な時間と適切なリソースを保持しています。
悪質なハッカー達は皆紳士であり、新脆弱性が公開された時から、攻撃を開始するまでしばらく待ってくれます。

　残念ながら、このような理想的な世界は存在しません。さらに、Webアプリケーションは多数のテクノロジーで出来ているために複雑なので、セキュリティを確保するレイヤーとして扱いが容易ではありません。

　現状、セキュリティ問題を起こさないようにするための、開発者に対しての注意、呼びかけやガイドラインの作成等の対策は非常に簡素なものです。そして、これのみでは不十分です。

　しかし、そのようなセキュリティ問題が発生した時に、すべての開発者と運用者が一瞬にしてセキュリティの専門家になることは期待できません。IT業界の現実は複雑であり、セキュリティから見て防御の立場は有利ではないからです。そこで防御の追加層としてのWAFは、アプリケーションのセキュリティ対策として賢明なアプローチになる訳です。

　WAFは、アプリケーションとインフラの運用者の立場から見ても便利です。プロフェッショナルなWebアプリケーションは、ファームのようなIT環境で頻繁に実装されています。通常、コードの詳細を知らないまま専門的なオペレータによって運用されています。IT業界の倫理では、本番環境の厳しいガイドラインに従うため、勝手に変更することはできません。それは可用性の第一の目標では、不正なチェンジによる被害を防ぐためだからです。

　多大なシステム障害の根本原因は、サービス精神旺盛なシステムの管理者が小さな問題を無理やり解決しようとした場合の派手な修正ミスにあります。

　このようなシステム変更の失敗リスクを最低限起こさせないためにはITシステムの変更プロセスを厳守しなければなりません。
まず専門的なアプローチとしては、テストの厳格な変更サイクル、メンテナンスウィンドウのスケジューリング、承認付きステークホルダー会議、およびロールバック計画の準備が必要不可欠です。ただ明らかに大きな本番環境には大きな変更リスクが潜伏していますので、そのような変更プロセスの変更ウィンドウは月に一、二回程度、極端な場合は年に数回しか利用できません。

　そして公開された脆弱性の対策として、大規模で複雑なIT環境の場合では、何百ものアプリケーションを同時に修正することが必要となります。従来のプロセスのやり方では、誰かがメディアに脆弱性を報告するたびに、このような大規模なシステムの変更を繰り返すことは可能とはとても言えません。

WAFのビジネスケース：仮想パッチ

　WAF上の仮想パッチでアプリケーションの脆弱性を事実上すべてのアプリケーションに一元的に適用させることができます。WAFのビジネスケースはまさにここにあります。

　仮にすべてのアプリケーションのセキュリティ状況、すべての開発者と運用者のセキュリティ知識が最高のレベルだと考えても、仮想パッチは効率的及び有益なアプローチです。

　WAFは、このような問題をすべてのアプリケーションで集中的にキャッチし、解決することをサポートします。したがって、ITのスタッフがパニックモードに陥ることなく、次の正規開発サイクルでアプリケーションを修正すればいいと考える余裕が生まれ、メディアが騒ぎ立てたパニックモードからスタッフは開放されることになります。

　これを常に規則的な方法で行えば、例外やインシデント追跡の時間とエネルギーを消費する多くのリソースから解放されることになります。

インバウンドのWAFシナリオ：Webアプリケーションのために

　WAFの導入にはもう一つ戦略的な理由があります：大規模なWeb配信およびアクセスのインフラストラクチャの一部である場合、ビジネスのアプリケーションに付加価値をもたらすことが期待できます。

　実例：

集中セキュリティアクセスサーバとしてのスイススタイル的なアプローチで、すべてのWebアプリケーションに対してポリシーと認証を同時に実施強化します。
VPNをサポートしたWAFは、イントラネットのWebベースのアプリケーションへセキュアなリモートアクセスサービスの提供ができます。
ポータル機能をサポートしたWAFは、インターネットポータル及びイントラネットポータルを作成するためのセキュアなプラットフォームサービスとして提供可能です。

アウトバウンドのWAFシナリオ：フォーワードプロキシ

　上記のシナリオはインバウンドのみですが、アウトバウンドソリューションのようなWAFもフォワードプロキシシナリオとして使用できます。

外部のWebサービスベースのSOAを利用しながら、SOAP/XMLをサポートしたWAFは内部のアプリケーションをその外部のウエブサービスのリスクから保護します。
外部のペイロード検査ができるWAFは、httpプロトコルレイヤー上のファイル転送のマルウエアリスクから保護します。

　SOAP/XMLフィルタリング機能を備えたアウトバウンドWAFは、外部SOA Webサービス（ビジネスパートナ）を安全に使用するためのセキュリティインフラストラクチャです。このような承認プロキシ機能はスイスの金融業界でも実装されています。