Cloudflare Access 向け ZTNA アクセスポリシーの設計

今日の組織は、絶えず変化する脅威環境のなかで会社の資産とインフラストラクチャを守るため、Zero Trust セキュリティ ↗ の姿勢を採用するケースが増えています。レガシーネットワーク設計に伴う従来のセキュリティは、企業ネットワーク境界内の信頼を前提とします。対照的に、Zero Trust は「決して信頼せず、常に検証する」という原則で動き、場所やネットワークに関係なく、すべてのユーザー、デバイス、アプリケーションに継続的な 認証と厳格なアクセス制御 ↗ を適用します。

通常、Zero Trust アーキテクチャでは 2 つの技術が役割を果たします。まず、Secure Web Gateway（SWG） ↗ がインターネット向けの送信トラフィックをフィルターし、フィッシングキャンペーンに関わるサイトなど高リスクのウェブサイトへのアクセスをブロックします。次に、SaaS アプリ、社内ホストのアプリケーション、ネットワークへのリモートアクセスを可能にするため、Zero Trust Network Access（ZTNA ↗）サービスが安全なトンネルを作り、リモートユーザーにプライベートアプリケーションへのアクセスを提供します。

このガイドは、Cloudflare の ZTNA サービス（Access）を導入するお客様向けで、適切なポリシーを効果的に構築するためのベストプラクティスと指針を示します。まだ読んでいない場合は、Cloudflare の SASE リファレンスアーキテクチャ も読むことを推奨します。Zero Trust の取り組みの一部として Cloudflare を使う方法のすべての側面を詳しく説明しています。

このドキュメントは、既存の VPN サービスを置き換えるため、または社内リソースへの新しいリモートアクセスを提供するために、Cloudflare を評価している、または採用した管理者向けです。最初の ZTNA ポリシーを設計する出発点であり、継続的な参照先でもあります。このガイドは次の 3 つの主なセクションで構成されます。

• 技術的な前提条件: 最初のアプリケーションへのアクセスを保護し、アクセスポリシーを定義する前に揃える必要があるものです。
• ポリシーの構築: アクセスポリシーの主な構成要素と、それらを組み合わせる方法です。
• ユースケース: 独自のポリシー設計の青写真として使える、一般的なユースケースとポリシーです。

この設計ガイドは、Cloudflare の ZTNA ソリューションである Cloudflare Access の基本を理解していることを前提とします。そのため、効果的なアクセスポリシーの設計に焦点を当て、DNS、ID、デバイスポスチャプロバイダー の設定と、セルフホストアプリケーションおよび関連ネットワークへの 接続の作成 はすでに完了しているものとします。

このガイドの終わりまでに、一般的な企業シナリオにわたって Zero Trust の原則を適用する、きめ細かいアクセスポリシーを実装できるようになります。

このセクションでは、きめ細かいアクセスポリシーを設計する前に理解しておくべき、必須のアーキテクチャ構成要素と概念を扱います。

Cloudflare を使うと、組織は connectivity cloud ↗ でアプリケーションアクセスを促進できます。場所に関係なく、ユーザー、アプリケーション、データを安全につなぎます。プラットフォームの中核は Cloudflare の 広範なグローバルネットワーク ↗ であり、世界中のユーザーに低遅延の接続を届けます。すべてのデータセンターですべてのサービスを動かすことで、Cloudflare はネットワーキング、パフォーマンス、セキュリティ機能を 1 パスで適用し、複数の専用セキュリティサーバーへトラフィックを回す必要をなくし、待ち時間を減らし、パフォーマンスのボトルネックを避けます。

プライベートアプリケーションとネットワークへのアクセスを提供する方法は主に 2 つです。公開ホスト名でリクエストをアプリケーションへプロキシする方法と、プライベート IP で、ユーザーがデバイスまたはネットワーク上にあり、Cloudflare 経由でプライベートな企業ネットワークへ接続されている方法です。

公開ホスト名を使うには、Cloudflare 上に アクティブなドメイン が必要です。ほとんどのお客様は Cloudflare をプライマリ DNS サービスとして使いますが、Access で使うドメインを設定しつつ、DNS レコードを別の場所 で維持することもできます。

Cloudflare がアクセスを制御するには、アプリケーションの前に立ち、認証に成功したユーザー向けの安全で信頼性の高いネットワークルートが必要です。アプリケーションアクセスのリクエストはまず Cloudflare に届き、そこでポリシーが適用され、成功すればユーザーリクエストがアプリケーションへルーティングされます。

Cloudflare は次の種類のアプリケーションへのアクセスに対応しています。

• インターネット上の SaaS アプリケーション
• 公開ホスト名経由でアクセスするセルフホストアプリケーション
• プライベート IP 経由でアクセスするセルフホストアプリケーション

SaaS およびその他のインターネット向けアプリケーションでは、Cloudflare からのアクセスは単純です。すでにインターネット上にあります。セルフホストアプリケーションでは、アプリケーションが動いているプライベートネットワークへ、Cloudflare からトンネルを作成します。方法は 2 つあります。

• 推奨するアプローチは、cloudflared や Cloudflare Mesh などの ソフトウェアエージェント を使うことです。（公開ホスト名をプライベートアプリケーションへプロキシできるのは、現在 cloudflared だけです。）
• ネットワークベースの接続では、Cloudflare WAN（旧 Magic WAN）が IPsec または GRE トンネルを使い、プライベートネットワークに接続された既存のネットワーク機器へ Cloudflare をつなぎます。Network Interconnect は、アプリケーションが Cloudflare の運用するデータセンター内のサーバーで動いている場合に直接接続を作ります。（既存のレガシー VPN ソリューションからネットワークベースのトンネルへ移行する場合は、このガイド が役立つことがあります。）

