Cloudflare +リモートブラウザ分離

Cloudflareは本日、S2 Systems Corporationを買収したことをお知らせいたします。現在、市場に出回っている他社製品とは異なり、革新的なリモートブラウザ分離ソリューションを構築しているシアトルエリアのスタートアップ企業です。エンドポイントの侵害の大半は、Webブラウザが関わります。ユーザーのデバイスとWebコードを実行する場所の間にスペースを置くと、ブラウザ分離によってエンドポイントの安全性が大幅に向上します。このブログでは、ブラウザ分離とは何か、なぜそれが重要なのか、S2 Systemsがどのようにクラウドブラウザを機能させるのか、より良いインターネットの構築に貢献するというCloudflareのミッションにどのように適合するのかについて、お話ししたいと思います。

Tim Berners-Lee 氏が、現在World Wide Webと呼ばれるものの基礎となるテクノロジーを定義するプロジェクトの考案を書いてから30年以上の年月が経ちました。Berners-Lee氏が「 非常に創造力があり、共通の目標に向かって取り組んでいる数千人」にとって役に立つと思い描いていたもの[1]は、商業、ビジネス、グローバル経済の基礎部分であり、世界人口の58%以上によって用いられる社会の不可欠な部分[2]にまで成長してきました。

World Wide WebとWebブラウザが人が毎日生産的な仕事（と遊び）のほとんどを行うプラットフォームになっているのは明らかです。しかし、Webの広汎性が高まるにつれて、犯罪者にとってのチャンスも増えました。毎日のように大規模な新しいサイバーセキュリティ侵害のニュースが報道されています。サイバー犯罪を前例のないレベルにまで押し上げる要因がいくつかあります。そうした要因とは、ハッキングツールの商業化、malware-as-a-service（サービスとしてのマルウェア）の出現、十分な資金力を持つ国家と組織犯罪の存在、あらゆる悪意のある行為者が匿名で活動を収益化できる暗号通貨の発展などです。

セキュリティ侵害の大部分はWebから発生しています。米国の調査会社 Gartnerは、パブリックインターネットを「攻撃の巣窟」と呼び、Webブラウザをエンドポイント侵害の70%を引き起こす第一容疑者と見ています。[3]実は、あまり驚くべきことではありません。最新のWebブラウザが卓越していると言っても、基本的なアーキテクチャ上の意思決定の多くが、セキュリティやプライバシー、企業管理、コンプライアンスといったコンセプトが問題になる以前の1990年代に作成されています。主力のWebブラウジング機能（基盤となるWWWアーキテクチャ全体を含む）は、違う時代と環境向けに設計され構築されたものです。

今日の世界で、Webブラウジングの前提は時代遅れなだけでなく、危険でさえあります。Webブラウザとその基盤となるサーバーテクノロジーは複雑に相互関連するテクノロジーを含んでおり、そうしたテクノロジーは広範囲にわたり、数も増え続けています。常に活発なオープンソースコミュニティ、コンテンツパブリッシャー、検索エンジン、広告主、ブラウザ企業間の競争によって動かされ、常に流動的です。その根底にある複雑性のために、Webブラウザは主要な攻撃ベクトルになるという結果に陥っています。Gartnerによると、「ユーザーがインターネットを閲覧したり、_URL_リンクをクリックするという行為そのものが、企業にとっては多大なリスクを招くことなのです。[…]ブラウザを介して攻撃するのは簡単で、ターゲットも豊富です。」[4]「表向き優良なWebサイトが簡単に侵害され、訪問者を攻撃するために使われてしまいます」（Gartner[5]）悪意のあるURLの40%以上が優良ドメインで見つかっています（[6]）。（脆弱性の完全なリストは、この記事では扱いません。）

