7.13. ハウツー - クイックガイド

7.13.1. 独自のプロキシ証明書を使用する方法

  • Shieldプロキシに独自証明書を使用する方法

前提条件

アップロードする証明書は、ルート CA またはサブ CA である必要があります。 ホスト証明書であることはできません。

使用方法

プロキシアクセスに標準のericomshield.crtではなく、独自の証明書を使用するには、以下を実行します。

  • Shieldの管理ポータルを開きます。
  • [設定]-[SSL]をクリックします。
カスタムCAパスワード 証明書のパスフレーズを入力する
カスタムCA公開鍵のアップロード 目的の証明書の公開鍵をアップロードします。証明書にはチェーン全体が含まれている必要があります。
カスタムCA秘密鍵のアップロード 対応する秘密鍵をアップロードする
カスタム信頼性証明書のアップロード 信頼できる証明書をアップロードする
../_images/howto_es2111_36.jpg

ファイルのアップロードに成功すると、通知ポップアップが表示されます。

../_images/howto_es2111_37.jpg

最後に、Rancherにログインし、ワークロードを再展開することで、新しい証明書を有効化します。

ext-proxy

../_images/howto_es2111_38.jpg

および ext-proxy-noadblock

../_images/howto_es2111_39.jpg

次にユーザーがShieldプロキシに移動するときは、更新された証明書が使用されます（ローカルブラウザで使用するためにこの証明書をインストールすることを忘れないでください）。

トラブルシューティング

設定に間違いがある場合は、エラーメッセージが表示されます。

../_images/howto_es2111_40.jpg

アップロードされた証明書がCAでない場合、特定のRancherワークロードが起動しない：ext-proxyおよびext-proxy-noadblock

../_images/howto_es2111_41.jpg

この場合、管理ポータルサイトの「設定」→「SSL」→「証明書の復元」を実行します。

../_images/howto_es2111_42.jpg

Rancherのワークロードがオンラインに戻るまで数分待ち、ルートCA証明書を再インポートします。

証明書がCAであることを確認するには、openSSLを使用して、openssl x509 -in <証明書名> -purpose -noout -textを実行します。

openssl x509 -in <証明書名> -purpose -noout -text

SSL CAがYesであることを確認します。

7.13.2. Shieldサービス

Shieldには、以下のサービスが含まれています。

インストール、既存のクラスターの変更、バージョンのアップグレードなどのさまざまなプロセスで、必要に応じてこれらのサービスを使用してください。

Shieldをインストールする

このサービスは、Shieldをインストールするか、新しいShieldバージョンにアップグレードするために使用されます。

install-shield.shスクリプトを取得します。

curl -so install-shield.sh https://raw.githubusercontent.com/EricomSoftwareLtd/Shield/master/Kube/scripts/install-shield.sh
chmod x install-shield.sh

使用法:

./install-shield.sh -p <PASSWORD> [-v | --version <version-name>] [-r | --releases] [--registry <RegistryIPAddress：Port>] [-n | --namespace <NAMESPACE>（<NAMESPACE>）] [-l | --label] [-h | --help]

引数:

  • -p：Shieldリポジトリには有効なパスワードが必要です。Ericom Shield Professional Servicesに連絡してパスワードを取得し、コマンドで置き換えてください。
  • [-v | –version] <バージョン名>： 特定のバージョンをインストールします。バージョン名の形式は次のとおりです。Rel-yy.mm.xxx（例：Rel-20.03.641）
  • [-r | –releases]：インストールできる最新の3つのバージョンのリストを表示します
  • [–registry <RegistryIPAddress：port>]：オフラインインストールのみ。DockerイメージにShieldレジストリを使用する
  • [-n | –namespace <NS>（<NS>）]：指定された名前空間のみをインストールします。他の名前空間は変更しないでください
  • [-l | –label]：ラベルを設定する
  • [-h | –help]：オプションメニューを表示します

サーバーを準備する

このサービスは、サーバーノードをクラスターに参加させる前に準備します。 OS設定の構成、Dockerのインストールなど。

使用法:

./shield-prepare-servers [-u <USER>] <ServerIPAddress(s)>

ServerIPAddress（s）は、サーバーノードのIPアドレスを表します。スペース（ 「」）で区切って、複数のIPアドレスを入力できます。

引数:

  • [-u | –user]：SSH経由でノードに接続するために使用するユーザー名（すべてのノードで同じである必要があります）
  • [ - オフラインモード]：インターネット接続を必要とするタスクを実行しないでください
  • [–offline-registry] <address：port>：オフラインレジストリのIPアドレスとポート

例:

./shield-prepare-servers -u ericom xx.xx.xx.xx yy.yy.yy.yy zz.zz.zz.zz

オフラインの場合：

./shield-prepare-servers -u ericom --offline-mode --offline-registry vv.vv.vv.vv：5000 xx.xx.xx.xx yy.yy.yy.yy zz.zz.zz.zz

Shieldを再起動します

Shieldを再起動するには、/ ericomshieldフォルダーにあるstop.shおよびstart.shスクリプトを使用します。

最初のスクリプトは停止してすべてのShield名前空間を削除し、2番目のスクリプトはそれらを新しいものから実行します。

使用法:

stop.sh [-n | --namespace <NAMESPACE>] [-s | --silent] [-k | --keep-namespace] [-h | --help]

引数:

  • -n：特定の名前空間を削除します：shield-management、shield-proxy、shield-farm、shield-elk
  • -s：サイレント：確認を求めないでください）
  • -k：特定の名前空間の削除をスキップする
start.sh [-n | --namespace <NAMESPACE>] [-l | --label] [-o | --overwrite] [-f | --force] [-h | --help]
  • -n：特定の名前空間をデプロイします：shield-management、shield-proxy、shield-farm、shield-elk
  • -l：ラベルを設定する
  • -f：強制オプション
  • -o：yamlファイルを上書きする

7.13.3. Kerberosアカウントを作成する方法

Kerberosを介してドメインユーザーを認証できるようにするには、各Shieldシステムに専用のユーザーアカウントを特別に作成する必要があります。

この専用ユーザーは、有効期限が切れないパスワードを持っている必要があり、Kerberos事前認証メカニズムをスキップする必要があります。

次の手順に従って、ユーザーを作成します。

ドメインコントローラーで、ActiveDirectoryユーザーとコンピューターを開きます

アクション|を選択します新規|メニューからのユーザー

新しいユーザーアカウントの詳細を入力し、[次へ]をクリックします

目的のパスワードを設定し、ユーザーが次回のログイン時にパスワードを変更する必要があることを確認し、パスワードが期限切れにならないことを確認します。

ユーザーを保存した後、再度開いて[アカウント]タブを選択し、[アカウントオプション]セクションで[Kerberosの事前認証を必要としない]を設定します。

ユーザーが作成されたら、Keytabファイルを生成する必要があります。Keytabファイルには、Windows以外のマシン（この場合はShield Server）がKerberosを利用できるようにする共有シークレットが含まれています。キータブファイルを作成するには：

ドメインコントローラーでコマンドプロンプトを開きます。

管理画面のKerberos設定からコピーしたコマンド（詳細はこちら）または以下のコマンドを使用して、keytabを作成し、ユーザー名を新しいサービス名にマッピングします（以前に作成したユーザー認証情報を使用します）。

ktpass -out <DNS名> .keytab-mapUser <ユーザーの完全なUPN> -pass <パスワード> -mapOp set DumpSalt -crypto rc4-hmac-nt -ptype KRB5_NT_PRINCIPAL -princ HTTP / <ShieldサーバーのFQDN>@<DOMAIN>

実例：

上記の詳細を例にとると、キータブファイルの作成に使用されるコマンドは次のようになります。

ktpass -out Shieldnode.company.local.keytab -mapUser shield@company.local -pass Password1 -mapOp set DumpSalt -crypto rc4-hmac-nt -ptype KRB5_NT_PRINCIPAL -princ HTTP / Shieldnode.company.local@COMPANY.LOCAL

注意

Kerberos認証では、ドメイン名（HTTP / Shieldnode.company.local @ COMPANY.LOCAL）に大文字を使用することが重要です。また、Shieldサーバーをプロキシとして使用するようにブラウザを構成する場合は、IPアドレスではなくFQDNも使用することが重要です。

7.13.4. Shieldをスプリットモードでデプロイする

一部のコンポーネントがLANにあり、他のコンポーネントがDMZにある場合、Shieldはスプリットモードで展開できます。

これが選択された展開である場合、2つのクラスターが作成され、それらの場所（DMZ / LAN）ごとに定義されます。

../_images/howto_es2111_01.jpg

