ポリシー

Cloudflare Access は、設定した Access ポリシーを適用して、誰がアプリケーションに到達できるかを決めます。

すべての Access ポリシーは、次の 4 つの構成要素でできています。

• Actions: ユーザーがポリシーに一致したときの動作（Allow、Block、Bypass、Service Auth）
• Rule types: 条件の組み合わせ方（Include、Require、Exclude）
• Selectors: 確認する属性（メールドメイン、国、デバイスポスチャなど）
• Values: 照合する具体的な値（@example.com など）

アクションでは、特定のユーザーまたはユーザーグループに権限を与えるか拒否するかを決めます。ポリシーごとに設定できるアクションは 1 つだけです。

Cloudflare Access の Allow アクションは、一定の条件を満たすユーザーが Access 配下のアプリケーションに到達することを許可します。

次の表は、IdP で検証した @example.com のメールアドレスを持つユーザーなら誰でもアプリケーションに到達できる、Cloudflare Access の Allow ポリシーの例です。

同じポリシーアクションに Require ルールを追加すると、追加の確認を強制できます。Exclude ルールがある場合、その定義に当てはまるユーザーはアプリケーションに到達できません。

たとえば、次の表は Require と Exclude ルール付きの Allow ポリシーです。この設定では、IdP で検証した @team.com のメールアドレスを持つポルトガルのユーザーなら誰でもアプリケーションに到達できます。ただし user-1 と user-2 は除きます。

Cloudflare Access の Block アクションは、一定の条件を満たすユーザーがアプリケーションに到達することを防ぎます。たとえば、次の表は、承認済み IP のリスト にないロシアの送信元 IP からのリクエストをブロックする Block ポリシーです。

Block ポリシーは、Allow ポリシー と組み合わせて、Allow ポリシーの例外を切り出す用途に向いています。Access はデフォルトで拒否するため、Block ポリシーに一致しないユーザーでも、Allow ポリシーに明示的に一致しなければアクセスは拒否されます。

Cloudflare Access の Bypass アクションは、特定のトラフィックに対する Access の適用を無効にします。

Bypass アクションは、定義したルール条件に合うトラフィックに対する Access の適用をすべて無効にします。Bypass は通常、特定のエンドポイントを公開する必要があるアプリケーションで使います。

たとえば、一部のアプリケーションでは /admin 配下のエンドポイントを公開ルーティング可能にする必要があります。この場合、ドメイン test.example.com/admin/<your-url> 向けの Access アプリケーションを作成し、次の表の Bypass ポリシーを追加できます。

Zero Trust セキュリティモデルの一環として、社内アプリケーションへの恒久的な直接アクセスを Bypass で与えることは Cloudflare は推奨しません。社内ネットワーク上の従業員に、つなぎ目のない安全なアクセスを提供するには、Cloudflare Tunnel で プライベートネットワークを接続 し、ユーザーを Cloudflare One Client 経由で接続させます。

デバイスポスチャチェック ルールを含む Bypass ポリシーは、次の場合に機能しません。

• Access で保護しているゾーンで Zaraz が有効
• Worker がリクエストを傍受している

これらの制限を回避して Access をバイパスするには、ポリシーアクションを Service Auth に変更することを推奨します。

Cloudflare Access の Service Auth ルールは、アイデンティティプロバイダー（IdP）へのログインを必要としない認証フロー（サービストークンや mutual TLS など）を強制します。

次の表は、Cloudflare Access の Service Auth ポリシー設定の例です。

ルールタイプは論理演算子のように働き、条件をどう組み合わせてユーザーを評価するかを決めます。すべての Access ポリシーには、少なくとも 1 つの Include ルールが必要です。この Include ルールが、アプリケーションにアクセスできる候補ユーザーの初期集合を定義します。そのあと Exclude と Require ルールを追加して範囲を絞れます。

Cloudflare Access の Include ルールは、OR 論理演算子に似ています。Include ルールが複数ある場合、ユーザーはいずれか 1 つの条件を満たせば十分です。