アプリケーションへの接続が確立したら、ユーザーアクセスを促進します。ポリシー要件（後述）によっては、ユーザーは公開ホスト名へのインターネット接続で直接アプリケーションにアクセスできます。より高いセキュリティのためには、デバイスエージェント である Cloudflare One Client の利用を推奨します。Cloudflare へのトンネルを直接作り、アクセスポリシーで使うデバイス情報も提供します。

アプリケーションアクセスの重要な部分は、ユーザーの認証です。Cloudflare にはメールベースの 組み込み認証 方法があります。ただし、サードパーティの ID プロバイダーを設定することを強く推奨します。コンシューマーおよび企業の ID プロバイダー の両方に対応し、SAML または OpenID 準拠の任意のサービスを使えます。グループメンバーシップはアプリケーションアクセスを定義する最も一般的な属性の 1 つで、手動で定義するか、System for Cross-Domain Identity Management（SCIM）でインポートできます。

本当に効果的なアクセスポリシーを構築するための最後の前提条件は、デバイスポスチャ の設定です。デバイスエージェント を使うと、Cloudflare はデバイスに関する さまざまな情報 にアクセスでき、それをアクセスポリシーで使えます。エージェントレスの方法 でアプリケーションにアクセスする場合、利用できるのはユーザー ID 情報だけです。Microsoft、Crowdstrike、Sentinel One など、他ベンダーからのデバイスポスチャ情報の利用にも対応しています。

ここまでのアーキテクチャを簡潔にまとめると、Cloudflare は次の状態です。

• アプリケーションへのネットワークアクセスの前に立っています。
• ID プロバイダーと連携しています。
• デバイスエージェントまたはサードパーティベンダーを使うユーザーのデバイスポスチャ詳細を把握しています。

ユーザーがアプリケーションへのアクセスをリクエストすると、まず認証する必要があります。アクセスが付与される前に、リクエストしているユーザーに関連するデータに基づいて、アプリケーション内のポリシーが評価されます。ポリシーとその他のアプリケーション固有の設定は、Access アプリケーションで定義します。

Cloudflare Access は、次の 4 つの主なアプリケーション種類に対応しています。

• Self-hosted は、組織がオンプレミスまたはクラウドでホストおよび管理するアプリケーションを指します。Cloudflare は公開ホスト名を作成し、安全なトンネル経由でアプリケーションへトラフィックをプロキシします。サーバーがインターネット上で公開されているだけでも公開ホスト名経由のアクセスには対応していますが、cloudflared を使い、アプリケーションから Cloudflare のエッジへ安全な、送信専用の接続を作ることを推奨します。それが完了すると、Cloudflare は対象のアプリケーション/コンテンツをユーザーへリバースプロキシします。
• Private IP アプリケーションも同様にプライベートホストですが、完全修飾の公開ホスト名がありません。アクセスは cloudflared、Cloudflare Mesh、Cloudflare WAN、または Cloudflare Network Interconnect 経由で促進できます。すでに Cloudflare に接続されたネットワークにいないリモートユーザーは、プライベート IP 経由でアプリケーションにアクセスするためにデバイスクライアントが必要です。ユーザーに IP アドレスを使わせないようにするには、内部 DNS サービス でプライベートホスト名をプライベート IP アドレスに解決します。ただし、エージェントレスの ブラウザー分離サービス を使うと、クライアントにソフトウェアをデプロイせずにアクセスを提供することもできます。
• SaaS アプリケーションは公開インターネット経由でアクセスするため、Cloudflare へのトンネル接続は不要です。代わりに、Access はユーザーと SaaS アプリケーションのあいだの ID プロキシとして動作します。ユーザーが SaaS アプリへのアクセスを試みると、まず Cloudflare で認証され、Cloudflare がメインの ID サービスへリダイレクトします。SaaS アプリケーションは、SAML または OAuth 経由で Cloudflare を信頼するように設定します。これにより、SaaS または ID プロバイダーがこれらの機能にネイティブ対応していなくても、追加のセキュリティ層（デバイスポスチャチェックなど）を実装し、SaaS アプリケーションのアクセス制御を集中管理できます。
• Infrastructure アプリケーションは、プライベートネットワーク内の個別のサーバー、クラスター、データベースへのアクセスをユーザーが制御できるようにします。Infrastructure アプリは cloudflared 経由でプロキシされる「ターゲット」を定義して動作しますが、複数のマシンを同じターゲットの下にまとめられます。つまり、異なるインフラストラクチャリソースにわたって共通のアクセスポリシーを定義できます。組み込みのアクセスログとコマンドログにより、組織はコンプライアンスとセキュリティ調査のための詳細な監査証跡を維持できます。

Access アプリケーションは通常、単一のアプリケーションに直接対応します。ただし、1 つの Access アプリケーションとその関連ポリシーを、複数のアプリケーションエンドポイントの前に置くこともできます。これは、共通のアクセスポリシーを実装したい複数の Windows RDP サーバーに関連する IP 範囲である場合があります。同じ考え方は公開ホスト名にも適用でき、同じポリシーを持たせたい複数のアプリケーションを指すホスト名が複数ある場合があります。たとえば、wiki.domain.com と wiki.domain.co.uk は異なるアプリケーションインスタンスですが、共通のアクセスポリシー要件があります。

次に、効果的なアクセスポリシーを作るために理解すべき、ZTNA 保護アプリケーションの主な要素を調べ、その後、それらの具体的な要素を適用するユースケースを見ます。

