Ericom Shieldのアーキテクチャ

../_images/architecture_f17.png

Ericom Shield には、複数のマイクロサービスを含む 5 つの個別の論理コンポーネントがそれぞれ含まれています。これらのマイクロサービスは、Linux サーバー上の Docker コンテナーとして公開されます。 (Ubuntu/CentOS上で稼働します。)

コンポーネントは、単一のマシンに一緒にインストールすることも、異なるマシンや場所に分離することもできます。 優れた柔軟性により、顧客のニーズに応じて、一部をローカルドメイン内、一部をDMZ内などに配置できます。これらは、各コンポーネントで実行されているマイクロサービスを持つさまざまなコンポーネントです。

Shield-Management

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

Shield-Proxy

  • 認証
  • HTTPS の SSL Bump
  • ポリシー管理と施行 - ブラックおよびホワイト ポリシールールを処理

Shield-Log (ELK)

  • ログ
  • レポート(Kibana)

Farm Services

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

Browser Farm

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

Common

  • FluentBit
  • コレクター

プロセスフロー

ユーザは、ブラウザのアドレスバーにURLアドレスを入力することによって、希望するウェブページにアクセスします。

HTTP/S 要求は、処理のためにShieldプロキシに送信されます。ホワイトリストに登録されたドメインとアプリケーションは、ユーザーに直接転送されます。その他のすべての要求はファームに送信され、定義済みのポリシー (管理コンソールで構成) に従って特定のドメインを処理します。

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

URLがblackでもwhiteでもないサイトである場合、Shield Coreは利用可能なブラウザプールからShield Browserを割り当て、割り当てられた専用コンテナが目的のURLを開いてユーザーに配信されます。 Shield Browserを使用すると、管理者が設定した定義済みのポリシーに従って、ビデオ、オーディオ、印刷、ダウンロードなどの一般的に使用されるすべての機能を含む、シームレスなブラウジングエクスペリエンスを実現できます。

ファイルをダウンロードするとき、ダウンロードされたファイルは、ファイルを分解し、潜在的な害（既知の脅威と未知の脅威の両方）を引き起こす可能性のあるコンテンツを削除するように設計された Content Disarm and Reconstruct（CDR）エンジンに最初に送信されます。 ファイルのサニタイズが完了すると、サニタイズされたファイルがユーザーに送信されます。

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

使用例

Shieldは、単一のマシンからマルチマシン、マルチゾーンの展開に至るまで、さまざまに展開できます。Shield 展開の一般的なユースケースを次に説明します。

基本

../_images/basic4.png

すべてのShield コンポーネントは、1台のコンピューターに展開されます。これは、Shieldの迅速な評価に使用される最も基本的なオプションです。

評価

../_images/evaluation4.png

Shield-Management、Shield-Proxy および Shield-Log コンポーネントを実行している1台のマシンが含まれています。このマシンはドメインに配置する必要があります。Farm Services & Browser Farm コンポーネントを実行する 2台目のマシン。このマシンはDMZに配置する必要があります。

推奨 の 評価 展開です。この展開は 基本オプションよりも安定して安全ですが、高可用性 (HA) をサポートしていません。

小規模展開 (HA)

../_images/smalldeployment4.png

3台分のマシンが含まれています。各マシンには、すべてのShieldコンポーネントが含まれています。この展開は、安定しており、HA を確保するため、小規模な運用環境に適しています。ただし、すべてのマシンがドメインに配置されるので、DMZ のセキュリティが欠如しています。

本番環境

../_images/production4.png

これは、運用環境向けの 推奨 展開です。Shield-Management 、Shield-Proxy 、Shield-Log コンポーネントを実行している3台のマシンがドメインに配置され、Farm Services & Browser Farm コンポーネントを実行している3台（またはそれ以上）のマシンがDMZに配置されます。

参考

Farm Services を実行している3台のマシンが必要です。 Farm Services コンポーネントを追加せずに、必要に応じて Browser Farm を追加できます。

この運用環境の展開は安定しており、HA を確保し、DMZ にある Farm コンポーネントにより安全性が高くなります。

参考

Kubernetes の推奨事項によると、10 を超える Workerノードを含む展開では、専用のクラスタ管理 (3つのMasterノード、etcd & Control Plane を実行） を Worker ノードから分離することをお勧めします。

展開トポロジ

Ericom Shieldには、既存の顧客環境において、いくつかのトポロジーが考えられます。

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

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

いくつかのトポロジの例を以下に示します。

../_images/topologies7.png