アクセス
Cloudflare Accessは、設定したアクセスポリシーを適用することによって、誰がアプリケーションにアクセスできるかを決定します。
アクセスポリシーは、アクションと、そのアクションの範囲を決定するルールで構成されます。ルールを構築するには、ルールタイプ、セレクタ、およびセレクタの値を選択する必要があります。
アクションを使用すると、特定のユーザーまたはユーザーグループに対して権限を付与または拒否できます。ポリシーごとに1つのアクションのみを設定できます。
許可アクションは、特定の条件を満たすユーザーがAccessの背後にあるアプリケーションにアクセスできるようにします。
以下の例では、IdPに対して検証された@example.comのメールアドレスを持つユーザーがアプリケーションにアクセスできるようにします：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| 許可 | 含む | メールアドレスの末尾: | @example.com |
同じポリシーアクションにRequireルールを追加して、追加のチェックを強制することができます。最後に、ポリシーにExcludeルールが含まれている場合、その定義を満たすユーザーはアプリケーションにアクセスできなくなります。
例えば、この2番目の構成では、IdPに対して検証された@team.comのメールアドレスを持つポルトガルのユーザーがアプリケーションにアクセスできるようにしますが、user-1とuser-2は除外されます：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| 許可 | 含む | 国 | ポルトガル |
| 必要 | メールアドレスの末尾 | @team.com | |
| 除外 | メール | user-1@team.com, user-2@team.com |
ブロックアクションは、ユーザーがAccessの背後にあるアプリケーションにアクセスするのを防ぎます。
例えば、この構成では、user-1@team.comからのリクエストを除いて、アプリケーションへのすべてのリクエストをブロックします：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| ブロック | 含む | すべての人 | すべての人 |
| 除外 | メール | user-1@team.com |
バイパスアクションは、定義されたルール基準を満たすトラフィックに対するAccessの強制を無効にします。バイパスは、特定のエンドポイントを公開する必要があるアプリケーションを有効にするために通常使用されます。例えば、いくつかのアプリケーションには、公開可能である必要がある/adminルートの下にエンドポイントがあります。この状況では、test.example.com/admin/<your-url>のドメインに対してAccessアプリケーションを作成し、次のバイパスポリシーを追加できます：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| バイパス | 含む | すべての人 | すべての人 |
ゼロトラストセキュリティモデルを実装する一環として、内部アプリケーションへの直接的な恒久的アクセスを付与するためにバイパスを使用することは推奨しません。ネットワーク内の従業員にシームレスで安全なアクセスを提供するには、Cloudflare Tunnelを使用してプライベートネットワークに接続し、ユーザーがWARPを通じて接続できるようにします。
サービス認証ルールは、サービストークンや相互TLSなど、アイデンティティプロバイダーIdPのログインを必要としない認証フローを強制します。
| アクション | ルールタイプ | セレクタ |
|---|---|---|
| サービス認証 | 含む | 有効な証明書 |
ルールは論理演算子のように機能します。これにより、ポリシーが影響を与えるユーザーのカテゴリを定義できます。すべてのAccessポリシーには、含むルールが含まれている必要があります。これが、アプリケーションにアクセスできる適格ユーザーの初期プールを定義します。その後、除外および必要ルールを追加して、これらのユーザーに特定のポリシーを強制できます。
含むルールは、OR論理演算子に似ています。複数の含むルールが指定されている場合、ユーザーは1つの基準を満たす必要があります。
除外ルールは、NOT論理演算子のように機能します。除外基準を満たすユーザーは、アプリケーションへのアクセスを許可されません。
必要ルールは、AND論理演算子のように機能します。ユーザーは、アクセスを許可されるためにすべての指定された必要ルールを満たす必要があります。
Accessポリシーのために必要ルールを設定する際には、ルールに追加する値はAND演算子によって連結されることを考慮してください。例えば、フルタイムの従業員と契約者の両方にアプリケーションへのアクセスを付与したい場合、かつ特定の国、例えばポルトガルとアメリカに拠点を置く者のみを対象とする場合、次のような構成のルールを設定したとします：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| 許可 | 必要 | メールアドレスの末尾 | @cloudflare.com, @contractors.com |
| 必要 | 国 | アメリカ合衆国, ポルトガル |
このポリシーは、アメリカ合衆国とポルトガルの両方からアプリケーションにアクセスし、かつ@cloudflare.comと@contractors.comの両方のメールアドレスを持つ人にのみアクセスを許可します。したがって、誰もアプリケーションにアクセスできなくなります。
代わりに、Accessグループを使用してこのニーズに対処できます。まず、ポルトガルまたはアメリカにいるユーザーを含むグループ（これをMy Access Groupと呼びます）を設定できます：
| ルールタイプ | セレクタ | 値 |
|---|---|---|
| 含む | 国 | アメリカ合衆国, ポルトガル |
次に、グループを必要とし、@cloudflare.comまたは@contractors.comで終わるメールアドレスを持つユーザーも含むアプリケーションのポリシーを作成できます：
| アクション | ルールタイプ | セレクタ | 値 |
|---|---|---|---|
| 許可 | 必要 | My Access Group | - |
| 含む | メールアドレスの末尾 | @cloudflare.com, @contractors.com |
ポリシーにルールを追加する際、ユーザーが満たすべき基準/属性を指定するよう求められます。これらの属性は、SaaS、自己ホスト、および非HTTPアプリケーションを含むすべてのAccessアプリケーションタイプで利用可能です。
アイデンティティベースの属性は、ユーザーがAccessに認証する際にのみチェックされますが、非アイデンティティ属性はユーザーセッション中に変更のために継続的にポーリングされます。もしSCIMプロビジョニングを設定している場合、IdPでユーザーを取り消すか、IdPグループメンバーシップを更新するたびに、ユーザーにすべての属性を再確認させることができます。
| セレクタ | 説明 | ログイン時にチェック | 継続的にチェック1 |
|---|---|---|---|
| メールアドレス | you@company.com | ✅ | ❌ |
| メールアドレスの末尾 | @company.com | ✅ | ❌ |
| 外部評価 | 外部API内のカスタムロジックに基づいてアクセスを許可または拒否します。 | ✅ | ❌ |
| IP範囲 | 192.168.100.1/24（IPv4/IPv6アドレスおよびCIDR範囲をサポート） | ✅ | ✅ |
| 国 | IPアドレスを使用して国を特定します。 | ✅ | ✅ |
| すべての人 | すべての人へのアクセスを許可、拒否、またはバイパスします。 | ✅ | ❌ |
| コモンネーム | リクエストは、期待されるコモンネームを持つ有効な証明書を提示する必要があります。 | ✅ | ✅ |
| 有効な証明書 | リクエストは、任意の有効なクライアント証明書を提示する必要があります。 | ✅ | ✅ |
| サービストークン | リクエストは、特定のアプリケーションに対して構成された正しいサービストークンヘッダーを提示する必要があります。 | ✅ | ✅ |
| いずれかのAccessサービストークン | リクエストは、このアカウントのために作成された任意のサービストークンのヘッダーを提示する必要があります。 | ✅ | ✅ |
| ログイン方法 | ログイン時に使用されたアイデンティティプロバイダーをチェックします。 | ✅ | ❌ |
| 認証方法 | ユーザーが使用した多要素認証方法をチェックします（アイデンティティプロバイダーがサポートしている場合）。 | ✅ | ❌ |
| アイデンティティプロバイダーグループ | アイデンティティプロバイダー（IdP）で構成したユーザーグループをチェックします。このセレクタは、AzureAD、GitHub、Google、またはOktaをIdPとして使用している場合にのみ表示されます。 | ✅ | ❌ |
| SAMLグループ | SAML属性名/値ペアをチェックします。このセレクタは、一般的なSAMLアイデンティティプロバイダーを使用している場合にのみ表示されます。 | ✅ | ❌ |
| OIDCクレーム | OIDCクレーム名/値ペアをチェックします。このセレクタは、一般的なOIDCアイデンティティプロバイダーを使用している場合にのみ表示されます。 | ✅ | ❌ |
| デバイスポスチャ | WARPクライアントまたはサードパーティサービスプロバイダーからのデバイスポスチャ信号をチェックします。 | ✅ | ✅ |
| WARP | デバイスがWARPに接続されていることを確認します。消費者版を含みます。 | ✅ | ✅ |
| ゲートウェイ | デバイスがWARPクライアントを介してゼロトラストインスタンスに接続されていることを確認します。 | ✅ | ✅ |
1 SaaSアプリケーションの場合、Accessは初回サインオン時とSaaSセッションの再発行時にのみポリシーを強制できます。ユーザーがSaaSアプリに認証された後、セッション管理はSaaSアプリの権限内に完全に委ねられます。
ポリシーは、そのアクションタイプと順序に基づいて評価されます。バイパスおよびサービス認証ポリシーは、UIに示されているように、上から下へと最初に評価されます。その後、ブロックおよび許可ポリシーがその順序に基づいて評価されます。
例えば、次のように配置されたポリシーのリストがあるとします：
- 許可 A
- ブロック B
- サービス認証 C
- バイパス D
- 許可 E
ポリシーは次の順序で実行されます：サービス認証 C > バイパス D > 許可 A > ブロック B > 許可 E。ユーザーが許可またはブロックポリシーに一致すると、評価は停止し、その後のポリシーが決定を上書きすることはできません。
アローポリシーに以下のルールのいずれかを追加すると、誰でもあなたのアプリケーションにアクセスできるようになります。
| ルールタイプ | セレクター | 値 |
|---|---|---|
| 含める | すべての人 | Everyone |
| ルールタイプ | セレクター | 値 |
|---|---|---|
| 含める | ログイン方法 | One-time PIN |