Cloudflare で SASE アーキテクチャへ進化する

このリファレンスアーキテクチャの PDF 版 をダウンロードします。

Cloudflare One は、エンタープライズアプリケーション、ユーザー、デバイス、ネットワークを保護するセキュアアクセスサービスエッジ（SASE）プラットフォームです。Cloudflare One を段階的に採用すると、ハードウェアアプライアンスやその他のポイントソリューションの寄せ集めから離れ、セキュリティとネットワーキングの能力を 1 つの統合されたコントロールプレーンにまとめられます。このようなネットワークとセキュリティの変革は、現代のビジネスが直面する次の主な課題に対応します。

• Zero Trust の実践で、任意のユーザーから任意のリソースへのアクセスを保護する
• マルチチャネルフィッシングやランサムウェア攻撃を含むサイバー脅威から防御する
• 規制に準拠し、漏洩を防ぐためにデータを保護する
• オフィス、データセンター、クラウド環境にわたる接続を簡素化する

Cloudflare One は、Cloudflare の connectivity cloud ↗ の上に構築されています。これは、すべてのネットワーク（エンタープライズとインターネット）、クラウド環境、アプリケーション、ユーザーの間の任意対任意の接続を可能にする、プログラマブルなクラウドネイティブサービスの統合されたインテリジェントなプラットフォームです。世界最大級のネットワーク ↗ の 1 つであり、データセンターは 世界数百都市 ↗ にわたり、over 13,000 network peers と相互接続しています。主要な Internet Exchange ↗ における存在感も、多くの大規模テクノロジー企業より大きいです。

その結果、Cloudflare は世界のインターネット接続人口の約 95% から約 50 ms 以内で運用しています。すべての Cloudflare サービスはすべてのネットワークロケーションで動くように設計されているため、すべてのトラフィックはソースの近くで接続、検査、フィルタされ、最高のパフォーマンスと一貫したユーザー体験を提供します。

このドキュメントは、SASE アーキテクチャへ進む組織向けのリファレンスアーキテクチャを説明し、Cloudflare One がそのようなセキュリティとネットワーキングの変革をどう可能にするかを示します。

このリファレンスアーキテクチャは、組織の既存インフラに何らかの責任を持つか、なじみがある IT またはセキュリティの専門家向けです。ハイブリッドワークの保護に重要な技術の経験があると役立ちます。IdP、ユーザーディレクトリ、SSO、エンドポイントセキュリティまたは管理（EPP、XDR、UEM、MDM）、ファイアウォール、ルーター、パケットまたはコンテンツ検査ハードウェア、脅威防止、データ損失防止技術などのポイントソリューションです。

Cloudflare の基礎理解を深めるには、次のリソースを推奨します。

• Cloudflare とは？ | Web サイト ↗（約 5 分）または 動画 ↗（約 2 分）

• ソリューションブリーフ: Cloudflare One ↗（3 分の読み物）
• ホワイトペーパー: Overview of Internet-Native SASE Architecture ↗（10 分の読み物）
• ブログ: Zero Trust, SASE, and SSE: foundational concepts for your next-generation network ↗（14 分の読み物）

このリファレンスアーキテクチャを読むと、次を学べます。

• Cloudflare One が組織の従業員、デバイス、アプリケーション、データ、ネットワークをどう保護するか
• Cloudflare One が既存インフラにどう収まり、SASE アーキテクチャへの移行にどう取り組むか
• Cloudflare One のデプロイをどう計画するか

このドキュメントは技術レベルで Cloudflare One を検討しますが、プラットフォーム内のすべての製品の細かい詳細は扱いません。代わりに、Cloudflare One のすべてのサービスが、ネットワーキングとネットワークセキュリティを 1 つのアーキテクチャにどうまとめられるかを見ます。製品領域または用途に固有の詳細は、開発者ドキュメント ↗ を参照してください。

従来、ほとんどの従業員はオフィスで働き、Ethernet または Wi-Fi で社内ネットワークにローカル接続していました。ほとんどの業務システム（ファイルサーバー、プリンター、アプリケーションなど）はこの内部ネットワーク上にあり、そこからだけアクセスできました。接続後、ユーザーは通常、ローカルリソースへ広いアクセスを持ちました。公開インターネットからの外部脅威から保護するため、ネットワークの周りにセキュリティ境界が作られました。ほとんどの業務ワークロードはオンプレミスでホストされ、ネットワーク内部からだけアクセスできました。インターネット上に会社のデータやアプリケーションはほとんど、またはまったくありませんでした。

しかし、3 つの重要な潮流が、この「城と堀」型の IT セキュリティに問題を生みました。

1. 従業員がよりモバイルになった。 組織はリモート / ハイブリッドワークをますます受け入れ、個人（会社所有でない）デバイスの利用をサポートします。
2. クラウド移行が加速した。 組織は、柔軟性、スケーラビリティ、費用対効果を上げるため、高価なオンプレミスデータセンターからパブリックまたはプライベートクラウド環境へ、アプリケーション、データ、インフラを移しています。
3. サイバー脅威が進化した。 上記の潮流は組織の攻撃面を広げます。たとえば、攻撃キャンペーンは複数チャネルを悪用して組織に侵入する、より巧妙で持続的になりました。サイバー犯罪者は、「cybercrime-as-a-service」の闇市場の普及により、参入障壁が低くなりました。

従来の境界ベースのセキュリティは、これらの変化への適応に苦戦してきました。特に「堀」を外側へ広げることは、管理者の運用複雑さ、ユーザーの体験の悪化、ユーザーとアプリケーションにわたるセキュリティ制御の適用の不一貫を招きました。

上の図は、この適応した境界ベースのアプローチの例です。ファイアウォール、WAN ルーター、VPN コンセントレーターが、MPLS 回線および / または専用線で構成される専用 WAN オンランプで接続されています。図はよくある問題領域も示します。ポリシーを中央化しようとする組織は、従業員のすべてのインターネットトラフィックを VPN インフラ経由に強制することがあり、ブラウジングが遅くなり、ユーザーの不満につながります。従業員は未承認デバイスの使用などの回避策を探し、在宅勤務や公衆 Wi-Fi でインターネット由来の攻撃への露出が増えます。加えて、IT チームはネットワークインフラの複雑さのため、変化するビジネスニーズへすばやく対応できません。

このような課題により、多くの組織は次の目標を優先します。

• 安全な任意対任意アクセスでリモート / ハイブリッドワークをサポートし、ビジネスの機敏性を加速する
• ポリシー管理を簡素化し、ユーザー体験を効率化し、生産性を上げる
• すべてのチャネルでフィッシング、ランサムウェア、その他の脅威からユーザーとデータを保護し、サイバーリスクを減らす
• ネットワーキングとセキュリティにわたる可視性と制御をまとめる
• 高価なアプライアンスとインフラ（VPN、ハードウェアファイアウォール、MPLS 接続など）を置き換えてコストを減らす

近年、セキュアアクセスサービスエッジ ↗、つまり SASE が、これらの目標達成を助ける志向アーキテクチャとして現れました。SASE アーキテクチャでは、ネットワーク接続とセキュリティが単一のクラウドプラットフォームとコントロールプレーンに統一され、任意のユーザーから任意のアプリケーションまで一貫した可視性、制御、体験を提供します。

SASE プラットフォームは、ネットワーキングとセキュリティのサービスで構成され、すべてを支える運用サービスとポリシーエンジンがあります。

• ネットワークサービスは、さまざまなネットワークからのトラフィックを単一のグローバルな企業ネットワークへ転送します。ファイアウォール、ルーティング、ロードバランシングなどの能力を提供します。
• セキュリティサービスは、ネットワーク上を流れるトラフィックに適用され、特定種類のトラフィックのフィルタと、誰が何にアクセスできるかの制御を可能にします。
• 運用サービスは、ログ、API アクセス、Terraform などのプロバイダーによる包括的な Infrastructure-as-Code サポートなど、プラットフォーム全体の能力を提供します。
• ポリシーエンジンはすべてのサービスにわたって統合され、管理者がポリシーを定義し、接続されたすべてのサービスに適用できます。

ほとんどの組織は、一度にではなく段階的に SASE アーキテクチャへ進みます。主要なセキュリティと接続の用途を優先し、Zero Trust Network Access ↗（ZTNA）や Secure Web Gateway ↗（SWG）などのサービスを採用します。一部の組織は複数ベンダーの SASE サービスを選びます。ただし、ほとんどの組織では、簡素化された管理、包括的な可視性、一貫した体験を達成するため、単一ベンダーでセキュリティをまとめることが志向です。

Cloudflare One ↗ は単一ベンダーの SASE プラットフォームで、すべてのサービスがすべてのロケーションで動くように設計されています。すべてのトラフィックはソースの最も近くで検査され、どこでも一貫した速度と規模を提供します。組み合わせ可能で柔軟なオンランプにより、任意のソースからのトラフィックを任意の宛先へルーティングできます。

