7.2. Shield のアーキテクチャ

7.2.1. 導入

../_images/shieldarchitecture_es2111_01.jpg

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

コンポーネントは、単一のマシンに一緒にインストールすることも、異なるマシンや場所に分離してインストールすることもできます。ドメイン内または DMZ 内にインストールすることができます。ユーザのニーズに合わせて柔軟に対応可能です。これらは、各コンポーネントで実行されているマイクロサービスを備えたさまざまなコンポーネントです。

Shield管理

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

Shieldプロキシ

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

Shield-Log (ELK)

  • ログ
  • レポート(Kibana)

ファームサービス

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

ブラウザファーム

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

共通

  • Logstash
  • コレクタ

7.2.2. 展開トポロジ

既存のお客様の環境では、EricomShieldにいくつかの可能なトポロジがあります。

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

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

トポロジの例を以下に示します:

../_images/shieldarchitecture_es2111_02.jpg

7.2.3. プロセスフロー

ユーザは、ブラウザのアドレスバーにドメインアドレスを入力して、目的の Web ページに移動します。

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

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

Shieldブラウザを使用すると、管理者が設定した事前定義されたポリシーに従って、ビデオ、オーディオ、印刷、ダウンロードなどの一般的に使用されるすべての機能を含む、シームレスなブラウジングエクスペリエンスをユーザーに提供できます。

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

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

7.2.4. ユースケース

Shieldは、単一のマシンから複数のマシン、マルチゾーンの展開に至るまで、さまざまな展開で展開できます。Shield展開の一般的な使用例は次のとおりです。

基本

../_images/shieldarchitecture_es2111_03.jpg

すべての Shield コンポーネントは単一のマシンにデプロイされます。これは最も基本的なオプションであり、Shield の迅速な評価に使用されます。

小規模な展開(非HA)

../_images/shieldarchitecture_es2111_04.jpg

含まれるもの:

  • Shield-Management、Shield-Proxy、Shield-Log＆FarmServicesコンポーネントを実行している1台のマシン。
  • ブラウザファームを実行している2番目のマシン。このマシンは、リモートブラウザ専用である必要があります。

これは、HAを必要としない小規模な展開に推奨される展開です。この展開は、基本オプションよりも安定していて安全ですが、高可用性（HA）をサポートしていません。

スプリットモード

../_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に配置されたそれらのファームサービスおよびブラウザファームコンポーネントを実行する3台（またはそれ以上）のマシンが含まれます。

注意

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

この実稼働展開は、DMZ に配置されたファームコンポーネントにより、最も安定しており、HAを保証し、より安全です。

参考

Kubernetesの推奨事項によると、10を超えるワーカーノードを含むデプロイでは、専用のクラスター管理（3つのマスターノード、実行中のetcd＆コントロールプレーン）をワーカーノードから分離することをお勧めします。