ユーザー ID の認証は、あらゆる Zero Trust ポリシーの重要な構成要素です。アプリケーションへのログインを試みると、ユーザーは設定済みの ID プロバイダーへリダイレクトされます。ユーザーが ID プロバイダーでの認証に失敗すると、Cloudflare はアプリケーションへのリクエストを受け付けません。

前述のとおり、Cloudflare は企業およびコンシューマーのすべての ID プロバイダー（IdP）と連携できます。その後、アプリケーションおよびポリシーレベルで、認証に許可する IdP を選びます。たとえば、限られた数の従業員だけがアクセスできるアプリケーションがある場合があります。その場合は企業 IdP だけを有効にします。別のアプリケーションでは、契約者やサードパーティパートナーなど、より広い非従業員ユーザーグループへのアクセスを許可したい場合があります。それらのユーザーの一部は、GitHub または LinkedIn の資格情報で認証します。

ユーザーがアプリケーションへのアクセスを試みると、どの IdP で認証するかを選ぶサインインページが表示されます。単一の IdP だけのアプリケーションでは、ユーザーをその IdP へ自動リダイレクトできます。設定済みのすべての IdP をアプリケーションに表示するように設定することもでき、ポリシーを更新せずに将来新しいプロバイダーを追加できます。

認証後、IdP は ID に関する情報を Cloudflare へ送ります。IdP によっては、この情報に Authentication Method Reference ↗（amr）値、IdP グループ、SAML 属性、OIDC クレームが含まれ、ポリシーで使えます。

デバイスエージェントを使う場合、ユーザーも認証する必要があり、カスタムの IdP リストを提示できます。エージェントが認証されると Cloudflare に接続でき、デバイスエージェントに関連する既存の認証セッションを信頼して、アプリケーションの認証をスキップするように設定できます。

ここからがこのガイドの主な焦点です。アプリケーションへのアクセスを定義するポリシーです。ここで、誰がどのようにアクセスするかを定義する本作業が行われます。ユースケースの例を見る前に、ポリシーの動作を分解します。

各アプリケーションは複数のポリシーを含められ、順に評価されます。複数のルールセットを持つ複数のポリシーはかなり複雑になり得るため、ユーザー名を指定して、すべてのポリシーとルールに対してユーザーがどう評価されるかを見るポリシーテスターがあります。ポリシーは次の要素で構成されます。

何のためのものかは自明に見えますが、ポリシーの命名戦略を持つことを強く推奨します。複数のアプリケーションにわたって似たポリシーを作ることが多いためです。たとえば「すべての正社員を許可する」や「高リスクユーザーをブロックする」です。すべてのアプリケーションで同じ命名スキームを使うと、アプリケーションアクセスの確認と、将来ポリシーの完全な一覧を理解することが大幅に効率化されます。

ポリシーの Action フィールドは、ユーザーまたはサービスがポリシーの条件に一致したときに何が起きるかを決めます。主なアクションの種類は 4 つです。

• Allow はアプリケーションへのアクセスを付与します。初回のアクセスリクエスト時に、ユーザーにログインページが表示されます。
• Block はアプリケーションへのアクセスを拒否します。Access はデフォルトで拒否するため、通常は不要です。ブロックポリシーを実装する理由は、特定のポリシー条件をテストするか、ポリシー評価をショートサーキットすることだけです。ブロックポリシーが Allow より優先され、ユーザーがブロックポリシーに一致すると、他のすべてのポリシー評価は停止します。
• Bypass は、アプリケーションにアクセスする前に、ユーザーまたはサービスがトラフィックへの強制を無効にできるようにします。たとえば、アプリケーション内の特定のエンドポイントがインターネット上で広くアクセス可能である必要がある場合があります。
• Service Auth は、mTLS または サービストークン を使い、他のサービスまたはアプリケーションからのリクエストを認証できるようにします。このポリシー条件を満たす場合、ユーザーまたはサービスにログインページは表示されません。他のアプリケーションからのリクエストなど、非ユーザーリクエストが保護されたリソースにアクセスできるように設計されています。

セッション期間は、アプリケーションへのログインに成功したあと、ユーザーの認証が有効であり続ける時間の長さを指します。通常、セッション期間は 24 時間に設定されますが、機微なアプリケーションではすぐに期限切れにする設定もできます。このアプローチは、「決して信頼せず、常に検証する」という Zero Trust の中核原則に沿います。ユーザーが最初に適切なデバイスポスチャと ID コンテキストを提示しても、継続的な検証により、新しいリクエストごとにアクセス権が再評価されます。この方法は、最初の認証と認可の状態が長期間有効であり続けるという前提を取り除くため、リスクウィンドウを大幅に減らします。

これらはポリシーの主な焦点です。ルールは、ポリシーがアクセスを許可するか拒否するか、またはアプリケーションを分離ブラウザーで描画するかを決めるすべての属性を定義します。セレクターと値で構成され、評価したい属性と、評価しているデータです。

各ルールは、このポリシーが影響するユーザーを決めるフィルターです。ルールのカテゴリはいくつかあります。

• Include ルールは、アクセスの対象となる誰または何を定義します。ユーザーが「Include」ルールに一致すると、ポリシー内の他のルールタイプに従うことを条件に、アクセスの候補になります。これらのルールは OR ロジックを使います。いずれか 1 つを満たせば十分です。たとえば、特定のグループにアプリケーションを公開しつつ、メールリストの契約者を追加する必要がある場合があります。ユーザーがこれらのいずれか（グループメンバーシップ、または有効なメール）に一致すれば、ルールに含まれます。すべてのポリシーには少なくとも 1 つの Include 句が必要です。