Cloudflare の connectivity cloud は、アプリケーションのパフォーマンスとセキュリティを向上させる他の多くのサービスも提供します。API Gateway ↗、Web Application Firewall ↗、Content Delivery ↗、DDoS 緩和 ↗ などです。これらはすべて組織の SASE アーキテクチャを補完できます。たとえば、Content Delivery Network（CDN）機能を使い、自前ホストの社内イントラネットのパフォーマンスを向上できます。Cloudflare のサービスの全範囲は下図のとおりです。

Cloudflare の SASE プラットフォームは、anycast ↗ 技術の利用から恩恵を受けます。Anycast により、Cloudflare は世界中のすべてのデータセンターからサービスの IP アドレスを告知でき、トラフィックは常にソースに最も近い Cloudflare データセンターへルーティングされます。これは、トラフィック検査、認証、ポリシー適用がエンドユーザーの近くで行われることを意味し、一貫して高品質な体験につながります。

anycast を使うと、Cloudflare ネットワークの負荷がよく分散されます。ネットワーク上のトラフィックが急増しても、負荷を複数データセンターに分散できます。これが、ユーザーの一貫した信頼性の高い接続の維持に役立ちます。さらに、Cloudflare の大きな ネットワーク容量 ↗ と AI/ML 最適化スマートルーティング ↗ も、パフォーマンスが常に最適化されるのに役立ちます。

対照的に、多くの他の SASE プロバイダーは Unicast ルーティングを使います。単一の IP アドレスが単一のサーバーおよび / またはデータセンターに紐付きます。そのようなアーキテクチャの多くでは、単一の IP アドレスが特定のアプリケーションに紐付き、そのアプリケーションへのアクセスリクエストは、トラフィックがどれだけ遠くまで移動する必要があるかによって、非常に異なるネットワークルーティング体験になることがあります。たとえば、アプリケーションのサーバーの隣のオフィスで働く従業員にはパフォーマンスが優れ、リモート従業員や海外勤務者には劣ることがあります。Unicast はトラフィック負荷のスケーリングも複雑にします。その単一のサービス場所が負荷増加時にリソースを増やす必要がある一方、anycast ネットワークは多くのデータセンターと地理にわたってトラフィックを共有できます。

SASE が組織の IT インフラにどう収まるかを理解するには、下図を参照してください。インフラの一般的な構成要素をすべて図示しています。このガイドの以降のセクションは図に追加し、Cloudflare の SASE プラットフォームの各部分がどこに収まるかを示します。

図の上半分には、さまざまなインターネットリソース（Facebook など）、SaaS アプリケーション（ServiceNow など）、infrastructure-as-a-service（IaaS） ↗ プラットフォーム（AWS など）で動くアプリケーションがあります。この例の組織は、Zero Trust イニシアチブの一環として、すでにクラウドベースの IdP ↗、unified endpoint management ↗（UEM）、エンドポイント保護プラットフォーム（EPP）をデプロイしています。

下半分には、さまざまなユーザー、デバイス、ネットワーク、ロケーションがあります。ユーザーは家庭、本社とブランチオフィス、空港など、さまざまな場所で働きます。使うデバイスは組織が管理するものか、個人デバイスかもしれません。クラウドに加えて、アプリケーションは組織の本社のデータセンターと、データセンター事業者のコロケーション施設（この例では Equinix ↗）でも動きます。

SASE アーキテクチャは、各ユーザーとデバイスが図内のさまざまなリソースにどう接続するかを定義し、保護し、効率化します。以降のセクションでは、Cloudflare One を上記インフラへ統合する方法を示します。

• アプリケーションとサービス: プライベートアプリケーションとサービスへのアクセスを Cloudflare の背後に置く
• ネットワーク: ネットワーク全体を Cloudflare に接続する
• デバイストラフィックの転送: 任意のデバイスから Cloudflare 保護リソースへのアクセスを容易にする
• ユーザーとデバイスの検証: アクセスリクエストがどのユーザーから来るか、そのユーザーがどのデバイスを持つかを識別する

SASE アーキテクチャへの旅は、インターネット非公開の社内専用 Web アプリケーションとサービス（SSH や RDP など）へのリモートアクセスを提供する必要から始まります。組織は通常、アプリケーションがホストされる社内ネットワークへユーザーを接続するために VPN アプライアンスをデプロイします。しかし、多くのアプリケーションは現在、従来の VPN ソリューションの構成が難しいクラウド IaaS プラットフォームにあります。これは、ユーザーのアプリケーションと接続のパフォーマンスの悪化につながることがよくあります。

Zero Trust Network Access ↗（ZTNA）は、セルフホストアプリケーションとサービスへのアクセスを保護する SASE サービスです。ZTNA の機能は大きく 2 つに分けられます。1 つは Cloudflare のネットワークとアプリケーションが動く環境の間の接続を確立すること、もう 1 つはユーザーがこれらのアプリケーションにどうアクセスできるかを定義するポリシーを設定することです。このセクションでは、まず前者、アプリを Cloudflare に接続する方法を検討します。

セルフホストアプリケーションへの接続は、ソフトウェアコネクタ cloudflared が作成して維持するトンネルで容易になります。cloudflared は組織のインフラにインストールされる軽量デーモンで、Cloudflare のグローバルネットワークへのアウトバウンド接続経由でトンネルを作成します。コネクタはさまざまな方法でインストールできます。

• ベアメタルサーバーにインストールされた OS 内
• 仮想化環境で動く OS 内
• Docker または Kubernetes 環境で動く コンテナ ↗ 内

cloudflared は Windows、Linux、macOS で動き、UDP（TCP ではなく）を使う現代のプロトコル QUIC で暗号化トンネルを作成し、高速なトンネル性能と現代の暗号化規格を提供します。一般に、ユーザーが環境に cloudflared をデプロイする方法は 2 つあります。

1. アプリケーションまたはサービスが動いているのと同じサーバーと OS 上。 これは通常、アプリケーションごとに独立したトンネルを必要とする高リスクまたはコンプライアンス導入です。cloudflared の CPU と RAM 消費は小さいため、サーバー性能への影響はわずかです。
2. アプリケーションが動く同じネットワーク内の専用サーバー上。 これは多くの場合、Docker または Kubernetes 環境の複数コンテナの形を取ります。

cloudflared は Cloudflare への複数のアウトバウンド接続を管理し、通常はネットワークファイアウォールの変更は不要です。それらの接続は信頼性とフェイルオーバーのため、複数の Cloudflare データセンターのサーバーに分散されます。トンネル宛てのトラフィックは、リクエストに地理的に最も近い接続へ転送されます。cloudflared 接続が応答しない場合、トンネルは次に利用可能な接続へ自動フェイルオーバーします。

各トンネル接続経由でルーティングされるトラフィックをより細かく制御するには、Cloudflare の ロードバランシング サービスと統合できます。信頼性の高いローカル接続を確保するため、組織はアプリケーションインフラにわたって cloudflared のインスタンスを複数デプロイすべきです。たとえば、Kubernetes クラスターで 10 台のフロントエンド Web サーバーが動いている場合、cloudflared レプリカを実行する Kubernetes サービスを 3 つデプロイする、といった具合です。

トンネルが確立されると、ユーザートラフィックをアプリケーションまたはサービスへ転送する方法は 2 つあります。以下の各方法は、認証とアクセスを強制する ZTNA サービスが管理するポリシーで保護されます（このドキュメントの後半 でさらに詳しく検討します）。

各パブリックホスト名は、プライベートアプリケーションに関連するアドレス、プロトコル、ポートに固有です。同じホストで複数のアプリケーションが動いているときに、特定サービスへの狭いアクセスを許可します。

たとえば、組織はパブリックホスト名（mywebapp.domain.com）を定義して https://localhost:8080 で動く Web サーバーへのアクセスを提供しつつ、ローカル Kubernetes サービスへのアクセスはないようにできます。

主な能力:

• ホスト名が公開 DNS ゾーンに作成され、そのホスト名へのすべてのリクエストはまず Cloudflare ネットワークへルーティングされ、構成済みのセキュリティとアクセスポリシーと照合されたあと、トンネル経由で保護されたプライベートリソースへルーティングされます
• トンネルあたり複数のホスト名を定義でき、各ホスト名は単一のアプリケーション（サービスアドレスとポート）に対応します
• HTTP/HTTPS プロトコルに対応
• リソースへのアクセスにはブラウザーだけが必要です
• ユーザーデバイスに Cloudflare のデバイスクライアントがデプロイされている場合、ポリシーは追加のコンテキストシグナル（デバイスが管理対象か、最新 OS で動いているかなど）をポリシー適用に使えます
• SSH/VNC サービスへのアクセスでは、Cloudflare がブラウザー内の WebAssembly で SSH/VNC ターミナルを描画します

