NetFlow プロトコルを使用すると、ルータとスイッチを通過するトラフィックをフローに集約し、それらのフローをフローコレクターにエクスポートできます。

フローコレクタはこれらのフローレコードを受け取ると、オフラインでクエリと分析を行えるようにフローストレージに保存します。シスコ製ルータとスイッチは、NetFlow をサポートしています。

通常、セットアップには次の手順が含まれます。

1. 1 つ以上のネットワークデバイスで NetFlow 機能を有効にし、デバイスがエクスポートする必要があるフローテンプレートを設定します。

2. リモート ネットワーク デバイスで NetFlow コレクタのエンドポイント情報を設定します。この NetFlow コレクタが、設定されたエンドポイントでリッスンし、NetFlow フローレコードを受信して処理します。

NetFlow コネクタは、本質的に NetFlow コレクタです。コネクタは、ネットワークデバイスからフローレコードを受信し、フロー分析のために Secure Workload に転送します。NetFlow コネクタは、Secure Workload Ingest アプライアンスで有効にし、Docker コンテナとして実行できます。

NetFlow コネクタは、Secure Workload NetFlow エージェントとしても Secure Workload に登録されます。NetFlow コネクタは、NetFlow プロトコルパケット（つまり、フローレコード）のカプセル化を解除し、通常の Secure Workload エージェントのようにフローを処理して報告します。優れた可視性エージェントとは異なり、プロセスやインターフェースの情報は報告しません。

（注）	NetFlow コネクタは、NetFlow v9 および IPFIX プロトコルをサポートしています。

（注）

各 NetFlow コネクタは、1 つの VRF のフローのみを報告する必要があります。コネクタは、フローをエクスポートし、それらを Secure Workload クラスタ内のエージェント VRF 設定に基づいて VRF に配置します。 コネクタの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）] の順に選択し、[設定（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF設定（Agent Remote VRF Configurations）] セクションで、[設定の作成（Create Config）] をクリックし、コネクタに関する詳細を指定します。 このフォームでは、VRF の名前、コネクタの IP サブネット、およびフローレコードをクラスタに送信できる可能性のあるポート番号の範囲を入力するように要求されます。

NetFlow コネクタは、毎秒 15000 までのフローを受け入れます。特定の NetFlow v9 または IPFIX パケットには、1 つ以上のフローおよびテンプレートレコードが含まれている可能性があることに注意してください。NetFlow コネクタはパケットを解析し、フローを識別します。コネクタが毎秒 15,000 を超えるフローを解析する場合、超過分のフローレコードはドロップされます。

また、フローレートがこの許容限度内にある場合にのみ、Secure Workload カスタマーは NetFlow コネクタをサポートします。

フローレートが毎秒 15,000 フローを超える場合は、まずフローレートを調整して制限内に収めて、（高着信フローレートに関連した問題を回避するために）少なくとも 3 日間そのレベルを維持することを推奨します。

元の問題が解決しない場合は、カスタマーサポートが問題の調査を開始し、適切な回避策や解決策を特定します。

NetFlow コネクタは、NetFlow v9 および IPFIX プロトコルの次の情報要素のみをサポートします。詳細については、「IP Flow Information Export (IPFIX) Entities」を参照してください。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。NetFlow コネクタの場合、IPv4 および IPv6（デュアルスタックモード）アドレスがサポートされます。ただし、デュアルスタックのサポートはベータ機能であることに注意してください。

コネクタでは、以下を設定できます。

• ログ：詳細については、「ログ設定」を参照してください。

さらに、許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの IPFIX プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。詳細については、「update-listening-ports」を参照してください。

F5 BIG-IP IPFIX ロギングは、F5 BIG-IP を通過するトラフィックのフローデータを収集し、IPFIX レコードをフローコレクタにエクスポートします。

通常、セットアップには次の手順が含まれます。

1. F5 BIG-IP アプライアンスで IPFIX Log-Publisher を作成します。

2. F5 BIG-IP アプライアンスで IPFIX Log-Destination を構成します。この log-destination は、設定されたエンドポイントでリッスンし、フローレコードを受信して処理します。

3. IPFIX フローレコードを log-publisher に公開する F5 iRule を作成します。

4. F5 iRule を対象の仮想サーバーに追加します。

   （注）	F5 コネクタは、F5 BIG-IP ソフトウェアバージョン 12.1.2 以降をサポートします。

F5 BIG-IP コネクタは、本質的に IPFIX コレクタです。このコネクタは、F5 BIG-IP ADC からフローレコードを受信すると、NATed フローをステッチして、フロー分析の目的で Secure Workload に転送します。さらに、F5 コネクタに LDAP が設定されている場合、トランザクションに関連付けられたユーザーの設定済み LDAP 属性の値が判断されます（F5 がトランザクションを処理する前にユーザーを認証する場合）。LDAP 属性は、フローが発生したクライアントの IP アドレスに関連付けられています。

（注）	F5 コネクタは IPFIX プロトコルのみをサポートします。

（注）

各 F5 コネクタは、1 つの VRF のフローのみを報告します。コネクタは、エクスポートしたフローを、Cisco Secure Workload クラスタのエージェント VRF 設定に基づいて VRF に配置します。 コネクタの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）]の順に選択し、[設定（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF設定（Agent Remote VRF Configurations）] セクションで、[設定の作成（Create Config）] をクリックし、コネクタに関する詳細を指定します。このフォームでは、VRF の名前、コネクタの IP サブネット、およびフローレコードをクラスタに送信できる可能性のあるポート番号の範囲を入力するように要求されます。

次の手順は、F5 BIG-IP ロードバランサ用です。（参照：IPFIX 用 F5 BIG-IP を設定する）

上記の手順では、F5 BIG-IP ロードバランサで IPFIX を設定し、アプライアンスを通過するトラフィックの IPFIX プロトコルパケットをエクスポートします。F5 の設定例を示します。

上記の例では、フローレコードは ipfix-pub-1 に公開されます。ipfix-pub-1 には、IPFIX メッセージを IPFIX プール ipfix-pool-1 に送信する log-destination ipfix-collector-1 が設定されています。ipfix-pool-1 には、IPFIX コレクタの 1 つとして 10.28.118.6 が設定されています。仮想サーバー vip-1 は、IPFIX テンプレートとテンプレートの入力方法と送信方法を指定する IPFIX iRule ipfix-rule-1 を使用して設定されます。

• TCP 仮想サーバーの F5 および Secure Workload 承認済み iRule。詳細については、「TCP 仮想サーバーの L4 iRule」を参照してください。

• UDP 仮想サーバーの F5 および Secure Workload 承認済み iRule。詳細については、「UDP 仮想サーバーの L4 iRule」を参照してください。

• HTTPS 仮想サーバーの F5 および Secure Workload 承認済み iRule。詳細については、「HTTPS 仮想サーバーの iRule」を参照してください。

（注）	このガイドからダウンロードした iRule を使用する前に、iRule を追加する F5 コネクタで設定された log-publisher を指すように log-publisher を更新します。

（注）

