VPN コンセントレーターから Zero Trust Network Access へのネットワーク中心の移行

ここ数年、社内プライベートネットワークへのリモートアクセス用ハードウェアを設置・保守する従来の手法は、もはや安全でもコスト効率もよくありません。オンプレミス VPN 製品で見つかる 脆弱性 ↗ の増加により、セキュリティと IT チームは、CVE アラート ↗ を監視して対応しなくてもよいソリューションを探しています。これらのシステムは、すべてのユーザーのインターネットトラフィックを単一インフラ経由でルーティングするため、ユーザーの帯域も制限し、体験が悪化します。IT チームは、自前ハードウェアの設置と保守のコストと手間を、より新しくより安全なクラウドホスト型サービスで相殺できると認識しています。アプリケーション性能へのユーザー期待は、帯域制約のある自前 VPN ソリューションの限界を露呈しています。まとめると、自前 VPN の運用は高価でリスクが高く、優れたユーザー体験を提供しません。

そのため、多くの組織は、プライベートリソースへのリモートアクセスを提供する Secure Access Service Edge ↗ (SASE) アーキテクチャの一部として、Zero Trust Network Access ↗ (ZTNA) サービスを使い、ゼロトラスト ↗ のセキュリティ姿勢へ移ろうとしています。重要なソフトウェアがすべてクラウドサービスとして動くため、組織はサーバーとソフトウェアを最新に保つ負担から解放されます。クラウドプラットフォームは大規模スケール向けに設計されているため、エンドユーザーが使える帯域が大幅に増え、体験が向上します。

旧モデルでは、VPN ハードウェアはアプリケーションがあるネットワークへ直接アクセスし、通常ユーザーはネットワーク全体へアクセスできました。新しい SASE のリモートアクセスは、クラウドプラットフォームからアプリケーションがあるネットワークへの接続を作りますが、公開するのは特定のアプリケーションまたはネットワークアドレスだけです。Cloudflare の推奨アプローチは、エンドユーザーデバイス上のものに似たソフトウェアエージェントをインストールし、クラウドからプライベートネットワークへ安全なトンネルを作ることです。ただし、常に簡単な道ではありません。レガシーなリモートアクセスハードウェアを急いで置き換えたいネットワーク管理者にとって、新しいサーバーのデプロイや、既存アプリケーションサーバーへのソフトウェア導入のための長い変更管理は、許容できる期間ではできないことがあります。代わりに、ネットワーク管理者は、GRE や IPsec などのなじみのあるプロトコルで、クラウド SASE プラットフォームから既存ネットワークハードウェアへ安全なトンネルを作る方が、慣れていて制御しやすい場合があります。これは、VPN アクセスに使っていた同じハードウェアアプライアンスを使い、単に安全なトンネルコネクターへ簡素化し、高価で脆弱なリモートアクセス機能のライセンスを切る（または外す）ことを意味することもあります。

このデザインガイドは、その状況にある組織向けです。自前のリモートアクセスハードウェアの利用をすばやく置き換えまたは緩和し、その後、適切な場所では推奨のソフトウェアエージェントアプローチへ段階的に移ります。

このガイドは、現在の VPN ベンダーの置き換えを検討しつつ、組織をゼロトラストまたは SASE アーキテクチャへ準備しているネットワークおよびセキュリティの専門家向けです。IPsec トンネル、ルーティングテーブル、スプリットトンネリングなどのネットワーキング概念に慣れていることを前提とします。

学べること:

• Cloudflare が従来の VPN のような実装をどう置き換えられるか
• VPN ネットワークトラフィックの可視性をどう得るか
• 規模で Cloudflare ソリューションを実装するために考慮すべきこと
• 推奨の Zero Trust Network Access 実装へ移るための手順

このガイドが説明するソリューションには、次を含む Cloudflare との契約が必要です。

• オンボードしたいユーザー数分の Cloudflare One ライセンス
• Cloudflare WAN（旧 Magic WAN）

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

1. Cloudflare とは？ | ウェブサイト ↗（5 分の読み物）または 動画 ↗（2 分）
2. ブログ: What is SASE? | Secure access service edge | Cloudflare ↗（14 分の読み物）
3. リファレンスアーキテクチャ: Cloudflare で SASE アーキテクチャへ進化する（3 時間の読み物）

従来の VPN アプローチは、通常次の種類のアクセスを提供します。

