安全性の画面転送か、利便性の無害化か…。

もう悩まない新Web分離
株式会社アシスト仮想化事業推進室

Copyright © 2019 K.K. Ashisuto1

セッションの目的
 Web分離製品の「画面転送」、「サニタイズ」の仕組みと違いをスッキリ理解いただく。
 仕組みを理解した上で、画面転送とサニタイズのどちらが良いのか結論を出す！
Discramer:本セッションでご紹介するクリスタルレンダリングは、正式リリース前の機能です。来年初頭にリリース予定ですが、リリース時期の変更や、機能・仕様の変更が行われる可能性があります。

Copyright © 2019 K.K. Ashisuto2

構成 インターネット分離ソリューションが生まれた経緯
 いろいろあるWeb分離ソリューション

 Ericom Shieldの画面転送の仕組み
 Ericom Shieldのサニタイズの仕組み

 多面的に比較
 結論

Copyright © 2019 K.K. Ashisuto3

株式会社アシスト 会社概要
設立

1972年3月

代表取締役会長

ビル・トッテン代表取締役社長

大塚辰男

資本金6,000万円

売上高

317億円（2018年度）

従業者数

1,160名（2019年4月現在） ※グループ会社含む

事業内容

コンピュータ用パッケージ・ソフトウェアの販売、技術サポート、
教育およびコンサルティング

本社所在地

東京都千代田区九段北4-2-1

オフィス所在地

札幌、仙台、名古屋、金沢、大阪、広島、宇部、福岡、沖縄

取引会社数

6,300社（2018年度）

主要取扱製品数

60製品（2019年4月現在）

グループ会社

株式会社アシスト本舗
株式会社アシスト北海道
株式会社のれん

Copyright © 2019 K.K. Ashisuto

市ヶ谷東急ビル4

サイバー攻撃対策としての多層防御の現状
対策
ユーザー教育アンチウィルス

EDR/SIEM/ログ取得
サンドボックス

抑止・防止効果ポリシー・手順に沿って業務をしても、高度に偽装されたメールの添付ファイルの開封、本文のリンククリッ
クによる感染を防げず、感染の認識も困難
パターンマッチされないポリモーフィックマルウェア、ファイルレス攻撃によって標的型攻撃対策としては効果が低い。誤検知や大量のアラートに埋もれてしまうこともアラートを上げることはできても防止・抑止はできない。対応には高度な技術者によるトリアージと対応の実行権限が必要
高度なマルウェアはサンドボックスにいることを感知して振る舞い、すり抜ける

攻撃サーバのドメインは短時間で切り替わるため、ドメインレピュテーションのデータベース登録が行われる前に被害にあう。善意のサイトも改ざんさている場合がある

Webフィルター
SSLインスペクション
メールゲートウェイ
IPS
脆弱性管理

Webの通信内容をトレースできても不正通信の検知は検知エンジンの次第
わかりやすい攻撃メール、登録済みのドメイン、実行形式の添付ファイルであればフィルタリングできるが、高度なものはすり抜ける
高度な攻撃と正当な通信や振る舞いと高度な攻撃の区別が困難
既知の脆弱性に対する攻撃は対応可能だが、脆弱性を利用しない攻撃やゼロデイは防げない

上記は対策の一部ですが、すべて対策実施しても防ぎきれないのが標的型攻撃
最大の脆弱ポイントはWebサイト閲覧によるローカルPCでのコード実行
Copyright © 2019 K.K. Ashisuto5インターネット分離とは攻撃の9割が入ってくるインターネットと内部ネットワークの通信経路を分断し、外から内への脅威の侵入（入り口対策）と、内から外への不正な通信を防止（出口対策）する、効果の高いサイバーセキュリティ対策。
重要インフラ系、工場、病院は古くから内外ネットワークはもともと分離されていたが、年金機構の事件を受け、総務省の主導で全国自治体が実施したことでインターネット分離が一躍有名になった。

秘ネ重ッ要ト情ワ報ーク

秘秘

秘業務端末
Copyright © 2019 K.K. Ashisuto

