ブラウザ分離（RBI）とは？Remote Browser Isolationの仕組み・効果・弱点・導入方法を実務解説

最終確認日：2026年8月19日

冒頭文

ブラウザ分離（RBI：Remote Browser Isolation）は、WebサイトのHTMLやJavaScriptなどを利用者のPCではなく、クラウドや隔離環境にあるリモートブラウザで実行するセキュリティ技術です。

危険なWebサイトを開いてしまっても、悪意あるJavaScriptやブラウザ脆弱性を狙うコードを利用者端末へ直接実行させないことが目的です。

単純にWebサイトを「ブロックする」のではありません。

怪しいからブロックする

ではなく、

怪しいので、
PCから離れた安全な場所で開く

という考え方です。

CISAはWebブラウザ保護のガイドで、Remote Browser IsolationはWebデータの処理をローカル端末から安全な仮想環境やクラウド上の隔離環境へ移す技術だと説明しています。2025年のフィッシング対策ガイダンスでも、悪意あるリンクやバイナリからマルウェアが組織内へ広がることを防ぐ対策としてRBIを挙げています。

結論・要点

RBIの核心は、「Webサイトを信用してから開く」のではなく、「信用できなくても端末から隔離した場所で開く」ことです。

通常のブラウジングでは、

インターネット
      ↓
自分のブラウザ
      ↓
JavaScript実行
ファイル処理
ブラウザ脆弱性
      ↓
自分のPC

となります。

RBIでは、

インターネット
      ↓
リモートブラウザ
      ↓
HTML / JavaScriptを実行
      ↓
安全な描画結果だけ転送
      ↓
自分のブラウザ

という構造になります。

NISTのデータ機密性保護リファレンスでも、Browser Isolationは悪意あるWebコンテンツやインターネットから取得した実行ファイルを隔離し、エンドポイントへマルウェアが広がるリスクを抑える技術として扱われています。

ただし、RBIは万能ではありません。

認証情報フィッシング、セッション窃取、情報漏えい、SaaSの不正操作などは、RBIだけでは防げない場合があります。

そのため、

RBI
+
DNS / SWG
+
DLP
+
EDR
+
MFA
+
ID管理

として使うことが重要です。

この記事の要点

RBIは、Webサイトのコードを利用者PCではなく隔離されたリモートブラウザで実行するセキュリティ技術です。

RBIでは、悪意あるJavaScriptやブラウザ脆弱性への攻撃を利用者端末から物理的・論理的に遠ざけられます。

RBIは、危険なWebサイトを単純にブロックするのではなく、隔離環境で安全に閲覧させる考え方です。

RBIは、未知のWebサイト、新規ドメイン、フィッシングリンク、広告経由の攻撃への防御に有効です。

RBIでは、コピー、貼り付け、ファイルアップロード、ダウンロード、印刷、キーボード入力を制御できる製品があります。

RBIだけでは、利用者自身が偽ログイン画面へパスワードを入力する認証情報フィッシングを完全には防げません。

RBIは、SWG、DNSフィルタリング、DLP、EDR、MFAなどと組み合わせて利用することが重要です。

RBIは、VDIやVPNとは異なり、主にWebブラウザの実行環境だけをリモートへ隔離します。

RBIは、すべてのWeb通信を隔離するより、高リスク通信を動的に隔離する設計が実用的です。

RBI導入時は、表示遅延、WebGL、WebAuthn、ファイル転送、SSOなどの互換性を事前検証する必要があります。

この記事で分かること

この記事では、次の内容を説明します。

• RBIの基本的な仕組み
• 通常のブラウザとの違い
• マルウェアを防げる理由
• フィッシングに対する効果
• Pixel StreamingとVector Rendering
• RBIとTLSインスペクションの関係
• RBIとSWG・VDI・VPN・EDRの違い
• ファイル・クリップボード・DLP制御
• RBIでは防げない攻撃
• 導入対象の決め方
• 動作確認方法
• 運用上の問題
• 2026年時点で注意すべきMicrosoft Application Guardの扱い
• Zero Trust環境でのRBIの位置付け

対象読者・前提環境

この記事は、次の読者を想定しています。