この方法で公開されたアプリケーションは、Cloudflare の主要な DNS、CDN、DDoS サービス、および Web アプリケーションファイアウォール（WAF）、API、ボットサービスの恩恵をすべて受けます。アプリケーションサーバーをインターネットに直接公開する必要はありません。

ユーザーが ZTNA ポリシーを活用して、プライベートネットワーク全体の多くのアプリケーションへのアクセスを提供したい場合もあります。これにより、クライアントの接続方法とサービスの公開方法の柔軟性が増します。HTTP 以外のプロトコルでのリソース通信も可能になります。このシナリオでは、Cloudflare 経由でアクセス可能にしたいプライベートネットワークのサブネットを指定します。

主な能力:

• cloudflared は Cloudflare デバイスエージェントと組み合わせて、プライベートネットワークへのアクセスを提供し、任意の L4 TCP、UDP、または ICMP 接続を許可します
• CIDR 記法（例: 172.21.0.16/28）を使って 1 つまたは複数のネットワークを構成できます
• プライベートネットワーク上のリソースへのアクセスには、クライアントへの Cloudflare デバイスエージェントのインストールと、接続ネットワーク上の少なくとも 1 つの Cloudflare Tunnel サーバーが必要です

どちらの方法でも、cloudflared がプロキシするのはプライベートアプリケーションまたはネットワークへのインバウンドトラフィックだけであることに注意してください。プロキシ先のネットワークから Cloudflare へ戻るゲートウェイまたは「オンランプ」にはなりません。これは、Web サーバーが別のインターネットベースの API への独自接続を開始しても、その接続は Cloudflare Tunnel 経由ではルーティングされず、ホストサーバーのデフォルトルートとゲートウェイ経由でルーティングされることを意味します。

これはほとんどのネットワークトポロジーで望ましい結果です。ただし、ネットワークサービスがリモート接続ユーザー、または他のセグメント化されたネットワーク上のサービスと直接通信する必要がある場合もあります。

サーバーまたはネットワーク起点の接続を Cloudflare 経由でルーティングする必要がある場合は、これを達成する複数のオンランプがあります。「ネットワークを接続する」セクションでさらに説明します。

SaaS アプリケーションは本質的に常に公開インターネットに接続され、そこからアクセスされます。そのため、前述のトンネルとアプリコネクタのアプローチは適用されません。代わりに、SASE アーキテクチャを持つ組織は、クラウドネイティブなフォワードプロキシとして機能する セキュア Web ゲートウェイ ↗（SWG）経由で、インターネット向け SaaS トラフィックを検査し、ポリシーを適用します。

SWG には、アウトバウンドのトラフィックリクエストとインバウンドのコンテンツレスポンスを調べ、ユーザー、デバイス、またはネットワークロケーションがインターネット上のリソースへのアクセスを持つかを判断するポリシーがあります。組織はこれらのポリシーを使い、承認済み SaaS アプリケーションへのアクセスを制御し、未承認アプリケーション（シャドー IT ↗ とも呼ばれる）の使用を検出してブロックできます。

一部の SaaS アプリケーションでは、リクエストのソース IP アドレスに基づいてアプリケーションへのアクセスを制限する IP アドレス許可リストを構成できます。Cloudflare では、組織は専用の egress IP アドレスを取得でき、ネットワークを出るすべてのトラフィックのソースアドレスとして使えます。SaaS アプリケーションの許可リストと組み合わせると、ユーザーがまず Cloudflare に接続している場合にのみアプリケーションにアクセスできるようにできます。（このアプローチの詳細は、ユーザーデバイスの接続に関する後半のセクションで概説します。）

SaaS アプリケーションへのアクセスを保護するもう 1 つの方法は、認証と認可プロセスの一部として、Cloudflare が ID プロキシ（IdP として機能する）になるようにシングルサインオン（SSO）を構成することです。

主な能力:

• セルフホストと SaaS アプリケーションの両方に一貫したアクセスポリシーを適用する
• デバイスセキュリティポスチャを認証プロセスに重ねる（例: 管理対象デバイスで、最新 OS を実行し、すべてのエンドポイントセキュリティチェックを通過したものだけが SaaS アプリケーションにアクセスできるようにする）
• アクセスに特定のネットワークルートを使うことを保証する（例: デバイスエージェントで Cloudflare に接続することを要求し、SaaS アプリケーションへのトラフィックをフィルタし、保護データのダウンロードを防ぐ）
• SSO アプリケーションを Cloudflare にまとめ、Cloudflare から IdP への SSO 連携を 1 つ作成する。インフラとアクセスポリシーの両方を SSO 非依存にする（例: 認証にどの IdP が使われても、MFA が使われた場合にのみ重要なアプリケーションへのアクセスを許可する）

Cloudflare がアプリケーションの SSO サービスとして機能する場合、ユーザー認証は引き続き組織の既存 IdP が処理しますが、Cloudflare 経由でプロキシされ、追加のアクセス制限を適用できます。下図は、典型的なリクエストフローの概要例です。

SaaS アプリケーションを Cloudflare の SASE アーキテクチャに接続する最後の方法は、API ベースの クラウドアクセスセキュリティブローカー ↗（CASB）です。Cloudflare CASB は API 経由で 人気の SaaS スイート（Google Workspace、Microsoft 365、Salesforce など）と連携し、設定ミス、未承認のユーザー活動、その他のセキュリティリスクについてこれらのアプリケーションを継続的にスキャンします。

Cloudflare の データ損失防止 ↗（DLP）サービスとのネイティブ統合により、CASB は権限が正しくないファイルに保存されている可能性のある機密または規制対象データをスキャンできます。CASB は、IT チームに次のような項目を警告する検出結果を報告します。

• 十分な MFA がない管理アカウント
• 公開アクセス権限で保存されたファイル内の会社の機密データ
• 不足しているアプリケーション構成（SPF/DMARC レコードがないドメインなど）

これが、Cloudflare サービスと連携したあとの典型的な組織のアーキテクチャです。Cloudflare は次の方法で、組織の既存アプリケーションとサービスを保護するように設計されていることに注意してください。

• すべてのセルフホストアプリケーションとサービスは Cloudflare 経由でのみアクセスでき、Cloudflare ZTNA が定義するポリシーで制御されます
• SaaS アプリケーションのトラフィックは Cloudflare SWG 経由でフィルタされ、保護されます
• SaaS サービスは Cloudflare CASB 経由でスキャンされ、保存データの構成と権限が確認されます

組織のアプリケーションとサービスが統合されたら、既存ネットワークを Cloudflare に接続する番です。地域オフィス、本社、小売拠点、データセンター、クラウドホストのインフラはすべて、新しい企業 SASE ネットワークへトラフィックを転送する必要があります。

すべてのトラフィックが Cloudflare を流れると、SASE サービスは次の操作を実行します。

• アプリケーションアクセスの付与
• 一般的なインターネット向けトラフィックのフィルタ（マルウェアをホストするサイトへのアクセスのブロックなど）
• Web サイトを分離し、デイゼロまたは未知の有害なインターネットコンテンツからユーザーを保護する
• DLP ポリシーで定義されたデータを識別するためにトラフィックをフィルタし、安全でないデバイスまたはアプリケーションへのそのデータのダウンロード / アップロードをブロックする
• 未承認アプリケーションの使用の可視性を提供し、管理者がブロックするか、使用に関するポリシーを適用できるようにする

ネットワークを Cloudflare に接続するアプローチはいくつかあり、組織が SASE 保護リソースへのアクセスを提供する方法にさらに柔軟性を与えます。

1. ソフトウェアエージェントを使い、ホストマシンから Cloudflare へトンネルを作成する。 これは通常、自前のサーバーとアプリケーションを所有するユーザーが好む方法です。
2. ネットワークルーターとファイアウォールから IPsec または GRE トンネルを設定し、Cloudflare WAN サービスに接続する。 これは、ネットワーク全体との間でトラフィックを転送したいネットワーク管理者が使うアプローチです。
3. ネットワークを Cloudflare に直接接続する。 この方法は、組織のネットワークが対応データセンター、通常は Cloudflare データセンターとコロケーションしている場所にあるときに最もよく機能します。

これらの方法は次のセクションでさらに説明します。

現在ネットワーク上にあるアプリケーションの種類に応じて、ネットワークを Cloudflare に接続するソフトウェアベースの方法は 2 つあります。

前のセクションで説明したとおり、cloudflared はプライベートネットワーク上のアプリケーションとサービスへのリクエストをプロキシします。プライベートネットワーク内のサーバーにインストールされ、インターネット越しに Cloudflare への安全なトンネルを作成します。これらの接続は信頼性のため複数の Cloudflare データセンターに分散され、複数のコネクタ経由で作成でき、トンネルの容量増加に役立ちます。