秘ネット端末イン
ネタッー
トネワッートク接続系
6インターネット分離の最大の欠点
 セキュリティは高まるが…

インターネット用ネットワーク

インターネット分離
個人情報

❌
•
•
•

利便性、生産性、満足度が低下
コスト増加
シャドーITリスク

個人情報

行政システム
物理分離と同様のセキュリティ向上とその課題を解決するために生まれたのがインターネット分離ソリューション
Copyright © 2019 K.K. Ashisuto7

インターネット分離されると困るアプリたち
ブラウザ/http(s)Webアプリ・
アプリ更新/http(s)・ネット検索・SaaSアプリケーション
・Webメール・CMS・ファイル共有等

・Windowsアップデート
・パターンファイルアップデート
・Skype、Zoom、ハングアウト
等

メール/SMTPローカルメーラー

インターネット分離ソリューション
デスクトップをまるごと分離しなくても、インターネットアプリを分離・無害化、制御すれば良い
Copyright © 2019 K.K. Ashisuto8

インターネット分離ソリューションの守備範囲
Web分離ソリューション
分離環境でWebを実行、害の無い結果のみ取得
本セッションで深堀りします

ブラウザ/http(s)Copyright © 2019 K.K. Ashisuto

メール無害化

特定アプリと接続先ドメインをホワイトリスト化
単純な仕組みで安全性向上

Webアプリ・
アプリ更新/http(s)メール/SMTP

9

検知型アプローチとWeb分離の違い
既知

未知・新しいマルウェア
・ゼロデイ
・高度な攻撃・脆弱性を突く攻撃

検知系セキュリティ対策

セキュリティパッチ、Webフィルター、ネットワークセキュリティ、振る舞い検知、アンチウィルス等すり抜け・・

感染検知型セキュリティ対策
Copyright © 2019 K.K. Ashisuto

分離実行環境無害化

安全♪

＜Web分離のメリット＞
 既知/未知の脅威を分離 ゲートウェイ、エンドポイント、不正通信検知、SOC等への過剰なセキュリティ投資を抑制
 人の脆弱性による感染を防止
 ユーザーが安心して業務ができる
 端末のマルウェア感染が激減し、内部ネットワークのセキュリティインシデントが激減
 セキュリティ担当・IT担当が助かるセキュリティ向上施策

Web分離
10

Ericom Shieldの特徴

画面転送方式によるWebの完全分離

ローカルブラウジングと同等のユーザビリティ

タブLinuxブラウザベースのためMicrosoftライセンスを削減可

CDR

セッション
OS

タブ毎分離による感染範囲/リスクを最小化

あらゆるブラウザ、デバイスに対応

ファイル無害化機能をビルトイン

セキュリティ

ユーザビリティコスト

Copyright © 2019 K.K. Ashisuto11

Ericom Shieldの特徴
ローカルブラウザのお気に入りを利用可能

クリップボード対応

ローカルブラウザに既に登録済みのお気に入りを継続して利用可能です。もちろん新たにお気に入りを登録することも可能です。

リモートブラウザ側でコピーしたテキストをローカルデバイス側のクリップボードにリダイレクトします。その逆も可能です。

ローカルプリンタで印刷
閲覧中のWebページを一度PDF化し、ローカルプリンタで印刷を行います。
見えている範囲でなく、Webページ全体の印刷が可能です。

動画/音声対応
動画再生のプラグイン等もインストールせずに、安全に動画再生。

ファイルのダウンロード/アップロード

ローカルデバイスの辞書登録を利用可能
ローカルデバイスに登録している辞書登録機能をそのまま利用可能です。

ビルトインされたCDRとShieldの連携により、違和感無く無害化されたファイルをダウンロードすることが可能です。
インターネット側へのアップロードも対応しています。

ローカルブラウジングとほぼ変らないユーザビリティを提供
Copyright © 2019 K.K. Ashisuto12

無害化における「画面転送」と「サニタイズ」の争い
安全
第一

画面転送派の意見

サニタイズ派の意見

画面転送は全Webコンテンツを分離して実行するから完全分離だから100%安全です！

