基礎から理解するWAF入門: 第5回 WAFの導入方法について

本シリーズ最終回となるこの記事では、クラウド型WAFの導入方法について紹介します。クラウド型WAFの導入は手順自体は簡単ですが、誤検知が起こるリスクがあるため、それをケアしながら導入を進める必要があります。

目次

WAFの導入手順

実際にWAFの導入手順を見ていきましょう。大まかな流れは以下の7Stepです。

STEP
WAFの選定・契約

まずはWAFの選定を行います。考慮するポイントは企業によって様々であり、具体的なビジネス要件やセキュリティニーズに応じて詳細な検討が必要になるかと思いますが、一般的な要素として以下のものが上げられます。

  • セキュリティ機能と性能
  • 使いやすさと管理
  • 統合の容易性と互換性
  • コンプライアンスと規制準拠
  • サポートと信頼性
  • コストと価格設定モデル

これらの要素から優先度を決め、自社システムに適したWAFを選定します。選定の際には、必要に応じてPoC(Proof of Concept)を行うことで、製品に対する認識のズレを解消・軽減することができます。

STEP
WAFの構築

利用するWAFが決定し、契約が完了したら、WAFの初期構築を行います。これには、ルールセットの選択、防御ポリシーの構成、ホワイトリストやブラックリストの設定が含まれます。こう見ると複雑なようにも思えますが、多くのクラウドWAFでは、主要な攻撃・脆弱性から守るためのマネージドルール・ポリシー(WAFベンダーが管理している、ベストプラクティスなルールやポリシー郡)が用意されています。

そのため、まずは利用するクラウドベンダーが定めるベストプラクティスを中心に設計し、設定を行うのが良いかと思います。プラスアルファで必要に応じ、特定のアプリケーションやビジネスの要件に合わせて、カスタムルールを設定できると望ましいです。

STEP
動作検証

構築が一段落したら、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からの名前解決で取得可能)。

STEP
導入

動作検証で問題がないようであれば、WAFを導入していきます。ここで大事なポイントは、初期導入時では、WAFのアクションを「遮断」ではなく、「検知」モードとすることです。アクションというのは、WAFのルールやポリシーにマッチした際の、挙動を意味しています。例えば、以下のような通信に対して、SQLインジェクション攻撃としてマッチしたとします。

http://www.bloomblock.net/account/serach?accountid=1234or1=1

この時、一般的なWAFの動作は下記の2つです。

  • 検知(検知のログ出力のみ)
  • 遮断(検知のログ出力+通信ブロック)

事前の動作検証において、全ての通信パターンを網羅するということは不可能です。正常通信に対する誤検知を防ぐため、「検知」モードで初期導入し、次のステップであるモニタリングを経て、最終的に「遮断」モードへ移行します。

モニタリングを行わず「遮断」モードで導入を行うと、正常通信に対する誤検知(False Positive)が発生し、結果的にユーザトラフィックに影響を与えてしまう可能性があります。

WAF導入の方法ですが、CDNと同様(実際、WAFはCDNのサービスと一緒に導入することが多いです)、DNSの設定を変更して、ユーザトラフィックをWAFにルーティングさせます。

STEP
モニタリングと分析

導入後、実通信における、WAFのパフォーマンスとセキュリティイベントをモニタリングします。WAFのサービスにより、ログの保管期間は異なりますが、1-2週間程度が保存期間であることが多いため、その期間に絞ったログを精査します。観点としては、正しく攻撃を検知していることと、誤検知、主にFalse Positive(偽陽性)がないことを確認します。

この時、仮にFalse Positiveを確認した場合は、例外処理のルール、あるいは、正常通信の見直しが必要になってきます。前者については、「特定の正常通信に対してはルールを適用させない」といった処理です。後者については、WAFが攻撃として検知しているということは、その通信の処理自体に問題がある可能性もあります。例えば、HTTPのリクエストがRFCに則っていなかった、などです。その場合は、WAFではなく、システム側の改修を検討する必要があります。

STEP
「遮断」アクション有効化

モニタリングと分析の結果、誤検知などもなく、WAFが正常に動作しているようであれば、「検知」モードから「遮断」モードへ移行します。このタイミングで、WAFは攻撃と判断した通信を遮断し、システムを攻撃から保護します。

STEP
定期レビューとメンテナンス

セキュリティの脅威は常に進化し続けるため、WAFの設定とポリシーを定期的に見直し、更新する必要があります。

また、新しいWebアプリケーションをデプロイする際にも、上記Stepに倣い、「検知」モードで導入し、モニタリングで問題がないことを確認後、「遮断」モードへ移行します。

おわりに

本記事では、クラウドWAFの一般的な導入方法を紹介させていただきました。自社システムに適したWAFを選んでいただき、セキュアなシステムを開発いただければと思います。

本記事がクラウドWAFの導入の指針になれば幸いです。特に重要なのは、「遮断モード」ではなく、「検知」モードで初期導入を行う点です。そのため、WAFの導入の際は、モニタリングと分析のリードタイムを含めることをお忘れなきよう、ご注意ください。

WAF入門の記事一覧ページはこちらです。読み返したい場合は、ブックマークをお願いいたします。

あわせて読みたい
基礎から理解するWAF入門 記事一覧 近年、WAF(Web Application Firewall)の需要は着実に増加しています。Webアプリケーション攻撃の頻度や複雑さは年々増しており、攻撃からウェブアプリケーションを保...
よかったらシェアしてね!

CD

目次