F5 は GitHub リポジトリ f5-tetration を公開して、フロースティッチングを開始できるようにしています。さまざまなプロトコルタイプの F5 コネクタに IPFIX レコードを公開する iRules は、f5-tetration/irules で入手できます。 最新の iRule 定義については、このサイトにアクセスしてください。さらに、F5 は、次のためのスクリプトも開発します。 仮想サーバーに正しい iRule をインストールします。 IPFIX コレクタエンドポイント（F5 コネクタが IPFIX レコードをリッスンします）のプールを追加します。 log-collector と log-publisher を設定します。 仮想サーバーに正しい iRule をバインドします。 このツールにより、フロースティッチングのユースケースを有効にしながら、手作業の設定とユーザーエラーを最小限に抑えます。スクリプトは f5-tetration/scripts で入手できます。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。

コネクタでは、以下を設定できます。

• LDAP：LDAP 設定は、LDAP 属性の検出をサポートし、ユーザー名に対応する属性を選択するワークフローと、ユーザーごとに取得される最大 6 つの属性のリストを提供します。詳細については、「検出」を参照してください。

• ログ：詳細については、「ログ設定」を参照してください。

さらに、コンテナの実行が許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの IPFIX プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。詳細については、「update-listening-ports」を参照してください。

Citrix NetScaler AppFlow は、NetScaler を通過するトラフィックのフローデータを収集し、IPFIX レコードをフローコレクタにエクスポートします。Citrix AppFlow プロトコルは、IPFIX を使用してフローをフローコレクタにエクスポートします。Citrix AppFlow は、Citrix NetScaler ロードバランサでサポートされています。

通常、セットアップには次の手順が含まれます。

1. 1 つ以上の Citrix NetScaler インスタンスで AppFlow 機能を有効にします。

2. リモート ネットワーク デバイスで AppFlow コレクタのエンドポイント情報を設定します。この AppFlow コレクタが、設定されたエンドポイントでリッスンし、フローレコードを受信して処理します。

3. AppFlow のアクションとポリシーを設定して、フローレコードを AppFlow コレクタにエクスポートします。

（注）	NetScaler コネクタは、Citrix ADC ソフトウェアバージョン 11.1.51.26 以降をサポートしています。

NetScaler コネクタは、本質的に Citrix AppFlow（IPFIX）コレクタです。コネクタは Citrix ADC からフローレコードを受信すると、NATed フローをステッチして、フロー分析の目的で Secure Workload に転送します。NetScaler コネクタは Cisco Ingest Secure Workload アプライアンスで有効にすることができ、Docker コンテナとして稼働します。また、NetScaler コネクタは Secure Workload NetScaler エージェントとして Secure Workload に登録されます。

（注）	NetScaler コネクタは、IPFIX プロトコルのみをサポートします。

（注）

各 NetScaler コネクタは、1 つの VRF のフローのみを報告する必要があります。コネクタによってエクスポートされたフローは、Secure Workload クラスタ内のエージェント VRF 設定に基づいて VRF に配置されます。コネクタの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）]に移動し、[設定（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF設定（Agent Remote VRF Configurations）] セクションで、[設定の作成（Create Config）] をクリックし、コネクタに関する詳細を指定します。このフォームで、VRF の名前、コネクタの IP サブネット、およびフローレコードをクラスタに送信できる可能性のあるポート番号の範囲を提供するようにユーザーに要求します。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。コネクタでは、以下を設定できます。

• ログ：. 詳細については、「ログ設定」を参照してください。

さらに、許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの IPFIX プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。. 詳細については、「update-listening-ports」を参照してください。

Cisco Secure Firewall コネクタは、基本的に NetFlow コレクタです。コネクタは、Cisco Secure Firewall ASA および Cisco Secure Firewall Threat Defense から NSEL レコードを受信し、フロー分析のために Secure Workload に転送します。Cisco Secure Firewall コネクタは、Secure Workload Ingest アプライアンスで有効にし、Docker コンテナとして実行できます。

Cisco Secure Firewall コネクタも Secure Workload エージェントとして Secure Workload に登録されます。Cisco Secure Firewall コネクタは、NSEL プロトコルパケット（つまり、フローレコード）のカプセル化を解除し、通常の Secure Workload エージェントのようにフローを処理して報告します。優れた可視性エージェントとは異なり、プロセスやインターフェースの情報は報告しません。

（注）	Cisco Secure Firewall コネクタは、NetFlow v9 プロトコルをサポートします。

（注）

各 Cisco Secure Firewall コネクタは、1 つの VRF のフローのみを報告する必要があります。コネクタによってエクスポートされたフローは、Secure Workload クラスタのエージェント VRF 設定に基づいて VRF に配置されます。コネクタの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）]に移動し、[設定（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF設定（Agent Remote VRF Configurations）] セクションで、[設定の作成（Create Config）] をクリックし、コネクタに関する詳細を指定します。このフォームで、VRF の名前、コネクタの IP サブネット、およびフローレコードをクラスタに送信できる可能性のあるポート番号の範囲を提供するようにユーザーに要求します。

次の表は、さまざまな NSEL イベントが Cisco Secure Firewall コネクタによってどのように処理されるのかを示しています。これらの要素の詳細については、「IP フロー情報エクスポート（IPFIX）エンティティ」マニュアルを参照してください。

Cisco Secure Firewall コネクタは、NSEL レコードに基づいてフロー観測データを Cisco Secure Workload に送信します。NSEL フローレコードは双方向レコードです。したがって、Cisco Secure Firewall コネクタは、Cisco Secure Workload に対してフォワードフローとリバースフローの 2 つのフローを送信します。

以下は、Cisco Secure Firewall コネクタから Cisco Secure Workload に送信されるフロー観測データの詳細です。

NAT

クライアントから ASA へのフローが NATed の場合、NSEL フローレコードは、サーバー側の NATed IP やポートを示します。Cisco Secure Firewall コネクタは、この情報を使用して、サーバーから ASA へのフロー、および ASA からクライアントへのフローをスティッチングします。

順方向の NATed フローレコードは次のとおりです。

フィールド	NSEL 要素 ID	NSEL 要素名
[プロトコル（Protocol）]	4	NF_F_PROTOCOL
[送信元アドレス（Source Address）]	225	NF_F_XLATE_SRC_ADDR_IPV4
	281	NF_F_XLATE_SRC_ADDR_IPV6
[送信元ポート（Source Port）]	227	NF_F_XLATE_SRC_PORT
[宛先アドレス（Destination Address）]	226	NF_F_XLATE_DST_ADDR_IPV4
	282	NF_F_XLATE_DST_ADDR_IPV6
[宛先ポート（Destination Port）]	228	NF_F_XLATE_DST_PORT
[フロー開始時刻（Flow Start Time）]	152	NF_F_FLOW_CREATE_TIME_MSEC
[バイト数（Byte Count）]	231	NF_F_FWD_FLOW_DELTA_BYTES
[パケット数（Packet Count）]	298	NF_F_FWD_FLOW_DELTA_PACKETS

フォワードフローは、順方向の NATed フローレコード関連としてマーク付けされます（逆も同様）。

逆方向の NATed フローレコードは次のとおりです。

フィールド	NSEL 要素 ID	NSEL 要素名
[プロトコル（Protocol）]	4	NF_F_PROTOCOL
[送信元アドレス（Source Address）]	226	NF_F_XLATE_DST_ADDR_IPV4
	282	NF_F_XLATE_DST_ADDR_IPV6