• セキュリティ担当者
• インフラエンジニア
• SOC・CSIRT担当者
• 情報システム担当者
• Zero TrustやSASEを検討している企業
• フィッシング対策を強化したい企業
• SaaS利用時の情報漏えいを防ぎたい企業
• ブラウザ経由のゼロデイ攻撃を減らしたい企業
• TLSインスペクション、SWG、DLP、EDRとの違いを知りたい人

特定のRBI製品だけを対象にはしていません。

ただし、具体例については2026年時点のCloudflare Browser Isolation、Zscaler、Microsoft、CISA、NISTの一次情報を使用しています。

用語と全体像

RBIとは

RBIは、

Remote Browser Isolation

の略です。

日本語では、

• リモートブラウザ分離
• ブラウザ分離
• Web Isolation
• Browser Isolation

などと呼ばれます。

「危険かもしれない荷物を自宅で開封せず、別の検査施設で開ける」と考えると分かりやすくなります。

Webサイトの場合は、

HTML
CSS
JavaScript
WebAssembly
画像
動画
PDF
Webアプリ

などをリモート側で処理します。

CloudflareのRBIでは、JavaScriptなどのアクティブコンテンツを利用者端末ではなく隔離されたブラウザ上で実行します。

通常のWebアクセスとRBIの違い

通常のブラウザ

@startuml
title 通常のWebブラウジング

actor "利用者" as User
rectangle "利用者PC" {
    rectangle "ローカルブラウザ" as Browser
}

cloud "インターネット" {
    rectangle "Webサイト" as Web
}

User --> Browser : URLを開く
Browser --> Web : HTTPSリクエスト
Web --> Browser : HTML / JavaScript / File
Browser -> Browser : JavaScript実行\nHTML解析\nファイル処理

note right of Browser
悪意あるコードも
利用者PC上のブラウザへ届く
end note

@enduml

通常のブラウザでは、Webサイトから受け取ったコンテンツをローカルPCで処理します。

ブラウザに脆弱性が存在した場合、悪意あるWebサイトからブラウザやOSを攻撃される可能性があります。

RBIを使ったWebアクセス

@startuml
title Remote Browser Isolation

actor "利用者" as User

rectangle "利用者PC" {
    rectangle "ローカルブラウザ" as Local
}

rectangle "RBIクラウド / 隔離環境" {
    rectangle "リモートブラウザ" as Remote
}

cloud "インターネット" {
    rectangle "Webサイト" as Web
}

User --> Local : URL・マウス・キーボード
Local --> Remote : 操作情報

Remote --> Web : HTTPSリクエスト
Web --> Remote : HTML / CSS\nJavaScript / File

Remote -> Remote : HTML解析\nJavaScript実行\n危険コンテンツ処理

Remote --> Local : 描画結果

note bottom of Remote
悪意あるコードは
隔離環境で実行
end note

note bottom of Local
利用者端末には
必要な表示結果だけを転送
end note

@enduml

ここがRBI最大の違いです。

Webサイト
   ↓
ユーザーPC

ではなく、

Webサイト
   ↓
隔離ブラウザ
   ↓
表示結果
   ↓
ユーザーPC

になります。

CISAも、Remote Browser IsolationはWebデータ処理をローカル端末から安全な仮想・クラウド環境へ移す方式と説明しています。

RBIで何が起きているのか

利用者が次のURLを開いたとします。

https://example.com/

RBI環境では概ね次の処理になります。

① 利用者がURLを入力
        ↓
② RBIへアクセス要求
        ↓
③ RBI上のブラウザがexample.comへ接続
        ↓
④ HTMLを取得
        ↓
⑤ JavaScriptをRBI上で実行
        ↓
⑥ ページをRBI上でレンダリング
        ↓
⑦ 描画結果を利用者ブラウザへ転送
        ↓
⑧ マウス・キーボード操作をRBIへ返送

利用者は普通のブラウザを操作しているように見えます。

しかし、実際にWebサイトを開いているブラウザはクラウド側にあります。

RBIは「リモートデスクトップ」と同じではない

見た目は似ていますが、目的が違います。

RBIは、

OS全部をリモート化

するのではなく、

危険性の高いブラウザ実行部分だけリモート化

する設計です。

RBIはどのように画面を送っているのか

すべてのRBI製品が同じ方式ではありません。

代表的には、

Pixel Streaming

と、

描画命令を転送する方式

があります。

Pixel Streaming