アクティブコンテンツはコンテナで分離実行し、画面操作の命令だけを送り、感染リスクのないコンテンツは端末側でレンダリング（実は仕組みが分かっていないが）サニタイズは完全分離ではない！
自治体では分離方式として公認されていない！

先端技術

通常のブラウジングと変わらないスムーズさを実現します！
画面転送は画面がカクカクして使いものになりませんよ！
ネットワークも広帯域が必要です！

画面転送もサニタイズも対応（2020年初頭）するEricom Shieldを使って両方式の裏側の仕組みを解き明かし、スッキリさせます！

Copyright © 2019 K.K. Ashisuto13

本題
Ericom Shieldの場合、どっちを選べば良いの？

画面転送
Copyright © 2019 K.K. Ashisuto

VSサニタイズ14

Ericom Shieldとはメール、ドキュメント、ブラウザをきっかけにした、以下のようなあらゆるWeb経由の攻撃から端末と内部のネットワークを守るWeb分離製品です

Copyright © 2019 K.K. Ashisuto

未知の攻撃、未知のマルウェアによる攻撃

メール、ドキュメント、Webサイト中の悪意のあるリンク

ドライブバイダウンロード

マクロ等のエクスプロイトが含まれるドキュメントのダウンロードWebアプリのアクセスポリシー制御

Ericom Shieldのシステム構成概要
組織内ネットワーク

リモートブラウザ環境/DMZ

インターネットShieldサーバ①⑤＜構成上の特徴＞• 専用クライアントも、ブラウザプラグインも不要②④
ローカルブラウザ• EricomのSSLルート証明書③

をインストールして、Proxyの⑦

向き先をShieldに変えるだけ

仮想コンテナ⑥
CDR処理

感染リスクのあるWebコンテンツで利用可能• Shieldの置き場所はオンプレ
ミス、クラウドどちらでもOK

CDRプラットフォーム
Copyright © 2019 K.K. Ashisuto16

Ericom Shieldの無害化方式の呼び名

画面転送

サニタイズ

フレームレンダリング

クリスタルレンダリング（2020年初頭リリース）

Copyright © 2019 K.K. Ashisuto17

【フレームレンダリング】Shieldによる画面転送の流れ
ブラウザ
１．httpリクエスト
共通のコンテナ準備段階

フレームレンダリ
ングセッ
ション

５．ShieldのHTMLを実行してShieldクライアントのJavaScriptを要求
７．ShieldのJavaScriptを実行
８．WebSocketに接続アップグレード要求
９．WebSocketセッション開始

Shield
２．認証
３．アクセス先URLに応じたアクセス制御
４．Shieldが下準備の標準HTMLを返す
６．クライアントのJavaScriptを提供

９．WebSocketセッション開始
１０．コンテナ割り当て
１１．URLのWebコンテンツを取得して実行
１２．仮想的な画面にレンダリングしてJPG変換
１３．画像と表示座標を送付

１４．送られてきた画像を指定座標に表示
１５．マウス、文字の入力イベントを随時送信

１６．画面上に変化が生じたら、新しい画像を送付

１７．送られてきた画像を指定座標に表示

１８．セッション終了時、コンテナ削除

Copyright © 2019 K.K. Ashisuto18

【フレームレンダリング】仕組み解明
インターネットWebサイト

Ericom Shield Webプロキシ/認証
 アクセスポリシー制御
 ベースのHTMLを返す コンテナ管理と割当
 Webコンテンツの実行 結果の画面をJPG化して転送 ブラウザからのイベントをストリーム実行
 画面差分のJPGと配置座標をストリーム転送

Copyright © 2019 K.K. Ashisuto

クライアントPCのブラウザ<html><body><script src=Cookie読み取り.js></script><script src=Shieldクライアント本体.js></script><script src=Shieldクライアント設定.js></script><canvas ローカルブラウザのウィンドウサイズ>
インターネットWebサイト</canvas>canvas領域

マウス、キーボードのイベント送信ベースのHTML
ストリームされるJPGがはめ込まれる
canvas領域を定義。ウィンド
ウサイズを変えるとリアルタイムに変わる。

</body></html>
19

