ソフトウェアエージェントの展開
(注) |
自動ロールマッピングを使用して LDAP/AD アカウントからダウンロードしたインストーラスクリプトは、ユーザーがログアウトするとすぐに失敗します。インストーラスクリプトにクラスタへの連続アクセスを許可するには、ユーザーに対して [ローカル認証を使用(Use Local Authentication)] を有効にすることを推奨します。「Use Local Authentication」オプション |
展開が成功すると、エージェントが実行されているホストに固有の一連のパラメータに基づき、Secure Workload クラスタによってエージェントに固有の ID が割り当てられます。ホスト名と BIOS UUID は設定の一部であるため、次の問題が発生する可能性があります。
-
BIOS UUID とホスト名を保持したまま仮想マシンを複製すると、登録に失敗します。登録の失敗は、VDI インスタントクローニングの実行時などにも発生する可能性があります。これは、Secure Workload クラスタに、同じパラメータセットを使用して登録されたソフトウェアエージェントがすでにあるためです。ユーザーは、OpenAPI を使用して登録済みのエージェントを削除できます。場合によっては、起動時に設定された重複 BIOS UUID が、遅延後に VMware によって変更されます。エージェントの登録は、Cisco Secure Workload サービスが再起動されない限り回復しません。
-
ホスト名を変更してホストを再起動すると、エージェントの新しい ID が生成される可能性があります。冗長または古いエージェントエントリは、一定時間が経過すると非アクティブとしてマークされます。ソフトウェアエージェントのトラブルシューティングを参照してください。
サポートされているプラットフォームと要件
サポートされているプラットフォームとソフトウェアエージェントの追加要件については、以下を参照してください。
-
ご使用のリリースのリリースノートは、https://www.cisco.com/c/en/us/support/security/tetration/products-release-notes-list.html から入手できます。
-
Secure Workload Web ポータルのエージェント インストール ウィザード:左側のナビゲーションバーで を選択し、[インストーラ(Installer)] タブをクリックします。インストール方法、プラットフォーム、およびエージェントタイプ(該当する場合)を選択して、サポートされているプラットフォームのバージョンを確認します。
-
https://www.cisco.com/go/secure-workload/requirements/agents から入手可能なサポートマトリックス。このリソースには、複数の追加の依存関係が含まれています。すべての列が表示されていることを確認してください。
-
以下の各プラットフォームおよびエージェントタイプのセクションの追加要件。
Linux エージェント:優れた可視性と適用
要件および前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
サービスをインストールして実行するには、ルート権限が必要です。
-
エージェントおよびログファイルのストレージ要件:IBM Z の場合は 500MB。それ以外の場合は 1GB。
-
ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を構成することにより、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
-
エージェントがインストールされているホストには特別なユーザー tet-sensor が作成されることに注意してください。ホストで PAM/SELinux が構成されている場合は、tet-sensor プロセスの実行やコレクタへの接続など、tet-sensor ユーザーに適切な権限を付与する必要があります。代替のインストールディレクトリがあり、SELinux が設定されている場合は、代替のインストールディレクトリで実行が許可されていることを確認してください。
-
エージェントが自動インストール(インストーラスクリプト)メソッドを使用してインストールされている場合は、unzip コマンドを使用できる必要があります。
エージェントのインストール
- インストーラを使用したエージェントの自動インストール
- 従来のパッケージインストーラを使用したエージェントの手動インストール
インストーラを使用した自動インストール(Linux)
インストーラスクリプトは、Linux プラットフォームで優れた可視性と適用のエージェントを展開する場合に推奨される方法です。
デフォルトでは、インストールされたエージェントは優れた可視性と適用の両方をサポートしています。デフォルトでは適用は無効になっていますが、Secure Workload ユーザーインターフェイスを使用して簡単に有効にすることができます。
エージェントをインストールするには、次の手順を実行します。
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||||
ステップ 3 |
[インストーラを使用してエージェントを自動インストール(Auto-Install Agent using an Installer)] ワークフローを選択し、[次へ(Next)] をクリックします。 |
||||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||||
ステップ 5 |
CMDB ラベルを選択し、関連付けられた値を入力して、それをエージェントインストーラに添付します(オプションの選択)。インストールされたエージェントがこのホストで見つかった新しい IP アドレスをクラスタに報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP に自動的に割り当てられます。アップロードされた CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合:
|
||||
ステップ 6 |
[プラットフォーム(Platform)] セクションで [Linux] を選択します。 |
||||
ステップ 7 |
ネットワークに HTTP プロキシが必要な場合は [はい(Yes)] を選択し、有効なプロキシ URL を入力します。それ以外の場合は [いいえ(No)] を選択します。 |
||||
ステップ 8 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||||
ステップ 9 |
[Download Installer(インストーラのダウンロード)] をクリックし、ファイルをローカルディスクに保存します。インストーラスクリプトがローカルに保存されたら、[次へ(Next)] をクリックします。 |
||||
ステップ 10 |
インストーラ シェル スクリプトを展開するためにすべての Linux ホストにコピーします。 |
||||
ステップ 11 |
コマンド
|
||||
ステップ 12 |
エージェントをインストールするには、root 権限でコマンド
インストーラスクリプトの使用方法は、次のとおりです。 $ 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>] [–visibility] –pre-check:事前チェックのみを実行します –skip-pre-check=<option>:指定されたオプションで事前インストールチェックをスキップします。有効なオプションには「all」、「ipv6」および「enforcement」が含まれます。たとえば、‘–skip-pre-check=all’ は、すべての事前インストールチェックをスキップします。すべての事前チェックはデフォルトで実行されます –no-install:システムでのセンサーパッケージのダウンロードおよびインストールは行いません –logfile <filename>:<filename> で指定されたファイルにログを書き込みます。 –proxy <proxy_string>:HTTPS_PROXY の値を設定します。クラスタとの通信にプロキシが必要な場合は、これを使用します。文字列は http://<proxy>:<port> の形式にする必要があります –no-proxy:システム全体のプロキシをバイパスします。 –proxy フラグが指定されている場合、このフラグは無視されます –help:このヘルプを印刷します –version:現在のスクリプトのバージョンを印刷します。 –sensor-version <version_info>:センサーのバージョン(たとえば「–sensor- version=3.4.1.0」)を選択します。このフラグが提供されていない場合、デフォルトで最新バージョンをダウンロードします –ls:システムで使用可能なすべてのセンサーバージョンを一覧表示します(3.1 以前のパッケージは表示しません)。パッケージはダウンロードしません –file <filename>:クラスタからダウンロードする代わりに、センサーをインストールするためのローカル zip ファイルを提供します –save <filename>:zipファイルをダウンロードして <filename> として保存します –new:以前にインストールされたセンサーをすべて削除します。新しい登録を成功させるには、以前のセンサー ID をクラスタから削除する必要があります –reinstall:センサーを再インストールし、クラスタと同じ ID を保持します。このフラグは、–new よりも優先されます –unpriv-user=<username>:unpriv プロセスで tet-sensor の代わりに <username> を使用します –force-upgrade:–sensor-version フラグで指定されたバージョンへのセンサーのアップグレードを強制します(例:'–sensor-version=3.4.1.0 –force-upgrade')– sensor-version フラグが指定されていない場合、デフォルトで最新バージョンを適用します –upgrade-local:–sensor-version フラグで指定されたバージョンへのローカルセンサーのアップグレードをトリガーします(例:'–sensor-version=3.4.1.0 –upgrade-local')次の場合、デフォルトで最新バージョンを適用します –sensor-version フラグは提供されませんでした –upgrade-by-uuid=<filename>:<filename> に uuid がリストされているトリガーセンサーを –sensor-version フラグで指定されたバージョンにアップグレードします(例:‘–sensor-version=3.4.1.0 – upgrade-by-uuid=/usr/local/tet/sensor_id’)– sensor-version フラグが指定されていない場合、デフォルトで最新バージョンを適用します –baseir=<base_dir>:/usr/local を使用する代わりに <base_dir> を使用してエージェントをインストールします。フルパスは <base_dir>/tetration となります –logbasedir=<log_base_dir>:/usr/local/tet/log にログインする代わりに <log_base_dir> を使用します。フルパスは <log_base_dir>/tetration です –visibility:優れた可視性エージェントのみをインストールします。 –reinstall は、以前にインストールされたエージェントタイプがエンフォーサである場合、このフラグを上書きします
|
従来のパッケージインストーラを使用した手動インストール(Linux)
このセクションでは、エージェントイメージをダウンロードして Linux ホストにインストールする方法について説明します。
ほとんどの場合、手動でインストールする特別な理由がない限り、より単純な自動インストール方法(前述)を使用する必要があります。
前提条件:
デフォルトのテナントの下にインストールしていないときの SaaS および複数のテナントがあるオンプレミスクラスタの場合:
手動でインストールする前に、user.cfg ファイルで ACTIVATION_KEY と HTTPS_PROXY を設定する必要があります。詳細については、「(手動インストールのみ)ユーザー構成ファイルの更新」を参照してください。
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||
ステップ 3 |
[従来のパッケージインストーラを使用した手動インストール(Manual Install using classic packaged installers)] ワークフローを選択し、[次へ(Next)] をクリックします。 |
||
ステップ 4 |
適切なバージョン/プラットフォーム/アーキテクチャ/エージェントタイプを見つけて、[ダウンロード(Download)] ボタンをクリックします。 |
||
ステップ 5 |
展開するすべての Linux ホストに rpm パッケージをコピーし、ルート権限で rpm コマンドを実行します。
RHEL/CentOS/Oracle プラットフォームの場合:
Ubuntu プラットフォームの場合:
|
エージェントがインストールされていることの確認
手順
ステップ 1 |
コマンド |
||
ステップ 2 |
エントリが 1 つあることを確認します。
$ sudo rpm -q tet-sensor tet-sensor-3.1.1.50-1.el6.x86_64 |
Windows エージェント - 優れた可視性および適用
要件および前提条件
-
「サポートされているプラットフォームと要件」を参照してください。
-
管理者権限(インストールとサービス実行の両方)
-
Npcap がインストール済みである必要があります。Npcap ドライバがまだインストールされていない場合、推奨される Npcap バージョンが、サービスの開始から 2 分後にエージェントによってサイレントにインストールされます。Npcap のバージョン情報については、「https://www.cisco.com/go/secure-workload/requirements/agents」を参照してください。
-
エージェントとログファイルのストレージ要件:1 GB。
-
必要な Windows サービス:Windows ホストのセキュリティが強化されている場合や、Microsoft から出荷されたときのデフォルト構成から逸脱している場合は、エージェントのインストールを正常に行うために必要な一部の Windows サービスが無効になっている可能性があります。「必要な Windows サービス」を参照してください。
-
ホストを監視しているセキュリティ アプリケーションでセキュリティの除外を設定することにより、他のセキュリティ アプリケーションがエージェントのインストールやエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
エージェントのインストール
- インストーラを使用したエージェントの自動インストール
- クラシック パッケージ インストーラを使用したエージェントの手動インストール
ゴールデンイメージを使用したインストールも可能です。「VDI インスタンスまたは VM テンプレートへのエージェントの展開(Windows)」を参照してください。
インストーラを使用したエージェントの自動インストール(Windows)
これは、Windows プラットフォームで優れた可視性または適用エージェントを展開するために推奨される方法です。「インストーラスクリプト」と呼ばれることもあります。
デフォルトでは、インストールされたエージェントは優れた可視性と適用の両方をサポートしています。デフォルトでは適用は無効になっていますが、Secure Workload ユーザーインターフェイスを使用して簡単に有効にすることができます。
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||
ステップ 3 |
[インストーラを使用して自動インストール(Auto-Install using Installers)] ワークフローを選択し、[次へ(Next)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。
|
||
ステップ 5 |
CMDB ラベルを選択し、関連付けられた値を入力して、それをエージェントインストーラに添付します(オプションの選択)。インストールされたエージェントがこのホストで見つかった新しい IP アドレスをクラスタに報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP に自動的に割り当てられます。アップロードされた CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合:
|
||
ステップ 6 |
プラットフォームとして [Windows] を選択します。 |
||
ステップ 7 |
ネットワークに HTTP プロキシが必要な場合は [はい(Yes)] を選択し、有効なプロキシ URL を入力します。それ以外の場合は [いいえ(No)] を選択します。 |
||
ステップ 8 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 9 |
[インストーラのダウンロード(Download Installer)] をクリックし、ファイルをローカルディスクに保存します。インストーラスクリプトがローカルに保存されたら、[次へ(Next)] をクリックします。 |
||
ステップ 10 |
インストーラの 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 <install Path>] –pre-check:事前チェックのみを実行します –skip-pre-check= <Option>:指定されたオプションで事前インストールチェックをスキップします。有効なオプションには「all」、「ipv6」および「enforcement」が含まれます。(たとえば、‘-skipPreCheck all’ は、すべての事前インストールチェックをスキップします。)すべての事前チェックはデフォルトで実行されます –no-install:システムでのセンサーパッケージのダウンロードおよびインストールは行いません -logFile <FileName>:<FileName> で指定されたファイルにログを書き込みます -proxy <ProxyString>:HTTPS_PROXY の値を設定します。クラスタとの通信にプロキシが必要な場合は、これを使用します。文字列は http: //<proxy>:<port> の形式にする必要があります -noProxy:システム全体のプロキシをバイパスします。-proxy フラグが指定されている場合、このフラグは無視されます -help:このヘルプを印刷します -version:現在のスクリプトのバージョンを印刷します -sensorVersion <VersionInfo>:センサーのバージョン(例:‘-sensorVersion 3.4.1.0.win64’)を選択します。このフラグが提供されていない場合、デフォルトで最新バージョンをダウンロードします -ls:システムで使用可能なすべてのセンサーバージョンを一覧表示します(3.1 以前のパッケージは表示しません)。パッケージはダウンロードされません -file <filename>:クラスタからダウンロードする代わりに、センサーをインストールするためのローカル zip ファイルを提供します -save <filename>:zipファイルをダウンロードして <filename> として保存します -new:以前にインストールされたセンサーをすべて削除します。新しい登録を成功させるには、以前のセンサー ID をクラスタから削除する必要があります -reinstall:センサーを再インストールし、クラスタと同じ ID を保持します。このフラグは、-new よりも優先されます -npcap:既存の npcap を上書きします -forceUpgrade:-sensorVersion フラグで指定されたバージョンへセンサーのアップグレードを強制します(例:‘-sensorVersion 3.4.1.0.win64 -forceUpgrade’) -sensorVersion フラグが指定されていない場合、デフォルトで最新バージョンを適用します -upgradeLocal:-sensorVersion フラグで指定されたバージョンへのローカルセンサーのアップグレードをトリガーします(例:‘-sensorVersion 3.4.1.0.win64 -upgradeLocal’)-sensorVersion フラグが指定されていない場合、デフォルトで最新バージョンを適用します。 -upgradeByUUID <FileName>:<FileName> に uuid がリストされているトリガーセンサーを -sensorVersion フラグで指定されたバージョンにアップグレードします(例:‘-sensorVersion 3.4.1.0.win64 -upgradeByUUID “C:\Program Files\Cisco Tetration\sensor_id”’)-sensorVersion フラグが指定されていない場合、デフォルトで最新バージョンを適用します。 -visibility:優れた可視性エージェントのみをインストールします。-reinstall は、以前にインストールされたエージェントタイプがエンフォーサである場合、このフラグを上書きします -goldenImage:VDI 環境または VM テンプレートのゴールデンイメージにエージェントをインストールするときに、このフラグを使用します。このパラメータにより、ゴールデンイメージのインストール後はエージェントサービス(tetsensor および tetenforcer)が自動的に開始されなくなります。異なるホスト名を持つゴールデンイメージから作成されたインスタンスでは、これらのサービスは予想されるとおりに自動で開始されます。 -installFolder:このフラグを使用して、-installFolder フラグで指定されたカスタムフォルダにエージェントをインストールします(例:‘-installFolder “c:\custom sensor path”’)デフォルトのパスは「C:\Program Files\Cisco Tetration」です。 |
従来のパッケージインストーラを使用した手動インストール(Windows)
このセクションでは、エージェントイメージをダウンロードして Windows ホストにインストールする方法について説明します。
(注) |
ほとんどの場合、手動でインストールする特別な理由がない限り、より単純な自動インストール方法(前述)を使用する必要があります。 |
(注) |
既存の実行中のエージェントに古いバージョンのエージェント MSI を手動で展開しないでください。 |
パッケージ内のサイト関連ファイル:
-
ca.cert(必須):センサー通信用の CA 証明書。
-
Enforcer.cfg(適用センサーをインストールする場合にのみ必須):適用エンドポイントの構成が含まれています。
-
sensor_config(必須):優れた可視性センサーの構成。
-
sensor_type:センサーのタイプ(適用または優れた可視性)。
-
site.cfg(必須):グローバル サイト エンドポイント構成。
-
user.cfg(TaaS の場合は必須):センサー アクティベーション キーとプロキシ構成。
前提条件:
デフォルトのテナントの下にインストールしていないときの SaaS および複数のテナントがあるオンプレミスクラスタの場合:
手動でインストールする前に、user.cfg ファイルで ACTIVATION_KEY と HTTPS_PROXY を設定する必要があります。詳細については、(手動インストールのみ)ユーザー構成ファイルの更新を参照してください。(手動インストールのみ)ユーザー構成ファイルの更新
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||
ステップ 3 |
[従来のパッケージインストーラを使用した手動インストール(Manual Install using classic packaged installers)] ワークフローを選択し、[次へ(Next)] をクリックします。 |
||
ステップ 4 |
適切なバージョン/プラットフォーム/アーキテクチャ/エージェントタイプを見つけて、[ダウンロード(Download)] をクリックします。 |
||
ステップ 5 |
ZIP パッケージを展開用のすべての Windows ホストにコピーし、管理者権限で以下の手順に従います。 |
||
ステップ 6 |
tet-win-sensor<version>.win64-<clustername>.zip ファイルを解凍して、非圧縮フォルダに移動します。 |
||
ステップ 7 |
コマンド MSI インストーラで使用可能なオプション:
エージェントを新しいバージョンにアップグレードする必要がある場合は、「ソフトウェアエージェントのアップグレード」で説明されているアップグレードプロセスに従ってください。 |
エージェントがインストールされていることを確認する
手順
ステップ 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 であることを確認します。 |
設定されたサービス ユーザー コンテキストでエージェントが実行されていることを確認します。
-
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 列目)。
VDI インスタンスまたは VM テンプレートへのエージェントの展開(Windows)
デフォルトでは、エージェントのインストール後にエージェントサービスが自動的に開始されます。ゴールデンイメージにインストールする場合は、インストーラフラグを使用して、エージェントサービスが開始されないようにする必要があります。インスタンスがゴールデンイメージから複製されると、エージェントサービスは予想どおりに自動的に開始されます。
同様に、Npcap は通常、エージェントのインストール後に自動的にインストールされます(エージェントがまだ存在していない場合)。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
-
サポートされている 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 をアンインストールしません。
AIX エージェント - 詳細可視性と適用
(注) |
プロセスツリー、パッケージ(CVE)、およびフォレンジック イベント レポート機能は、AIX ではまだ使用できません。さらに、これらの機能の一部は、OS の制限により、サポートされているプラットフォームの特定のマイナーリリースでは利用できない場合があります。 |
要件および前提条件
「サポートされているプラットフォームと要件」を参照してください。
優れた可視性のための追加要件
-
サービスをインストールして実行するには、ルート権限が必要です。
-
エージェントおよびログファイルのストレージ要件:500MB。
-
ホストを監視しているすべてのセキュリティ アプリケーションでセキュリティの除外を構成することにより、他のセキュリティ アプリケーションがエージェントのインストールまたはエージェントのアクティビティをブロックしないようにします。「セキュリティの除外」を参照してください。
-
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 セキュリティが有効になっている場合、Secure Workload エンフォーサエージェントの実行中にエラーとして報告され、エンフォーサエージェントは適用を停止します。適用エージェントの実行中に IP セキュリティフィルタを安全に無効にするには、サポートにお問い合わせください。
エージェントのインストール
優れた可視性と適用の AIX エージェントは、インストールスクリプトを使用しないとインストールできません。
デフォルトでは、インストールされたエージェントは優れた可視性と適用の両方をサポートしています。デフォルトでは適用は無効になっていますが、Secure Workload ユーザーインターフェイスを使用して簡単に有効にすることができます。
そのプロセスは次のとおりです。
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||
ステップ 3 |
[インストーラを使用して自動インストール(Auto-Install using Installers)] ワークフローを選択し、[次へ(Next)] をクリックします。 |
||
ステップ 4 |
エージェントをインストールするテナントを選択します。Secure Workload SaaS クラスタでは、テナントの選択は必要ありません。 |
||
ステップ 5 |
CMDB ラベルを選択し、関連付けられた値を入力して、それをエージェントインストーラに添付します(オプションの選択)。インストールされたエージェントがこのホストで見つかった新しい IP アドレスをクラスタに報告すると、このホストによって報告された IP に割り当てられているアップロード済みの別の CMDB ラベルとともに、ここで選択されたインストーラ CMDB ラベルが新しい IP に自動的に割り当てられます。アップロードされた CMDB ラベルとインストーラ CMDB ラベルの間で競合が発生した場合:
|
||
ステップ 6 |
プラットフォームとして AIX を選択します。 |
||
ステップ 7 |
ネットワークに HTTP プロキシが必要な場合は [はい(Yes)] を選択し、有効なプロキシ URL を入力します。それ以外の場合は [いいえ(No)] を選択します。 |
||
ステップ 8 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 9 |
[インストーラのダウンロード(Download Installer)] をクリックし、ファイルをローカルディスクに保存します。インストーラスクリプトがローカルに保存されたら、[次へ(Next)] をクリックします。 |
||
ステップ 10 |
インストーラ シェル スクリプトを、展開するためにすべての AIX ホストにコピーします。 |
||
ステップ 11 |
コマンド
|
||
ステップ 12 |
エージェントをインストールするには、root 権限でコマンド 以下のスクリプトの使用方法の詳細で指定されているように、事前チェックを実行することをお勧めします。
インストーラスクリプトの使用方法は、次のとおりです。 $ ksh tetration_installer_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>] [–visibility] –pre-check:事前チェックのみを実行します –pre-check-user:事前チェック su サポートに nobody ユーザーの代替を提供します –skip-pre-check=<option>:指定されたオプションで事前インストールチェックをスキップします。有効なオプションには「all」、「ipv6」および「enforcement」が含まれます。たとえば、–skip-pre-check=all’ は、すべての事前インストールチェックをスキップします。すべての事前チェックはデフォルトで実行されます –no-install:システムでのセンサーパッケージのダウンロードおよびインストールは行いません –logfile <filename>:<filename> で指定されたファイルにログを書き込みます –proxy=<proxy_string>:HTTPS_PROXY の値を指定します。文字列は http://<proxy>:<port> の形式にする必要があります。 –no-proxy:システム全体のプロキシをバイパスします。 –proxy フラグが指定されている場合、このフラグは無視されます –help:このヘルプを印刷します –version:現在のスクリプトのバージョンを印刷します –sensor-version=<version_info>:センサーのバージョン(たとえば「–sensor- version=3.4.1.0」)を選択します。このフラグが提供されていない場合、デフォルトで最新バージョンをダウンロードします –ls:システムで使用可能なすべてのセンサーバージョンを一覧表示します(3.3 以前のパッケージは表示しません)。パッケージはダウンロードしません –file <filename>:クラスタからダウンロードする代わりに、センサーをインストールするためのローカル zip ファイルを提供します –osversion=<osversion>:–save フラグに osversion を指定します –save=<filename>:zip ファイルをダウンロードして <filename> として保存します。–osversion flag(例:‘–save=myimage.aix72.zip – osversion=7.2’)で指定された osversion のパッケージをダウンロードします –new:以前にインストールされたセンサーをすべて削除します。新しい登録を成功させるには、以前のセンサー ID をクラスタから削除する必要があります –reinstall:センサーを再インストールし、クラスタと同じ ID を保持します。このフラグは、-new よりも優先されます –unpriv-user=<username>:unpriv プロセスで tet-snsr の代わりに <username> を使用します –libs=<libs.zip>:エージェントが使用する指定されたライブラリをインストールします –force-upgrade:–sensor-version フラグで指定されたバージョンへのセンサーのアップグレードを強制します(例:'–sensor-version=3.4.1.0 –force-upgrade')– sensor-version フラグが指定されていない場合、デフォルトで最新バージョンを適用します –upgrade-local:–sensor-version フラグで指定されたバージョンへのローカルセンサーのアップグレードをトリガーします(例:'–sensor-version=3.4.1.0 –upgrade-local')次の場合、デフォルトで最新バージョンを適用します –sensor-version フラグは提供されませんでした –upgrade-by-uuid=<filename>:<filename> に uuid がリストされているトリガーセンサーを –sensor-version フラグで指定されたバージョンにアップグレードします(例:‘–sensor-version=3.4.1.0 – upgrade-by-uuid=/usr/local/tet/sensor_id’)– sensor-version フラグが指定されていない場合、デフォルトで最新バージョンを適用します –logbasedir=<log_base_dir>:/opt/cisco/tetration/log use にログインする代わりに <log_base_dir> を使用します。フルパスは <log_base_dir>/tetration です –visibility:優れた可視性エージェントのみをインストールします。 –reinstall は、以前にインストールされたエージェントタイプがエンフォーサである場合、このフラグを上書きします |
エージェントがインストールされていることを確認する
手順の概要
- コマンド
lslpp -c -l tet-sensor.rte
を実行し、以下のように 1 つのエントリがあることを確認します。
手順の詳細
コマンド
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 管理者の資格情報が必要です。
-
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 設定リファレンスを参照してください。
エージェントのインストール
この「インストーラースクリプト」による方法では、将来のノードにエージェントが自動的にインストールされます。
手順
ステップ 1 |
左側のナビゲーションバーで、 をクリックします。 |
||
ステップ 2 |
[インストーラ(Installer)] タブをクリックします。 |
||
ステップ 3 |
[インストーラを使用して自動インストール(Auto-Install using Installers)] を選択し、[次へ(Next)] をクリックします。 |
||
ステップ 4 |
[Kubernetes] を選択します(該当する場合はテナント範囲を選択します)。 |
||
ステップ 5 |
ネットワークに HTTP プロキシが必要な場合は [はい(Yes)] を選択し、有効なプロキシ URL を入力します。それ以外の場合は [いいえ(No)] を選択します。 |
||
ステップ 6 |
[インストーラの有効期限(Installer expiration)] セクションで、利用可能なオプションから 1 つを選択します。
|
||
ステップ 7 |
[Download Installer(インストーラのダウンロード)] をクリックし、ファイルをローカルディスクに保存します。インストーラスクリプトがローカルに保存されたら、[次へ(Next)] をクリックします。 |
||
ステップ 8 |
Kubernetes API サーバーにアクセスでき、デフォルトのコンテキスト/クラスタ/ユーザーとしての管理者権限を持つ kubectl 構成ファイルも存在する Linux マシンで、インストーラスクリプトを実行します。 |
||
ステップ 9 |
インストーラはデフォルトの場所(~/.kube/config)からファイルを読み取ろうとしますが、これは |
||
ステップ 10 |
インストールスクリプトが成功すると、インストールされた Secure Workload Agent Daemonset とポッドを確認する方法の説明が出力されます。
|
(手動インストールのみ)ユーザー構成ファイルの更新
以下の手順は、次のすべてを含むインストールにのみ必要です。
-
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 コネクタ」を参照してください。
NetFlow、NetScaler、F5、AWS などのその他のコネクタ
コネクタの詳細については、「コネクタとは」を参照してください。
接続情報
一般に、エージェントがワークロードにインストールされると、Secure Workload クラスタでホストされているバックエンドサービスへの多数のネットワーク接続が開始されます。エージェントのタイプとその機能に応じて、接続数の表示は異なります。
次の表は、さまざまなエージェントタイプによって確立されたさまざまな固定接続を示しています。
エージェント タイプ |
コンフィギュレーション サーバー |
コレクタ |
適用バックエンド |
---|---|---|---|
可視性(オンプレミス) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
該当なし |
可視性(TaaS) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:443 |
該当なし |
適用(オンプレミス) |
CFG-SERVER-IP:443 |
COLLECTOR-IP:5640 |
ENFORCER-IP:5660 |
適用(TaaS) |
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 が接続先になります。
(注) |
|
ワークロードがファイアウォールの背後にある場合や、ホスト ファイアウォール サービスが有効になっている場合は、クラスタへの接続が拒否される可能性があることに注意することが重要です。管理者は、適切なファイアウォールポリシーを作成して、そのような接続を許可する必要があります。