リモートブラウザで描画した画面を、画像や映像のように利用者へ送ります。

Webページ
   ↓
リモートブラウザ
   ↓
レンダリング
   ↓
Pixels
   ↓
利用者ブラウザ

Zscalerの公式ドキュメントでは、リモートブラウザでページを読み込み、レンダリング結果をPixel Streamとして利用者のブラウザへ送信する方式が説明されています。

長所

• ローカルへWebコードを持ち込みにくい
• JavaScriptを端末で実行しなくてよい
• 隔離境界が分かりやすい

短所

• 帯域を使いやすい
• 動画や高速スクロールで遅延しやすい
• 高解像度表示の負荷が大きい

Network Vector Rendering

別の方法として、画像そのものではなく、

ここに文字を描く
ここに線を描く
ここに画像を配置する

という描画命令を送る方法があります。

Cloudflareはこれを**Network Vector Rendering（NVR）**と呼んでいます。

Webサイト
   ↓
Cloudflare Remote Browser
   ↓
JavaScript実行
   ↓
描画命令へ変換
   ↓
利用者ブラウザ
   ↓
画面表示

Cloudflareは、ページ全体を動画として送るのではなく、軽量な描画命令を利用者ブラウザへ送る方式を採用しています。2026年にはHTML5 Canvas向けのCanvas Remotingも追加され、2D Canvasについて描画命令をクライアント側へ転送できるようになっています。

ただし、WebGLやWebGPUなどへの対応には制限があります。これはRBIそのものの普遍的な制約ではなく、製品やレンダリング方式によって異なります。

問題・仕組み・原因

なぜRBIが必要なのか

ブラウザは非常に大きな攻撃面を持っています。

Webサイトを表示するだけでも、

HTML Parser
CSS Engine
JavaScript Engine
WebAssembly
画像Decoder
動画Codec
PDF Viewer
WebGL
WebRTC
ブラウザ拡張
Cookie
Storage
Authentication

など、多くの機能が動作します。

攻撃者から見ると、

悪意あるWebサイトを開かせる
        ↓
ブラウザ脆弱性を攻撃
        ↓
Sandbox Escape
        ↓
OSへ侵入

という経路を狙えます。

RBIは最初の、

悪意あるWebコンテンツ
        ↓
ローカルブラウザ

という接触そのものを減らします。

NISTのリファレンスアーキテクチャでも、悪意あるWebサイトをBrowser Isolationへ通すことで、マルウェアがユーザー端末や企業システムへ広がることを抑える構成が示されています。

RBIが特に有効な攻撃

Drive-by Download

ユーザーがWebサイトを閲覧しただけで、脆弱性や自動ダウンロードを利用してマルウェアが配布される攻撃です。

RBIでは、

悪意あるWebサイト
      ↓
マルウェア
      ↓
RBIコンテナ

となり、

利用者PC

まで到達させない設計ができます。

Malvertising

Malvertisingは、広告ネットワークを悪用して悪意あるサイトやスクリプトへ誘導する攻撃です。

正常なニュースサイト
       ↓
広告
       ↓
悪意ある広告
       ↓
リダイレクト
       ↓
攻撃サイト

という経路があります。

CISAはMalvertising対策の一つとしてBrowser Isolationを紹介しています。

フィッシング

メール内のリンクをクリックしても、

メール
 ↓
怪しいリンク
 ↓
RBI
 ↓
フィッシングサイト

として隔離できます。

さらにRBI製品によっては、

Keyboard入力禁止
Copy禁止
Paste禁止
Upload禁止
Download禁止

といった制御も可能です。

Cloudflare Browser Isolationでは、コピー、貼り付け、ファイルアップロード、ダウンロード、キーボード入力、印刷をポリシーで制御できます。

ただしRBIだけではフィッシングを完全に防げない

ここは非常に重要です。

ユーザーが、

偽Microsoft 365ログイン

を開いたとします。

RBIがWebページを安全に表示していても、

ユーザー
 ↓
ID入力
 ↓
Password入力
 ↓
偽サイト

を許可していれば、認証情報は攻撃者へ送られます。

つまり、

マルウェアからPCを守る

ことと、

パスワードを盗ませない

ことは別問題です。

NISTのセキュリティシナリオでも、偽ログインページによる認証情報窃取は別途MFAやアクセス制御などで防御する必要があるとされています。