【フレームレンダリング】動的なトップ画面表示

•••
•

•

Copyright © 2019 K.K. Ashisuto

この間約１秒。600KB程度のダウンロード
企業や情報系Webサイトはトップページが動的なものが多いため、常に画面転送は発生する
画面はキャッシュされず再利用されないため、常に画像がストリームされ続ける
動的な画面を表示したまま操作しなければインアクティブセッションの切断イベント発生まで画面はストリームされ続ける。
1分で36MB、5分で180MB
FPS値のデフォルトは8FPS/sec

20

【フレームレンダリング】マウス操作によるイベント発生時

マウスイベント

ローカルブラウザ上でマウス移動•••

画面変化

差分画面転送コンテナブラウザで実行し、画面変化を検出

ローカルブラウザのcanvasに上塗り

ローカルブラウザのマウスの座標情報、クリックといったイベントは常に送信され、リモートのコンテナ側で同じイベントが実行される。コンテナ側で画面が変化すれば、その画面変化がローカルに送信される差分の画面転送は画面全部ではなく、差分が生じた部分とその周辺が送られる
画面内の要素も見た目にも変更がない場合、画面転送は発生しない

Copyright © 2019 K.K. Ashisuto21

【フレームレンダリング】スクロール••••

スクロール時のFPSはデフォルトで5に設定され、jpgの圧縮率も高く設定されているためよく見るとにじみが確認できる
スクロールが完了すると、静止時の圧縮率に戻り、精彩な画面になる
スクロール1秒あたり、800KB程度の転送量
スクロール時のFPSと、圧縮率は変えられるが、圧縮率は90%にしてもサイズが10分の1にならない

Copyright © 2019 K.K. Ashisuto22

【フレームレンダリング】文字入力「A」を打鍵•変換候補が表示さらに変換候補が表示「S」を打鍵アシストと入力して文字変換完了までに約30枚のjpgがダウンロードされた。トータルおよそ3MBのデータ転送量。その間およそ4秒

Copyright © 2019 K.K. Ashisuto23

【フレームレンダリング】カーソル点滅••

カーソルの点滅も画面転送の対象になる変化の一つ
カーソルの点滅を無効にすることはブラウザではできない

Copyright © 2019 K.K. Ashisuto

24

デモ環境

クラウド
Webプロキシサービス

Wi-Fi/VPN

Ericom Shield
このパソコンのブラウザ

Copyright © 2019 K.K. Ashisuto

アシスト社内ネットワーク

インターネット
Webサイト25

クリスタルレンダリングを理解するためのキーワード「DOM」
 HTMLをブラウザが読み込むと、ブラウザ内にDOM （Document Object Model）
ツリーが作られる このツリーを構成するすべてのDOMノードを、JavaScriptでつついて好きなように操作して見た目を変えられる 文字や画像を変えたり、背景や文字色などのスタイルを変えたり、アニメーションのようにダイナミックに動かしたり、新しいDOMノードを追加することもできる

DOMツリー
Document
HTMLBODYDIVDOMノード

PText

P
Text

Copyright © 2019 K.K. Ashisuto26

【クリスタル】Shieldによるクリスタルレンダリングの流れ
ブラウザ
１．httpリクエスト
共通のコンテナ準備段階

クリスタ
ルレンダ
リング
セッショ
ン

５．ShieldのHTMLを実行してShieldクライアントのJavaScriptを要求
７．ShieldのJavaScriptを実行
８．WebSocketに接続アップグレード要求
９．WebSocketセッション開始

１２．HTMLをパースしてリソースをリクエスト
１４．Webコンテンツをレンダリング
マウス、文字の入力イベントを随時送信
１７．DOM操作を実施して、本来のページの姿に１８．入力イベントを随時送信

２０．DOM操作を実施
Copyright © 2019 K.K. Ashisuto

Shield
２．認証
３．アクセス先URLに応じたアクセス制御
４．Shieldが下準備の標準HTMLを返す
６．クライアントのJavaScriptを提供