Webを支える構造と基盤となるテクノロジーは、本質的に安全を維持するのが困難です。ブラウザの脆弱性は、正当な機能の違法な使用が原因です。ブラウザでファイルやドキュメントのダウンロードができるようにするのはいいことですが、マルウェアに感染しているファイルをダウンロードすることを許可するのは、危険なことです。1つのWebページ内で複数のサイトからコンテンツを動的に読み込むことはいいことですが、クロスサイトスクリプティングは避けるべきことです。さらに、広範囲な広告エコシステムを有効にすることはいいのですが、ハイジャックされたリンクやマルウェアやフィッシングサイトへと悪意のあるリダイレクトを検出できないのは良くないことです。

企業は、従来のブラウザをめぐってさらに多くの課題を抱えています。

逆説的になりますが、IT部門は企業内で最もユビキタスなアプリ、つまりWebブラウザに対する制御が一番できていない部門です。企業セキュリティとITの専門家から言われる最も一般的なWebブラウザについての苦情は、次の通りです。

1. （当然ながら）セキュリティ。セキュリティ侵害が絶えないのはパブリックインターネットが原因であり、問題は増え続けて、2016年以降、攻撃は11倍も増加しています（Meeker[7]）。検出と修復にかかる費用は増える一方で、侵害による風評被害や財政的被害は相当なものになるかもしれません。

2. コントロール。IT部門はユーザーのアクティビティに対する可視性がほとんどなく、コンテンツの非武装化と再構築（CDR）、いつどこで誰がファイルをダウンロードしたかまたはアップロードしたかを含めたデータ損失防止（DLP）メカニズムを活用する機能も制限されています。

3. コンプライアンス。地域を超えてデータとアクティビティの制御ができなかったり、さらに厳しくなる規制要件を満たすために必要となる監査のテレメトリーが得られなかったりします。その結果、重大な罰則や罰金の対象となります。

EメールやWebブラウジングといった日常的なユーザーのアクティビティで、引き起こされる脆弱性を考慮して、こうしたアクティビティを制限する組織もあります。どちらも正当で重要なビジネス機能であるため、Webブラウザ利用を制限したり縮小したりする努力は必然的に失敗するか、業務の生産性と従業員のモラルに大きな悪影響を及ぼすことになります。

Web閲覧に起因するセキュリティ問題を軽減する現行のアプローチは、主にデータファイルと実行可能ファイルのシグネチャテクノロジーと既知の優良/不良URLアドレスとDNSアドレスリストに基づいています。こうしたアプローチの問題は、既知攻撃（ファイルのシグネチャ、URLとDNSアドレス）とゼロデイ攻撃に対する固有の脆弱性についての情報を最新の状態にしておくのが難しいことです。ハッカーはシグネチャベースのアプローチを打ち負かし（例：未知のシグネチャがついた大量のファイルを生成する）、URL/DNSブロックリストを回避すために何百もの一時的なWebサイトを生成する自動化されたツールを考案してきました。

こうしたアプローチが一部の攻撃を防止できるのは間違いありませんが、インシデント数の増加とセキュリティ侵害の深刻度の高まりは効果的な代替手段が必要となっていることを明確に示しています。

ブラウザ分離には、物質的な分離によるセキュリティという中核的な概念があります。ユーザーのWebブラウザとエンドポイントデバイスの間に「間隔」を作り、それによって悪用や攻撃からデバイス（と企業ネットワーク）を保護します。既知の脅威パターンまたはシグネチャに依存するセキュアなWebゲートウェイ、ウイルス対策ソフトウェア、ファイアウォールとは異なり、これはゼロトラストアプローチです。

主要なブラウザ分離アーキテクチャが2つあります。(1)クライアントベースローカル分離と(2)リモート分離です。

ローカルブラウザ分離は、アプリレベルまたはOSレベルのサンドボックスを利用してローカルエンドポイントで実行するブラウザを分離しようとします。分離に失敗があると、エンドポイントにリスクが残るだけでなく、こうしたシステムは特定のハードウェアとソフトウェアコンポーネントからのサポートに依存するため、大量のエンドポイントリソース（メモリ＋コンピューティング）が必要となり、脆くなってITチームが管理するのが難しくなります。