[送信元ポート（Source Port）]	228	NF_F_XLATE_DST_PORT
[宛先アドレス（Destination Address）]	225	NF_F_XLATE_SRC_ADDR_IPV4
	281	NF_F_XLATE_SRC_ADDR_IPV6
[宛先ポート（Destination Port）]	227	NF_F_XLATE_SRC_PORT
[フロー開始時刻（Flow Start Time）]	152	NF_F_FLOW_CREATE_TIME_MSEC
[バイト数（Byte Count）]	232	NF_F_REV_FLOW_DELTA_BYTES
[パケット数（Packet Count）]	299	NF_F_REV_FLOW_DELTA_PACKETS

リバースフローは、逆方向の NATed フローレコード関連としてマーク付けされます（逆も同様）。

（注）	このセクションに記載されている NSEL 要素 ID のみが、Cisco Secure Firewall コネクタでサポートされます。

次の手順は、NSEL を設定し、NetFlow パケットをコレクタ（つまり、Cisco Secure Firewall コネクタ）にエクスポートする方法のガイドラインです。詳細については、『Cisco Secure Firewall ASA NetFlow 実装ガイド』にある公式のシスコ コンフィギュレーション ガイドを参照してください。

    flow-export destination outside 172.29.142.27 4729
    flow-export template timeout-rate 1
    !
    policy-map flow_export_policy
      class class-default
      flow-export event-type flow-create destination 172.29.142.27
      flow-export event-type flow-teardown destination 172.29.142.27
      flow-export event-type flow-denied destination 172.29.142.27
      flow-export event-type flow-update destination 172.29.142.27
      user-statistics accounting
    service-policy flow_export_policy global

この例では、Cisco Secure Firewall ASA アプライアンスは、NetFlow パケットをポート 4729 の 172.29.142.27 に送信するように設定されています。さらに、flow-export アクションは、flow-create、flow-teardown、flow-denied、および flow-update イベントで有効になります。これらのフローイベントが ASA で発生すると、NetFlow レコードが生成され、設定で指定された宛先に送信されます。

Cisco Secure Firewall コネクタが、Secure Workload が有効になっていて、Secure Workload Ingest アプライアンスの 172.29.142.27:4729 でリッスンしていると仮定すると、コネクタは Cisco Secure Firewall ASA アプライアンスから NetFlow パケットを受信します。コネクタは、「NSEL イベントの処理」で説明されているように NetFlow レコードを処理し、フロー観測データを Cisco Secure Workload にエクスポートします。さらに、NATed フローの場合、コネクタは関連するフロー（クライアント側とサーバー側）をステッチします。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。コネクタでは、以下を設定できます。

• ログ：詳細については、「ログ設定」を参照してください。

さらに、許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの IPFIX プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。詳細については、「update-listening-ports」を参照してください。

Netflow プロトコルを使用すると、Meraki ファイアウォールなどのネットワークデバイスは、デバイスを通過するトラフィックをフローに集約し、それらのフローをフローコレクタにエクスポートできます。フローコレクタはこれらのフローレコードを受け取ると、オフラインでクエリと分析を行えるようにフローストレージに保存します。

通常、セットアップには次の手順が含まれます。

1. Meraki ファイアウォールで NetFlow 統計レポートを有効にします。

2. Meraki ファイアウォールで NetFlow コレクタのエンドポイント情報を設定します。

Meraki コネクタは、本質的に NetFlow コレクタです。コネクタは、NetFlow トラフィック統計をエクスポートするように設定されている Meraki ファイアウォールから、フローレコードを受信します。NetFlow レコードを処理し、Meraki ファイアウォールによって報告されたフロー観測を、フロー分析のために Secure Workload に送信します。Meraki コネクタは、Ingest アプライアンスで有効にすることができ、Docker コンテナとして実行されます。Secure Workload

Meraki コネクタは、Secure Workload Meraki エージェントとしても Secure Workload で登録されます。Meraki コネクタは、NetFlow プロトコルパケット（フローレコード）のカプセル化を解除します。次に、通常の Secure Workload エージェントのようにフローを処理してレポートします。Deep Visibility Agent とは異なり、プロセスやインターフェースの情報は報告しません。

（注）	Meraki コネクタは NetFlow v9 プロトコルをサポートしています。

（注）

各 Meraki コネクタは、1 つの VRF のフローのみを報告する必要があります。コネクタによってエクスポートされたフローは、Secure Workload クラスタのエージェント VRF 設定に基づいて VRF に配置されます。コネクタの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）]に移動し、[設定（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF設定（Agent Remote VRF Configurations）] セクションで、[設定の作成（Create Config）] をクリックし、コネクタに関する詳細を指定します。このフォームで、VRF の名前、コネクタの IP サブネット、およびフローレコードをクラスタに送信できる可能性のあるポート番号の範囲を提供するようにユーザーに要求します。

Meraki コネクタは、NetFlow レコードに基づいてフロー観察情報を Cisco Secure Workload に送信します。Meraki NetFlow フローレコードは双方向レコードです。したがって、Meraki コネクタは、Cisco Secure Workload への順方向フローと逆方向フローの 2 つのフローを送信します。

以下は、Meraki コネクタから Cisco Secure Workload に送信されるフロー観察情報の詳細です。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。コネクタでは、以下を設定できます。

• ログ：詳細については、「ログ設定」を参照してください。

さらに、許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの NetFlow v9 プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。詳細については、「update-listening-ports」を参照してください。

Encapsulated Remote Switch Port Analyzer（ERSPAN）は、ほとんどの Cisco スイッチに存在する機能です。ERSPAN は、ネットワークデバイスによって認識されるフレームをミラーリングし、IP パケットにカプセル化して、リモートアナライザに送信します。ユーザーは、監視するスイッチ上のインターフェイスや VLAN のリストを選択できます。

一般に、セットアップでは、1 つ以上のネットワークデバイスで送信元 ERSPAN モニタリングセッションを設定し、トラフィックアナライザに直接接続されているリモート ネットワーク デバイスで宛先 ERSPAN モニタリングセッションを設定します。

Secure Workload ERSPAN コネクタでは、宛先 ERSPAN セッションとトラフィックアナライザ機能の両方が提供されるため、Secure Workload ソリューションを使用してスイッチで宛先セッションを構成する必要はありません。

各 ERSPAN コネクタは、クラスタに SPAN エージェントを登録します。Secure Workload SPAN エージェントは、ERSPAN パケットのみを処理するように構成された通常の Secure Workload エージェントです。シスコの宛先 ERSPAN セッションと同様に、ミラーリングされたフレームのカプセル化を解除します。その後、通常の Secure Workload エージェントのようにフローを処理して報告します。優れた可視性エージェントとは異なり、プロセスやインターフェイスの情報を報告しません。

Secure WorkloadERSPAN の Ingest アプライアンスは、3 つの ERSPAN Secure Workloadコネクタを内部で実行する VM です。通常の Ingest アプライアンスと同じ OVA または QCOW2 を使用します。