９．WebSocketセッション開始
１０．コンテナ割り当て
１１．HTML内のJavaScript要素を潰して渡す
１３．その他のコンテンツ（CSS、画像等）を送付
１５．オリジナルのWebコンテンツを実行
１６．JavaScript実行でDOMノードが変化したら、同じ変化を生むDOM操作のJavaScriptコードを送付
１９．イベントを実行し続け、DOMノードに変化が生じたら、同様にDOM操作のJavaScriptコードを送付
２１．セッション終了時、コンテナ削除27

【クリスタル】仕組み解明
インターネットWebサイト

Ericom Shield Webプロキシ/認証
 アクセスポリシー制御
 ベースのHTMLを返す コンテナ管理と割当
 Webコンテンツの実行 オリジナルHTMLのJavaScript無効化（サニタイズ）と転送
 コンテナでイベント実行 →結果のDOMコード生成→ ブラウザへ送信
Copyright © 2019 K.K. Ashisuto

クライアントPCのブラウザ<html><body><script src=Cookie読み取り.js></script><script src=Shieldクライアント本体.js></script><script src=Shieldクライアント設定.js></script><iframe><body><no-script src = “オリジナルJavaScript.js”><no-script>オリジナルJavaScriptコード</no-script><p>オリジナルテキスト</p><img src = “オリジナル画像”><link href = “オリジナルCSS”></body></iframe>

マウス、キーボードのイ
ベント送信
ベースのHTMLJavaScriptが無効化されたオリジナル
html</body></html>
28

【クリスタル】オリジナルJavaScriptを使わずに結果をエミュレーション
ブラウザ

WebSocket通信

Shieldコンテナブラウザ①「マウス位置は x:300px y:50だよ」④「リンクメニューのDOMノードを作成して、座標 x:300px y:80に表示せよ」②コンテナ上でマウスイベントを実行③DOMノードの変化を検出⑤指示通りにDOMノードを作成し、指定位置に表示⑥「マウス位置は x:400px y:100だよ」⑨「Ericom ShieldというテキストのDOMノードに「マウスオーバーされたときの文字スタイル」を適用せよ⑪「マウス位置 x:300px y:100でクリックしたよ」⑪DOMノードに「マウスオーバーされたときの文字スタイル」を適用
Copyright © 2019 K.K. Ashisuto⑫このウィンドウのままhttp://xx/xx.htmlにアクセスせよ⑦コンテナ上でマウスイベントを実行⑧DOMノードの変化を検出
29

デモ環境

クラウド
Webプロキシサービス

Wi-Fi/VPN

Ericom Shield
このパソコンのブラウザ

Copyright © 2019 K.K. Ashisuto

アシスト社内ネットワーク

インターネット
Webサイト30

【セキュリティ強度比較】フレームレンダリング VS クリスタルレンダリング
フレームレンダリング

クリスタルレンダリング

Web実行における端末のマルウェア感染

インターネット上の一切のコンテンツはコンテナで実行され、端末側には一切入ってこないため、ゼロデイ攻撃、高度な攻撃であったとしても端末側は100%安全といえる。

オリジナルのJavaScriptは無効化され、ページ内の静的要素のみを端末側でレンダリングするため、安全。将来的にブラウザを標的にJavaScript以外の攻撃手法が出現した際は、機能強化で対応。

ダウンロードファ
イルのサニタイズ

Votiroを利用可能。ただし、実行ファイル等サニタイズできないものあるため、全てが安全になるわけではない。

同左

フィッシング対策

詐欺サイト側に自ら情報を入力してしまえば、情報搾取は免れない。InterSafe
WebFilterやEricomのオプションと一緒に利用することで、認識された詐欺サイトへのアクセスは制御可能。

同左

Copyright © 2019 K.K. Ashisuto31

【使い勝手比較】フレームレンダリング VS クリスタルレンダリング
ローカルライクなブラウジング・ナ
ビゲーション

フレームレンダリング

クリスタルレンダリング

ブラウザから利用でき、ブラウザメニューもすべて有効なので、普段と使い勝手は変わらない。ただし、文字入力、画面スクロールのラグでストレスを感じやすい。

