セキュリティ境界は、かつての「城と堀」型の導入に比べ、はっきりしなくなっています。固定された境界の中では、データセンター内の単一の Web Application Firewall（WAF）導入で複数アプリケーションを守りやすかったです。いまはこの方法では柔軟性が足りません。アプリケーションとサービスが従来のデータセンターの外へ広がるためです。ハイブリッド構成や SaaS の採用には妥当な理由が多く、そのシナリオをカバーするよう WAF の考え方を更新する価値があります。
クラウドベースの WAF は、オンプレミス、クラウドの IaaS / PaaS、ハイブリッド環境に展開されたアプリケーションとサービスを、柔軟な導入モデルでカバーし、境界の拡大を抑えられます。
一方、クラウドベース WAF の実装を誤ると、セキュリティポリシーの断片化と重複が起き、保守と監視の両方でオーバーヘッドが増えます。非効率の経済的影響に加え、セキュリティ態勢そのものも低下します。最終的には、シナリオに応じたさまざまな重大度のインシデントにつながり得ます。
本デザインガイドは、複数のアプリケーション、ドメイン、サービスにまたがり、ハイブリッド環境へ展開できる、柔軟なクラウドベース WAF 構成を実装したいセキュリティ / ネットワーク管理者およびアーキテクト向けです。
Cloudflare は、高度に設定可能なクラウドベースの Web Application Firewall（WAF）を含む、包括的な Application Security & Performance ソリューションを提供します。
このガイドでは次を学びます。
- Cloudflare WAF の導入と、共通ルールのくくり出し方
- 複数アプリケーションへ共通構成を簡単に適用する方法
- 必要なときに例外と個別構成をデプロイする方法
- Cloudflare WAF 導入時のベストプラクティス
多くの Cloudflare 顧客は、1 つのアカウント（または Enterprise Organization）内に複数の Cloudflare ゾーンをオンボードします。各ゾーンは通常セカンドレベルドメイン（example.com など）に対応し、そのサブドメイン（web1.example.com、web2.example.com など）はそのゾーンで扱います。
この構成では、Cloudflare は DNS ベースのリバースプロキシです。各 Fully Qualified Domain Name（FQDN）をゾーンに設定し、顧客のオリジンサーバーを指します。オリジンの場所について、Cloudflare は特別な区別をしません。オンプレミス、クラウド上の仮想マシン、第三者の SaaS のいずれでも構いません。
複数の FQDN が、IP アドレスや別の FQDN などで到達する共有 Web インフラを指すこともよくあります。一部の FQDN は専用オリジンや外部 SaaS エンドポイントを指す場合もあります。
多くの場合、顧客は 1 つのアカウント内で多数のゾーン（example.com、example.org、myappexample.com など）と、各ゾーン内の多数の FQDN を管理します。複数ゾーンにまたがる多くの FQDN が、背後では共有 Web インフラを指すこともよくあります。
たとえば、次のような状況です。
- Web アプリケーションの大半は、新たに導入した社内コンテンツ管理システム（CMS）上で動く
- 独自スタックで動くレガシー Web アプリケーションもある
- 一部のアプリケーションはパートナーが管理する専用インフラ上にある
シナリオ例を次の図に示します。
WAF 設定の観点では、次の要件が浮かびます。
- 大半のアプリケーションの前に、標準の WAF ルール構成を簡単にデプロイできること
- 誤検知が出やすいレガシーアプリケーションの前では、デプロイするルールを細かく調整できること
- 上記に当てはまらないすべての Web トラフィックに、Cloudflare のデフォルト WAF 設定が必ず当たる「キャッチオール」構成があること
- アプリケーションの追加・削除に対し、初期設定と継続保守の手間を最小にすること
本ガイドでは、Cloudflare WAF の動作と、上記のアーキテクチャ要件を満たすためのツールを確認します。
Cloudflare WAF はゾーンレベルとアカウントレベルの両方で動作します。Custom Rules、Rate Limiting Rules、Managed Rules に対応する異なる WAF フェーズ（http_request_firewall_custom、http_ratelimit、http_request_firewall_managed）があります。これらのフェーズはアカウントとゾーンの両方に存在します。詳細は こちらのドキュメント を参照してください。アカウントのルールセットはゾーンのルールセットより先に評価される点が重要です。
本ガイドでは、上記のシナリオと WAF 要件を基に進めます。1 つの Cloudflare アカウント（または Enterprise Organization）に、2 つのセカンドレベルドメインがオンボードされているとします。
2 つのドメインにまたがる 6 つの FQDN の背後に 6 つのアプリケーションがあるとします。これらにはベースラインの WAF セキュリティ態勢を適用したいです。ただし 6 つのうち 2 つは特別な扱いが必要です。
- 1 つは誤検知が出やすいレガシーアプリケーションサーバー上にある
- もう 1 つは第三者のインフラ上に実装されている
シナリオを次に示します。
例として Cloudflare Managed Ruleset を使います。同じ考え方は、ほかの Cloudflare Managed Rules、Rate Limiting Rules、Custom Rules にも使えます。
web1.example.com、web2.example.com、web3.example.com、web5.example.orgには、Cloudflare がすでに調整したデフォルトの WAF Managed Ruleset を適用します。special4.example.comには、レガシーアプリケーションで誤検知を起こすルールをいくつか特定済みのため、デフォルト Managed Ruleset の別サブセットを適用します。special6.example.orgには、第三者の新規アプリケーションのため、保護方針の評価を始める段階として、Managed Ruleset をログモードで適用します。
次の方針を取れます。
- アカウントレベルで Cloudflare Managed Ruleset を 1 インスタンスデプロイし、それを必要とする 4 つの FQDN 向けの共通ルールセットにします。ゾーンレベルで同じ構成を 4 回複製するより、設定と保守が簡単です。
special4.example.comとspecial6.example.orgには、各 FQDN 背後のアプリケーションに必要な調整を加えた Managed Ruleset を、さらに 2 インスタンスデプロイします。
実際には、アカウントレベル WAF の Managed rulesets で Managed Ruleset を 3 インスタンスデプロイします。各インスタンスは独自の Custom Filter Expression を持ち、HTTPS リクエストのホスト名がリスト内の FQDN に属するかを確認します。
- 最初のリスト（
web1.example.com、web2.example.com、web3.example.com、web5.example.org）には、Cloudflare Managed Ruleset をDefault構成で適用します。 special4.example.comでは同じルールセットをDefaultモードでデプロイしますが、誤検知を起こす特定ルールは無効にします。これはダッシュボードまたは API の Rule Overrides で行えます。実例はこちら です。special6.example.orgでは最初のリストと同様の設定を繰り返し、今回は Managed Ruleset インスタンスをDefaultではなくLogモードにします。
完成した構成を次の図に示します。
この設定で、アプリケーショングループごとに調整した Managed Ruleset が 3 インスタンスになります。
将来保護するアプリケーションを追加する場合は、フィルター式に新しい FQDN を足すだけで十分です。多くは、推奨の Cloudflare 構成を使う標準ルールセットインスタンスに追加します。別のよくある戦略は、新規アプリケーションを Log モードインスタンスに追加し、監視したうえで Default モードのルールセット、または必要ならより個別のバリエーションへ移行することです。
ルールセット（特に Managed Ruleset）は、Cloudflare がすでに誤検知を避けるよう細かく調整しています。大半のアプリケーションでは、ほとんど、またはまったく調整せずにデプロイできます。つまり、多くの場合はデフォルトのルールセット構成で直接運用し、必要なときだけカスタマイズします。
このシナリオなら、Exceptions を使い、上記の設定を次のように簡略化できます。
- まず、ルールセットを
Logモードでデプロイし、特別な扱いが必要なアプリケーション（FQDN）を特定します。たとえばテストの結果、special1.example.comでは Managed Rules の小さなセットを無効にし、special2.example.orgでは似ているが異なるセットを無効にする必要があるとします。 - 各 FQDN にマッチするフィルター付きのマネージド Exceptions を 2 つデプロイし、Managed Ruleset からそれらのルールをスキップします。
- 最後に、それ以外すべてにマッチする Default 版の Managed Ruleset をデプロイし、Cloudflare 推奨設定を実行します。
例外が少なく、初期キャリブレーションで Cloudflare の誤検知最小化が自社環境でも妥当だと確認できた場合、この方法の方が簡単です。
Cloudflare では ホスト名のリスト を作成できます。この場合、フィルター式をそのリスト変数を参照するよう変更できます。
リストを直接更新し、複数のルールセットで再利用できます。たとえば同じリストを Cloudflare Managed Rules、OWASP Ruleset、Rate Limiting に使えます。フィルターは リストを直接参照するため、構成がきれいで保守しやすくなります。
リストを使うと、評価順の最後に実行する「キャッチオールルール」も導入しやすくなります。たとえば、HTTPS リクエストのホストがどのリストにも含まれない場合に Default の Cloudflare Managed Ruleset を実装できます。これにより、アプリケーションが誤ってリストに追加されなくても、デフォルトの WAF Managed Rules 構成が常に適用されます。
WAF 構成は API と Terraform ↗ で管理できます。ゾーンと FQDN がさらに多い場合や、ダッシュボード上の繰り返し作業を避けたいときに特に有用です。
たとえば、Rulesets と Lists を定義するデフォルトの Terraform 構成ファイルを作り、ダッシュボードを変更せずに保守・適用できます。
可能な限り、特に 1 つのゾーンに複数の DNS レコードがありそれぞれ個別構成が必要な場合は、アカウントレベルで構成を保つことを Cloudflare は推奨します。
ゾーンレベル WAF では、各ルールセット（Managed Rules、OWASP Rules など）を 1 インスタンスしかデプロイできず、特別なシナリオの扱いはより複雑、または不可能です。
上記の Managed Rules の考え方は、Custom Rulesets と Rate Limiting にも適用でき、手元のすべての WAF セキュリティツールに柔軟性を広げられます。
単一ゾーン固有の構成でなければ、アカウントレベルでの実装を Cloudflare は推奨します。
詳細は次のリソースを参照してください。
本デザインガイドでは、複数のアプリケーションとドメインをカバーする柔軟な WAF 構成の実装方法を示しました。この方針により、WAF セキュリティ構成のデプロイ、保守、更新の手間を減らせます。