Cloudflare Access の Exclude ルールは、NOT 論理演算子のように働きます。いずれかの除外条件に当てはまるユーザーは、アプリケーションへのアクセスを許可されません。

Cloudflare Access の Require ルールは、AND 論理演算子のように働きます。ユーザーは、指定した Require ルールをすべて満たさないとアクセスを許可されません。

デフォルトでは、Require ルールに追加した値は AND 演算子で連結されます。たとえば、正社員と請負業者の両方にアプリケーションへのアクセスを許可し、かつ特定の国（ポルトガルと米国）にいる人だけに限定したいとします。次の設定でルールを作ると、次のようになります。

このポリシーは、ユーザーが同時に米国 AND ポルトガルにいて、かつメールアドレスが @cloudflare.com AND @contractors.com の両方で終わることを要求します。そのため、誰もアプリケーションにアクセスできません。

対処: ルールグループ を使い、Require ルール内の AND 論理を OR 論理に変換します。

1. ポルトガル OR 米国にいるユーザーを含む、Country requirements というルールグループを作成します。

   Rule type	Selector	Value
   Include	Country	United States, Portugal

2. そのルールグループを必須にし、かつ @cloudflare.com OR @contractors.com で終わるメールのユーザーを含むポリシーを作成します。

   Action	Rule type	Selector	Value
   Allow	Require	Rule group	Country requirements
   	Include	Emails ending in	@cloudflare.com, @contractors.com

Cloudflare Access ポリシーにルールを追加するとき、ユーザーに満たしてほしい条件、つまり属性の指定を求められます。これらの属性は、SaaS、セルフホスト、非 HTTP を含む、すべての Access アプリケーションタイプで使えます。

非アイデンティティ属性は継続的にポーリングされます。つまり、ユーザーセッション 中の変化を、新しい HTTP リクエストごとに評価します。SCIM プロビジョニング を設定している場合、IdP でユーザーを取り消したとき、または IdP グループ所属を更新したときに、Access ですべての属性を再証明させることができます。

¹ SaaS アプリケーションでは、Access がポリシーを適用できるのは初回サインオン時と、SaaS セッションの再発行時だけです。ユーザーが SaaS アプリに認証したあとのセッション管理は、SaaS アプリ側の管轄になります。

接続コンテキスト設定では、アクセスを許可したあとに、ユーザーがアプリケーションとどうやり取りするかを制御できます。セレクター が誰がアプリケーションにアクセスできるかを決めるのに対し、接続コンテキスト設定はセッション中にユーザーが取れる操作を決めます。使える接続コンテキスト設定は、アプリケーションタイプによって異なります。

接続コンテキストはポリシーごとに設定できるため、ユーザーグループごとに異なる権限を与えられます。たとえば、正社員にはリモート RDP セッションからのデータコピーを許可し、請負業者は読み取り専用に制限できます。

Cloudflare Access ポリシーは、アクションの種類と、設定した順序に基づいて評価されます。Bypass と Service Auth ポリシーが先に、UI 上の上から下の順で評価されます。そのあと、Block と Allow ポリシーが上から下の順で評価されます。

たとえば、ポリシーが次の並びだとします。

• Allow A
• Block B
• Service Auth C
• Bypass D
• Allow E

実行順は次のとおりです。Service Auth C > Bypass D > Allow A > Block B > Allow E。ユーザーが Allow または Block ポリシーに一致すると評価は止まり、それ以降のポリシーで決定を上書きできません。

Allow ポリシーに次のいずれかのルールを追加すると、誰でもアプリケーションにアクセスできるようになります。

次の表は、全員を含む Cloudflare Access ポリシーです。

次の表は、有効なメールログイン方式を持つすべてのユーザーを含む Cloudflare Access ポリシーです。

API と Terraform を使うと、Access ポリシーと設定をプログラムから管理できます。