したがって、

RBI
+
Phishing-resistant MFA
+
URL Filtering
+
DNS Security
+
Identity Protection

という構成が必要です。

RBIで情報漏えいを防ぐ

RBIは「外から入ってくる攻撃」だけではなく、

社内 → インターネット

の情報漏えい対策にも利用できます。

例えば、機密文書を扱うSaaSで、

コピー禁止
貼り付け禁止
印刷禁止
Download禁止
Upload禁止

と設定できます。

Cloudflareの現在のBrowser Isolationポリシーでは、リモート→ローカルのコピー、ローカル→リモートの貼り付け、ダウンロード、アップロード、キーボード入力、印刷を個別に制御できます。

ファイルをPCへ落とさず閲覧する

RBIの有効な使い方の一つです。

通常は、

Webサイト
 ↓
PDF
 ↓
Download
 ↓
PC
 ↓
PDF Reader

となります。

RBIでは、

Webサイト
 ↓
PDF
 ↓
RBI
 ↓
Remote View
 ↓
画面だけ表示

とできます。

Cloudflare Browser Isolationでは、ダウンロードを禁止しながら、ファイルをリモートブラウザ内で閲覧させるポリシーがあります。

RBIとTLSインスペクションの違い

前回解説したTLSインスペクションとは役割が違います。

TLSインスペクション

暗号化
 ↓
復号
 ↓
通信内容を検査
 ↓
再暗号化

目的は、

「通信の中を見ること」

です。

RBI

Webコンテンツ
 ↓
リモートブラウザで実行
 ↓
結果だけ転送

目的は、

「危険なコードを端末で動かさないこと」

です。

@startuml
left to right direction

rectangle "TLS Inspection" {
    rectangle "HTTPSを復号" as TLS
    rectangle "内容を検査" as Inspect
}

rectangle "Remote Browser Isolation" {
    rectangle "Remote Browser" as RBI
    rectangle "JavaScriptを遠隔実行" as JS
}

TLS --> Inspect
RBI --> JS

note bottom of Inspect
通信を見る技術
end note

note bottom of JS
実行場所を隔離する技術
end note

@enduml

両者は競合技術ではありません。

併用できます。

実際、Cloudflare Browser Isolationでは透明な隔離ブラウジングを提供するため、インターネット通信のTLS復号も行うことが公式資料に記載されています。

RBIとSWGの違い

Secure Web Gatewayは、

URL
Domain
Category
HTTP
Download
Malware

などを検査します。

安全
 ↓
Allow

危険
 ↓
Block

が基本です。

RBIを組み合わせると、

安全
 ↓
Allow

明確に危険
 ↓
Block

判断が難しい
 ↓
Isolate

という3段階にできます。

この使い方が非常に重要です。

Cloudflareでも、SWGによるHTTP/HTTPSフィルタリングとBrowser Isolationを補完関係として設計しています。

RBIとEDRの違い

EDRは、

ブラウザ
 ↓
怪しいProcess
 ↓
PowerShell
 ↓
File作成

など、端末内部の振る舞いを監視します。

RBIはその前段で、

危険コードそのものを
PCへ近づけない

設計です。

Internet
   ↓
DNS
   ↓
SWG
   ↓
RBI
   ↓
Endpoint
   ↓
EDR

という多層防御になります。

どのWebサイトをRBIへ送るべきか

すべてのWebサイトをRBIにすると安全性は高まります。

しかし、互換性、コスト、遅延の問題も増えます。

実務では、

Known Good
    ↓
通常閲覧

Unknown / Risky
    ↓
RBI

Known Malicious
    ↓
Block

という動的な分離が使いやすい構成です。

CloudflareのRBIでも、ID、セキュリティリスク、コンテンツなどを条件に動的にIsolateポリシーを適用できます。

RBIを適用しやすい対象

確認方法

RBIが正しく動いているか確認する

RBIを導入したら、「画面が開く」だけで正常と判断してはいけません。

次を確認します。

RBI経由か判断するポイント

実装方法によって異なります。

Clientless RBI

Clientless方式では、URLがRBIサービス用URLへ変更されることがあります。

例えばCloudflare Clientless Web Isolationでは、専用のprefixed URLを使用する方式があります。

Inline RBI

利用者からは通常アクセスに見える場合があります。