cloudflared を使うと、Cloudflare Tunnel はトンネル越しのクライアントからサーバーへの接続に対応します。トンネル背後で動く任意のサービスまたはアプリケーションは、アウトバウンド接続の開始時にデフォルトのルーティングテーブルを使います。

このモデルは、外部ユーザーが双方向開始の通信を必要としないプライベートネットワーク内のリソースにアクセスする必要がある、大多数のシナリオに適します。

双方向、またはメッシュ接続では、組織は Cloudflare Mesh を使うべきです。

Cloudflare Mesh（旧 WARP Connector）は、基盤となるネットワークルーティングインフラの変更を必要としない、サイト間、双方向、メッシュネットワーキング接続向けの軽量ソリューションです。Cloudflare Mesh は組織のネットワーク内の Linux サーバーにインストールされ、Cloudflare へトラフィックをオンランプする必要がある他のローカルネットワークのゲートウェイになります。

これにより、Microsoft の System Center Configuration Manager（SCCM）、Active Directory サーバー更新、VOIP と SIP トラフィック、複雑な CI/CD パイプライン連携を持つ開発者ワークフローなどのサービスをサポートする軽量ソリューションが得られます。cloudflared と Cloudflare WAN（旧 Magic WAN）を補完して実行するか、Cloudflare ネットワークへのスタンドアロンのリモートアクセスおよびサイト間コネクタとして使えます。

Cloudflare Mesh はユーザー対ネットワークとネットワーク対ネットワークの両方の接続をプロキシできます。または、Carrier Grade NAT（CGNAT ↗）アドレス付きエンドポイントのオーバーレイネットワークを確立し、CGNAT IP 範囲を使って確立済みリソースへの安全で直接的な接続を提供できます。これは、重複するネットワーク IP 範囲の課題、ポイントソリューションのアクセス問題、より大きな基盤システムに影響せずにネットワーク設計を移すプロセスへの対応に役立ちます。

注: この画像のラベルは以前の製品名を反映していることがあります。

cloudflared 経由の Cloudflare Tunnel は、プライベートネットワーク上のアプリケーションとサービスへユーザーを接続する主な方法です。多くのアプリケーション所有者にとって、IPsec ↗ や GRE ↗ のような IP トンネルベースの接続技術より、より単純で粒度が細かく機敏なソリューションだからです。Cloudflare Mesh は、組織が基盤となるネットワークルーティングまたはエッジインフラを変更したくない場合の、メッシュまたはその他のソフトウェア定義ネットワーキング向けの推奨方法です。その多くは双方向接続を必要とします。

ソフトウェアエージェントのインストールが最適でない、または不可能な場合、既存のネットワーク機器（ルーターやネットワークファイアウォールなど）を使ってネットワークを Cloudflare に接続することもできます。そのためには、組織は Cloudflare のクラウドネイティブ Cloudflare WAN ↗ サービスに接続する IPsec または GRE トンネルを作成します。Cloudflare WAN では、既存のネットワークハードウェアが、a) インターネット越しの安全な IPsec ベースのトンネル、または b) Cloudflare Network Interconnect ↗（CNI）— 既存のネットワークロケーションを最も近い Cloudflare データセンターに結ぶプライベートな直接接続 — を通じて、それぞれのネットワークロケーションから Cloudflare へ接続し、トラフィックをルーティングできます。

Cloudflare の WAN サービスは、「ライトブランチ、ヘビークラウド」アーキテクチャを使い、ソフトウェア定義 WAN（SD-WAN）接続の進化を表します。下のネットワークアーキテクチャ図が示すとおり、Cloudflare WAN では Cloudflare グローバルネットワークが中央管理された接続ハブとして機能し、既存のすべてのネットワークロケーション間でトラフィックを安全かつ効率的にルーティングします。

前述のとおり、Cloudflare は anycast ↗ と呼ばれるルーティング技術を使い、WAN IP トンネルのエンドポイントを含む、Cloudflare ネットワーク上のすべてのサービスとエンドポイントをグローバルに告知します。

anycast IPsec ↗ または anycast GRE トンネルでは、組織のネットワークデバイス（エッジルーター、ファイアウォールアプライアンスなど）から構成された各トンネルが、世界数百の Cloudflare データセンターに接続します。組織のネットワークロケーションから送られたトラフィックはこれらのトンネル経由で直接送られ、常に最も近いアクティブな Cloudflare データセンターへルーティングされます。最も近い Cloudflare データセンターが利用できない場合、トラフィックは次に近いデータセンターへ自動再ルーティングされます。

ネットワークの耐障害性をさらに高めるため、Cloudflare WAN は Cloudflare ネットワークと組織のネットワークロケーションの間の Equal Cost Multi-Path（ECMP）ルーティングにも対応しています。ECMP では、トラフィックを複数の anycast IP トンネルにわたって負荷分散でき、スループットの増加とネットワーク信頼性の最大化に役立ちます。1 つ以上のトンネルのネットワークパス障害時は、残りの健全なトンネルへトラフィックを自動フェイルオーバーできます。

既存のネットワークロケーションを Cloudflare WAN サービスへオンランプする最も単純で簡単な方法は、Cloudflare One Appliance をデプロイすることです。企業ネットワークロケーションにインストールできる軽量アプライアンスで、安全な IPsec トンネル経由で任意の IP トラフィックを自動接続、ステア、シェーピングします。WAN Connector がネットワークにインストールされると、Cloudflare ネットワークとの通信を自動確立し、関連構成をダウンロードしてプロビジョニングし、耐障害性のある IPsec トンネルを確立し、接続されたサイトのネットワークトラフィックを Cloudflare へルーティングします。

WAN Connector はハードウェアまたは仮想アプライアンスとしてデプロイでき、オンプレミス、仮想、パブリッククラウドなど、さまざまなユーザーネットワーク環境に対応します。WAN Connector の管理、構成、可観測性、ソフトウェア更新は、ダッシュボードまたは Cloudflare API 経由で Cloudflare から中央管理されます。2023 年時点では、WAN Connector は小中規模ネットワーク（小規模オフィスや小売店など）を Cloudflare に接続するのに最も適しています。

Cloudflare One Appliance のデプロイが現実的でない、または望ましくない状況では、組織は既存の IPsec 対応ネットワークデバイス（WAN または SD-WAN ルーター、ファイアウォール、クラウド VPN ゲートウェイを含む）から IPsec トンネルを構成し、サイトネットワークを Cloudflare に安全に接続できます。検証済み IPsec デバイスの最新例は Cloudflare の ドキュメント を参照してください。

ネットワーク層の暗号化が不要な状況もあります。たとえば、サイトの WAN 向けトラフィックがすでにアプリケーション層（TLS 経由）で暗号化されている場合、または IPsec ネットワークデバイスが IPsec トラフィックの暗号化と復号でスループット性能が非常に限られる場合です。このような状況では、組織は GRE トンネル を使って Cloudflare ネットワークに接続できます。

組織は Cloudflare Network Interconnect ↗（CNI）経由で、ネットワークロケーションを Cloudflare ネットワークに直接接続することもできます。Cloudflare は、ネットワークを Cloudflare に接続する さまざまなオプション に対応しています。

• Cloudflare WAN と Magic Transit 向けの Direct CNI
• Magic Transit 向けの Classic CNI
• Cloudflare WAN と Magic Transit 向けの Cloud CNI
• インターネットエクスチェンジ、またはプライベートネットワーク相互接続（PNI）経由のピアリング

次の表は、ネットワークを Cloudflare に接続する異なる方法を要約します。

これらの接続とルーティング方法は、任意のロケーションから同時にデプロイできます。次の図は、単一アーキテクチャで異なる接続方法をどう使えるかを示します。

次のトラフィックフローに注意してください。

• Cloudflare Mesh ノードまたはデバイスエージェント経由で接続されたすべてのトラフィックは、メッシュネットワーク上で互いに通信できます
  • 在宅の開発者は、クラウド内の本番およびステージングサーバーと通信できます
  • 小売拠点の従業員と在宅の開発者は、ラップトップで VOIP 通話を受け取れます
• AWS 内の HPC クラスターは、サードパーティのソフトウェアエージェントをインストールできない独自ソリューションを表します。そのため Cloudflare WAN への IPsec 接続を使います
• 小売拠点では、Cloudflare One Appliance が IPsec トンネル経由ですべてのトラフィックを Cloudflare へルーティングします
  • デバイスエージェントを実行する従業員のラップトップは、IPsec トンネル上でルーティングされる Cloudflare への独自の安全な接続を作成します
• レポートシステムのアプリケーション所有者は、cloudflared を使って Cloudflare への接続を維持し、アプリケーションを従業員に公開するためにネットワーキングの助けを必要としません

注: この画像のラベルは以前の製品名を反映していることがあります。

