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