• Require ルールは、アクセスを付与するために満たす必要がある必須条件を設定します。Include ルールと異なり、「Require」ルールは AND ロジックを使います。すべてのルールを満たす必要があります。これは通常、Include ルールで定義した基本的なアクセス条件の上にセキュリティを重ねるために使います。たとえば、管理者はアプリケーションへのアクセスを試みるすべての人に、特定の MFA 方法の利用を要求できます。

• Exclude ルールはアクセスの例外を定義し、他のルールタイプを上書きします。ユーザーが「Exclude」ルールに一致すると、他のポリシー条件に関係なくアクセスを拒否されます。たとえば、ユーザーはログイン中に MFA 方法を使う要件を満たしても、その特定の 多要素認証（MFA）方法 が Exclude ルールで定義されていれば、ポリシーによってブロックされます。あるいは、ユーザーが「高リスク」IdP グループに関連付けられている場合、他のすべてのポスチャ要件を満たしていても、その根拠で除外できます。

これらの異なる種類のルールがどう適用されるかを想像する便利な方法は、漏斗を想像することです。Include セレクターは、Allowed、Blocked などになるポリシーに含まれるユーザー、トラフィック、またはデバイスの属性を定義します。Require はその一覧から、ユーザーに関連付ける必要がある属性をさらにフィルターし、Exclude タイプは Include と Require の両方に一致したユーザーをポリシー評価から除きます。

上の図は、「強力な MFA を使う安全なデバイス上のすべての従業員と契約者」というポリシーの例を可視化します。「All Employees」グループの誰か、または自社ドメインのユーザー名で認証した契約者がこのポリシーに一致します。最新の OS を持ち、暗号化ストレージを使うデバイスを使っていることが求められます。MFA 要素で認証している必要がありますが、SMS ではありません。また、Cloudflare のセキュアウェブゲートウェイ経由でアプリケーションにアクセスしている必要があります。

セレクターの種類 は多数あります。ここでは可能なすべてのセレクターを列挙しませんが、Cloudflare Access を使う組織がポリシー構築時に通常望む具体的な成果を次に示します。特定の成果をどう達成するかを理解するのに役立ちます。

• ユーザートラフィックは Cloudflare Gateway 経由か。 ユーザーが SWG である Cloudflare Gateway 経由でのみアプリケーションにアクセスすることを保証すると、フィッシングや資格情報の盗難による不正アクセスを防ぐのに大いに役立ちます。加えて、アプリケーション向けのすべてのトラフィックが Cloudflare Gateway でログされ、フィルターされることを確保できます。

  この制御は、「gateway」デバイスポスチャチェックを有効にし、アプリケーションポリシーで「gateway」を必須にすることで設定できます。「gateway」を必須にする方が、デバイスエージェントだけに頼るより柔軟です。ユーザーは Browser Isolation または Cloudflare WAN 接続サイトからもオンランプでき、どちらもトラフィックのログとフィルターを提供するためです。加えて、デバイスエージェントを使う場合、一連のデバイスポスチャチェックを通過した準拠デバイスから来ていることを保証できます。

  ゲートウェイの必須化は、セルフホストアプリケーション では継続的に強制されます。SaaS アプリではログイン時にのみ強制されます。ただし、専用の egress IP を併用すると、トラフィックが常に Cloudflare Gateway 経由であることを強制できます。

• ユーザーは既存のグループに属するか、特定の ID 属性を持つか。 IdP が SCIM に対応している場合、グループメンバーシップ情報を Cloudflare にインポートし、ポリシーで使えます。グループ情報は、認証の一部として送られる SAML または OAuth データからも来ます。実際、OIDC または SAML が使われ、クレームが送られる場合、ポリシーで使えます。ユーザーが SAML で IDP に認証し、結果のトークンに「role」が含まれる場合、ルールでその値を照会できます。

• 認証にどの ID サービスが使われたか。 IdP グループおよび属性と同様に、この「Login methods」セレクターはどの ID サービスが使われたかを問い、IdP グループと同様に、アクセスポリシー上の特定の行項目よりアクセスグループに向いています。Login methods を使うと、特定の ID プロバイダーで認証した特定のユーザーに異なるポリシーを適用できます。たとえば、GitHub や LinkedIn などのコンシューマー ID で認証したユーザーは、認証方法にハードトークンベースの MFA が含まれている場合にだけアクセスを許可できます。

  これは非典型的なシナリオですが、認証に複数の IdP を有効にする必要がある場合、このセレクターを使い、ユーザーが特定のサービスで認証していることを確認できます。この要件の価値は、複数の層になったセキュリティポリシーを扱い、ログインに基づいて異なるアクセスレベルを定義する必要があるときに、より明確になります。

• 個人または組織のメール すべての ID サービスはメールアドレスを提供し、多くの場合それは個人のユーザー名と一致します。ポリシーでメールを使うと、任意のメールを許可するコンシューマー IdP 経由で認証する可能性がある場合でも、ドメイン全体のユーザーへのアクセスを許可したいときに便利です。たとえば、GitHub 経由で @company.com のメールアドレスを使って認証したユーザーだけにアクセスを許可できます。

  このセレクターのもう 1 つの良い使い方は、高リスクである、または特定のアプリケーションからブロックされたユーザーの メールリスト を管理している場合です。Exclude ルールとリストを使い、一部のユーザーがアプリケーションにアクセスできないようにできます。

• ユーザーはどのように認証したか。 ID プロバイダーがユーザーを認証して Cloudflare へリダイレクトするとき、どの認証方法が使われたかに関する情報を含めます。これは通常 Authentication Method Reference ↗ データとして送られます。これを使い、MFA が使われたか、どの種類かを確認できます。

  これは、異なるアプリケーションに異なる資格情報要件のレベルを定義するのに便利です。たとえば、一般的な会社アプリケーションは MFA が使われたことだけを要求し、方法は気にしない場合があります。本当に機微な管理ツールは FIDO2 ハードウェアベースのセキュリティキーを要求し、認証プロセスの一部として SMS 経由の OTP だけが使われた場合は明示的にアクセスを拒否できます。