注: Cloudflare Mesh またはデバイスエージェント経由で接続されたすべてのエンドポイントは、100.96.0.0/12 アドレス範囲から自動で IP アドレスが割り当てられます。Cloudflare WAN に接続されたエンドポイントは、割り当てられた RFC1918 プライベート IP アドレスを保持します。cloudflared は、アプリケーション所有者が任意のロケーションにデプロイし、アプリケーションへのホスト名ベースの接続を提供できます。

ネットワーク、アプリケーション、ユーザーデバイスが Cloudflare に接続されると、接続方法とデバイスに関係なく、すべてのトラフィックを Cloudflare SASE サービスが検査、認証、フィルタし、意図した宛先へ安全にルーティングできます。加えて、Cloudflare への到着方法に関係なく、すべてのトラフィックに一貫したポリシーを適用できます。

これが、あらゆる場所からの企業ネットワークトラフィックが Cloudflare へ転送され、処理される SASE アーキテクチャです。このアーキテクチャでは、任意のリモートロケーション、オフィスローケーション、データセンターからネットワーク接続を行い、SaaS インフラ、クラウドホストインフラ、または組織自身のオンプレミスデータセンターにあるアプリケーションとサービスに接続できます。

注: この画像のラベルは以前の製品名を反映していることがあります。

前のセクションでは、ZTNA でセルフホストアプリケーションへのアクセスを保護し、SWG でインターネット向けトラフィックを検査してフィルタする方法を説明しました。Cloudflare の connectivity cloud に接続された会社ネットワークのいずれかにいるデバイスでユーザーが作業しているとき、そのトラフィックはすべて検査され、ユーザーのワークフローを中断せずにポリシーが適用されます。しかし、ユーザーは常に（あるいは一度も）オフィスにいるわけではありません。在宅、移動中、または他の公開ネットワークから働きます。内部アプリケーションへの信頼性の高いアクセスをどう確保しますか。勤務地に関係なく、インターネットブラウジングの安全性をどう確保しますか。

Cloudflare 保護ネットワークに接続されていないユーザーデバイスからのトラフィックも Cloudflare 経由で転送され、保護されるようにするアプローチはいくつかあります。

• デバイスにエージェントをインストールする
• ブラウザーのプロキシ構成を変更する
• ユーザーをリモートブラウザーインスタンスへ誘導する
• DNS 構成を変更する

デバイストラフィックが Cloudflare へ転送されることを確保する推奨方法は、デバイスエージェント（Cloudflare One Client とも呼ばれる）をインストールすることです。エージェントは Windows、macOS、Linux、iOS、Android/ChromeOS で動き、ローカルでないすべてのトラフィックが送られる Cloudflare への安全な接続を作成します。Cloudflare の anycast ネットワーキングの利用により、デバイスエージェントは常に最も近い Cloudflare サーバーに接続し、ユーザーに最高のパフォーマンスを保証します。デバイスエージェントはローカルマシンとネットワーク情報も収集し、リクエストに含めて Cloudflare のポリシーを豊かにします。

異なるデバイスとユーザーの接続方法に柔軟性を持たせるため、複数の デプロイモード があります。

• 完全な L4 トラフィックプロキシ
• L7 DNS プロキシ
• L7 HTTP プロキシ
• デバイスポスチャ情報だけを収集する能力

たとえば、組織が既存の DNS フィルタ ↗ サービスを使い続けるオフィスを持っている場合、エージェントをネットワークと HTTP トラフィックだけをプロキシするように構成できます。

エージェントは柔軟なルーティング制御でも構成でき、オフィスプリンター宛てのトラフィックを Cloudflare ネットワークへ送らず、ローカルネットワークへルーティングするシナリオを許可します。これらの スプリットトンネル構成 は、ユーザーグループ、デバイス OS の種類、またはネットワークに固有にできます。デフォルトでは、すべてのプライベート IPv4 および IPv6 範囲 ↗ 宛てのトラフィックはデバイスのデフォルトゲートウェイへ送られます。ユーザーが到達しようとしているアプリケーションが公開 DNS にない場合、ホスト名とドメインを ローカル DNS サービス で解決するように構成でき、デバイスエージェントが Cloudflare DNS でこれらを解決しようとしません。

エージェントはネットワークプロキシ以上のものです。OS が完全に最新か、ハードディスクが暗号化されているかなど、デバイスのセキュリティポスチャを調べられます。CrowdStrike ↗、SentinelOne ↗、その他のサードパーティサービスとの Cloudflare の連携も、デバイスのセキュリティポスチャに関する追加データを提供します。この情報はすべて各リクエストに関連付けられ、したがって会社ポリシーで使えます。「統合管理」セクションで説明します。

エージェントは、手動または既存のエンドポイント管理（UEM）技術を使ってデバイスに デプロイ できます。エージェントを使い、ユーザーは統合された IdP でデバイスを Cloudflare に登録して認証します。ID 情報はローカルデバイスに関する情報と組み合わされ、SWG と ZTNA ポリシー（これらの Cloudflare サービス間で共有されるインライン CASB 能力を含む）で使われます。

デバイスにソフトウェアをインストールできない場合、エージェントレスのアプローチがあります。

1 つのオプションは、ブラウザーまたは OS でプロキシサーバーの詳細を構成し、HTTP リクエストを Cloudflare へ転送するようにブラウザーを構成することです。手動でもできますが、インターネットホストの Proxy Auto-Configuration（PAC）ファイルを使ってブラウザープロキシ設定を自動構成するほうが一般的です。ブラウザーはいくつかの方法で PAC ファイルの場所を識別します。

• MDM ソフトウェアがブラウザーの設定を構成する
• Windows ドメインでは、グループポリシーオブジェクト（GPO）がブラウザーの PAC ファイルを構成できる
• ブラウザーは Web Proxy Auto-Discovery ↗（WPAD）を使える

そこから、ブラウザーがすべての HTTP リクエストを送るプロキシエンドポイントを構成します。この方法を使う場合、次に注意してください。

• HTTPS トラフィックのフィルタには、デバイスへの Cloudflare ルート証明書のインストールと信頼 も必要です。
• プロキシエンドポイントは、サイトの NAT ゲートウェイが使う公開 IP アドレスプールなど、管理者が指定する必要がある既知の IP アドレス集合から発信されたトラフィックだけをプロキシします。

デバイストラフィックが Cloudflare へ送られることを確保するもう 1 つのオプションは、リモートブラウザー分離 ↗（RBI）を使うことです。リモートユーザーが Web サイトを訪問しようとすると、対応するリクエストとレスポンスは、ユーザーデバイスのローカルブラウザーの「クローン」として機能する、Cloudflare ネットワーク内のヘッドレスリモートブラウザーが処理します。これにより、訪問する Web サイトからダウンロードされる可能性のある有害なコンテンツとコード実行からユーザーのデバイスを守ります。

RBI は、受信したコンテンツを分離された安全なクラウド環境で描画します。Web コンテンツをローカルで実行する代わりに、ユーザーデバイスは、すべての OS のすべての HTML5 準拠ブラウザーがサポートする高度に最適化されたプロトコル経由で、最終的に描画された Web ページを「描く」方法のコマンドを受け取ります。リモートブラウザーは Cloudflare のサーバーで動くため、すべてのブラウザーリクエストに SWG ポリシーが自動適用されます。

サイトへのアクセスが RBI で保護されることを確保するために、ローカルソフトウェアのインストールやユーザーのブラウザーの再構成は不要です。これを達成する いくつかの方法 は次のとおりです。

• 通常、リモートブラウザーセッションは SWG ポリシーの結果として開始されます。ユーザーは、コンテンツがリモートブラウザーで読み込まれていることを通知されずに Web サイトをリクエストします。
• 組織は、RBI が各リクエストを常に処理することを自動で保証するリンクをユーザーに提供することもできます。
• 組織は、ZTNA サービスを使い、セルフホストアプリケーションからのすべてのトラフィックを RBI インスタンス経由にリダイレクトすることも選べます。

リモートブラウザー経由のすべてのリクエストは Cloudflare SWG を通過するため、ポリシーは特定の Web サイトアクセス制限を強制できます。たとえば、ブラウザー分離ポリシーを次のように確立できます。

• リモート Web ページとユーザーのローカルマシン間のコピー / ペーストを無効にし、従業員が独自コードをサードパーティのチャットボットに貼り付けるのを防ぐ
• リモート Web コンテンツの印刷を無効にし、コントラクターが機密情報を印刷するのを防ぐ
• ファイルのアップロード / ダウンロードを無効にし、機密の会社データが特定の Web サイトへ送られない、またはそこからダウンロードされないようにする
• （他のポリシーと組み合わせて）キーボード入力を無効にし、フィッシングサイトへのパスワード入力など、データ露出を制限する