各コネクタは、1 つの vNIC と 2 つの vCPU コア（制限クォータなし）が排他的に割り当てられた専用の Docker コンテナ内で実行されます。

ERSPAN コネクタは、コンテナホスト名 <VM hostname>-<interface IP address> を持つクラスタに ERSPAN エージェントを登録します。

コネクタとエージェントは、VM、Docker デーモン、または Docker コンテナのクラッシュまたは再起動時に、保持または復元されます。

（注）	ERSPAN コネクタのステータスは、[コネクタ（Connector）] ページに報告されます。[エージェントリスト（Agent List）] ページを参照して、対応する SPAN エージェントの状態を確認してください。

必要な仮想アプライアンスについては、「コネクタ用の仮想アプライアンス」を参照してください。ERSPAN コネクタの場合、IPv4 および IPv6（デュアルスタックモード）アドレスがサポートされます。ただし、デュアルスタックのサポートはベータ版の機能であることに注意してください。

次の手順は、Nexus 9000 スイッチ用です。他のシスコプラットフォームでは、設定方法が若干異なる場合があります。Cisco プラットフォームの設定については、『Cisco Secure Workload ユーザーガイド』を参照してください。

上記の手順により、ID 10 の送信元 ERSPAN セッションが作成されました。スイッチは、インターフェイス eth1/23 の入力と出力（ both）フレーム、および VLAN 315 と 512 上のフレームをミラーリングします。ミラーリングされたフレームを運ぶ外部 GRE パケットには、送信元 IP 172.28.126.1（このスイッチの L3 インターフェイスのアドレス）と宛先 IP 172.28.126.194 が含まれます。これは、ERSPAN VM で構成されている IP アドレスの 1 つです。

Secure Workload SPAN エージェントは、提案されている ERSPAN RFC で説明した ERSPAN タイプ I、II、および III パケットを処理できます。したがって、Cisco デバイスによって生成された ERSPAN パケットは処理可能です。RFC に準拠していない形式の中では、VMware vSphere Distributed Switch（VDS）によって生成された ERSPAN パケットを処理できます。

ERSPAN 送信元のポート/VLAN リストを慎重に選択します。SPAN エージェントには 2 つの専用 vCPU がありますが、セッションによって大量のパケットが生成され、エージェントの処理能力が飽和する可能性があります。エージェントが処理能力を超えるパケットを受信している場合、クラスタの [優れた可視性エージェント（Deep Visibility Agent）] ページの [エージェントパケット欠落（Agent Packet Misses）] グラフに表示されます。

ERSPAN 送信元がミラーリングするフレームの詳細な調整は、通常は filter 構成キーワードを指定し、ACL ポリシーを使用して行います。

スイッチでサポートされている場合、通常は mtu キーワードを使用して、ERSPAN パケットの最大伝送ユニット（MTU）を変更するように ERSPAN 送信元セッションを設定できます（通常、デフォルト値は 1500 バイト）。MTU 値を小さくすると、ネットワーク インフラストラクチャでの ERSPAN 帯域幅の使用が制限されますが、エージェントのワークロードはパケット単位であるため、SPAN エージェントの負荷には影響しません。MTU 値を小さくする場合は、ミラーフレーム用に 160 バイトのスペースを確保してください。ERSPAN ヘッダーオーバーヘッドの詳細については、提案されている ERSPAN RFC を参照してください。

ERSPAN には 3 つのバージョンがあります。バージョンが小さいほど、ERSPAN ヘッダーのオーバーヘッドは低くなります。バージョン II および III では、ERSPAN パケットに QoS ポリシーを適用し、複数の VLAN 情報を提供できます。バージョン III には、さらに多くの設定が含まれています。バージョン II は通常、Cisco スイッチのデフォルトです。Secure Workload SPAN エージェントは 3 つのバージョンをすべてサポートしていますが、現時点では、ERSPAN バージョン II および III パケットに含まれる追加情報は利用していません。

ERSPAN ゲスト オペレーティング システムの取り込み仮想マシンは CentOS 7.9 であり、そこから OpenSSL サーバー/クライアントパッケージが削除されています。

（注）	CentOS 7.9 は、Cisco Secure Workload 3.8.1.19 以前のリリースの Ingest および Edge 仮想アプライアンスのゲスト オペレーティング システムです。Cisco Secure Workload 3.8.1.36 以降、オペレーティングシステムは AlmaLinux 9.2 です。

VM が起動し、SPAN エージェント コンテナが展開されると（初回起動時のみ数分かかります）、ループバック以外のネットワーク インターフェイスは仮想マシンに表示されません。そのため、アプライアンスにアクセスするにはそのコンソールを使用するしか方法がありません。

VM ネットワーク インターフェイスは Docker コンテナ内に移動しました。コンテナは、TCP/UDP ポートを開かずに、centos:7.9.2009 ベースの Docker イメージを実行します。

（注）	Cisco Secure Workload 3.8.1.36 以降、コンテナは almalinux/9-base:9.2 を実行します。

また、コンテナは基本権限（–privileged オプションなし）に加え、NET_ADMIN 機能を使用して実行されます。

万が一、コンテナが侵害された場合でも、VM ゲスト OS はコンテナの内部から侵害されないようにするべきです。

ホスト内で実行される Secure Workload エージェントで有効な他のすべてのセキュリティ上の考慮事項は、Docker コンテナ内で実行される Secure Workload SPAN エージェントにも適用されます。

クラスタの [モニタリング/エージェントの概要（Monitoring/Agent Overview）] ページに SPAN エージェントがアクティブな状態で表示された後は、ERSPAN 仮想マシンで操作する必要はなく、ユーザーがログインする必要もありません。エージェントが表示されない場合や、フローがクラスタに報告されない場合は、次の情報が展開の問題を特定するのに役立ちます。

通常の状態では、VM で次の情報を表示できます。

• systemctl status tet_vm_setup により、SUCCESS 終了ステータスになっている非アクティブなサービスがレポートされます。

• systemctl status tet-nic-driver により、アクティブなサービスがレポートされます。

• docker network ls により、5 つのネットワーク（host、none および 3 つの erspan-<iface name>）がレポートされます。

• ip link により、ループバック インターフェイスのみがレポートされます。

• docker ps により、3 つの実行中のコンテナがレポートされます。

• 各コンテナの docker logs <cid> には次のメッセージが含まれます。INFO success: tet-sensor entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

• docker exec <cid> ifconfig により、ループバックに加えて 1 つのインターフェイスのみがレポートされます。

• docker exec <cid> route -n により、デフォルトゲートウェイがレポートされます。

• docker exec <cid> iptables -t raw -S PREROUTING により、ルール -A PREROUTING -p gre -j DROP がレポートされます。

上記のいずれにも当てはまらない場合は、/local/tetration/logs/tet_vm_setup.log の展開スクリプトログで、SPAN エージェントコンテナの展開が失敗した理由を確認します。

他のエージェントの登録/接続の問題は、docker exec コマンドを使用して、ホストで実行されているエージェントと同じ方法でトラブルシューティングできます。

