この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「認証」
Cisco TrusSec のセキュリティ アーキテクチャは、信頼できるネットワーク デバイスのクラウドを確立することによってセキュア ネットワークを構築します。クラウド内の各デバイスは、そのネイバーによって認証されます。クラウド内のデバイス間リンクでの通信は、暗号化、メッセージ整合性検査、データパス リプレイ防止メカニズムを組み合わせたセキュリティで保護されます。またCisco TrustSec は、認証時に取得されたデバイスおよびユーザの識別情報を、ネットワークに入る際のパケットの分類またはカラリングに使用します。このパケット分類は、Cisco TrustSec ネットワークへの入力時にパケットにタグ付けされることにより維持されます。タグによってパケットはデータ パス全体を通じて正しく識別され、セキュリティおよびその他のポリシー基準が適用されます。このタグは、セキュリティ グループ タグ(SGT)と呼ばれることもあります。エンドポイントのデバイスが SGT に応じてトラフィックをフィルタリングできるようにすることにより、アクセス コントロール ポリシーをネットワークに強制できます。
(注) 入力とは、宛先へのパス上のパケットが最初の Cisco TrustSec 対応デバイスに入ることです。出力とは、パス上の最後の Cisco TrustSec 対応デバイスを出ることです。
図9-1 に、Cisco TrustSec クラウドの例を示します。この例では、Cisco TrustSec クラウド内に、ネットワーク接続されたデバイスが数台とエンドポイント デバイスが 1 台あります。エンドポイント デバイス 1 台とネットワーク接続デバイス 1 台がクラウドの外部にあるのは、これらが Cisco TrustSec 対応デバイスでないか、またはアクセスを拒否されたからです。
図9-1 Cisco TrustSec ネットワーク クラウドの例
Cisco TrustSec アーキテクチャは、主に次のコンポーネントで構成されています。
• 認証 ― Cisco TrustSec ネットワークにデバイスを加入させる前に、各デバイスの識別情報を検証します。
• 許可 ― 認証されたデバイスの識別情報に基づいて、Cisco TrustSec ネットワークのリソースに対するデバイスのアクセス権のレベルを決定します。
• アクセス コントロール ― 各パケットのソース タグを使用して、パケット単位でアクセス ポリシーを適用します。
• セキュア通信 ― Cisco TrustSec ネットワークの各リンク上のパケットに、暗号化、整合性検査、データパス リプレイ防止を提供します。
Cisco TrustSec ネットワークには、次の 3 つのエンティティがあります。
• サプリカント ― Cisco TrustSec ネットワークへの加入を試行するデバイス
• オーセンティケータ(AT) ― すでに Cisco TrustSec ネットワークに含まれているデバイス
• 許可サーバ ― 認証情報、許可情報、またはその両方を提供できるサーバ
サプリカントと AT の間のリンクの初回の確立時には、次の一連のイベントが発生します。
1. 認証(802.1X) ― 認証サーバがサプリカントの認証を実行します。あるいは、これらのデバイスが無条件に相互認証するように設定している場合は認証がそのまま完了します。
2. 許可 ― リンクの両側が、そのリンクに適用する SGT および ACL などのポリシーを取得します。サプリカントは、認証サーバへの他のレイヤ 3 ルートがない場合には、AT をリレーとして使用する必要があります。
3. Security Association Protocol(SAP)ネゴシエーション ― サプリカントと AT の間で、EAPOL-Key が交換され、暗号スイートのネゴシエーション、Security Parameter Index(SPI; セキュリティ パラメータ インデックス)の交換、キーの管理が実行されます。これら 3 つの作業が正常に完了すると、Security Association(SA; セキュリティ アソシエーション)が確立します。
SAP ネゴシエーションが完了するまで、ポートは未許可状態(ブロッキング状態)です(図9-2を参照)。
SAP ネゴシエーションには、次のいずれかの動作モードが使用されます。
Cisco TrustSec は、IEEE 802.1AE 規格に基づいて、ESP-128 GCM および GMAC を使用します。
Cisco TrustSec は、デバイスのネットワーク加入を許可する前にデバイスを認証します。Cisco TrustSec は、Extensible Authentication Protocol(EAP)方式としてのExtensible Authentication Protocol Flexible Authentication via Secure Tunnel(EAP-FAST)とともに、802.1X 認証を使用して、認証を実行します。
Cisco TrustSec は認証に EAP-FAST を使用します。EAP-FAST カンバセーションによって、チェーンを使用した EAP-FAST トンネル内で他の EAP 方式の交換が可能になります。この方法では、管理者は Microsoft Challenge Handshake Authentication Protocol Version 2(MSCHAPv2)のような従来型のユーザ認証方式を使用しながら、EAP-FAST トンネルが提供するセキュリティも利用できます。図9-3 に、EAP-FAST トンネルおよび Cisco TrustSec で使用される内部方式を示します。
Cisco TrustSec に EAP-FAST を実装することにより、次の機能拡張が実現されました。
• オーセンティケータの認証 ― AT と認証サーバの間の共有秘密を得るために Protected Access Credential(PAC)を使用するように AT に求めることにより、AT のアイデンティティをセキュアに判断します。また、この機能により、AT が使用できるすべての IP アドレスに関して認証サーバに RADIUS 共有秘密を設定する手間が省けます。
• ネイバーのアイデンティティを各ピアに通知 ― 認証交換の完了までに、認証サーバはサプリカントと AT の両方を識別します。認証サーバは、保護された EAP-FAST 終端で追加の type-length-value(TLV)パラメータを使用して、AT のアイデンティティと、その AT が Cisco TrustSec に対応しているかどうかをサプリカントに伝えます。認証サーバはさらに、Access- Accept メッセージの RADIUS 属性を使用して、サプリカントのアイデンティティおよびそのサプリカントが Cisco TrustSec に対応しているかどうかを AT に伝えます。各ピアは、ネイバーのアイデンティティを認識しているため、認証サーバに追加の RADIUS Access-Requests を送信し、リンクに適用されるポリシーを取得できます。
• AT ポスチャ評価 ― AT は、サプリカントの代わりに認証サーバと認証交換を開始すると、そのポスチャ情報を認証サーバに提供します。
802.1X では、AT に認証サーバとの IP 接続が必要です。AT はRADIUS over UDP/IP を使用してサプリカントと AT の認証交換をリレーする必要があるためです。PC などのエンドポイント デバイスはネットワークへの接続時にサプリカントとして動作することになります。ただし、2 つのネットワーク デバイス間の Cisco TrustSec 接続の場合、各ネットワーク デバイスの 802.1X ロールが他方のネットワーク デバイスに即座に認識されない場合もあります。
NX-OS デバイスに AT とサプリカントのロールを手動で設定する代わりに、Cisco TrustSec はロール選択アルゴリズムを実行し、AT として動作する NX-OS デバイスとサプリカントとして動作する NX-OS デバイスを自動的に判断します。ロール選択アルゴリズムは、RADIUS サーバに IP で到達可能なデバイスに AT ロールを割り当てます。どちらのデバイスも AT とサプリカントの両方のステート マシンを起動します。ある NX-OS デバイスが、ピアに RADIUS サーバへのアクセス権があることを検出すると、そのデバイスは自身の AT ステート マシンを終了し、サプリカントのロールを引き受けます。両方の NX 飽S デバイスに RADIUS サーバへのアクセス権がある場合、アルゴリズムは EAP over LAN(EAPOL)パケット送信の送信元として使用される MAC アドレスを比較します。MAC アドレスの値が大きい方の NX-OS デバイスが AT になり、もう一方の NX-OS デバイスがサプリカントになります。
Cisco TrustSec 認証プロセスが完了するまでに、認証サーバは次の処理を行います。
• サプリカントがエンドポイント デバイスの場合はユーザの認証
Cisco TrustSec 認証プロセスの完了時には、AT およびサプリカントの両方が次の情報を取得しています。
Cisco TrustSec はデバイスのアイデンティティとして IP アドレスも MAC アドレスも使用しません。その代わり、各 Cisco TrustSec 対応 NX-OS デバイスに、Cisco TrustSec ネットワークで一意に識別できる名前(デバイス ID)を手動で割り当てる必要があります。このデバイス ID は次の操作に使用されます。
Cisco TrustSec はパスワードベースの証明書をサポートしています。認証サーバは、代わりに自己署名式の証明書を使用する場合もあります。Cisco TrustSec はパスワードでサプリカントを認証し、MSCHAPv2 を使用することにより、たとえ認証サーバの証明書を検証できなくても、相互認証が可能です。
認証サーバはこれらの証明書を EAP-FAST フェーズ 0(プロビジョニング)の交換(サプリカントで PAC がプロビジョニングされる)中にサプリカントの相互認証に使用します。Cisco TrustSec は PAC の期限が切れるまで、EAP-FAST フェーズ 0 交換は再実行しません。その後のリンク起動時には、EAP-FAST フェーズ 1 とフェーズ 2 の交換のみを実行します。EAP-FAST フェーズ 1 交換では、認証サーバとサプリカントの相互認証に PAC が使用されます。Cisco TrustSec がデバイスの証明書を使用するのは、PAC プロビジョニング(または再プロビジョニング)段階だけです。
認証サーバは、Cisco TrustSec ネットワークにサプリカントが最初に加入する際に、一時的に設定されたパスワードをそのサプリカントの認証に使用します。サプリカントが最初に Cisco TrustSec ネットワークに加入する際に、認証サーバは証明書を作成してサプリカントを認証し、強力なパスワードを生成して、これを PAC でサプリカントに送信します。認証サーバはさらに、データベースに新しいパスワードを保存します。認証サーバとサプリカントは、その後の EAP-FAST フェーズ 0 交換の相互認証にこのパスワードを使用します。
Cisco TrustSec には、エンドポイント デバイスの特定タイプのユーザ証明書は必要ありません。ユーザに対して任意のタイプの認証方式(MSCHAPv2、LEAP、Generic Token Card [GTC]、または OTP など)を選択し、対応する証明書を使用できます。Cisco TrustSec は、EAP-FAST フェーズ 2 交換の一部として EAP-FAST トンネル内でユーザ認証を実行します。
SGACL(セキュリティ グループ アクセス リスト)を使用すると、割り当てられたセキュリティ グループに基づいてユーザが実行できる操作を制御できます。許可をロールにまとめることにより、セキュリティ ポリシーの管理が容易になります。NX-OS デバイスにユーザを追加する際に、1 つ以上のセキュリティ グループを割り当てれば、ユーザは適切な許可を即座に受信できます。セキュリティ グループを変更することにより、新しい許可を追加したり、現在の許可を制限することもできます。
Cisco TrustSec はセキュリティ グループに、SGT(セキュリティ グループ タグ)という 16 ビットの固有のタグを割り当てます。NX-OS デバイス内の SGT の数は認証済みのネットワーク エンティティの数に制限されます。SGT は全社内の送信元の許可を示す単一ラベルです。範囲は Cisco TrustSec ネットワーク内でグローバルです。
管理サーバは、セキュリティ ポリシーの設定に基づいて SGT を引き出します。これらを手動で設定する必要はありません。
いったん認証されると、Cisco TrustSec はデバイスを送信元とするすべてのパケットに、そのデバイスが割り当てられているセキュリティ グループを表す SGT を付けます。タグ付けされたパケットはネットワークを通じて Cisco TrustSec ヘッダーで SGT を運びます。このタグは、送信元のグループを表しているので、送信元の SGT として参照されます。Cisco TrustSec は、ネットワークの出口で、パケットの宛先デバイスに割り当てられているグループを判断し、アクセス コントロール ポリシーを適用します。
Cisco TrustSec はセキュリティ グループ間のアクセス コントロール ポリシーを定義します。Cisco TrustSec は、ネットワーク内のデバイスをセキュリティ グループに割り当て、セキュリティ グループ間およびセキュリティ グループ内でアクセス コントロールを適用することにより、ネットワーク内での原則的なアクセス コントロールを達成します。図9-4 に SGACL ポリシーの例を示します。
Cisco TrustSec ネットワークでは、図9-5 のように SGT の割り当てと SGACL の強制が実行されます。
図9-5 Cisco TrustSec ネットワークでの SGT と SGACL
NX-OS デバイスは、従来の ACL の IP アドレスではなく、デバイス グループに Cisco TrustSec アクセス コントロール ポリシーを定義します。このような組み合わせの解除によって、ネットワーク全体でネットワーク デバイスを自由に移動し、IP アドレスを変更できます。ネットワーク トポロジ全体を変更することが可能です。ロールと許可が同じであれば、ネットワークが変更されてもセキュリティ ポリシーには影響しません。これによって、ACL のサイズが大幅に節約され、保守作業も簡単になります。
従来の IP ネットワークでは、設定されている ACE(アクセス コントロール エントリ)の数は次のように決定されます。
Cisco TrustSec クラウドの入口のネットワーク デバイスは、Cisco TrustSec クラウドにパケットを転送する際に、パケットに SGT をタグ付けできるように、Cisco TrustSec クラウドに入るパケットの SGT を判断する必要があります。出口のネットワーク デバイスは、パケットの SGT を判断し、SGACL を適用する必要があります。
ネットワーク デバイスは、次のいずれかの方法でパケットの SGT を判断します。
• ポリシー取得時に送信元の SGT を取得する ― Cisco TrustSec 認証フェーズ後、ネットワーク デバイスは認証サーバからポリシーを取得します。認証サーバは、ピア デバイスが信頼できるかどうかを伝えます。ピア デバイスが信頼できる場合、認証サーバはそのピア デバイスから着信するすべてのパケットに適用する SGT も提供します。
• Cisco TrustSec ヘッダーの送信元 SGT フィールドを取得する ― 信頼できるピア デバイスからパケットが着信した場合、Cisco TrustSec ヘッダーの SGT フィールドで正しい値が伝送されます。これは、そのパケットにとって、そのネットワーク デバイスが Cisco TrustSec クラウド内の最初のネットワーク デバイスではない場合に適用されます。
• 送信元 IP アドレスに基づいて送信元 SGT を検索する ― 場合によっては、送信元 IP アドレスに基づいてパケットの SGT を判断するように手動でパケットを設定することもできます。SGT Exchange Protocol(SXP)も、IP-address-to-SGT マッピング テーブルに値を格納できます。
Cisco TrustSec クラウドの出口のネットワーク デバイスは、SGACL を適用する宛先グループを判断します。場合によっては、入口のデバイスまたは出口以外のその他のデバイスが使用できる宛先グループの情報を持っていることもあります。このような場合、SGACL は出口のデバイスではなく、これらのデバイスに適用されます。
アクセス レイヤの NX-OS デバイス ハードウェアは Cisco TrustSec をサポートしています。Cisco TrustSec ハードウェアがないと、Cisco TrustSec ソフトウェアはパケットに SGT をタグ付けできません。SXP を使用すると、Cisco TrustSec のハードウェア サポートがないネットワーク デバイスに SGT を伝播 できます。
SXP はアクセス レイヤ デバイスと宛先レイヤ デバイスの間で動作します。アクセス レイヤ デバイスは SXP を使用して、SGT とともに Cisco TrustSec 認証デバイスの IP アドレスを宛先スイッチに渡します。Cisco TrustSec 対応のソフトウェアとハードウェアを両方備えたディストリビューション デバイスはこの情報を使用して、パケットに適切にタグを付けます(図9-6 を参照)。
認証が終了すると、サプリカントと AT はいずれも認証サーバからセキュリティ ポリシーを取得します。サプリカントと AT はお互いに対してポリシーを強制します。サプリカントと AT はいずれも、認証後に受信したピア デバイス ID を提供します。ピア デバイス ID を使用できない場合、Cisco TrustSec は手動で設定されたピア デバイス ID を使用できます。
• Cisco TrustSec の信頼状態 ― パケットに SGT を付けるにあたり、ネイバー デバイスが信用できるかどうかを示します。
• ピア SGT ― ピアが属しているセキュリティ グループを示します。ピアが信頼できない場合は、ピアから受信したすべてのパケットにこの SGT がタグ付けされます。SGACL がピアの SGT に関連付けられているかどうかデバイスが認識できないと、そのデバイスは SGACL を取得するために追加要求を送信する場合もあります。
• 許可期限 ― ポリシーの期限が切れるまでの秒数を示します。シスコ独自の属性値(AV)ペアは、許可またはCisco TrustSec デバイスへのポリシー応答の期限を表します。Cisco TrustSec デバイスはポリシーと許可を期限が切れる前にリフレッシュする必要があります。
ヒント Cisco TrustSec デバイスは、認証サーバからピアの適切なポリシーを取得できない場合に備えて、最小限のデフォルト アクセス ポリシーをサポートする必要があります。
Cisco TrustSec 環境データは、Cisco TrustSec ノードとしてのデバイスの機能を支援するひとまとまりの情報またはポリシーです。デバイスは、Cisco TrustSec クラウドに最初に加入する際に、認証サーバから環境データを取得しますが、一部のデータをデバイスに手動で設定することもできます。たとえば、Cisco TrustSec のシード デバイスには認証サーバの情報を設定する必要がありますが、この情報は、デバイスが認証サーバから取得するサーバ リストを使用して、あとで追加することができます。
デバイスは、期限前に Cisco TrustSec 環境データをリフレッシュする必要があります。データの期限が切れていなければ、デバイスはデータをキャッシュしてリブート後に再使用することもできます。
デバイスは RADIUS を使用して、認証サーバから次の環境データを取得します。
• サーバ リスト ― クライアントがその後の RADIUS 要求に使用できるサーバのリスト(認証および許可の両方)
802.1X 認証プロセスで Cisco TrustSec AT のロールを引き受ける NX-OS デバイスは、認証サーバへの IP 接続を通じて、UDP/IP での RADIUS メッセージの交換により、認証サーバからポリシーと許可を取得します。サプリカント デバイスは認証サーバとの IP 接続がなくてもかまいません。サプリカントに 認証サーバとの IP 接続 がない場合、Cisco TrustSec は AT をサプリカントの RADIUS リレーとして機能させることができます。
サプリカントは、RADIUS サーバの IP アドレスと UDP ポートを持つ Cisco TrustSec AT に特別な EAP over LAN(EAPOL)メッセージを送信し、RADIUS 要求を完了します。Cisco TrustSec AT は受信した EAPOL メッセージから RADIUS 要求を抽出し、これを UDP/IP を通じて認証サーバに送信します。認証サーバから RADIUS 応答が返ると、Cisco TrustSec AT はメッセージを EAPOL フレームにカプセル化して、サプリカントに転送します。
Cisco TrustSecの設定および動作は、各 Virtual Device Context(VDC)に固有です。VDC の詳細については、『 Cisco NX-OS Virtual Device Context Configuration Guide, Release 4.0 』を参照してください。
Cisco TrustSec に関する注意事項と制約事項は次のとおりです。
• Cisco TrustSec は認証に RADIUS を使用します。
• 1 つのインターフェイスに、Cisco TrustSec と 802.1X を両方設定することはできません。設定できるのはこれらのどちらか一方です。ただし、Cisco TrustSec で EAP-FAST 認証を使用するには、802.1X 機能をイネーブルにする必要があります。
• Cisco TrustSec の AAA 認証および許可は、Cisco Secure Access Control Server(ACS)でのみサポートされます。
• Cisco TrustSec は IPv4 アドレスのみをサポートします。
• 「Cisco TrustSec デバイスの証明書の設定」
• 「Cisco TrustSec の認証、許可、SAP、およびデータ パス セキュリティの設定」
Cisco TrustSec を設定するには、その前に、NX-OS デバイス上で 802.1X と Cisco TrustSec の機能をイネーブルにする必要があります。
(注) Cisco TrustSec 機能をイネーブルにすると、その後に 802.1X 機能をディセーブルにすることはできません。
|
|
|
---|---|---|
ネットワーク内の Cisco TrustSec 対応 NX-OS デバイス各々に、固有の Cisco TrustSec 証明書を設定する必要があります。Cisco TrustSec は証明書のパスワードをデバイスの認証に使用します。
(注) Cisco Secure ACS にも NX-OS デバイスの Cisco TrustSec 証明書を設定する必要があります(「Configuration Guide for the Cisco Secure ACS」を参照)。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
Cisco TrustSec の認証に Cisco Secure ACS を使用できます。ネットワーク クラウド内の Cisco TrustSec 対応 NX-OS デバイスの 1 つに、RADIUS サーバ グループを設定し、デフォルトの AAA 認証および許可を指定する必要があります。Cisco TrustSec は RADIUS リレーをサポートしているため、AAA を設定するのは、Cisco Secure ACS に直接接続されている NX-OS シード デバイスのみです。Cisco TrustSec がイネーブルのすべての NX-OS デバイスに対して、Cisco TrustSec は自動的にプライベート AAA サーバ グループ aaa-private-sg を提供します。NX-OS シード デバイスは管理 VRF を使用して、Cisco Secure ACS と通信します。
(注) Cisco TrustSec をサポートしているのは、Cisco Secure ACS のみです。
RADIUS サーバの設定に関する詳細は、 第 3 章「RADIUS の設定」 を参照してください。RADIUS サーバ グループの設定に関する詳細は、 第 2 章「AAA の設定」 を参照してください。
ここでは、Cisco TrustSec ネットワーク クラウド内のシード NX-OS デバイスに AAA を設定する手順を説明します。
(注) シード NX-OS デバイスの AAA RADIUS サーバ グループを設定する際には、VRF を指定する必要があります。管理 VRF を使用する場合、ネットワーク クラウド内の非シード デバイスにそれ以上の設定を行う必要はありません。異なる VRF を使用する場合は、非シード デバイスに VRF を設定する必要があります(Cisco TrustSec 非シード NX-OS デバイスでの AAA の設定を参照)。
正しい VDC 内にいることを確認します(あるいは、 switch to vdc コマンドを使用します)。
Cisco ACS の IPv4 または IPv6 のアドレスまたはホスト名を取得します。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
2. radius-server host { ipv4-address | ipv6-address | hostname } password password pac
4. aaa group server radius group-name
5. server { ipv4-address | ipv6-address | hostname }
8. aaa authentication dot1x default group group-name
9. aaa authorization cts default group group-name
|
|
|
---|---|---|
radius-server host { ipv4-address | ipv6-address | hostname } password password pac switch(config)# radius-server host 10.10.1.1 password L1a0K2s9 pac |
||
aaa group server radius group-name |
||
(注) 管理 VRF を使用する場合、ネットワーク クラウド内の非シード デバイスにそれ以上の設定を行う必要はありません。異なる VRF を使用する場合は、非シード デバイスに VRF を設定する必要があります(Cisco TrustSec 非シード NX-OS デバイスでの AAA の設定を参照)。 |
||
Cisco TrustSec はネットワーク クラウド内の非シード NX-OS デバイスに aaa-private-sg という名前の AAA サーバ グループを設定します。デフォルトでは、aaa-private-sg サーバ グループは Cisco Secure ACS との通信に管理 VRF を使用し、非シード NX-OS デバイスに対するそれ以上の設定は必要ありません。ただし、異なる VRF の使用を選択した場合は、正しい VRF を使用するように、非シード NX-OS デバイスの aaa-private-sg を変更する必要があります。
正しい VDC 内にいることを確認します(あるいは、 switch to vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
ネットワーク内のシード NX-OS デバイスが設定されていることを確認します(Cisco TrustSec シード NX-OS デバイスでの AAA の設定を参照)。
2. aaa group server radius aaa-private-sg
|
|
|
---|---|---|
aaa group server radius aaa-private-sg |
RADIUS サーバ グループ aaa-private-sg を指定し、RADIUS サーバ グループ コンフィギュレーション モードを開始します。 |
|
• 「インターフェイスに対する Cisco TrustSec データパス リプレイ保護の設定」
Cisco TrustSec の認証および許可を設定するには、次の手順を行います。
ステップ 1 Cisco TrustSec 機能をイネーブルにします(Cisco TrustSec 機能のイネーブル化を参照)。
ステップ 2 Cisco TrustSec の認証をイネーブルにします(Cisco TrustSec 認証のイネーブル化を参照)。
ステップ 3 インターフェイスに対して Cisco TrustSec の 802.1X 認証をイネーブルにします(Cisco TrustSec 認証のイネーブル化を参照)。
インターフェイスに対して Cisco TrustSec 認証をイネーブルにする必要があります。デフォルトでは、データパス リプレイ保護機能がイネーブルになり、SAP 動作モードは GCM-encrypt です。
(注) Cisco TrustSec の 802.1X モードをイネーブルにすると、そのインターフェイス上の許可と SAP がイネーブルになります。
2. interface ethernet slot / port [ - port2 ]
5. no data-path replay protection
|
|
|
---|---|---|
interface ethernet slot / port [ - port2 ] |
||
Cisco TrustSec の 802.1X 認証をイネーブルにして、Cisco TrustSec 802.1X コンフィギュレーション モードを開始します。 |
||
(任意)インターフェイスに SAP 動作モードを設定します。 |
||
デフォルトでは、NX-OS ソフトウェアによってデータパス リプレイ保護機能をイネーブルにします。接続デバイスが SAP をサポートしていない場合は、レイヤ 2 Cisco TrustSec のインターフェイスでデータパス リプレイ保護をディセーブルにできます。
正しい VDC 内にいることを確認します(あるいは、 switch to vdc コマンドを使用します)。
インターフェイスの Cisco TrustSec 認証がイネーブルになっていることを確認します(Cisco TrustSec 認証のイネーブル化を参照)。
|
|
|
---|---|---|
interface ethernet slot / port [ - port2 ] |
||
Cisco TrustSec の 802.1X 認証をイネーブルにして、Cisco TrustSec 802.1X コンフィギュレーション モードを開始します。 |
||
レイヤ 2 Cisco TrustSec のインターフェイスに SAP 動作モードを設定できます。デフォルトの SAP 動作モードは GCM-encrypt です。
正しい VDC 内にいることを確認します(あるいは、 switch to vdc コマンドを使用します)。
インターフェイスの Cisco TrustSec 認証がイネーブルになっていることを確認します(Cisco TrustSec 認証のイネーブル化を参照)。
|
|
|
---|---|---|
interface ethernet slot / port [ - port2 ] |
単一のインターフェイスまたはインターフェイス範囲を指定し、インターフェイス コンフィギュレーション モードを開始します。 |
|
Cisco TrustSec の 802.1X 認証をイネーブルにして、Cisco TrustSec 802.1X コンフィギュレーション モードを開始します。 |
||
SAP プロトコル交換をトリガーして、新しいキー セットを生成し、インターフェイス上のデータ トラフィックを保護できます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
NX-OS デバイスに Cisco Secure ACS へのアクセス権がない場合や、MAC アドレス認証バイパス機能がイネーブルになっていて認証が必要でない場合には、インターフェイスに手動で Cisco TrustSec を設定することも可能です。接続の両側のインターフェイスに手動で設定する必要があります。
(注) 半二重モードのインターフェイスでは、Cisco TrustSec をイネーブルにできません。インターフェイスが半二重モードに設定されているかどうかを調べるには、show interface コマンドを使用します。
正しい VDC 内にいることを確認します(あるいは、 switch to vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
2. interface ethernet slot / port
4. sap pmk key modelist { gcm-encrypt | gmac | no-encap | null }
5. policy dynamic identity peer-name
|
|
|
---|---|---|
interface ethernet slot / port |
||
Cisco TrustSec 手動コンフィギュレーション モードを開始します。 (注) 半二重モードのインターフェイスでは、Cisco TrustSec をイネーブルにできません。 |
||
sap pmk key [ modelist { gcm-encrypt | gmac | no-encap | null }] |
SAP の Pairwise Master Key(PMK)と動作モードを設定します。 key 引数は、最大 32 文字の偶数文字数の 16 進値です。モードのリストには、次に示すデータ パス暗号化と認証の暗号モードを指定します。 • no-encap ― 非カプセル化および SGT 非挿入 |
|
policy dynamic identity peer-name switch(config-if-cts-manual)# policy dynamic identity MyDevice2 |
ダイナミック許可ポリシーのダウンロードを設定します。 peer-name 引数は、ピア デバイスの Cisco TrustSec デバイス ID です。ピア名では、大文字と小文字が区別されます。 (注) Cisco TrustSec 証明書が設定されていること(Cisco TrustSec デバイスの証明書の設定を参照)および Cisco TrustSec の AAA が設定されていること(Cisco TrustSec の AAA の設定を参照)を確認します。 |
|
スタティック許可ポリシーを設定します。 tag 引数は、0x0 から 0xffff の 16 進形式で指定します。 trusted キーワードを指定すると、SGT 付きでインターフェイスにトラフィックが着信した場合、そのタグは上書きされません。 |
||
• 「VLAN に対する SGACL ポリシーの強制のイネーブル化」
• 「VRF に対する SGACL ポリシーの強制のイネーブル化」
Cisco TrustSec の SGACL ポリシーを設定するには、次の手順を行います。
ステップ 1 レイヤ 2 インターフェイスの場合は、Cisco TrustSec がイネーブルになっているインターフェイスがある VLAN に対して、SGACL ポリシーの強制をイネーブルにします(VLAN に対する SGACL ポリシーの強制のイネーブル化を参照)。
ステップ 2 レイヤ 3 インターフェイスの場合は、Cisco TrustSec がイネーブルになっているインターフェイスがある VRF に対して、SGACL ポリシーの強制をイネーブルにします(VRF に対する SGACL ポリシーの強制のイネーブル化を参照)。
ステップ 3 SGACL ポリシーの設定のダウンロードに Cisco Secure ACS 上の AAA を使用しない場合は、SGACL のマッピングとポリシーを手動で設定します(IPv4 アドレスと SGACL SGT のマッピングの手動設定およびSGACL ポリシーの手動設定を参照)。
SGACL を使用する場合、Cisco TrustSec がイネーブルになっているレイヤ 2 インターフェイスがある VLAN 内で、SGACL ポリシーの強制をイネーブルにする必要があります。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
SGACL を使用する場合、Cisco TrustSec がイネーブルになっているレイヤ 3 インターフェイスがある VRF 内で、SGACL ポリシーの強制をイネーブルにする必要があります。
(注) 管理 VRF の場合は、SGACL ポリシーの強制をイネーブルにできません。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
ダイナミック Address Resolution Protocol(ARP; アドレス解決プロトコル)検査がイネーブルになっていること( 第 15 章「DAI の設定」 を参照)または Dynamic Host Configuration Protocol(DHCP)スヌーピングがイネーブルになっていること( 第 14 章「DHCP スヌーピングの設定」 を参照)を確認します。
|
|
|
---|---|---|
SGACL が実行されるパケットに、固有の Cisco TrustSec SGT(セキュリティ グループ タグ)を手動で設定できます。
(注) Cisco Secure ACS にも、NX-OS デバイスの Cisco TrustSec 証明書を設定する必要があります。
|
|
|
---|---|---|
デバイスから送信されるパケットの SGT を設定します。 tag 引数は、 0x hhhh の形式の 16 進値です。有効値の範囲は 0x1 ~ 0xfffd です。 |
||
SGACL ポリシー設定のダウンロードに Cisco Secure ACS を使用しない場合は、IPv4 アドレスと SGACL SGT のマッピングを VLAN または VRF に手動で設定できます。NX-OS デバイスで、Cisco Secure ACS、ダイナミック ARP 検査、DHCP スヌーピングを使用できない場合は、この機能を使用できます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
VLAN に対する SGACL ポリシーの強制がイネーブルになっていること(VLAN に対する SGACL ポリシーの強制のイネーブル化を参照)または VRF に対する SGACL ポリシーの強制がイネーブルになっていること(VRF に対する SGACL ポリシーの強制のイネーブル化を参照)を確認します。
|
|
|
---|---|---|
SGACL ポリシー設定のダウンロードに Cisco Secure ACS を使用しない場合は、NX-OS デバイスに手動で SGACL ポリシーを設定できます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
VLAN に対する SGACL ポリシーの強制がイネーブルになっていること(VLAN に対する SGACL ポリシーの強制のイネーブル化を参照)、またはVRF に対する SGACL ポリシーの強制がイネーブルになっていること(VRF に対する SGACL ポリシーの強制のイネーブル化を参照)を確認します。
2. cts role-based access-list list-name
deny tcp [{ dest | src } {{ eq | gt | lt | neq } port-number | range port-number1 port-number2 }]
deny udp [{ dest | src } {{ eq | gt | lt | neq } port-number | range port-number1 port-number2 }]
permit tcp [{ dest | src } {{ eq | gt | lt | neq } port-number | range port-number1 port-number2 }]
permit udp [{ dest | src } {{ eq | gt | lt | neq } port-number | range port-number1 port-number2 }]
6. cts role-based sgt { sgt-value | any | unknown } dgt { dgt-value | any | unknown } access-list list-name
Cisco TrustSec のデバイス証明書と AAA の設定後、Cisco Secure ACS からダウンロードされた Cisco TrustSec SGACL ポリシーを検証できます。NX-OS ソフトウェアは、インターフェイスに対する認証および許可を通じて、SXP によって、または IPv4 アドレスおよび SGACL SGT の手動マッピングから新しい SGT を学習すると、SGACL ポリシーをダウンロードします。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
Cisco TrustSec SGACL を表示します(Cisco Secure ACS からダウンロードされたものと NX-OS デバイスに手動で設定されたものの両方)。 |
Cisco Secure ACS によって NX-OS デバイスにダウンロードされた SGACL ポリシーをリフレッシュできます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
SGT Exchange Protocol(SXP)を使用すると、Cisco TrustSec のハードウェア サポートがないネットワーク デバイスに SGT を伝播 できます。ここでは、ネットワーク内の NX-OS デバイスに Cisco TrustSec SXP を設定する手順について説明します。
• 「Cisco TrustSec の認証および許可の設定プロセス」
• 「Cisco TrustSec SXP のイネーブル化」
Cisco TrustSec SXP の設定手順は次のとおりです。
ステップ 1 Cisco TrustSec 機能をイネーブルにします(Cisco TrustSec 機能のイネーブル化を参照)。
ステップ 2 VRF に対する SGACL ポリシーの強制をイネーブルにします(VRF に対する SGACL ポリシーの強制のイネーブル化を参照)。
ステップ 3 Cisco TrustSec SXP をイネーブルにします(Cisco TrustSec SXP のイネーブル化を参照)。
ステップ 4 スピーカー ピアとリスナー ピア に接続を設定します(Cisco TrustSec SXP のピア接続の設定を参照)。
(注) SXP には管理(mgmt 0)接続は使用できません。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
|
|
|
---|---|---|
SXP トランザクションのピア接続を設定する必要があります。パスワード保護を使用している場合は、必ず両エンドに同じパスワードを使用してください。
(注) デフォルトの SXP 送信元 IP アドレスが設定されていない場合に、接続の SXP 送信元アドレスを指定しないと、NX-OS ソフトウェアは既存のローカル IP アドレスから SXP 送信元 IP アドレスを抽出します。その NX-OS デバイスから開始される各 TCP 接続で SXP 送信元アドレスが異なる可能性があります。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
SXP がイネーブルになっていることを確認します(Cisco TrustSec SXP のイネーブル化を参照)。
VRF に対する SGACL ポリシーの強制がイネーブルになっていることを確認します(VRF に対する SGACL ポリシーの強制のイネーブル化を参照)。
2. cts sxp connection peer peer-ipv4-addr [ source src-ipv4-addr ] password { default | none | required password } mode { speaker | listener } [ vrf vrf-name ]
デフォルトでは、SXP は接続のセットアップ時にパスワードを使用しません。NX-OS デバイスにデフォルトの SXP パスワードを設定できます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
SXP がイネーブルになっていることを確認します(Cisco TrustSec SXP のイネーブル化を参照)。
|
|
|
---|---|---|
NX-OS ソフトウェアは、送信元 IP アドレスが指定されないと、新規の TCP 接続すべてにデフォルトの送信元 IP アドレスを使用します。デフォルト SXP 送信元 IP アドレスを設定しても、既存の TCP 接続には影響しません。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
SXP がイネーブルになっていることを確認します(Cisco TrustSec SXP のイネーブル化を参照)。
|
|
|
---|---|---|
ピアが SXP 接続を終了すると、内部ホールドダウン タイマーが開始されます。内部ホールドダウン タイマーが終了する前にピアが再接続すると、SXP 復帰期間タイマーが開始されます。SXP 復帰期間タイマーがアクティブな間、NX-OS ソフトウェアは前回の接続で学習した SGT マッピング エントリを保持し、無効なエントリを削除します。デフォルト値は 120 秒(2 分)です。SXP 復帰期間を 0 秒に設定すると、タイマーがディセーブルになり、前回の接続のすべてのエントリが削除されます。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
SXP がイネーブルになっていることを確認します(Cisco TrustSec SXP のイネーブル化を参照)。
|
|
|
---|---|---|
SXP リトライ期間によって、NX-OS ソフトウェアが SXP 接続を再試行する頻度が決まります。SXP 接続が正常に確立されなかった場合、NX-OS ソフトウェアは SXP リトライ期間タイマーの終了後に、新たな接続の確立を試行します。デフォルト値は 60 秒(1 分)です。SXP リトライ期間を 0 秒に設定すると、タイマーがディセーブルになり、再試行は実行されません。
正しい VDC 内にいることを確認します(あるいは、 switchto vdc コマンドを使用します)。
Cisco TrustSec がイネーブルになっていることを確認します(Cisco TrustSec 機能のイネーブル化を参照)。
SXP がイネーブルになっていることを確認します(Cisco TrustSec SXP のイネーブル化を参照)。
|
|
|
---|---|---|
Cisco TrustSec の設定情報を表示するには、次のいずれかの作業を行います。
|
|
---|---|
このコマンドの出力フィールドについての詳細は、『 Cisco NX-OS Security Command Reference, Release 4.0 』を参照してください。
• 「シード NX-OS デバイスへの Cisco TrustSec AAA の設定」
• 「インターフェイスに対する Cisco TrustSec 認証のイネーブル化」
• 「VRF に対する Cisco TrustSec ロールベース ポリシー強制の設定」
• 「デフォルト以外の VRF に対する Cisco TrustSec ロールベース ポリシー強制の設定」
• 「VLAN に対する Cisco TrustSec ロールベース ポリシー強制の設定」
• 「デフォルト VRF に対する IPv4 アドレスと SGACL SGT のマッピングの設定」
• 「デフォルト以外の VRF に対する IPv4 アドレスと SGACL SGT のマッピングの設定」
• 「VLAN に対する IPv4 アドレスと SGACL SGT のマッピングの設定」
• 「Cisco TrustSec SGACL の手動設定」
Cisco TrustSec をイネーブルにする例を示します。
次の例では、シード デバイスに Cisco TrustSec の AAA を設定します。
次の例では、インターフェイスに対して、クリア テキスト パスワードを使用する Cisco TrustSec 認証をイネーブルにします。
次の例では、インターフェイスに対して、クリア テキスト パスワードを使用する Cisco TrustSec 認証をイネーブルにします。
次の例では、インターフェイスに手動で Cisco TrustSec 認証を設定します。
次の例では、デフォルト VRF に対して Cisco TrustSec のロールベース ポリシー強制をイネーブルにします。
次の例では、デフォルト以外の VRF に対して Cisco TrustSec のロールベース ポリシー強制をイネーブルにします。
次の例では、VLAN に対して Cisco TrustSec のロールベース ポリシー強制をイネーブルにします。
次の例では、デフォルト VRF に対して Cisco TrustSec ロールベース ポリシーの IPv4 アドレス対 SGACL SGT マッピングを手動で設定します。
次の例では、デフォルト以外の VRF に対して Cisco TrustSec ロールベース ポリシーの IPv4 アドレス対 SGACL SGT マッピングを手動で設定します。
次の例では、VLAN に対して Cisco TrustSec ロールベース ポリシーの IPv4 アドレス対 SGACL SGT マッピングを手動で設定します。
次の例では、Cisco TrustSec SGACL を手動で設定します。
レイヤ 3 Cisco TrustSec の設定例を示します。
次の例では、switch1に、デフォルト VRF の SXP を設定します。
次の例では、switch2に、デフォルト VRF の SXP を設定します。
表9-1 に Cisco TrustSec パラメータのデフォルトの設定値を示します。
|
|
---|---|
Cisco TrustSec の実装に関する詳細情報については、次を参照してください。
• 「関連資料」
|
|
---|---|