LAN内にある管理クラスター（クラスターAと呼ばれる）には、管理コンポーネントとプロキシコンポーネントが含まれます。DMZにあるファームクラスター（クラスターBと呼ばれる）には、ELKとブラウザーファームが含まれます。

これが展開の場合、2つのクラスター間を接続するためにいくつかの設定を構成する必要があります。これにより、一方のクラスターのコンポーネントが認識され、もう一方のクラスターと通信して、Shieldが適切に機能するようになります。

管理者設定

管理者に移動|設定|動的ノードおよび動的ノードファームのURLを更新して、30443ポートを使用してファームを指すようにします。例えば。 ericom-farm.mydomain.local：30443。

管理者に移動|設定| ericom-farm.mydomain.localを指すようにWebSocketURLを拡張および更新します

さまざまなコンポーネントを構成する

  • クラスターA（ドメイン）の構成変更

注意

以下の手順には、YAMLファイルのいくつかの変更が含まれています。スペースのみを使用して、正しいインデントを維持する必要があることに注意してください。タブの使用はYAMLではサポートされておらず、エラーが発生します。

クラスターAを実行しているマシンに移動し、次のyamlファイルを更新します。

custom-management.yamlとcustom-proxy.yamlを編集します（ファイル内の指示に従います）：

# Split-Mode: uncomment these lines and replace the IP (dashes separated) of the server running the Browser Farm
#   farmAddress: |
#     - name: FARMURL
#       value: https://ericom-farm.mydomain.local:30443
#     - name: FARMENABLED
#       value: 'true'
# When ELK is running on a different system (e.g. Split Mode), uncomment this
# line and replace the IP (enter the IP of the server running ELK)
#  elasticHost: "ericom-farm.mydomain.local:9200"

注意

ericom-farm.mydomain.localは、使用中の特定のサーバー、または複数のサーバーが使用されている場合はVIPを指す必要があります。

custom-common.yamlを編集し、ファイル内の指示に従い、管理用の関連ファイルのコメントを解除します。

#  For Split Mode only on Management Uncomment these lines:
#  Replace the IP (enter the IP of the server running ELK)
#  logstash:
#    elasticHost: "ericom-farm.mydomain.local:9200"
#    logstashHost: ""
#    logstashPort: "30500"

さらに、IPをクラスターBのIPアドレス（DMZ内）に更新します。

  • クラスターB（DMZ）の構成変更

注意

以下の手順には、YAMLファイルのいくつかの変更が含まれています。スペースのみを使用して、正しいインデントを維持する必要があることに注意してください。タブの使用はYAMLではサポートされておらず、エラーが発生します。

クラスターBを実行しているマシンに移動し、custom-farm.yamlを編集します。ファイル内の指示に従い、次の行のコメントを解除します。

# Split-Mode: uncomment these lines:
#  proxyless:
#    sslip:
#      enabled: true
#  extProxyIngress: true
#  extProxyIngressPort: 30128

custom-common.yamlを編集し、ファイル内の指示に従い、ファームの関連行のコメントを解除します。

#  For Split Mode only on FARM - Uncomment these lines:
#  logstash:
#    consulvar: |
#      - name: CONSUL_HOST
#        valueFrom:
#          fieldRef:
#            fieldPath: status.hostIP
#      - name: CONSUL_PORT
#        value: '8500'
#  filebeat:
#    consulvar: |
#      - name: CONSUL_HOST
#        valueFrom:
#          fieldRef:
#            fieldPath: status.hostIP
#      - name: CONSUL_PORT
#        value: '8500'

custom-values-elk.yamlファイルを編集し、コメントを解除します。

# On split mode Uncomment and change to the appropriate port
#    consulvar: |
#      - name: CONSUL_HOST
#        valueFrom:
#          fieldRef:
#            fieldPath: status.hostIP
#      - name: CONSUL_PORT
#        value: '8500'
#  logstash:
#    cloudProvider: "local"
#    service:
#      type: NodePort
#      ports:
#         - name: beats
#           protocol: TCP
#           nodePort: 30500
#           port: 5000
#    consulvar: |
#      - name: CONSUL_HOST
#        valueFrom:
#          fieldRef:
#            fieldPath: status.hostIP
#      - name: CONSUL_PORT
#        value: '8500'

ポート

Portsの表から、Yes/Exclusiveと表示されているポートがすべて開かれていることを確認します。

7.13.5. 外部CDR名前付きポリシーをShieldにマッピングする方法

選定した CDR ソリューションが名前付きポリシーをサポートしている場合、Shield 内でこれらの名前付きポリシーを使用できます。

名前付きポリシーは、単一のルールにグループ化された一連の定義であり、CDR ソリューション(Shield の外部)で作成できます。このような名前付きポリシーが存在する場合は、それらを Shield にマッピングし、ドメイン、プロファイル、カテゴリなどに使用できます。Shield 管理コンソールで新しい名前付きポリシーを定義するには、以下の手順に従います:

「設定 | ファイル & サニタイズ」に移動します。

ドロップダウンリストから「File Sanitization Provider」(ファイルサニタイズプロバイダ)を選択します。

URL が正しく定義されていることを確認します。

「Named Policies」(名前付きポリシー)サブセクションを開きます。

../_images/howto_es2111_02.jpg

「Default」(デフォルト)として使用する名前付きポリシーを選択するか、新しい名前付きポリシーを追加します。

新しいポリシーを追加するには、テーブルの左上にある「Add Named Policy」(名前付きポリシーの追加)オプションを選択し、ダイアログに入力します。

../_images/howto_es2111_03.jpg

すべての詳細を入力した後、「Add」(追加)をクリックすると、新しい名前付きポリシーがテーブルに表示されます。

注意

Provider Named Policy の値は、外部 CDR ソリューションで定義されている名前付きポリシーと一致する必要があります。

名前付きポリシーの追加が完了した後、ポリシーテーブルに移動すると、新しく定義した名前付きサニタイズポリシーが「ダウンロード」ポリシーの値リストで使用できるようになります。

../_images/howto_es2111_04.jpg

ドメイン/カテゴリごとに、使用する名前付きポリシーを選択するか、デフォルト/上書きのダウンロードポリシー値を定義します。

「デフォルト」としてマークされた名前付きポリシーは、ダウンロードポリシーの「サニタイズ」オプションに使用される実際のポリシーです。この場合、ダウンロードポリシーが「サニタイズ」に設定されていると、「デフォルト」の名前付きポリシーが実際のサニタイズポリシーとして使用されます。つまり、サニタイズされたすべてのファイルは、プロバイダの名前付きポリシー(外部の CDR ソリューション)の定義に従ってサニタイズされます。

プロバイダの名前付きポリシーの Shield 内でのマッピングは、管理者ユーザが完全に責任を持つことになります。Shield は、プロバイダの名前付きポリシーを管理できず、定義の正確性に関する検証は実行されません。プロバイダの名前付きポリシーが正しくない場合の結果は不明です。CDR プロバイダによっては、サニタイズが失敗する場合や(適切なメッセージが表示されない場合もあります)、別の名前付きポリシーが使用される場合があります。名前付きポリシーを定義するときは、正しいプロバイダの名前付きポリシーをマッピングすることが最も重要です。

初期のデフォルトの名前付きポリシー(外部の名前付きのデフォルトポリシーにマッピングされている)は削除できません。さらに、(チェックボックスのマークで)デフォルトとして選択されている他の名前付きポリシーは削除できません。デフォルトとして定義されている名前付きポリシーを削除するには、最初に別の名前付きポリシーをデフォルトとして定義してから、名前付きポリシーを削除します。

名前付きポリシーテーブルのエントリを編集するには、目的のエントリをクリックします(シングルクリック)。行が編集可能になります。必要は変更をすべて完了したら、テーブル内の別の場所をクリックします。行が編集できなくなり、変更がコミットされます。

Sasa Gate Scanner を使用する場合、Provider Named Policy(プロバイダの名前付きポリシー)は、名前付きポリシーの ID と一致する数値である必要があります。

Opswat MetaDefenderを使用する場合、組み込みのデフォルトポリシーはありません。特定のルール（Opswat UIで作成）をマップする必要があります。デフォルトのエントリを編集し、[プロバイダー名付きポリシー]列で外部ルール名を設定します。

7.13.6. Shieldの状態を確認する方法

Shieldシステムのステータスを確認するには、Rancherを開き、クラスターに移動して[デフォルト]オプションを選択します。

../_images/howto_es2111_05.jpg

[ワークロード]の下に、すべてのネームスペースとそのデプロイメントが表示され、それぞれに視覚的なステータスインジケーターが表示されます（緑色のインジケーター=正常）。

../_images/howto_es2111_06.jpg

