7.2. Shield のアーキテクチャ

7.2.1. 導入

../_images/shieldarchitecture_es2111_01.jpg

Ericom Shieldは5つの独立した論理コンポーネントを含み、それぞれがいくつかのマイクロサービスを含んでいます。これらのマイクロサービスは、Linux Ubuntuサーバ上でDockerコンテナとして公開されています。

コンポーネントは、1台のマシンにまとめてインストールすることも、異なるマシンや場所に分けてインストールすることも可能です。あるものはドメインに、あるものはDMZにと、顧客のニーズに応じて柔軟に対応できます。以下は、各コンポーネント上で動作するマイクロサービスです。

Shield管理

  • Web ベースの管理コンソール
  • インメモリデータベース - すべての内部構成が保持されます
  • ライセンス管理

Shieldプロキシ

  • 認証
  • HTTPS の SSL バンピング
  • ポリシーの管理と実施-白黒のポリシールールを処理します

Shield-Log (ELK)

  • ログ
  • レポート(Kibana)

ファームサービス

  • ブラウザファームのエントリポイント(プロキシ/リダイレクト)
  • 自動スケーラー - リモートブラウザとノードの両方
  • ポリシー管理 - すべての Shield ポリシー (ダウンロード、印刷、レンダリングなど) の管理
  • CDR サービス
  • 広告のブロックとキャッシュ

ブラウザファーム

  • リモートブラウザ - ブラウジング接続を実行している実際のコンテナ
  • ポリシーの適用 -ファームサービスポリシーマネージャーを使用して、ブラウジング接続にこれらのポリシーを適用します

共通

  • Logstash
  • コレクタ

7.2.2. 展開トポロジ

Ericom Shieldを既存のお客様の環境に導入する場合、いくつかのトポロジーが考えられます。

既存の環境では、エンドユーザーとインターネットとの間の接続チェーンの中に、いくつかのコンポーネントが存在する場合があります。Ericom Shieldはこの接続チェーンに統合されます。既存のプロキシが1つ以上あるか、全くないか。ファイアウォールや複数のファイアウォール、DMZがあるかもしれません。Shieldは、このチェーンの様々な位置に配置することができます。

Shield-Management、Shield-Proxy、および Shield-Log をドメインに配置し、Farm Services および Browsers Farm を DMZ に配置することが推奨されます。これは、最も安全でセキュアな展開です。しかし、お客様の既存の環境は、システム内のすべてのパラメータとコンポーネントを考慮した上で、最終的な配置を決定します。

ここでは、トポロジーの例をいくつか紹介します。

../_images/shieldarchitecture_es2111_02.jpg

7.2.3. プロセスフロー

ユーザーは、ブラウザーのアドレスバーにドメインアドレスを入力することで、目的のウェブページに移動することができます。

HTTP/SリクエストはShield Proxyに送られ、処理されます。ホワイトリストに登録されたドメインとアプリケーションは、ユーザーに直接転送されます。その他のリクエストはファームに送信され、ファームは事前に定義されたポリシー (Administration Console で設定) に従って指定されたドメインを処理します。

ドメインがブラックリストに登録されている場合、接続がブロックされ、ユーザーにメッセージが表示されます。ドメインがホワイトリストに登録されている場合は、Shieldを介さずに直接開かれます。ドメインがシールドされている場合、Shield Proxyは利用可能なブラウザプールからShield Browserを割り当て、新しい専用コンテナがセッションに割り当てられ、目的のドメインが開かれてユーザーに配信されます。

Shield Browserは、管理者があらかじめ設定したポリシーに従って、ビデオ、オーディオ、印刷、ダウンロードなど、一般的に使用されるすべての機能を含むシームレスなブラウジング体験をユーザーに提供することが可能です。

ファイルをダウンロードする際、ダウンロードされたファイルはまずCDR（Content Disarm and Reconstruct）エンジンに送られ、ファイルを分解して潜在的な害をもたらす可能性のあるコンテンツ（既知および未知の脅威）を除去するよう設計されています。ファイルのサニタイズが完了すると、サニタイズされたファイルがユーザーに送信されます。

ユーザーがブラウザを閉じると、セッションが終了し、コンテナは破棄されます。これは、セッションがタイムアウトした場合のシナリオでもあります。

7.2.4. ユースケース

Shield は、シングルマシンからマルチマシン、マルチゾーンまで、さまざまなデプロイメントが可能です。ここでは、Shieldのデプロイメントに関する一般的なユースケースをいくつか紹介します。

基本

../_images/shieldarchitecture_es2111_03.jpg

すべてのShieldコンポーネントが1台のマシンに配備されています。これは最も基本的なオプションで、Shieldの迅速な評価に使用されます。

小規模な展開(非HA)

../_images/shieldarchitecture_es2111_04.jpg

含まれるもの:

  • Shield-Management、Shield-Proxy、Shield-Log & Farm Servicesの各コンポーネントが稼働しているマシン1台。
  • 2台目のマシン、その上でBrowser Farmを実行する。このマシンは、リモートブラウザ専用にする必要があります。

これは、HA を必要としない小規模なデプロイメントに推奨される配置です。この配置は、Basic オプションよりも安定性と安全性が高いですが、HA (High Availability) はサポートされません。

スプリットモード

../_images/shieldarchitecture_es2111_05.jpg

管理クラスターと呼ばれる、Shield-ManagementおよびShield-Proxyコンポーネントを実行する1台のマシンが含まれます。このマシンはドメインに配置する必要があります。Shield-Log、Farm Services、およびBrowser Farmコンポーネントを実行する2番目のマシンで、FarmClusterと呼ばれます。このマシンは DMZ に配置する必要があります。

小規模な展開(HA)

../_images/shieldarchitecture_es2111_06.jpg

3台のマシンが含まれています。各マシンにShieldコンポーネントが全て入っています。このデプロイは、安定性が高く、HAを確保できるため、小規模な本番環境に適しています。ただし、すべてのマシンがドメイン内に配置されているため、DMZのセキュリティには欠ける。

本稼働

../_images/shieldarchitecture_es2111_07.jpg

これは、本番環境に推奨される展開です。ドメイン内に配置された、Shield-Management、Shield-Proxy、Shield-Log の各コンポーネントを実行する 3 台のマシンと、DMZ 内に配置された、Farm Services と Browser Farm の各コンポーネントを実行する 3 台 (以上) のマシンで構成されています。

注意

ファームサービスが動作するマシンが3台必要です。ファームサービスのコンポーネントを追加することなく、必要に応じてブラウザファームを追加することができます。

この本番環境は最も安定しており、HAを保証し、DMZにあるファームコンポーネントによってより安全です。

参考

Kubernetesの推奨事項によると、10台以上のWorkerノードを含むデプロイメントでは、Workerノードとは別に専用のクラスタ管理（etcdとControl Planeを実行する3台のマスターノード）を用意することが推奨されています。