- ライター：根本 幸訓
- イノベーション推進部で新しい技術領域のビジネス開発（GX、ロボティクス）を担当。
2011年、ネットワン新卒入社。事業部SE（文教市場、自治体）、応用技術部（サービス開発）を経て、現在に至る。
ネットワーク、セキュリティ、サーバ、ストレージ、仮想デスクトップなどの幅広い技術知識と、提案、設計、構築、サービス開発、ビジネス開発などの幅広い業務経験。この2つの幅広さを生かして記事をお届けします。
目次
前回までのシリーズでは、Web分離やテレワークの全体像を解説しました。
（記事下部の「関連ページ」に前回のシリーズ全3回分のリンクを張っています。）
今回からのシリーズは、前回ご紹介した方式のなかでも
特に注目度の高い「仮想ブラウザ方式」について、
同じ方式の製品間で違いが出てくる部分を記載していきます。
私が評価検証する際に注目している項目の一部となりますが、
読者のみなさまが製品を選定する際のお役に立てればと思います。
機能面の選定ポイント
レンダリングエンジン
多くの仮想ブラウザ製品が、LinuxOSのDockerという
仮想コンテナ技術を用いて実装されています。
Linux上で仮想的にブラウザを動かす仕組みなので、
仮想ブラウザのベースとなるブラウザは、
必然的にLinuxがサポートするものに限られてきます。
要するにInternet Explorerは動作しないため、
日本でよくあるIEしかサポートしていないWebアプリケーションなどは、
仮想ブラウザでは正常に動作しない恐れがあります。
また、仮想ブラウザのベースブラウザは、
おおよそFireFoxベースとChromiumベースの2つのタイプに大別されます。
例えば、FireFoxで閲覧できないページは、
FireFoxベースの仮想ブラウザでも閲覧できない可能性があります。
したがって、仮想ブラウザ製品が、
どのブラウザをベースにしているか、
という点が、重要なポイントとなります。
なお、Chromiumベースの仮想ブラウザの製品の中には、
ChromeのIEモードに対応させようとしている製品も登場してきています。
画面転送型かWeb無害化型か
仮想ブラウザ製品は、仕組み（あるいはコンセプト）の観点から、
画面転送型とWeb無害化型という2つのタイプに分類できます。
それぞれのタイプの説明の前にポイントを書いてしまいますが、
Web無害化型はページが崩れる、
正常にページが表示されない、といった可能性があります。
また、以前の記事で書いたように、画面を転送するわけではないため、
特定通信として解釈できるかどうか、という論点もあります。
その一方で、
画面転送型はネットワークの消費帯域量が多い特徴があります。
画面転送の通信は、いわば動画のような特徴を持つ通信となるため、
生のHTMLデータの転送より帯域を多く消費する傾向があります。
（コンテンツの内容にも依ります）
それでは、画面転送型とWeb無害化型、それぞれの仕組みを説明していきます。
▼画面転送型のアーキテクチャイメージ
画面転送型は、下図の通り、
サーバ基盤上（の仮想コンテナ上）でブラウザを稼働させます。
この仮想ブラウザがWebページにアクセスして
ページを表示させます（レンダリング処理）。
そして、レンダリングされた「画面」を手元の端末に転送し、
ユーザは転送された画面を操作する形でブラウジングを行います。
▼Web無害化型のアーキテクチャイメージ
Web無害化型は、
以下の2つの機能を組み合わせた仕組みとなります。
・Webプロキシ機能
・Web無害化エンジン機能
まずWebプロキシとして、
サーバがユーザの代わりにWebページにアクセスします。
サーバは、Webページから受信したHTMLデータを
Web無害化エンジンで処理して無害化します。
Web無害化エンジンは、受け取ったWebページを一度分解し、
動的なコンテンツなど、悪意ある攻撃に利用されやすい部分を
削除（無害化処理）します。
Webページの無害化処理が完了すると、
Webページのデータを再構成して、手元の端末に転送します。
手元端末は、無害化エンジンから送られてきた、
無害化されたHTMLデータを手元のブラウザで受信して
レンダリング処理を実行する、という形でWebを閲覧します。
クライアント型かクライアントレス型か
仮想ブラウザ製品は、画面転送を受信する方法の切り口で、
以下の2つのタイプに分類できます。
・クライアントレス型：一般的なブラウザで転送画面を受信する型
・クライアント型：手元端末にクライアントソフトをインストールする型
クライアントレス型は普段利用しているChromeなどのブラウザ上に、
遠隔で稼働している仮想ブラウザの画面を転送するタイプなので、
展開時の主な作業内容としては証明書の配布とプロキシの指定（PAC配布など）となります。
その一方で、クライアント型の場合は、
利用するユーザの端末にクライアントソフトを配布して
インストールする必要があるため、
展開作業のために、それなりの工数を見込む必要があります。
ファイル無害化エンジン
仮想ブラウザ製品の多くが、
ファイル無害化エンジンとAPI連携させることで、
Webページからダウンロードしたファイルを
シームレスに無害化して利用することができます。
したがって、
どのファイル無害化エンジンと連携できるか、
という点が非常に重要なポイントとなります。
というのも、一般的にファイル無害化エンジンは、
・無害化後のファイルが破損する
・無害化処理数が増えると処理が停止する
といったクリティカルなトラブルが発生する可能性があるからです。
4年ほど前の国内では、とある無害化製品が一強の状況でしたが、
現在はOPSWATという優れた後発製品が開発されています。
なので、私が仮想ブラウザ製品を評価する際は、
OPSWATと連携できるかどうかを重要視して選定しています。
また、ファイル無害化エンジンのメーカは海外にあることが多いため、
仮想ブラウザ製品も海外製のほうが、
実装までのスピード感など、メーカ間の連携が活発な印象です。
運用フェーズにおいても、不具合発生時の製品間の切り分けや、
不具合改修などの局面で、メーカ同士のパートナーシップの強さが、
対応内容やスピードに影響してきます。
・製品が日本製か、海外製か
・ファイル無害化エンジンメーカとのパートナーシップの強さ
この２点も、重要なポイントとなると考えています。
URLフィルタリングのカテゴリ
多くの仮想ブラウザ製品はURLカテゴリ単位で
アクセスポリシーを設定することができます。
ここで気を付けないといけないポイントは、
海外製の製品の場合は、
URLのカテゴライズが海外の分類方法となるため、
日本のWebページが意図していないカテゴリとして
扱われてしまう可能性がある、ということです。
したがって、
URLごとにポリシーを設定したい場合は、
URLのカテゴライズが国内に準拠しているかどうか、
が選定のポイントになってきます。
おわりに
今回は「仮想ブラウザ方式」の機能面での製品間の違いを説明しました。
次回は「仮想ブラウザ方式」の性能面に着目して選定ポイントをご説明したいと思います。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