• リモートユーザーが、社内ネットワーク上で動く自前プライベートアプリケーションへアクセスできるようにする
• すべてのユーザーのインターネットトラフィックを、セキュリティポリシーが適用される単一の集中 VPN アクセスポイント経由でルーティングする

SASE プラットフォームは、2 つの主要サービスで従来の VPN ハードウェアを置き換えます。第一に、自前 VPN サービスが通常社内ネットワーク全体への広いアクセスを提供するのに対し、社内ネットワークまたはクラウド上の内部アプリケーションへユーザーアクセスを直接マッピングします。第二に、ユーザーの近くでインターネットトラフィックをフィルタリングし、すべてのトラフィックを社内ネットワーク経由にせずに安全にインターネットへアクセスできるようにし、効率を上げつつセキュリティを維持します。

リモートユーザーは、クラウドホスト型の Zero Trust Network Access (ZTNA) サービスに認証して接続します。そのサービスが、プライベートアプリケーションがあるネットワークへ接続します。Cloudflare の SASE リファレンスアーキテクチャ は、Cloudflare を既存のアプリケーションとネットワークへ接続する 3 つの方法を説明します。

1. ソフトウェアコネクター（cloudflared または Cloudflare Mesh）
2. Cloudflare WAN を使う IPsec または GRE トンネル
3. Cloudflare Network Interconnect を使う直接ネットワーク接続

3 つの方法にはそれぞれ利点があります。ただし、現代の Zero Trust 実装を検討する場合、ソフトウェアコネクターが通常好まれる理由は 3 つです。

1. 環境間で柔軟に複製しやすいネットワーク接続モデルを提供します。設定をほとんど変えずに、アプリケーションとサーバーを移せます。
2. ソフトウェアデーモンアーキテクチャにより、トラフィック需要の増加へのスケールが簡単です。より多くのサーバーにエージェントを追加インストールするだけです。
3. デーモンは（ネットワークエッジではなく）アプリケーションの近くで動くため、ポリシーを適用する隔離されたネットワークまたはアプリケーションセグメントを構築でき、横方向移動を防ぎ、ゼロトラストモデルの利点を最大限に得られます。

一般インターネット宛てのトラフィックは、クラウドの Secure Web Gateway (SWG) 経由でルーティングされます。悪意あるウェブサイトへのリクエストをフィルタリングし、ユーザー識別とデバイスセキュリティポスチャーに基づいて SaaS アプリケーションへのアクセスを許可するポリシーを書きます。

Cloudflare の SASE リファレンスアーキテクチャ は、ユーザーデバイスを Cloudflare へ接続するさまざまな方法を説明します。デバイスエージェントのインストールが必要なものもあれば、ユーザーが Web ブラウザーで URL を開くだけの方法もあります。この文書では、従来の VPN の多くがデバイス上に何らかのクライアントソフトウェアを必要とするため、Cloudflare の デバイスエージェント を使うソリューションを説明します。

既存のリモートアクセスハードウェアが脆弱で、急いで置き換える必要がある状況では、速度が重要です。また、既存 VPN ハードウェアからの移行を任されたチームは、サーバーへのソフトウェアインストールよりネットワークに慣れていることがあります。既存ハードウェアを根本的に異なるモデル、つまりソフトウェアエージェントのデプロイで置き換えるフルプロジェクトは、数日ではなく数週間かかることがあります。このガイドは、既存 VPN ソリューションをすばやく除去または緩和し、その後 SASE プラットフォームのすべての側面を活用する後続ステップを提案します。

このアプローチにより、ネットワークとセキュリティチームはすばやく稼働しつつ、内部アプリケーションへのリモートアクセス向けの現代的なゼロトラストデプロイの経験を積めます。ネットワークトラフィックの可視性が増えることで、アプリケーション利用の洞察も得られ、成功する安全なゼロトラスト移行の計画に役立ちます。

このガイドは次のフェーズを概要で説明します。環境固有の詳細が必要な場合は Cloudflare へ連絡 ↗ してください。

• フェーズ 1: 従来 / 脆弱な VPN ハードウェアをクラウドベースのリモートアクセスですばやく置き換え、アプリケーショントラフィックの洞察を得る。
• フェーズ 2: 規模を拡大し、従来の IPsec トンネルをオフロードする。
• フェーズ 3: アプリケーションアクセスをセグメント化し、クライアントレスアクセスを有効にしてセキュリティ姿勢を改善する。