• リクエストはどの国から来ているか。 着信リクエストの地理的なルックアップに基づいてルールを設定できます。ビジネスを行う特定の国へのアクセスを制限するのに便利なことがあります。

• リクエストはどの IP 範囲から来ているか。 着信リクエストの IP 範囲に基づいてルールを設定できます。企業ネットワークの IP 範囲からのアクセスだけを許可する場合などです。

• リストからデバイスまたはユーザー情報を検証できるか。 他のカテゴリにうまく収まらない特定のデバイスまたはユーザー特性に基づいて、アクセスを付与または制限したい場合があります。ここで リスト が役立ちます。契約者のメールリストや、承認済みデバイスのシリアル番号リストを定義またはインポートし、Access ポリシー内の条件として使えます。これらのリストは手動または API 経由で更新でき、他のデバイスまたはユーザー管理システムとの連携が可能です。

• デバイスのセキュリティポスチャは十分か。 ここでデバイスクライアントは、アクセスリクエストを行うネイティブデバイスのテレメトリを提供します。デバイスレベルのスキャンを実行することでこれを達成します。デバイスのハードドライブは暗号化されているか。エージェントは BitLocker や FileVault などの技術が有効かを確認でき、特定のボリューム名の確認もできます。機微なアプリケーションや重要な情報を持つものを保護している場合、これは強制するのに効果的な要件です。

• リクエストは別のプロセスまたはアプリケーションが行っているか。 アプリケーションへのアクセスを試みるのは、常にデバイス上の実在の人間ではありません。そのため、他のソフトウェアによる API への通信を管理するために Cloudflare Access を活用すると便利です。リクエストにはサービストークン、相互 TLS 証明書、SSH 証明書が含まれ、自動化プロセスとマシン間通信のログインを可能にします。Cloudflare 内のサービス認証オプションを使うと、これらのトークンと証明書の保存とライフサイクル管理も集中できます。

• サードパーティツールはデバイスについて何と言っているか。 多くの組織は、Crowdstrike、SentinelOne、Microsoft Intune などのエンドポイントセキュリティ向けの専門ツールを使い、アプリケーションリクエストを行うデバイスのセキュリティポスチャに関するテレメトリを提供します。ユーザーに複数の UI を行き来させる代わりに、これらのツールを API 経由で Cloudflare One に連携し、その洞察をアプリケーションログイン中に強制できるデバイスポスチャ属性に適用できます。

セキュリティの改善に役立つ、検討すべき追加のアプリケーション設定をいくつか示します。

契約者やパートナーなど、信頼度の低いサードパーティユーザー向けに、セルフホストアプリケーションへのアクセスを管理したい場合があります。アプリケーション内のコンテンツを読むことは許可しつつ、ファイルのダウンロード、データのコピー＆ペースト、ページの印刷を制限したい場合があります。Cloudflare Access を使うと、アプリケーションをリモート ブラウザー（リモートブラウザー分離、または RBI を使用）で描画できます。コンテンツをすべてユーザーのブラウザーへ送るのではなく、ネットワーク上のヘッドレスブラウザーでアプリケーションを描画します。これにより Cloudflare は、ユーザーがコンテンツとどうやり取りできるかについて一連の制御を強制できます。

この設定はポリシーレベルなので、1 つのポリシーは信頼できるユーザー（従業員など）に通常どおりアプリケーションへアクセスさせ、ブラウザー分離を有効にした別のポリシーは契約者に RBI サービスを適用できます。

この設定は、エンドユーザーへ届ける前にトラフィックを分離ブラウザーへ強制するため、すべてのトラフィックが Cloudflare Gateway で検査および管理されます。ユーザーができることを制限するには、同じユーザーを識別し、アクセスを制限したい 制御 を強制する、Gateway 内の付随ポリシーを作成する必要があります。Gateway ポリシーは、Cloudflare Access ポリシーが適用される、アプリケーションにアクセスする同じユーザーグループに対してのみ RBI を強制するように書くことが重要です。そうしないと、ポリシーはすべてのユーザーにブラウザー分離を強制するデフォルトになります。

ユーザーが非セキュアなデバイスでアプリケーションへのアクセスを試みる場合、同じユーザーセットに対して実際に RBI を強制することもできます。この場合、Cloudflare Access で従業員向けのポリシーを定義し続けます。ただし、同じアプリケーション URL へ向かうユーザーが、デバイスが管理対象外または安全でないとみなすデバイスポスチャチェックに失敗した場合にアプリケーションを分離するポリシーを、Cloudflare Gateway にも作成します。これは、デバイスに会社のエンドポイントセキュリティクライアント（Crowdstrike や SentinelOne など）がインストールされていない場合、またはセキュリティチェックに失敗した場合です。これを次のユースケースで示します。

逆に、ブラウザーを分離すると、アプリケーションに対する脆弱性の悪用や悪意あるコードの実行を試みる者から、ローカルデバイスも保護されます。

アプリケーションのすべての認証イベントを監査し、正当性の詳細を取得したい場合があります。この設定は、ユーザーアクセスのより明確に定義された監査証跡を作り、管理者がアクセスパターンと正当性を確認・分析できるようにします。有効にすると、ユーザーはアクセスを得る前に短い説明を求められます。機微なアプリケーションや、通常の営業時間外などの特定の期間に特に便利です。

指定された承認者から「一時認証」の承認を得ることをユーザーに求め、追加のアクセス制御層を追加します。有効にすると、アクセスをリクエストするユーザーは承認者への通知を起動します。