• docker exec <cid> ps -ef により、tet-engine, tet-engine check_conf の 2 インスタンス、および /usr/local/tet/tet-sensor -f /usr/local/tet/conf/.sensor_config の 2 インスタンスがレポートされます。1 つは root ユーザー、もう 1 つは tet-sensor ユーザーに関するものです。加えて、プロセスマネージャ /usr/bin/ python /usr/bin/supervisord -c /etc/supervisord.conf -n インスタンスもレポートされます。

• docker exec <cid> cat /usr/local/tet/log/tet-sensor.log により、エージェントのログが表示されます。

• docker exec <cid> cat /usr/local/tet/log/fetch_sensor_id.log により、エージェントの登録ログが表示されます。

• docker exec <cid> cat /usr/local/tet/log/check_conf_update.log により、設定更新ポーリングログが表示されます。

  必要に応じて、tcpdump をコンテナのネットワーク名前空間に設定し、コンテナとの間のトラフィックをモニターできます。

  1. docker inspect <cid> | grep SandboxKey を使用して、コンテナのネットワーク名前空間（SandboxKey）を取得します。

  2. コンテナのネットワーク名前空間 nsenter --net=/var/run/docker/netns/... に対して設定します。

  3. eth0 traffic tcpdump -i eth0 -n をモニターします。

AnyConnect NVM は、オンプレミスとオフプレミスの両方でエンドポイントとユーザーの動作を可視化およびモニタリングします。次のコンテキストを含むエンドポイントから情報を収集します。

1. デバイス/エンドポイントコンテキスト：デバイス/エンドポイント固有の情報。

2. ユーザーコンテキスト：フローに関連付けられたユーザー。

3. アプリケーション コンテキスト：フローに関連付けられたプロセス。

4. ロケーションコンテキスト：ロケーション固有の属性（利用可能な場合）。

5. 接続先コンテキスト：宛先の FQDN。AnyConnect NVM は 3 つのタイプのレコードを生成します。

   NVM レコード	説明
   エンドポイントレコード	一意のデバイス識別子（UDID）、ホスト名、OS 名、OS バージョン、製造元などのデバイス/エンドポイント情報。
   インターフェイスレコード	エンドポイント UDID、インターフェイス固有識別子（UID）、インターフェイス インデックス、インターフェイスタイプ、インターフェイス名、MAC アドレスなど、エンドポイントの各インターフェイスに関する情報。
   Flow Record	エンドポイント UDID、インターフェイス UID、5 タプル（送信元/宛先 IP/ポートおよびプロトコル）、イン/アウトバイトカウント、プロセス情報、ユーザー情報、宛先の FQDN など、エンドポイントで観測されるフローについての情報。

各レコードは、IPFIX プロトコル形式で生成およびエクスポートされます。デバイスが信頼ネットワーク（オンプレミス/VPN）にある場合、AnyConnect NVM は設定されたコレクタにレコードをエクスポートします。AnyConnect コネクタは、AnyConnect NVM から IPFIX ストリームを受信して処理できる IPFIX コレクタの一例です。

（注）	AnyConnect コネクタは、Cisco AnyConnect セキュア モビリティ クライアントのバージョン 4.2 以降の AnyConnect NVM をサポートします。

Cisco Secure Firewall ASA または Cisco Identity Services Engine (ISE) を使用して AnyConnect NVM を導入する手順については、『How to Implement AnyConnect NVM』[英語] を参照してください。NVM モジュールが展開されたら、NVM プロファイルを指定し、Cisco AnyConnect セキュア モビリティ クライアントを稼働中のエンドポイントにプッシュしてインストールする必要があります。NVM プロファイルを指定する際、ポート 4739 の AnyConnect コネクタを指すように IPFIX コレクタを設定する必要があります。

AnyConnect コネクタは、Secure Workload AnyConnect プロキシ エージェントとして Secure Workload にも登録されます。

AnyConnect コネクタは、次に示すように AnyConnect NVM レコードを処理します。

エンドポイントレコード

AnyConnect コネクタがエンドポイントレコードを受信すると、そのエンドポイントは Cisco Secure Workload 上の AnyConnect エージェントとして登録されます。AnyConnect コネクタは、NVM レコードに存在するエンドポイント固有の情報と AnyConnect コネクタの証明書を使用して、エンドポイントを登録します。エンドポイントが登録されると、Cisco Secure Workload 内のいずれかのコレクタへの新しい接続を作成することにより、エンドポイントのデータプレーンが有効になります。このエンドポイントからのアクティビティ（フローレコード）に基づいて、AnyConnect コネクタは、クラスタでこのエンドポイントに対応する AnyConnect エージェントを定期的に（20 ～ 30 分）チェックインします。

AnyConnect NVM は、4.9 以降のエージェントバージョンで送信を開始します。デフォルトでは、AnyConnect エンドポイントは Cisco Secure Workload 上でバージョン 4.2.x として登録されます。このバージョンは、サポートされる AnyConnect NVM の最小バージョンを意味します。バージョン 4.9 以降の AnyConnect エンドポイントの場合、Secure Workload 上の対応する AnyConnect エージェントには、インストールされている実際のバージョンが示されます。

（注）	AnyConnect エージェントのインストールバージョンは、Cisco Secure Workload によって制御されません。Secure Workload UI で AnyConnect エンドポイントエージェントをアップグレードしようとしても、効果がありません。

Flow Record

フローレコードを受信すると、AnyConnect コネクタはそのレコードを Secure Workload が認識できる形式に変換し、そのエンドポイントに対応するデータプレーンを介して FlowInfo を送信します。さらに、フローレコードに含まれるプロセス情報をローカルに保存します。また、AnyConnect コネクタに LDAP 設定が提供されている場合、エンドポイントのログインユーザーの設定済み LDAP 属性の値が決定されます。属性は、フローが発生したエンドポイントの IP アドレスに関連付けられています。定期的に、プロセス情報とユーザーラベルが Cisco Secure Workload にプッシュされます。

（注）

各 AnyConnect コネクタは、1 つの VRF のみのエンドポイント/インターフェイス/フローを報告します。AnyConnect コネクタによって報告されるエンドポイントとインターフェイスは、Cisco Secure Workload のエージェント VRF コンフィギュレーションに基づいて VRF に関連付けられます。AnyConnect エンドポイントの代わりに AnyConnect コネクタエージェントによってエクスポートされたフローは、同じ VRF に属します。エージェントの VRF を設定するには、[管理（Manage）] > [エージェント（Agents）] に移動し、[構成（Configuration）] タブをクリックします。このページの [エージェントのリモートVRF構成（Agent Remote VRF Configurations）] セクションで、[構成の作成（Create Config）] をクリックし、AnyConnect コネクタに関する詳細を指定します。このフォームでは、VRF の名前、エージェントがインストールされているホストの IP サブネット、およびフローレコードをクラスタに送信する可能性のあるポート番号の範囲を提供するようにユーザーに要求します。

エンドポイントマシンが同じゴールデンイメージから複製された場合、複製されたすべてのエンドポイントの UDID が同一である可能性があります。同一の場合、AnyConnect コネクタは、同一の UDID を持つエンドポイントからエンドポイントレコードを受信し、同じ UDID で Secure Workload に登録します。コネクタは、それらのエンドポイントからインターフェイスまたはフローレコードを受信すると、データを関連付けるために Secure Workload の正しい AnyConnect エージェントを判別できないため、すべてのデータを 1 つのエンドポイントに関連付けます（確定的ではありません）。

