CloudSec 暗号化

Cisco ACI CloudSec 暗号化

ほとんどの Cisco ACI 展開で、ディザスタリカバリとスケーリングに対処する Multi-Site アーキテクチャを採用しているため、ローカルサイト内で MACsec 暗号化を使用する現在のセキュリティ実装は、複数のサイトにわたるデータセキュリティと整合性を保証するには不十分になっています。それらのサイトは、安全でない外部 IP ネットワークによって接続されており、個別のファブリックを相互接続しているからです。Nexus Dashboard Orchestrator リリース 2.0(1) は、トラフィックのサイト間暗号化を提供するために設計された CloudSec 暗号化を導入しています。

Multi-Site トポロジはサイト間の接続を提供するために、3 つのトンネルエンドポイント (TEP) IP アドレスを使用します。これらの TEP アドレスは、 Nexus Dashboard Orchestrator の管理者により設定され、各サイトの Cisco APIC にプッシュダウンされ、その後スパインスイッチで設定されます。これらの 3 つのアドレスは、トラフィックがリモートサイトに送信されるタイミングを決定するために使用されます。この場合、2 つのスパインスイッチ間に暗号化された CloudSec トンネルが作成され、サイト間ネットワーク (ISN) を介して 2 つのサイト間の物理接続が提供されます。

次の図は、ローカルサイトトラフィックの MACsec とサイト間トラフィックの暗号化に CloudSec を組み合わせた全体的な暗号化アプローチを示しています。

Requirements and Guidelines

When configuring CloudSec encryption, the following guidelines apply:

CloudSec has been validated using a Nexus 9000 Inter-Site Network (ISN) infrastructure. If your ISN infrastructure is made up of different devices, or the devices are unknown (such as in the case of circuits purchased from a service provider), it is required that an ASR1K router is the first hop device directly connected to the ACI spine (with a separate pair of ASR1K devices deployed in each site), or the Nexus 9000 ISN network. The ASR1K router with padding-fixup enabled allows the CloudSec traffic to traverse any IP network between the sites.

To configure an ASR1K router:
1. Log in to the device.
2. Configure the UDP ports.
```
ASR1K(config)# platform cloudsec padding-fixup dst-udp-port 9999
```
3. Verify the configuration.
```
ASR1K# show platform software ip rp active cloudsec
  CloudSec Debug: disabled
  CloudSec UDP destination port: enabled
  1st UDP destination port: 9999
  2nd UDP destination port: 0
  3rd UDP destination port: 0

ASR1K# show platform software ip fp active cloudsec
  CloudSec Debug: disabled
  CloudSec UDP destination port: enabled
  1st UDP destination port: 9999
  2nd UDP destination port: 0
  3rd UDP destination port: 0
```
If one or more spine switches are down when you attempt to disable CloudSec encryption, the disable process will not complete on those switches until the switches are up. This may result in packet drops on the switches when they come back up.

We recommend you ensure that all spine switches in the fabric are up or completely decommissioned before enabling or disabling CloudSec encryption.
The CloudSec Encryption feature is not supported with the following features:
- Precision Time Protocol (PTP)
- Remote Leaf Direct
- Virtual Pod (vPOD)
- SDA
- Intersite L3Out, if the sites are running Cisco APIC releases prior to 5.2(4).
  
  CloudSec is supported with intersite L3Out for APIC sites running release 5.2(4) or later.
- Other routable TEP configurations

Requirements

The CloudSec encryption capability requires the following:

Cisco ACI spine-leaf architecture with a Cisco APIC cluster for each site
Cisco Nexus Dashboard Orchestrator to manage each site
One Advantage or Premier license per each device (leaf only) in the fabric
An add-on license ACI-SEC-XF per device for encryption if the device is a fixed spine
An add-on license ACI-SEC-XM per device for encryption if the device is a modular spine

The following table provides the hardware platforms and the port ranges that are capable of CloudSec encryption.


Hardware Platform	Port Range
N9K-C9364C spine switches	Ports 49-64
N9K-C9332C spine switches	Ports 25-32
N9K-X9736C-FX line cards	Ports 29-36

