はじめに
怪しいURLをクリックしないでください。
セキュリティ教育ではよく言われますが、現場ではそれだけで守り切れません。取引先から届いたURL、SaaSのログイン画面、調査で開く海外サイト、採用候補者のポートフォリオ、問い合わせフォームに貼られたリンク。業務上、開かざるを得ないWebサイトはあります。
そこで出てくる考え方が、RBI、つまりRemote Browser Isolationです。
RBIは、ものすごく雑に言えば「危ないかもしれないWebサイトを、利用者のPCではなく、遠隔の隔離環境で開く」仕組みです。CISAも、フィッシング対策の文脈でRBIを、ユーザー実行時にマルウェアサンプルを隔離する対策として挙げています1。
本稿では、RBIを次の観点で整理します。
- RBIとは何か
- 仮想コンテナ上でマルウェアが実行された場合、何が起きるのか
- SWG、VDI、サンドボックス、EDRとは何が違うのか
- 導入時にどのポリシーを見るべきか
1. RBIは「ブラウザを守る技術」ではなく「実行場所を変える技術」です
RBIを理解するうえで重要なのは、ブラウザそのものを強くする技術ではなく、Webコンテンツの実行場所を変える技術だという点です。
通常のWeb閲覧では、HTML、CSS、JavaScript、画像、PDF、ダウンロードファイルなどがユーザー端末のブラウザに届き、端末上で処理されます。ブラウザにはサンドボックス機構がありますが、ゼロデイ脆弱性や悪意あるスクリプト、フィッシング、悪性広告、ファイルダウンロードなど、攻撃面は広く残ります。
RBIでは、この流れを変えます。
通常のWeb閲覧
[ユーザー端末のブラウザ]
│
│ HTML / JavaScript / ファイル
▼
[インターネット上のWebサイト]
RBI利用時
[ユーザー端末のブラウザ]
│
│ 画面表示・操作結果
▼
[RBIの隔離ブラウザ / 仮想コンテナ]
│
│ HTML / JavaScript / ファイル
▼
[インターネット上のWebサイト]
Cloudflareの公式ドキュメントでは、RBIはSWGやZTNAを補完するものとして、JavaScriptやプラグインなどのアクティブコンテンツを安全な隔離ブラウザで実行すると説明されています2。Palo Alto Networksのドキュメントでも、RBIはユーザーのローカルブラウザ上でWebサイトのコードやファイルを実行させない隔離環境を作るものと説明されています3。
ここでのポイントは、「安全か危険かを完全に判定する」のではなく、「危険かもしれないものを端末で実行しない」ことです。
つまり、RBIの思想は次のように整理できます。
| 観点 | 従来の発想 | RBIの発想 |
|---|---|---|
| Webサイト | 危険なものを検知して止める | そもそも端末で直接実行しない |
| マルウェア | 侵入前後に検知する | 実行場所を隔離する |
| ブラウザ脆弱性 | パッチとEDRで守る | 悪用されても影響範囲を隔離環境に閉じ込める |
| ユーザー操作 | クリックを抑止する | クリックしても端末に届く経路を制御する |
「検知」ではなく「隔離」に重心を置く。ここがRBIの本質です。
2. 仮想コンテナ上で感染したマルウェアはどうなるのか
では、RBI環境で悪性サイトを開き、仮想コンテナ上のブラウザがマルウェアに攻撃された場合、何が起きるのでしょうか。
結論から言うと、理想的には「感染するのはユーザー端末ではなく、隔離された一時的なブラウザ環境」です。
2.1 マルウェアは隔離環境側で実行される
RBIでは、Webページのコードやアクティブコンテンツは遠隔の隔離ブラウザで処理されます。ユーザー端末に届くのは、レンダリング結果、画面情報、操作結果などです。
そのため、悪性JavaScript、ブラウザ脆弱性を狙うExploit、悪意ある広告、偽装ページ上のスクリプトなどは、ユーザー端末ではなくRBI側の環境で処理されます。
悪性サイトにアクセスした場合
[ユーザー端末]
- 悪性JavaScriptを直接実行しない
- 表示結果と操作だけを受け取る
[RBI隔離環境]
- Webコードを実行
- 攻撃コードもここで処理
- セッション終了後に破棄される設計が多い
Cloudflareのドキュメントでは、隔離ブラウザを閉じるとセッションが自動削除されると説明されています2。ただし、これは実装依存です。すべてのRBI製品が同じ保持期間、同じ破棄方式、同じログ設計を採用しているわけではありません。
2.2 「感染しても安全」ではなく「感染経路を限定する」が正確です
ここは誤解しやすいところです。
RBIを入れたからといって、あらゆるリスクが消えるわけではありません。より正確には、マルウェアが端末へ到達する経路を限定し、実行環境を使い捨てに近づける技術です。
特に注意すべき経路は次のとおりです。
| 経路 | リスク | RBI側で見るべき制御 |
|---|---|---|
| ファイルダウンロード | 悪性ファイルを端末で開くと感染し得る | ダウンロード禁止、無害化、サンドボックス連携、AVスキャン |
| クリップボード | 機密情報のコピー、悪性コマンド貼り付け | コピー・ペースト制御 |
| アップロード | 社内ファイルの外部流出 | アップロード禁止、DLP連携 |
| 印刷 | 紙・PDF経由の情報持ち出し | 印刷禁止、透かし |
| キーボード入力 | 認証情報の入力、フィッシング | 危険サイトでの入力禁止 |
| Cookie / セッション | セッション乗っ取り、認証情報悪用 | セッション分離、短時間化、IdP側制御 |
RBIでWebコードを隔離できても、利用者が悪性ファイルを端末にダウンロードして開けば、端末側の問題になります。つまり、RBIの効果は「ファイル・入力・出力の制御」とセットで考える必要があります。
Palo Alto NetworksのRBIドキュメントでも、コピー＆ペースト、キーボード入力、アップロード、ダウンロード、印刷などのユーザー操作をIsolation Profileで制御できると説明されています3。これは、RBIが単なるリモート表示ではなく、データ移動の制御点でもあることを示しています。
2.3 コンテナ内感染後のライフサイクル
RBI環境内でマルウェアが動いた場合のライフサイクルは、概念的には次のようになります。
1. ユーザーが危険なWebサイトにアクセス
↓
2. WebコードはRBI側の隔離ブラウザで実行
↓
3. 攻撃コードがブラウザ脆弱性を突く
↓
4. 影響はRBI側の一時セッションに閉じ込める
↓
5. セッション終了、タイムアウト、管理者操作で破棄
↓
6. ログ、ファイル、IOCを調査に利用
ここで重要なのは、RBIを「攻撃が絶対成功しない仕組み」と見ないことです。むしろ、「攻撃される前提で、どこまで影響範囲を狭められるか」という設計です。
この考え方は、ゼロトラストやセキュリティバイデザインに近いです。
3. SWG、VDI、サンドボックス、EDRとの違い
RBIは、SWG、VDI、サンドボックス、EDRと混同されがちです。どれもWebや端末を守る文脈で出てきますが、守っている場所と考え方が違います。
3.1 SWGとの違い
SWG、Secure Web Gatewayは、ユーザーとインターネットの間に入り、Webアクセスを検査・制御する仕組みです。Cloudflareのドキュメントでは、SWGの中核機能としてURL・ドメインフィルタリング、マルウェアスキャン、アプリケーション制御、DLP、HTTPSトラフィック検査などが挙げられています4。
SWGは、アクセス先や通信内容を見て、危険なものをブロックします。
一方、RBIは、許可したWebサイトであっても、その中のコードを端末で直接実行させないことに価値があります。
SWG:
危険な通信を検査して止める
RBI:
危険かもしれないWebコードを端末で実行しない
SWGは「門番」、RBIは「隔離部屋」と考えると分かりやすいです。
3.2 VDIとの違い
VDI、Virtual Desktop Infrastructureは、デスクトップ環境そのものを遠隔の仮想基盤上で提供する仕組みです。NIST SP 800-46 Rev.2では、VDIを、標準化されたOSとデスクトップの仮想イメージにユーザーが接続する方式として説明しています5。Microsoft Azure Virtual Desktopも、Azure上で動作するデスクトップおよびアプリケーション仮想化サービスとして説明されています6。
VDIは、ブラウザだけでなく、業務アプリ、Office、ファイル操作、社内システムなど、作業環境全体をリモート化します。
一方、RBIは基本的にブラウザ閲覧に特化します。
| 比較 | RBI | VDI |
|---|---|---|
| 主対象 | Webブラウザ | デスクトップ全体 |
| 実行場所 | 隔離ブラウザ環境 | 仮想デスクトップ環境 |
| 主目的 | Web由来脅威の隔離 | リモートワーク、端末非依存、データ集中管理 |
| 導入負荷 | 比較的軽いことが多い | 設計・運用が重くなりやすい |
| 影響範囲 | Webアクセス中心 | 業務環境全体 |
| 注意点 | ダウンロード・入力制御が重要 | 内部ネットワークへの到達範囲が重要 |
VDIでもブラウザを遠隔実行できます。しかし、VDIは「業務端末をクラウドやデータセンターに置く」発想です。RBIは「危険なWeb実行だけを切り離す」発想です。
また、VDI上のブラウザが感染した場合、そのVDIが内部ネットワークへ広いアクセス権を持っていると、VDI環境内で横展開されるリスクがあります。非永続VDIであればセッション破棄で回復しやすいですが、永続VDIでは感染状態や設定変更が残る可能性もあります。
つまり、VDIはRBIの上位互換ではありません。目的が違います。
3.3 サンドボックスとの違い
サンドボックスは、疑わしいファイルやURLを解析環境で実行し、悪性かどうかを判定する仕組みです。
RBIと似ていますが、利用者体験が違います。
| 比較 | RBI | サンドボックス |
|---|---|---|
| 対象 | ユーザーの実際のWeb閲覧 | 疑わしいファイル・URLの解析 |
| タイミング | 閲覧中に隔離 | 事前・事後解析が多い |
| 目的 | 端末への到達を防ぐ | 悪性判定・IOC抽出 |
| ユーザー体験 | 隔離されたままWeb操作 | 解析完了まで待つ場合がある |
サンドボックスは「これは危険か」を調べる技術です。RBIは「危険かどうかに関係なく、端末で実行させない」技術です。
3.4 EDRとの違い
EDRは、Endpoint Detection and Responseの略で、端末上の挙動を監視し、侵害の兆候を検知・調査・対応する仕組みです。
EDRは端末上で起きたことを見ます。RBIは、端末上で起きる前に実行場所を遠ざけます。
EDR:
端末で起きた異常を検知・対応する
RBI:
Web由来の危険な実行を端末に持ち込まない
したがって、RBIを入れたからEDRが不要になるわけではありません。RBIはWeb経由の攻撃面を狭めますが、USB、メール添付、社内横展開、正規ツール悪用、認証情報悪用などはEDRやID保護、ログ監視の領域です。
4. RBI導入で見るべき設計ポイント
RBIは入れれば終わりではありません。むしろ、どのアクセスを隔離し、何を許可し、何を禁止するかが重要です。
4.1 全隔離か、選択隔離か
RBIの適用方式は、大きく分けると次の2つです。
| 方式 | 内容 | 向いているケース |
|---|---|---|
| 全隔離 | すべてのWeb閲覧をRBI経由にする | 高リスク業務、BYOD、特権ユーザー |
| 選択隔離 | 条件に合うWebだけRBI経由にする | 一般企業、既存SWGとの併用 |
現実的には、選択隔離から始めるケースが多いと思います。
例えば、次のような条件です。
- 未分類URL
- 新規作成ドメイン
- Webメール
- ファイル共有サイト
- 個人向けクラウドストレージ
- 採用・問い合わせ経由の外部リンク
- 海外の未知サイト
- 管理外端末からのアクセス
- 高権限ユーザーのインターネット閲覧
全隔離は強力ですが、コスト、遅延、互換性、ユーザー体験の影響が大きくなります。最初から全社一律にかけるより、リスクベースで対象を絞る方が失敗しにくいです。
4.2 ファイルダウンロードをどう扱うか
RBI導入時に最も重要なのは、ファイルダウンロードの扱いです。
Webコードを隔離しても、ファイルをローカル端末へ落として開けば、そこで感染する可能性があります。
設計パターンとしては、次のようなものがあります。
| 方針 | 内容 | 備考 |
|---|---|---|
| ダウンロード禁止 | 端末への保存を禁止 | 高セキュリティだが業務影響が大きい |
| スキャン後許可 | AV・サンドボックス検査後に許可 | 検査回避型には注意 |
| 無害化後許可 | CDRでマクロやアクティブ要素を除去 | 文書業務に向く |
| 管理領域のみ保存 | 端末ではなくVDIやクラウドストレージへ保存 | DLPと相性が良い |
| 拡張子別制御 | exe、js、iso、zipなどを制御 | 実務上は必須に近い |
RBIは、ダウンロード制御とセットで初めて効果が出ます。
4.3 クリップボード、印刷、アップロードを制御する
RBIは、閲覧の隔離だけではなく、データの出入り口を制御するためにも使えます。
特に、機密情報を扱うSaaSや社内ポータルでは、次の制御が重要です。
- コピー禁止
- ペースト禁止
- スクリーンショット抑止
- 印刷禁止
- ファイルアップロード禁止
- ファイルダウンロード禁止
- 危険サイトでのキーボード入力禁止
ここはDLPと重なります。
RBIは「外から入ってくる脅威」を隔離するだけでなく、「中から出ていく情報」を制御するポイントにもなります。
4.4 TLS復号とプライバシーを明示する
RBIやSWGを本格的に使う場合、HTTPS通信の復号が関係します。CloudflareのRBIドキュメントでも、透過的な隔離閲覧とWeb脅威ブロックのために、CloudflareのルートCAを使ってインターネットトラフィックを復号する旨が説明されています2。
これは技術的には自然ですが、運用上は非常に重要です。
- どの通信を復号するのか
- 金融、医療、個人メールなどを除外するのか
- ログにURL、入力内容、ファイル名が残るのか
- 画面記録やセッション記録を行うのか
- 従業員へどう説明するのか
- 個人情報保護、労務、監査の観点で問題ないか
RBIはセキュリティ製品ですが、同時に「ユーザーのWeb閲覧を中継・可視化する製品」でもあります。ここを曖昧にすると、導入後に揉めます。
5. RBIを過信しないための再検証
RBIは強力ですが、万能ではありません。
導入前に、次の観点で再検証しておくべきです。
| リスク | 内容 | 対策 |
|---|---|---|
| 互換性 | WebRTC、WebUSB、リッチメディア、特殊SaaSが動かない場合がある | PoCで業務サイトを検証 |
| 遅延 | 画面転送や遠隔実行により体感遅延が出る | 対象サイトを絞る |
| ダウンロード経路 | ファイルを許可すると端末感染リスクが残る | CDR、サンドボックス、拡張子制御 |
| 認証情報 | フィッシングサイトに入力すれば資格情報リスクは残る | 入力禁止、FIDO2、条件付きアクセス |
| ベンダー集中 | Web閲覧がRBI事業者に集約される | 契約、監査、ログ保持、障害時設計 |
| ログ・プライバシー | 復号や閲覧ログが発生する | 利用規程、除外カテゴリ、監査設計 |
| 内部脅威 | 正規ユーザーによる持ち出しは残る | DLP、UEBA、CASB、権限管理 |
| 非Web経路 | USB、メール添付、共有フォルダ経由は守れない | EDR、メールセキュリティ、端末制御 |
特に大事なのは、RBIを「EDRやSWGの代わり」と見ないことです。
RBIは、Webコードの実行場所を変える技術です。SWGは通信を検査します。EDRは端末を監視します。VDIは作業環境全体を遠隔化します。DLPは情報の持ち出しを制御します。
それぞれの守備範囲が違います。
Webアクセス制御:
SWG
Web実行の隔離:
RBI
端末上の検知・対応:
EDR
作業環境全体の仮想化:
VDI
情報持ち出し制御:
DLP
RBIは、この中で「未知のWebコードを端末で実行しない」という明確な役割を持ちます。
おわりに
RBIの価値は、「危険なサイトを見分ける」ことではありません。
むしろ、「危険かどうか分からないWebサイトを、なぜ端末で直接実行しているのか」という問いを投げかける技術です。
これまでのセキュリティは、URLフィルタリング、アンチウイルス、EDR、サンドボックスのように、危険なものを見つけて止める方向で発展してきました。もちろん、それは今でも重要です。
ただし、Webブラウザが業務の入口になり、SaaS、クラウド、生成AI、外部コラボレーションが当たり前になるほど、「すべてを正確に判定してから開く」ことは難しくなります。
そこでRBIは、発想を変えます。
危険かどうかを完全に見抜く
ではなく、
危険かもしれないものを端末で実行しない
特に、次のような組織では検討価値があります。
- BYODや委託先端末から業務SaaSへアクセスする
- 採用、広報、営業、調査部門などが未知のURLを多く開く
- 金融、医療、公共など、Web経由の侵害影響が大きい
- VDIを全社展開するほどではないが、Web閲覧リスクを下げたい
- SWGやEDRだけではゼロデイや未知サイトに不安がある
次にやるべきことは、いきなり全社導入することではありません。
まずは、未分類URL、Webメール、ファイル共有、管理外端末、高権限ユーザーなど、リスクの高い経路を洗い出し、RBIをどこに当てると効果が出るかをPoCで確認することです。
RBIは、単なる「リモートブラウザ」ではありません。
ブラウザという最大級の攻撃面を、端末から一段遠ざけるための設計パターンです。
参考
-
CISA, Phishing Guidance: Stopping the Attack Cycle at Phase One — フィッシング対策におけるRBIの位置付けと、ユーザー実行時のマルウェア隔離に関する根拠。 ↩
-
Cloudflare One Docs, Remote browser isolation — RBIがSWG/ZTNAを補完し、アクティブコンテンツを隔離ブラウザで実行すること、セッション削除、TLS復号に関する根拠。 ↩ ↩2 ↩3
-
Palo Alto Networks Docs, Remote Browser Isolation — ローカルブラウザでWebコードやファイルを実行しないこと、コピー＆ペースト、キーボード入力、アップロード、ダウンロード、印刷制御に関する根拠。 ↩ ↩2
-
Cloudflare One Docs, Traffic policies — SWGの基本機能であるURLフィルタリング、マルウェアスキャン、アプリケーション制御、DLP、HTTPS検査に関する根拠。 ↩
-
NIST SP 800-46 Rev.2, Guide to Enterprise Telework, Remote Access, and BYOD Security — VDIの説明、セッション終了後の仮想イメージ破棄、BYOD保護の文脈に関する根拠。 ↩
-
Microsoft Learn, What is Azure Virtual Desktop? — Azure Virtual Desktopがデスクトップおよびアプリケーション仮想化サービスであることの根拠。 ↩