リストを状態で並べ替えて、異常な展開があるかどうかを簡単に確認することができます。

不健全な展開を修復する

展開が不健全な場合、視覚的なインジケーターの色はオレンジ/赤になります（問題の重大度によって異なります）。

この問題を修正するには、異常なデプロイメントを選択し、[再デプロイ]オプションを選択します。

このオプションが期待どおりに実行されない場合（いくつかの問題がまだ残っている場合）、次のことを試してください。

異常な展開を選択します。関連するポッドが表示され、それぞれに視覚的なステータスインジケータが表示されます。

異常なポッドを選択し、[削除]をクリックします。新しい健康的なポッドがすぐに作成されます。

不健全なコントローラーマネージャーとスケジューラ

ランチャーに異常なコントローラーマネージャーおよび/またはコントローラースケジューラに関するメッセージ/アラートが含まれている場合：

../_images/howto_es2111_07.jpg

一部のコンテナは待機モードになっている可能性がありますが、イベントやログはありません。この状況を解決するには、以下を使用してクラスター管理マシンを再起動します。

sudo reboot

Shield情報を収集する

Ericomサポートによるさらなる調査が必要な問題がある場合は、Shieldサポートサービスを使用して、出力をEricomに送信して処理してください。

このサービスを実行し、次の手順に従います。

sudo ./shield-support.sh

このサービスは、システム、Docker、Rancher、およびShieldに関する情報を収集し、これらすべての情報を含むzip形式のtarファイルを作成します。tarファイルは非表示の /tmpフォルダーの下にあります。

../_images/howto_es2111_08.jpg

このtarファイルをローカルにダウンロードして（たとえば、winSCPを使用して）、Ericom Shield ProfessionalServicesチームに送信します。

7.13.7. プロキシポートをカスタマイズする方法

Shieldプロキシに使用されるデフォルトのポートを変更することができます。これを行うには、custom-management.yamlファイルとcustom-proxy.yamlファイルを編集します。

customAuthProxyPortを参照している行のコメントを解除し、目的の値を入力します。

最終結果は次のようになります。

../_images/howto_es2111_09.jpg

冗長なスペース/タブを入力しないように注意してください。変更を保存します。

新しいプロキシポートを更新するため Shieldを再起動します。

7.13.8. ノードあたりのポッド数を増やす方法

Shieldシステムでは、各ノードは最大24コア（最大）である可能性があります。

ノードに16を超えるコアがある場合、デフォルトのポッド数（110）を増やす必要があります。

これを行うには、次の手順に従います。

Rancherを開き、更新するクラスターを選択します。

[ノード]をクリックし、[クラスターの編集]（右側）を選択します。

[YAMLとして編集]オプションを選択します。kubeletの下に追加：

extra_args：
  max-pods：200

ポッドの推奨最大数は200です。必要に応じて、より低い値を入力できます。

../_images/howto_es2111_10.jpg

「Save」(保存)をクリックします。クラスターはすぐに更新され、kubeletは更新されたポッド数で再起動します。

7.13.9. ネットワークの問題のトラブルシューティング

Ericom Shieldには、Webページの読み込み時間を測定するために使用されるPage LoadAnalyzerツールが含まれています。アナライザーの結果には、ブラウジングプロセスのさまざまなイベントと、各イベントの期間（クライアント側とサーバー側の両方で、各イベントが受信されるまでの時間）が含まれます。イベントは次のように実行および受信されます。

../_images/howto_es2111_11.jpg

注意

ほとんどの場合、これは一連のイベントです。それでも、これはイベントの配列であるため、順序は少し異なる場合があります（たとえば、ページが完全に読み込まれた後にdom readyイベントが受信されます）。これはアナライザーの結果に特別な影響を与えることはなく、無視してもかまいません。

アナライザーツールは、ページの読み込みに時間がかかりすぎる場合にネットワークの問題を特定するのに役立ち、これらの問題の根本的な原因を特定することもできます。

アナライザーの結果は、特定のWebページ、そのリソース、リダイレクト、ネットワークの状態などによって異なる場合があります。このページを使用して、リダイレクトを含まない一般的に使用されるURLを分析します。各リダイレクトには追加のイベントが含まれるため、結果は次のようになります。理解しにくい。2台の異なるエンドユーザーコンピューターからアナライザーを実行することをお勧めします。1台は適切なベースライン（パフォーマンスに関して）と見なされ、もう1台は低速またはパフォーマンスの問題があると見なされます。次に結果を比較します。

Page Load Analyzerを使用するには、Shieldブラウザーを開き、http://shield-perf/ 解析するURLを入力し、「Go」をクリックします。ページが解析された後、結果が表示されます。

../_images/howto_es2111_12.jpg

ページロードアナライザーの結果の読み取り

結果は2つのセグメントに分けることができます。プロキシを保護するためのローカルブラウザ（黄色）とインターネットへのリモートブラウザ（青色）。

  • プロキシを保護するローカルブラウザ

これは、最初の要求から始まり、WSが接続されたときに終了するプロセスの最初のセグメントです。以下のイベントが含まれます:

Client_domReady Shield サーバーページの HTML が読み込まれます
Client_mainFrameLoaded AccessNow HTML ページの読み込みが開始されます
Client_webSocketConnecting WebSocket が接続を確立しています
Client_webSocketConnected リモートブラウザへの WebSocket 接続が完了しました

このセグメントが遅い（合計時間が2秒を超える）場合は、次のいずれかのオプションが原因である可能性があります。

  • エンドユーザーブラウザとShieldプロキシ間の通信が遅い

通信を検査するユーザーとプロキシ、またはその他の検査ツールの間のローカルAVまたはローカルFWによって、大幅な速度低下が発生する場合があります。これが当てはまるかどうかを確認するには、プロキシに直接接続するブラウザを使用します（AV、FWなどを無効にします）。

  • DNS解決が遅い

プロキシはURLのDNS解決を行います。DNSが遅い場合、ページの読み込みが遅れる可能性があります。これは、管理コンソールのアナライザーツール（[サービス] | [アナライザー]の下）でテストできます。内部DNSサーバーによって速度が低下する場合は、googleなどの他のDNSを設定してみてください。

  • カテゴリの検出が遅い（システムでカテゴリが有効になっている場合）

プロキシは、URLごとに適切なカテゴリを取得するためのリクエストを行う。この通信が遅いと、ページの読み込みが遅くなります。これが事実かどうかを確認するには、http://shield-cat/ のページを使用して、カテゴリを取得するのにかかるクエリ時間をチェックしてください。ほとんどの場合、300ms未満であるはずです。

../_images/howto_es2111_13.jpg
  • インターネットへのリモートブラウザ

2番目のセグメントは、リモートブラウザとインターネットの間にあります。以下のイベントが含まれます:

ポリシー情報を取得し、URLに移動する 両方のイベントは、リモートブラウザがWebページを初めてレンダリングするときに受信されます
Client_firstImageRecieved リモートページに初期画像が表示されます
Client_domReadyEventReceived リモートブラウザがDomReadyイベントを取得しました
Client_mainFrameLoadedEventReceived すべてのページリソースを受け取ったとき
Shieldサーバーページが完全にロードされました ページが完全に読み込まれます

このセグメントが遅い（合計時間が10秒を超える）場合は、次のいずれかのオプションが原因である可能性があります。

  • リモートブラウザとインターネット間の通信が遅い

これは、アクティブなSSL検査またはファイアウォールがある場合に、Shield外部プロキシまたはカスタマーネットワーク機器に問題があることを示している可能性があります。

  • 追加

広告の影響により、ページの読み込みが遅くなることがあります（最大で30%〜50%程度遅くなります）。これを避けるには、広告ブロックサービスが有効になっていることを確認してください。

  • ブラウザノードのCPU使用率が高い

ブラウザノードのリソースが使い果たされると、ページの読み込みが遅くなります。 この場合は、ブラウザノードのメモリとCPUの制限を増やすことを検討してください。詳細については、EricomShieldプロフェッショナルサービスチームにお問い合わせください。

  • 遅い外部DNSサーバー

Kibana - Connections Info Report

上記のイベントはShieldで監視および記録され、Kibanaログでアクセスできます。

Kibanaに移動し、メインメニューで[検出]を選択します。connectioninfo- *を検索します。関連する時間枠が表示されていることを確認してください。

../_images/howto_es2111_14.jpg

結果の各エントリは、完了したブラウジングセッションを表します。目的のエントリを選択して展開します。入手可能な情報は次のとおりです。

../_images/howto_es2111_15.jpg

注意

さまざまなイベントの色は、アナライザーの結果の関連するセグメントに従ってマークされています。