Web アプリケーションを分離し、リスクのある Web サイトにポリシーを適用すると、組織はサイバー脅威またはユーザーエラーによるデータ損失を制限できます。Cloudflare One の多くの能力と同様に、RBI は SASE アーキテクチャの他の領域でも活用できます。たとえば、Cloudflare の メールセキュリティ ↗ サービスは、メール内の疑わしいリンクを自動で書き換え、分離できます。この「メールリンク分離」能力は、資格情報収集フィッシングなどの潜在的な悪意ある活動からユーザーを保護するのに役立ちます。

Cloudflare ネットワーク経由でトラフィックを保護するもう 1 つのオプションは、デバイスを構成して DNS トラフィックを Cloudflare へ転送し、検査してフィルタすることです。まず DNS locations を作成し、異なるネットワークロケーションに基づいてポリシーを適用できるようにします。リクエストのソース IP アドレスで判断するか、「DNS over TLS ↗」または「DNS over HTTPS ↗」を使えます。

ソース IP アドレスを使う場合、デバイスにどの DNS サーバーを使うかを伝えるか、デバイスが接続しているネットワーク上のローカル DNS サーバーがすべての DNS クエリを Cloudflare へ転送する必要があります。DNS over TLS または HTTPS 対応では、デバイスの構成が必要で、対応状況は異なります。より広い OS 対応がある DNS over HTTPS の使用を推奨します。

上記の方法はすべて、すべてのトラフィックではなく DNS リクエストだけが Cloudflare へ送られる結果になります。SWG DNS ポリシーはこのレベルで実装され、企業ネットワークリソースへのアクセスを管理します。

次の表は、トラフィックを Cloudflare へ転送するさまざまな方法の SWG 能力を要約します（2023 年 10 月時点）。

注:

1. DNS over HTTP モードでデバイスエージェントを実行すると、ユーザー ID 情報が得られ、DNS 経由の接続と同じ能力に加えて使えます。
2. HTTPS トラフィックをフィルタするには、各デバイスに Cloudflare 証明書 をインストールする必要があります。デバイスエージェントを使うときは自動化できます。
3. DNS over HTTPS を構成する場合、リクエストに サービストークン を注入し、クエリを認証済みユーザーに関連付けられます。

ネットワーク全体または個々のデバイスを接続することで、組織はユーザートラフィックを Cloudflare へルーティングし、プライベートホストアプリケーションへの安全なアクセスと、安全な公開インターネットアクセスを実現できます。

すべてのユーザーデバイスからのトラフィックが Cloudflare ネットワークへ転送されたら、組織は高レベルの SASE アーキテクチャを見直す番です。

注: この画像のラベルは以前の製品名を反映していることがあります。

SASE アーキテクチャ実装のこの時点で、組織は、ユーザーデバイス上のブラウザーからリクエストが出された時点から、Cloudflare のネットワークを通って、会社ホストのプライベートアプリケーション / サービスまたは公開インターネットまで、トラフィックをルーティングして保護できます。

しかし、そのアクセスを管理するポリシーを定義する前に、誰がリクエストしているかを知り、デバイスのセキュリティポスチャを判断する必要があります。

任意のアクセス判断の最初のステップは、誰がリクエストしているか、つまりユーザーを認証することです。

Cloudflare は、組織の従業員、コントラクター、パートナー、その他のユーザーのリソースへの安全なアクセスを管理する IdP と連携します。任意の SAML または OpenID Connect（OIDC）準拠サービスとの連携に対応しています。Cloudflare One には Okta、Microsoft Entra ID（旧 Azure Active Directory）、Google Workspace、および Facebook、GitHub、LinkedIn などのコンシューマー IdP との事前構築された連携もあります。

複数の IdP を統合でき、組織は幅広い内部および外部ユーザーにポリシーを適用できます。ユーザーが Cloudflare で保護されたアプリケーションまたはサービスにアクセスしようとすると、統合された IdP の 1 つ経由で認証するようリダイレクトされます。デバイスエージェントを使う場合、ユーザーは組織が構成した IdP の 1 つでも認証する必要があります。

ユーザーが認証されると、Cloudflare はそのユーザーの情報を受け取ります。ユーザー名、グループメンバーシップ、認証方法（パスワード、MFA が関与したかとその種類）、その他の関連属性（ユーザーのロール、部署、オフィスローケーションなど）です。IdP からのこの情報は、ポリシーエンジンで使えます。

ユーザー ID に加えて、ほとんどの企業ディレクトリにはそれらの ID が属するグループも含まれます。Cloudflare はグループ情報のインポートに対応し、ポリシーの一部として使います。グループメンバーシップは、単一 ID を集約し、ポリシーをより単純にするための重要な部分です。たとえば、営業部門の全従業員が Salesforce にアクセスできるようにするポリシーを設定するほうが、営業組織内の各ユーザーを識別するよりはるかに簡単です。

Cloudflare は、工場の気象条件を監視する IoT デバイスなど、通常は人間のユーザーに関連付けられないデバイスの認証にも対応しています。そのような安全な接続では、組織は サービストークン を生成するか、そのようなデバイスまたはマシンアプリケーションにデプロイできる Mutual TLS ↗（mTLS）証明書を作成できます。

ユーザー ID を検証するだけでなく、ユーザーデバイスのセキュリティポスチャも評価する必要があります。デバイスエージェントはさまざまなデバイス情報を提供でき、Cloudflare はそれを使って包括的なセキュリティポリシーを構築します。

次の組み込みポスチャチェックが利用できます。

• Application check: 特定のアプリケーションプロセスが実行中かを確認します
• File check: ファイルの存在を確認します
• Firewall: ファイアウォールが実行中かを確認します
• Disk encryption: ディスクが暗号化されているか / いくつ暗号化されているかを確認します
• Domain joined: デバイスが Microsoft Active Directory ドメインに参加しているかを確認します
• OS version: 実行中の OS バージョンを確認します
• Unique Client ID: MDM ツールを使うとき、組織はモバイル、デスクトップ、ラップトップデバイスに検証可能な UUID を割り当てられます
• Device serial number: デバイスシリアルが会社のデスクトップ / ラップトップコンピューターの一覧と一致するかを確認します

Cloudflare One は、デプロイ済みのエンドポイントセキュリティソリューション（Microsoft Endpoint Manager、Tanium、Carbon Black、CrowdStrike、SentinelOne など）とも連携できます。それらの製品からの任意のデータを Cloudflare に渡し、アクセス判断に使えます。

上記のすべてのデバイス情報は、ユーザー ID とデバイスが接続しているネットワークのデータと組み合わされ、Cloudflare で会社ポリシーの一部として使えます。たとえば、脅威がなく、最新 OS を実行し、会社ドメインに参加しているデバイスでのみ、管理者がサーバーへ SSH できるように選べます。

この情報はすべてのネットワークリクエストで使えるため、デバイスポスチャが変わるたびに、組織のリソースへの接続能力はすぐに影響を受けます。

多くの組織にとって最大のコミュニケーションツールであり、フィッシング攻撃が最もよく起きるチャネルでもあるメールは、SASE アーキテクチャ経由で保護すべきもう 1 つの重要な企業リソースです。フィッシングは、金銭的損失とブランド損害につながる侵害の 90% 以上の根本原因です。

Cloudflare のメールセキュリティサービスは、受信箱に届く前に悪意あるコンテンツまたは添付の兆候をスキャンし、攻撃者のインフラと攻撃配信メカニズムについてインターネットを積極的にスキャンし、計画された攻撃の一部としてコンテンツをホストするためにプログラムで作成されたドメインを探します。当社のサービスは、このデータをすべて使い、ビジネスおよびベンダーのメール侵害（BEC ↗ / VEC ↗）からも保護します。これらはペイロードがなく、正当なメールトラフィックのように見えるため、検出が非常に難しいことで知られています。

メールサーバーへのトラフィックを管理・制御するためにトンネルをデプロイする代わりに、Cloudflare はメールセキュリティの セットアップ に 2 つの方法を提供します。

• Inline: MX レコードを変更し、ユーザーの受信箱に届く前にすべてのインバウンドメールトラフィックを Cloudflare 経由にリダイレクトする
• API: Microsoft 365 または Gmail などのメールプロバイダーと Cloudflare を直接連携する

MX レコードの変更（インラインデプロイ）は、すべてのインバウンドメールトラフィックを当社のクラウドメールセキュリティサービス経由に強制し、そこでスキャンし、悪意があると判明した場合はユーザーの受信箱への到達をブロックします。サービスは MX レコードレベルで動くため、任意の SMTP 準拠 ↗ メールサービスでメールセキュリティサービスを使えます。

組織は、API 経由でメールセキュリティをメールサービスと直接連携することも選べます。このアプローチには 2 つの欠点があることに注意してください。Cloudflare が対応する連携が少なく、メールがサービスに配信されてから Cloudflare が API 経由で検出するまでに常に小さな遅延があります。