この問題に対処するために、AnyConnect NVM 4.8 リリースには、エンドポイントで UDID を見つけて再生成する dartcli.exe というツールが同梱されています。

• dartcli.exe -u は、エンドポイントの UDID を取得します。

• dartcli.exe -nu は、エンドポイントの UDID を再生成します。このツールを実行するには、次の手順を使用します。

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
    UDID : 8D0D1E8FA0AB09BE82599F10068593E41EF1BFFF

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -nu
    Are you sure you want to re-generate UDID [y/n]: y
    Adding nonce success
    UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
    UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5

AnyConnect コネクタは、AnyConnect エンドポイントインベントリでプロセススナップショットとユーザーラベルを定期的に送信します。

1. [プロセススナップショット（Process Snapshot）]：AnyConnect コネクタは、5 分ごとに、その間隔でローカルで保持されているプロセスを調べ、その間隔中にフローがあったすべてのエンドポイントのプロセススナップショットを送信します。

2. [ユーザーラベル（User Labels）]：AnyConnect コネクタは、2 分ごとに、ローカルで保持されている LDAP ユーザーラベルを調べ、それらの IP アドレスのユーザーラベルを更新します。

ユーザーラベル用に、AnyConnect コネクタは、組織に属する全ユーザーの LDAP 属性のローカルスナップショットを作成します。AnyConnect コネクタが有効になっている場合、LDAP の設定（サーバー/ポート情報、ユーザーに関して取得される属性、ユーザー名を含む属性）が提供される場合があります。さらに、LDAP サーバーにアクセスするための LDAP ユーザーログイン情報が提供されることもあります。LDAP ユーザーログイン情報は暗号化され、AnyConnect コネクタで公開されることはありません。オプションで、LDAP サーバーに安全にアクセスするための LDAP 証明書の提供も可能です。

（注）	AnyConnect コネクタは、24 時間ごとに新しいローカル LDAP スナップショットを作成します。この間隔は、コネクタの LDAP 設定で変更できます。

必要な仮想アプライアンスについては、「コネクタの仮想アプライアンス」を参照してください。コネクタでは、以下を設定できます。

• LDAP：LDAP 設定は、LDAP 属性の検出をサポートし、ユーザー名に対応する属性を選択するワークフローと、ユーザーごとに取得される最大 6 つの属性のリストを提供します。詳細については、「検出」を参照してください。

• エンドポイント：詳細については、「エンドポイントの設定」を参照してください。

• ログ：詳細については、「ログ設定」を参照してください。

さらに、許可されたコマンドを使用して、Secure Workload Ingest アプライアンスの Docker コンテナで、コネクタの IPFIX プロトコルのリスニングポートを更新できます。このコマンドは、コネクタのコネクタ ID、更新するポートのタイプ、および新しいポートの情報が提供されると、アプライアンスで発行できます。コネクタ ID は、Secure Workload UI の [コネクタ（connector）] ページにあります。詳細については、「update-listening-ports」を参照してください。

（注）	この統合には、ISE バージョン 2.4+ と ISE PIC バージョン 3.1+ が必要です。

必要な仮想アプライアンスについては、「コネクタ用の仮想アプライアンス」を参照してください。ISE コネクタの場合、IPv4 および IPv6（デュアルスタックモード）アドレスがサポートされます。ただし、デュアルスタックのサポートはベータ機能であることに注意してください。

コネクタでは、次の設定が許可されています。

• ISE インスタンス：ISE コネクタは、指定された設定を使用して ISE の複数のインスタンスに接続できます。各インスタンスには、ISE に接続するためのホスト名およびノード名とともに ISE 証明書のログイン情報が必要です。詳細については、「ISE インスタンスの設定」を参照してください。

• LDAP：LDAP 設定は、LDAP 属性の検出をサポートし、ユーザー名に対応する属性を選択するワークフローと、ユーザーごとに取得される最大 6 つの属性のリストを提供します。詳細については、「検出」を参照してください。

• ログ：詳細については、「ログ設定」を参照してください。

  （注）	ISE コネクタは getSessions API コールに接続して、タイムフレームの間にすべてのアクティブエンドポイントを取得します。ISE コネクタには、すべての新しいエンドポイントの更新を提供する PxGrid のセッショントピックに登録するリスナーもあります。

ISE コネクタは、次に説明するようにレコードを処理します。

ISE コネクタは、ISE エンドポイントインベントリでユーザーラベルを定期的に共有します。

1. [エンドポイントスナップショット（Endpoint Snapshots）]：20 時間ごとに、ISE コネクタは、エンドポイントとセキュリティグループラベルのスナップショットを ISE インスタンスから取得し、変更が検出された場合はクラスタを更新します。このコールでは、ISE からの Secure Workload でエンドポイントが表示されない場合に切断されるエンドポイントは検出対象になりません。

2. [ユーザーラベル（User Labels）]：2 分ごとに、ISE コネクタは、ローカルで保持されている LDAP ユーザーと ISE エンドポイントラベルをスキャンし、それらの IP アドレスのユーザーラベルを更新します。

ユーザーラベル用に、ISE コネクタは、組織に属する全ユーザーの LDAP 属性のローカルスナップショットを作成します。ISE コネクタが有効になっている場合、LDAP の設定（サーバー/ポート情報、ユーザーに関して取得される属性、ユーザー名を含む属性）が提供される場合があります。さらに、LDAP サーバーにアクセスするための LDAP ユーザーログイン情報が提供されることもあります。LDAP ユーザーログイン情報は暗号化され、ISE コネクタで公開されることはありません。オプションで、LDAP サーバーに安全にアクセスするための LDAP 証明書の提供も可能です。

（注）	ISE コネクタは、24 時間ごとに新しいローカル LDAP スナップショットを作成します。この間隔は、コネクタの LDAP 設定で変更できます。

（注）	Cisco ISE デバイスのアップグレード時は、アップグレード後に ISE によって生成される新しい証明書を使用して ISE コネクタを再設定する必要があります。

アプライアンス/コネクタからのハートビートが欠落しているためにアプライアンス（またはコネクタ）がダウンしている可能性がある場合、アラートが生成されます。

アラートテキスト：<アプライアンス/コネクタ> のハートビートがありません。ダウンしている可能性があります。（Missing <Appliance/Connector> heartbeats, it might be down.）

重大度：高

許可された Secure Workload 仮想アプライアンス：Secure Workload Ingest および Secure Workload Edge

許可されたコネクタ：すべて

アプライアンス（およびコネクタ）のシステム使用率（CPU、メモリ、およびディスク）が 90% を超えると、アプライアンス（とコネクタのいずれかまたは両方）が、増加したシステム負荷を現在処理していることを示す情報アラートを生成します。

アプライアンスとコネクタが大量の処理アクティビティ中にシステムリソースの 90% 以上を消費することがありますが、これは正常です。

アラートテキスト：<アプライアンス/コネクタ> での <数字> 個の CPU/メモリ/ディスク使用率が高すぎます。

重大度：高

許可された Secure Workload 仮想アプライアンス：Secure Workload Ingest および Secure Workload Edge

許可されたコネクタ：すべて

