Cloudflareは10年余り前に TechCrunch Disruptをローンチしました。その際私たちは、Cloudflareを従来のセキュリティベンダーと差別化するための3つの基本原則について話しました。それはより安全で、より高性能で、そして驚くほど簡単に使えることでした。使いやすさは、当社の判断の軸であり、Cloudflare Tunnelについても変わりありません。
この考えから、これまでターミナルで最大14個のコマンドを必要としたトンネルの作成を、たった3つの簡単なステップで、Zero Trustのダッシュボードから直接行えるようになったことを、本日発表いたします。
サインアップまたはチームにアクセスして、VPNを解除し、Cloudflareでプライベートネットワークの構築を始めてみてください。このリリースの目的と今後の開発についてもっと知りたい方は、このままスクロールしてください。
当社のコネクタ
Cloudflare Tunnelは、ローカルHTTPサーバー、Kubernetesクラスターが提供するWebサービス、プライベートネットワークセグメントなど、お客様のインフラをCloudflareに接続する最も簡単な方法です。この接続は、当社の軽量なオープンソースコネクタ 、cloudflaredによって実現されます。当社のコネクタは、Cloudflareのネットワーク内の2つの異なるデータセンターへの4つの長寿命な接続を作成し、設計による高可用性を提供します。つまり、個々の接続、サーバー、データセンターがダウンしても、ネットワークは稼働し続けることができます。コネクタの複数のインスタンスを配置することで、何らかの理由で単一のホストが停止した場合に備えて、ユーザー自身の環境内で冗長性を維持することも可能です。
これまで、当社のコネクタをデプロイする最良の方法は、cloudflared CLIを使用することでした。それが本日、Zero Trustのダッシュボードから直接、リモートでトンネルとその設定を作成、デプロイ、管理する新しいソリューションを起ち上げ、発表に至りました。この新しいソリューションにより、当社のお客様は、Zero Trustネットワークアクセスをわずか15分以内で従業員に提供できます。
CLIとは？GUIとは？両方ではダメなのか
コマンドラインインターフェイスの性能が卓越しています。ユーザーがコンソールやターミナルでコマンドを渡し、オペレーティングシステムと直接インタラクトが可能になります。この正確さにより、ユーザーは精度が求められるプログラムやサービスとのやりとりを正確に制御することができます。
ただし、学習曲線が高いため、新しいユーザーにとっては直感的でない場合もあります。そのため、ユーザーは使いたいツールをよく調べてから試してみる必要があります。こうした調べものを行う余裕がなく、とりあえずプログラムをテストしてみてから、自分の問題にはあまり合わないとわかるケースは少なくありません。
それとは対照的に、当社のZero TrustダッシュボードのようなGUIは、実際にやってみることで学ぶという柔軟性を持っています。プログラムの知識はほとんど必要ありません。ユーザーは直感的に望む結果へと導かれ、このソリューションが自分の問題に合っていることが分かってから、あるステップがどのように、なぜ完了したのかを調べるだけでよいのです。
Cloudflare Tunnelをリリースした当初、開始に用意されたコマンドは10種類以下でした。現在では、これよりはるかに多く、また、それらを呼び出す新しいユースケースも無数にあります。そのため、当社製品を知ったばかりのユーザーにとっては、これまで簡単に操作できたCLIライブラリが煩雑なものに感じられてしまいました。
単純な誤字脱字は一部のユーザーに強い苛立ちを与えていました。例えば、あるユーザーがプライベートネットワークトンネルのIPルートをアドバタイズする必要があるとしましょう。cloudflared tunnel route ip add <IP/CIDR>を覚えるのはなかなか面倒です。Zero Trustダッシュボードからならば、CLIライブラリのセマンティクスを覚えておく必要がありません。必要なのはトンネルの名前と、Cloudflareを通じて接続したいネットワーク範囲だけです。my-private-net（または呼び出したいもの）を入力し、インストールスクリプトをコピーし、ネットワーク範囲を入力するだけです。とてもシンプルです。誤って無効なIPやCIDRブロックを入力した場合、ダッシュボードが対処可能な、人が読める形でエラーを表示し、また正しい道筋に戻ることができます。
CLIとGUIのどちらを好むかは別として、異なる手段でも最終的には同じ結果を得ることができるのです。それぞれにメリットがあり、ユーザーが1つのソリューションで双方の長所を享受できるのが理想的です。
問題点を解消する
トンネルは通常、リクエストを適切な送信先にルーティングするために、ローカルに管理された設定ファイルが必要でした。この設定ファイルはデフォルトでは作成されませんが、ほとんどすべてのユースケースで不可欠なものだったのです。このため、ユーザーは 開発者向けドキュメントにある事例を使用して、コマンドラインを使用して設定ファイルを作成し、入力しなければなりませんでした。cloudflaredに機能が追加されるにつれて、設定ファイルの管理は扱いにくいものになっていったのです。パラメータや値をどこに含めるかを理解することは、ユーザーにとって負担になっています。これらの問題は、実際に目で確認することが難しく、ユーザーにとってはトラブルシューティングに手間がかかることが多かったのです。
また、最新のリリースでは、トンネルパーミッションの概念の改善を目指しました。それまで、ユーザーは2つの異なるトークンを管理する必要がありました。それは、cert.pemファイルとTunnel_UUID.jsonファイルです。つまり、cert.pemは、cloudflared tunnel loginコマンドで発行され、CLIを通じてCloudflareアカウントのトンネルを作成、削除、リストする機能を付与しました。Tunnel_UUID.jsonは、cloudflared tunnel create <NAME>コマンド中に発行され、指定したトンネルを実行する機能を付与しました。しかし、トンネルはZero TrustダッシュボードでCloudflareアカウントから直接作成できるようになったため、作成前にオリジンを認証する必要はなくなりました。このアクションは、最初のCloudflareログインイベントで既に実行されています。
本日のリリースにより、ユーザーは設定ファイルやトークンをローカルで管理する必要がなくなりました。これからはお客様がZero Trustダッシュボードで提供した入力に基づいて、Cloudflareがお客様に代わって管理します。ユーザーがホスト名やサービスを間違えても、トンネルの実行を試みる前にはっきりわかるので、時間と手間を省くことができます。また、トークンの管理も代行し、将来的にトークンの更新が必要な場合は、トークンのローテーションも代行します。
クライアントのあるZero TrustとクライアントレスのZero Trust
当社ではCloudflare Tunnelを、Zero Trustプラットフォームへの「オンランプ」と呼んでいます。接続後は、WARP、Gateway、Accessとシームレスにペアリングし、Zero Trustセキュリティポリシーでリソースを保護することができ、それぞれのリクエストは組織のデバイスとIDベースのルールに対して検証されます。
クライアントレスのZero Trust
Cloudflare TunnelとAccessを組み合わせることで、クライアントレスでZero Trustを実現できます。このモデルでは、ユーザーはZero Trustダッシュボードで示されたフローに従うことになります。まず、ユーザーは自分のトンネルに名前を付けます。次に、オリジンのオペレーティングシステムとシステムアーキテクチャに合わせた単一のインストールスクリプトがユーザーに提供されます。最後に、トンネルの公開ホスト名またはプライベートネットワークのルーティングを作成します。先に説明したように、この手順により設定ファイルが不要になります。公開ホスト名の値は、リモートで管理されたトンネルのイングレスルールを置き換えるようになります。プライベートリソースにアクセスするためのパブリックホスト名を追加するだけで構いません。次に、ホスト名の値をオリジンサーバーの背後にあるサービスにマッピングします。最後に、要件を満たしたユーザーのみがこのリソースにアクセスできるように、Cloudflareアクセスポリシーを作成します。
クライアントベースのZero Trust
また、Cloudflare TunnelとWARP、Gatewayを組み合わせることで、クライアントベースのZero Trustをつくることも可能です。ここでは、上記と同じフローに従いますが、パブリックホスト名を作成する代わりに、プライベートネットワークを追加します。このステップは、CLIライブラリのcloudflared tunnel route ip add <IP/CIDR>のステップを置き換えるものです。その後、Zero TrustダッシュボードのCloudflare Gatewayセクションに移動し、プライベートネットワーク接続をテストするためのルールを2つ作成し、開始することができます。
- 名前：許可<IP/CIDR>の<current user>
ポリシー：<IP/CIDR>内の送信先IP、ユーザーEmail は<Current User Email>
アクション：許可 - 名前：<IP/CIDR>のデフォルト拒否
ポリシー：<IP/CIDR>内の送信先IP
アクション：ブロック
ここで重要なのは、どちらのアプローチにおいても、ほとんどのユースケースで必要となるトンネルは1つだけであるということです。トンネルは、公開ホスト名とプライベートネットワークの両方を競合することなくアドバタイジングすることができます。これにより、オーケストレーションが簡単にできるようになりました。実際、トンネルの数をできるだけ少なくして、トンネルを追加するのではなく、レプリカを使って冗長性を処理することをお勧めします。もちろん、これは各ユーザーの環境によりますが、一般的には1つのトンネルから始めて、ネットワークやサービスを論理的に分離する必要がある場合にのみトンネルを作成するのがいいでしょう。
今後の展開は？
Cloudflare Tunnelのローンチから作成されたトンネルは数十万本におよびます。これは、新しいオーケストレーション手法に移行する必要のある無数のトンネルです。当社はこのプロセスを摩擦のないものにしたいと考えています。そのため、現在、ローカルで管理している設定をCloudflareで管理している設定へ、シームレスに移行するためのツールを構築中です。数週間後にはご利用いただけるかと思います。
また、ローンチ当初は開発者向けドキュメントに記載されているグローバル設定オプションはサポート外になる予定です。これらのパラメータは状況に応じたサポートが必要であり、時間をかけて徐々にコマンドを追加していくことになります。cloudflaredのロギングレベルを調整する最善の方法は、Cloudflare Tunnel のサービス開始コマンドを修正し、サービス実行コマンドに --loglevelフラグを追加することで実現できることが、何より重要だと考えています。これは、移行ウィザードのリリース後に優先されることになります。
以上の通り、当社にはリモートトンネル管理の将来について楽しみなプランがあり、前進しながらこれに投資し続けるつもりです。今すぐそれを確認し、ダッシュボードから3つの簡単なステップで最初のCloudflare Tunnelをデプロイしてください。