たとえば、このレポートを使用して、接続速度の低下やマシンの速度低下を検出できます（構成が正しくないため）。接続が遅いことを示す特定の期間/間隔フィールドで結果をフィルタリングします。

たとえば、2500より大きいfirstImageSentTime.numeric（読み込みが遅いことを示します）に従って、特定のclientIPを使用して結果をフィルタリングします。結果は、どのマシンが低速で、問題のある構成になっている可能性があるかを示します。

7.13.10. ランチャーでクラスター監視ツールを使用する方法

GrafanaとPrometheusは、Rancherに含まれている組み込みツールであり、ノードの監視、保存、および時系列データの視覚化に使用されます。

Prometheusは、特定の頻度でデータを照会し、その情報をエクスポーターから取得するツールです。Prometheusは、その情報を保存するデータベースでもあります。

Grafanaは、Prometheusに接続された視覚化ツールであり、保存された情報を視覚的に表示します。

デスクトップとパネルを使用して、複数のビューを使用できます。Grafanaにデフォルトで含まれている視覚化パネルとは別に、必要に応じて、ユーザーが新しいパネル/デスクトップを作成できます。

デベロッパーツールを有効にする

インストールプロセス中に以下の監視ツールを有効にすることをお勧めします。

監視ツールを有効にするには、[クラスター] | [クラスター]に移動します。ツール|モニタリング：

../_images/howto_es2111_16.jpg

必要に応じてデータ保持値を設定します（最大72時間推奨）。Add Selectorを選択し、次のキーを追加します。shield-role/ farm-services = acceptを使用して、監視関連のワークロードがスケジュールされるノードを選択します。

../_images/howto_es2111_17.jpg

下にスクロールして有効にします。

注意

PrometheusとGrafanaにはいくつかのリソースが必要です。Shieldの公式要件は、これらのリソースに対応できます。

有効にすると、追加のメトリックが（緑色で）表示され、オレンジ色のアイコンはGrafanaから実装された追加の視覚化を示します。

../_images/howto_es2111_18.jpg

特定のノードを監視する

特定のノードが誤動作しているか、CPU/メモリの使用量が不規則な場合は、Grafana モニタリングを使用して根本原因を調査することができます。

クラスターに移動|ノード|特定のノード|ノードメトリクス

../_images/howto_es2111_19.jpg

展開された領域には、CPUとメモリの使用率、ディスクI / O、ネットワークI / Oなど、時間の経過に伴うすべてのグラフが表示されます。時間枠は、右側のドロップダウンで選択できます。Grafanaから収集された情報によると、これらのグラフ（最も一般的に使用されるグラフ）はRancherによって実装されています。

../_images/howto_es2111_20.jpg

詳細情報と追加の視覚化から、Grafanaに移動します。Grafanaアイコン（オレンジ、右上）を選択すると、関連するGrafanaダッシュボードで新しいタブが開きます。左上の選択を使用してクラスター、ノード、ポッド、コンポーネントなどの間を移動し、右上の選択ボックスを使用して時間範囲を選択することができます。

../_images/howto_es2111_21.jpg

Grafana デスクトップ

情報はそのままGrafanaで見ることができますが、多くのアクションはサインインした後でのみ許可されます - 左下、デフォルトの認証情報はadmin/adminです。

サインインすると、新しいパネルとデスクトップを作成することができます（デフォルトのパネルに一致するパネルがない場合）。さらに、パネルのデータをエクスポートすることができ、デスクトップの構造（データではない）をエクスポートすることができ、また、追加のアクションが利用可能です。

特定のパネルをCSVにエクスポート

誤動作しているノードの調査中に、Grafanaで不規則なデータが見つかった場合、このデータをCSVにエクスポートし、Ericom Shield ProfessionalServicesに送信してさらに調査することができます。

データのエクスポートは、単一のパネルごとにのみ実行されます。このオプションは、デスクトップごとには使用できません。

パネルをCSVにエクスポートするには、次の手順に従います。

特定のパネル/グラフを選択し、パネル名を選択します|詳細| CSVのエクスポート：

../_images/howto_es2111_22.jpg

モード、時間形式、およびExcelCSV方言を次のように変更します。

../_images/howto_es2111_23.jpg

[エクスポート]を選択します。CSV ファイルがローカルにダウンロードされます。今後の調査のために、このファイルをEricomに送信してください。

7.13.11. 特定のShieldバージョンをインストールする方法

Shieldの特定のバージョンをインストールすることが可能です。

利用可能なバージョンを見つけるには、次のコマンドを実行します。

./install-shield.sh -r

特定のバージョンをインストールするには：

sudo ./install-shield.sh -l -p <PASSWORD> -v <version-name>

バージョン名の形式は次のとおりです。Rel-yy.mm.xxx（例：Rel-20.07.667）。

7.13.12. 複数の認証コンポーネントを使用してシステムを構成する方法

ユーザーを認証するための複数の方法を含むシステムでは、例えば、

  • プロキシやセキュアゲートウェイなどの予備コンポーネント（Shieldシステム外）
  • 内部ActiveDirectory（Shieldシステム内）またはSAMLIdP

認証チェーンとLDAP認証方式の両方を定義して使用することが可能です

このシナリオでの認証フローの例：

  • ユーザーがShieldから外部コンポーネントに接続する（例：squidプロキシ）
  • プロキシルールに従って、ユーザーは認証されている（または認証されていない）
  • プロキシは、認証されたユーザー名（存在する場合）を使用してX-Authenticated-Userヘッダーを作成します
  • Shieldは、プロファイルベースのルールのヘッダーのユーザー名を使用します。ユーザー名が空/欠落している場合-使用されるプロファイルは「すべて」になります。

参考

このシナリオでは、Shieldは実際の認証を実行せず、ユーザー認証をX-Authenticated-Userヘッダーのみに依存します。

7.13.13. 未登録ノードの処理方法

Shieldのインストールまたはアップグレード中に、ノードが正しく登録されていない場合（Rancherに赤い「未登録」ステータスで表示されます）、IPv6が無効になっていることが原因である可能性があります。これは、ノードKubeletログを確認することで確認できます。

ノードマシンで、次のように入力します。

Code block labellanguagesudo docker ps | grep kubelet

コンテナ ID をコピーして、以下を実行します。

Code block labellanguagesudo docker logs <container-id>

以下のメッセージを検索します: 「アドレスファミリはサポートされていません」。このメッセージがログに表示される場合、実際の根本的な原因は、このノードで Ipv6 が無効になっていることです。

この問題を解決するには、次の手順に従います:

  • /etc/default/grub にあるGRUBファイルを編集します
  • 次の行を置換します:
Code block labellanguageGRUB_CMDLINE_LINUX="ipv6.disable=1"
  • 置換後：
Code block labellanguageGRUB_CMDLINE_LINUX=""
  • ファイルを保存して次を実行します:
Code block labellanguagesudo update-grub2
  • 再起動します。

GRUB で Ipv6 がすでに無効になっている場合は、sysctl を使用してみてください。以下を実行します:

Code block labellanguagesudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=0

これで、ノードが期待どおりに機能するはずです。

登録されていないすべてのノードに対してこれを繰り返します。

7.13.14. 追加の問題に対処する方法

以下は、Shieldの使用中に発生する可能性のある追加の問題の説明と回避策です。

ビデオ関連の問題

Shieldには2つのメディアストリーミングオプションがあります（メディアポリシーで定義されています）-ストリームとフレーム。

ビデオがShieldでストリーミングされると（メディアポリシーがStreamに設定されている）、ビデオフレームに特別なビデオプレーヤーが表示され、ビデオはShieldを介して直接ストリーミングされるため、パフォーマンスが向上し、リソースが削減されます。このプレーヤーの表示は、サイト固有のプレーヤーとは多少異なります。

たとえば、youtube.comでは、これは特定のプレーヤーです。

../_images/howto_es2111_24.jpg

そして、これはShieldの特別なプレーヤーです：

../_images/howto_es2111_25.jpg

（ストリームモードで）ビデオを再生しているときに、ビデオフレームがページ内の他の要素（メニューなど）に重なって、バックグラウンドで表示されることがあります。

フラッシュ埋め込みビデオは、Shieldではサポートされていません。回避策は、関連する元のサイトでビデオを開くことです。

読み込みが遅いサイト

一部のサイトとセキュリティサービス（例：google reCAPTCHA）は、クラウドIPアドレスからのブラウジングを識別する際に厳しいものになります。その結果、Shieldがクラウドにデプロイされ、ブラウザのIPアドレスがクラウドで生成された場合、一部のサイトの読み込みに時間がかかる場合があります。さらに、一部のセキュリティサービスは、それが実際に人間のユーザーであることを確認するために、より厳格な方法で動作する場合があります（たとえば、より複雑な質問を提示する）。