ZTNA ポリシーを定義する最も重要な部分の 1 つは、Access Groups と呼ばれる再利用可能な要素を活用することです。各アクセスグループは、今説明したのと同じルールを使い、ユーザー、トラフィック、またはデバイスを定義します。これらのグループは多くのポリシーにわたって使い、アプリケーションへのアクセスを許可、拒否、バイパス、または分離できます。

たとえば、「Employees」を Access Group として一度定義し、従業員を指したいすべてのアプリケーションポリシーで使えます。この Access Group への更新は、すべてのポリシーに反映されます。入れ子のロジックを含める良い方法でもあります（たとえば、Linux デバイスを使い、アンチウイルスソフトウェアが有効なユーザー）。

次は「Secure Administrators」という Access Group の図で、安全な管理者の特性を定義するために一連の属性を使います。図は「Secure Administrators」内への他の 2 つの Access Group の追加を示します。グループには、最新の Windows または macOS で動くデバイスと、デバイスが File を持っている必要があるという要件が含まれます。

アプリケーションへのアクセスを保護する基本インフラストラクチャとポリシーシステムを扱ったので、一般的なユースケースに入ります。

多くの会社は、機密の会社情報が置かれる何らかの内部コンテンツシステムをホストしています。Wiki は、従業員が誰とでも簡単に協働できる一般的な種類のアプリケーションです。ただし、この情報は機密であるため、強力な資格情報でユーザー認証を検証し、安全な接続経由の安全なデバイスからのアクセスであることも確保することが重要です。

ただし、会社ユーザーが非会社デバイスを使い、wiki にアクセスする必要がある場合もあります。これを許可しつつ、ユーザーの操作を制限するポリシーをセットアップしたい場合があります。たとえば、データの編集や、管理対象外デバイスへのコピー＆ペーストを防ぎます。このユースケースでは、従業員向けの安全なアクセスを定義する Cloudflare Access アプリケーションのセットアップ方法を説明します。安全な接続上の安全なデバイスにいるときは完全に機能するアクセスを与えつつ、非セキュアなデバイスからも限定的なアクセスを許可します。

まず、次のパラメーターで Access アプリケーションを作成します。

2 つのポリシーがどう定義されるかを見る前に、従業員を識別し、承認済みデバイスが最新のオペレーティングシステムバージョンで動いている例を観察します。

このアクセスグループは両方のポリシーで使われ、唯一の目標は「Secure Employee」とは何かを識別することです。

これは非常に単純な Access Group で、グループセレクターは 2 つだけです。特定のディレクトリからのグループに基づいてメンバーシップを確認しているため、ユーザーがそのディレクトリに認証していることも暗黙に求められます。将来、別の ID プロバイダーへ移る、または正社員を定義するグループメンバーシップ要件を変更する場合、この Access Group を一度変更するだけで済みます。

ご覧のとおり、「all employees」は Azure AD グループ「Full Time Employees」にいて、かつグループ「Completed security training」にもいる人として定義されます。最初のセレクターは Access Group の初期スコープを定義し、2 番目のセレクターは、その特定のグループにもいることを必須にします。

この Access Group は、OS version 向けに 3 つの デバイスポスチャチェック が作成されていることを要求します。たとえば、ポスチャチェック「Latest version of macOS」は「macOS version is greater than or equal to 15.1」として定義され、会社が安定かつ安全とみなす最新バージョン（最新の OS バージョンそのものではない）を反映します。Access ポリシーに含めると、ここで確立したロジックが強制されます。「Secure Employee」としてサインインしたいユーザーは、これらの要件を満たす必要があります。

次に、アプリケーション内の最初のポリシーを定義します。まず、すでに定義した Access Group を選びます。次に、ユーザーがどう認証し、どうアプリケーションに接続するかを決める次のルールを定義します。

このポリシーは、次の要件を通過した場合にだけ、会社 wiki への完全なアクセスをユーザーが得られることを確保します。

• 最新のオペレーティングシステムを持つデバイス上の正社員である。
• ユーザーが MFA を使って認証している。
• ユーザーが、Cloudflare デバイスエージェントが動いているデバイス経由でアプリケーションにアクセスしている。

2 番目のポリシーは、安全なデバイスにいないユーザーを扱う必要があります。このポリシーはアプリケーション内のポリシーリストの 2 番目であり、ユーザーが最初のポリシーの要件を満たさないときに評価されます。

このポリシーは最初のものと非常に似ていますが、最新のオペレーティングシステムを持つデバイスとデバイスエージェントの利用という要件を除きます。ユーザーは依然として、強力な MFA 付き資格情報で認証した正社員である必要があります。

ただし、今回は「Isolate Application」を有効にします。これは何を意味するか。アプリケーションへのすべてのリクエストが、RBI 技術上で描画されるように強制します。RBI は wiki の UX がエンドユーザーのブラウザーに直接読み込まれるのを防ぎ、代わりに Cloudflare のグローバルクラウドネットワーク上のサーバーで動くヘッドレスブラウザーでコンテンツを描画します。その描画結果が、安全かつ効率的にエンドユーザーのブラウザーへ伝えられます。このため、リクエストは SWG サービス経由でも送られ、ユーザーが wiki とどうやり取りできるかを制御するポリシーを書けます。

Gateway HTTP Policy

上の例では、SWG ポリシーは会社 wiki へ向かう任意のトラフィックに一致し、RBI を強制し（ZTNA アプリケーションポリシーと一致させるため）、wiki とのすべてのやり取りを無効にします。