グローバルな IT インフラを持つ組織を考えます。具体的には、欧州、米国、アジアに 3 つのデータセンターがあり、それぞれ独自の VPN サービスを持っています。最良の性能を得るため、この VPN 実装では、従業員が自分の場所に応じてどの VPN クラスターに接続するかを意識して選ぶ必要があります。この例では、すべてのユーザーのインターネットトラフィックが VPN サービスを経由し、ファイアウォールが一般インターネットの危険からユーザーを守るレベルのセキュリティを適用します。

この最初のフェーズでは、ユーザーデバイスと、既存ネットワークインフラ経由で現在アクセスしているプライベートネットワークの間に、ネットワーク接続を作ります。これは 2 つの方法で実現します。

• 従業員デバイスに Cloudflare の デバイスエージェント をインストールします。既存の VPN クライアントソフトウェアの代わりです。
• データセンターの既存ネットワークハードウェアを使い、Cloudflare WAN サービスで管理される IPsec トンネルを Cloudflare へ作成します。

従業員デバイスとデータセンターネットワークの両方は、最も近い Cloudflare サーバーへ接続します。これは Cloudflare の anycast アーキテクチャ ↗ によるもので、従業員や IT サポートの手間なしに、ユーザートラフィックの最適な経路を確保します。ユーザーは接続先の VPN サービスリージョンを選ぶ必要がなくなり、Cloudflare は常に最も近く応答の良いサービスへ接続し、プライベートアプリケーションへのアクセス性能を最大化します。

図 4 は、エンドユーザーデバイスから Cloudflare へのトラフィックと、プライベートデータセンターへルーティングするトンネルを示します。ユーザートラフィックが最も近い Cloudflare アクセスポイントに到達すると、Cloudflare はプライベートアプリケーション宛てのトラフィックをデータセンターへ直接ルーティングし、インターネット宛てのトラフィックは Cloudflare の Secure Web Gateway (SWG) で処理します。プライベートアドレスへのリクエスト解決には、既存の DNS サービスを Cloudflare の Gateway DNS ポリシー で活用できます。Cloudflare WAN は、Cloudflare とデータセンターの間に IPsec トンネルを作り、各既存ネットワークとアプリケーションへトラフィックが到達する方法を決める静的ルートで構成します。

既存のネットワークまたはセキュリティアプライアンスで IPsec トンネルを終端することで、現行インフラへの影響を抑えつつ安全なオフランプを作れます。これらの IPsec トンネルは、サーバー起点のアウトバウンドトラフィックも通し続けられます。ただし、デプロイの規模によっては、既存アプライアンスが帯域制限に達することがあります。この最初のフェーズは、すばやく稼働し、ユーザーとアプリケーションの接続を検証する「パイロット」または小規模デプロイと考えるのがよいです。次のフェーズでは、このフェーズで得た洞察を使って設計を改善します。

このような設計があれば、Cloudflare はリクエストユーザーの識別に基づいてトラフィックをフィルタリングできます。たとえば、企業の ID プロバイダーに認証済みで "Engineering" グループのメンバーであるユーザーだけが、社内ホストのソースコードリポジトリへアクセスできます。さらに、接続前にユーザーデバイスが 特定のポスチャーチェック に合格する必要がある場合もあります。参照として使える ネットワークポリシーの例 がゼロトラストドキュメントにあります。本質的には、関連する IP アドレス範囲ではなくユーザー識別を使ってネットワークアクセスポリシーを定義できます。従来の 5-tuple ACL から離れることが、ゼロトラストモデルへの第一歩になります。

ネットワークを Cloudflare に接続したので、次は従業員デバイスから Cloudflare ネットワークへトラフィックを送る必要があり、これには デバイスエージェント が必要です。エージェントの初回インストール時、ユーザーは Cloudflare に設定した ID プロバイダー (IdP) で認証するよう求められます。IdP は既存の識別でユーザーが認証することを保証し、アクセスポリシーで使うグループメンバーシップ情報もインポートできます。デバイス登録ポリシー は、適切なユーザーが、適切な方法で認証し、安全なデバイスを使って、アプリケーションへアクセスする前に組織の Cloudflare Zero Trust インスタンスへ新しいデバイスを接続できるようにします。