Shield から Office2010/2013 への画像の貼り付け

Shieldから画像をコピーしてOffice2010 / 2013アプリケーションに貼り付けると、期待どおりに機能せず、画像が正しく貼り付けられない場合があります。これを解決するには、以下の手順で画像をペースとします:

「形式を選択して貼り付け」オプションを選択します。

../_images/howto_es2111_26.jpg

「デバイスに依存しないビットマップ」を選択し、「OK」をクリックします。

../_images/howto_es2111_27.jpg

これにより、期待どおりに画像がペーストされます。

Firefoxでの貼り付け

FirefoxでShieldを使用してブラウジングする場合、貼り付けの右クリックオプションは機能しません。これは、Firefoxが非同期クリップボードをサポートしていないため、Firefoxの制限によるものです。

Firefoxに貼り付けるには、CTRLVオプションを使用します。

クリスタルレンダリングモード

このポリシーを選択すると、ChromeおよびEdge（バージョン79、クロムベース）での閲覧中に利用できます。他のブラウザを使用すると、レンダリングは自動的にストリームレンダリングに戻ります（シームレスな方法で）。

このモードを使用すると、一部のサイトで特定の問題が発生する場合があります。Ericom Shieldは常にこれらの問題を改善するために機能しますが、それでもいくつかの制限が発生する可能性があります。たとえば、期待どおりに機能しないメニュー、Crystalモードでサポートされていない特定のWebコンポーネントなど。

ブラウザメニュー-検索

ChromeおよびEdgeブラウザーでは、メニュー|検索オプションはサポートされていません。CTRLFを使用する必要があります。

印刷中のスケール

Chromeでは、Shieldを介して印刷する場合、セキュリティで保護されていないブラウジングとはスケーリングの動作が異なります。縮尺を変更すると、各ページに個別に影響します（ページ内の情報に関係なく）。これにより、印刷ページに空白が残る場合（> 100％の場合）、または部分的な情報のみが含まれる場合（<100％の場合）があります。ベストプラクティスは、[ページに合わせる]オプションを使用して印刷することです。

クロスオリジンIframeを含むサイトの印刷

Webサイトにクロスオリジンiframe（異なるサイトで作成されたiframe）が含まれている場合、Webページのコンテンツを印刷するときにこれらのiframeを含めることはできません。同じドメインで作成されたiframeのみが印刷に含まれます。これは電子10の制限です。

ホワイトリストに登録されたドメインとSAML認証

SAMLが有効になっているシステムで、ホワイトリストに登録されたドメインを参照すると、外部オブジェクトが期待どおりに読み込まれません。これはブラウザの制約によるものです。

考えられる回避策は、ホワイトリストに登録されたドメインの外部オブジェクト（[管理] | [設定] | [コンテンツの分離]の下）を[絶対ホワイト]に設定することです。これにより、すべてのページリソースもホワイトリストに登録され、SAMLに関連する競合は発生しません。

オートコンプリート

一部の入力フィールドでは、過去の入力に基づいて、ブラウザにいくつかの内容が提案あれます。これにより、ユーザーは数文字の入力を開始した後に、オプションから1つを選択し、入力を自動補完できます。特定のブラウザベースのアルゴリズムによるため、これは Shield で常にサポートされているわけではありません。その場合は、必要な入力テキストを入力してください。

WebGL

WebGLは、主に 3D グラフィック要素に使用されるコンポーネントであり、ほとんど使用されることはありません。これは現在のところ、Shield ではサポートされていません。

動的(クラウド)ブラウザファームでの内部サイトの使用

ブラウザのファームが動的である場合（クラウドにデプロイされている場合）、内部Webサイトにアクセスできません。これは、これらのサイトとクラウドの間に接続がないためです。このシナリオで内部サイトへのアクセスを有効にするには、PACファイルで内部サイトを除外するか、ポリシーテーブルでそれらをホワイトリストに登録します。

認証のないシステムでのセッション数の制限

Shieldには、ユーザーあたりのデフォルトの最大セッション数が付属しています（[管理]、[リソース]、[リソースの保護]で定義された[ユーザーあたりの最大アクティブリモートセッション]）。特定の認証がないシステムでは、ユーザーはシステムによって自動的に生成されたブラウザーGUIDで識別されます。ユーザーは個人の資格情報によって識別されないため、セッションの数は自動的に強制されません。

身元不明のユーザーにこの設定を適用するには、次の手順に従います。

Rancher Serverマシンで、custom-proxy.yamlファイルを編集します-次の2行のコメントを解除します（＃を削除します）。

# shield-proxy:
# checkSessionLimit: true

変更を保存してShieldを起動し、次のコマンドを実行します。

./start.sh

注意

yamlファイルを編集するときは、冗長な文字（空白、タブなど）を避けることが重要です。また、このファイルをバックアップすることをお勧めします。

Ubuntu16.04でKubernetesを実行する

Shieldに推奨されるシステムは、Ubuntu18.04のデフォルトインストールです。Ubuntu 16.04システムを使用する場合、Kubernetesを正常に実行するには、OSを最新のアップデートで完全にアップデートし、すべての組み込みパッケージを含める必要があります。これを行うには、（Rancherをインストールする前に）次の手順に従います。

sudo apt update
sudo apt upgrade
reboot
sudo apt autoremove

また、ホストサーバーのUbuntu Security Automatic UpdatesをONにすることをお勧めします。

7.13.15. エンドユーザインジケータを変更する方法

[エンドユーザーShieldの許可]インジケーターが[はい]に設定されている場合（[設定] | [エンドユーザーオプション]で）、各リモートブラウザータブには、ドメイン名に追加されたデフォルトのインジケーター（⭐）が含まれます。

../_images/howto_es2111_28.jpg

このデフォルトのインジケーターをカスタマイズするには、次の手順に従います。

翻訳セクションに移動します

文字列STR_END_USER_INDICATORを検索します

文字列を目的の値に更新します（文字またはサポートされているアイコン/絵文字の組み合わせにすることができます）。

必ず短い文字列を使用してください（より便利です）。最後に空白を残します（ドメイン名がShieldインジケーターから分離されるようにします）。

この例では、デフォルトのインジケーターが[砂時計]に変更されました。

../_images/howto_es2111_29.jpg

7.13.16. 高可用性クラスターを設定する方法

ランチャークラスターを使用してShieldシステムをセットアップし、高可用性を実現するには、以下の手順に従ってください。

ノードを準備する

HA クラスターに必要なノードの数は、以下の追加ノードを備えた Shield サーバーの数(目的の展開ごと)となります。

  • 管理ワークステーション用の 1 ノード
  • ランチャークラスターへのゲートウェイとして機能する負荷分散プロキシ用の 2つのノード。

注意

追加の LB ノードを使用できますが、HA には 最低限 2つの LB ノードが必要です。

<Total#ofNodes> = <#ofShieldServers> + <2LBServers> + <1AdminWS>

例えば、 RancherHAを備えた5ノード（3マネージャー、2ブラウザーファーム）のShieldシステムには、8ノードが必要です。

注意

推奨される展開については、Shield アーキテクチャのページを参照してください。

  • ソフトウェア要件
    • Linux Ubuntu Server 18.04 (64ビット。非ワークステーション)。
    • 固定IPアドレスがあること
    • 一意のホスト名がある
    • 他のノードと同じユーザ<USER>とパスワードを持っている
    • (システム内の他のマシンと)同じタイムゾーンが設定されている
    • SSH サーバーがインストールされている

Shieldノードはこれらの要件を備えている必要があります。その他のノード（LBと管理者用ワークステーション）は、最低限のメモリとCPUリソースを確保する必要があります。

このシステム用に、ローカルでアクセス可能な DNS サーバーが存在することを確認してください。

管理ワークステーションを構成する

WS にssh-keygen および ssh-copy-id プログラムがあり、Docker がインストールされていることを確認してください。

sudo apt updatedsudo apt install docker.io

Shield リポジトリを WS に複製します:

id="$(docker create securebrowsing/es-shield-cli:Rel-20.05.648)"
docker cp "$id:/home/ericom/ericomshield" .
docker cp "$id:/usr/bin/kubectl" /usr/local/bin/
docker cp "$id:/usr/bin/helm" /usr/local/bin/
docker cp "$id:/usr/bin/rancher" /usr/local/bin/
docker rm -v "$id"

RKE をインストールします:

curl -sLO https://github.com/rancher/rke/releases/download/v1.0.6/rke_linux-amd64
chmod +x rke_linux_amd64

すべてのノードにDockerをインストールします（shield-prepare-serversを使用）。