If CloudSec is enabled for a site, but the encryption is not supported by the ports, a fault is raised with unsupported-interface error message.

CloudSec encryption's packet encapsulation is supported if Cisco QSFP-to-SFP Adapters (QSA), such as CVR-QSFP-SFP10G, is used with a supported optic. The full list of supported optics is available from the following link: https://www.cisco.com/c/en/us/support/interfaces-modules/transceiver-modules/products-device-support-tables-list.html.

CloudSec 暗号化に関する用語

CloudSec 暗号化機能は、サイト間の初期キーとキー再生成の要件に対して、安全なアップストリーム対称キーの割り当てと配布方法を提供します。この章では、次の用語を使用します。

アップストリームデバイス – CloudSec 暗号化ヘッダーを追加し、ローカルで生成された対称暗号化キーを使用してリモートサイトへの送信時に VXLAN パケットペイロードの暗号化を行うデバイス。
ダウンストリームデバイス – CloudSec 暗号化ヘッダーを解釈し、リモートサイトで生成された暗号化キーを使用して受信時に VXLAN パケットペイロードの復号化を行うデバイス。
アップストリームサイト – 暗号化された VXLAN パケットを発信するデータセンターファブリック。
ダウンストリームサイト – 暗号化されたパケットを受信して復号するデータセンターファブリック。
TX キー – クリアな VXLAN パケットペイロードを暗号化するために使用される暗号化キー。ACI では、1 つの TX キーがすべてのリモートサイトに対してアクティブであることができます。
RX キー – 暗号化された VXLAN パケットペイロードを復号するために使用される暗号化キー。ACI では、2 つの RX キーをリモートサイトごとにアクティブにできます。

2 つの RX キーをキーの再生成プロセス中に同時にアクティブにすることができます。ダウンストリームサイトは、新しいキーの展開が一定期間終了した後、古い RX キーと新しい RX キーを保持し、いずれかのキーを適切に復号することで、順序どおりでないパケット配信が可能になるようにします。
対象キー – 同じ暗号化キーを使用して、アップストリームデバイスとダウンストリームデバイスによるパケットストリームの暗号化 (TX キー) と復号 (RX キー) をそれぞれ行う場合。
キーの再生成 – 古いキーの有効期限が切れた後、すべてのダウンストリームサイトの古いキーを新しいキーに置き換えるためにアップストリームサイトによって開始されたプロセス。
安全なチャネル識別子 (SCI) – サイト間のセキュリティ関連付けを表す 64 ビット識別子。CloudSec ヘッダーの暗号化されたパケットで送信され、パケットの復号化のためにダウンストリームデバイスの RX キーを取得するために使用されます。
アソシエーション番号値 (AN) – 暗号化されたパケットのCloudSecヘッダーで送信される2ビットの数値( 0, 1, 2, 3)。これは、復号化のために SCI とともにダウンストリームデバイスでキーを導出するために使用されます。これにより、ダウンストリームデバイスで複数のキーをアクティブにして、キーの再生成操作の後で、同じアップストリームデバイスからの異なるキーを使用したパケットの順序どおりでない到着を処理できます。

ACI では、2 つのアクティブな RX キーには 2 つのアソシエーション番号値（0 または 1 1）のみが使用され、TX キーには常に 1 つのアソシエーション番号値（0 または 1）のみが使用されます。
事前共有キー (PSK) – CloudSec TX および RX キーを生成するためのランダムシードとして使用するには、Cisco APIC GUI で 1 つ以上のキーを設定する必要があります。複数の PSK が設定される場合、各キーの再生成プロセスはインデックスの順序で次の PSK を使用します。さらに高いインデックスの PSK がない場合、最下位のインデックスの PSK が使用されます。各 PSK は、64文字の長さの16進数ストリングでなければなりません。Cisco APIC は最大256の事前共有キーをサポートします。

CloudSec の暗号化と復号の処理