構成済みのコネクタを構成済みのサーバーに接続しようとして、構成エラーが発生すると、システムは、承認されて展開された構成に潜在的な問題があることを示すアラートを生成します。

たとえば、AnyConnect コネクタは LDAP 構成を取得し、構成を検証して受け入れることができますが、通常の操作中に、構成が無効になる可能性があります。

アラートは、このシナリオをキャプチャし、構成を更新するための修正アクションをユーザーが実行する必要があることを示します。

アラートテキスト：Cannot connect to <Appliance/Connector> server, check <Appliance/Connector> config.

重大度：高、低

許可されている Secure Workload 仮想アプライアンス：Secure Workload Ingest および Secure Workload Edge

許可されているコネクタ：AnyConnect、F5、ISE、WDC、ServiceNow。

Cisco Secure Workload Ingest アプライアンスは、さまざまなコネクタから Secure Workload にフロー観測をエクスポートできるソフトウェアアプライアンスです。

仕様

• CPUコア数：8

• メモリ：8 GB

• ストレージ：250 GB

• ネットワークインターフェイスの数：3

• 1 つのアプライアンスにおけるコネクタ数：3

• オペレーティングシステム：CentOS 7.9（Cisco Secure Workload 3.8.1.19 以前）、AlmaLinux 9.2（Cisco Secure Workload 3.8.1.36 以降）

「コネクタ用の Cisco Secure Workload 仮想アプライアンス」で、重要な制限事項を確認してください。

（注）	Secure Workload のルート範囲には、最大 100 の Secure Workload Ingest アプライアンスを展開できます。

Cisco Secure Workload Ingest アプライアンスでは、1 つのアプライアンスで最大 3 つのコネクタを有効にできます。同じアプライアンスで、同じコネクタの複数のインスタンスを有効にすることができます。ERSPAN Ingest アプライアンスの場合、3 つの ERSPAN コネクタが常に自動的にプロビジョニングされます。Ingest アプライアンスに展開されたコネクタの多くは、ネットワーク内のさまざまなポイントからテレメトリを収集します。これらのコネクタは、アプライアンスの特定のポートでリッスンする必要があります。そのため、各コネクタは、テレメトリデータを収集するためにコネクタがリッスンする必要がある IP アドレスとデフォルトポートのいずれかにバインドされます。その結果、各 IP アドレスは基本的に、アプライアンス上でコネクタが占有するスロットになります。コネクタが有効になると、スロットが使用されます（これにより、スロットに対応する IP が使用されます）。また、コネクタが無効になると、コネクタが占有していたスロットが解放されます（これにより、スロットに対応する IP が解放されます）。Ingest アプライアンスがスロットの状態を維持する方法については、「Cisco Secure Workload Ingest アプライアンスのスロット」を参照してください。

Cisco Secure Workload Edge は、さまざまな通知者にアラートをストリーミングし、Cisco ISE などのネットワーク アクセス コントローラからインベントリメタデータを収集する、制御アプライアンスです。Secure Workload Edge アプライアンスでは、すべてのアラート通知コネクタ（Syslog、電子メール、Slack、PagerDuty、Kinesisなど）、ServiceNow コネクタ、ワークロード AD コネクタ、および ISE コネクタを展開できます。

仕様

• CPUコア数：8

• メモリ：8 GB

• ストレージ：250 GB

• ネットワークインターフェイスの数：1

• 1 つのアプライアンスのコネクタの数：8

• オペレーティングシステム：CentOS 7.9（Cisco Secure Workload 3.8.1.19 以前）、AlmaLinux 9.2（Cisco Secure Workload 3.8.1.36 以降）

「コネクタ用の Cisco Secure Workload 仮想アプライアンス」で、重要な制限事項を確認してください。

（注）	Secure Workload のルート範囲には、最大 1 つの Secure Workload Edge アプライアンスを展開できます。

Secure Workload Edge アプライアンスに展開されたコネクタは、ポートでリッスンしません。したがって、Secure Workload Edge アプライアンスのコネクタ用にインスタンス化された Docker コンテナは、ポートをホストに公開しません。

NTP の設定により、アプライアンスは指定された NTP サーバーとクロックを同期できます。

テスト：ポート 123 で指定された NTP サーバーに対して UDP 接続を確立できるかどうかをテストします。いずれかの NTP サーバーでエラーが発生した場合は、この設定を受け入れないでください。

# --- GENERAL CONFIGURATION ---
server <ntp-server>
...
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# Drift file
driftfile /etc/ntp/drift

（注）	Cisco Secure Workload 3.8.1.19 以前に適用されます。

# Secure Workload appliance chrony.conf.
server <ntp-server> iburst
...
driftfile /var/lin/chrony/drift
makestep 1.0 3
rtcsync

許可されている Cisco Secure Workload 仮想アプライアンス：すべて

許可されているコネクタ：なし

ログ構成により、アプライアンスやコネクタのログレベル、ログファイルの最大サイズ、ログ ローテーション パラメータが更新されます。アプライアンスで構成の更新がトリガーされると、アプライアンスコントローラのログ設定が更新されます。一方、コネクタで構成の更新がトリガーされると、サービスコントローラとサービスログの設定が更新されます。

テスト：運用なし。

適用：アプライアンスで構成がトリガーされた場合は、アプライアンスの tet-controller の構成ファイルが更新されます。構成がコネクタでトリガーされた場合は、tet-controller の構成ファイルと、コネクタを管理する Docker コンテナ上のコントローラによって管理されるサービスが更新されます。

許可されている Secure Workload 仮想アプライアンス：すべて

許可されているコネクタ：NetFlow、NetScaler、F5、AnyConnect、ISE、ASA、Meraki。

（注）	すべてのアラート通知コネクタ（Syslog、Email、Slack、PagerDuty、Kinesis）は Secure Workload Edge 上の単一の Docker サービス（Cisco Secure Workload Alert Notifier）で実行されるため、別のアラート通知コネクタの構成に影響を与えずにコネクタのログ構成を更新することはできません 。Secure Workload Edge アプライアンス上の Secure Workload Alert Notifier（TAN）Docker サービスのログ構成は、許可されたコマンドを使用して更新できます。

詳細については、「アラート通知コネクタのログ構成の更新」を参照してください。

エンドポイントの設定では、AnyConnect および ISE コネクタのエンドポイントの非アクティブタイムアウトを指定します。エンドポイントがタイムアウトすると、コネクタは Secure Workload とのチェックインを停止し、コネクタ上のエンドポイントのローカル状態を消去します。

テスト：運用なし。

適用：新しい値でコネクタの構成ファイルを更新します。

許可されている Secure Workload 仮想アプライアンス：なし

許可されているコネクタ：AnyConnect および ISE

Slack で Secure Workload アラートを公開するためのデフォルトの構成。

テスト：ウェブフックを使用してテストアラートを Slack に送信します。アラートが正常に投稿された場合、テストは合格です。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されているコネクタ：Slack

PagerDuty で Secure Workload アラートを公開するためのデフォルト設定。

テスト： サービスキーを使用してテストアラートを PagerDuty に送信します。アラートが正常に発行された場合、テストは合格です。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されたコネクタ：PagerDuty