デバイスポスチャチェック「WARP Check (Mac OS)」も追加し、ユーザーのデバイスにデバイスエージェントがあるかをスキャンします。ユーザーのデバイスにエージェントがインストールおよび有効でない場合、デバイスポスチャチェックは実行できず、ポリシー要件を自動的に満たせません。ユーザーがデバイスエージェントを有効にしている場合、ポスチャチェックに合格し、wiki への完全なアクセスが付与されます。「WARP」は Cloudflare のデバイスエージェントである Cloudflare One Client の以前の名前です。

本質的に、非セキュアなデバイス上の従業員は「読み取り専用」モードで wiki を見ることは許可されますが、アップロード/ダウンロードや機密情報のコピー＆ペーストなどのそれ以上のやり取りは制限されます。

このポリシーアプローチは、いくつかの目的を達成します。

1. wiki への完全なアクセスに信頼できるデバイスの利用を強制し、Zero Trust のセキュリティ目標に沿います。
2. 個人デバイスを使う従業員向けのフォールバックを提供し、ブラウザー分離経由で限定的かつ安全な方法で wiki にアクセスできるようにします。
3. 従業員に会社デバイスの利用、または Cloudflare One Client を有効にしたままにすることを促し、組織のセキュリティ姿勢にとってプラスです。
4. Cloudflare Access ポリシーと Cloudflare Gateway HTTP ポリシーを組み合わせることで達成できる、より細かいセキュリティ制御の力と柔軟性を示します。

このアプローチは wiki を保護するだけでなく、他のアプリケーションを保護するモデルも確立します。ハイブリッドワークの現実に適応しつつ、強いサイバー衛生を維持できます。

2 つ目のユースケースは、デバイスクライアントの利用も必要とする安全なアクセス戦略を実装します。ただし、実装は前の wiki の例よりやや複雑です。

具体的な内容に入る前に、Cloudflare 経由で SaaS アプリへのアクセスを保護する利点を学びます。結局のところ、Salesforce やその他の主要な SaaS プロバイダーは、独自のアクセス制御、MFA、監査ログを含む堅牢なセキュリティ機能をすでに提供しています。それでも一部の組織が SaaS トラフィックを Cloudflare 経由でルーティングするのはなぜか。

ここでの主な利点は、IT エコシステム全体でセキュリティポリシーの強制を集中することです。Salesforce アクセスを Cloudflare 経由でルーティングすると、Salesforce を保護するだけでなく、すべてのユーザーアクティビティの単一の可視化点を含み、複数のセキュリティシステムの管理の複雑さを減らす、より広い Zero Trust 戦略に統合します。単一の SaaS アプリケーションへのアクセスに対して、多くの異なる IdP の強制を実装することもできます。

このユースケースの文脈では、機微な顧客データを含む Salesforce を誤用から保護し、認可されたユーザーだけにアクセスを限定することが重要です。これら両方の目的をカバーできる安全なアクセスポリシーを設計します。

最初のステップは、Cloudflare Gateway の下で egress IP ポリシー を設定することです。これにより、Gateway 経由でトラフィックがフィルターされるユーザーに、特定の IP を購入して割り当てられます。次に Salesforce で、egress ポリシーのものと一致する送信元 IP を持つトラフィックだけにアクセスを許可するように強制できます。この組み合わせにより、Salesforce へのアクセス方法は Cloudflare 経由だけになります。

これは Salesforce へのアクセスを保護するためだけでなく、利用中の内容を適切に保護するためにも重要です。次のステップは、wiki 向けに今作成したものと似たアクセスポリシーを調べることです。ただし、このポリシーは Sales または Executives グループのメンバーにアクセスを限定しています。Crowdstrike 連携も使い、ユーザーが会社管理デバイス上にいることを確保します。

2 番目のポリシーはすべての従業員に適用しますが、アクセスが付与される前にさらにいくつかのステップを適用します。

この 2 番目のポリシーに一時認証を追加します。つまり、着信リクエストが Sales または Executives 部門外の誰かからだと Cloudflare が判断した場合、管理者が一時アクセスを明示的に付与する必要があります。文脈としては、顧客情報が機微で機密になり得るため、営業部門外の従業員の Salesforce アクセスを保護するためにこのポリシーを使えます。

このアプローチが重要な理由はいくつかあります。

• 潜在的にリスクのあるアクセス試行に人の監視を入れ、侵害された、または安全でないデバイス経由の不正アクセスの可能性を減らします。
• デバイスが最高のセキュリティ基準を満たせない場合でも、正当なユーザーがアプリケーションにアクセスできる柔軟性を提供します。デバイス上で良いセキュリティ慣行を維持することを促します。
• 加えて、すべてのユーザートラフィックが Cloudflare 経由でルーティングされるため、Web トラフィックポリシー経由で追加のセキュリティ対策（機微なデータのダウンロード防止など）を強制できます。

このシナリオは、PostgreSQL データベース管理ツールの保護を扱います。これはプライベートホストで、機微なデータへのアクセスがあるため高価値の標的です。安全なアクセスの設計には特に注意が必要です。データベースツールの性質上、このユースケースではアクセスポリシーを層にしません。

ここでは、MFA から始めて多数のセキュリティポスチャチェックを導入します。MFA に関する式は 2 つあります。1 つ目は、ユーザーが MFA 方法で認証することを要求します。2 つ目の「exclude」式は、SMS が有効な認証方法とみなされないことを示します。SMS は攻撃者が悪用・覆しやすい方法の 1 つであり、そのため他の MFA 方法より 安全性が低い ↗ とみなされるためです。その結果、ハードキーまたは認証アプリからの OTP など、より強い資格情報をユーザーが提供した場合にだけアクセスを許可します。これらのより厳しい MFA 要件を強制すると、資格情報ベースの攻撃のリスクが下がり、ユーザーのパスワードを入手していても、攻撃者がこの重要なデータベースへの不正アクセスを得ることがはるかに難しくなります。