上記のステップは、Cloudflare One を使って SASE アーキテクチャへ進化する完全な見取り図を提供します。下図が示すとおり、すべてのプライベートアプリケーション、サービス、ネットワークへの安全なアクセス、およびユーザーの一般的なインターネットアクセスの安全性の確保が、内部か外部かを問わず、組織のすべてのユーザーに適用されるようになりました。

注: この画像のラベルは以前の製品名を反映していることがあります。

使いやすさのため、Cloudflare One プラットフォーム全体は API 経由で構成できます。Cloudflare の Terraform プロバイダー ↗ を使うと、組織はインフラの残りを自動化するのと同じツールで Cloudflare グローバルネットワークを管理できます。これにより、IT チームは次のセクションで詳述するすべてのポリシーを含む、Cloudflare One インフラ全体をコードで完全に管理できます。また（2023 年 10 月時点で）500 以上の GitHub ↗ リポジトリがあり、その多くは IT チームが Cloudflare デプロイを管理するツールを使い、構築できるようにします。

すべてのユーザー、デバイス、アプリケーション、ネットワーク、その他の構成要素が SASE アーキテクチャ内でシームレスに統合されたので、Cloudflare One は包括的な管理のための中央プラットフォームを提供します。IT インフラ全体にわたる Cloudflare の可視性により、Cloudflare はデバイス、ユーザー、ネットワークを含むさまざまなソースからのシグナルを集約できます。これらのシグナルは、組織リソースへのアクセスを管理するポリシーの作成に情報を与えます。

Cloudflare に接続されたアプリケーション、サービス、ネットワークへのアクセスを管理するポリシーの書き方の詳細に入る前に、Cloudflare の SASE プラットフォームでアクセスを制御する 2 つの主な適用ポイント、SWG と ZTNA サービスを見る価値があります。これらのサービスは単一の管理ダッシュボードで構成され、SASE デプロイ全体のポリシー管理を簡素化します。

次の図は、これらのサービスを通るリクエストの流れを示します。ポリシーの適用と、これらのポリシーのデータの出所を含みます。下図では、ユーザークエストはリクエストされたサービスの種類に応じて SWG または ZTNA から入れます。両方のサービスを組み合わせることもできます。たとえば、ZTNA Cloudflare Tunnel 背後のプライベートホストアプリケーションに関連するトラフィックを検査するために DLP サービスを使う SWG HTTP ポリシーを実装します。この構成により、組織が外部アクセスを認可した内部アプリケーションからの機密データのダウンロードをブロックできます。

以降のセクションでは、特定の用途を満たすために異なるポリシーをどう構成できるかの例を紹介します。これらの例は網羅的ではありません。目標は、Cloudflare One が SASE アーキテクチャへの移行で組織が直面する課題にどう対応できるかを示すことです。

IdP を Cloudflare に接続すると、グループメンバーシップ、認証方法、特定のユーザー属性などの要因に基づいてアクセス判断ができます。Cloudflare のデバイスエージェントは、OS の評価や、デバイスのシリアル番号を会社管理デバイスと照合するなど、ポリシー検討向けの追加シグナルも提供します。ただし、強力なポリシーを構築するためのデプロイに追加データを取り込む機能があります。

Cloudflare の広大なインテリジェントネットワークは、数十億の Web 資産を継続的に監視し、脅威インテリジェンスとインターネットコンテンツの一般知識に基づいて 分類 します。無料の Cloudflare Radar ↗ サービスを使い、特定のドメインにどのカテゴリが適用されるかを調べられます。ポリシーはこれらのカテゴリを含め、公開インターネット上の既知および潜在的なセキュリティリスク、および特定カテゴリのコンテンツをブロックできます。

加えて、Cloudflare の SWG は、カスタマイズした データのリスト を作成して維持する柔軟性を提供します。これらのリストは CSV ファイルでアップロードするか、手動で維持するか、Cloudflare API を使って他のプロセスやアプリケーションと連携できます。リストには次のデータを含められます。

• URL
• ホスト名
• シリアル番号（macOS、Windows、Linux）
• メール
• IP アドレス
• デバイス ID（iOS、Android）

たとえば、組織はすべてのリモートオフィスローケーションの IP アドレスのリスト、短期コントラクターのメールアドレス、信頼できる会社ドメインを維持できます。これらのリストは、既知のオフィス IP アドレスからのトラフィックであればコントラクターが特定のアプリケーションにアクセスできるようにするポリシーで使えます。

Cloudflare は、ソース IP、リクエストされたドメイン、リクエストを開始した認証済みユーザーの ID を含む、リクエストのさまざまな側面を見ます。Cloudflare は、機密コンテンツの存在に基づいてリクエストを検出してブロックできる DLP サービスも提供します。金融情報、個人識別情報（PII）、API キーなど、一般的なデータタイプ向けの組み込み DLP プロファイルがあります。

ソースコード向けのプロファイルもあり、ユーザーは C++ または Python ファイルの転送を検出してブロックできます。組織はカスタマイズした DLP プロファイルを作成し、探しているデータのパターンを定義する正規表現を使えます。パターンを定義しにくいデータには、正確なデータ値に一致するデータセットを使えます。これらのデータセットは、顧客アカウント ID のリストや機密プロジェクト名など、一致させる任意のデータの一括アップロードを許可します。これらのプロファイルとデータセットはポリシーに組み込み、機密の顧客データを含む大きなファイルのダウンロードを防げます。

誤検知のリスクを減らすため、内部ユーザーはプロファイルに一致カウントを設定できます。これは、プロファイルがトリガーされる前に、データ内で特定数の一致が必要であることを意味します。このアプローチは、PII やクレジットカード番号に似たランダムな文字列が不必要にプロファイルをトリガーするシナリオを防ぎます。一致カウントを実装すると、ポリシーは複数のデータ要素がプロファイルに揃うことを求め、精度が大幅に上がります。

コンテキスト分析を有効にすると、DLP プロファイルの精度をさらに上げられます。この機能は、一致の約 1000 文字以内に特定の近接キーワードが存在することを要求します。たとえば、文字列 "123-45-6789" は、"ssn" などのキーワードの近くにある場合にのみ検出として数えられます。この文脈要件は検出プロセスの精度を強化します。

DLP サービスは、Cloudflare の SWG と API 駆動の CASB サービスの両方とシームレスに統合されます。API CASB の場合、各 SaaS アプリケーションとの各連携のスキャン向けに DLP プロファイルが選ばれます。このカスタマイズにより、各アプリケーション内で保護したいデータの種類に基づいて検出基準を調整できます。

SWG サービスでは、ゲートウェイを通過する任意のリクエスト内の機密データの存在を検出するため、DLP プロファイルを任意のポリシーに含められます。この検出に関連する最も一般的なアクションはリクエストのブロックで、堅牢なセキュリティ層を提供します。

Access Groups は、ZTNA サービスでユーザーまたはデバイスを単一のエンティティに集約し、ポリシー内から参照するための強力なツールです。Cloudflare 内では、複数の情報を単一の Access Group に結合でき、複数のポリシーにわたってデータを効率的に再利用しつつ、1 つの中央の場所で維持できます。

重要なサーバーインフラへのアクセスを管理するように設計された Access Group を考えてください。同じ Access Group を、管理者が Cloudflare への接続を無効にできないようにするデバイスエージェントポリシーで使えます。このアプローチはポリシー管理を効率化し、さまざまなポリシー実装にわたる一貫性を確保します。

下図は「Secure Administrators」という Access Group を示し、安全な管理者の特性を定義するさまざまな属性を使います。図は「Secure Administrators」内に他の 2 つの Access Group を追加することを示します。グループには最新の Windows または macOS で動くデバイスが含まれ、デバイスに File Vault または Bitlocker が有効である必要もあります。

Cloudflare の包括的な柔軟性と一貫して、Access Groups は Cloudflare API または Terraform 経由で作成、更新、ポリシーへ適用できます。これにより、既存の IT システムとプロセスとのシームレスな統合が可能になり、アクセス管理への一体的なアプローチが確保されます。

利用可能なすべての構成要素をしっかり理解したので、よくある用途とその構成方法を拡大して見ましょう。Cloudflare のポリシーエンジンは非常に強力で柔軟であることを念頭に置いてください。これらの例は、Cloudflare の SASE プラットフォームの能力の一端にすぎません。

SASE アーキテクチャへ移る一般的な動機の 1 つは、既存の VPN 接続をより柔軟で安全なソリューションに置き換えることです。Cloudflare One SASE アーキテクチャは、世界中のどこからでもセルフホストアプリケーションへの高性能で安全なアクセスを可能にします。ただし、次のステップはリソースへのアクセスを制御するポリシーの定義です。

