本シリーズ最終回となるこの記事では、クラウド型WAFの導入方法について紹介します。クラウド型WAFの導入は手順自体は簡単ですが、誤検知が起こるリスクがあるため、それをケアしながら導入を進める必要があります。
WAFの導入手順
実際にWAFの導入手順を見ていきましょう。大まかな流れは以下の7Stepです。
まずはWAFの選定を行います。考慮するポイントは企業によって様々であり、具体的なビジネス要件やセキュリティニーズに応じて詳細な検討が必要になるかと思いますが、一般的な要素として以下のものが上げられます。
- セキュリティ機能と性能
- 使いやすさと管理
- 統合の容易性と互換性
- コンプライアンスと規制準拠
- サポートと信頼性
- コストと価格設定モデル
これらの要素から優先度を決め、自社システムに適したWAFを選定します。選定の際には、必要に応じてPoC(Proof of Concept)を行うことで、製品に対する認識のズレを解消・軽減することができます。
利用するWAFが決定し、契約が完了したら、WAFの初期構築を行います。これには、ルールセットの選択、防御ポリシーの構成、ホワイトリストやブラックリストの設定が含まれます。こう見ると複雑なようにも思えますが、多くのクラウドWAFでは、主要な攻撃・脆弱性から守るためのマネージドルール・ポリシー(WAFベンダーが管理している、ベストプラクティスなルールやポリシー郡)が用意されています。
そのため、まずは利用するクラウドベンダーが定めるベストプラクティスを中心に設計し、設定を行うのが良いかと思います。プラスアルファで必要に応じ、特定のアプリケーションやビジネスの要件に合わせて、カスタムルールを設定できると望ましいです。
構築が一段落したら、WAFの動作検証を行います。クラウドWAFは、DNSのCNAME先をクラウドWAFに向け、リバースプロキシーとして動作させることが一般的です。つまり、開発者クライアントのhostsファイルに以下のレコードを追加することで、テスト通信のみをクラウドWAFに向けることができます。これにより、通常のユーザトラフィックには影響を与えることなく、動作検証を行うことが可能です。
A.B.C.D www.bloomblock.net
このようなレコードをhostsファイルに設定することで、開発者クライアントのみ、www.bloomblock.netの名前解決の応答が、WAFのIPアドレスとなります。
(※)A.B.C.DのIPアドレスは事前に取得しておきます。(この例ではcloud.waf.sample
からの名前解決で取得可能)。
動作検証で問題がないようであれば、WAFを導入していきます。ここで大事なポイントは、初期導入時では、WAFのアクションを「遮断」ではなく、「検知」モードとすることです。アクションというのは、WAFのルールやポリシーにマッチした際の、挙動を意味しています。例えば、以下のような通信に対して、SQLインジェクション攻撃としてマッチしたとします。
http://www.bloomblock.net/account/serach?accountid=1234or1=1
この時、一般的なWAFの動作は下記の2つです。
- 検知(検知のログ出力のみ)
- 遮断(検知のログ出力+通信ブロック)
事前の動作検証において、全ての通信パターンを網羅するということは不可能です。正常通信に対する誤検知を防ぐため、「検知」モードで初期導入し、次のステップであるモニタリングを経て、最終的に「遮断」モードへ移行します。
モニタリングを行わず「遮断」モードで導入を行うと、正常通信に対する誤検知(False Positive)が発生し、結果的にユーザトラフィックに影響を与えてしまう可能性があります。
WAF導入の方法ですが、CDNと同様(実際、WAFはCDNのサービスと一緒に導入することが多いです)、DNSの設定を変更して、ユーザトラフィックをWAFにルーティングさせます。
導入後、実通信における、WAFのパフォーマンスとセキュリティイベントをモニタリングします。WAFのサービスにより、ログの保管期間は異なりますが、1-2週間程度が保存期間であることが多いため、その期間に絞ったログを精査します。観点としては、正しく攻撃を検知していることと、誤検知、主にFalse Positive(偽陽性)がないことを確認します。
この時、仮にFalse Positiveを確認した場合は、例外処理のルール、あるいは、正常通信の見直しが必要になってきます。前者については、「特定の正常通信に対してはルールを適用させない」といった処理です。後者については、WAFが攻撃として検知しているということは、その通信の処理自体に問題がある可能性もあります。例えば、HTTPのリクエストがRFCに則っていなかった、などです。その場合は、WAFではなく、システム側の改修を検討する必要があります。
モニタリングと分析の結果、誤検知などもなく、WAFが正常に動作しているようであれば、「検知」モードから「遮断」モードへ移行します。このタイミングで、WAFは攻撃と判断した通信を遮断し、システムを攻撃から保護します。
セキュリティの脅威は常に進化し続けるため、WAFの設定とポリシーを定期的に見直し、更新する必要があります。
また、新しいWebアプリケーションをデプロイする際にも、上記Stepに倣い、「検知」モードで導入し、モニタリングで問題がないことを確認後、「遮断」モードへ移行します。
おわりに
本記事では、クラウドWAFの一般的な導入方法を紹介させていただきました。自社システムに適したWAFを選んでいただき、セキュアなシステムを開発いただければと思います。
本記事がクラウドWAFの導入の指針になれば幸いです。特に重要なのは、「遮断モード」ではなく、「検知」モードで初期導入を行う点です。そのため、WAFの導入の際は、モニタリングと分析のリードタイムを含めることをお忘れなきよう、ご注意ください。
WAF入門の記事一覧ページはこちらです。読み返したい場合は、ブックマークをお願いいたします。