この場合は、

• RBI管理ログ
• Gatewayログ
• Network Sessionログ
• Policy ID
• Remote Browser Session

を確認します。

対処方法・安全な導入方法

Step 1：いきなり全Webサイトを隔離しない

まず、

Unknown
New Domain
Phishing疑い
Malware疑い
File Sharing
Webmail

などから開始します。

Step 2：BlockとIsolateを分ける

明確なマルウェアサイトを、

RBIなら安全だからAllow

とするのは適切ではありません。

Known Malicious
      ↓
BLOCK

Unknown
      ↓
ISOLATE

Known Good
      ↓
ALLOW

とします。

RBIは「危険なサイトを許可する技術」ではありません。

判断できないWebサイトを安全側へ倒す技術として使う方が適切です。

Step 3：データ方向を設計する

RBIでは、

Internet → User

だけではなく、

User → Internet

も重要です。

例えば、

Copy
Paste
Upload
Download
Print
Keyboard

を個別に決めます。

高リスクサイト例

Copy       Allow
Paste      Block
Upload     Block
Download   Remote View Only
Print      Block
Keyboard   Block

これならWebサイトは閲覧できます。

しかし、

Password入力
機密情報貼り付け
File Upload

はできません。

Step 4：SSOとMFAを検証する

RBIはWebブラウザ環境を分離するため、Cookieやセッション境界が変わります。

Cloudflareの隔離ポリシーでも、通常ブラウジングの既存Cookieやセッションがリモートブラウザへ引き継がれない場合があり、IdPを含めた隔離設計が必要になるケースが説明されています。

次をテストします。

SAML
OIDC
OAuth
WebAuthn
FIDO2
Passkey
Client Certificate
Third Party Cookie
SameSite Cookie

Step 5：WebAuthnを特に確認する

WebAuthnやハードウェアセキュリティキーは、RBI方式によって問題になることがあります。

Cloudflare Clientless Web Isolationでは、URLへprefixを付加する方式のため、YubiKeyやWebAuthnが動作しない構成があります。一方、inline deploymentでは動作可能とされています。

したがって、

RBI導入
 ↓
Passkeyが動かない

という障害を、

IdP障害

と誤認しないよう注意します。

Step 6：WebGL・動画・WebRTCをテストする

RBI製品ではレンダリング方式が異なります。

例えば2026年4月時点のCloudflare Browser Isolationでは、

• Webcam
• Microphone
• 一部WebGL
• WebGPU
• 一部動画Codec

などに制約があります。

これはRBI全体の制限ではありません。

採用製品ごとに確認します。

動作確認

本番展開前に、少なくとも次のシナリオを確認します。

正常アクセス

通常サイト
 ↓
Allow

期待結果：

表示正常
ログ正常
余計な遅延なし

Unknown Domain

Unknown
 ↓
Isolate

期待結果：

Remote Browser起動
Web表示正常

Known Malware

Known Malware
 ↓
Block

期待結果：

RBIすら起動せず遮断

Download

RBI
 ↓
File
 ↓
Download

期待結果：

設定がRemote View Onlyなら、

ローカルPCへFileが存在しない

ことを確認します。

Paste

機密情報を模したテスト文字列を利用します。

INTERNAL-CONFIDENTIAL-TEST-0001

期待結果：

Paste Block

Upload

テストファイルを使用します。

期待結果：

Upload Block

または、

許可対象サイトのみUpload可能

になっていることを確認します。

再発防止・継続運用

RBIは導入して終わりではありません。

特に確認したい指標は次です。

Isolated Sessions
Blocked Sessions
Unknown Domain
Newly Registered Domain
Download Attempts
Upload Attempts
Clipboard Blocks
Keyboard Blocks
Phishing Categories
Malware Categories
RBI Errors
Rendering Errors
Session Latency

これらをSOCで継続監視します。

RBIポリシーを動的にする

最初は安全だったWebサイトが侵害されることがあります。

逆に、新規サイトだからといって永久に隔離する必要もありません。

そのため、

Domain Reputation
Threat Intelligence
User Risk
Device Posture
URL Category
File Type
Identity

からポリシーを動的に変えます。

@startuml
start

:Webアクセス;

if (既知の悪性サイト?) then (Yes)
    :BLOCK;
    stop
