企業セキュリティの進化し続ける分野において、CISOとCIOは、パフォーマンスの優れたAny-to-Any接続を実現するために、新しい企業ネットワークの構築と古い企業ネットワークの維持にたゆまぬ努力を続けなければなりません。ネットワークアーキテクトのチームにとって、ニーズの変化に対応するために自社の環境を調査することは、仕事の半分を占めています。もう一方は、既存の環境にシームレスに統合する新しい革新的なソリューションを発見することです。安全で柔軟なインフラを求めて絶えず構築と強化を行うサイクルは、CloudflareのSASEサービスであるCloudflare Oneのために構築されたものなのです。
Cloudflare Oneは、お客様やアナリストからのフィードバックに基づいて徐々に進化してきました。当社は本日、Cloudflare WARP Connectorの一般公開を発表します。この新ツールは、既存のネットワークインフラに破壊的な変更を加えることなく、双方向、サイト間、メッシュ状の接続の安全性をさらに容易にします。
CloudflareのZero Trust事例のギャップを埋める
Cloudflareのアプローチは、ネットワーク接続のための万能ソリューションは存在しないことを認識し、常に幅広い製品を提供することに注力してきました。当社のビジョンはシンプルで、Any-to-Any接続を、あなたが望む方法でご利用いただくことです。
WARP Connector以前は、インフラをCloudflareに接続する最も簡単な方法の1つは、ローカルHTTPサーバー、Kubernetesクラスタによって提供されるWebサービス、プライベートネットワークセグメントなどいずれも、Cloudflare Tunnelアプリコネクタであるcloudflaredを経由するものでした。多くの場合、これはすばらしく機能しますが、時間の経過とともに、cloudflaredの基盤となるアーキテクチャに基づいてサポートできないユースケースのロングテールが表面化するようになりました。これには、顧客がVoIP電話を利用し、ユーザーのソフトフォンへの発信接続を確立するSIPサーバーが必要になったり、CI/CDパイプラインの各段階について関連するステークホルダーに通知を送信するCI/CDサーバーが必要になったりする状況が含まれます。このブログ記事の後半では、これらのユースケースについて詳しく説明します。
OSI参照モデルのレイヤー4にある_clouflared_プロキシとして、その設計は、オリジンサービスへのリクエストをプロキシするために特別に最適化されたものであり、オリジンサービスからのリクエストを処理するアクティブなリスナーとなるようには設計されていませんでした。この設計上のトレードオフは、cloudflaredがアプリサーバーにプロキシするすべてのリクエストを、ソースNATを使って行う必要があることを意味します。このセットアップは、お客様がオリジナルサービスの前にcloudflaredをデプロイするために、ルーティングテーブルを更新する必要がない場合に便利です。しかし、これは同時に、リクエスト送信するクライアントの真のソースIPを見ることができなくなることを意味します。これは、ネットワークファイアウォールがすべてのネットワークトラフィックをログに記録する場合には重要です。なぜなら、すべてのリクエストのソースIPが_cloudflaredの_IPアドレスになり、お客様が真のソースを把握できなくなるためです。
構築するか、借用するか
この問題を解決するために、私たちは2つの潜在的なソリューションを特定しました。これは、新しいコネクタを構築することでゼロから始める方法と、cloudflaredまたはWarpのような既存のコネクタから借用する方法です。
次の表は、2つのアプローチのトレードオフを概説したものです。
機能
cloudflaredで構築
Warpから借用
双方向のトラフィックフロー
前のセクションで説明したように、レイヤー4のプロキシは制限されます。
プロキシの場所
レイヤー3になります。そのサブネットのデフォルトゲートウェイとして動作し、両方向からのトラフィックフローをサポートすることができます。
ユーザーエクスペリエンス
Cloudflare Oneのお客様の場合、2つの異なる製品(cloudflaredとWarp)を操作してサービスとユーザーを接続する必要があります。
Cloudflare Oneのお客様の場合、ネットワークとユーザーを接続する1つの製品に慣れるだけで済みます。
支店、データセンター(オンプレミスおよびクラウド)、本社間のサイト間接続
推奨されません
各デバイスでエージェントを実行することが現実的ではないサイトの場合、他のサイト/支店/データセンターでWarpクライアントを実行しているユーザーに簡単にサイトを接続させることができます。これは、基盤となるトンネルがすべて同じであれば、シームレスに機能します。
真のソースIPの可視化
ソースNATを使用。
デフォルトのゲートウェイとして機能するため、どのようなトラフィックフローに対しても真のソースIPアドレスを保持します。
高い可用性
設計上、本質的に信頼でき、フェイルオーバーの際のレプリカをサポートします。
信頼性の仕様は、デフォルトゲートウェイのユースケースとエンドポイントデバイスエージェントでは大きく異なります。したがって、ここにイノベーションの機会があるのです。
WARP Connectorの導入
本日より、WARP Connectorの導入により、サーバーから開始される(SIP/VoIP)フロー、そして支社、本社、クラウドプラットフォームをつなぐサイト間接続、Warp-to-Warpによるメッシュ状ネットワークを利用でき、新たな可能性が開かれました。内部的には、この新しいコネクターはWarpクライアントの拡張機能であり、ネットワーク内のあらゆるサブネットの仮想ルーターとして機能し、Cloudflareを介してトラフィックをオン/オフランプすることができます。
Warp上で構築することで、IPトラフィックをルーティングする目的で物理インターフェース(NIC)を論理的に細分化するために、ホスト上に仮想ネットワークインターフェースを作成するという設計を活用することができました。これにより、ホストとCloudflareエッジ間で維持されたWireGuard/MASQUEトンネルを介して双方向のトラフィックを送信することができます。このアーキテクチャのおかげで、お客様はクライアントの真のソースIPを可視化できるという付加価値も得ることができます。
WARP Connectorは、追加のルーティング変更なしにデフォルトのゲートウェイに簡単に導入できます。あるいは、WARP Connector経由でルーティングする必要のある特定のCIDRに対して静的ルートを設定することができます。また、この静的ルートは、デフォルトゲートウェイまたはそのサブネット内のすべてのホストで設定することもできます。
プライベートネットワークのユースケース
ここでは、お客様が新しいコネクターを導入したいと思われる理由をいくつか説明します。ただし、このソリューションは、Microsoftのシステムセンターコンフィギュレーションマネージャー(SCCM)、Active Directoryサーバーの更新、VoIPおよびSIPトラフィック、複雑なCI/CDパイプライン相互作用のある開発者ワークフローなど、多数のサービスをサポートできることを覚えておいてください。また、このコネクターは、cloudflaredおよびMagic WANと一緒に実行でき、Cloudflareグローバルネットワークへのスタンドアロンのリモートアクセスおよびサイト間コネクターとしても使用できます。
ソフトフォンとVoIPサーバー
ユーザーがVoIPソフトウェアサービスを介して音声通話やビデオ通話を確立する場合、通常、プライベートネットワーク内のSIPサーバーが、エンドユーザーの最後の既知のIPアドレスを使用して接続をブローカーします。しかし、トラフィックがパス上のどこかにプロキシされた場合、参加者は音声信号またはデータ信号を部分的にしか受信できないことが多くあります。「WARP Connector」を使用することで、お客様はこれらのサービスにきめ細かいポリシーを適用して、安全なアクセスを実現し、Zero Trustフレームワーク内でVoIPインフラを強化できるようになります。
CI/CDパイプラインへのアクセス保護
組織のDevOpsエコシステムは一般的に多くの部分から構築されていますが、JenkinsやTeamcityなどのCI/CDサーバーはすべての開発アクティビティの中核となります。そのため、CI/CDサーバーの保護が重要です。WARP ConnectorとWarpクライアントを使用することで、組織はCI/CDパイプライン全体の安全性を確保し、また簡単に合理化することができます。
Kubernetesアプリ用の典型的なCI/CDパイプラインを見てみましょう。環境は、上の図のように設定されており、開発者およびQAのノートパソコンにWarpクライアントがあり、WARP Connectorは異なるネットワーク上のCI/CDサーバーとステージングサーバーを安全に接続しています。
通常、CI/CDパイプラインは、開発者がコード変更をコミットし、CI/CDサーバー上でWebフックを呼び出したときにトリガーされます。
イメージが構築されたら、コードをデプロイします。これは通常、テスト、ステージング、本番という段階で行われます。
テスト/ステージング環境でイメージの準備ができたら、開発者とQAエンジニアに通知が送信されます。
QAエンジニアは、CI/CDサーバーからWebフック経由で通知を受け取り、監視とトラブルシューティングのワークフローを開始します。
WARP Connectorを利用することで、お客様はエコシステムをプライベートにし、一般に公開しないことで、開発者をDevOpsエコシステム内のツールに簡単に接続させることができます。DevOpsエコシステムがCloudflareに安全に接続されれば、CI/CDパイプラインへのアクセスを保護するために、きめ細かいセキュリティポリシーを簡単に適用できます。
真のソースIPアドレスの保持
Microsoft ADサーバーや非Webアプリサーバーを運用している組織は、監査やポリシーアプリのために真のソースIPアドレスを特定する必要があることがよくあります。これらの要件が存在する場合、WARP Connectorはこれを簡素化し、NAT境界を追加しないソリューションを提供します。これは、不健全なソースIPアドレスのレート制限境界内のACLベースのポリシー、エンドユーザーからの追加診断の収集などに役立ちます。
WARP Connectorの利用を開始
このローンチの一環として、Cloudflare Oneダッシュボードにいくつかの変更を加え、異なるネットワークオン/オフランプオプションをより際立たせています。本日より、ダッシュボードに新しい「ネットワーク」タブが表示されます。これが、Cloudflare Tunnel UIの新しいホームになります。
また、「Tunnel」の横に、新しい「Route」タブを導入しています。このページは、お客様の仮想ネットワーク、Cloudflare Tunnel、およびそれらに関連付けられたルートの組織図を表示します。この新しいページは、ネットワーク設定に関する次のようなお客様の質問に答えます。たとえば、「どのCloudflare Tunnelに私のホスト192.168.1.2へのルートがありますか?」」、「CIDR 192.168.2.1/28のルートが存在する場合、どうすればアクセスできますか?」、「自分の環境で重複しているCIDRは何ですか?そしてそれらが属するVNETは何ですか?」などです。これは、接続性問題のトラブルシューティングにCloudflareダッシュボードを使用する、非常に複雑な企業ネットワークを保有するお客様にとって、非常に有益です。
WARP Connectorの利用は簡単です。現在Linuxホストにデプロイ可能で、ユーザーは「Tunnelの作成」を選択し、cloudflaredとWarpのいずれかを選択して、ダッシュボードから直接デプロイできます。開発者向けドキュメントに従って、いくつかの簡単なステップで導入を開始してください。近い将来、WARP Connectorを導入できるより多くのプラットフォームのサポートを追加する予定です。
今後の展開は?
プライベートベータ版をご利用のすべてのお客様、貴重なフィードバックをいただきどうもありがとうございます。今後、Cloudflareがこの先の数四半期で直面している課題は、デプロイメントの簡素化、cloudflaredのそれを反映させること、そして、冗長性とフェイルオーバーメカニズムを通じた高可用性の強化です。
私たちはCloudflare Oneプラットフォームの革新と強化に向けて努力を続けていきますので、今後のアップデートにご期待ください。お客様がWARP Connectorを活用して、接続性とセキュリティ環境を変革する様子が見られることを楽しみにしています。