./shield-prepare-servers [-u <USER>] <ServerIPAddress(s)>

USERを、すべてのノードに一致するユーザーに置き換えます。ServerIPAddress（s）を、システム内のすべてのノードのIPアドレスのリストに置き換えます。 スペース（ 「」）で区切って、複数のIPアドレスを入力できます。

WSからUSERアカウントで、SSH公開鍵を使ってすべてのノードにSSHでアクセスできることを確認します。以下のコマンドを実行して、鍵ペアを生成し、全ノードに公開鍵を配布してください（各ノードで個別に行う必要があります）。

ssh-keygen
ssh-copy-id <ServerIPAddress1>
ssh-copy-id <ServerIPAddress2>
ssh-copy-id <ServerIPAddress3>

キーペアがデフォルトのパスに配置されていない場合は、rancher-cluster.ymlにパスパラメーターを次のように追加します。

ssh_key_path: <path>/id_rsa
  • DNS

LBノードを指すようにDNSサーバーにFQDNレコードを作成します。システム内のすべてのLBノードを指す単一のレコード。共通ファイルを編集します-RANCHER_LB_HOSTNAMEをFQDNレコードに設定します

  • 証明書

既存のCA証明書（または証明書のチェーン）を使用するには、〜/ Shield / Kube / scriptsに移動し、cacerts.pemとして保存します。

さらに、FQDNレコードのサーバー証明書を生成し、一致する秘密鍵とともに、それぞれcert.crtおよびcert.keyという名前で同じディレクトリに保存します。

既存のCA証明書がない場合は、Rancherクラスターで使用する新しいCA証明書と新しいサーバー証明書（およびそれぞれに対応するキー）を作成し、次のコマンドを実行します。

cd RKE/
./generate_ca.sh    (creates a new CA certificate & key)
./generate_cert.sh  (creates a new server certificate & key)
  • 構成ファイル

システム全体の構成は、rancher-cluster.ymlファイルで定義されています。このファイルは、システム構成を含むように編集され、後でそれを展開するために使用されます。

LBノードはsystem-role / ingress-rancherでマークされています。ラベルを受け入れます。各LBノードの関連セクションをコピーします。例えば。 2ノードの場合、ファイルには次のものが含まれている必要があります。

../_images/howto_es2111_30.jpg

ユーザーを更新します。USER-上記のユーザーを使用します。

ShieldManagerノードは次の役割でマークされています。[controlplane、worker、etcd]。

ワーカーノードは役割でマークされています：[ワーカー]。

システム内のすべてのShieldノードへの参照を含めるようにファイルを変更します。計画されたShield展開に従って、各ノードごとにラベル/Shieldの役割（管理、プロキシ、エルク、ファームサービス、リモートブラウザなど）を一致させます。例:

../_images/howto_es2111_31.jpg

kubernetes_versionをv1.17.4-rancher1-2に変更します。

ユーザーが複数のネットワークインターフェイスカードを備えたサーバーを使用している場合は、ローカルネットワークでの通信に使用されたインターフェイス名をflannel_iface（ネットワーク/オプションの下）で指定する必要があります。

../_images/howto_es2111_32.jpg

変更を保存します。

  • ランチャーをデプロイする

ランチャークラスターを構築してデプロイします。次のコマンドをこの順序で実行し、各コマンドが完了するのを待ってから次のコマンドに進みます。

./0_rke_up.sh
./1_install_tiller.sh
./2_deploy_rancher.sh

致命的なエラーがないことを確認し、Rancherが正常にデプロイされるのを待ちます。

参考

特定のエラーが表示される場合があります。 「サーバーからのエラー（NotFound）：シークレット「tls-ca」が見つかりません」。これらは無視してかまいません。

Rancher UIを開きます-ブラウザでhttps：// <RANCHER_LB_HOSTNAME>：8443にアクセスします。指示に従います（パスワードの設定など）。Rancherがエラーなしで動作し、ローカルクラスターがインポートされ、エラーなしで機能することを確認します（準備が整うまでに少し時間がかかる場合があります）。

設定ファイルを適切な場所（/.kube以下）にコピーします。

cp kube_config_rancher-cluster.yml ~/.kube/config
  • Shield を展開する

通常の Shield のインストール手順に進み、以下を実行します。

./install-shield.sh -p <password>

Rancherで、名前空間をデフォルトプロジェクトの下に移動します。

ShieldがRancherHAとともにインストールされました。

既存のクラスターを更新する

既存の実行中のクラスターを更新するには（たとえば、新しいRancherバージョンがリリースされた場合、または追加のノードをShieldシステムに追加する必要がある場合）、必要に応じてrancher-cluster.ymlを変更し、保存して実行します。

./0_rke_up.sh

これで、新しい構成がクラスタに適用され、クラスタが更新されます。

7.13.17. 非 HA システムの潜在的な問題

単一の管理ノード（非HAシステムと見なされる）を含むShieldシステムでは、Rancherサーバー（管理ノード上にある）がダウンした場合にサービスの低下が発生する可能性があります。

単一のRancherサーバーがあるため、サーバーがダウンしている場合、システムで次の1つ以上の問題が発生する可能性があります。

  • 新しいブラウザは作成されません
  • このノードで実行されているすべてのコンテナーは、ランチャーサーバーが復旧するまで使用できません。これは、管理コンソールやShieldバックアップ機能などに影響を与える可能性があります

これらのシナリオは、非HAシステムの制限と見なされ、システムの展開を計画する際に考慮に入れる必要があります。

7.13.18. SSH キーを設定する方法

SSH キーを使用する方がはるかに安全です。ほとんどのクラウドプロバイダーはSSHキーを使用しています。つまり、証明書（公開キーと秘密キーを含む）を使用してマシンに接続しています。Shieldは、証明書を使用した接続をサポートしています。証明書を使用した接続を有効にするには、証明書（公開鍵と秘密鍵）を作成し、接続しようとしているマシンに公開鍵をコピーします。

SSH公開鍵と秘密鍵を作成する

ユーザ ericomとして実行します(または他のユーザい。ただし root でないことを確認してください):

sudo ssh-keygen -t rsa

キーを保存するファイル名を入力します（例：./ shield.pem）

パスフレーズ（セキュリティを強化するための証明書のパスワード）を入力します。オプション。パスフレーズがない場合は空のままにします)。

2つのファイルが作成されます。例：shield.pem.pub（公開鍵）およびshield.pem（秘密鍵）。ファイル内でユーザー名が期待どおりであることを確認します（rootではありません）。

公開鍵をターゲットマシンにコピーする

ターゲットマシンのルートに、.sshという名前のフォルダーが存在することを確認します。そのようなフォルダがない場合は作成してください。

公開鍵をauthorized_keysという名前のファイルにコピーし、.sshフォルダーに配置します。

以下を使用してターゲットマシンにログインします:

ssh -I shield username@IPAddress

パスワードが不要であること、.sshフォルダーが存在すること、およびそのフォルダーにauthorized_keysファイルが含まれていることを確認します。

パスフレーズが定義されている場合は、パスフレーズを入力してログインします。

7.13.19. 組み込みのCDRソリューションで高度な機能を構成する方法

ログレベルを変更する

CDR ソリューションのログレベルを変更することが可能です。デフォルトのログレベルはデバッグです。

そのためには、CDRサーバーの以下のパスに移動してください。

C:\Program Files\Votiro\SDS Web Service\Config

すべてのログ設定はこのファイルで定義され（LogLevel、MaxFileSize、NumberOfBackupsなど）、更新できます。

これらの設定は、各サニタイズノードに対して有効です。同じことがAPIログとSNMCログにも当てはまります。

logs.xmlの設定を更新した後、CDRサーバーでSNMCおよびAPIサービスを再起動する必要があります。

使用するアンチウイルスを定義する

v8.3では、AVライセンスがある場合、3つのAVエンジンが使用可能です。ESET、Avira、Windows Defenderです。デフォルトでは、これらのすべてが連続的に使用されます。手動で使用するAVエンジンを定義するには、C:\Program Files\Votiro\Votiro.Malware.ScannerConfigscanner.xml に移動して、不要なアンチウイルスエンジンを false に設定します。

IsActivated="false"

HTTPS(SSL)を有効にする

SSL 証明書は、ブラウザとサーバ間の安全な暗号化接続を確立するために使用されます。SSL 証明書は、HTTPS を使用して CDR に接続するサーバとすべてのブラウザにインストールする必要があります。ファイルmakecert.exeを使用するには、CDRサーバーに対する管理者権限とWindowsSDKへのアクセス権が必要です。このプロセスには、SSL証明書の生成とインストールが含まれます。すでにSSL証明書をお持ちの場合は、手順2に進んでください。