さらに、ローカルブラウザ分離は前述のような制御上の問題とコンプライアンス上の問題を解決する方法にはなりません。

リモートブラウザ分離（RBI）は、クラウドのリモートサービスまたは企業ネットワーク内の別のオンプレミスサーバーへとブラウザを移動することでエンドポイントを保護します。

• オンプレミス分離は、実際にリスクを排除せずに、エンドポイントから企業内の別のロケーションへと単に場所を変えるだけです。

• クラウドベースのリモートブラウジングは、ITコントロールとコンプライアンスソリューションを完全に有効化する一方で、エンドユーザーのデバイスと企業のネットワークを分離します。

こうした特有の利点から、S2 Systemsを含めたブラウザ分離ソリューションの多くがクラウドベースのリモート分離を活用しています。適切に実装されたリモートブラウザ分離は、ブラウザの悪用、プラグイン、ゼロデイ脆弱性、マルウェア、Webコンテンツに埋め込まれた攻撃から組織を保護することができます。

通常のクラウドベースのRBIシステム（下記の青い破線のボックス❶） では、個々のリモートブラウザ❷はクラウドで削除可能なコンテナインスタンスとして実行されます。通常ユーザー1人につき1つのインスタンスです。リモートブラウザは、特定のプロトコルとデータフォーマット❸を使って、Webページのレンダリングされたコンテンツをユーザーのエンドポイントデバイス❹に送信します。キーストローク、マウスコマンド、スクロールコマンドなどのユーザーの動作は、セキュアな暗号化チャンネルを介して分離サービスに送り返されます。その後で、リモートブラウザによって処理され、リモートブラウザのWebページへの変更はエンドポイントデバイスに送り返されます。

実際、エンドポイントデバイスは、クラウドブラウザを「リモートコントロール」しています。既存のRBIシステムはローカルエンドポイントにインストールされている専用のクライアントを使います。一方、他のクライアントはエンドポイントでHTML5と互換性があるブラウザを活用し、「クライアントレス」と見なされます。

リモートブラウザで発生したデータ漏えいは、ローカルエンドポイントと企業ネットワークから分離されています。リモートブラウザインスタンスは全て、各セッションの後に侵害され処理されたかのように取り扱われます。新しいブラウザセッションが新しいインスタンスで開始します。言うまでもなく、RBIサービスはブラウザコンテナの外部からサービス自体にブラウザ侵害がもれるのを防ぐ必要があります。ほとんどのRBIシステムはファイルのダウンロードの不要にするリモートファイルビュアーを提供するだけでなく、ダウンロードを許可する前にマルウェアを検査する機能もあります。

上記のアーキテクチャで不可欠なコンポーネントはクラウドRBIサービスで採用されている特定のリモートテクノロジーです。リモートテクノロジーは運用コストとRBIサービスの拡張性、Webサイトの忠実度と互換性、帯域幅要件、エンドポイントハードウェア/ソフトウェア要件、ユーザー体験に大きな影響を与えます。リモーティングテクノロジーは、RBIシステムが提供するセキュリティの実効レベルも決定します。

現在のクラウドRBIシステムは、次のいずれかのリモートテクノロジーを採用します。

(1) ピクセルプッシングはリモートブラウザ「ウインドウ」のピクセル画像をキャプチャして、一連の画像をクライアントのエンドポイントブラウザか、専用クライアントに送信するビデオベースのアプローチです。これは、リモートデスクトップとVNCシステムの動作とよく似ています。比較的安全だと考えられてはいますが、このアプローチならではの問題もあります。

• リモートWebページの動画のストリーミングをエンコードしたりユーザーエンドポイントデバイスに送信するのは、非常にコストがかかります。このアプローチを数百万人ものユーザーに広げると、コスト面でも困難で、ロジスティックの面でも複雑になります。

