Cloudflare Zero Trustのポリシー適用の順序についてまとめてみた
Cloudflare Zero Trustで作成できるポリシーについて
Cloudflare Zero Trustでは、様々なポリシーを作成することで細かなアクセス制御を行うことが可能です。しかしポリシーをいくつも作成しているうちに、「先に作成したポリシーが原因で思った通りの挙動をしてくれない。」といった事象に遭遇することが何度かありました。
そこで今回は、それぞれのポリシーがどのような役割を持っているのか、どの様な順番で適用されるのかについて簡単にまとめてみました。まずはどのようなポリシーを作成できるのかについて紹介していきます。
また、今回ご紹介したポリシーに基づいてアクセス制御がされたか否かをログで確認することが可能です。ログの見方については下記ブログで詳しく紹介しています。
Web Gateway ポリシー
こちらはCloudflare Gatewayに関連するポリシーです。DNS、ネットワーク、HTTP、および送信トラフィックを検査するためのポリシーです。これらのポリシーに引っかかりブロックされたサイトはユーザがアクセスできないようになります。特定のサイトだけではなくCloudflareが分類したWebサイトのカテゴリに基づいてサイトをブロックすることも可能です。（ショッピングサイトとカテゴリされたものや、暴力的なサイトだと判断されたものをブロックするなど）
- DNSポリシー - DNSクエリを検査し、ポリシーでブロックされた特定のドメインに対するクエリの解決を拒否することでユーザーがドメインにアクセスすることを阻止する。ポリシーにはブロックしたいドメインもしくはIPアドレスを記載する。（DNSフィルタリング）
- ネットワークポリシー - TCP/UDP/GREパケットを検査する。非HTTPリソースを含む特定のポートへのへのアクセスをユーザーごとに制御することが可能。
- HTTPポリシー - HTTPリクエストを検査することで、ドメイン自体だけではなく、特定のURLの読み込みをブロックすることが可能。DNSフィルタリングより詳細なフィルタリングが可能。
- Egress ポリシー - 通常、Cloudflare Gateway経由でインターネットに接続した場合、トラフィックにはCloudflareの送信元IPが割り当てられるようになっている。これを各アカウント専用の一意の静的IPが割り当てられるように変更し、どのEgress IPをいつ使用するのかを制御できるポリシー。（Enterpriseプランのみ）
ポリシーの適用順序
各ポリシーの優先順位は以下の通りです。
- DNSポリシー
- HTTPポリシー
- ネットワークポリシー
DNSポリシーはスタンドアローンなポリシーです。DNSポリシーでサイトをブロックした場合でも、それに対応するHTTPポリシーを作成していない時、ユーザーがそのサイトのIPアドレスを知っている場合はサイトにアクセスできてしまいます。 HTTPポリシーとネットワークポリシーにおいては、HTTPポリシーの方が優先されるため、例えばHTTPポリシーでブロックされた送信元IPはネットワークポリシーで許可されていたとしてもブロックされるようになっています。
Cloudflare Zero TrustではHTTP/3トラフィックの検査にも対応していますが、この場合は優先順位が少し変わり、以下の通りとなります。
- DNSポリシー
- ネットワークポリシー
- HTTPポリシー
各ポリシーごとの適用順序についてご紹介する前に、下記画像のようにUI上に表示されているポリシーの順番について少しお話しします。
ポリシーの左側の数字はポリシーの優先順位を示しています。最も低い値が最優先ポリシーとなっています。ドラッグアンドドロップで簡単に順序を入れ替えることが可能です。
Gatewayではこのポリシー優先順位に沿ってサイトを評価していきますが、途中でサイトがAllow/Blockポリシーに一致した場合は評価がその時点で停止します。つまり後続のポリシーでは決定を上書きできないということです。
そのため、具体的なポリシーはリストの先頭の方に記載し、より一般的なポリシーを後ろに持ってくると良いです。
DNSポリシー
DNSポリシーのSelectorの項目はそれぞれDNS解決前に評価されれるか、DNS解決後に評価されるか評価段階が異なってきます。
そのため、まずDNSポリシーはポリシーの優先順位が高いものから、評価段階順にポリシーを確認していくことになります。
少しややこしいので、例を使って説明すると、
- Resolved Continentに基づいたポリシー（クエリが解決される大陸に基づいたフィルター。評価段階はDNS解決後
- Content Categoriesに基づいたポリシー(Cloudflareによってカテゴライズされた特定のコンテンツに基づいたフィルター。評価段階はDNS解決前)
といった２つのポリシーがあった場合には、ポリシーの優先順位だけで見るとResolved Continentに基づいたポリシーが先に評価されるように見えますが、実際にはDNS解決前に評価されるContent Categoriesに基づいたポリシーが先に評価されるということになります。
また、注意点として、一つのポリシーにDNS解決前に評価されるSelector項目と、DNS解決後に評価されるSelectorの両方があった場合、GatewayはDNS解決後にポリシー全体を評価します。
HTTPポリシー
HTTPポリシーはActionsのタイプとポリシーの優先順位の二つに基づいてポリシーを確認していくことになります。 Actionタイプの優先順位としては以下の通りです。
- Do Not Inspect ポリシー（検査をしない）
- Isolate ポリシー
- Allow/Block/Do Not Scan ポリシー
Do Not Inspectポリシーは常に他のポリシーよりも優先されるようになっています。これはGatewayが最初に復号化を行うべきかどうかを判断するためです。 Do Not Inspectポリシーにサイトが一致する場合はサイトはGatewayの通貨を自動的に許可される為、他のすべてのポリシーが適用されなくなります。
ただ、例外としてクライアントレスで行うBlowser Isorationの場合はDo Not Inspectであっても暗黙的にブラウザの分離が行われるようになっているので注意しましょう。
続いてGatewayはIsolateポリシーを評価し、分離すべきサイトを判断します。最後にAllow/Block/Do Not Scanのポリシーについて評価し、これらのポリシーはブラウザ分離が行われたか否かに関係なく適用されるという順序になります。
ネットワークポリシー
ネットワークポリシーに関しては単純にポリシーの優先順位に従って評価がされるようになっています。
上記で説明した内容を図解したモノが以下になります。
Access ポリシー
こちらはCloudflareに追加したアプリケーションに対して、アクセスできるユーザーを決定するためのポリシーです。
- Allow - 特定の基準を満たすユーザーがAccess配下のアプリケーションにアクセスすることを許可するポリシー。ポリシーにExcludeルールが含まれている場合は、その定義を満たすユーザはアクセスが出来なくなる。
- Block - このポリシーに含まれるユーザーがAccessガイアかのアプリケーションにアクセスできなくなるポリシー。Excludeルールが含まれている場合は、その定義を満たすユーザー以外をブロックする。
- Bypass - 定義されたルール基準を満たすトラフィックに対してのアクセス制限を無効にするポリシー。会社のオフィス等の信頼できる環境からは認証なしでアクセスできるような設定が可能。（Zerro Trust的な観点で見ると非推奨）
- Service Auth - サービストークンや相互TLSといったIdPログインを必要としない承認フローを経てアクセスができるようにするポリシー。
ポリシーの適用順序
AccessポリシーはActionのタイプとUI上に表示されている数字（ポリシーの優先順位）に基づいて、適用順序が決まります。
Actionタイプ別の優先順位としては、Bypass/Service Auth > Alow/Blockとなります。
Bypass/Service Authのポリシーを上から順番に適用した後に、Alow/Blockポリシーを上から順番に適用する形です。
どこかでAlowポリシーもしくはBlockポリシーに一致した場合は後続のポリシーでは決定を上書きすることが出来ないため、Alow/Blockポリシーに関しては優先度の高いポリシーから順番に作成していきましょう。
- Aを許可
- Bをブロック
- Cをバイパス
- Ⅾをブロック
上記のような場合はCをバイパス > Aを許可 > Bをブロック > Dをブロックの順番でポリシーが適用されます。
Browser Isoration ポリシー
Webコンテンツの読み込み/実行をユーザーデバイス上ではなくユーザーから分離されたブラウザで行うためのポリシーです。仮にWebコンテンツが有害なものであっても、リモートブラウザで実行されるためユーザーのデバイスや使用しているネットワークに直接被害が及ばないというのがメリットとなります。
こちらの機能に関しては、下記ブログで詳しくご紹介しています。
こちらのポリシーはHTTPポリシーを通じて有効にすることが可能なため適用順序はHTTPポリシーのものと同様です。
Date Loss Prevention (DLP) ポリシー
Date Loss Prevention(DLP)ポリシーは、は直訳するとデータ損失防止ポリシーとなります。機密データ（クレジットカード番号や社会保障番号、社外秘のドキュメントなど）の存在を確認し、保護することが可能なポリシーです。HTTPポリシーと紐づけることで、該当の情報が、WebのトラフィックやSaaSアプリケーションに保存した情報に含まれていないかを調べることが可能です。
こちらの機能に関しては下記ブログで詳しく説明しています。
HTTPポリシーと紐づけて使用するポリシーのため、適用順序はHTTPポリシーのものと同じです。
ドメインのカテゴリ
Gateway ポリシーではCloudflare Raderによって分類されたカテゴリのコンテンツをすべてブロックするようなことが可能です。
また、Cloudflare Raderでは特定のドメインやURLがどのカテゴリーに属しているのかを調べることも可能なため、ポリシー作成の際に迷った場合はこちらを活用するのも良いと思います。
どの様なカテゴリが存在するのか詳しくはこちらのドキュメントをご覧ください。
リストについて
GatewayポリシーやAccessポリシーを作成する際に参照するURL、ホスト名、その他のエントリのリストを作成することが出来ます。複数の項目に対してルールを適用したい場合はこの機能を使うと便利です。
CSVファイルをアップロードしてリストを作成する方法と、手動でリストを作成する方法があります。
リストの作成方法については下記ブログのシリアルナンバーリストの作成の項目でも紹介しています。
まとめ
今回はCloudflare Zero Trustでポリシー作成をする際に念頭に入れておきたい基礎知識とポリシーの適用順序についてまとめてみました。細かなアクセス制御を行うことが可能なのはCloudflare Zero Trustの特徴の一つです。
組織内でポリシーを作成する場合は複数名が関わる場合も多いと思います。本ブログに記載の基本情報とCloudflareのポリシーに関してのドキュメントの内容を把握しておくと少しポリシーの作成が楽になるかもしれません。