Amazon Kinesis で Secure Workload アラートを公開するためのデフォルトの設定。

テスト：指定された設定を使用して、テストアラートを Kinesis ストリームに送信します。アラートが正常に発行された場合、テストは合格です。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されているコネクタ：Kinesis

電子メールで Secure Workload アラートを公開するためのデフォルト設定です。

[テスト（Test）]：指定された設定を使用してテスト電子メールを送信します。アラートが正常に発行された場合、テストは合格です。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されるコネクタ：電子メール

Syslog で Secure Workload アラートを公開するためのデフォルト構成。

テスト：指定された構成を使用して、テストアラートを Syslog サーバーに送信します。アラートが正常に発行された場合、テストは合格です。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されるコネクタ：Syslog

次の表は、Syslog の Secure Workload アラートにおけるデフォルトのシビラティ（重大度）マッピングを示しています。

この設定は、次の設定を使用して変更できます。

[テスト（Test）]：運用なし。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されるコネクタ：Syslog

この設定では、Cisco Identity Services Engine（ISE）に接続するために必要なパラメータを指定します。この構成の複数のインスタンスを提供することにより、ISE コネクタは複数の ISE アプライアンスに接続してエンドポイントに関するメタデータをプルできます。最大 20 のISE 構成インスタンスを提供できます。

テスト：指定されたパラメータを使用して ISE に接続します。接続に成功したら、構成を受け入れます。

[適用（Apply）]：指定されたパラメータでコネクタの構成ファイルを更新します。

許可される Secure Workload 仮想アプライアンス：なし

許可されているコネクタ：ISE

• 使用している Kubernetes バージョンがサポートされていることを確認します。https://www.cisco.com/go/secure-workload/requirements/integrationsを参照してください。

• 以下の説明に従い、EKS で必要なアクセスを構成します。

クラスタロールとユーザー/サービスアカウントの、クラスタ ロール バインディングを作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csw-clusterrolebinging 
subjects:
- kind: User
  name: csw.read.only
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: csw.read.only
  apiGroup: rbac.authorization.k8s.io
  kubectl create -f clusterrolebinding.yaml 
clusterrolebinding.rbac.authorization.k8s.io/csw-clusterrolebinging created

EKS ロールとアクセスの詳細については、「EKS ロールおよびアクセス権限」の項を参照してください。

AWS コネクタを設定するときに、マネージド Kubernetes サービスの機能を有効にします。「新しい AWS コネクタの作成」を参照してください。

EKS クラスタごとに Assume Role ARN が必要になります。詳細については、以下を参照してください。 https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

AWS ユーザーを使用して EKS クラスタにアクセスしている場合は、そのユーザーに Assume Role へのアクセスを許可します。

クロスアカウントの IAM ロールを使用している場合は、IAM ロールが Assume Role にアクセスすることを許可します。

EKS で、ロードバランササービスのサポートが追加されました。CSW エージェントは、コンシューマホストとプロバイダーホスト/ポッドにルールを適用します。

EKS ロードバランサには、次の 2 つのオプションがあります。

1. [クライアントIPの保持（Preserve Client IP）]。

2. プロバイダーポッドで生成

3. [ターゲットタイプ（Target Type）]。

ケースを開始する前、次のポリシーインテントの場合：

次のように生成された、さまざまなケースの許可アクションルールを持つ、コンシューマからプロバイダーへのサービス、サービスプロトコル、およびポート：

ケース 1：

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノードにホストルールはありませんが、送信元をコンシューマ、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、プロバイダーポッドに入力ルールを生成します。

ケース 2：

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノードには、送信元をコンシューマ、宛先をすべてのプロバイダーノード、プロトコルをサービスプロトコル、ポートをサービスのノードポート、アクションを許可として生成された、事前ルーティングルールがあります。

プロバイダーポッドでは、送信元をプロバイダーノード、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、入力ルールを生成します。

ケース 3：

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノードにホストルールはありません。プロバイダーポッドでは、送信元を lb 入力 IP、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、入力ルールを生成します。

ケース 4：

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノードは、lb 入力 IP を送信元として設定し、すべてのプロバイダーノードを宛先として設定する、事前ルーティングルールを生成します。このルールでは、サービスプロトコルをプロトコルとして指定し、サービスのノードポートをポートとして指定し、アクションを許可に設定します。

プロバイダーポッドでは、送信元をプロバイダーノード、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、入力ルールを生成します。

• 使用している Kubernetes バージョンがサポートされていることを確認します。Cisco Secure Workload エージェントのオペレーティングシステム、外部システム、およびコネクタについては、「互換性マトリックス」を参照してください。

• Azure コネクタを構成するときに、マネージド Kubernetes サービス（AKS）機能を有効にして構成します。詳細については、「Azure コネクタの設定」の項を参照してください。

AKS は、クライアント IP の保持をサポートしています。

次のポリシーインテントの場合：

次のように生成された、さまざまなケースの許可アクションルールを持つ、コンシューマからプロバイダーへのサービス、サービスプロトコル、およびポート：

ケース 1：クライアント IP の保持がオンになっている。

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノード用に事前ルーティングルールが生成されます。このルールは、コンシューマを送信元として指定し、すべてのプロバイダーノードを宛先として指定します。このルールでは、サービスプロトコルをプロトコルとして含め、サービスのノードポートをポートとして含め、アクションを許可に設定します。

プロバイダーポッドでは、送信元をプロバイダーノード、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、入力ルールを生成します。

ケース 2：クライアント IP の保持がオフになっている。

コンシューマノードで、コンシューマからロードバランササービス（lb 入力 ip）へのサービスプロトコルとポートの許可を使用して出力ルールを生成します。

プロバイダーノードは、lb 入力 IP を送信元として設定し、すべてのプロバイダーノードを宛先として設定する、事前ルーティングルールを生成します。このルールでは、サービスプロトコルをプロトコルとして指定し、サービスのノードポートをポートとして指定し、アクションを許可に設定します。

プロバイダーポッドでは、送信元をプロバイダーノード、宛先をプロバイダーポッド（任意）、プロトコルをターゲットプロトコル、ポートをターゲットポート、アクションを許可として、入力ルールを生成します。

Cisco Secure Workload の要件：このコネクタには仮想アプライアンスは不要です。

プラットフォーム要件：

• このコネクタに必要なアクセスを設定するための権限が GCP にあることを確認してください。

• 各 GKE クラスタは、1 つの GCP コネクタにのみ属することができます。

• 次の「GCP コネクタの設定」の表に記載されている情報を収集します。

GKE の要件：

• GKE で必要なアクセス権限を設定する必要があります。

• マネージド K8s 機能をサポートするために、サービスアカウントに必要なロールは次のとおりです。

  • Compute Network Viewer は、GCP 内のすべてのネットワークリソースへの読み取り専用アクセスを許可する IAM ロールです。https://cloud.google.com/compute/docs/access/iam#compute.networkViewer

  • Kubernetes Engine Viewer は、GKE クラスタ内のリソース（ノード、ポッド、GKE API オブジェクトなど）への読み取り専用アクセスを提供する GKE クラスタロールです。 https://cloud.google.com/iam/docs/understanding-roles#kubernetes-engine-roles