• かなりの帯域幅も必要となります。高度に最適化されている場合でも、ピクセルをプッシュすると帯域幅が集中します。

• 不可避のレイテンシーはユーザー体験に不満を残します。こうしたシステムは低速になりやすく、ユーザーから多くの苦情が寄せられることになります。

• 不安定な接続が原因で大量の帯域幅が必要となることでモバイルサポートのレベルが低下します。

• HiDPIディスプレイは、低解像度でレンダリングされることがあります。画素密度は解像度によって、指数関数的に増加します。これは、HiDPIデバイスのリモートブラウザセッション（特にフォント）がぼやけて見えたり、ピンぼけになる可能性があります。

(2) DOM再構築はピクセルプッシングの欠点を補う手法として登場しました。DOM再構築は、コンテンツをローカルエンドポイントブラウザに転送する前にWebページ、HTML、CSSなどをクリーンにしようとします。基本となるHTML、CSSなどはアクティブコード、既知のエクスプロイト、他の潜在的な悪意のあるコンテンツを削除するために、再構築されます。レイテンシー、運用コスト、ピクセルプッシングでのユーザー体験問題に取り組む中で、2つの重要な問題が起きました。

• セキュリティ。基盤となるテクノロジー（HTMLやCSS、Webフォントなど）はハッカーがエンドポイントを侵害するために活用する攻撃ベクトルです。悪意のあるコンテンツまたはコードを排除しようと試みることは、蚊を洗うようなものです。きれいにすることはできますが、危険で悪意のあるコンテンツ固有のキャリアであるという事実は変わりません。RBIシステムを通してもこうしたテクノロジーを悪用する手段をすべて、事前に特定することは不可能です。

• Webサイトの忠実度。必然的に、悪意のあるアクティブなコードを削除し、HTML、CSS、最新Webサイトの再構築をしようとすると、適切にレンダリングしないまたは、全くレンダリングしない壊れたページが表示されます。今日動作しているWebサイトが、明日は動作しないこともあり得ます。それは、サイトパブリッシャーが毎日変更するサイトがDOM再構築を機能的に破壊する可能性があるからです。その結果、もぐらたたきゲームのように終わりのないゲームで重要なリソースを必要とする問題が永遠に続くことになります。マルウェアを含んだEメールが依然として、侵害の大きな原因であり続けているにもかかわらず、Google G SuiteやMicrosoft Office 365のように一般に普及しているエンタープライズサービスのサポートに、RBIソリューションは悪戦苦闘しています。

お客様は、ユーザー体験が悪く運用コストが高い安全なソリューションか、より高速ではあるが安全性がずっと低くWebサイトを壊すソリューションのどちらかを選択するしかありません。このようなトレードオフは、一部のRBIプロバイダーが自社製品にリモートテクノロジー両方を実施する要因となっています。しかし、依然として根本的な問題を解決せずに、お客様に究極の選択をさせることになります。

RBIシステムで大きなトレードオフとなることを考えると、リスクの高い経営幹部、経理部、ビジネス開発部、人事部の従業員など組織で最も脆弱なユーザーだけにリモートブラウジング機能をデプロイするのが、お客様のためによく行われる最適化です。しかし、教室にいる生徒の半分だけにワクチン接種をするようなものでセキュリティに関する間違った考え方です。これでは、大きな組織を保護する上で、ほとんど効果がありません。

残念なことですが、最大の「ギャップ」は現行のリモートブラウザ分離システムによって作られており、基盤となる分離に関する概念の潜在的な可能性と利用可能なRBIシステムの実装における現実との間にできた隔たりなのです。

S2 Systemsのリモートブラウザ分離は、ネットワークベクトルレンダリング（NVR）と呼ばれるS2特許技術に基づいた、根本的に異なるアプローチです。

