短時間のSSHアクセスは、2024年10月にCloudflareのSASEプラットフォームで初登場しました。BastionZeroの買収で得た知識を活用した短時間SSHアクセスによって、ゼロトラスト制御をLinuxサーバーの前に適用することができます。しかし、それはほんの始まりに過ぎませんでした。長い間要望されてきた機能である、リモートデスクトッププロトコル（RDP）のクライアントレスなブラウザベースのサポートを発表できることを嬉しく思います。Cloudflareの最新のプロキシアーキテクチャ上に構築されたRDPプロキシは、セキュアかつ高パフォーマンスで、何よりセットアップ、保守、使用が簡単なソリューションです。
リモートデスクトッププロトコル（RDP）は1998年に誕生し、Windows NT 4.0 Terminal Server Editionで初めて提供されました。そのWindowsバージョンを聞いたことがないとしたら、それは、以来16の主要なWindowsリリースが行われているからです。それにもかかわらず、今でも数千の企業がWindowsサーバーへのリモートアクセスにRDPを使用しています。RDPは、リモートWindowsサーバー上のインタラクションをエミュレートするために、立て続けに撮られた画面キャプチャをグラフィカルユーザーインターフェースを使って表示するという、少し奇妙なプロトコルです。（ここでは、描画コマンド、ビットマップ更新、動画ストリームなど、画面キャプチャ以外にも多くのことが起こっています。先ほども言いましたが、これは少し奇妙です）。RDPはこの複雑さのため計算負荷が高くなる可能性があり、従来のVPNで高パフォーマンスを実現する上での課題となっています。
RDPはその奇妙さもさることながら、初期の脆弱性のせいでセキュリティ業界では悪評がありました。主な問題は、脆弱なユーザーサインイン認証情報と無制限のポートアクセスの2つです。Windowsサーバーは一般にパスワードで保護されていますが、パスワードはセキュリティが不十分なものが多く、しかも複数アカウントで共有されている場合があります。そのため、RDPサーバーは、ブルートフォース攻撃（総当たり攻撃）やクレデンシャルスタッフィング攻撃に対して無防備になります。
これまで、悪質なアクターがRDPのデフォルトポートである3389を悪用してオンパス攻撃を仕掛けてきました。発見された最も深刻なRDP脆弱性の1つがBlueKeepです。正式にはCVE-2019-0708として知られる脆弱性で、これを悪用すれば、リクエストが特定のフォーマットに準拠し、RDPを実行しているポートに送信される限り、認証なしでリモートコード実行（RCE）できます。さらに悪いことにBlueKeepはワーマブルで、ユーザーの操作なしにネットワーク内の他のマシンに広がります。悪質アクターはRDPを侵害して不正にアクセスできるため、攻撃者はネットワーク内を水平移動して、権限を昇格させ、マルウェアをインストールすることができます。RDPは、Ryuk、Conti、DoppelPaymerなどのランサムウェアのデプロイにも使用されており、「Ransomware Delivery Protocol」というニックネームが付けられています。
これはRDPの登場以来見つかった脆弱性の一部に過ぎませんが、RDPが駄目と言っているわけではありません。幸いなことに、Windowsの新バージョン、CVEパッチ、パスワード衛生管理の改善、特権アクセスに関する意識の高揚により、多くの企業で攻撃対象領域が縮小しています。しかし、これほど多くのWindowsサーバーがセキュリティで保護されているにもかかわらず、オンライン上には未だにパッチ未適用のシステムや設定が不十分なシステムが数え切れないほどあり、ランサムウェアやボットネットの格好の標的になっています。
セキュリティ上のリスクはあるものの、RDPは多くの企業にとって依然不可欠で、特に分散型ワークフォースやサードパーティ請負業者を使う場合は欠かせません。RDPは、ユーザーのマシンよりも多いCPU/GPUリソースを備えた高パワーのWindowsサーバーを必要とする計算集約型タスクで力を発揮します。セキュリティ重視の企業では、RDPのおかげで、Windowsサーバーにアクセスしているのが誰か、セッション中にどのようなアクションがとられているかについて、より優れた可視性を得ることができます。
企業のデバイスを請負業者に支給するのは高コストで面倒なため、多くの企業が私物デバイス持ち込み（BYOD）の方針を採用しています。そうなると、企業は請負業者に、任務遂行に必要な企業リソースを備えたWindowsサーバーへのRDP接続の手段を提供する必要があります。
従来のRDPはユーザーデバイスにクライアントソフトウェアをインストールする必要があるため、私物マシンや非管理デバイスを使用する請負業者（または従業員）にとって適切なソリューションとはいえません。Cloudflareのお客様はこれまで、ブラウザベースのRDPアクセスを有効にするために、Apache GuacamoleやDevolutions Gatewayなどのセルフホスト型サードパーティツールを使わざるを得ませんでした。これにより、運用上の問題がいくつか発生しました：
インフラストラクチャの複雑さ： RDPゲートウェイのデプロイと保守で、運用オーバーヘッドが増大します。
保守の負担： 商用ツールやオープンソースツールは頻繁なアップデートやパッチ適用が必要な場合があり、カスタムフォークが必要になる場合もあります。
コンプライアンスの課題： サードパーティソフトウェアは、特に規制対象業界では追加のセキュリティ監査とリスク管理評価が必要です。
悪い意味の冗長性： お客様がCloudflareを頼られるのは、インフラストラクチャの保守を簡素化したいからであり、さらなる複雑化は望まれません。
Cloudflareではお客様の声を大切にしています。Cloudflareは、ゼロトラストネットワークアクセス（ZTNA）サービスに組み込んだ最新セキュリティ制御を活用する高性能RDPプロキシをアーキテクチャ化しました。当社は、業界でよく言う「セキュリティとパフォーマンスのトレードオフ」は時代遅れの考え方だと感じています。適切な基盤となるネットワークアーキテクチャを使用することで、RDPの最も悪名高い問題を軽減することができます。
ブラウザベースのRDPソリューションはCloudflare Accessの最新製品で、SSHやVNCといった既存のクライアントレスサービスと共に、VPNやRDPクライアントなしでWindowsサーバーへのセキュアなリモートアクセスを実現します。Cloudflareのグローバルネットワーク内にネイティブに構築されているため、追加のインフラストラクチャは必要ありません。
当社のブラウザベースのRDPアクセスは、セルフホスト型のAccessアプリケーションの力とターゲットの柔軟性の高さを組み合わせており、Access for Infrastructureで提供されます。管理者は以下を強制適用できます：
認証： SSO、MFA、デバイスポスチャーによって、内部RDPリソースにアクセスするユーザーの認証方法を制御します。
認可： ポリシーベースのアクセス制御によって、誰が、どのターゲットに、いつアクセスできるかを決定します。
監査： セキュリティ侵害が発生した場合、規制コンプライアンスと可視性をサポートするためにアクセスログを提供します。
ユーザーが必要とするのはWebブラウザだけで、ネイティブのRDPクライアントは必要ありません！RDPサーバーには、当社のアプリコネクタCloudflare Tunnelを介して、既存のAccessのお客様と共通のデプロイメントモデルを使用してアクセスします。特定のRDPサーバーにアクセスするためにユーザーデバイスをプロビジョニングする必要がなく、最小限のセットアップでこの新機能を導入できます。
Cloudflareの実装では、ブラウザ上で動作する高性能RDPクライアントIronRDPを利用します。IronRDPが選ばれた理由は、効率的で応答性の高い最新のRDPクライアント実装だからです。JavaベースのApache GuacamoleもRDPクライアント実装でよく使われますが、それとは異なり、IronRDPはRustで構築され、Cloudflareの開発エコシステムと非常にうまく統合します。
適切なツールを選択することの効果は多大ですが、ブラウザでRDPセッションを円滑に進めるには、いくつかの課題があります。実用的な観点から言えば、ブラウザはRDPメッセージを送信することができません。RDPは、レイヤー4伝送制御プロトコル（TCP）に直接依存して通信します。ブラウザは基本プロトコルとしてTCPを使用できますが、未加工のTCPソケット上でアプリが直接プロトコルサポートを構築できるようなAPIは公開しません。
もう1つの課題はセキュリティ関連です。ユーザー名とパスワードを使ったRDPネイティブの認証メカニズムは、ゼロトラスト時代の認証としては至らない点が多いのです。
これら両方の課題に取り組むため、IronRDPクライアントはRDPセッションをWebSocket接続にカプセル化します。レイヤー4TCPトラフィックをHTTPSでラップすることにより、クライアントはネイティブブラウザAPIを使用してCloudflareのRDPプロキシと通信することができます。また、Cloudflare AccessがID認識型ポリシーを使用してセッション全体を保護することも可能になります。Cloudflare Accessの認証JSON Webトークン（JWT）をCookie経由でWebSocket接続に添付することにより、RDPセッションのすべてのサービス間ホップが認証済みユーザーからのものであることを検証します。
ここで、セキュリティとパフォーマンスの最適化方法について簡単に説明しましょう。従来のクライアントベースのRDPトラフィックでは、クライアントとサーバーがTLS接続をネゴシエートして、セッションの保護と検証を行います。しかし、ブラウザからCloudflareへのWebSocket接続は既にTLSで保護されているため、IronRDPのRDCleanPathプロトコル拡張によって、この2番目のトラフィックのカプセル化を排除します。こうして重複をなくすことで、セッションハンドシェイク時の不要なパフォーマンス低下と複雑化を回避できます。
IronRDPクライアントは、専用WebSocketプロキシへのWebSocket接続を開始します。このプロキシはクライアントの認証、WebSocket接続の終了、Cloudflareのインフラストラクチャの深部へトンネル伝送されたRDPトラフィックのプロキシによる接続円滑化の役割を担っています。このWebSocketプロキシの構築方法を決めることは一見単純な作業のように見えますが、実は開発プロセスの中で最も難しい決断でした。
最初に提案したのは、当社ネットワーク内のすべてのサーバーで稼働する新サービスの開発でした。実現は可能でしたが、新サービスの運用には少なからず保守の負担が伴い、最終的にはオーバーヘッドが付加価値を上回るとの判定に至りました。次の提案は、Cloudflareの最も古いサービスの1つであり、毎秒数千万のHTTPリクエストを処理するフロントライン（FL）に新サービスを組み込むことでした。このアプローチを取れば、新しいIPアドレスを公開する必要を回避でき、チームは既存のスキャフォールディングを活用して迅速に作業できたでしょう。ただ、最初は有望に見えたこのアプローチも結局却下されました。FLには多大な投資が行われており、状況が流動的な中で構築することをチームが望まなかったからです。
そしてついに、Cloudflare Workersを使ってプロキシサービスを実装するというソリューションを見つけました！幸い、Workersは大量のリクエストに応じて自動的にスケールするため、新サービスの構築を選択すれば必要であろう準備作業の一部が不要になります。率直に言って、このアプローチはWorkersとCloudflareの内部サービスとの通信方法について不明瞭な点がいくつかあったため、当初は好まれませんでしたが、Workersチームのサポートにより前進の道筋が見つかりました。
WebSocketプロキシWorkerから、トンネルされたRDP接続が、Cloudflare Zero Trustのオンランプとオフランプの間のトラフィックルーティングを担当するApolloサービスへ送られます。Apolloはこうした複雑さを一元化し、抽象化して、他のサービスがアプリケーション固有の機能に集中できるようにします。Apolloは、ターゲットのCloudflare Tunnelに最も近いCloudflareコロケーションセンターを選定し、そのコロケーションセンターで実行されている同一のApolloインスタンスへの接続を確立します。次に、エグレスするApolloインスタンスがCloudflare Tunnelへの最終的な接続を促します。Cloudflareのグローバルネットワークを使って、イングレスのコロケーションセンターとターゲットのCloudflare Tunnel間の距離を移動することで、ネットワークの混乱と輻輳を管理することができます。
ApolloはRDPサーバーに接続し、イングレスとエグレスの接続をOxy-teamsに渡します。Oxy-teamsは、RDPトラフィックの検査とプロキシを担当するサービスです。WebクライアントがRDPサーバーに対して認証する際のパススルーとして機能（トラフィックの接続を厳密に有効化）します。当初のリリースでは、ユーザー名とパスワードの入力を必要とするチャレンジ応答型認証プロトコルであるNT LAN Manager（NTLM）認証を使用しています。クライアントがサーバーで認証されると、Oxy-teamsは後続のすべてのRDPトラフィックをプロキシすることができます。
ホップ数が多いように聞こえるかもしれませんが、当社はネットワーク内のすべてのサーバーですべてのサービスを実行しています。信じられないかもしれませんが、この複雑な過程を1台のサーバーで処理し、通信にUNIXドメインソケットを使用することで、パフォーマンスへの影響も最小限に抑えています。これらのサーバーのいずれかが過負荷になった場合、ネットワーク障害が発生した場合、またはハードウェアに問題が生じた場合、負荷はCloudflareのL4ロードバランサーUnimogによって自動的に隣のサーバーに移動します。
ユーザーによる開始： ユーザーがCloudflareのアプリランチャーからRDPサーバーを選択します（あるいは直接URL経由でアクセスします）。各RDPサーバーは、 Cloudflareによって保護されたパブリックホスト名に関連付けられます。
イングレス： このリクエストは、Cloudflareのネットワーク内の最寄りのデータセンターで受信されます。
認証： Cloudflare Accessは、リクエストに有効なJWTが含まれていることを確認し、セッションを認証します。このトークンは、ユーザーが指定されたドメインを通じて選択されたRDPサーバーにアクセスすることを認められていることを証明します。
Webクライアント配信： Cloudflare WorkersはIronRDP Webクライアントをユーザーのブラウザに配信します。
セキュアトンネリング： クライアントは、TLSで保護されたWebSocketを介して、ユーザーのブラウザからのRDPトラフィックを別のCloudflare Workerへトンネリングします。
トラフィックルーティング： IronRDP接続を受信したWorkerはWebSocket接続を終了し、Apolloへの接続を開始します。そこから、ApolloはRDPサーバーへの接続を作成します。
認証リレー： 接続が確立されると、ApolloはWebクライアントとRDPサーバーの間でRDP認証メッセージを中継します。
接続確立： 認証が成功すると、CloudflareはWebブラウザとRDPサーバーの間のRDPプロキシとして機能し、フリーフローのトラフィックでユーザーをRDPサーバーへ接続します。
ポリシー適用： CloudflareのセキュアWebゲートウェイであるOxy-teamsは、レイヤー4ポリシーとRDPトラフィックのログ記録を適用します。
このアーキテクチャの主なメリット：
追加ソフトウェア不要： ブラウザからWindowsサーバーに直接アクセスできます。
低遅延： Cloudflareのグローバルネットワークは、パフォーマンスのオーバーヘッドを最小限に抑えます。
セキュリティ強化： RDPアクセスはAccessポリシーによって保護され、ラテラルムーブメントを防止します。
統合されたロギングと監視： 管理者は、RDPトラフィックを観察し、制御することができます。
Cloudflareのプロキシ機能の詳細については、プロキシのフレームワークを説明した関連ブログ記事をご覧ください。
CloudflareのブラウザベースのRDPソリューションは、最新のRDP認証メカニズムのみをサポートし、セキュアなアクセスのためのベストプラクティスを適用します。当社のアーキテクチャでは、安全でないパスワードベースの認証やRC4暗号化など、旧バージョンのRDP標準に従った古いセキュリティ機能や脆弱なレガシーセキュリティ機能を使用したRDPトラフィックが、お客様のエンドポイントに決して到達できないようにします。
Cloudflareは、以下の原則に基づいてセキュアなセッションネゴシエーションをサポートしています：
トランスポートセキュリティのためのTLSベースのWebSocket接続。
シングルサインオン（SSO）、多要素認証（MFA）、動的認証を適用するきめ細かなポリシー。
SAML（Security Assertion Markup Language）やOIDC（OpenID Connect）によるエンタープライズIDプロバイダーの統合。
Cloudflareのネットワークを経由するRDPセッションはすべて暗号化され、認証されます。
これは、当社のブラウザベースRDPソリューションの始まりに過ぎません。Cloudflareでは、引き続き注力すべき分野をいくつか既に特定しています：
管理者のための可視性と制御性の強化： RDPトラフィックはCloudflare Workersとプロキシサービスを経由するため、ブラウザベースのRDPを拡張しセッションの監視も含まれるようにします。また、パフォーマンスを損なうことなく不正なデータ流出を防ぐため、ファイル転送やクリップボード使用などのアクションを制限するといったデータ損失防止（DLP）サポートも評価しています。
高度な認証： 長期間有効な認証情報はもはや過去のものです。将来的には、ブラウザベースのRDPのイテレーションにパスワードレス機能を含め、エンドユーザーがパスワードを記憶する必要も、管理者がパスワードを管理する必要もなくします。そのために、クライアント証明書認証、パスキーとスマートカード、Accessを介したサードパーティ認証プロバイダーとの統合などの方法を評価しています。
企業および政府機関向けのFedRAMP HighサービスにブラウザベースのRDPを含める予定です。これは、2月初旬に発表した優先度の高い取り組みです。「High（ハイ）」認証を取得すれば、当社のソリューションが以下について最高基準を満たしていると確認されたことになります：
データ保護
IDとアクセス管理
継続的な監視
インシデント対応
FedRAMP Highの準拠を目指す取り組みは、連邦政府、ヘルスケア、金融などのセクターのように機密性の高い環境の保護に対するCloudflareのコミットメントを示すものです。
Cloudflareは、こだわりをもって最新かつセキュアなRDP実装を実施することにより、セキュリティとコンプライアンスの重要義務を負う組織のニーズに応じて、セキュアでスケーラブルでコンプライアンス要件に適合したソリューションを提供します。
Cloudflareは、ZTNAのための極めて包括的なソリューションを提供することに尽力しています。このソリューションには現在、ブラウザベースのRDPを介した、Windowsサーバーのような機密性の高いインフラへの特権アクセスも含まれています。CloudflareのブラウザベースのRDPソリューションはクローズドベータ版で、毎週、新しいお客様をオンボードしています。こちらからアクセスをリクエストして、この魅力的な新機能をお試しください。
また、Cloudflareが機密性の高いインフラへの特権アクセスをどのように保護しているかを、Access for Infrastructureのドキュメントでご確認ください。Access for Infrastructureは現在、ユーザー50人未満のチームは無料で、既に従量課金プランおよび契約プランをご利用のお客様はAccessまたはZero Trustのサブスクリプションを通じて追加料金なしでお使いいただけます。当社は今後も、BastionZeroのテクノロジーをCloudflareのAccess for Infrastructureサービスにネイティブに再構築していきますので、ご期待ください！