ソフトウェアエージェントの展開
(注) |
自動ロールマッピングを使用して LDAP/AD アカウントからダウンロードしたインストーラスクリプトは、ユーザーがログアウトするとすぐに失敗します。インストーラスクリプトにクラスタへの連続アクセスを許可するには、ユーザーに対して [ローカル認証を使用(Use Local Authentication)] を有効にすることを推奨します。 |
展開が成功すると、エージェントが実行されているホストに固有の一連のパラメータに基づき、Secure Workload クラスタによってエージェントに固有の ID が割り当てられます。ホスト名と BIOS UUID は設定の一部であるため、次の問題が発生する可能性があります。
-
BIOS UUID とホスト名を保持したまま仮想マシンを複製すると、登録に失敗します。登録の失敗は、VDI インスタントクローニングの実行時などにも発生する可能性があります。これは、Secure Workload クラスタに、同じパラメータセットを使用して登録されたソフトウェアエージェントがすでにあるためです。ユーザーは、OpenAPI を使用して登録済みのエージェントを削除できます。場合によっては、起動時に設定された重複 BIOS UUID が、遅延後に VMware によって変更されます。エージェントの登録は、Cisco Secure Workload サービスが再起動されない限り回復しません。
-
ホスト名を変更してホストを再起動すると、エージェントの新しい ID が生成される可能性があります。冗長または古いエージェントエントリは、一定時間が経過すると非アクティブとしてマークされます。ソフトウェアエージェントのトラブルシューティングを参照してください。
サポートされているプラットフォームと要件
サポートされているプラットフォームとソフトウェアエージェントの追加要件については、以下を参照してください。
-
ご使用のリリースのリリースノートについては、「Release Notes」を参照してください。
-
Cisco Secure Workload Web ポータルのエージェント インストール ウィザード:左側のナビゲーションバーで タブをクリックします。インストール方法、プラットフォーム、およびエージェントタイプ(該当する場合)を選択して、サポートされているプラットフォームのバージョンを確認します。
を選択し、[インストーラ(Installer)] -
その他の依存関係については、「Support Matrix」を参照してください。すべての列が表示されていることを確認します。
-
各プラットフォームおよびエージェントタイプの追加要件は、以下の項で示されています。
優れた可視性と適用のための Linux エージェントのインストール
Linux エージェントのインストールの要件と前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
サービスをインストールして実行するには、ルート権限が必要です。
-
エージェントおよびログファイルのストレージ要件:1 GB。
-
ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を設定することにより、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
-
エージェントがインストールされているホストには特別なユーザー tet-sensor が作成されることに注意してください。ホストで PAM/SELinux が設定されている場合は、tet-sensor プロセスの実行やコレクタへの接続など、tet-sensor ユーザーに適切な権限を付与する必要があります。代替のインストールディレクトリがあり、SELinux が設定されている場合は、代替のインストールディレクトリで実行が許可されていることを確認してください。
-
エージェントが自動インストール(インストーラスクリプト)メソッドを使用してインストールされている場合は、unzip コマンドを使用できる必要があります。
Linux エージェントをインストールするためにサポートされている方法
優れた可視性と適用のために Linux エージェントをインストールする方法:
-
インストーラを使用したエージェントの自動インストール
-
従来のパッケージインストーラを使用したエージェントの手動インストール
エージェント スクリプト インストーラ方式を使用した Linux エージェントのインストール
インストーラスクリプトは、Linux プラットフォームで優れた可視性と適用のエージェントを展開する場合に推奨される方法です。
(注) |
|
スクリプトインストーラ方式を使用して Linux エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントスクリプトインストーラ(Agent Script Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォームの選択(Select Platform)] ドロップダウンメニューから、[Linux] を選択します。 サポートされている Linux プラットフォームを表示するには、[サポートされているプラットフォームの表示(Show Supported Platforms)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
(オプション)ワークロードにラベルを割り当てるには、ラベルキーを選択し、ラベル値を入力します。 インストールされたエージェントがホストで IP アドレスを報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP アドレスに自動的に割り当てられます。アップロード済みの CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合は、次のようになります。
|
||
ステップ 6 |
Cisco Secure Workload との通信に HTTP プロキシが必要な場合は、[はい(Yes)] を選択し、有効なプロキシ URL を入力します。 |
||
ステップ 7 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 8 |
[ダウンロード(Download)] をクリックし、ファイルをローカルディスクに保存します。 |
||
ステップ 9 |
Linux ホストでインストーラ シェル スクリプトをコピーし、
|
||
ステップ 10 |
エージェントをインストールするために、ルート権限で
|
スクリプトの使用方法の詳細で指定されているように、事前チェックを実行することを推奨します。
bash tetration_linux_installer.sh [--pre-check] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--basedir=<basedir>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of CL_HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--save=<filename>: download and save zip file as <filename>
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of tet-sensor
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--basedir=<base_dir>: instead of using /usr/local use <base_dir> to install agent. The full path will be <base_dir>/tetration
--logbasedir=<log_base_dir>: instead of logging to /usr/local/tet/log use <log_base_dir>. The full path will be <log_base_dir>/tetration
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
(注) |
|
エージェント イメージ インストーラ方式を使用した Linux エージェントのインストール
エージェントイメージ方式を使用してエージェントを手動でインストールする具体的な理由がない限り、(自動化されている)インストーラスクリプト方式を使用して Linux エージェントをインストールすることを推奨します。
前提条件:
SaaS クラスタの場合、および複数のテナントがあるオンプレミスクラスタでデフォルトテナントにインストールしない場合は、user.cfg ファイルで ACTIVATION_KEY と HTTPS_PROXY を設定する必要があります。詳細については、(手動インストールのみ)ユーザー構成ファイルの更新を参照してください。(手動インストールのみ)ユーザー構成ファイルの更新
エージェントイメージ方式を使用して Linux エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントイメージインストーラ(Agent Image Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォーム(Platform)] フィールドに、Linux と入力します。 |
||
ステップ 4 |
必要なエージェントタイプとエージェントのバージョンを入力し、結果から必要なバージョンのエージェントをダウンロードします。 |
||
ステップ 5 |
RPM パッケージを展開するためにすべての Linux ホストにコピーします。
|
||
ステップ 6 |
プラットフォームに基づいて、ルート権限で RPM コマンドを実行します。
|
Linux エージェントのインストールの確認
手順
コマンド 出力例: 指定された出力は、プラットフォームとアーキテクチャによって異なる場合があります。 |
優れた可視性と適用のための Windows エージェントのインストール
Windows エージェントのインストールの要件と前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
インストールとサービス実行のための管理者権限が必要です。
-
Windows 2008 R2 を実行しているワークロードでは、Npcap をインストールする必要があります。また、インストールされているエージェントのバージョンがバージョン 3.8 より前の場合も、Npcap をインストールする必要があります。Npcap ドライバがまだインストールされていない場合、推奨される Npcap バージョンが、サービスの開始後にエージェントによってサイレントにインストールされます。Npcap のバージョン情報を参照してください。
-
エージェントおよびログファイルのストレージ要件:1 GB。
-
必要な Windows サービス:Windows ホストのセキュリティが強化されている場合や、Microsoft から出荷されたときのデフォルト構成から逸脱している場合は、エージェントのインストールを正常に行うために必要な一部の Windows サービスが無効になっている可能性があります。「必要な Windows サービス」を参照してください。
-
ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を設定することにより、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
Windows エージェントをインストールするためにサポートされている方法
優れた可視性または適用の目的で Windows プラットフォームにエージェントをインストールするには、2 つの方法があります。
-
インストーラを使用したエージェントの自動インストール
-
従来のパッケージインストーラを使用したエージェントの手動インストール
ゴールデンイメージを使用したインストールも可能です。「VDI インスタンスまたは VM テンプレートへのエージェントの展開(Windows)」を参照してください。
エージェント スクリプト インストーラ方式を使用した Windows エージェントのインストール
インストーラスクリプトは、Windows プラットフォームで優れた可視性と適用のエージェントを展開する場合に推奨される方法です。
(注) |
|
スクリプトインストーラ方式を使用して Windows エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントスクリプトインストーラ(Agent Script Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォームの選択(Select Platform)] ドロップダウンメニューから、[Windows] を選択します。 サポートされている Windows プラットフォームを表示するには、[サポートされているプラットフォームの表示(Show Supported Platforms)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
(オプション)ワークロードにラベルを割り当てるには、ラベルキーを選択し、ラベル値を入力します。 インストールされたエージェントがホストで IP アドレスを報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP アドレスに自動的に割り当てられます。アップロード済みの CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合は、次のようになります。
|
||
ステップ 6 |
Cisco Secure Workload との通信に HTTP プロキシが必要な場合は、[はい(Yes)] を選択し、有効なプロキシ URL を入力します。 |
||
ステップ 7 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 8 |
[ダウンロード(Download)] をクリックし、ファイルをローカルディスクに保存します。 |
||
ステップ 9 |
インストーラの PowerShell スクリプトを展開用のすべての Windows ホストにコピーし、管理者権限でスクリプトを実行します。
|
# powershell -File tetration_windows_installer.ps1 [-preCheck] [-skipPreCheck <Option>] [-noInstall] [-logFile <FileName>] [-proxy <ProxyString>] [-noProxy] [-help] [-version] [-sensorVersion <VersionInfo>] [-ls] [-file <FileName>] [-save <FileName>] [-new] [-reinstall] [
-npcap] [-forceUpgrade] [-upgradeLocal] [-upgradeByUUID <FileName>] [-visibility] [-goldenImage] [-installFolder <Installation Path>]
-preCheck: run pre-check only
-skipPreCheck <Option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '-skipPreCheck all' will skip all pre-installation checks; All pre-checks will be performed by default
-noInstall: will not download and install sensor package onto the system
-logFile <FileName>: write the log to the file specified by <FileName>
-proxy <ProxyString>: set the value of HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
-noProxy: bypass system wide proxy; this flag will be ignored if -proxy flag was provided
-help: print this usage
-version: print current script's version
-sensorVersion <VersionInfo>: select sensor's version; e.g.: '-sensorVersion 3.4.1.0.win64'; will download the latest version by default if this flag was not provided
-ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
-file <FileName>: provide local zip file to install sensor instead of downloading it from cluster
-save <FileName>: downloaded and save zip file as <FileName>
-new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
-reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than -new
-npcap: overwrite existing npcap
-forceUpgrade: force sensor upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -forceUpgrade'; apply the latest version by default if -sensorVersion flag was not provided
-upgradeLocal: trigger local sensor upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -upgradeLocal'; apply the latest version by default if -sensorVersion flag was not provided
-upgradeByUUID <FileName>: trigger sensor whose uuid is listed in <FileName> upgrade to version given by -sensorVersion flag; e.g.: '-sensorVersion 3.4.1.0.win64 -upgradeByUUID "C:\\Program Files\\Cisco Tetration\\sensor_id"'; apply the latest version by default if -sensorVersion flag was not provided
-visibility: install deep visibility agent only; -reinstall would overwrite this flag if previous installed agent type was enforcer
-goldenImage: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
-installFolder: install Cisco Secure Workload Agent in a custom folder specified by -installFolder e.g.: '-installFolder "c:\\custom sensor path"'; default path is "C:\Program Files\Cisco Tetration"
エージェント イメージ インストーラ方式を使用した Windows エージェントのインストール
エージェントイメージ方式を使用してエージェントを手動でインストールする具体的な理由がない限り、(自動化されている)インストーラスクリプト方式を使用して Windows エージェントをインストールすることを推奨します。
(注) |
ホストで既存のエージェントがすでに実行されている場合は、古い MSI エージェントバージョンを手動で展開しないでください。 |
パッケージ内には次のサイト関連ファイルがあります。
-
ca.cert(必須):センサー通信用の CA 証明書。
-
enforcer.cfg(適用センサーをインストールする場合にのみ必須):適用エンドポイントの構成が含まれています。
-
sensor_config(必須):優れた可視性センサーの構成。
-
sensor_type:センサーのタイプ(適用または優れた可視性)。
-
site.cfg(必須):グローバル サイト エンドポイント構成。
-
user.cfg(SaaS の場合は必須):センサー アクティベーション キーとプロキシ構成。
前提条件:
SaaS クラスタの場合、および複数のテナントがあるオンプレミスクラスタでデフォルトテナントにインストールしない場合は、user.cfg ファイルで ACTIVATION_KEY と HTTPS_PROXY を設定する必要があります。詳細については、(手動インストールのみ)ユーザー構成ファイルの更新を参照してください。(手動インストールのみ)ユーザー構成ファイルの更新
エージェントイメージ方式を使用して Windows エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||||||||||||||||||
ステップ 2 |
[エージェントイメージインストーラ(Agent Image Installer)] をクリックします。 |
||||||||||||||||||
ステップ 3 |
[プラットフォーム(Platform)] フィールドに、Windows と入力します。 |
||||||||||||||||||
ステップ 4 |
必要なエージェントタイプとエージェントのバージョンを入力し、結果から必要なバージョンのエージェントをダウンロードします。 |
||||||||||||||||||
ステップ 5 |
tet-win-sensor<version>.win64-<clustername>.zip ファイルを、展開用のすべての Windows ホストにコピーします。 |
||||||||||||||||||
ステップ 6 |
管理者権限で ZIP ファイルを解凍します。 |
||||||||||||||||||
ステップ 7 |
解凍したフォルダで、コマンド さらに、MSI インストーラでは次のオプションを使用できます。
|
(注) |
|
Windows エージェントのインストールの確認
手順
ステップ 1 |
フォルダ |
ステップ 2 |
TetSensor サービス(優れた可視性エージェント向け)が存在し、実行状態であることを確認します。管理者権限で
状態が Running であることを確認します。
DISPLAY-NAME が Cisco Secure Workload Deep Visibility であるかを確認します。 または services.msc コマンドを実行します。 Cisco Secure Workload Deep Visibility という名前を見つけます。 状態が Running であることを確認します。 |
ステップ 3 |
TetEnforcer サービス(適用エージェント向け)が存在し、実行状態であることを確認します。 管理者権限で
状態が Running であることを確認します。
DISPLAY-NAME が Cisco Secure Workload Enforcement であるかを確認します。 または
Cisco Secure Workload Enforcement という名前を見つけます。 状態が Running であることを確認します。 |
設定されたサービス ユーザー コンテキストの Windows エージェントの確認
-
TetSensor(詳細可視性のため)と TetEnforcer(適用のため)の両サービスが設定されたサービス ユーザー コンテキストで実行されていることを確認します。TetSensor と TetEnforcer は、同じサービス ユーザー コンテキストで実行されます。
管理者権限で
cmd.exe
コマンドを実行します。sc query tetsensor
コマンドを実行します。SERVICE_START_NAME <configured service user> を確認します。
sc qc tetenforcer
コマンドを実行します。SERVICE_START_NAME <configured service user> を確認します。
または
services.msc
コマンドを実行します。Cisco Secure Workload Deep Visibility という名前を見つけます。
<configured service user> の Log On As を確認します。
Cisco Secure Workload Enforcement という名前を検索します。
<configured service user> の Log On As を確認します。
または
tasklist /v | find /i “tet”
コマンドを実行します。実行中のプロセスのユーザーコンテキストを確認します(5 列目)。
サービスアカウントの変更
Windows エージェントのインストール後にサービスアカウントを変更するには、次のいずれかの方法を使用して、既存の優れた可視性および適用のサービスを変更します。
-
services.msc を使用します。
-
任意のサードパーティ アプリケーションを使用して、サービスを構成します。
-
次のコマンドを使用します。
-
管理者として cmd を実行します。
-
次のコマンドを実行して、サービスアカウント名を使用してサービスを変更します。
-
sc config tetsensor obj=<service user name>パスワード=<password>
-
sc config tetenforcer obj= <service user name> password= <password>
-
-
次のコマンドを実行して構成を確認します。
-
sc qc tetsensor
-
sc qc tetenforcer
-
-
次のコマンドを実行して、tetsensor と tetenforcer サービスを再開します。
-
sc stop tetsensor / tetenforcer
-
sc start tetsensor / tetenforcer
-
-
VDI インスタンスまたは VM テンプレートへのエージェントの展開(Windows)
デフォルトでは、エージェントのインストール後にエージェントサービスが自動的に開始されます。ゴールデンイメージにインストールする場合は、インストーラフラグを使用して、エージェントサービスが開始されないようにする必要があります。インスタンスがゴールデンイメージから複製されると、エージェントサービスは予想どおりに自動的に開始されます。
同様に、Npcap は通常、エージェントのインストール後に自動的にインストールされます(エージェントがまだ存在していない場合)。Npcap はゴールデンイメージに自動的にインストールされませんが、必要に応じて、ゴールデンイメージから複製された VM インスタンスに自動的にインストールされます。詳細については、「Windows エージェントインストーラと Npcap」を参照してください。
エージェントではゴールデン VM に Npcap はインストールされませんが、必要に応じて、ゴールデンイメージから複製された VM インスタンスに自動的にインストールされます。詳細については、「Windows エージェントインストーラと Npcap」を参照してください。
VDI 環境または VM テンプレートのゴールデンイメージにエージェントをインストールする
手順
ステップ 1 |
MSI インストーラまたは PowerShell インストーラスクリプトを使用して、VDI 環境または VM テンプレートのゴールデンイメージにエージェントをインストールします。 nostart=yes を指定した MSI インストーラーを使用
または -goldenImage フラグを指定した PowerShell インストーラを使用
|
ステップ 2 |
フォルダ |
ステップ 3 |
TetSensor サービス(優れた可視性エージェント向け)が存在し、停止していることを確認します。 管理者権限で
状態が Stopped であることを確認します。 |
ステップ 4 |
TetEnforcer サービス(適用エージェント向け)が存在し、停止していることを確認します。 sc query tetenforcer コマンドを実行します。 状態が Stopped であることを確認します。 |
ステップ 5 |
これで VM テンプレートが設定されました。 |
ステップ 6 |
VM テンプレートをシャットダウンします。 |
新規 VDI インスタンス VM の作成
手順
ステップ 1 |
VM テンプレートを複製して、新規 VDI インスタンス VM を作成します。 |
||
ステップ 2 |
VDI インスタンス VM を再起動します。 |
||
ステップ 3 |
VDI インスタンス VM を再起動した後、TetSensor(詳細可視性のため)と TetEnforcer(適用のため)の両サービスが設定されたサービスコンテキストで実行されていることを確認します。「エージェントがインストールされていることを確認する」を参照してください。 |
||
ステップ 4 |
VDI インスタンス VM で、NPCAP ドライバがインストールされ、実行されていることを確認します。 管理者権限でコマンド コマンド [実行中(Running)] の状態を確認します。 |
||
ステップ 5 |
VDI インスタンス VM で、有効な sensor_id を使用してエージェントが登録されていることを確認します。
|
Windows エージェントインストーラと Npcap:Windows 2008 R2 の場合
-
サポートされている Npcap バージョンについては、https://www.cisco.com/go/secure-workload/requirements/agents のサポートマトリックスを参照してください。
-
インストール:
Npcap がインストールされていない場合、エージェントはサービスの開始から 10 秒後にサポートされているバージョンをインストールします。ユーザーが Npcap をインストールしていても、サポートされているバージョンより古い場合、Npcap はアップグレードされません。Npcap を自分でアップグレード/アンインストールするか、オプション overwritenpcap=yes を指定してエージェントインストーラを実行するか、または -npcap を指定してインストーラスクリプトを実行して、サポートされている Npcap バージョンを取得してください。Npcap ドライバがアプリケーションで使用されている場合、エージェントは後で Npcap のアップグレードを試みます。
-
アップグレード:
Npcap が Windows エージェントによってインストールされ、そのバージョンがサポートされているバージョンより古い場合、Npcap はサービスの開始から 10 秒後にサポートされているバージョンにアップグレードされます。Npcap ドライバがアプリケーションで使用されている場合、エージェントは後で Npcap のアップグレードを試みます。Npcap が Windows エージェントによってインストールされていない場合、Npcap はアップグレードされません。
-
アンインストール:
Npcap が Windows エージェントによってインストールされている場合、Npcap は Windows エージェントによってアンインストールされます。Npcap がユーザーによってインストールされていても、overwritenpcap=yes でエージェントインストーラによってアップグレードされた場合、アンインストールされません。Npcap ドライバがアプリケーションで使用されている場合、エージェントは Npcap をアンインストールしません。
Windows エージェント フロー キャプチャ:Windows 2008 R2 を除くすべての Windows OS の場合
最新バージョンの Windows エージェントからは、エージェントは、ndiscap.sys(Microsoft 組み込み)ドライバと、Windows を使用したイベントトレース(ETW)フレームワークを使用して、ネットワークフローをキャプチャします。
最新バージョンへのアップグレード中に、以下のことが行われます。
-
エージェントが npcap.sys から ndiscap.sys に切り替わります。
-
エージェントインストーラが次の場合に Npcap をアンインストールします。
-
Npcap がエージェントによってインストールされている
-
Npcap が使用されていない
-
OS バージョンが Windows 2008 R2 ではない
-
エージェントサービスが開始されると、エージェントが、ETW セッション、CSW_MonNet、および CSW_MonDns(DNS データ用)を作成し、ネットワークフローのキャプチャを開始します。
(注) |
Windows 2012 では、DNS データのネットワークパケットが解析されます。 |
優れた可視性と適用のための AIX エージェントのインストール
(注) |
プロセスツリー、パッケージ(CVE)、およびフォレンジック イベント レポート機能は、AIX では使用できません。さらに、これらの機能の一部は、OS の制限により、サポートされているプラットフォームの特定のマイナーリリースでは利用できない場合があります。 |
AIX エージェントのインストールの要件と前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
優れた可視性のための追加要件:
-
サービスをインストールして実行するには、ルート権限が必要です。
-
エージェントおよびログファイルのストレージ要件:500 MB。
-
ホストを監視しているすべてのセキュリティ アプリケーションでセキュリティの除外を構成することにより、他のセキュリティ アプリケーションがエージェントのインストールまたはエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
-
AIX は、20 個のネットデバイスのフローキャプチャのみをサポートします(バージョンが AIX 7.1 TL3 SP4 以前の場合は 6 個のネットデバイス)。優れた可視性エージェントは、最大 16 個のネットワークデバイスからキャプチャを行い、他の 4 個のキャプチャセッションを一般的なシステム用途(tcpdump など)に排他的に使用できるようにします。
-
優れた可視性エージェントは、この動作を確実にするために次のことを行います。
-
エージェントは、エージェントディレクトリ(/opt/cisco/tetration/chroot/dev/bpf0 - /opt/cisco/tetration/chroot/dev/bpf15)の下に 16 個の bpf デバイスノードを作成します。
-
bpf を使用する tcpdump およびその他のシステムツールは、未使用のノード(!EBUSY)が見つかるまで、システムデバイスノード(/dev/bpf0-/dev/bpf19)をスキャンします。
-
エージェントが作成した bpf ノードとシステム bpf ノードは同じメジャー/マイナーを共有し、各メジャー/マイナーは 1 つのインスタンス(tcpdump またはエージェント)によってのみ開かれます。
-
エージェントはシステムデバイスノードにアクセスせず、tcpdump のようにそれらを作成しません(tcpdump-D は /dev/bpf0. . . /dev/bpf19 が存在しない場合これらを作成します)。
-
-
システムで iptrace を実行すると、特定のシナリオで tcpdump および優れた可視性エージェントからのフローキャプチャが防止されます。これは設計上の既知の問題であり、IBM に確認する必要があります。
-
エージェントをインストールする前にこのシナリオが存在するかどうかを確認するには、tcpdump を実行します。tcpdump: BIOCSETIF: en0: File exists のようなエラーメッセージが表示される場合、iptrace はフローキャプチャをブロックしています。iptrace を停止すると、問題が解決します。
-
-
AIX では、すべての優れた可視性機能がサポートされているわけではありません。例えば、パッケージとプロセスのアカウンティングはサポートされていません。
-
-
ポリシーの適用に関する追加要件:
-
IP セキュリティフィルタが有効になっている場合(例:smitty ipsec4)、事前チェックでエージェントのインストールが失敗します。エージェントをインストールする前に、IP セキュリティフィルタを無効にすることを推奨します。
-
IP セキュリティが有効になっている場合、Cisco Secure Workload エンフォーサエージェントの実行中にエラーとして報告され、適用エージェントは適用を停止します。適用エージェントの実行中に IP セキュリティフィルタを安全に無効にするには、サポートにお問い合わせください。
-
エージェント スクリプト インストーラ方式を使用した AIX エージェントのインストール
優れた可視性または適用の AIX エージェントは、エージェント スクリプト インストール方式を使用しないとインストールできません。
(注) |
|
AIX エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントスクリプトインストーラ(Agent Script Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォームの選択(Select Platform)] ドロップダウンメニューから、[AIX] を選択します。 サポートされている AIX プラットフォームを表示するには、[サポートされているプラットフォームの表示(Show Supported Platforms)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
(オプション)ワークロードにラベルを割り当てるには、ラベルキーを選択し、ラベル値を入力します。 インストールされたエージェントがホストで IP アドレスを報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP アドレスに自動的に割り当てられます。アップロード済みの CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合は、次のようになります。
|
||
ステップ 6 |
Cisco Secure Workload との通信に HTTP プロキシが必要な場合は、[はい(Yes)] を選択し、有効なプロキシ URL を入力します。 |
||
ステップ 7 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 8 |
[ダウンロード(Download)] をクリックし、ファイルをローカルディスクに保存します。 |
||
ステップ 9 |
インストーラ シェル スクリプトを、展開するためにすべての AIX ホストにコピーします。 |
||
ステップ 10 |
スクリプトに実行権限を付与するために、
|
||
ステップ 11 |
エージェントをインストールするために、ルート権限で
|
スクリプトの使用方法の詳細で指定されているように、事前チェックを実行することを推奨します。
AIX インストーラスクリプトの使用方法の詳細:
ksh tetration_installer_default_enforcer_aix.sh [--pre-check] [--pre-check-user] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--osversion=<osversion>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--libs=<libs.zip|tar.Z>] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--pre-check-user: provide alternative to nobody user for pre-check su support
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.3 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--osversion=<osversion>: specify osversion for --save flag;
--save=<filename>: download and save zip file as <filename>; will download package for osversion given by --osversion flag; e.g.: '--save=myimage.aix72.tar.Z --osversion=7.2'
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of tet-snsr
--libs=<libs.zip|tar.Z>: install provided libs to be used by agents
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--logbasedir=<log_base_dir>: instead of logging to /opt/cisco/tetration/log use <log_base_dir>. The full path will be <log_base_dir>/tetration
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
AIX エージェントのインストールの確認
手順
コマンド
Subsystem Group PID Status tet-sensor 1234567 active
Subsystem Group PID Status tet-enforcer 7654321 active |
優れた可視性と適用のための Kubernetes または OpenShift エージェントのインストール
要件および前提条件
Kubernetes 1.[16-22]
-
RHEL:7.[0-9](x86_64 アーキテクチャのみ)
-
CentOS:7.[0-8](x86_64 アーキテクチャのみ)
-
Oracle Linux:7.[0-8](x86_64 アーキテクチャのみ)
-
Ubuntu:16.04、18.04、20.04(x86_64 アーキテクチャのみ)
-
SUSE Linux Enterprise Server:12sp[0-5](x86_64 アーキテクチャのみ)
-
Amazon Linux 2(x86_64 アーキテクチャのみ)
Openshift 4.[5-9]
-
Red Hat Enterprise Linux CoreOS:4.[5-9](x86_64 アーキテクチャのみ)
コンテナ ランタイム
-
Docker
-
CRI-O
-
containerd(>= 1.5.x)
(注) |
containerd ランタイムでは、config_path が設定されていない場合は、config.toml(デフォルトの場所:/etc/containerd/config.toml)を次のように変更します。 [plugins.”io.containerd.grpc.v1.cri”.registry] config_path = “/etc/containerd/certs.d” containerd デーモンを再起動します。 |
追加の要件
-
インストールスクリプトには、クラスタノードで特権エージェントポッドを起動するための Kubernetes または OpenShift 管理者のログイン情報が必要です。
-
Cisco Secure Workload エンティティは、‘tetration’ という名前の名前空間に作成されます。
-
ノードまたはポッドのセキュリティポリシーは、特権モードのポッドを許可する必要があります。
-
busybox:1.33 イメージは、事前にインストールされているか、Docker Hub からダウンロード可能である必要があります。
-
Kubernetes または OpenShift コントロールプレーンノードで実行するには、-toleration フラグを使用して、Secure Workload ポッドの容認を渡すことができます。これは通常、ポッドがコントロールプレーンノードで実行されないようにする NoSchedule 容認です。
ポリシー適用の要件
コンテナ オーケストレーション プラットフォームでポリシーを適用するエージェントは、RHEL 7.[0-9]、CentOS 7.[0-8]、または Ubuntu 16.04/18.04/20.04 ノードでサポートされます。
IPVS ベースの kube-proxy モードは、OpenShift ではサポートされません。
これらのエージェントは、[ルールの保持(Preserve Rules)] オプションを有効にして設定する必要があります。「エージェント設定プロファイルの作成」を参照してください。
適用が適切に機能するためには、インストールされている CNI プラグインが次の条件を満たす必要があります。
-
すべてのノードとポッド間にフラットなアドレス空間(IP ネットワーク)を提供すること。クラスタ内通信のためにソースポッド IP をマスカレードするネットワークプラグインはサポートされていません。
-
Secure Workload 適用エージェントが使用する Linux iptables ルールまたはマークに干渉しないこと(マークビット 21 および 20 は、NodePort サービスのトラフィックを許可および拒否するために使用されます)
次の CNI プラグインは、上記の要件を満たすことがテストされています。
-
次の Felix 設定を持つ Calico (3.13):(ChainInsertMode: Append, Ipta- blesRefreshInterval: 0) または (ChainInsertMode: Insert, IptablesFilterAllowAction: Return, IptablesMangleAllowAction: Return, IptablesRefreshInterval: 0)。その他のオプションは、そのデフォルト値を使用します。
これらのオプションの設定に関する詳細については、Felix 設定リファレンスを参照してください。
エージェント スクリプト インストーラ方式を使用した Kubernetes または OpenShift エージェントのインストール
(注) |
エージェント スクリプト インストーラ方式では、後から含まれるノードにエージェントが自動的にインストールされます。 |
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントスクリプトインストーラ(Agent Script Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォームの選択(Select Platform)] ドロップダウンメニューから、[Kubernetes] を選択します。 サポートされている Kubernetes または OpenShift プラットフォームを表示するには、[サポートされているプラットフォームの表示(Show Supported Platforms)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
Cisco Secure Workload との通信に HTTP プロキシが必要な場合は、[はい(Yes)] を選択し、有効なプロキシ URL を入力します。 |
||
ステップ 6 |
[ダウンロード(Download)] をクリックし、ファイルをローカルディスクに保存します。 |
||
ステップ 7 |
Kubernetes API サーバーにアクセスでき、デフォルトのコンテキスト、クラスタ、ユーザーとしての管理権限を持つ kubectl 構成ファイルが存在する Linux マシンで、インストーラスクリプトを実行します。 インストーラは、デフォルトの場所(~/.kube/config)からのファイルの読み取りを試みます。ただし、--kubeconfig コマンドラインオプションを使用して明示的に指定できます。 |
インストールスクリプトにより、インストールされた Cisco Secure Workload エージェントの Daemonset とポッドを確認するための説明が提供されます。
(注) |
ダウンロード前にエージェント インストーラ ページで構成された HTTP プロキシは、Cisco Secure Workload エージェントが Cisco Secure Workload クラスタに接続する方法のみを制御します。この設定は、Kubernetes または OpenShift ノードによる Docker イメージの取得方法には影響しません。これらのノードのコンテナランタイムでは、独自のプロキシ設定が使用されるためです。Docker イメージを Cisco Secure Workload クラスタからプルできない場合は、コンテナランタイムのイメージプルプロセスのデバッグが必要になり、適切な HTTP プロキシの追加が必要になる場合があります。 |
優れた可視性のための Solaris エージェントのインストール
Solaris エージェントのインストールの要件と前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
サービスをインストールして実行するには、ルート権限が必要です。
-
エージェントおよびログファイルのストレージ要件:1 GB。
-
ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を設定することにより、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
エージェント スクリプト インストーラ方式を使用した Solaris エージェントのインストール
インストールされた Solaris エージェントは、優れた可視性とプロセスやパッケージの可視性の両方をサポートします。
手順
ステップ 1 |
エージェントのインストール方式に移動するために、次の手順を実行します。
|
||
ステップ 2 |
[エージェントスクリプトインストーラ(Agent Script Installer)] をクリックします。 |
||
ステップ 3 |
[プラットフォームの選択(Select Platform)] ドロップダウンメニューから、[Solaris] を選択します。 サポートされている Solaris プラットフォームを表示するには、[サポートされているプラットフォームの表示(Show Supported Platforms)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
(オプション)ワークロードにラベルを割り当てるには、ラベルキーを選択し、ラベル値を入力します。 インストールされたエージェントがホストで IP アドレスを報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP アドレスに自動的に割り当てられます。アップロード済みの CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合は、次のようになります。
|
||
ステップ 6 |
Cisco Secure Workload との通信に HTTP プロキシが必要な場合は、[はい(Yes)] を選択し、有効なプロキシ URL を入力します。 |
||
ステップ 7 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 8 |
[ダウンロード(Download)] をクリックし、ファイルをローカルディスクに保存します。 |
||
ステップ 9 |
Solaris ホストでインストーラ シェル スクリプトをコピーし、
|
||
ステップ 10 |
エージェントをインストールするために、ルート権限で
|
スクリプトの使用方法の詳細で指定されているように、事前チェックを実行することを推奨します。
Solaris インストーラスクリプトの使用方法の詳細:
tetration_installer_default_sensor_solaris.sh [--pre-check] [--skip-pre-check=<option>] [--no-install] [--logfile=<filename>] [--proxy=<proxy_string>] [--no-proxy] [--help] [--version] [--sensor-version=<version_info>] [--ls] [--file=<filename>] [--save=<filename>] [--new] [--reinstall] [--unpriv-user] [--force-upgrade] [--upgrade-local] [--upgrade-by-uuid=<filename>] [--basedir=<basedir>] [--logbasedir=<logbdir>] [--tmpdir=<tmp_dir>] [--visibility] [--golden-image]
--pre-check: run pre-check only
--skip-pre-check=<option>: skip pre-installation check by given option; Valid options include 'all', 'ipv6' and 'enforcement'; e.g.: '--skip-pre-check=all' will skip all pre-installation checks; All pre-checks will be performed by default
--no-install: will not download and install sensor package onto the system
--logfile=<filename>: write the log to the file specified by <filename>
--proxy=<proxy_string>: set the value of CL_HTTPS_PROXY, the string should be formatted as http://<proxy>:<port>
--no-proxy: bypass system wide proxy; this flag will be ignored if --proxy flag was provided
--help: print this usage
--version: print current script's version
--sensor-version=<version_info>: select sensor's version; e.g.: '--sensor-version=3.4.1.0'; will download the latest version by default if this flag was not provided
--ls: list all available sensor versions for your system (will not list pre-3.1 packages); will not download any package
--file=<filename>: provide local zip file to install sensor instead of downloading it from cluster
--save=<filename>: download and save zip file as <filename>
--new: remove any previous installed sensor; previous sensor identity has to be removed from cluster in order for the new registration to succeed
--reinstall: reinstall sensor and retain the same identity with cluster; this flag has higher priority than --new
--unpriv-user=<username>: use <username> for unpriv processes instead of nobody
--force-upgrade: force sensor upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --force-upgrade'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-local: trigger local sensor upgrade to version given by --sensor-version flag: e.g.: '--sensor-version=3.4.1.0 --upgrade-local'; apply the latest version by default if --sensor-version flag was not provided
--upgrade-by-uuid=<filename>: trigger sensor whose uuid is listed in <filename> upgrade to version given by --sensor-version flag; e.g.: '--sensor-version=3.4.1.0 --upgrade-by-uuid=/usr/local/tet/sensor_id'; apply the latest version by default if --sensor-version flag was not provided
--logbasedir=<log_base_dir>: instead of logging to /opt/cisco/secure-workload/log use <log_base_dir>. The full path will be <log_base_dir>/secure-workload
--tmpdir=<tmp_dir>: instead of using /tmp use <tmp_dir> as temp directory
--visibility: install deep visibility agent only; --reinstall would overwrite this flag if previous installed agent type was enforcer
--golden-image: install Cisco Secure Workload Agent but do not start the Cisco Secure Workload Services; use to install Cisco Secure Workload Agent on Golden Images in VDI environment or Template VM. On VDI/VM instance created from golden image with different host name, Cisco Secure Workload Services will work normally
Solaris エージェントのインストールの確認
手順
ステップ 1 |
コマンド |
||||||||
ステップ 2 |
出力として単一のエントリがあることを確認します。これにより、Solaris エージェントがホストにインストールされていることが確認されます。
|
(手動インストールのみ)ユーザー構成ファイルの更新
以下の手順は、次のすべてを含むインストールにのみ必要です。
-
Secure Workload SaaS、または複数のテナントを持つオンプレミスクラスタ(デフォルトのテナントのみを使用するオンプレミスクラスタでは、この手順は不要)
-
手動インストール
-
Linux または Windows プラットフォーム
エージェントを Secure Workload クラスタに登録するには、クラスタ アクティベーション キーが必要です。さらに、エージェントがクラスタに到達するために HTTPS プロキシが必要な場合は、プロキシを指定する必要があります。
(注) |
Windows 環境では、手動インストール時にアクティベーションキーとプロキシオプションを使用する場合、user.cfg を手動で構成する必要はありません。 |
インストールの前に、ユーザー構成ファイルで必要な変数を設定します。
手順
ステップ 1 |
アクティベーションキーの取得: に移動し、[インストーラ(Installer)] タブをクリックし、[従来のパッケージインストーラを使用した手動インストール(Manual Install using classic packaged installers)] をクリックしてから、[エージェントアクティベーションキー(Agent Activation Key)] をクリックします。 |
ステップ 2 |
Secure Workload エージェントのインストールフォルダにある |
ステップ 3 |
アクティベーションキーを ACTIVATION_KEY 変数に追加します。例: |
ステップ 4 |
エージェントに HTTPS プロキシが必要な場合は、HTTPS_PROXY 変数を使用して http プロトコルプロキシサーバーとポートを追加します。例: |
その他のエージェント同様のツール
AnyConnect エージェント
Network Visibility Module (NVM) を備えた Cisco AnyConnect セキュア モビリティ エージェントでサポートされるプラットフォームです。追加の Secure Workload エージェントは必要ありません。AnyConnect コネクタは、これらのエージェントを登録し、フロー観測データ、インベントリデータ、およびラベルをSecure Workload にエクスポートします。詳細については、「AnyConnect コネクタ」を参照してください。
Windows、Mac、Linux プラットフォームについては、『Cisco AnyConnect セキュア モビリティ クライアント データ シート』[英語] を参照してください。
ISE エージェント
Cisco Identity Services Engine(ISE)に登録されたエンドポイント。このエンドポイントに Secure Workload エージェントは必要ありません。ISE コネクタは、ISE アプライアンスの pxGrid サービスを介して ISE からエンドポイントに関するメタデータを収集します。エンドポイントを Secure Workload で ISE エージェントとして登録し、このエンドポイントにインベントリのラベルをプッシュします。詳細については、「ISE コネクタ」を参照してください。
SPAN エージェント
SPAN エージェントは ERSPAN コネクタと連携します。詳細については、「ERSPAN コネクタ」を参照してください。
サードパーティ製品および追加のシスコ製品との統合
-
Secure Workload で設定された外部オーケストレータを使用した統合。
外部オーケストレータを参照してください。
-
Secure Workload で設定されたコネクタを使用した統合。
「コネクタとは」を参照してください。
接続情報
一般に、エージェントがワークロードにインストールされると、Secure Workload クラスタでホストされているバックエンドサービスへの多数のネットワーク接続が開始されます。エージェントのタイプとその機能に応じて、接続数の表示は異なります。
次の表は、さまざまなエージェントタイプによって確立されたさまざまな固定接続を示しています。
エージェント タイプ |
コンフィギュレーション サーバー |
コレクタ |
適用バックエンド |
---|---|---|---|
可視性(オンプレミス) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
該当なし |
可視性(SaaS) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:443 |
該当なし |
enforcement (オンプレミス) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
ENFORCER-IP:5660 |
適用(SaaS) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:443 |
ENFORCER-IP:443 |
Docker イメージ |
CFG-SERVER-IP:443 |
該当なし |
該当なし |
説明:
-
CFG-SERVER-IP は、コンフィギュレーション サーバーの IP アドレスを表します。
-
COLLECTOR-IP は、コレクタの IP アドレスを表します。詳細可視性エージェントと適用エージェントは、利用可能なすべてのコレクタに接続します。
-
ENFORCER-IP は、適用エンドポイントの IP アドレスを表します。適用エージェントは、使用可能なエンドポイントのうち 1 つのみに接続します。
-
Kubernetes/Openshift エージェントの展開の場合、インストールスクリプトにエージェントソフトウェアが含まれていません。エージェントソフトウェアを含む Docker イメージは、各 Kubernetes/Openshift ノードによって Secure Workload クラスタからプルされます。これらの接続は、コンテナランタイムイメージ取得コンポーネントによって確立され、CFG-SERVER-IP:443 が接続先になります。
(注) |
|
ワークロードがファイアウォールの背後にある場合や、ホスト ファイアウォール サービスが有効になっている場合は、クラスタへの接続が拒否される可能性があることに注意することが重要です。管理者は、適切なファイアウォールポリシーを作成して、そのような接続を許可する必要があります。