S2リモートブラウザは、Google ChromeのベースであるオープンソースのChromiumエンジンを使用しています。市場シェア最大70%[8]のGoogle Chromeに加えて、Chromiumは新しいMicrosoft Edgeブラウザを含む21のWebブラウザで活用されています。[9]その結果、Chromiumエンジンへの継続的な高額投資をすることで、高レベルのWebサイトサポート、互換性、継続的な改善の流れが保証されます。

Chromiumブラウザの主要なアーキテクチャ機能は、Skiaグラフィックライブラリーの使用です。Skiaは広く利用されるクロスプラットフォームグラフィックエンジンで、Android、Google Chrome、Chrome OS、Mozilla Firefox、Firefox OS、FitbitOS、Flutter、Electronアプリケーションフレームワークとその他多数の製品で使用されています。Chromiumと同様に、Skiaの普及率は高いので、ハードウェアとプラットフォームの継続的かつ広範なサポートが保証されます。

_Skia_コードフラグメント

Chromiumブラウザウインドウで表示されるものはすべてが、Skiaレンダリングレイヤーを通してレンダリングされます。これには、メニューなどのアプリケーションウインドウUI が含まれますが、もっと重要なことは、Webページウインドウのコンテンツ全体がSkiaを介してレンダリングされることです。Chromiumの構成、レイアウト、レンダリングは異なるコンテンツの種類、デバイス、コンテキストに最適化された複数のパラレルパスを伴って極端に複雑です。次の図は、S2の仕組みを説明するために、かなり簡略化したものです（Chromiumの専門家の皆さん、すみません）。

S2SystemsのNVRテクノロジーは、リモートChromiumブラウザのSkia描画コマンド❶をインターセプト（傍受）してからトークン化して圧縮し、そして暗号化してワイヤ❷を介して、ユーザーエンドポイントデスクトップまたはモバイル端末でローカルに実行するHTML5準拠のWebブラウザ❸（Chrome、Firefox、Safariなど）へと送信します。NVRにキャプチャされたSkia APIコマンドは事前にラスタ化されています。つまり非常にコンパクトだという意味です。

S2 RBIサービスは、初回使用時にNVRWebAssembly（Wasm）ライブラリ❹を後で使用する場合のためにキャッシュするエンドポイントデバイスにあるローカルHTML5 Webブラウザへと透過的にプッシュします。NVR Wasmコードには埋め込まれたSkiaライブラリとアンパック、解読、リモートRBIサーバーからローカルブラウザウインドウへのSkiaからの描画コマンドに「返信する」ために必要なコードが含まれています。WebAssemblyの機能は「広範なプラットフォームで利用できる共通ハードウェア機能を巧みに活かして、ネイティブのスピードで実行する」[10]もので、ネイティブに近い描画パフォーマンスを実現します。

S2 リモートブラウザ分離サービスはクラウド内のChromiumベースのヘッドレスブラウザを使用し、描画レイヤー出力を透過的にインターセプトし、描画コマンドをWeb上で効率的かつ安全に送信し、ローカルHTML5ブラウザのウインドウで再描画します。このアーキテクチャは技術的な利点がたくさんあります。

(1)セキュリティ：基盤となるデータ転送は既存の攻撃ベクトルではなく、お客様はセキュリティとパフォーマンスの間でトレードオフを強いられることはありません。

(2) Webサイトの互換性：Webサイトの互換性問題がなく、進化するWebテクノロジー、新たに出現した脆弱性を追いかける長いテールもありません。

(3) パフォーマンス：システムは非常に速く、通常ローカルブラウジング（今後のブログ記事の題材）よりも高速です。

(4) 透過的なユーザー体験：S2 リモートブラウジングはネイティブのブラウジングのように感じられ、ユーザーはリモートでブラウジングしている時、それを気がつかないほどです。