この例では、2 つのサービスを考えます。データベース管理アプリケーション（例: pgadmin ↗）と、データベースサーバーで動く SSH デーモンです。下図はトラフィックの流れを示し、ZTNA サービスを強調します。他のすべてのサービスが引き続きリクエストを検査できることに注意してください。たとえば、ドイツで個人の携帯電話を使うコントラクターは db 管理ツールへのアクセスだけを持ち、管理対象デバイス上の従業員は db 管理ツールとデータベースサーバーへの SSH の両方にアクセスできます。

アクセスを可能にするポリシーは、2 つの Access Group に依存します。

• コントラクター
  • Okta 経由で認証し、「Contractors」とラベル付けされた Okta グループのメンバーであるユーザー
  • 認証にはハードウェアトークンの使用が必要
• データベースおよび IT 管理者
  • Okta 経由で認証し、Okta グループ「IT administrators」または「Database administrators」に属するユーザー
  • 認証にはハードウェアトークンの使用が必要
  • ユーザーは「Managed Devices」リストにあるシリアル番号のデバイス上にいるべき

これらのグループは、2 つの異なるアクセスポリシーで使われます。

• データベース管理ツールへのアクセス
  • データベースおよび IT 管理者はアクセスを許可される
  • 「Contractor」Access Group のメンバーはアクセスを許可されるが、各認証セッションでユーザーは正当化リクエストを完了する必要がある
  • 管理ツールは Cloudflare のエッジネットワーク上の分離ブラウザーで描画され、ファイルダウンロードは無効
• データベースサーバー SSH アクセス
  • 「Database and IT administrators」グループはアクセスを許可される
  • デバイスは CrowdStrike リスクスコアが少なくとも 80 を通過する必要がある
  • アクセスは、当社のデバイスエージェントを実行し、Cloudflare に接続しているデバイスから来る必要がある

これらのポリシーは、コントラクターがデータベース管理ツールへのアクセスのみを許可され、サーバーへの SSH アクセスを持たないことを示します。IT およびデータベース管理者は、デバイスがデバイスエージェント経由で Cloudflare に安全に接続している場合にのみ SSH サービスにアクセスできます。Access Group とポリシーのすべての要素がすべてのログインで評価されるため、侵害されたラップトップを使う IT 管理者、またはハードウェアトークンで認証できないコントラクターはアクセスを拒否されます。

どちらのユーザーグループも、Cloudflare の世界分散ネットワークの最も近くて速いアクセスポイント経由で Cloudflare に接続し、場所に関係なくすべてのユーザーに高品質な体験をもたらします。

SASE ソリューションを使うもう 1 つの理由は、勤務地に関係なく、組織内のすべてのユーザー（従業員かコントラクターかを問わず）に会社のセキュリティポリシーを一貫して適用することです。Cloudflare One SASE アーキテクチャは、デバイス上で直接ルーティングされるか、接続されたネットワーク経由かを問わず、すべてのユーザートラフィックが Cloudflare を通ることを示します。Cloudflare の SWG がこのトラフィックの検査を担当します。接続方法に応じて、ポリシーは HTTP または DNS リクエストに適用できます。たとえば:

これを 1 つのポリシーですべてのユーザーの保護に適用できます。Cloudflare は、ソーシャルメディア Web サイトへのアクセスを許可しつつ、すべてのセッションを Cloudflare のネットワーク上でホストされるリモートブラウザーで分離する別のポリシーも書けます。

このセットアップでは、ソーシャルメディア Web サイトへのすべてのリクエストで次のセキュリティ対策が確保されます。

• 有害なコードを含むソーシャルメディア Web サイト上のコンテンツは、ローカルデバイスで実行されない
• 外部ユーザーは、マルウェアまたはスパイウェアに感染している可能性のあるサイトからのコンテンツのダウンロードを制限される

Cloudflare One はすべてのネットワークリクエストを可視化できるため、Cloudflare はリクエスト内のデータに適用されるポリシーを作成できます。これは、DLP サービスを使い、アプリケーションからのコンテンツのダウンロードを検出し、特定のユーザー層に対してブロックできることを意味します。次のポリシーを見てください。

このポリシーは、コントラクターが顧客アカウント情報を含むファイルをダウンロードするのを防ぎます。さらに、ユーザーのデバイスが特定のセキュリティポスチャ要件を満たさない場合に同じダウンロードをブロックする追加ポリシーを構成できます。これにより、必要なセキュリティ基準を満たさないデバイスへ機密の顧客データをダウンロードできない、という共通ルールの一貫した強制が確保されます。

DLP ポリシーは逆方向にも適用でき、会社の機密文書が未承認のクラウドストレージまたはソーシャルメディアへアップロードされないようにします。

SASE の旅のこの時点で、ユーザーは IT ネットワークとセキュリティインフラを再設計し、Cloudflare One SASE プラットフォームのすべての能力を十分に活用しています。長期デプロイにおける重要な要素は、組織への完全な可視性の確立と、問題を診断してすばやく解決する能力です。

すばやい分析のため、Cloudflare は組み込みダッシュボードとアナリティクスを提供し、デプロイの運用状態の日次概要を提供します。トラフィックが Cloudflare を流れると、ダッシュボードは最もよく使われる SaaS アプリケーションについて内部ユーザーに警告し、外部ユーザーが未承認アプリケーションにアクセスした場合にすばやく対応できるようにします。さらに、すべての Cloudflare One サービスからのすべてのログ情報は、管理者のダッシュボードからアクセスして検索できます。これにより、特定のブロックされたリクエストのフィルタが効率的になり、各ログにはユーザー ID、デバイス情報、ブロックを引き起こした特定のルールなどの有用な情報が含まれます。これは、ルールの調整がよく必要なデプロイ初期段階で非常に便利です。

ただし、多くの組織は、インフラのパフォーマンスに関する長期的な可視性を管理するために、既存の専用ツールに依存しています。これをサポートするため、Cloudflare はすべてのログ情報をそのようなツールへエクスポートできます。Cloudflare One のあらゆる側面がログに記録され、エクスポートできます。Cloudflare は、AWS、Google Cloud Storage、SumoLogic、Azure、Splunk、Datadog、任意の S3 互換サービスを含むさまざまなプラットフォームへの小さなデータバッチの継続送信向けの組み込み連携を提供します。この柔軟性により、組織はフィールドを選択的に選び、既存ツールに取り込むデータの種類と量を制御できます。

トラフィックとポリシーに関連するログの上に、Cloudflare は管理活動も監査します。すべての管理操作と Cloudflare Tunnels への変更がログに記録されます。これにより変更管理監査が可能になり、他のすべてのログと同様に、より広い変更管理監視ソリューションの一部として他のツールへエクスポートできます。

Cloudflare は、インターネットと接続されたネットワークおよびデバイスのパフォーマンスへの 深い洞察 ↗ を持っています。この知識は、IT 管理者にエンドユーザーの一分ごとの体験の可視性を与え、生産性に影響する問題の迅速な解決を可能にします。

Digital Experience Monitoring（DEM）サービスにより、IT はユーザーデバイスに対して継続的なテストを実行し、会社リソースへの接続品質を判断できます。これらのテストの結果は Cloudflare One ダッシュボードで利用でき、IT 管理者は特定のユーザーがアプリケーションへのアクセスで困難に遭遇したときの根本原因を確認して特定できます。これらの問題は、ユーザーのローカル ISP または特定の性能が低い SaaS サービスプロバイダーから生じることがあります。このデータは、管理者が貧しいユーザー体験を診断して対処し、より速い問題解決につながる上で非常に価値があります。

ダッシュボードはデバイスフリート全体の包括的な要約を表示し、組織のすべてのデバイスのリアルタイムおよび過去の接続メトリクスを示します。IT 管理者はさらに分析するため、特定のデバイスへドリルダウンできます。

Cloudflare の SASE プラットフォームを包括的に理解したので、既存インフラと統合する準備が整いました。このシステムは、デバイス上の最初のリクエストから始まり、すべてのネットワークを横断して、場所に関係なくアプリケーションまで、従業員と外部ユーザーの両方のアプリケーションへのアクセスを効率的に保護します。この強力な新しいモデルは、巨大な Cloudflare ネットワークの上に構築され、直感的な管理インターフェイスで管理されます。

このドキュメントで説明した能力の多くは、最大 50 ユーザーまで、時間制限なしで無料で使えます。アカウントに サインアップ ↗ し、Cloudflare One ↗ セクションへ進んでください。このドキュメントはプラットフォーム全体の概要を提供しましたが、特定の領域をより深く掘り下げたい場合は、次のリソースを探索することを推奨します。

SASE 要件をより詳しく議論し、当社のアーキテクトの 1 人とつながりたい場合は、https://www.cloudflare.com/cloudflare-one/ ↗ を開き、相談を依頼してください。