リリース 2.0(1) 以降では、データセキュリティと整合性の両方に対応する、完全に統合されたシンプルでコスト効率の高いソリューションを提供するために、Multi-Site は Multi-Site ファブリック間の送信元から宛先への完全なパケット暗号化を可能にする CloudSec 暗号化機能を提供します。

次の図は、CloudSec カプセル化の前後のパケットダイアグラムと、その後の暗号化および復号化プロセスの説明を示しています。

パケット暗号化

次に、CloudSec が発信トラフィックパケットを処理する方法の概要を示します。

パケットは、外部 IP ヘッダーとレイヤ 4 宛先ポート情報を使用してフィルタ処理され、一致するパケットは暗号化の対象としてマークされます。
暗号化に使用するオフセットは、パケットのフィールドに基づいて計算されます。たとえば、オフセットは、802.1q VLAN があるかどうか、またはパケットが IPv4 または IPv6 パケットであるかどうかによって異なります。
暗号キーはハードウェアテーブルでプログラムされ、パケット IP ヘッダーを使用してテーブルから検索されます。

パケットに暗号化のマークが付けられると、暗号キーがロードされ、暗号化を開始するパケットの先頭からのオフセットが判明すると、次の追加の手順が実行されます。

UDP 宛先ポート番号は、UDP ヘッダーから CloudSec フィールドにコピーされ、パケットが暗号解読されるときにリカバリされます。
UDP 宛先ポート番号は、CloudSec パケットであることを示すシスコ独自のレイヤ 4 ポート番号（ポート 9999）で上書きされます。
[UDP 長(UDP length)] フィールドは、追加されるバイト数を反映するように更新されます。
CloudSec ヘッダーは、UDP ヘッダーの後に直接挿入されます。
整合性チェック値 (ICV) は、ペイロードと CRC の間のパケットの最後に挿入されます。
ICV では、128 ビットの初期化ベクトルを構築する必要があります。CloudSec の場合、ICV のために送信元 MAC アドレスを使用すると、SCI ごとのプログラム可能な値に置き換えられます。
CRC は、パケットのコンテンツの変更を反映するように更新されます。

パケットの暗号解読

CloudSec が受信パケットを処理する方法は、上記で説明した発信パケットアルゴリズムと対称的です。

受信したパケットが CloudSec パケットである場合は、暗号解読され、ICV が検証されます。

ICV 検証に合格すると、追加フィールドが削除され、UDP 宛先ポート番号が CloudSec ヘッダーから UDP ヘッダーに移動され、CRC が更新され、パケットの暗号解読と CloudSec ヘッダーの削除後に宛先に転送されます。そうでない場合、パケットはドロップされます。
キーストアが2つ以上の可能な暗号解読キーを返す場合、CloudSec ヘッダーの Association Number (AN) フィールドを使用して、使用するキーを選択します。
パケットが CloudSec パケットでない場合、パケットはそのまま残ります。

CloudSec 暗号化キーの割り当てと配布

初期キー構成

次に、上記の図に示されている CloudSec 暗号キーの初期割り当ておよび配信プロセスの概要を示します。

アップストリームサイトの Cisco APIC は、サイトから送信された VXLAN パケットのデータ暗号化に使用されるためのローカル対称キーを生成します。アップストリームサイトが暗号化に使用するのと同じキーが、ダウンストリームリモート受信サイトのパケットの復号に使用されます。

各サイトはほかのサイトに送信するトラフィックのためのアップストリームサイトです。複数のサイトが存在する場合、各サイトは独自のサイトツーサイトキーを生成し、そのキーを暗号化に使用してからリモートサイトに送信します。
生成された対称キーは、ダウンストリームリモートサイトに配布するために、アップストリームサイトの Cisco APIC によって Nexus Dashboard Orchestrator (NDO) にプッシュされます。
NDO はメッセージブローカとして機能し、生成された対称キーをアップストリームサイトの Cisco APIC から収集し、それをダウンストリームリモートサイトの Cisco APIC に配布します。
各ダウンストリームサイトの Cisco APIC は、受信したキーを、キーを生成したアップストリームサイトからのトラフィックを受信することを目的としたローカルスパインスイッチの RX キーとして設定します。
各ダウンストリームサイトの Cisco APIC は、ローカルスパインスイッチから RX キーの展開ステータスを収集し、NDO にプッシュします。
NDO は、すべてのダウンストリームリモートサイトからアップストリームサイトの Cisco APIC に戻って、主要な展開ステータスを中継します。