else (No)
endif

if (Known Good?) then (Yes)
    :通常ブラウジング;
    stop
else (No)
endif

if (Unknown / High Risk?) then (Yes)
    :Remote Browser Isolation;
else (No)
    :通常ブラウジング;
endif

if (機密操作?) then (Yes)
    :Copy / Paste / Upload\nDownloadを制限;
endif

stop
@enduml

注意点・よくある誤解

注意点1：RBIだけでフィッシングは防げない

RBIで、

evil.js

を隔離できても、

User
 ↓
Password
 ↓
Phishing Site

を許可すれば認証情報は盗まれます。

そのため、

• Phishing-resistant MFA
• DNS Protection
• URL Filtering
• Identity Protection
• Keyboard制御

が必要です。

CISAの2025年フィッシング対策でも、RBIだけでなく、Protective DNS、フィッシングフィルタ、最小権限、アプリケーション制御など複数対策が併記されています。

注意点2：RBIを理由にEDRを削除してはいけない

RBIが守るのは主にWeb経路です。

攻撃経路には、

Email Attachment
USB
VPN
RDP
Supply Chain
SaaS
Credential Theft
Internal Attack

もあります。

RBIはEDRの代替ではありません。

注意点3：すべてRBIにすればよいとは限らない

全Web通信をRBIにすれば隔離範囲は広がります。

しかし、

• 遅延
• コスト
• Web互換性
• 動画品質
• WebGL
• WebRTC
• Passkey
• SSO
• ファイル転送

の問題も増えます。

Unknown / High Riskを中心に動的に隔離する構成の方が、実務では扱いやすい場合があります。

注意点4：RBIサービス自体が重要なセキュリティ境界になる

Web通信、入力、ファイルなどがRBIサービスを経由します。

一部のインライン型RBIではTLS復号も実施します。

Cloudflare Browser Isolationも、透明なWeb隔離を提供するためネットワーク上でTLS通信を復号することを明記しています。

そのため、

RBIなら絶対安全

ではありません。

RBI事業者の、

Security
Isolation Architecture
Data Retention
Region
Logging
Encryption
Access Control
Incident Response

も評価する必要があります。

注意点5：Browser Site IsolationとRBIは別物

ChromeなどにあるSite Isolationは、

同じ端末のブラウザ内部

でサイトごとのプロセスを分離する仕組みです。

RBIは、

ユーザー端末
     │
     │ ネットワーク
     │
Remote Browser

と実行場所そのものを遠隔化します。

同じ「Isolation」でも境界が違います。

Microsoft Defender Application Guardとの違い

Microsoft Defender Application Guardは、Windows上の仮想化技術を利用して信頼されていないWebサイトを隔離する仕組みでした。

これは典型的なクラウドRBIというより、

Local Hardware Isolation

に近い方式です。

重要なのは現在の扱いです。

MicrosoftはMicrosoft Defender Application Guardを非推奨としています。

さらに、Windows 11 Version 24H2以降ではMicrosoft Defender Application Guardは利用できません。

したがって、2026年現在、

Windows標準のApplication Guardを
これからRBI代替として新規導入する

という設計は適切ではありません。

Microsoft自身も、コンテナ型隔離が必要な場合にはWindows SandboxやAzure Virtual Desktopなどを検討するよう案内しています。

RBIに対する否定的な評価

RBIには明確な価値がありますが、過大評価も避けるべきです。

1. 「ユーザー教育が不要になる」という考えには賛成できない

マルウェア実行は隔離できても、

認証情報入力
OAuth Consent
MFA承認
情報入力

は人間の判断が残ります。

ユーザー教育を完全に廃止できる技術ではありません。

2. 全通信RBIはコストに見合わない可能性がある

Known Goodな業務SaaSまで常時隔離すると、

コスト
遅延
互換性問題
Helpdesk対応

が増える可能性があります。

リスクベースの動的隔離を先に検討すべきです。

3. RBIを導入すると新しい依存先を作る

RBIクラウドが障害を起こした場合、

Web閲覧不能
SaaS不能
認証不能

になる設計も考えられます。

RBIサービスそのものが新しい可用性・セキュリティ境界になります。

4. 「RBIだからゼロデイを100%防げる」とは言えない

攻撃対象が、

Local Browser

から、