デバイスプロファイル を使い、異なるユーザー、または Managed networks を使って異なる場所にいる同じユーザーに、異なるデバイスエージェント構成を適用します。インターネットトラフィックを VPN サーバー経由でルーティングしない企業では、デバイスプロファイルで デバイスエージェントがインターネットトラフィックを Cloudflare トンネルから除外 し、インターネットへ直接接続するよう設定できます。このガイドでは、そのトラフィックのセキュリティをより強く制御できる Cloudflare 経由でインターネット向けトラフィックを送ることを強く推奨します。ただし、ビデオ会議など帯域の大きいトラフィックは、選択的に Cloudflare をバイパスできます。

内部リソース宛ての、デバイスエージェントを使う従業員からのトラフィックは、送信元 IP が 100.96.0.0/12 IP 範囲になります。これは RFC 6598 Carrier-grade NAT 空間 ↗ の範囲で、これらのユーザーへトラフィックを戻すために、データセンターリージョンのルートとして追加する必要があります。詳細は Cloudflare WAN と WARP の連携 ドキュメントを参照してください。

このフェーズでは従業員トラフィックの大部分に Cloudflare WAN サービスと IPsec トンネルを使いますが、内部ホスト名の DNS 解決では Cloudflare のソフトウェアコネクターが重要な役割を果たします。これらのソフトウェアコネクターの経験は次のフェーズでも役立つため、デプロイと管理のプロセス定義は、この最初のフェーズで始めるべきです。

Cloudflare は 2 種類のソフトウェアコネクターを提供します。

• cloudflared
• Cloudflare Mesh（旧 WARP Connector）

導入で述べたように、cloudflared は Zero Trust Network Access の推奨方法ですが、ネットワークとアプリケーションサーバーへのインバウンド接続だけをサポートします。サーバー起点の接続はトンネルを通らず、サーバーのデフォルトネットワーク経路に従います。Cloudflare Mesh はインバウンドとアウトバウンドの両方を通すトンネルを作るよう設計されていますが、現時点では同じレベルのフェイルオーバーサポートと設定の容易さはありません。このガイドでは、説明する内部 DNS のユースケースをサポートする cloudflared を扱います。

大規模なリモートアクセスのユースケースでは、Cloudflare はコネクターを専用ホストへデプロイすることを推奨します。デプロイの推奨事項とサーバーサイジングは System Requirements ドキュメント を参照してください。これらのサーバーをどこに置くかは、必要なアクセスと、内部ファイアウォールルールおよびネットワークのセグメント化に依存します。一部のお客様は最初のデプロイを DMZ から始め、他のお客様はネットワークのより奥にインストールしてそこから進化させます。

cloudflared のインストールは自動化が最適です。Docker などの仮想化技術でデプロイするか、VMware ゲストとしてデプロイし Ansible で構成することを推奨します。できれば、cloudflared トンネルを使うトラフィックが増えるにつれ、ホストから収集したリアルタイムメトリクスに基づいてデプロイを自動スケールできるシステムにします。cloudflared インスタンスは Prometheus メトリクスエンドポイント で監視できます。Prometheus は SNMP に似た機能を持つ HTTP ベースの監視・アラートシステムで、監視対象リソースからポーリングできるメトリクスを公開します。今日の市場にあるほとんどの監視システムは、アラートとデプロイの自動スケールに必要なメトリクス収集の形式として Prometheus をサポートします。

規模で cloudflared コネクターをデプロイする詳細:

• Ansible、Terraform、Kubernetes などの環境での デプロイと更新の各種ガイド
• レプリカ による高可用性
• Grafana でトンネルを監視する

図 4 のとおり、DNS と一般ネットワークトラフィックの両方は、従業員デバイスから Cloudflare へ流れます。デフォルトでは、デバイスエージェントはすべての DNS クエリを Cloudflare へ転送し、DNS ポリシー に基づいて検査とフィルタリングを行います。これは有用です。管理者が セキュリティ脅威をブロックする DNS ポリシー を設定でき、従業員がオンラインになった時点ですぐに保護を始められるためです。これは、インターネットトラフィックがトンネルから Cloudflare へ来る一方、クライアントがホスト名リクエストを Cloudflare DNS サービス経由で解決する場合にも当てはまります。

ただし、内部ドメインについては、Cloudflare が解決方法を知る必要があります。ここで resolver policies が登場します。着信 DNS リクエストに DNS ポリシーを適用したあと、内部 DNS ホスト名のリクエストを内部 DNS サーバーへ転送できます。たとえば、ドメイン example.local は 10.10.10.123 で動く DNS サーバーでホストされていることがあります。resolver policy は、そのドメインのホスト名リクエストがその IP へ送られるようにします。