アップストリームサイトはCisco APIC 、すべてのダウンストリームリモートサイトから受信したキー展開ステータスが成功したかどうかを確認します。

ダウンストリームデバイスから受信した展開ステータスが成功した場合、アップストリームサイトはスパインスイッチの TX キーとしてローカル対称キーを展開し、ダウンストリームサイトに送信される VXLAN パケットの暗号化を有効にします。

ダウンストリームデバイスから受け取った展開ステータスが失敗した場合、失敗した Cisco APIC サイトで障害が発生し、NDO で構成された「セキュアモード」設定に基づいて処理されます。「セキュアが必須 (must secure)」モードでは、パケットはドロップされ、「セキュアであるべき (should secure)」モードでは、パケットは宛先サイトに平文 (暗号化されていない) で送信されます。

（注）

現在のリリースでは、モードは常に「セキュアであるべき (should secure)」に設定されており、変更できません。

キー再生成プロセス

生成された各 TX / RX キーは、設定された時間が経過すると有効期限が切れます。デフォルトでは、キーの有効期限は 15 分に設定されています。TX/RX キーの初期セットが期限切れになると、キー再生成プロセスが行われます。

キーの再割り当てプロセスには、同じ一般的なキーの割り当てと配布フローが適用されます。キー再生成プロセスは「ブレーク前に作成 (make before break)」ルールに従います。つまり、新しい TX キーがアップストリームサイトに展開される前に、ダウンストリームサイトのすべての RX キーが展開されます。これを実現するために、アップストリームサイトは、ローカルアップストリームサイトのデバイスに新しい TX キーを構成する前に、ダウンストリームサイトからの新しい RX キーの展開ステータスを待ちます。

ダウンストリームサイトが新しい RX キーの展開で障害ステータスを報告した場合、キー再生成プロセスは終了し、古いキーはアクティブなままになります。ダウンストリームサイトは、新しいキーの展開が一定期間終了した後、古い RX キーと新しい RX キーを保持し、いずれかのキーを適切に復号することで、順序どおりでないパケット配信が可能になるようにします。

（注）

スパインスイッチのメンテナンス中のキー再生成プロセスに関しては、特別な注意が必要です。詳細については、スパインスイッチメンテナンス中のキー再生成プロセスを参照してください。

キー再生成プロセスの失敗

ダウンストリームサイトがキー再生成プロセスによって生成された新しい暗号化キーの展開に失敗した場合、新しいキーは破棄され、アップストリームデバイスは以前の有効なキーを TX キーとして引き続き使用します。このアプローチにより、アップストリームサイトは、ダウンストリームサイトのセットごとに複数の TX キーを維持する必要がなくなります。ただし、このアプローチでは、いずれかのダウンストリームサイトでキー再生成の展開エラーが発生し続ける場合、キー更新プロセスが遅延する可能性もあります。マルチサイト管理者は、キー再生成を成功させるために、キーの展開の失敗の問題を修正するための行動を取ることが期待されています。

Cisco APICキー管理のロール

Cisco APIC は、キー割り当て (初期キーとキー再配布の両方)、スパインスイッチからのキー展開ステータスメッセージの収集、および他のサイトへの配布のための各キーのステータスに関する Nexus Dashboard Orchestrator への通知に責任をもちます。

キー管理における Nexus Dashboard Orchestrator の役割

Nexus Dashboard Orchestrator は、アップストリームサイトから TX キー（初期キーと後続のキーの再生成の両方）を収集し、RX キーとして展開するためにすべてのダウンストリームサイトに配布します。NDO はまた、ダウンストリームサイトから RX キーの展開ステータス情報を収集し、成功した RX キー展開ステータスで TX キーを更新するために、アップストリームサイトに通知します。