静的なページ表示に必要なコンテンツはすべてローカル側に落ちてきているため、ローカルブラウジングと同様にスムーズにナビゲーションできる。

ローカルブラウジ 動画・音声再生、コピー＆ペースト、おングと同様の機気に入り、ユーザー辞書、印刷、ファイ能性
ルのダウンロードとアップロードなど、基本的な機能にすべて対応。

同左

あらゆるWebサ
イトを閲覧可能か

左記の制限にプラスして、現時点ではJavaScriptの使われ方によってはナビゲーションができない、表示がされない、といった場合がある。多機能なWebアプ
リ系（Salesforce等）はまだ苦手。

Copyright © 2019 K.K. AshisutoLinuxのブラウザで閲覧できるサイトであればすべて閲覧可能。
ただし、クライアント証明書や、ローカルストレージを利用する特殊なWebサイトでは利用できない。

32

【端末CPU比較】フレームレンダリング VS クリスタルレンダリング
テストシナリオ：日経のWebサイトを表示して、ページの一番下まで1分かけてスクロールを実施

フレームレンダリング
ページ要求

静止

スクロール

・ページ要求してから表示完了までのタイミングは早い
・静止している時間は通信も処理も発生していないため、CPU使用率は低い
・スクロール時も、単純に画像のやり取りなので、CPU使用率は特別大きくない
Copyright © 2019 K.K. Ashisuto

クリスタルレンダリング

ページ要求

スクロール

・ページの表示開始時にCPUを多く消費。ロー
カルブラウジングと同じリソースの処理傾向
・ページ内のコンテンツを表示仕切る前でもスクロール可能

33

【端末ネットワーク比較】フレームレンダリング VS クリスタルレンダリング
テストシナリオ：日経のWebサイトを表示して、ページの一番下まで1分かけてスクロールを実施

フレームレンダリング
ページ要求500表示スクロール• スクロール時平均3Mbps程度の通信が発生• 別タブ表示中は、隠れたタブの画面転送は止まる• モバイル環境で長時間利用するには向かない• 利用者の数に応じて、アクセスネットワーク、サーバネットワークの増強も検討が必要

Copyright © 2019 K.K. Ashisuto

Kbps

Mbps

10

クリスタルレンダリング

ページ要求

スクロール

• ページ要求時、MAXで7Mbps程度まで上がった。普通のブラウジングと同じ挙動• スクロール中の帯域使用量は平均150Kbps程度• HTMLをダウンロードした後はスクロールや、テキストは読めるため、低帯域・高遅延ネットワークで利用可
34

【ブラウザサーバのリソース】フレーム＆クリスタル共通
最もサーバCPU負荷がかかるのはコンテナ作成時。ブラウザ閲覧時の負荷は両方とも気にするほどではない。
朝のアクセスピークに合わせてブラウザコンテナ数を増やす機能で準備しておけばオフピークできる。

CPU負荷

作成

待機利用

高低中

コンテナ数
ピーク前に ピーク
事前に準備

ピーク

9時

12時

待機コンテナ数

時間

使用中コンテナ数

ピーク時前に待機コンテナ数を増やしてオフピーク
準備せずピーク時にコンテナを大量作成するとスローダウンの懸念あり
Copyright © 2019 K.K. Ashisuto

httpリクエストに対して瞬間的に割り当て

破棄

ユーザーがタブを閉じたり、リロードしたり、ページ内リンクをクリックしたり、無操作から一定時間を経過すると自動的に破棄35

【サーバリソース比較】フレームレンダリング VS クリスタルレンダリング
フレームレンダリング

クリスタルレンダリングCPU

既定値：0.2CPU～2CPU/コンテナ
ページロード時：25～40%程度
スクロール時：15%～25%程度
一部動いているとき：10%程度
安静時：1%

既定値：0.2CPU～2CPU/コンテナ
ページロード時：30%～60%程度
スクロール時：15%程度
JavaScriptが多いページ：15%程度
安静時：1%

メモリ

既定値：150～1,000MB/コンテナ
ブラウジングに必要な機能だけで使うため、VDIと比べると極めて軽量

同左