CDRサーバーに証明書を作成してインストールします。

次のコマンドを発行して、ROOT 証明書を作成します:

makecert.exe -sk RootCA -sky signature -pe -n CN=<MachineHostName> -r -sr LocalMachine -ss Root <RootCertName>.cer

サーバー証明書を作成します:

makecert.exe -sk server -sky exchange -pe-n CN=<CDRServerIpAddress> -ir LocalMachine -isRoot -ic <RootCertName>.cer -sr LocalMachine -ss My <CertName>.cer

Windows証明書リストを参照し、個人パスの下に新しい有効な証明書が存在することを確認します。

サーバー証明書の拇印を[詳細]> [拇印]にコピーします。

サーバー証明書をSSLポートにバインドします（デフォルト：443）次のコマンドを使用します。

netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid={b6445322-3509-4d0f-8b4b-0a12eeadaed0}

Votiro.Sanitization.APIおよびVotiro.SNMCWindowsサービスを再起動します。

https://CDRServerIPAddress/SDSService/v3 を参照してください。証明書の警告や検証の問題がないことを確認します。

ビッグファイルをダウンロード

Shieldの組み込みCDRソリューションでは、ファイルサイズに既知の制約があります。サニタイズに許可される最大サイズは2.1GBです。

より大きなファイルを許可するには、次の手順を実行します。

    1. C:\Program Files\Votiro\SDS Web Service に移動します。
    1. SdsApiService.exe.config ファイルを編集し、WEBHttpBinding_ISdsWebService と WEBSecureHttpBinding_ISdsWebService の maxReceivedMessageSize を希望のサイズ（バイト単位）に増加します。
    1. C:\Program Files\Votiro\SDS Web Service\config に移動します。
    1. SystemSettings に MaxInProcessSizeInBytes=」5368709120」 を追加し、手順 2 で入力したサイズと同じにします。
    1. Votiro.Sanitization.API と Votiro.SNMC.Web サービスの両方を再起動します。

ユーザーに表示されるメッセージを更新する

アーカイブされたフォルダーの場合、含まれているファイルが（CDRプロセスによって）ブロックされると、それらはpdfドキュメントに置き換えられ、アイテムがブロックされたことをユーザーに通知します。CDRサーバーにある辞書テンプレートを更新することにより、ユーザーに表示されるメッセージを変更することができます。

辞書のテンプレートは、C:\Program files\Votiro\SDS Web ServiceTemplatesBlocked にあります。

辞書のテンプレートを更新した後、SNMCおよびAPIサービスをCDRサーバで再起動する必要があります。

7.13.20. 既存のクラスターにノードを追加する方法

すでに本番環境にある既存のShieldクラスターにノードを追加するには、次の手順に従います。

ランチャーサーバーに移動し、以下を使用して新しいノードを準備します。

./shield-prepare-servers [-u <USER>] <ServerIPAddress(s)>

USERを、すべてのノードに一致するユーザーに置き換えます。ServerIPAddress（s）を新しいノードのIPアドレスのリストに置き換えます。

既存のクラスタにノードを参加させ、ラベルを設定し、Shieldを再起動します。

これで、クラスターが新しいノードで更新されます。

堅牢なHA

マルチマシンシステムでは、真の堅牢な高可用性を確保するために、領事館のコンポーネントを明示的に再シャッフルする必要があります

ノード間。これを行うには、一致するyamlファイルを更新します。

たとえば、ラベルがManagementのノードが3つある場合は、custom-management.yamlを更新します。

または、farm-servicesというラベルの付いたノードが3つある場合は、custom-farm.yamlを更新します

ファイルを編集します-次の行のコメントを解除します（＃を削除します）。

# antiAffinity: hard
../_images/howto_es2111_33.jpg

Shieldを停止して再起動し（必要に応じて、特定の名前空間に-nオプションを使用）、変更を適用し、ノード間で領事サービスを再シャッフルします。

7.13.21. アップストリームプロキシを構成する方法

インターネットアクセスがアップストリームプロキシを介してのみ利用できる環境では、すべてのShieldマシンがアップストリームプロキシで動作するように構成する必要があります。次の手順に従って、関連するサービスを取得して実行します。

まず、システムで使用されているPhytonを確認します。

python --version
../_images/howto_es2111_34.jpg

Pythonが存在しない場合-Python2をインストールします（最小）：

apt install python-minimal

Python 2を使用する場合-proxy.pyファイルを取得します：

sudo wget https://raw.githubusercontent.com/EricomSoftwareLtd/Shield/master/Utils/proxy.py
sudo chmod +x proxy.py
sudo ./proxy.py

Phyton 3を使用している場合は、proxy3.pyを取得します。

sudo wget https://raw.githubusercontent.com/EricomSoftwareLtd/Shield/master/Utils/proxy3.py
sudo chmod +x proxy3.py
sudo ./proxy3.py
../_images/howto_es2111_35.jpg

次に、[プロキシの設定]オプション（＃1）を選択し、次のプロキシの詳細を入力します（プロンプトが表示されたら）。IPアドレス、ポート、ユーザー名、パスワード（定義されている場合はスキップ）

7.13.22. Dockerログのサイズを変更する方法

Dockerコンテナのログは大きくなり、大量のディスクを消費する可能性があります。ログファイルに制限を設定することをお勧めします。

これを行うには、/etc/docker/ に移動し、log-driverキーとlog-optsキーを設定します。

次の例では、ログドライバーをjson-fileに設定し、max-sizeオプションとmax-fileオプションを設定します。この場合に使用されるディスクの合計は、50MB（5 * 10m）を超えません。

"log-driver": "json-file",
"log-opts":
{
  "max-size": "10m",
  "max-file": "5"
}

必要に応じて、max-sizeとmax-fileを変更します。

参考

OVAを使用してShieldをインストールする場合、これらの値はすでに事前定義されているため、これをスキップできます。

7.13.23. ドメインリスト

ドメインを参照する場合、元のドメインに到達して開くまで、途中で他のドメインにリダイレクトされることがよくあります。これは、ページ内にさまざまなリソースが含まれているWebサイトでも発生する可能性があります。

ドメインがShieldされているが、そのリダイレクト/リソースがホワイトリストに登録されている場合、このドメインの参照は失敗し、ページが正しく読み込まれない可能性があります（場合によってはまったく読み込まれません）。元のドメインがホワイトリストに登録され、リダイレクト/リソースの1つがShieldされている場合も、同じ結果が発生する可能性があります。

特定のドメインがShieldまたはShield内のホワイトリストとして適切に機能するためには、追加のドメインもポリシーテーブルで定義する必要があります（同じアクセスポリシー値を使用）。

使用頻度の高いドメイン

以下は、頻繁に使用されるドメインとそれらの追加の関連ドメインの詳細なリストです。元のドメイン（タイトル内）が[ポリシー]テーブルに追加されたら、関連するすべてのドメインも含める必要があります。

参考