アップストリームモデル

MPLS など、ダウンストリームキー割り当てを使用する他のテクノロジーとは対照的に、CloudSec のアップストリームモデルには次の利点があります。

このモデルはシンプルで、運用とネットワークへの導入が容易です。
モデルは、マルチサイトのユースケースに適しています。
複数の宛先サイトに送信される複製パケットの各コピーに同じキーと CloudSec ヘッダーを使用できるため、マルチキャストトラフィックに利点があります。ダウンストリームモデルでは、各コピーは暗号化中にサイトごとに異なるセキュリティキーを使用する必要があります。
障害が発生した場合のトラブルシューティングが容易になり、複製されたユニキャストパケットとマルチキャストパケットの両方に対して、送信元から宛先へのパケットのトレーサビリティが一貫して向上します。

CloudSec 暗号化のための Cisco APIC の設定

CloudSec 暗号と復号キーを生成するために、Cisco APIC で使用する 1 個以上の事前共有キー（PSK）を構成する必要があります。PSK は再キープロセス中のランダムシードとして使用されます。複数の PSK が設定される場合、各再キープロセスはインデックスの順序で次の PSK を使用します。さらに高いインデックスの PSK がない場合、最下位のインデックスの PSK が使用されます。

暗号キーの生成に対するシードとして PSK が使用されるため、複数の PSK の設定では生成された暗号キーの長時間にわたる脆弱性を下げることにより、追加のセキュリティを提供します。

（注）

Cisco APIC で事前共有キーが構成されていない場合、CloudSec はそのサイトに対して有効にはなりません。その場合、マルチサイトで CloudSec 設定をオンにすると、障害が生じます。

いつでも新しい PSK で前に追加した PSK を更新したい場合、新しいキーを追加するときと同様の手順を繰り返すだけですが、インデックスは既存のものを指定してください。

1 つ以上の事前共有キーを次の 3 通りの方法のいずれかを使用して設定できます。

GUI を使用した CloudSec 暗号化の Cisco APIC の設定で説明されている Cisco APIC GUI の使用
NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定で説明されている Cisco APIC NX-OS スタイルの CLI の使用
REST API を使用した CloudSec 暗号化の Cisco APIC の設定で説明されている Cisco APIC REST API の使用

GUI を使用した CloudSec 暗号化の Cisco APIC の設定

このセクションは、Cisco APIC GUI を使用して 1 つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