ここでの他のポスチャ要素は次です。

• 最新の OS を必須にする。
• ユーザーのデバイスが Microsoft Active Directory ドメインに参加している。
• ユーザーのデバイスが明示的に会社管理デバイスである（管理対象デバイスのシリアル番号リストを参照することで示す）。

これらの組み合わせたポスチャチェックにより、管理環境内の最新の、会社が管理するデバイスだけがデータベースにアクセスでき、攻撃面と、侵害された、または管理されていないエンドポイントからのアクセスのリスクをさらに減らします。

追加設定では、データベースにアクセスする目的の正当性をユーザーが入力することも要求します。セキュリティチームがアクセスパターンを分析し、潜在的に不審な動作を特定できるようにします。この一連のセキュリティ制御は、重要なデータベースへのアクセスが厳しく規制、ログ、正当化されることも確保し、不正アクセスや誤用のリスクを大幅に減らします。

このレベルの保護と可視化を、ばらばらのスタンドアロンセキュリティソリューションで達成するのは、大幅に複雑でリソース集約的です。Cloudflare 経由でセキュリティポリシーの強制を集中すると、重要な内部リソースへのきめ細かいアクセスの実装方法を簡素化できます。

この最後のユースケースは、RDP 経由のデバイスへのリモートアクセスを 2 通りで保護することに焦点を当てます。セルフホストまたはプライベート IP です。どちらも独自の利点がありますが、最終的には優先順位次第です。アクセスの簡素化がより重要か、アクティビティの厳密な監視がより重要か。

セルフホストのオプションから始めます。ポート 3389 をトンネル経由でプロキシし、ホスト名にマッピングします。

ポリシーを定義します。

ポリシー内では、IT Admins 向けの新しいアクセスグループにこのアプリケーションを公開しています。「Require」の下では、Cloudflare Gateway だけでなく Cloudflare One Client の利用を具体的に強制しています。ユーザーは会社管理デバイス上にいる必要があり、会社の Cloudflare インスタンスに認証されたアクティブなデバイスクライアントがあり、ログイン中に MFA を使う必要があり、その下に外部評価向けの追加オプションがあります。

External evaluation は、何らかの アクセスロジック ↗ を含む API エンドポイントがあることを意味します。この場合は時刻ベースのアクセスです。このエンドポイントへ API 呼び出しを行い、応答が API から来たことを Cloudflare が検証するために使うキーを定義します。これが便利な理由はいくつかあります。

外部評価により、デフォルトのポスチャチェックセットではカバーされない条件に基づく、独自のセキュリティポスチャチェックを作成できます。この例では、Cloudflare Workers ↗ 上に構築したサービスを使います。

• 営業時間外のターミナルへのアクセスを制限すると、時刻ベースのアクセス制御の一形態を実装します。潜在的な攻撃者の機会の窓を制限することで、追加のセキュリティ層を加えます。

次に、プライベート IP アプリケーションとして RDP アクセスを保護する方法を学びます。

前述のとおり、プライベート IP アプリケーションが動くのは、Cloudflare がその IP 範囲をネットワーク全体でプロキシするからです。このアプリケーションの性質上、デバイスクライアントの利用が必須です。ユーザーが Cloudflare に接続していない限り（より具体的には、Client-to-Tunnel 接続を活用できない限り）、非ローカルの RFC 1918 アドレスに到達できないためです。

ここでのアプリケーション定義は単純です。Cloudflare が IP 範囲を自動入力し、検出されたプロトコルを RDP に限定する必要があります。ただし、プライベート IP アプリケーションのルールは少し異なります。Access で管理しているにもかかわらず、Cloudflare Gateway メニューの下のネットワークポリシーとして表示されることに気づくでしょう。MFA と外部評価の確認などの一部のオプションはここには現れません。ただし、これらの属性は、ユーザーがデバイスクライアントを有効にし、組織に認証するときに検証できます。

ここで利用できるオプションの 1 つは、デバイスエージェントのクライアントセッション期間の強制です。一定時間後、ユーザーは再認証を強制されます。この機能により、プライベート IP アプリケーションの保護にも Zero Trust アプローチを取れます。ユーザーの資格情報が侵害されたり、デバイスが放置されたりしても、不正アクセスの潜在的な窓が制限されます。再認証を定期的に要求することで、ユーザーの ID と認可ステータスを継続的に検証し、「決して信頼せず、常に検証する」という Zero Trust の中核原則に沿います。

きめ細かいアクセス制御と詳細なアクティビティログを組み合わせることで、Cloudflare は Zero Trust の方法論で重要なリソースへのアクセスを保護および監視する包括的なセキュリティソリューションを提供します。

成功する ZTNA 実装は、技術的な設定だけではありません。組織固有のニーズ、ユーザーワークフロー、セキュリティ要件を慎重に検討する必要があります。Cloudflare の柔軟性により、基本的な安全なアクセスポリシーから始め、組織のニーズの変化とセキュリティ要件の成熟に合わせて進化させられます。このガイドで示した原則と実践に従うことで、可能な限り精密かつ透明に保護する堅牢なセキュリティ姿勢を作れます。

ZTNA、SASE、または Cloudflare One プラットフォームの他の側面について詳しく知りたい場合は、リファレンスアーキテクチャライブラリ または 開発者ドキュメント を参照して始めてください。

関連リソース

• Cloudflare SASE リファレンスアーキテクチャ
• Microsoft での Cloudflare SASE の利用
• Cloudflare ZTNA のデプロイ方法