これらのドメインをポリシーテーブルに追加するときは、キャッシュをクリアし、更新が有効になるまで数分待ってください。

  • Amazon

    • ssl-images-amazon.com

  • Dropbox

    • db.tt
    • dropbox.com
    • dropboxapi.com
    • dropboxbusiness.com
    • dropboxforums.com
    • dropboxforum.com
    • dropboxinsiders.com
    • dropboxmail.com
    • dropboxpartners.com
    • dropboxstatic.com
    • dropbox.zendesk.com
    • getdropbox.com
    • instructorledlearning.dropboxbusiness.com
    • paper.dropbox.com

  • Ebay

    • ebaystatic.com
    • ebayimg.com
    • ebayrtm.com

  • Facebook

    • s-static.ak.facebook.com
    • static.ak.facebook.com
    • graph.facebook.com
    • upload.facebook.com
    • chat.facebook.com
    • apps.facebook.com
    • channel.facebook.com
    • pixel.facebook.com
    • star.facebook.com
    • star.c10r.facebook.com
    • vupload2.facebook.com
    • vupload2.t.facebook.com
    • b-api.facebook.com
    • fbcdn.net
    • fbsbx.com

  • Google Chat

    • xmpp-server.l.google.com
    • chatenabled.mail.google.com
    • talkgadget.google.com
    • talk.google.com
    • talks.l.google.com

  • Google Talk

    • talkx.l.google.com
    • talk.l.google.com
    • talk.google.com

  • Google Drive

    • www.google.com
    • accounts.google.com
    • clients3.google.com
    • talk.google.com
    • drive.google.com
    • www.googleapis.com
    • ssl.gstatic.com
    • docs.google.com
    • drive.google.com
    • googleusercontent.com
    • s.ytimg.com
    • video.google.com
    • lh3.google.com
    • lh4.google.com
    • lh5.google.com
    • lh6.google.com

  • iTunes

    • itunes.apple.com
    • ax.itunes.apple.com
    • ax.init.itunes.apple.com
    • albert.apple.com
    • gs.apple.com
    • phobos.apple.com
    • mzstatic.com
    • akamai.net

  • LinkedIn

    • edge.quantserve.com
    • secure-us.imrworldwide.com
    • b.scorecardresearch.com
    • pixel.quantserve.com

  • Microsoft OneDrive

    • akadns.net
    • akamai.net
    • edgesuite.net
    • live.com
    • live.net
    • mesh.com
    • microsoft.com
    • msn.com
    • nexus.passport.com
    • nsatc.net
    • verisign.com
    • windows.com
    • windowsupdate.com
    • windowsupdate.nsatc.net

  • Netflix

    • btstatic.com
    • customerevents.netflix.com
    • movies.netflix.com
    • nccp.netflix.com
    • nflxext.com
    • nflximg.com
    • nflximg.net
    • nflxvideo.net
    • secure.netflix.com

  • Pinterest

    • pinterest.com
    • s-media-cache-ak0.pinimg.com
    • s-passets-cache-ak0.pinimg.com
    • pinimg.com

  • Slack

    • slack.com
    • a.slack-edge.com

  • Spotify Browser Player

    • akamaiedge.net
    • ap.spotify.com
    • apresolve.spotify.com
    • cdn.betrad.com
    • cloudfront.net
    • d2c87l0yth4zbw.cloudfront.net
    • embed.spotify.com
    • gslb.spotify.com
    • l.betrad.com
    • play.spotify.com
    • play.spotify.edgekey.net
    • spapps.co
    • spapps.spotify.edgekey.net

  • Twitter

    • twimg.com
    • api.twitter.com
    • pic.twitter.com
    • dev.twitter.com
    • platform.twitter.com
    • search.twitter.com
    • userstream.twitter.com
    • twimg0-a.akamaihd.net
    • upload.twitter.com
    • api.twitter.com

  • Vimeo

    • vimeo.com
    • vimeocdn.com

  • Windows Live Messenger

    • login.live.com
    • contacts.msn.com
    • storage.msn.com
    • c.msn.com
    • messenger.msn.com
    • g.msn.com
    • crl.microsoft.com
    • messenger.hotmail.com
    • rsi.hotmail.com
    • sqm.microsoft.com
    • messenger.live.com
    • rad.msn.com
    • spaces.live.com
    • dp.msnmessenger.akadns.com
    • echo.edge.messenger.live.com
    • livefilestore.com

  • Yahoo Messenger

    • messenger.yahoo.com
    • msg.edit.yahoo.com
    • msg.yahoo.com
    • webcam.yahoo.com
    • vc.yahoo.com

  • YouTube

    • www.youtube-nocookie.com
    • c.youtube.com
    • ytimg.l.google.com
    • googlesyndication.com
    • ytimg.com
    • accounts.google.com
    • youtube.l.google.com

追加のドメインを発見する方法

ドメイン（このリストからではない）がポリシーテーブルに追加されたが、期待どおりに機能しない場合、関連するドメインが関与しているが、まだテーブルに追加されていない可能性があります。テーブルにドメインを追加する必要があるかどうかを確認するには、[セッション] | [セッション]を開きます。セッション履歴は、特定のドメインを参照した直後に登録されたエントリを報告および検査します。この方法は、追加するドメインを決定するのに役立つ場合があります。

それでも正しく参照できないドメインがある場合は、Ericom Shield ProfessionalServicesに連絡してサポートを受けてください。

7.13.24. ShieldでTech-Preview機能を利用する方法

Shieldには、管理コンソールを介して管理されるいくつかのTech-Preview機能が含まれており、リリースごとに異なる場合があります。これらのTech-Preview機能を有効にするには、[設定]、[プレビュー]の順に移動します。一般で、[技術プレビュー機能を有効にする]を[はい]に設定します。 次の機能はTech-Previewとして定義されています（詳細については、特定のリンクをクリックしてください）。

  • IE Mode
  • AutoFill

Shieldノードをバックアップとしてマッピングする方法

サーバーの1つをSFTPサーバーとして定義するには、次のようにします。

Shieldノードで、SSHキーを生成します。

  • マシン上でキーを生成します。
ssh-keygen

キーのshield.pemを設定します

他の質問にはEnterキーを押してください。秘密鍵と公開鍵が作成されます。

参考

パブリック/プライベートRSAキーペアを生成します。 キーを保存するファイル（/home/ericom/.ssh/id_rsa）を入力します：shield.pem パスフレーズを入力します（パスフレーズがない場合は空）：（入力） 同じパスフレーズをもう一度入力します。（入力） あなたの身分証明書はshield.pemに保存されています。 公開鍵はshield.pem.pubに保存されています

  • 公開鍵をsftpサーバーにコピーし、.sshフォルダーに置きます
ssh-copy-id -i shield.pem.pub ericom@sftpserver
  • IDファイルを使用して接続できることを確認します。
ssh -i ./shield.pem ericom@sftpserver

7.13.25. ブラウザノードのクローン

既存のオンプレミスシステムにブラウザノードを追加（クローン）する場合は、以下の手順で行ってください。

既存のシステムにブラウザノードを追加する必要がある場合、以下の手順で現在のブラウザノードのクローンを作成することができます。これにより、追加のブラウザノードのデプロイメントにかかる時間とリソースを節約することができます。

既存のブラウザモードをクローンする

VMWareシステムを使用して、既存のブラウザノードのクローンを作成します。クローンが、ソースノードと同じリソースとネットワークを持っていることを確認します。

新しいノードの設定

VMware Web Consoleまたは同様のアクセス方法を使用して、新しいノードにログインします。

ログインは、ericom/ericomshieldを使用します。

新しいノードのIPが一意になるように設定します。

/etc/systemd/network に移動して、20-wired.network ファイルを編集（特定のIPアドレス/サブネットを参照するなど）します。

[Match]
Name=en*

[Network]
Address=10.1.10.12/24
Gateway=10.1.10.1
DNS=10.1.10.1
#optional, multiples may be used
#DNS=10.1.10.2
IPForward=ipv4

マシンの名前をユニークな名前に変更します（クラスタを正しく作成するために必要です）。rootで、実行します。

hostnamectl set-hostname <NewUniqueHostname>

/etc/hosts ファイルで新しいホスト名を更新します。不足している場合は、追加してください。

Rancherの設定をクリーンアップ

新しいノードで以下を実行します。

~/ericomshield$ sudo ./clean-rancher-agent.sh

clean-rancher-agent.sh がサーバーにない場合は、これらのコマンドを1つずつ実行してください。

docker rm -f $(docker ps -qa)

docker volume rm $(docker volume ls -q)

docker system prune -a -f

rm -f ~/.kube/config

新しいノードを既存のシステムに参加させる

Rancherをhttps://RancherServerIPAddress:8443（Rancher ServerのIPアドレスを使用）開きます。

クラスターに移動し、Editを選択します。

../_images/howto_es2111_43.jpg

ページの一番下までスクロールし、必要なチェックボックスにマークを付け（予定されている展開に従って）、一番下のコマンドをコピーします（右の「クリップボードにコピー」オプションを使用）。

../_images/howto_es2111_44.jpg

新しいノードに対してコピーしたコマンドを実行し、クラスタに参加させます。クラスタメニューの[ノード]をクリックして、ノードの参加状況を確認します。

処理が終了するまで待ちます。ノードがクラスタに参加すると、ページの下部に緑色のメッセージが表示されます。クラスタが完成するまで、各ノードごとにこのプロセスを繰り返します。

  • ノードのラベルを設定する

計画された展開に従って、各マシンのノード・ラベルを設定します。

Rancherで、Nodesを選択し、編集したい各ノードについて、右側のメニューからEditオプションを選択します。

../_images/howto_es2111_45.jpg

「ノードの編集」ダイアログで、「ラベルと注釈」セクションを展開し、必要なラベルをノードに追加します。各ラベルには、値acceptを設定します。可能なラベルは次のとおりです。

../_images/howto_es2111_46.jpg

ラベルは、以下のラベルを1行ずつ手動で追加するか、コピー＆ペーストを使用して1行以上追加することができます。

shield-role/management=accept
shield-role/proxy=accept
shield-role/elk=accept
shield-role/farm-services=accept
shield-role/remote-browsers=accept

[保存]を押します。更新されたラベルは、ノードの詳細に表示されるようになりました。

../_images/howto_es2111_47.jpg