内部 DNS サーバーへのルートを公開するトンネルが必要です。cloudflared は、10.10.10.123 IP アドレスへ DNS トラフィックをルーティングできるホストにデプロイします。DNS ゲートウェイ経由の内部ドメインリクエストは、その後トンネル経由でこの DNS サーバーへリダイレクトされます。

この最初のフェーズで手順を進め、最初のユーザーがアプリケーションへアクセスし始めると、適切な監視とログの必要性が明らかになります。Cloudflare を流れるトラフィックの可視性は、次に役立ちます。

• サポートスタッフによるトラブルシューティングなどの運用活動。
• SIEM（セキュリティ情報およびイベント管理 ↗）サービスなどを使った SOC による潜在的脅威の監視。
• セキュリティと性能の改善余地を見つけるためのアプリケーショントラフィックの可視性（フェーズ 2 も参照）。

Cloudflare は、dashboard 経由または Logpush でエクスポートできる、異なるレベルの可視性を提供します。Cloudflare WAN の IPsec トンネルを流れるトラフィックについては、dashboard と GraphQL API で Network Analytics を確認できます。これはトラフィックのサンプリング統計を示し、傾向とトラフィックフロー分析に使えます。

次に、より詳細な ネットワークセッションログ があり、失敗したリクエストを含め、Cloudflare のセキュア Web ゲートウェイを通るすべてのネットワーク接続 / セッションの情報を収集します。その後に Gateway アクティビティログ があり、ゲートウェイエンジンがトラフィックを検査するときに発動したポリシーの情報を含みます。これらのログの組み合わせにより、ユーザー識別を含むすべてのネットワークフローを完全に把握できます。この情報を使い、ネットワークとセキュリティチームは、どの種類のトラフィックがどこへ流れるかを分析し、次のステップの計画に使えます。

最後に、リアルタイムアラートとして、IPsec と cloudflared トンネルの健全性、および Cloudflare インフラ全体の状態などのイベント向けに Cloudflare Notifications を設定できます。

ほとんどの環境では、IPsec 終端ポイントのスループットに限りがあり、事業全体のトラフィックへスケールするとき、いずれこれが問題になります。フェーズ 1 の最終ステップで、アプリケーショントラフィックフローの洞察が得られます。アプリケーションランドスケープを完全にマッピングできていなくても、現在の IPsec トンネルに大きな負荷をかけるアプリケーションは見つかっているでしょう。

幸い、これらのアプリケーションの多くは、よりスケーラブルなソフトウェアコネクターベースのトンネルへ 1 つずつ移行できます。サーバー起点トラフィックに依存しないアプリケーションは、この種の移行の対象です。フェーズ 1 での cloudflared 初期デプロイの経験を活かして:

1. 関連環境（次の例では USA データセンター）に 2 つ以上の cloudflared インスタンスをデプロイします。
2. トンネルへ Private Networks を追加 し、そのトンネルが扱うネットワークとアプリケーションにより具体的にスコープしたルーティングとアクセスを定義します。たとえば、Cloudflare WAN 管理の IPsec トンネルが公開するより広い 10.20.0.0/16 ではなく、ソフトウェアコネクタートンネル経由で 10.20.56.0/24 サブネットを公開します。
3. 従業員からのトラフィックは、/16 ルートで IPsec トンネルを通る代わりに、/24 サブネットではソフトウェアコネクタートンネル経由でルーティングされ、IPsec 終端デバイスへの依存をオフロードします。

場合によっては（上の Asia データセンターなど）、IPsec トンネルが不要になり、ソフトウェアコネクターがインフラへの唯一の接続になります。その場合、10.30.0.0/16 サブネット全体を cloudflared で管理し、IPsec トンネル（と関連ハードウェア）を廃止できます。このフェーズは継続的な取り組みになる可能性が高いです。より多くのアプリケーションがマッピングされ、ソフトウェアコネクターベースのトンネルに適したトラフィックフローと判断されるにつれ、必要に応じて移行します。

このガイドの最初の 2 フェーズは、VPN コンセントレーターを活用する従来の VPN に非常に近い設計になり、ポリシー適用は境界で行われます。導入で述べた理由でそうしましたが、ゼロトラストアーキテクチャの約束は、リソースのできるだけ近くでセキュリティポリシーを適用する、より小さなアプリケーション / ネットワークセグメントを定義してセキュリティ姿勢を改善することです。