ネットワーク・操作時＆動的ページの閲覧時は平均的に1～3Mbps/コンテナ程度使用するため、ユーザーの数に合わせてアクセス回線とサーバー側ネットワークの増強の検討が必要
・携帯キャリアのデータプランには向かない。

普通のブラウザと同様な帯域利用なので、今のネットワーク構成を変える必要がない

Copyright © 2019 K.K. Ashisuto3636

結果まとめ大項目
セキュリティ

使い勝手

ハードウェ
ア（コスト）

フレーム
レンダリングクリスタル
レンダリング

Web実行におけるマルウェア感染◎○

ファイルのサニタイズ○○

フィッシング対策△△

ローカルライクなブラウジング・ナビゲーション△○

ローカルブラウジングと同様の機能性○○

あらゆるWebサイトを閲覧可能か

○

△

CPU

○

○

メモリ

○

○

ネットワーク△○Copyright © 2019 K.K. Ashisuto37結果まとめ大項目
セキュリティ

フレーム
レンダリングクリスタル
レンダリング

Web実行におけるマルウェア感染◎○

ファイルのサニタイズ○○

フィッシング対策△△

ローカルライクなブラウジング・ナビゲーション△○

ローカルブラウジングと同様の機能性○○

あらゆるWebサイトを閲覧可能か

○

△

CPU

○

○

引き分け

使い勝手

ハードウェ
ア（コスト）

メモリ○○
個人的にはクリスタルレンダリングの今後の進化に期待
ネットワークCopyright © 2019 K.K. Ashisuto△○38

アシストからの推奨
フレームレンダリング
 自治体、教育委員会のように国から完全分離を義務化、推奨されている分野
 国家機密、軍事技術開発、先端技術開発に関わっている 怪しいサイトを潜入調査するセキュリ
ティリサーチャークリスタルレンダリング
 Web分離はしたいが、使い勝手を維持したい
 導入時にオンプレミスのネットワーク構成を変えたくない 文字入力するWebアプリの利用 モバイル端末から携帯キャリアのデータ通信で利用する

実はEricom Shieldなら同じライセンスで使い分けが可能！
Copyright © 2019 K.K. Ashisuto39

WebセキュリティをEricom Shieldで一元管理

どのサイトを誰に あらゆるサイト
 特定ドメイン

 全員
 特定グループ※オプション機能

 特定のURL

どう接続させてクリスタルレンダリング
フレームレンダリング
ローカルブラウジング
アクセスブロック

どう使わせるか

ファイルのサニタイズ有無
アップロード可否コピー＆ペースト可否
印刷可否 etc「うちの組織にピッタリなWebセキュリティ」を実現
Copyright © 2019 K.K. Ashisuto40Ericom Shield×Webフィルター
Ericom Shield URL
カテゴリゼーション・オプション

InterSafe WebFilter連携

URLカテゴリごとのアクセス制御はInterSafe側で行います

Ericom Shieldのオプション機
能。URLカテゴリごとのアクセス制
御をShield内で定義＆管理します。

「未分類」カテゴリのURLアクセスのみを分離する低コスト構成
Ericom ShieldとInterSafe WebFilterの連携イメージ
Copyright © 2019 K.K. Ashisuto41

まとめ フレームレンダリング（画面転送）は端末側は100%安全だが、文字入の多いサイトには向かない。ネットワークにも考慮が必要
 クリスタルレンダリング（サニタイズ）の仕組みはオリジナルのJavaScriptをコンテナ側では実行するが、クライアント側では実行させず、DOMの操作命令で結果の見た目を同じにしている クリスタルレンダリングの操作感は普通のブラウジングと変わらず、理論上安全。ただし、まだ動かないサイトも多い どちらもWebセキュリティとしては十分だが、組織のリスク判断に応じて使い分ければセキュリティと使い勝手を最適化できる
Copyright © 2019 K.K. Ashisuto42

※本資料に記載している情報は、2019年10月17日現在のものです。
※本資料の内容は、今後予告なく変更されることがあります。
※OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
※文中の社名、商品名等は各社の商標または登録商標である場合があります。

Copyright © 2019 K.K. Ashisuto43