Remote Browser
RBI Protocol
RBI Client
Identity
Session

へ移る面もあります。

リスクを消す技術ではなく、端末から隔離環境へリスクを移し、被害範囲を限定する技術と考える方が正確です。

推奨する全体構成

企業環境なら、RBI単独ではなく次の構成を推奨します。

@startuml
top to bottom direction

rectangle "User" as U
rectangle "Protective DNS" as DNS
rectangle "Secure Web Gateway" as SWG
rectangle "Remote Browser Isolation" as RBI
rectangle "DLP" as DLP
rectangle "Internet / SaaS" as NET
rectangle "EDR" as EDR
rectangle "SIEM / SOC" as SOC

U --> DNS
DNS --> SWG

SWG --> NET : Known Good
SWG --> RBI : Unknown / High Risk
SWG --> SWG : Known Malicious\nBLOCK

RBI --> DLP
DLP --> NET

U --> EDR

DNS --> SOC
SWG --> SOC
RBI --> SOC
DLP --> SOC
EDR --> SOC

@enduml

考え方は、

Known Malicious → Block

Unknown        → Isolate

Known Good     → Allow

です。

kurutann.com / Kururu Securityへ応用するなら

以下は筆者の設計案です。

KururuシリーズへRBIの考え方を組み込むなら、単純な「クラウドブラウザ」だけにせず、既存のセキュリティイベントと統合すると有効です。

KururuReputationDB
        ↓
Domain Reputation
        ↓
KururuIPS
        ↓
Risk Score
        ↓

┌─────────────────────┐
│ score < 20          │
│ ALLOW               │
├─────────────────────┤
│ score 20〜69        │
│ RBI                 │
├─────────────────────┤
│ score >= 70         │
│ BLOCK               │
└─────────────────────┘

さらに、

KururuReputationDB
+
KururuIPS
+
KururuXDR
+
KururuEDR
+
Remote Browser

を連携します。

イベント例は次です。

{
  "event_type": "rbi_session",
  "domain": "unknown-example.test",
  "reputation_score": 47,
  "policy_action": "isolate",
  "clipboard": "blocked",
  "upload": "blocked",
  "download": "remote_view_only",
  "source": "kururu-rbi",
  "malware_detected": false
}

こうすると、

「怪しいからBLOCK」

だけではなく、

「危険度は不明だが業務で必要なので隔離して閲覧」

という第三の選択肢を作れます。

まとめ

Remote Browser Isolationは、

Webコンテンツを信用せず、危険なコードを利用者PCから離れた環境で実行する技術です。

通常は、

Internet
   ↓
Browser
   ↓
Endpoint

ですが、RBIでは、

Internet
   ↓
Remote Browser
   ↓
安全な表示結果
   ↓
Endpoint

になります。

特に有効なのは、

Drive-by Download
Malvertising
Browser Exploit
Unknown Domain
Malicious JavaScript
File Download
Phishing Link

です。

しかし、

Credential Phishing
OAuth Abuse
Session Theft
Insider Threat
SaaS Misuse

までRBIだけで解決できるわけではありません。

そのため、

Protective DNS
      +
Secure Web Gateway
      +
Remote Browser Isolation
      +
DLP
      +
EDR
      +
MFA
      +
SOC

として設計します。

最も重要なのは、

Known Good
     ↓
ALLOW

Unknown / High Risk
     ↓
ISOLATE

Known Malicious
     ↓
BLOCK

という考え方です。

RBIは「危険なWebサイトも自由に開ける魔法の技術」ではありません。

「ブロックするほどの根拠はない。しかし直接端末で開かせるほど信用もできない」というWebコンテンツに対して、非常に有効な中間防御になります。

FAQ

Q1. RBIとは何の略ですか？

Remote Browser Isolationです。

日本語では「リモートブラウザ分離」と呼ばれます。

Q2. RBIを使えばウイルス対策ソフトは不要ですか？

不要にはなりません。

RBIは主にWebブラウザ経由の攻撃を隔離します。

USB、メール添付、VPN、Supply Chainなど別経路の攻撃にはEDRやアンチマルウェアが必要です。

Q3. RBIを使えばフィッシングを完全に防げますか？

完全には防げません。

ユーザーが偽サイトへ認証情報を入力できる状態なら、RBI上でも認証情報を盗まれる可能性があります。