ステップ 1	APIC にログインします。
ステップ 2	[テナント] > [インフラ] > [ポリシー] > [CloudSec 暗号化]に移動します。
ステップ 3	SA キーの有効期限を指定します。このオプションは、各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キープロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。
ステップ 4	[事前共有キー]テーブルの + アイコンをクリックします。
ステップ 5	追加する事前共有キーのインデックスを指定し、その後、事前共有キー自体を指定します。 [インデックス (Index)] フィールドは、事前共有キーを使用する順序を指定します。最後 (最高位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。各事前共有キーは、64 文字の 16 進数文字列である必要があります。

NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定

このセクションでは、 Cisco APIC NX OS Style CLI を使用して1つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

ステップ 1	Cisco APIC NX-OS style CLI にログインします。
ステップ 2	コンフィギュレーションモードを入力します。例: `apic1# configure apic1 (config)#`
ステップ 3	デフォルト CloudSec プロファイルのコンフィグレーションモードを入力します。例: `apic1(config)# template cloudsec default apic1(config-cloudsec)#`
ステップ 4	事前共有キー (PSK) の有効期限を指定します。このオプションは、各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キープロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。例: `apic1(config-cloudsec)# sakexpirytime <duration>`
ステップ 5	1 つまたは複数の事前共有キーを指定します。次のコマンドでは、設定している PSK のインデックスと PSK 文字列自体を指定します。例: `apic1(config-cloudsec)# pskindex <psk-index> apic1(config-cloudsec)# pskstring <psk-string>` `<psk-index>` パラメータは、事前共有キーが使用される順序を指定します。最後 (最上位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。 `<psk-string>`パラメータは、実際の PSK を指定します。これは、64 文字の 16 進数文字列である必要があります。
ステップ 6	(オプション) 現在の PSK 設定を表示します。現在設定されている PSK の数とその期間を表示するには、次のコマンドを使用します。例: `apic1(config-cloudsec)# show cloudsec summary`

REST API を使用した CloudSec 暗号化の Cisco APIC の設定

このセクションは、Cisco APIC REST API を使用して 1 つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

PSK 有効期限、インデックス、文字列を設定します。

次の XML POST で、次を置換します。

各 PSK の期限をもつ sakExpiryTime の値。

この sakExpiryTime パラメータは各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キープロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。
設定している PSK のインデックスをもつ インデックス の値。

インデックス パラメータは、事前共有キーが使用される順序を指定します。最後 (最高位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。
設定している PSK のインデックスをもつ pskString の値。

pskString パラメータは実際の PSK を指定します。これは 16 進文字列で長さ 64 文字でなければなりません。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
    <cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "false" status="" >
        <cloudsecPreSharedKey index="1" pskString="1234567812345678123456781234567812345678123456781234567812345678" status=""/>
    </cloudsecIfPol>
</fvTenant>

Nexus Dashboard Orchestrator GUI を使用した CloudSec 暗号の有効化

CloudSec 暗号化は、サイトごとに個別に有効または無効にすることができます。ただし、2 つのサイト間の通信は、この機能が両方のサイトで有効になっている場合にのみ暗号化されます。

始める前に

2 つ以上のサイト間で CloudSec 暗号化を有効にする前に、次のタスクを完了しておく必要があります。

『Cisco APIC のインストール、アップグレード、ダウングレードガイド』で説明されているように、複数のサイトに Cisco APIC クラスタをインストールして設定します。
『Cisco Nexus Dashboard Orchestrator インストレーションおよびアップグレードガイド』の説明に従って、Nexus Dashboard Orchestrator をインストールし、設定します。
『Cisco ACI マルチサイトコンフィギュレーションガイド』の説明に従って、各 Cisco APIC サイトを Nexus Dashboard Orchestrator に追加します。

手順

ステップ 1

Nexus Dashboard Orchestrator にログインします。

ステップ 2

左のナビゲーションメニューから、[インフラストラクチャ（Infrastructure）] > [サイト接続（Site Connectivity）]を選択します。

ステップ 3

メインウィンドウの右上にある [構成（Configure）] ボタンをクリックします。

ステップ 4

（オプション）[一般設定（General Settings）] ページの [コントロールプレーンの構成（Control Plane Configuration）] タブで、[IANA 予約済み UDP ポート（IANA Reserved UDP Port）] オプションを有効にします。

デフォルトでは、CloudSec は独自の UDP ポートを使用します。このオプションを使用すると、サイト間の CloudSec 暗号化に公式の IANA 予約ポート 8017 を使用するように CloudSec を構成できます。

（注）

IANA 予約ポートは、リリース 5.2(4) 以降を実行している Cisco APIC サイトでサポートされています。

この設定を変更するには、すべてのサイトで CloudSec を無効にする必要があります。IANA 予約ポートを有効にしたいが、すでに 1 つ以上のサイトで CloudSec 暗号化を有効にしている場合は、すべてのサイトで CloudSec を無効にし、[IANA 予約 UDP ポート（IANA Reserve UDP Port）] オプションを有効にしてから、必要なサイトで CloudSec を再度有効にします。

ステップ 5

左側のサイドバーから、CloudSec 設定を変更するサイトを選択します。

ステップ 6

右側のサイドバーで、[Cloudsec 暗号化（Cloudsec encryption）] 設定を切り替えて、サイトの CloudSec 暗号化機能を有効または無効にします。

スパインスイッチメンテナンス中のキー再生成プロセス

次に、この機能が有効になっているスパインスイッチの一般的なメンテナンスシナリオでの CloudSec キー再生成プロセスの概要を示します。

通常の解放: CloudSec 対応スパインスイッチがデコミッションされると、 CloudSec キー再生成プロセスが自動的に停止します。解放されたノードが再起動されるか、解放されたノード ID が次から削除されるまで、キー再生成プロセスは再度開始されません: Cisco APIC
スパインスイッチのソフトウェアアップグレード: スパインスイッチがソフトウェアのアップグレードによりリロードされると、CloudSec キー再生成プロセスは自動的に停止します。キー再生成プロセスは、スパインスイッチのリロードが完了すると、再開されます。
メンテナンス (GIR モード) : CloudSec キー再生成プロセスは、NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にするに記載されている手順を使用して、手動で停止する必要があります。キー再生成は、ノードがトラフィックを転送する準備が再度整った後にのみ、有効にできます。
Cisco APICからの解放と削除 : CloudSec キー再生プロセスは、NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にするに記載されている手順を使用して、手動で停止する必要があります。キー再生成は、Cisco APIC からノードが削除された後にのみ有効にできます。

NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にする

キーの再生成プロセスを手動で停止し再開することが可能です。特定の状況でキーの再生成プロセスを手動で管理することが必要な場合があります。たとえば、でコミッションとメンテナンスの切り替えなどです。このセクションは、 Cisco APIC NX-OS Style CLI を使用して設定を切り替える方法を説明します。

手順

ステップ 1	Cisco APIC NX-OS style CLI にログインします。
ステップ 2	コンフィギュレーションモードを入力します。例: `apic1# configure apic1(config)#`
ステップ 3	デフォルト CloudSec プロファイルのコンフィグレーションモードを入力します。例: `apic1(config)# template cloudsec default apic1(config-cloudsec)#`
ステップ 4	キーの再生成プロセスを停止するか、再開します。キーの再生成を停止するには: 例: `apic1(config-cloudsec)# stoprekey yes` キーの再生成プロセスを再開するには: 例: `apic1(config-cloudsec)# stoprekey no`

REST API を使用したキー再生成プロセスの無効化と再有効化

キーの再生成プロセスを手動で停止し再開することが可能です。特定の状況でキーの再生成プロセスを手動で管理することが必要な場合があります。たとえば、でコミッションとメンテナンスの切り替えなどです。このセクションでは、Cisco APICREST API を使用して設定を切り替える方法について説明します。

手順

ステップ 1

キー再生成プロセスは、次のXML メッセージを使用して無効にすることができます。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
    <cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "true" status="" />
</fvTenant>

ステップ 2

キー再生成プロセスは、次のXML メッセージを使用して有効にすることができます。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
    <cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "false" status="" />
</fvTenant>

『Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics、Release 3.6（x）』

偏向のない言語

翻訳について

検索結果

章のタイトル： CloudSec 暗号化

CloudSec 暗号化

Cisco ACI CloudSec 暗号化

Requirements and Guidelines

Requirements

CloudSec 暗号化に関する用語

CloudSec の暗号化と復号の処理

パケット暗号化

パケットの暗号解読

CloudSec 暗号化キーの割り当てと配布

初期キー構成

キー再生成プロセス

キー再生成プロセスの失敗

Cisco APICキー管理のロール

キー管理における Nexus Dashboard Orchestrator の役割

アップストリーム モデル

CloudSec 暗号化のための Cisco APIC の設定

GUI を使用した CloudSec 暗号化の Cisco APIC の設定

手順

NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定

手順

例:

例:

例:

例:

例:

REST API を使用した CloudSec 暗号化の Cisco APIC の設定

手順

例:

Nexus Dashboard Orchestrator GUI を使用した CloudSec 暗号の有効化

始める前に

手順

スパイン スイッチ メンテナンス中のキー再生成プロセス

NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にする

手順

例:

例:

例:

例:

REST API を使用したキー再生成プロセスの無効化と再有効化

手順

例:

例:

このドキュメントは役に立ちましたか?

シスコに問い合わせ

アップストリームモデル

スパインスイッチメンテナンス中のキー再生成プロセス