Remote Browser Isolation ゼロトラストアーキテクチャをどのようにRemote Browser Isolation
- 明示的に確認してください：RBIはデフォルトで全てのWebセッションを信頼できないものとみなしており、コンテンツを表示する前に、隔離されたクラウドコンテナ内でレンダリングを行います。
- Webコンテンツにおける最小権限の原則：ユーザーはページの視覚的な表示とやり取りを行うものであり、生のHTML、JavaScript、または実行可能ファイルと直接やり取りすることは決してありません。
- 侵害を前提とする：たとえサイトが完全に乗っ取られたとしても、攻撃対象となるのは一時的なコンテナであり、エンドポイントでも、それでもない。
- CISA ZTMMとの整合性：RBIは、CISAの複数の柱、すなわち「デバイス」（管理対象外のエンドポイントの保護）、「アプリケーション」、および「ワークロード」をサポートしています。
- SSEの統合は不可欠です。RBIは、SWG、CASB、ZTNA、DLPと統合することで、最大のゼロトラストの価値を発揮します。
- 「導入格差」は依然として現実のものだ。ほとんどの企業は、ゼロトラストの成熟度向上に向けた道のりの初期段階にあり、ブラウザ層での制御も同様である。
Remote browser isolation RBI）は、ゼロトラストの中核となる指針「いかなるコンテンツ、セッション、デバイスに対しても暗黙の信頼を決して与えない」を最も直接的に技術的に具現化したもののひとつです。NIST SP 800-207の原則やCISAのゼロトラスト成熟度モデルに制御策を照合するセキュリティアーキテクトにとって、RBIは、SWGによるURLフィルタリングやエンドポイント検知だけでは埋められないギャップ、すなわち判定が下される前に実行されてしまうブラウザ経由の脅威を解消します。 本記事では、RBIがゼロトラストの「明示的な検証」「最小権限の原則」「侵害を前提とする」という原則にどのように対応しているかを具体的に解説するとともに、最新のSSEスタックにおいて、ZTNA、SWG、CASB、DLPと並んでRBIがどのような位置づけにあるかを説明します。
Remote Browser Isolationとは何ですか？
Remote browser isolation 、Webブラウジングセッションをクラウド上でホストされるコンテナ内で実行し、すべてのWebコードをユーザーのエンドポイントから物理的に分離するセキュリティ技術Remote browser isolation 。ローカルデバイスは、アクティブなWebコードを直接処理することは決してなく、代わりにピクセルストリーム、あるいはサニタイズされ再構築されたDOMのみを受け取ります。
ある中規模製造企業の調達アナリストが、新規サプライヤーからリンクを受け取った場面を想像してみてください。そのドメインは先週登録されたばかりで、URLの評価履歴がなく、「未分類」というグレーゾーンに位置しています。従来のSWG（Webゲートウェイ）であれば、これをブロックしてアナリストを苛立たせるか、あるいは許可して未知のものを信頼することになるでしょう。 RBI を使用すると、ページは使い捨てのクラウドコンテナ内で読み込まれます。アナリストは、フォームへの入力や PDF のダウンロードなど、完全にインタラクティブなページを閲覧できますが、JavaScript や ActiveX、埋め込まれたエクスプロイトが自分のノートパソコンに接触することは一切ありません。仮にそのページにゼロデイエクスプロイトが潜んでいたとしても、タブを閉じた瞬間にコンテナ内のデータが消去されるため、コンテナ内で無害に処理されるだけです。
このモデルは、これまで以上に重要になっています。Google Threat Intelligence Group（GTIG）の調査によると、2024年に実環境で悪用されたゼロデイ脆弱性は75件に上り、そのうち44％がエンタープライズ向け技術を標的としていました（GTIG、2025年4月）。ブラウザを介した攻撃チェーンは依然として根強い攻撃経路であり、RBIは脅威が既知か否かを問わず、多層防御を実現します。
ゼロトラストにおいてRBIが重要な理由
ゼロトラストは購入できる製品ではなく、一連の設計原則です。NIST SP 800 207 (2020) では、ゼロトラストとは、資産やユーザーアカウントに対して、その物理的またはネットワーク上の位置、あるいは資産の所有権のみに基づいて暗黙の信頼を与えることはないと想定するものとされています。 しかし、ブラウザは従来、暗黙の信頼に基づいて動作してきました。つまり、URLがSWGの許可リストに一致する場合や、ドメインに有効な証明書がある場合、エンドポイントはサーバーから送信されるすべてのコードを読み込み、実行します。これは、セッションレベルのやり取りに適用された境界型信頼モデルです。
成熟度の格差は依然として明らかである。ガートナーが2024年に実施したゼロトラスト導入に関する調査では、63％の組織がゼロトラスト戦略を完全または部分的に導入していると回答したが、ガートナーは、ほとんどの組織において、ゼロトラストが対象とする環境は依然として全体の半分以下にとどまり、企業全体のリスクの4分の1以下しか軽減できていないと指摘している。 依然として残る最も重要なギャップの一つが、ブラウザセッションである。ガートナーによると、ブラウザは現代の企業アプリケーションの大部分にとって主要なアクセス手段であるにもかかわらず、現在、セキュアなエンタープライズブラウザを導入している組織は10％未満にとどまっている。ただし、ガートナーは2028年までにその導入率が25％に上昇すると予測している。 ブラウザは、従業員がSaaSアプリケーション、AIツール、外部サイトと日々やり取りを行う場ですが、多くの組織では依然として、きめ細かな可視化、ポリシー、データ保護の制御を適用する代わりに、単純な「許可／ブロック」モデルで対応しています。
第三者ベンダーがホストする規制関連ポータルにアクセスする金融サービスのコンプライアンス担当者を想定してください。 SWGはこのドメインを「政府」として分類し、アクセスを許可します。しかし、ベンダーのポータルでは脆弱性のあるプラグインが実行されており、攻撃者が悪意のあるiframeを注入しています。RBIが導入されていない場合、担当者のエンドポイントが攻撃対象となります。RBIが導入されている場合、iframeは隔離されたコンテナ内で読み込まれ、悪意のあるペイロードはエンドポイントに到達することはありません。その結果、担当者は脅威の存在に気付くことなく、業務を完了することができます。
RBIが3つのゼロトラスト原則とどのように対応しているか
明示的に確認する
NIST SP 800 207 では、いかなる資産も本質的に信頼できるものではないと規定されており、企業はリソースへのアクセス要求を評価するたびに、その資産のセキュリティ態勢を評価しなければならない。 RBIは、この原則をWebセッション層で具体化しています。RBIは、URLのレピュテーションに基づいて二者択一の信頼判断を行うのではなく、条件を満たすすべてのセッションを隔離して実行し、コンテナ内での挙動に基づいてコンテンツを評価します。これにより、検証は単発的なゲート（URLチェック）から、継続的な封じ込めモデルへと移行し、たとえ「信頼された」ドメインであっても、エンドポイント上で生のコード実行権限は付与されません。
医療保険請求処理担当者がパートナーポータルを開き、ドライブバイダウンロードを引き起こすページに移動した時点で、従来の明示的な検証手段（MFA、デバイスのコンプライアンス、URLのレピュテーション）はすでに通過済みとなっています。ユーザーは認証済みであり、デバイスは管理下にあり、URLは安全と分類されています。RBIは、さらなる検証層を追加します。つまり、それまでのすべてのチェックを通過した後であっても、Webコンテンツ自体がエンドポイント上で実行されることは信頼されません。
最小権限の原則
NIST SP 800 207 では、可視性とアクセス可能性の両方を制限するために、最小権限の原則を適用することが規定されています。RBI は、Web コンテンツの配信にこの最小権限の原則を適用しています。ユーザーには、業務遂行に必要なもの、つまりページのレンダリング済み表示のみが提供されます。生の JavaScript、CSS、または実行可能オブジェクトは提供されません。RBI と統合された DLP 制御機能により、セッションの機密性に応じて、クリップボード操作、印刷、ファイルのアップロード、およびダウンロードをさらに制限することができます。
具体的な例を挙げると、マネージドサービスプロバイダーが、ZTNAを介して契約業者に自社のチケット管理システムへのアクセス権を付与する場合です。契約業者は認証を行い、デバイスのコンプライアンスチェックに合格した後、アプリケーションにアクセスします。 しかし、セキュリティアーキテクトはRBIポリシーも適用しています。これにより、契約業者のセッションは隔離された環境で実行され、コピー＆ペーストが無効化され、ダウンロードは平坦化されたPDFファイルに限定されます。契約業者はチケットの閲覧や更新はできますが、生データを抽出することはできません。これは、ネットワークアクセスだけでなく、セッション内でユーザーが実行できる操作に対しても「最小権限の原則」が適用されていることを示しています。
侵害が発生したと仮定する
NIST SP 800 207では、ネットワークは常に敵対的であり、外部および内部の脅威が常に存在すると想定されています。RBIはこの原則を設計に組み込んでおり、すべてのウェブページが侵害される可能性があると想定し、ウェブコンテンツとエンドポイントの間にエアギャップを構築しています。 クラウド・セキュリティ・アライアンス（CSA）が指摘しているように、RBI は高リスクの Web セッションを、隔離された一時的なクラウドコンテナ内で実行し、ユーザーのローカルエンドポイントがアクティブな Web コードと直接やり取りすることは決してありません（CSA、2026年1月）。
営業担当者が、悪用されたJavaScriptライブラリを介してファイルレス型マルウェアのペイロードを配信する、侵害されたSaaSベンダーのマーケティングページにアクセスした場合、そのペイロードはコンテナ内で実行され、セッションが終了すると破棄されます。永続化メカニズムも、横方向の移動の機会も、エンドポイント上の痕跡も一切残りません。脅威がスタック内の他のすべての制御を迂回したとしても、「侵害を前提とする」姿勢は維持されます。
RBIがCISAのゼロトラスト成熟度モデルにどのように位置づけられるか
CISAゼロトラスト成熟度モデル v2.0（2023年）は、ゼロトラストを「アイデンティティ」、「デバイス」、「ネットワーク」、「アプリケーションおよびワークロード」、「データ」という5つの柱に分類し、さらに「可視化と分析」、「自動化とオーケストレーション」、「ガバナンス」という3つの横断的機能で構成されています。RBIは、複数の柱に同時に貢献しています：
CISA ZTMMの柱：RBIの貢献と満期までの経過
NIST SP 800 207 では、ポリシーエンジン（PE）、ポリシー管理者（PA）、ポリシー施行ポイント（PEP）からなるアーキテクチャの三要素が定義されています。このモデルにおいて、RBI はブラウザのセッション層において PEP として機能します。 PEは、リクエストのコンテキスト（ユーザーの身元、デバイスの状態、URLのリスク、データの機密性）を評価し、PAはRBIサービスに対し、セッションを隔離し、適切なデータ制御を適用するよう指示します。これは、クラウドセキュリティアライアンス（CSA、2026年1月）が記述している、CISAのリクエストごとの検証体制要件と整合しています。
SSEスタックにおけるRBI：ZTNA、SWG、CASB、DLPとの統合
RBIを単独で利用しても有用ではありますが、その効果には限界があります。RBIが、SWG、CASB、ZTNA、DLPなどを含むSecurity Service Edge SSE）プラットフォーム内の統合コンポーネントとして機能して初めて、ゼロトラストの真価が発揮されるのです。
管理対象デバイスを使用している従業員が、ブラウザを通じて生成型AIツールにアクセスする場合のワークフローを考えてみましょう。SWGはリクエストを検査し、宛先を分類して、URLのリスクを判定します。 CASBはAIアプリケーションを識別し、それが許可されているかどうかを確認します。DLPエンジンはプロンプトテキストをスキャンして機密データを検出します。また、AIツールが「監視対象」に分類されているためSWGポリシーによってトリガーされるRBIセッションにより、従業員はツールを使用できるものの、顧客の個人識別情報（PII）を貼り付けたり、機密情報を含む応答をダウンロードしたり、規制対象のデータを含むファイルをアップロードしたりすることはできなくなります。これらすべてが、個別のコンソールを備えた4つの独立した製品にまたがるのではなく、単一のポリシーエンジン内で実行されます。
この統合パターンこそが、ガートナーがSASE市場が年平均成長率（CAGR）26％で成長し、2028年までに285億ドルに達すると予測している理由です（ガートナー、2025年2月）。 企業がアクセス制御、脅威対策、データセキュリティを統合プラットフォームに集約しているのは、その代替手段であるスタンドアロンのRBI、SWG、CASB、DLP製品を個別に組み合わせる方法では、ポリシーの不整合や適用の一貫性の欠如、運用上のオーバーヘッドが生じ、ゼロトラストモデルを損なうためです。
SkyhighPrivate Access 、ZTNAとDLPスキャン、シームレスなRBIPrivate Access 、ポリシーで必要とされる場合に、トラフィックを別の製品を経由させることなく、プライベートアプリケーションのセッションを隔離します。
ブラウザがワークスペースとなる場所
ブラウザは、SaaSへのアクセス、AIツールの利用、ファイルのダウンロード、認証情報の入力、およびサードパーティとの共同作業を行うための主要な作業環境です。プライベートアプリケーションを保護するためにZTNAを導入しながらも、従業員がそれらのアプリケーションを操作するブラウザセッションを無視しているセキュリティアーキテクトには、セキュリティ対策の抜け穴が存在します。RBIは、ユーザーがすでに慣れ親しんでいるブラウザ（Chrome、Edge、Firefox、Safari）を置き換えるのではなく、SSEポリシーによって制御されるクラウドベースの隔離レイヤーでセッションを包み込むことで、その抜け穴を埋めます。
管理対象外の契約業者が、リバースプロキシ型CASBを介して企業のCRMアプリケーションを開きます。CASBは契約業者を認証し、セッション制御を適用するとともに、そのデバイスが管理対象外であるためRBIポリシーをトリガーします。契約業者は通常通りCRMを閲覧・利用できますが、裏側ではセッションが隔離された状態で実行され、クリップボードの使用制限やダウンロードのブロックが行われています。企業は、契約業者にエージェントのインストール、デバイスの登録、あるいは専用ブラウザの使用を強制することなく、データのセキュリティを確保しています。
評価基準：ゼロトラストRBIで重視すべき点
RBIの実装すべてが、同等のゼロトラストの価値をもたらすわけではありません。ブラウザの隔離機能を評価するセキュリティアーキテクトは、以下の基準を検討する必要があります：
1. SSEとのネイティブ統合。RBIは、SWG、CASB、ZTNA、DLPと同じポリシーエンジンに組み込まれている必要があります。RBIに個別のコンソール、個別のポリシー、または個別のトラフィック制御が必要となる場合、運用上のギャップやポリシーの不整合が生じます。
2. 隔離セッション内でのきめ細かなデータ制御。ゼロトラストでは、セッションレベルでの最小権限の徹底が求められます。RBIは、ポリシーごと、ユーザーグループごと、およびアプリケーションカテゴリごとに、クリップボード、印刷、アップロード、ダウンロード、および画面キャプチャを個別に無効化できる機能をサポートすべきです。
3. 管理対象外のデバイスのサポート。隔離機能を利用するためにエンドポイントエージェントを必要とするソリューションは、RBIの主なユースケースの一つである「企業が管理していないデバイスからのアクセスを防御する」という目的と矛盾する。
4. パフォーマンスとユーザー体験。RBIによって目に見える遅延が生じると、ユーザーはそれを回避するようになる――個人所有のデバイスでリンクを開いたり、モバイルホットスポットを利用したり、あるいはIT部門が例外措置を講じるまで不満を訴え続けたりするだろう。分離層は、ネイティブに近い速度でページを表示できなければならない。
5. レンダリングの忠実度。現代のSaaSアプリケーションは、JavaScriptを多用した複雑なシングルページアプリケーションです。RBIは、機能を損なったり、インタラクティブな要素を欠落させたり、ユーザー体験を低下させたりすることなく、これらを処理できなければなりません。
6. ポリシーに基づくスケーラブルなアクティベーション。ゼロトラストでは、すべてのセッションを隔離する必要はありません。最適な実装では、セキュリティチームがリスクに基づいたトリガーを定義できるようになっています。具体的には、分類されていないURLを隔離する、高リスクユーザーのすべてのセッションを隔離する、特定のSaaSカテゴリを隔離する、あるいは管理対象外のデバイスからのすべてのトラフィックを隔離する、といったことが可能です。
7. 可視化と分析。RBIは、セッションのテレメトリデータをより広範なSSE分析レイヤーに提供し、CISAのZTMMにおける「可視化と分析」という横断的機能に貢献すべきである。つまり、誰が、いつ、どこから、どのデバイスを使用して、何にアクセスしたかを把握し、その行動がベースラインから逸脱しているかどうかを判断することである。
ブラウジングの死角がもたらす代償
ブラウザのセッションをゼロトラスト管理の対象外のままにしておくことには、測定可能なコストが伴います。IBMの『2024年データ侵害コスト報告書』（2024年7月）によると、2024年のデータ侵害による世界平均コストは488万米ドルに達しました。侵害された認証情報が最も一般的な攻撃経路であり、全侵害事例の16％を占めました。
ブラウザベースのフィッシングは、認証情報の窃取における主要な手口の一つです。 給与管理担当者が、福利厚生ポータルのログインページに見せかけたリンクを受け取ります。そのドメインは新しく登録されたもので、DMARCチェックを通過しており、一見すると正規のものに見えます。RBIが導入されていない場合、担当者は攻撃者のページに認証情報を入力してしまい、認証情報の窃取が完了してしまいます。RBIが未分類のドメインに対して隔離ポリシーを適用している場合、フィッシングページはコンテナ内で読み込まれ、DLPが認証情報の送信パターンを検知し、認証情報が隔離環境から流出する前にセッションが終了されます。
RBIの導入による経済的なメリットは、単なる理論上の話ではありません。ブラウザ層におけるセキュリティ対策の不備を解消した組織は、最もコストのかかる侵害経路――認証情報の盗難、Webを介したマルウェアの配布、監視対象外のブラウザ操作によるデータ流出――への曝露リスクを低減することができます。
ゼロトラストモデルにおけるRBIの導入でよくある間違い
RBIを単体製品として導入する場合。SSEとの統合がないと、RBIは独自のポリシー・サイロを持つ単なるポイントソリューションの一つになってしまいます。SWGとは別にRBIを導入する医療システムでは、2つの異なるURL分類エンジンと2つのポリシーコンソールが存在することになり、必然的にポリシーの不整合が生じます。その結果、ポリシー間の競合が発生し、例外が急増し、ゼロトラストモデルが損なわれてしまいます。
常にすべてを隔離する。一律の隔離は、コンピューティングリソースを浪費し、リスクの低いセッションのパフォーマンスを低下させます。リスクに基づくアプローチ、つまり分類されていないドメイン、高リスクのユーザーグループ、および機密性の高いアプリケーションカテゴリを隔離することで、摩擦を最小限に抑えつつ、より優れたセキュリティ成果を実現できます。
管理対象外のデバイスを無視している。一部の実装では、エージェントがトラフィックを隔離サービスへ誘導することを要求しており、RBIが最大の価値を発揮する具体的なユースケース（契約社員、BYOD、M&Aに伴う移行）が除外されてしまっている。個人のタブレットを使用して季節限定の倉庫管理者を採用する小売業者には、エージェントに依存したリダイレクトではなく、エージェントレスな隔離が必要である。
隔離セッション内でのDLP対策の怠り。データ制御を伴わないRBIは、マルウェアは阻止できるものの、データの持ち出しは防げない。通常のブラウザでは顧客記録を個人のメールに貼り付けることができない従業員でも、クリップボードの制御が実施されていない限り、隔離セッションを通じては依然として貼り付けが可能である。
RBIをVDIの代替として扱うこと。RBIはブラウザセッションを分離するものであり、デスクトップ全体を分離するものではありません。特定のユースケース（サードパーティによるWebアクセスなど）においてはVDIを補完しますが、ネイティブのデスクトップアプリケーションを必要とするユーザーにとっては、VDIの代わりにはなりません。