このフェーズは、トンネルの背後に公開するリソースをより小さく、より隔離し、内部ネットワーク内の横方向移動を防ぐことです。前のフェーズで得た可視性を使い、アプリケーション（または一連のアプリケーション）、関連 IP アドレスを選び、専用のソフトウェアコネクターインスタンスをデプロイします。コネクターのデプロイとプライベートネットワークの公開 のドキュメントを参照し、手順 3 でアプリケーションの IP アドレスを設定します。

各ソフトウェアコネクターインスタンスはアプリケーション専用になるため、唯一のエントリポイントとして設定できます。アプリケーションがあるネットワークセグメントへのトラフィックは完全に遮断でき、内部の横方向移動を防げます。必要なのは、ソフトウェアコネクターがトンネルを作るための有効なインターネット向けアウトバウンドルートと、ネットワーク / アプリケーションがソフトウェアコネクターのデプロイ先サーバーへ到達できることです。アクセス制御は IP ルーティングだけでなく、プロトコルレベルでも管理します。このアプローチでは、そのサーバー上の HTTPS だけにアクセスを定義できます。同じサーバーが SSH や他のサービスを動かしていても、そのアプリケーションポートにだけアクセスを定義します。

上の例では、サブネット X と Y はデータセンターの残りから完全にセグメント化されています。それらのサブネットで動くアプリケーション（それぞれ 10.10.45.1 と 10.20.56.1）へのトラフィックは、関連する認証と認可ポリシーが適用された Cloudflare 経由でのみ流れます。ソフトウェアコネクターの 1 対 1 デプロイが常に正しいわけではありません。プライベートネットワーク上で複数のアプリケーションが動き、それらのアプリケーションのトラフィックを処理するために cloudflared を動かす複数サーバーをデプロイすることもあります。

プライベート IP アドレス向けのトラフィックルーティングに加え、cloudflared は公開解決可能なホスト名経由で内部アプリケーションを公開できます。これにより、デバイス上にソフトウェアを使わずにそのようなアプリケーションへ接続できます。請負業者やパートナーへアプリケーションアクセスを与えるなど、デバイスにソフトウェアをインストールできないユースケースで非常に有用です。

次の例では、erp.example.com がトンネルの Public Hostname として追加され、内部サブネット Y 上の特定 IP アドレスのポート 80 および / または 443 へトラフィックをルーティングします。インターネットからのこのリソースへのアクセスは、従業員オンボーディング用に設定した IdP 接続にも依存する Cloudflare Access セキュリティポリシー で保護されます。

すべてのアプリケーションがこの種のアクセスに適するわけではありません。HTTP(S) アプリケーション、または SSH や VNC のように ブラウザーで描画できるアプリケーション だけがサポートされます。このようなデプロイと、Cookie 設定、ブラウザー隔離、アプリケーション内で認証に Access トークンを使うなどの追加の高度なオプションについては、セルフホストアプリケーションのドキュメント を参照してください。

このデザインガイドは、一般的な機能、制限、リスクを持つかなり従来型の VPN 環境から始まりました。ユーザーデバイス側の Cloudflare と、データセンターネットワーク向けの Cloudflare WAN を組み合わせることで、フェーズ 1 と 2 は既存の技術と知識を使う低リスクな移行設計を説明しました。これだけでも、VPN コンセントレーターの廃止、ネットワーク可視性の向上、内部リソースへのアクセス性能の改善という利点がありました。

フェーズ 3 は、識別ベースのネットワークポリシーと、ソフトウェアコネクターによるより小さなネットワークセグメントを導入して設計を改善しました。これにより、Web アプリケーションのクライアントレスアクセスや、ブラウザー描画の VNC / SSH セッションなど、他のゼロトラストアクセスモデルを提供する機会も開きました。

任意のデバイス、アプリケーション、ネットワークを接続する Cloudflare connectivity cloud の柔軟性により、このゼロトラスト移行を段階的に進められます。これによりリスクを減らし、ネットワークとセキュリティチームが組織の必要なペースで知識とアーキテクチャを適応できます。

• Cloudflare WAN 連携: Cloudflare WAN への WARP オンランプ
• ポリシー設定: Gateway Network ポリシー