(5) ほとんどのWebサイトでローカルブラウジングより帯域幅が小さくて済みます。Webブラウザに特有の高度なCachingとその他の独自な最適化、Webコンテンツとテクノロジーの特質を有効にします。

(6)クライアントレス：すでにユーザーエンドポイントデスクトップとモバイル端末にインストールされている、既存のHTML5の互換性があるブラウザを活用します。

(7) 優れた費用対効果のスケーラビリティ：これに関する詳細は、この記事の範囲を超えるものですが、S2バックエンドとNVRテクノロジーは実質的に既存のRBIテクノロジー処理も運用コストを大幅に削減されます。運用コストは、直接お客様のコストに換算されます。S2システムは、企業全体で展開するようにデザインされており、お客様にとって実行可能で魅力あるユーザーだけ（つまり前述のクラスの半分にワクチン接種する）を対象としているのではありません。

(8) RBI-as-a-platform（プラットフォームとしてのRBI）：DLP、コンテンツの非武装化と再構築（CDR）、フィッシング検出と予防など、関連/付帯サービスの実装を可能にします。

S2Systemsリモートブラウザ分離サービスと基盤となるNVRテクノロジーが、ブラウザ分離の概念的な潜在性と約束と現行のRBIテクノロジーの満足いかない現実の間での隔たりを排除します。

Cloudflareのブローバルなクラウドプラットフォームは、一意的にリモートブラウジング分離に適しています。当社のクラウドネイティブのパフォーマンス、信頼性、高度なセキュリティ製品とサービスとシームレスに統合し、当社製品のパワフルな機能を提供します。

CloudflareのWorkersアーキテクチャは90か国以上200都市でエッジコンピューティングを有効化し、先進国においてインターネット人口の99%以上に向けて100ミリ秒以内での対策の実行が可能です。2000万以上のインターネットプロパティが直接当社のネットワークと接続しているため、Cloudflareのリモートブラウザ分離は、地域的にキャッシュしたデータからメリットを受け、優れた接続性とネットワークのパフォーマンスの上に成り立っています。Argo Smart Routingの機能は、当社の通信バックボーンを活用してより高速で信頼度の高いネットワークパスを介してトラフィックをルーティングしています。その結果、Webアセットへのアクセスが平均30%も加速しました。

Cloudflare for Teamsスイートの高度なセキュリティ製品とされると、リモートブラウザ分離は、ブラウザの悪用、ゼロデイ脆弱性、マルウェア、Webコンテンツに埋め込まれたその他の攻撃から保護します。企業は、セキュリティかユーザー体験かのトレードオフをする必要がなく、全従業員のためにブラウザを安全にすることができます。サービスによってブラウザから送信される企業データのITコントロールとコンプライアンス監視を可能にできます。当社の製品とサービス全体でシームレスな統合することで、ユーザーも企業も恐怖心や結果を気にすることなく、Webを閲覧できるようになります。

Cloudflareはより良いインターネットの構築に貢献するというミッションを掲げています。インターネットで仕事をしたり遊んだりするため、ユーザーも企業も保護するということです。そして、インターネットアクセスを加速し、信頼性と透明性を持たせるということです。Webブラウジングの仕組みを再考して最新化することは、より良いインターネットの構築に貢献する上で重要な部分です。

[1] https://www.w3.org/History/1989/proposal.html

[2] “Internet World Stats,”https://www.internetworldstats.com/、情報取得日2019年12月21日

[6] “2019 Webroot Threat Report: Forty Percent of Malicious URLs Found on Good Domains”, 2019年2月28日

[7] “Kleiner Perkins 2018 Internet Trends”, Mary Meeker.

[8] https://www.statista.com/statistics/544400/market-share-of-internet-browsers-desktop/、情報取得日2019年12月21日

[9] https://en.wikipedia.org/wiki/Chromium_(web_browser)、情報取得日2019年12月29日

[10] https://webassembly.org/、情報取得日2019年12月30日