Keyboard入力制御、DNS、URL Filtering、FIDO2などと組み合わせます。

Q4. RBIはVDIと同じですか？

違います。

VDIはデスクトップ全体を遠隔化します。

RBIは主にブラウザだけを遠隔環境へ分離します。

Q5. RBIとTLSインスペクションは同じですか？

違います。

TLSインスペクションはHTTPS通信を復号して検査する技術です。

RBIはWebコンテンツの実行場所をリモートへ移す技術です。

両方を組み合わせることもできます。

Q6. RBIはZero Trustですか？

RBIそのものがZero Trust Architecture全体ではありません。

しかし、

Webサイトを最初から信用しない

という考え方はZero Trustとの相性が良く、NISTのZero Trust関連実装でもBrowser Isolationを含む構成が検討されています。NIST SP 1800-35は2025年6月に最終版が公開されています。

Q7. RBIはWebサイトをブロックするのですか？

必ずしもブロックしません。

例えば、

Allow
Block
Isolate

のように、Isolateを第三の選択肢として利用できます。

Q8. RBIでファイルダウンロードを禁止できますか？

対応製品では可能です。

Remote Browser内でファイルを閲覧し、ローカル端末への保存だけ禁止する方式もあります。Cloudflare Browser Isolationは現在このポリシーを提供しています。

Q9. RBIでコピー＆ペーストを禁止できますか？

対応製品では可能です。

ローカル→Remote、Remote→ローカルを別々に制御できる製品もあります。

Q10. WebAuthnやPasskeyは使えますか？

製品と導入方式によります。

特にURLを書き換えるClientless方式では、WebAuthnのオリジン要件と衝突する場合があります。導入前に実際のIdPで検証してください。

Q11. Microsoft Defender Application GuardをRBIとして使えますか？

新規導入先としては推奨できません。

Microsoft Defender Application Guardは非推奨で、Windows 11 Version 24H2以降では利用できません。

参考情報

CISA：Phishing Guidance – Stopping the Attack Cycle at Phase One

RBIをフィッシング経由のマルウェア拡散を抑える対策として紹介しています。

https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf

URL：
https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf

CISA：Securing Web Browsers and Defending Against Malvertising

Browser IsolationとRemote Browser Isolationの基本構造を説明しています。

https://www.cisa.gov/sites/default/files/2023-09/Non-Fed%20-%20Guidance_for_Securing_Your_Web_Browsers%20Aug-23%20Revision.pdf

URL：
https://www.cisa.gov/sites/default/files/2023-09/Non-Fed%20-%20Guidance_for_Securing_Your_Web_Browsers%20Aug-23%20Revision.pdf

NIST SP 1800-28：Data Confidentiality

Browser IsolationによるWebマルウェア隔離とデータ保護を扱っています。

https://www.nccoe.nist.gov/publication/1800-28/VolB/index.html

URL：
https://www.nccoe.nist.gov/publication/1800-28/VolB/index.html

NIST SP 1800-35：Implementing a Zero Trust Architecture

Zero Trust Architecture実装のNIST Practice Guideです。最終版は2025年6月公開です。

https://csrc.nist.gov/pubs/sp/1800/35/final

URL：
https://csrc.nist.gov/pubs/sp/1800/35/final

Cloudflare：Remote Browser Isolation

Cloudflare Browser Isolationの基本構造、アクティブコンテンツのリモート実行、プライバシーについて説明しています。

https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/

URL：
https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/

Cloudflare：Isolation Policies

Copy、Paste、Download、Upload、Keyboard、PrintingなどのRBIポリシーを確認できます。

https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/isolation-policies/

URL：
https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/isolation-policies/

Cloudflare：Known limitations

WebRTC、WebAuthn、WebGL、ファイルサイズなど、Browser Isolationの現在の制限事項を確認できます。

https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/known-limitations/

URL：
https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/known-limitations/

Cloudflare：Canvas Remoting

Network Vector Renderingと2026年追加のCanvas Remotingについて説明しています。

https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/canvas-remoting/

URL：
https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/canvas-remoting/

Microsoft：Microsoft Edge and Microsoft Defender Application Guard

Application Guardの非推奨とWindows 11 24H2以降で利用できないことが確認できます。

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-windows-defender-application-guard

URL：
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-windows-defender-application-guard