Webアイソレーション
Webページの読み込みやスクリプトの処理を、業務端末の通常の実行環境から分離して行うセキュリティ技術である。遠隔サーバや端末内の仮想環境などに処理を移し、Web閲覧を通じた端末への攻撃や感染の影響を抑える。
イマシルちゃんの解説
Webサイトを開くと、ブラウザはJavaScriptなどのプログラムも動かすんだ。
攻撃用のコードが含まれていると、端末の弱点を突かれるおそれがあるよ。
Webアイソレーションは、Webページを処理する場所を仕事用の環境から分けて守る技術なんだ。
例えば別のサーバでページを開き、手元には画面の画像や表示に必要な情報を送るの。
クリックや文字入力はそちらへ伝えるから、利用者は手元のブラウザで操作できるよ。
危険なコードを業務端末で直接動かさないようにして、閲覧による感染の危険を減らすんだね。
この解説はわかりやすかったですか?
より深い解説
閲覧すること自体が攻撃の入口になる
Webページには文章や画像だけでなく、動作を実現するJavaScriptなどのコードも含まれる。ブラウザはそれらを読み込み、解釈して実行する。ブラウザや画像・文書の処理に脆弱性があると、ページを開いただけで攻撃が成立する場合もある。
URLフィルタリングやマルウェア検査は危険な通信を見つけて止める対策である。しかし、まだ危険と判定されていないサイトや改ざんされた正規サイトを見逃す可能性がある。Webアイソレーションは、閲覧を許可するときにもコードを処理する場所を業務環境から切り離し、検知だけに依存する範囲を減らす。
例えばCloudflareの技術説明では、Webの動的な内容を隔離したブラウザで動かす方式を、通信の検査やアクセス制御と組み合わせている。隔離の仕組み自体にも更新や適切な設定が必要であり、すべての攻撃を無条件に防ぐという意味ではない。
処理をどこへ移すのか
大きく分けると、端末の外に処理を移す方法と、端末の内部に別の領域を作る方法がある。遠隔側のブラウザを使う方式をRBI(Remote Browser Isolation)と呼ぶ。クラウドサービスだけでなく、自組織が管理するサーバに設置する構成もある。
| 方式 | Webページを処理する場所 | 設計で確認すること |
|---|---|---|
| 遠隔のサーバを使う | クラウドや組織内の隔離したサーバ | 通信の遅れ、同時利用数、遠隔側から到達できる宛先 |
| 端末内の別領域を使う | 端末上の仮想マシンやサンドボックスなど | 端末の性能、隔離機能の強さ、業務領域とのデータ交換 |
後者では、危険な内容も端末という同じ物理装置の中で扱う。仮想化などで境界を設けることが重要であり、ブラウザを別のウィンドウで開くだけでは同じ効果にならない。方式の違いはCloudflareの概説でも整理されている。
遠隔側のブラウザで閲覧する流れ
一般的な遠隔処理の流れは次のようになる。ここでは組織のゲートウェイで利用者と接続先を判定する構成を例にする。
- 利用者が手元のブラウザからWebサイトへ接続しようとする。
- ゲートウェイが適用するポリシーを選び、隔離して閲覧する通信を遠隔側へ案内する。
- 遠隔側のブラウザが対象サイトからHTMLなどを取得し、スクリプトやページの描画を処理する。
- 手元の端末には画面の画像や描画命令など、採用する方式に応じた表示用の情報を送る。
- 利用者のクリックやキー入力を遠隔側へ送り、処理した結果を再び表示する。
このとき、対象サイトと通信する主体が遠隔側へ移る。サイトから見える送信元IPアドレスや、端末に保存していたCookieの扱いが通常の閲覧と変わる場合がある。IPアドレスによるアクセス制限やログイン状態を使う業務では、この違いを導入前に確認する。
端末側でも表示や操作を仲介するプログラムは動く。「端末ではJavaScriptが一切動かない」という意味ではなく、対象サイトの危険なコードをどこで処理し、何を端末へ渡すかが要点である。
端末へ返す情報にも方式の違いがある
遠隔側で処理する製品でも、手元へ戻す内容が同じとは限らない。表示の再現性や通信量だけでなく、端末側にどの処理を残すかで比べる。
| 代表的な方式 | 端末へ送る内容 | 主な確認点 |
|---|---|---|
| 画面転送 | 描画済みの画像や動画 | 画面の変化が多いときの通信量や応答の遅れ |
| DOMの再構成 | ページ構造を解析し、危険な内容を除去・変換したHTMLなど | 再構成の正確さ、端末で再び処理するコードの範囲 |
| 描画命令の転送 | 画面を描くための命令 | 描画機能への対応状況、文字や動画の表示 |
ページ構造を表すDocument Object Modelを使う方式では、変換後の内容を端末が処理する。単に「遠隔で開いたから元のコードは一切届かない」と考えてはならない。一方、CloudflareのNVR(Network Vector Rendering)は描画命令を送る方式であり、動画を配信する方式とは異なる。同社の互換性資料には、この方式でも利用できない機能があることが示されている。
ファイルや文字の受渡しを制御する
Webページを隔離しても、利用者が取得したファイルを業務端末へ保存して開けば、新たな入口になる。画面の閲覧と、ファイルや文字列を境界の外へ渡す操作は分けて考える。
| 操作 | データが移る方向 | 制御の例 |
|---|---|---|
| ダウンロード | 遠隔側から業務端末へ | 保存を禁止し、遠隔側での閲覧だけを許可する |
| アップロード | 業務端末から外部サイトへ | 業務で必要な宛先と利用者だけに許可する |
| コピーと貼付け | クリップボードを通じて双方向へ | それぞれの方向で許可・禁止を決める |
| 印刷 | 遠隔側の内容を紙やファイルへ | 機密情報を扱う用途では制限する |
| キー入力 | 業務端末から遠隔側のページへ | 危険度の高いサイトでは入力を禁止する |
これらはCloudflareの操作制御やPalo Alto Networksの構成説明でも、閲覧の隔離とあわせて設定する項目である。実際に利用できる制御は製品や接続方法で異なる。
業務でファイルの持込みが必要なら、検査や無害化の経路を用意する。CDR(Content Disarm and Reconstruction)は、文書の構造を解析して危険な要素などを取り除き、利用できる形へ再構成する技術である。例えばPalo Alto Networksの連携機能では、ダウンロード時にこの処理を組み込める。ただし、対応形式や残る機能を確認する必要があり、どんなファイルでも完全に安全になるとはいえない。
感染対策と情報流出対策を分けて考える
遠隔側で動く偽のログイン画面へ利用者がパスワードを入力すると、その情報は偽サイトへ届き得る。コードの処理場所を移すだけでは、だまされた利用者の操作まで防げない。
そのため、危険なサイトを閲覧専用にして文字入力を止める方法や、URLの判定、フィッシングに強い認証などを組み合わせる。外部サイトへの機密情報の送信には、送る内容を確認するDLP(Data Loss Prevention)との連携も検討する。操作を許可することと、その操作で送られる情報が適切であることは別の判断である。
Webアイソレーションを、ほかの対策と比較すると役割が分かりやすい。
| 対策 | 中心となる役割 | Webアイソレーションとの関係 |
|---|---|---|
| セキュアWebゲートウェイ | 接続先や通信内容に基づいてWeb利用を制御する | 隔離の対象を決める入口になり得る |
| マルウェア解析用サンドボックス | 疑わしいファイルなどを動かし、挙動を調べる | 判定が目的であり、利用者の継続的な閲覧とは用途が異なる |
| VDI | デスクトップ環境を遠隔側で実行する | 対象がWeb閲覧だけでなくOSや業務アプリケーション全体になる |
| ネットワークの分割 | 異なるネットワーク間の到達性を制限する | 許可したWebページの処理場所まで自動で変えるわけではない |
導入時に例外と接続経路を確認する
隔離の対象は、全Webサイトにする方法と、利用者・URL分類・危険度などに応じて選ぶ方法がある。対象を狭くすれば互換性や負荷を調整しやすいが、例外にしたサイトが侵害された場合は通常の閲覧経路に危険が残る。
また、別のブラウザや外部回線から対象サイトへ直接接続できると、必要な隔離を迂回できてしまう。端末の通信設定、ゲートウェイの経路、許可する外向き通信を組み合わせて設計する。業務用のブラウザ以外から行うAPI通信まで、そのまま同じ方式で保護されるとは限らない。
HTTPSを途中で検査する構成では、端末が管理用の認証局を信頼する設定が必要になる場合もある。クラウド側で閲覧内容を扱うなら、処理される場所、ログに残す情報、管理者の閲覧権限も確認する。隔離する機能とサービス提供者を信頼する範囲は別々に決める。
ログインを一度で済ませるシングルサインオンを使うサイトでは、対象サービスだけでなく認証先への遷移も試す。端末と遠隔側ではCookieやセッションの保存先が異なるため、認証先を含めたポリシーの整合が必要になる。セッション終了時に消す情報と、次回の利用へ引き継ぐ情報も確認する。
業務への影響と障害を切り分ける
遠隔処理では利用者の操作と結果の表示がネットワークを往復する。動画、画面の頻繁な更新、Web会議などでは遅延や通信量が利用感に影響する。手元のカメラ、マイク、USB機器などを使う機能は、製品ごとの対応状況を調べる。
| 症状 | 確認する点 |
|---|---|
| 特定の操作だけできない | 操作制限、使用するブラウザ機能、対応するファイル形式 |
| ログインを繰り返す | 認証先の扱い、Cookieやセッション、送信元IPアドレスの条件 |
| 画面だけ遅い | 利用者から隔離環境までの往復時間、帯域、同時利用数 |
| 外部サイト全体を開けない | ゲートウェイへの到達性、隔離サービスの稼働、名前解決 |
サービス停止時の扱いも決める。隔離できなければ接続を止めるフェイルクローズでは保護方針を維持できる一方、業務も止まり得る。直接接続へ切り替える運用では可用性を保てても隔離が外れる。代替経路や例外操作の権限と記録を、平常時から用意する。
設計問題での考え方
例えば「外部サイトを調査する業務を続けながら、Web閲覧による業務端末の感染を抑えたい」という条件なら、危険な処理を端末から遠ざける構成を検討できる。さらに「資料を社内へ持ち込む必要がある」という条件が付けば、閲覧経路だけでなくファイルの検査・無害化・受渡しも設計する。
「隔離しているからパスワードを入力しても安全」という判断はできない。何をどこで実行するか、境界を越えて何を許可するか、使えないときにどうするかを順に説明すると、対策の効果と残る危険を分けて答えられる。