セキュリティ強化の概要

Catalyst Center は、シスコ ネットワーク プラットフォーム向けの非常に高度で機能豊富なエンタープライズ コントローラです。Catalyst Center は企業ネットワークの最も重要なインフラストラクチャ コンポーネントの 1 つであるため、安全に展開してください。

このガイドでは、セキュアな展開を確保するためのベストプラクティスについて説明します。ネットワーク インフラストラクチャの Catalyst Center について、マルチレイヤセキュリティに関する考慮事項を慎重に評価してください。このガイドで推奨されているアクションを実行し、潜在的なセキュリティリスクを軽減します。


(注)  


  • Cisco DNA CenterCatalyst Center にブランド変更されました。ブランド変更プロセスの進行中は、両方の名前がさまざまな販促アイテムに表示されますが、どちらの名前も同じ製品を指して使用されます。

  • このガイドは、Catalyst Center で新しいセキュリティ強化が導入されるたびに定期的に更新されます。このガイドをブックマークし、Cisco.com から最新バージョンをダウンロードしてください。

    このガイドはリリースに依存しません。すべてのスクリーンショットと手順は、最新の UI に基づいて定期的に更新されます。以前のバージョンの Catalyst Center を使用していて、スクリーンショットまたはワークフローの違いに気付いた場合は、そのバージョンの『Cisco Catalyst Center Administrator Guide』を参照してください。


Catalyst Center 強化手順

Catalyst Center は、それ自体とモニターおよび管理対象のホスト/ネットワークデバイス用の多数のセキュリティ機能を提供します。セキュリティ機能は、明確に理解して、正しく設定してください。セキュリティに関する次の推奨事項に従ってください。

  • Catalyst Center は、プライベート内部ネットワーク内、およびインターネットなどの信頼できないネットワークに対して Catalyst Center を開いていないファイアウォールの背後に導入してください。

  • Catalyst Center のインターフェイスは個別の管理および企業ネットワークに接続してください。これにより、Catalyst Center を管理するために使用されるサービスと、ネットワークデバイスとの通信に使用されるサービスとが確実に分離されます。

  • 3 ノードクラスタセットアップで Catalyst Center を展開する場合は、クラスタインターフェイスが分離されたネットワークに接続されていることを確認してください。

  • パッチのアナウンス後、セキュリティパッチを含む重要なアップグレードで Catalyst Center を早急にアップグレードしてください。『Cisco Catalyst Center Upgrade Guide』を参照してください。

  • HTTPS プロキシサーバーを使用する Catalyst Center によってアクセスされるリモート URL を制限してください。Catalyst Center は、インターネット経由でアクセスして、ソフトウェアアップデート、ライセンス、デバイスソフトウェアをダウンロードしたり、最新のマップ情報やユーザーフィードバックを提供したりするように設定されています。これらの目的でインターネット接続は必須です。ただし、HTTPS プロキシサーバーを介して安全な接続を提供します。詳細については、必要なインターネット URL と完全修飾ドメイン名へのインターネットアクセスの保護 を参照してください。

  • ファイアウォールを使用して、Catalyst Center との間の入出力管理とエンタープライズ ネットワーク接続を制限します。既知の IP を許可し、未使用のポートへの接続をブロックすることでアクセスを制限します。詳細については、通信ポートを参照してください。

  • Catalyst Center の自己署名サーバー証明書を、内部認証局(CA)によって署名された証明書に置き換えてください。

  • 可能な場合は、使用しているネットワーク環境で SFTP 互換モードを無効にします。このモードでは、レガシー ネットワーク デバイスが古い暗号スイートを使用して Catalyst Center に接続できます。詳細については、SFTP 互換モードの有効化または無効化を参照してください。

  • ブラウザベースのアプライアンス設定ウィザードを無効にします。このウィザードには、自己署名証明書が付属しています。詳細については、ブラウザベースのアプライアンス設定ウィザードを参照してください。

  • 最小 TLS バージョンをアップグレードします。Catalyst Center では、TLSv1.1 および TLSv1.2 がデフォルトで有効になっています。ネットワーク環境の最小 TLS バージョンは 1.2 に設定することをお勧めします。詳細については、最小 TLS バージョンの変更と RC4-SHA の有効化(安全でない)を参照してください。

ユーザーロールの考慮事項

ユーザーには、特定の機能へのアクセスを定義するロールが割り当てられます。

Catalyst Center では、次のユーザーロールがサポートされます。詳細については、『Cisco Catalyst Center Administrator Guide』の「About User Roles」および「Create Local Users」[英語] を参照してください。

  • 管理者(SUPER-ADMIN-ROLE):このロールを持つユーザーは、Catalyst Center のすべての機能へのフルアクセスが可能です。管理者は、SUPER-ADMIN-ROLE を含むさまざまなロールを持つ他のユーザプロファイルを作成できます。このロールを持つユーザーの数は制限するようにしてください。

  • ネットワーク管理者(NETWORK-ADMIN-ROLE):このロールを持つユーザは、Catalyst Center のすべてのネットワーク関連機能へのフルアクセスが可能です。ただし、バックアップと復元など、システム関連の機能へのアクセス権はありません。

  • オブザーバ(OBSERVER-ROLE):このロールを持つユーザーは、Catalyst Center の機能への表示専用アクセスが可能です。オブザーバロールを持つユーザーは、Catalyst Center を設定または制御する機能やデバイスを管理する機能にはアクセスできません。

事前設定されたユーザーロールに加えて、Catalyst Center は、きめ細かなカスタムアクセスポリシーを使用したユーザーロールの作成もサポートします。こうしたユーザーロールでは、特定の Catalyst Center 機能およびサイトへのユーザーアクセスを許可または制限するカスタムロールを作成できます。詳細については、『Cisco Catalyst Center Administrator Guide』の「Configure site-based, role-based access control」を参照してください。


(注)  


管理者は、重要な機能の設定を制御できます。そのため、管理者ロールを持つユーザーの数は制限することを強くお勧めします。

Catalyst Center では、Cisco Identity Services Engine(ISE)やその他の認証、許可、およびアカウンティング(AAA)サーバーをユーザー認証に使用できます。詳細については、『Cisco Catalyst Center Administrator Guide』の「Configure Authentication and Policy Servers」[英語] を参照してください。

Catalyst Center の展開の保護

Catalyst Center は、それ自体とモニターおよび管理対象のホスト/ネットワークデバイス用の多数のセキュリティ機能を提供します。図に示すように、Catalyst CenterCisco ISE はローカルデータセンター(キャンパスのヘッド)またはリモートデータセンターのいずれかのファイアウォールの背後に配置します。

この図は、ローカルデータセンターまたはサービスブロックモデルと、MAN/WAN モデルを介したリモートデータセンターの 2 つの展開モデルを示しています。

Catalyst Center に GUI からアクセスし、ネットワークデバイスと対話できるようにするには、ファイアウォールで特定のポートを設定します。Catalyst Center はクラウドと統合し、実際の遅延要件に合わせて世界中に分散されます。

この図は、Catalyst Center に GUI からアクセスし、Catalyst Center がネットワークデバイスと対話できるようにするためのファイアウォール上の特定のポートを示しています。

通信ポート

表に、Catalyst Center が使用するポート、それらのポート上で通信するサービスの名前、およびポート使用における製品の目的を示します。「推奨処置」列は、ネットワークトラフィックを既知の IP アドレスまたは範囲に制限できるかどうか、Catalyst Center のポートやサービスとの間のネットワーク接続を Catalyst Center の機能に影響を与えることなくブロックできるかどうか、ポートを開いておく必要があるかどうかを示します。


(注)  


インターネット宛トラフィックをルーティングするように設定されているアプライアンス インターフェイスは、すべての通信の送信元として機能します。


Catalyst Center の宛先ポートは一部重複しています。サブセクションに用途と関連するネットワークサービスを示してあります。ファイアウォールルールで送信元や宛先の IP アドレスまたは範囲を制限できるほか、Catalyst Center の展開で使用していないサービスについてはポートを開かないようにすることができます。


重要


3 ノードクラスタの場合は、各ノードの送信元エンタープライズ IP アドレスが許可されていることを確認します。


表 1. Catalyst Center で使用する通信ポート
Port サービス名 目的 推奨処置

Catalyst Center の管理または設定

TCP 443

UI、REST、HTTPS

GUI、REST、HTTPS 管理ポート。

ポートを開いておく必要があります。

TCP 2222

Catalyst Center シェル

Catalyst Center シェルに接続します。

ポートを開いておく必要があります。既知の IP アドレスを送信元に制限します。

TCP 9004

Web UI インストール

GUI ベースのインストールページを提供します(Web ベースのオプションを使用して Catalyst Center をインストールする場合にのみ必要です)。

ノードのインストールが完了するまでポートを開いておく必要があります。

TCP 9005

Web UI インストール API サービス

Web ベースのインストール用の API を提供します(ブラウザクライアントによってポート 9004 から接続されます。外部エージェントはアクセスを必要としません)。

クラスタの形成が完了するまでポートを開いておく必要があります。

Cisco IMC の管理または設定

TCP 22

Catalyst Center シェル

Catalyst Center シェルに接続します。

ポートを開いておく必要があります。既知の IP アドレスを送信元として設定します。

UDP と TCP 53

DNS

DNS 名を IP アドレスに解決するために使用されます。

他のサービス(NTP DNS 名など)の IP アドレスの代わりに DNS 名を使用する場合は、ポートを開く必要があります。

UDP と TCP 389

LDAP

Cisco IMC ユーザー管理 LDAP。

LDAP を介した外部ユーザー認証が必要な場合はオプションです。

TCP 443

UI、REST、HTTPS

Web UI、REST、HTTPS 管理ポート。

ポートを開いておく必要があります。

UDP と TCP 636

LDAPS

SSL を介した LDAP による Cisco IMC ユーザー管理。

LDAPS を介した外部ユーザー認証が必要な場合はオプションです。

TCP 2068

HTTPS

リモート KVM コンソールのリダイレクトポート。

ノードのインストールが完了するまでポートを開いておく必要があります。

UDP 123

NTP

NTP サーバーと時刻を同期します。

ポートを開いておく必要があります。

UDP 161

SNMP ポーリング/設定

SNMP サーバーのポーリングと設定。

SNMP サーバーのポーリングおよび設定のオプションです。

UDP 162

SNMP トラップ

SNMP トラップを外部 SNMP サーバーに送信します。

SNMP サーバーコレクタのオプションです。

UDP 514

Syslog

外部サーバーの障害とログを表示します。

メッセージログを外部サーバーに送信する場合のオプションです。

Catalyst Center からデバイスおよび他のシステムへのアウトバウンド

ICMP

Catalyst Center では、ネットワークデバイスの検出やネットワーク接続の問題のトラブルシューティングに ICMP メッセージを使用します。

ICMP を有効にします。

TCP 22

SSH

Catalyst Center では、次の目的でネットワークデバイスに接続する際に SSH を使用します。

  • 検出用にデバイス設定を読み取る。

  • 設定を変更する。

Catalyst Center と管理対象ネットワークの間で SSH を開いておく必要があります。

TCP 23

Telnet

Telnet は使用しないことを強く推奨します。

Telnet は推奨されませんが、Catalyst Center では検出用のデバイス設定の読み取りや設定の変更に Telnet を使用できることに注意してください。

Telnet はデバイス管理に使用できますが、SSH のようなセキュリティメカニズムがないため推奨されません。

TCP 49

TACACS+

Cisco ISE などの TACACS+ サーバーを使用した外部認証を使用している場合のみ必要です。

TACACS+ サーバーを使用した外部認証を使用している場合のみ、ポートを開いておく必要があります。

TCP 80

HTTP

Catalyst Center は、トラストプールの更新に HTTP を使用します。

シスコのサポートするトラストプールにアクセスするには、アプライアンスから次の URL に対する発信トラフィックを許可するようにネットワークを設定します。

http://www.cisco.com/security/pki/

TCP 80

OCSP/CRL

Catalyst Center は、OCSP/CRL を使用した SSL/TLS 証明書の失効ステータスを確認します。

上記の URL は、直接でも Catalyst Center で構成されているプロキシサーバー経由でも到達できるようにする必要があります。そうしないと、 Catalyst Center が cisco.com に接続したときに証明書失効チェックがスキップされます。

http://validation.identrust.com

http://commercial.ocsp.identrust.com

UDP 53

DNS

Catalyst Center では、ホスト名の解決に DNS を使用します。

DNS によるホスト名の解決用にポートを開いておく必要があります。

UDP 123

NTP

Catalyst Center では、指定したソースとの時刻の同期に NTP を使用します。

時刻の同期用にポートを開いておく必要があります。

UDP 161

SNMP

Catalyst Center では、ネットワークデバイスの検出、デバイスタイプを含むデバイスインベントリの詳細の読み取り、CPU や RAM などのテレメトリデータの収集に SNMP を使用します。

ネットワークデバイスの管理と検出用にポートを開いておく必要があります。

TCP 443

HTTPS

Catalyst Center は HTTPS をクラウド接続型のアップグレードに使用します。

クラウド接続、テレメトリ、およびソフトウェアアップグレード用にポートを開いておく必要があります。

Cisco ISE 用のポートも開いておく必要があります。

TCP 830

NETCONF

Catalyst Center では、デバイスのインベントリ、検出、および設定に NETCONF を使用します。

NETCONF をサポートするネットワークデバイスの管理と検出用にポートを開いておく必要があります。

UDP 1645、1812

RADIUS

RADIUS サーバーを使用した外部認証を使用する場合のみ必要です。

Catalyst Center へのユーザーログインの認証に外部 RADIUS サーバーを使用している場合のみ、ポートを開いておく必要があります。

TCP 5222、8910

Cisco ISE

Catalyst CenterCisco ISE XMP(PxGrid 用)を使用します。

Cisco ISE 用にポートを開いておく必要があります。

TCP 9060

Cisco ISE

Catalyst CenterCisco ISE ERS API トラフィックを使用します。

Cisco ISE 用にポートを開いておく必要があります。

デバイスから Catalyst Center

ICMP

デバイスは ICMP メッセージを使用してネットワーク接続の問題を通知します。

ICMP を有効にします。

TCP 22、80、443

HTTPS、SFTP、HTTP

Catalyst Center からのソフトウェアイメージのダウンロードに HTTPS 443、SFTP 22、HTTP 80 を使用します。

Catalyst Center からの証明書のダウンロードに HTTPS 443、HTTP 80(Cisco 9800 ワイヤレスコントローラ、PnP)、センサー/テレメトリを使用します。

Catalyst Center からの JWT(認証トークン)の取得に HTTPS:443(Cisco Catalyst Assurance インテリジェントキャプチャ機能を使用する任意のアクセスポイント)を使用します。

(注)  

 

ポート 80 については、プラグアンドプレイ(PnP)、ソフトウェアイメージ管理(SWIM)、組み込みイベント管理(EEM)、デバイス登録、Cisco 9800 ワイヤレスコントローラを使用しない場合はブロックしてください。

これらのポートでアクセス権限が付与されたホストまたはネットワークデバイスの送信元 IP がファイアウォールルールで制限されていることを確認してください。

UDP 67

BOOTP

ネットワークデバイスと Catalyst Center 間の通信を開始するために使用します。

ポートを開いておく必要があります。

111

NFS

Assurance のバックアップに使用します。

ポートを開いておく必要があります。

UDP 123

NTP

デバイスは時刻の同期に NTP を使用します。

デバイスが時刻を同期できるようにポートを開いておく必要があります。

UDP 162

SNMP

Catalyst Center はデバイスから SNMP ネットワークテレメトリを受信します。

SNMP に基づくデータ分析用にポートを開いておく必要があります。

UDP 514

Syslog

Catalyst Center はデバイスから syslog メッセージを受信します。

syslog に基づくデータ分析用にポートを開いておく必要があります。

2049

NFS

Assurance のバックアップに使用します。

ポートを開いておく必要があります。

UDP 6007

NetFlow

Catalyst Center はデバイスから NetFlow ネットワークテレメトリを受信します。

NetFlow に基づくデータ分析用にポートを開いておく必要があります。

TCP 9991

Wide Area Bonjour サービス

Catalyst Center は、Bonjour 制御プロトコルを使用して、サービス検出ゲートウェイ(SDG)エージェントからマルチキャスト ドメイン ネーム システム(mDNS)トラフィックを受信します。

Bonjour アプリケーションがインストールされている場合、Catalyst Center でポートを開いておく必要があります。

20048

NFS

Assurance のバックアップに使用します。

ポートを開いておく必要があります。

UDP 21730

アプリケーション可視性サービス

アプリケーション可視性サービスの CBAR デバイス通信。

ネットワークデバイスで CBAR が有効になっている場合、ポートを開いておく必要があります。

TCP 25103

ストリーミングテレメトリが有効になっている Cisco 9800 ワイヤレスコントローラおよび Cisco Catalyst 9000 スイッチ

テレメトリに使用されます。

Catalyst Center と Catalyst 9000 デバイス間のテレメトリ接続用にポートが開いている必要があります。

TCP 32626

インテリジェントキャプチャ(gRPC)コレクタ

Cisco Catalyst Assurance インテリジェントキャプチャ機能に関連する AP/クライアント統計情報およびパケットキャプチャデータの受信用の gRPC チャネルを確立するために使用します。

Cisco Catalyst Assurance インテリジェントキャプチャ(gRPC)機能を使用する場合、ポートを開いておく必要があります。

TCP および UDP 32767

NFS

Assurance のバックアップに使用します。

ポートを開いておく必要があります。

HTTP ポート 80 例外リスト

表 2. HTTP ポート 80 例外リスト
エリア HTTP ポート 80 が必要な理由 該当する Catalyst Center/デバイスバージョン E2E 暗号化がない場合でもセキュリティを実現する方法

SCEP

RFC 8894 - Simple Certificate Enrollment Protocol

すべての Catalyst Center およびデバイスバージョン。

SCEP は、共有秘密と PKCS12 により暗号化された CSR/証明書交換を使用します。

プラグ アンド プレイ

PnP Hello は HTTP 経由で実行されますが、デバイスが ios.p7b をダウンロードすると HTTPS に切り替わります。

デバイスは、ios.7b トラストバンドルにトラストを固定することで、Catalyst Center との HTTPS を確立します。

すべての Catalyst Center およびデバイスバージョン。

Ios.p7b は、Cisco Manufacturing CA によって署名された暗号化ハッシュで保護されています。

テレメトリ証明書のダウンロード

証明書は HTTP を使用してダウンロードされます。

すべての Catalyst Center およびデバイスバージョン。

ダウンロードされた証明書は PKCS12 で暗号化されます。

SWIM

リモートサーバー(HTTP)から Catalyst Center イメージリポジトリにイメージをインポートすることができます。

すべての Catalyst Center バージョン。

HTTP を介してインポートされたイメージは、ファイルのハッシュをチェックすることによって完全性が検証されます。

Catalyst Center のディザスタリカバリの有効化

Catalyst Center は、Catalyst Center クラスタの損失(またはデータセンターの損失)から回復し、運用の継続性を維持するメカニズムを備えています。ディザスタ リカバリ アプリケーションは、メイン Catalyst Center クラスタの重要なデータをセカンダリ スタンバイ クラスタに複製することによって回復を促進します。

セキュリティに関する推奨事項Catalyst Center クラスタの損失(またはデータセンターの損失)から回復し、運用の継続性を維持するために、Catalyst Center のディザスタリカバリサービスを有効にすることを推奨します。

Catalyst Center リカバリクラスタには、メイン Catalyst Center クラスタから複製されたすべての重要なデータ(MongoDB、Postgresql、クレデンシャルと証明書、ファイルサービスなど)が含まれており、メイン Catalyst Center クラスタが失われた場合に制御します。詳細については、『Cisco Catalyst Center Administrator Guide』の「Set Up Disaster Recovery」を参照してください。


(注)  


ディザスタリカバリでは、メインシステム、リカバリシステム、および監視システム間のネットワークトラフィックを保護するために IPsec トンネリングを使用します。ディザスタリカバリシステム間の IPsec トンネリングを設定するための認証は、OpenSSL 証明書を使用した証明書ベースの方法を通じて行われます。

IPsec トンネリングでは、IPsec プロトコルのキー交換フェーズに安全で堅牢な IKE2 プロトコルを使用します。


ディザスタリカバリには別の証明書(HTTPS 接続用の Catalyst Center システム証明書とは別の証明書)を使用します。詳細については、『Cisco Catalyst Center Administrator Guide』の「Add the Disaster Recovery Certificate」[英語] を参照してください。

ディザスタリカバリ証明書の要件のチェック

ディザスタリカバリを使用する場合は、ディザスタリカバリシステムがクラスタ内通信に使用する証明書をインポートします。この方法については、『Cisco Catalyst Center Administrator Guide』の「Add the Disaster Recovery Certificate」のトピックを参照してください。


(注)  


  • メインサイトとリカバリサイトの両方で使用される、エンタープライズポートの仮想 IP アドレスと完全修飾ドメイン名(FQDN)などのすべての IP アドレスがこの証明書に含まれていることを確認してください。また、証明書の [keyUsage] パラメータに [digitalSignature] が指定されていることを確認します。

  • サードパーティ証明書の生成方法については、「OpenSSL を使用した証明書要求の生成」を参照してください。


ディザスタリカバリに FQDN のみの証明書を使用しているかどうかに基づいて、次のタスクのいずれかを選択します。

  • FQDN のみの証明書を使用している場合:メインクラスタとリカバリクラスタの両方、およびディザスタリカバリの VIP で同じ cluster_hostname(つまり、Catalyst Center 設定ウィザードで設定した Catalyst Center の FQDN)を使用します。証明書のサブジェクト代替名(alt_names セクション)は、次の例のようになります。
    [alt_names]
    DNS.1 = FQDN-of-Catalyst-Center
  • FQDN のみの証明書を使用していない場合:メインクラスタとリカバリクラスタの両方で、異なる cluster_hostnames(つまり、Catalyst Center 設定ウィザードで設定した企業ネットワーク内の Catalyst Center の FQDN)を使用します。証明書のサブジェクト代替名(alt_names セクション)は、次の例のようになります。
    [alt_names]
    DNS.1 = FQDN-of-Catalyst-Center-Main
    DNS.2 = FQDN-of-Catalyst-Center-Recovery
    

(注)  


PnP を使用する場合は、PnP 証明書の要件のチェックを参照してください。


ディザスタリカバリポート

実稼働環境でディザスタリカバリを使用している場合は、ディザスタリカバリの設定を保護するファイアウォールとセキュリティポリシーを使用します。表に示されているポートを開き、ネットワークのデータセンター全体でディザスタリカバリを設定するために必要なアクセス権が Catalyst Center にあることを確認します。


重要


  • 3 ノードクラスタの場合は、各ノードの送信元エンタープライズ IP アドレスが許可されていることを確認します。

  • ネットワークのファイアウォールで ICMP を有効にします。Catalyst Center は、ディザスタリカバリシステムのメインサイト、リカバリサイト、および監視サイト間の接続を追跡するために ICMP ping を定期的に送信します。


表 3. Catalyst Center ディザスタリカバリポート
ソース ポート 送信元 宛先ポート 接続先 説明

任意

Catalyst Center エンタープライズ IP/VIP

TCP 443

Catalyst Center エンタープライズ VIP

REST API アクセス

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 500

Catalyst Center エンタープライズ VIP

IPSec トンネル

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 873

Catalyst Center エンタープライズ VIP

rsync による GlusterFS データのレプリケーション

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 4500

Catalyst Center エンタープライズ VIP

IPSec トンネル

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8300

Catalyst Center エンタープライズ VIP

Consul RPC 通信

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8301

Catalyst Center エンタープライズ VIP

Consul SERF LAN ポート

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 8301

Catalyst Center エンタープライズ VIP

Consul SERF LAN ポート

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8302

Catalyst Center エンタープライズ VIP

Consul SERF WAN ポート1

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 8302

Catalyst Center エンタープライズ VIP

Consul SERF WAN ポート1

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8443

Catalyst Center エンタープライズ VIP

HA プロキシ API アクセス 2

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 500

監視 IP

IPSec トンネル

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 2222

監視 IP

監視システム到達可能性のための TCP ping

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 4500

監視 IP

IPSec トンネル

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8300

監視 IP

Consul RPC 通信

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8301

監視 IP

Consul SERF LAN ポート

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 8301

監視 IP

Consul SERF LAN ポート

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8302

監視 IP

Consul SERF WAN ポート1

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

UDP 8302

監視 IP

Consul SERF WAN ポート1

任意 (Any)

Catalyst Center エンタープライズ IP/VIP

TCP 8443

監視 IP

HA プロキシ API アクセス 2

任意(Any)

Catalyst Center エンタープライズ/管理 VIP

TCP 179

ネイバールータ

ネイバールータとの BGP セッション

(注)  

 

ディザスタリカバリ VIP をアドバタイズするように BGP が設定されている場合は、このポートを開きます。

任意(Any)

監視 IP

UDP 53

DNS Server

監視システムから DNS サーバーへ

任意(Any)

監視 IP

UDP 123

NTP Server

監視システムから NTP サーバーへ

任意(Any)

監視 IP

TCP 443

Catalyst Center エンタープライズ VIP

ディザスタリカバリ登録時の API へのアクセス

任意(Any)

監視 IP

UDP 500

Catalyst Center エンタープライズ VIP

IPSec トンネル

任意(Any)

監視 IP

UDP 4500

Catalyst Center エンタープライズ VIP

IPSec トンネル

任意(Any)

監視 IP

TCP 8300

Catalyst Center エンタープライズ VIP

Consul RPC 通信

任意(Any)

監視 IP

TCP 8301

Catalyst Center エンタープライズ VIP

Consul SERF LAN ポート

任意(Any)

監視 IP

UDP 8301

Catalyst Center エンタープライズ VIP

Consul SERF LAN ポート

任意(Any)

監視 IP

TCP 8302

Catalyst Center エンタープライズ VIP

Consul SERF WAN ポート1

任意(Any)

監視 IP

UDP 8302

Catalyst Center エンタープライズ VIP

Consul SERF WAN ポート1

任意(Any)

監視 IP

TCP 8443

Catalyst Center エンタープライズ VIP

HA プロキシ API アクセス 2

1 この要件は今後の Catalyst Center リリースで排除される予定です。
2 この要件は、今後の Catalyst Center リリースで追加されます。

必要なインターネット URL と完全修飾ドメイン名へのインターネットアクセスの保護

セキュリティに関する推奨事項:HTTPS プロキシを通じて、Catalyst Center で必要とされる URL と完全修飾ドメイン名だけにセキュアアクセスを許可することを推奨します。

詳細については、最新の『Cisco Catalyst Center Appliance Installation Guide』の「Required internet URLs and fully qualified domain names」および「Provide secure access to the internet」を参照してください。

管理インターフェイスの保護

Cisco Integrated Management Controller(IMC)を使用している場合、Catalyst Center アプライアンスで最初に実行するセキュリティアクションは、アウトオブバンド管理インターフェイス(Cisco IMC)アカウントの保護です。パスワードポリシーに従って、admin アカウントのデフォルトパスワードをより強力な値に変更します。『Cisco Catalyst Center Appliance Installation Guide』の「Enable browser access to Cisco IMC」および『Cisco Catalyst Center Administrator Guide』の「Configure external authentication」を参照してください。


(注)  


スーパー管理者アクセス権を持つ Maglev CLI ユーザーのパスワードを保護する必要があります。詳細については、『Cisco Catalyst Center Administrator Guide』の「Configure the primary node」を参照してください。


インターフェイスへの IP トラフィックのレート制限

セキュリティに関する推奨事項:ネットワークデバイスから Catalyst Center への着信 IP トラフィックにレート制限を適用することを推奨します。

デフォルトでは、Catalyst Center のインターフェイスへの IP トラフィックにはレート制限は適用されません。ただし、Catalyst Center インターフェイスへの特定の送信元 IP またはすべてのトラフィックからの着信 IP トラフィックのレート制限を行うことを推奨します。この制限は、内部ネットワークの脅威からの DoS/DDoS 攻撃に対する保護に役立ちます。

始める前に

この手順を実行するためには、root shell へのアクセス権限が必要です。ルートシェルアクセスを取得するには、Cisco TAC に問い合わせる必要があります。詳細については、『Cisco Catalyst Center Administrator Guide』の「About restricted shell」のトピックを参照してください。

手順

ステップ 1

SSH クライアントを使用して、設定ウィザードで指定した IP アドレスで Catalyst Center アプライアンスにログインします。

SSH クライアントで入力する IP アドレスは、ネットワークアダプタ用に設定した IP アドレスです。この IP アドレスは、アプライアンスを外部ネットワークに接続します。

ステップ 2

要求された場合は、SSH アクセス用にユーザー名とパスワードを入力します。

ステップ 3

特定の送信元からの着信トラフィックを制限するには、次のコマンドを入力します。

/opt/maglev/bin/throttle_ip [options]
Options
-h show this help text
-i IP to rate limit (default: 0.0.0.0 i.e. ALL traffic)
-c Committed Information Rate in KBps (default: 100 K Bps)
-n Interface number (Mandatory parameter)
-d delete the last config and move the NIC to default configuration
-a Insert the new IP (to be throttled) in the already build filter list
-s show the current filter

(注)  

 
特定の IP アドレスを入力しない場合、インターフェイス全体がスロットリングされます。インターフェイス名は必須で、トラフィックのすべてのクラスの入力転送レートがユーザー定義の基準に基づいて制限されます。
#To create a new filter list
./throttle_ip -i 192.0.2.105 -n enp0s8 -c 256

#To add a new IP with different bandwidth
./throttle_ip -a 192.0.2.106 -n enp0s8 -c 512

#To delete all the IP from the List
./throttle_ip -d -n enp0s8

#To show the filters
./throttle_ip -s -n enp0s8

ステップ 4

Catalyst Center アプライアンスからログアウトします。


最小 TLS バージョンの変更と RC4-SHA の有効化(安全でない)

セキュリティに関する推奨事項Catalyst Center の受信用の TLS 接続については、最小 TLS バージョンを TLSv1.2 にアップグレードしてください。

外部ネットワークからのノースバウンド REST API 要求には、ノースバウンド REST API ベースのアプリケーション、ブラウザ、および HTTPS を使用して Catalyst Center に接続しているネットワークデバイスが含まれます。Transport Layer Security(TLS)プロトコルは、このような要求を安全に保護します。

デフォルトでは、Catalyst Center は TLSv1.1 と TLSv1.2 をサポートしますが、SSL/TLS 接続の RC4 暗号はサポートしません。RC4 暗号には既知の弱点があるため、ネットワークデバイスでサポートされている場合は、最小 TLS バージョンを TLSv1.2 にアップグレードすることを推奨します。

Catalyst Center は、最小 TLS バージョンをダウングレードし、RC4-SHA を有効にする設定オプションを提供します。Catalyst Center の制御下にあるネットワークデバイスが既存の最小 TLS バージョン(TLSv1.1)または暗号をサポートできない場合は、このオプションを使用できます。ただし、セキュリティ上の理由から、Catalyst Center TLS のバージョンをダウングレードしたり RC4-SHA 暗号を有効にしたりしないことを推奨します。

Catalyst Center で TLS のバージョンを変更、または RC4-SHA を有効化するには、対応するアプライアンスにログインし、CLI を使用します。


(注)  


CLI コマンドは、リリースごとに変更される可能性があります。CLI の例では、すべての Catalyst Center リリース、特に Catalyst Center on ESXi リリースには適用されない可能性のあるコマンド構文を使用しています。

始める前に

この手順を実行するためには、maglev SSH アクセス権限が必要です。


(注)  


このセキュリティ機能は、Catalyst Center にポート 443 を適用します。この手順の実行により、Catalyst Center インフラストラクチャへのポートのトラフィックが数秒間無効になることがあります。したがって、TLS の設定は頻繁に行わないようにし、オフピーク時間またはメンテナンス期間中にのみ行う必要があります。

手順


ステップ 1

SSH クライアントを使用して、設定ウィザードで指定した IP アドレスで Catalyst Center アプライアンスにログインします。

SSH クライアントで入力する IP アドレスは、ネットワーク アダプタ用に設定した IP アドレスです。この IP アドレスは、アプライアンスを外部ネットワークに接続します。

ステップ 2

要求された場合は、SSH アクセス用にユーザー名とパスワードを入力します。

ステップ 3

次のコマンドを入力して、クラスタで現在有効になっている TLS バージョンを確認します。

次に例を示します。
Input
$ magctl service tls_version --tls-min-version show
Output
TLS minimum version is 1.1

ステップ 4

クラスタの TLS バージョンを変更する場合は、次のコマンドを入力します。たとえば、Catalyst Center 制御下のネットワークデバイスが既存の TLS バージョンをサポートできない場合は、現在の TLS バージョンを以前のバージョンに変更できます。

次の例は、TLS バージョン 1.1 から 1.0 に変更する方法を示しています。

Input
$ magctl service tls_version --tls-min-version 1.0
Output
Enabling TLSv1.0 is recommended only for legacy devices
Do you want to continue? [y/N]: y
WARNING: Enabling TLSv1.0 for api-gateway
deployment.extensions/kong patched

次の例は、TLS バージョン 1.1 から 1.2 に変更(RC4-SHA を有効にしていない場合のみ可能)する方法を示しています。

Input
$ magctl service tls_version --tls-min-version 1.2
Output
Enabling TLSv1.2 will disable TLSv1.1 and below
Do you want to continue? [y/N]: y
WARNING: Enabling TLSv1.2 for api-gateway
deployment.extensions/kong patched

(注)  

 
RC4-SHA 暗号が有効になっている場合、TLS バージョン 1.2 を最小バージョンとして設定することはサポートされていません。

ステップ 5

Catalyst Center と Catalyst 9000 デバイス間のストリーミングテレメトリ接続(TCP 25103 ポート経由)用の TLS バージョンを変更する場合は、次のコマンドを入力します。たとえば、Catalyst Center 管理下のネットワークデバイスが TLS バージョン 1.2 をサポートできる場合は、現在の TLS バージョンを変更できます。

次の例は、TLS バージョン 1.1 から 1.2 に変更する方法を示しています。

Input
$ magctl service tls_version --tls-min-version 1.2 -a assurance-backend collector-iosxe-db
Output
Enabling TLSv1.2 will disable TLSv1.1 and below
Do you want to continue? [y/N]: y
WARNING: Enabling TLSv1.2 for api-gateway
deployment.apps/collector-iosxe-db patched

ステップ 6

クラスタで RC4-SHA を有効にするには、次のコマンドを入力します(セキュアでないため、必要な場合だけにしてください)。

TLS バージョン 1.2 が最小バージョンである場合、RC4-SHA 暗号を有効にすることはサポートされていません。

次の例は、TLS バージョン 1.2 が有効になっていないことを示しています。
Input
$ magctl service ciphers --ciphers-rc4=enable kong
Output
Enabling RC4-SHA cipher will have security risk
Do you want to continue? [y/N]: y
WARNING: Enabling RC4-SHA Cipher for kong
deployment.extensions/kong patched

ステップ 7

プロンプトで次のコマンドを入力して、TLS および RC4-SHA が設定されていることを確認します。

次に例を示します。
Input
$ magctl service display kong 
Output
      containers:
      - env:
        - name: TLS_V1
          value: "1.1"
        - name: RC4_CIPHERS
          value: "true"

(注)  

 

RC4 および TLS の最小バージョンが設定されている場合は、magctl service display kong コマンドの env: にリストされます。これらの値が設定されていない場合は、env: に表示されません。

ステップ 8

以前に有効にした RC4-SHA 暗号を無効にするには、クラスタで次のコマンドを入力します。

Input
$ magctl service ciphers --ciphers-rc4=disable kong
Output
WARNING: Disabling RC4-SHA Cipher for kong
deployment.extensions/kong patched

ステップ 9

Catalyst Center アプライアンスからログアウトします。


Catalyst Center による HTTPS 接続のための OCSP および CRL の使用

Catalyst Center では、オンライン証明書ステータスプロトコル(OCSP)と証明書失効リスト(CRL)を使用して、リモート証明書が失効していないことを確認します。

手順


ステップ 1

Catalyst Center は OCSP をチェックします。証明書の Authority Information Access(AIA)フィールドに有効な OCSP URI または URL が記載されていれば、Catalyst Center は失効ステータスを検証するためにその URI または URL に OCSP 要求を送信します。

  • 証明書が失効している場合、Catalyst Center は接続を終了し、エラーを返します。

  • 証明書が失効していない場合、接続に進みます。

  • 接続がタイムアウトした場合(エアギャップネットワークの場合など)、次の手順に進みます。

  • 接続が不正な OCSP または CRL レスポンダに到達した場合、Catalyst Center は接続を終了し、エラーを返します。Cisco Web セキュリティアプライアンス(WSA)などの中間者(MiTM)Web プロキシがインターネット向けトラフィックに使用されている場合は、Catalyst Center からの OCSP および CRL URL を許可するように設定されていることを確認します。

ステップ 2

Catalyst Center は CRL をチェックします。証明書に CRL Distribute Points フィールドがあり、そのフィールドに有効な CRL URI または URL のエントリが少なくとも 1 つ記載されていれば、Catalyst Center はその URI または URL から CRL をダウンロードし、ダウンロードした CRL と照合して証明書を検証します。

  • 証明書が失効している場合、Catalyst Center は接続を終了し、エラーを返します。

  • 証明書が失効していない場合、接続に進みます。

  • 接続がタイムアウトした場合(エアギャップネットワークの場合など)、接続に進みます。これが最後のチェックであり、ほかには証明書が失効していることを確認する方法がないためです。

  • 接続が不正な OCSP または CRL レスポンダに到達した場合、Catalyst Center は接続を終了し、エラーを返します。Cisco WSA などの MiTM Web プロキシがインターネット向けトラフィックに使用されている場合は、Catalyst Center からの OCSP および CRL URL を許可するように設定されていることを確認します。

(注)  

 

Catalyst Center は HTTP タイプの CRL をサポートします。証明書で OCSP を定義するか、または [CRL Distribution Points] フィールドで、Lightweight Directory Access Protocol(LDAP)CRL の前に HTTP CRL をリストします。OCSP または HTTP CRL が使用できない場合、Catalyst Center は LDAP/AD をサポートしていないため、失効チェックを実行しません。

CRL 配布ポイントがチェックされる順序については、『Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile』の「CRL Distribution Points」[英語] の項を参照してください。


クレデンシャルとパスワードの管理

クラスタのパスワード

Catalyst Center は、3 ノード構成のクラスタをサポートします。効率性とセキュリティのために、次のアクションを推奨します。

  • エンタープライズ ネットワークへの接続用、クラスタ内ネットワークの形成用、および専用管理ネットワークへの接続用に、それぞれ専用のインターフェイスを持つクラスタを作成する必要があります。

  • クラスタ内ネットワークは隔離されたレイヤ 2 セグメントであり、他のネットワークセグメントを介して接続またはルーティングすることはありません。

  • Catalyst Center のクラスタメンバー間でパスワード(Cisco IMC または SSH)を再利用しないでください。

SSH または Maglev パスワード回復

SSH パスワードは保護する必要があります。SSH パスワードを共有する相手はスーパー管理者だけにしてください。Catalyst Center には SSH パスワードを回復する機能はありません。

SSH アカウントのロックアウトと回復

SSH を使用したログイン試行に 6 回連続して失敗すると、最後に失敗した時点から 5 分間、maglev アカウントが一時的にロックされます。このロックアウト期間中は、正しいパスワードでのログイン試行も失敗し、ログイン失敗としてカウントされます。SSH ログインのアカウントのロックは、その間にログインアクティビティがなければ 5 分後に解除されます。ただし、ロックアウト期間中も Cisco IMC コンソールを使用したログインは引き続き機能します。管理者は、Linux シェルで次のコマンドを実行することで、ロックアウト期間中に SSH ログインを有効にできます。

sudo pam_tally2 --reset

Web UI パスワードの回復

Web UI ユーザーがパスワードを忘れた場合は、コマンドラインシェルを使用してパスワードをリセットできます。これには SSH またはコンソールアクセスが必要です。『Cisco Catalyst Center Administrator Guide』の「Reset a Forgotten Password」[英語] を参照してください。

パスワードの暗号化

Catalyst Center の着脱可能な認証モジュール(PAM)では、デフォルトでは SHA-512 ハッシュアルゴリズムを使用してローカルユーザーアカウントのパスワードを保存およびハッシュします(UNIX ベースのシステムで使用可能な最も強力な方法)。Catalyst Center のパスワード暗号化メカニズムについて、ユーザーが設定可能なアクションはありません。

ログとデータベース管理

システムログは、昇格された権限(sudo アクセス)を持つオペレーティングシステム管理者ユーザーが使用できます。アプリケーションログは Elasticsearch に保存され、認証後に Web UI からアクセスできます。データベースはクレデンシャルによって保護されます。クレデンシャルはインストール時にランダムに生成され、データベースアクセスを必要とするアプリケーションに安全に渡されます。これらの設定の変更について、ユーザーが設定可能なアクションはありません。

通信プロトコルのペイロード暗号化

クラスタモードでは、Catalyst Center のノードはクラスタ内ネットワークを介して相互に通信します。クラスタ内トラフィックに個別の暗号化は適用されません。クラスタ内ネットワークを分離しておくことが重要です。


(注)  


相互に機密データを交換するサービスでは HTTPS を使用します。


GUI ユーザーおよび Linux ユーザーパスワードの変更

セキュリティに関する推奨事項Catalyst Center GUI ユーザーパスワードと Linux ユーザーの(maglev)パスワードは定期的に変更することを推奨します。

手順


ステップ 1

Linux ユーザーのパスワードを変更するには、次の手順を実行します。

  1. SSH クライアントを使用して、設定ウィザードで指定した IP アドレスで Catalyst Center アプライアンスにログインします。SSH クライアントで入力する IP アドレスは、ネットワーク アダプタ用に設定した IP アドレスです。

  2. 要求された場合は、SSH アクセス用にユーザー名とパスワードを入力します。

  3. 入力するコマンド

    Input
    $ sudo maglev-config update

    maglev 設定ウィザードのようこそ画面が開きます。

  4. [User Account Settings] ウィザード画面が表示されるまで [next>>] をクリックします。

  5. Linux ユーザーのパスワードを入力します。

  6. [CONFIGURATION SUCCEEDED!] メッセージが表示されるまで [next>>] をクリックします。

    (注)  

     

    詳細については、『Cisco Catalyst Center Appliance Installation Guide』の「Configure the Appliance Using the Maglev Wizard」の章を参照してください。

ステップ 2

GUI ユーザーパスワードを変更するには、次の手順を実行します。

(注)  

 

ユーザー自身だけが Catalyst Center にログインするために入力するパスワードを変更できます。管理者権限を持つユーザーであっても、ユーザーのパスワードを変更できません。管理者がユーザーのパスワードを変更する必要がある場合は、ユーザーを削除し、新しいパスワードを使用してユーザーを再度追加する必要があります。

  1. Catalyst Center GUI にログインします。

  2. メインメニューから次を選択します。[System] > [Users & Roles] > [Change Password] の順にクリックします。

  3. 必要なフィールドに情報を入力し、[Update] をクリックします。


証明書を管理する

デフォルトの証明書

セキュリティに関する推奨事項Catalyst Center のデフォルトの Transport Layer Security 証明書を内部認証局の署名付き証明書に置き換えることを推奨します。

デフォルトでは、Catalyst Center は自己署名証明書を使用します。Catalyst Center によるデバイスの管理には、それ以外に展開されていなければ、デバイスの自己署名証明書が使用されます。展開時には内部認証局の署名付き証明書を使用することを強く推奨します。


(注)  


  • Catalyst Center の証明書を自己署名証明書から内部 CA の署名付き証明書、またはルート CA の証明書から下位 CA の証明書に変更する際は、新しいトラストポイント CA により Catalyst Center の管理対象デバイスが最プロビジョニングされます。再プロビジョニングは自動的に開始されますが、Catalyst Center 2.3.7 以降では、ネットワーク管理者が変更を承認する必要がある場合があります。デバイスの再プロビジョニングが完了するまで、デバイスは Catalyst Center への新しい TLS/HTTPS 接続を認証できません。つまり、デバイスは SWIM 操作を実行したり、アシュアランステレメトリを送信したり、PnP を介して設定を取得したりすることができません。

    そのため、証明書のアップグレードは展開の開始前に行うことを強く推奨します。

  • FQDN のみの証明書の展開の場合、デバイスは Catalyst Center によってプロビジョニングされ、クラスタホスト名(FQDN)を使用して Catalyst Center に到達するため、DNS アーキテクチャは、クラスタのインターフェイス VIP または IP に対してデバイスが FQDN を解決できるようにする必要があります。


証明書および秘密キーのサポート

Catalyst Center は、セッション(HTTPS)の認証に使用される認証局管理機能をサポートしています。これらのセッションでは、CA と呼ばれる一般に認められた信頼されたエージェントを使用します。Catalyst Center は、認証局管理機能を使用して、内部 CA から X.509 証明書をインポートして保存し、管理します。インポートされた証明書は Catalyst Center のアイデンティティ証明書になり、Catalyst Center は認証のためにこの証明書をクライアントに提示します。クライアントは、ノースバウンド API アプリケーションとネットワークデバイスです。

Catalyst Center GUI を使用して次のファイルを(PEM または PKCS ファイル形式で)インポートできます。

  • X.509 証明書

  • 秘密キー(Private key)


(注)  


秘密キーについては、Catalyst Center で RSA キーのインポートをサポートしています。ユーザー自身のキー管理システムで秘密キーを保護してください。秘密キーのモジュラスサイズは最小でも 2048 ビット必要です。


ファイルをインポートする前に、内部 CA で発行された有効な X.509 証明書と秘密キーを取得する必要があります。証明書は所有する秘密キーに対応している必要があります。ファイルをインポートすると、X.509 証明書と秘密キーに基づくセキュリティ機能が自動的にアクティブ化されます。Catalyst Center は証明書を、要求するデバイスまたはアプリケーションに提示します。ノースバウンド API アプリケーションとネットワークデバイスでは、これらのログイン情報を使用して Catalyst Center との信頼関係を確立できます。


(注)  


自己署名証明書を使用したり、Catalyst Center にインポートしたりすることは推奨されません。内部 CA から有効な X.509 証明書をインポートすることをお勧めします。さらに、プラグアンドプレイ機能を正常に動作させるには、自己署名証明書(デフォルトで Catalyst Center にインストールされている)を、内部 CA によって署名された証明書に置き換える必要があります。


Catalyst Center は一度に 1 つのインポート済み X.509 証明書および秘密キーだけをサポートします。2 つ目の証明書および秘密キーをインポートすると、最初の(既存の)インポート済み証明書および秘密キーの値が上書きされます。

証明書チェーンのサポート

Catalyst Center では、GUI を介して証明書と秘密キーをインポートできます。場合によっては、下位証明書が、Catalyst Center にインポートされる署名付き証明書につながる証明書チェーンに含まれていることがあります。このような場合、これらの下位 CA の下位証明書とルート証明書の両方を 1 つのファイルに追加してインポートする必要があります。これらの証明書を追加する場合は、認定の実際のチェーンと同じ順序で追加する必要があります。

これらの証明書は、単一の PEM ファイルに一緒に貼り付ける必要があります。証明書のサブジェクト名と発行元を調べて、正しい証明書がインポートされ、正しい順序が維持されていることを確認してください。また、チェーンに含まれるすべての証明書が一緒に貼り付けられていることを確認してください。

  • [Signed Catalyst Center certificate]:件名フィールドに共通名 =<FQDN of Catalyst Center> が含まれていて、発行元が発行機関の CN を持っている。


    (注)  


    サードパーティ証明書をインストールする場合は、Catalyst Center へのアクセスに使用するすべての DNS 名(Catalyst Center の FQDN を含む)が証明書の alt_names セクションで指定されていることを確認してください。詳細については、OpenSSL を使用した証明書要求の生成のステップ 2 を参照してください。


  • [Issuing (subordinate) CA certificate that issues the Catalyst Center certificate]:サブジェクト名のフィールドには Catalyst Center の証明書を発行する(下位)CA の CN が含まれており、発行元が、ルート CA の CN を持っている。

  • [Next issuing (root/subordinate CA) certificate that issues the subordinate CA certificate]:件名フィールドがルート CA で、発行元が件名フィールドと同じ値である。それらが同じ値でない場合は、その次の発行元を追加していきます。

Catalyst Center サーバー証明書の更新

Catalyst Center では、認証局(CA)からの X.509 証明書と Catalyst Center によって生成された秘密キーをインポートして保存できます。これらを使用して、Catalyst Center、ノースバウンド API アプリケーション、およびネットワークデバイスの間に安全で信頼できる環境を作成することができます。[System Certificates] ウィンドウで証明書と秘密キーをインポートできます。

Catalyst Center サーバー証明書を更新するには、次の手順を実行します。

  1. 証明書署名要求(CSR)を生成します。

  2. CSR を CA に送信して、署名付き証明書を取得します。

  3. 署名付き証明書とそのチェーンを Catalyst Center にインポートします。

この手順では、CA の例として Microsoft Active Directory 証明書サービスを使用します。別の CA を使用する場合は、それに応じて手順を調整してください。


(注)  


Catalyst Center のサーバー証明書と秘密キーを更新する必要がある場合は、この手順を実行することをお勧めします。CLI ベースの手順で実行するには、『Catalyst Center セキュリティのベストプラクティスガイド』の「OpenSSL を使用した証明書要求の生成」のトピックを参照してください。


始める前に

秘密キーに対応する有効な X.509 証明書を内部 CA から取得する必要があります。

手順


ステップ 1

メインメニューから次を選択します。[System] > [Settings] > [Certificate] > [System Certificates] の順に選択します。

このウィンドウには、Catalyst Center のサーバー証明書に関する情報が表示され、これらの証明書を管理するためのアクションが提供されます。[System Certificates] の表には、証明書ごとに次の情報が表示されます。

  • [Issued To]:証明書の発行先。

  • [Issued By]:証明書に署名し、証明書を発行したエンティティの名前。

  • [Used For]:証明書がコントローラとディザスタリカバリのどちら(または両方)に使用されるかを示します。

  • [Certificate Serial Number]:証明書シリアル番号の最後の 5 文字を示します。

  • [Time Left]:証明書の有効期間の残り時間。

  • [Status]:証明書のステータスを表示します。

  • [Valid From/Valid To]:証明書が有効な時期。

    (注)  

     

    証明書の有効な日時は、グリニッジ標準時(GMT)値で表示されます。証明書有効期限の 2 か月前に、通知センターにシステム通知が表示されます。表示するには、ウィンドウの右上隅にある通知アイコンをクリックします。

  • [Action]:証明書を管理するために使用可能なアクション(置換、削除など)を示します。

ステップ 2

[+ New Certificate Request (CSR)] をクリックします。

CSR を初めて生成するときは、この [+ New Certificate Request (CSR)] リンクが有効になります。

既存の CSR を使用しない場合は、既存の要求を削除してください。

  1. 表で、削除する要求を見つけます。

  2. [Action] で、その要求の [Delete] をクリックします。

  3. [Warning] ダイアログボックスで [OK] をクリックします。

    [+ New Certificate Request (CSR)] リンクが有効になります。

(注)  

 

古いバージョンの Catalyst Center を使用している場合は、[Replace Certificate] をクリックします。CSR を初めて生成するときは、[Generate New CSR] リンクが表示されます。それ以外の場合は、[Download existing CSR] リンクが表示されます。詳細については、『Cisco Catalyst Center Administrator Guide』の対応するバージョンを参照してください。

ステップ 3

[New Certificate Request (CSR)] スライドインペインで、CSR を作成します。

  1. [Used For] で、チェックボックスをオンにして、CSR がコントローラとディザスタリカバリのどちら(または両方)用かを示します

  2. 次の必須フィールドに値を入力します。

    • [Key Algorithm]:キーの生成に使用されるアルゴリズム。

    • [Digest]:CSR の保護および検証に使用されるダイジェストアルゴリズム。

    • [Key Length]:証明書のキーのビットサイズ。

    • [Common Name]:サーバーの IP アドレス、ホスト名、または FQDN。

    • [Key Usage]:証明書のキーの目的。使用可能な値の説明については、RFC 5280 のセクション 4.2.1.3 を参照してください。

    • [Extended Key Usage]:証明書のキーの追加の目的。使用可能な値の説明については、RFC 5280 のセクション 4.2.1.12 を参照してください。

    [New Certificate Request (CSR)] スライドインペインに、CSR を作成するための必須フィールドとオプションのフィールドが表示されています。
  3. [Next] をクリックして CSR を生成します

ステップ 4

[Certificate Signing Request] スライドインペインで、CSR のコピーをダウンロードします。

  1. [CSR のダウンロード(Download CSR)] をクリックします。

    CSR は Base64 ファイルとしてローカルにダウンロードされます。

  2. [Done] をクリックします。

[Certificate Signing Request] スライドインペインで新しい CSR が開きます。

ステップ 5

証明書要求を CA に送信し、CA から発行元 CA チェーンをダウンロードします。

たとえば、Microsoft Active Directory 証明書サービスを使用して証明書要求を送信するには、次の手順を実行します。

  1. 先ほどダウンロードした CSR をコピーします。

  2. 新しいブラウザウィンドウで [Active Directory Certificate Services] を開きます。

  3. [Welcome] ページで、[Request a certificate] をクリックします。

  4. [Request a Certificate] ページで、[advanced certificate request] をクリックします。

  5. [Submit a Certificate Request or Renewal Request] ページで、[Saved Request] フィールドに要求を貼り付け、証明書テンプレートを選択して、[Submit] をクリックします。

    選択した証明書テンプレートがクライアント認証とサーバー認証の両方に設定されていることを確認します。

    ダウンロード後、CA に貼り付けられた CSR。
  6. [Certificate Issued] ページで、証明書のエンコード方法を選択し、[Download certificate chain] をクリックします。

    証明書チェーンは CA からダウンロードされます。

    証明書は、DER エンコードまたは Base 64 エンコードとして発行されます。

ステップ 6

証明書発行元から p7b で証明書の完全なチェーン(サーバーおよび CA)が提供されたことを確認します。不明な場合は、次の手順を実行し、チェーンを確認して組み立てます。

  1. p7b バンドルを DER 形式でダウンロードし、server-cert-chain.p7b として保存します。

  2. 入力するコマンド

    openssl pkcs7 -in server-cert-chain.p7b -inform DER -out server-cert-chain.pem -print_certs

ステップ 7

Catalyst Center GUI の [+ System Certificates] ウィンドウで、[+ Import Certificate] をクリックします。

ステップ 8

[Import Certificate] スライドインペインで、その証明書署名付き認証局チェーンが連結された署名付き証明書を Catalyst Center にインポートします。

  1. [Used For] で、チェックボックスをオンにして、この証明書がコントローラとディザスタリカバリのどちら(または両方)用かを示します

    [Import Certificate] スライドインペインには、証明書のアップロード方法に関する情報が表示されます。
  2. [Type] で、次の表を使用して証明書のファイル形式タイプを選択します。

    タイプ

    説明

    操作

    PEM Chain

    プライバシー強化メールファイル形式。

    [PEM Chain] をクリックします。

    証明書発行元からルーズファイルで証明書とその発行元 CA チェーンが提供された場合は、次の手順を実行します。

    1. PEM(base64)ファイルを収集するか、OpenSSL を使用して DER ファイルを PEM 形式に変換します。

    2. 証明書とその発行元 CA を連結し、証明書から下位 CA に続いてルート CA までを dnac-server-cert-chain.pem ファイルに出力します。

      cat certificate.pem subCA.pem rootCA.pem > server-cert-chain.pem

    PKCS

    公開キー暗号化標準ファイル形式。

    [PKCS] をクリックします。

    (注)  

     

    [+ New Certificate Request (CSR)] オプションを選択して証明書を要求した場合、[PKCS] ファイルタイプは無効になります。

  3. 選択したファイルのタイプに応じて、ファイルをアップロードします。

    アップロードするファイル

    結果

    PEM ファイルと、該当する場合は秘密キー

    1. PEM ファイルと秘密キーファイルをドラッグアンドドロップします。

      (注)  

       
      • PEM ファイルには、有効な PEM 形式の拡張子(.pem、.cer、または .crt)が必須です。証明書の最大ファイルサイズは 1 MB です。

      • 秘密キーには、有効な秘密キー形式の拡張子(.key)が必須です。秘密キーの最大ファイルサイズは 1 MB です。

      • [+ New Certificate Request (CSR)] を使用して CSR を作成した場合、インポートする秘密キーはありません。秘密キーは Catalyst Center 内に格納されます。

      アップロードに成功すると、システム証明書と秘密キーが検証されます。

    2. 秘密キーについては、[Encrypted] で、暗号化するかどうかを指定します。

      [Yes] を指定した場合、[Password] フィールドに秘密キーのパスワードを入力します。

    PKCS ファイル

    1. [Bundle Password] フィールドに証明書のパスワードを入力します。

    2. PKCS ファイルをドラッグアンドドロップします。

      (注)  

       

      PKCS ファイルには、有効な PKCS 形式の拡張子(.pfx または .p12)が必須です。証明書の最大ファイルサイズは 1 MB です。

      アップロードに成功すると、システム証明書が検証されます。

  4. [Save] をクリックします。

  5. [Warning] ダイアログボックスで、[Continue] をクリックします。

    (注)  

     

    Catalyst Center サーバーの SSL 証明書が置き換えられると、自動的にログアウトされます。証明書のインポートには約 1 分かかることがあるため、再度ログインする前に、少なくとも 1 分待ってください。

ステップ 9

Catalyst Center に再度ログインしたら、[System Certificates] ウィンドウに戻り、更新された証明書データを確認します。

[User For] で、更新された証明書のハイパーリンクテキストをクリックし、発行者、CA、および有効な日付に関する情報をスライドインペインで表示します。


OpenSSL を使用した証明書要求の生成

OpenSSL は、証明書署名要求(CSR)と秘密キーの作成によく使用されます。Windows、Linux、Mac など、ほとんどのプラットフォーム用の OpenSSL バージョンがあります。OpenSSL を使用してコンピュータ上で証明書を生成し、その証明書を Catalyst Center にアップロードします。この手順を実行する前に、プラットフォームに固有の OpenSSL バージョンをインストールしてください。


(注)  



手順


ステップ 1

maglev cluster network display コマンドを入力して、Catalyst Center の設定時に Catalyst Center のホスト名(FQDN)が設定されていることを確認します。このコマンドを実行するにはルート権限が必要です。

Input
$ maglev cluster network display
Output
cluster_network:
	cluster_dns: 169.254.20.10
	cluster_hostname: fqdn.cisco.com

cluster_hostname 出力フィールドが空であるか目的のものと異なる場合は、以下の例に示すように、sudo maglev-config update コマンドを入力して Catalyst Center のホスト名(FQDN)を追加または変更します。このコマンドを実行するにはルート権限が必要です。

Input
$ sudo maglev-config update
Output
Maglev config wizard GUI

入力プロンプト [Cluster's hostname] を含む [MAGLEV CLUSTER DETAILS] という手順が表示されるまで、[Next] をクリックします。ホスト名を目的の Catalyst Center の FQDN に設定します。Catalyst Center が新しい FQDN で再設定されるまで [Next] と [Proceed] をクリックします。

ステップ 2

テキストエディタを使用して、openssl.cnf という名前の構成ファイルを作成します。

ステップ 3

次のコマンドを入力して秘密キーを作成します。認証局管理チームから求められた場合は、キーの長さを 2048 に調整します。

openssl genrsa -out csr.key 4096

ステップ 4

openssl.cnf ファイルのフィールドの読み込みが完了したら、前の手順で作成した秘密キーを使用して証明書署名要求を生成します。

openssl req -config openssl.cnf -new -key csr.key -out server-cert.csr 

ステップ 5

証明書署名要求の内容を確認し、DNS 名が [subjectAltName] フィールドに正しく入力されていることを確認します。

openssl req -text -noout -verify -in server-cert.csr

ステップ 6

証明書署名要求をコピーし、CA(MS CA など)に貼り付けます。

MS CA の証明書署名要求がウィンドウに表示されます。

選択した証明書テンプレートがクライアント認証とサーバー認証の両方に設定されていることを確認します(手順 2 の openssl.cnf ファイルの例に示した extendedKeyUsage の行を参照)。

ステップ 7

発行された証明書とその発行元 CA チェーンの収集に進みます。

ステップ 8

証明書発行元から p7b で証明書の完全なチェーン(サーバーおよび CA)が提供された場合は、次の手順を実行します。

  1. p7b バンドルを DER 形式でダウンロードし、server-cert-chain.p7b として保存します。

  2. バンドルで提供される各証明書について、次のことを確認します。

    • -----BEGIN PKCS7----- ヘッダーで始まる。

    • -----END PKCS7----- フッターで終わる。

    そうでない場合、次の手順で入力するコマンドが失敗する可能性があります。

  3. 入力するコマンド

    openssl pkcs7 -in server-cert-chain.p7b -inform DER -out server-cert-chain.pem -print_certs

ステップ 9

証明書発行元からルーズファイルで証明書とその発行元 CA チェーンが提供された場合は、次の手順を実行します。

  1. PEM(base64)ファイルを収集するか、openssl を使用して DER を PEM に変換します。

  2. 証明書とその発行元 CA を連結し、証明書から下位 CA に続いてルート CA までを dnac-server-cert-chain.pem ファイルに出力します。

    cat certificate.pem subCA.pem rootCA.pem > server-cert-chain.pem

ステップ 10

csr.key および server-cert-chain.pem ファイルを Catalyst Center にインポートします。

  1. メインメニューから次を選択します。[System] > [Settings] > [Certificates] の順に選択します。

  2. [Import Certificate] をクリックします。

    (注)  

     

    古いバージョンの Catalyst Center を使用している場合は、[Replace Certificate] をクリックします。

  3. [Import Certificate] ウィンドウで、[PEM Chain] オプションボタンをクリックし、次のタスクを実行します。

    • [Drag and Drop] 領域にファイルをドラッグアンドドロップして、 [PEM] ファイルをインポートします。

      (注)  

       

      PEM ファイルには、有効な PEM 形式の拡張子(.pem、.cer、または .crt)が必須です。証明書の最大ファイルサイズは 1 MB です。

      アップロードに成功すると、システム証明書が検証されます。

    • [Drag and Drop] 領域にファイルをドラッグアンドドロップして、[Private Key] をインポートします。([Generate New CSR] リンクを使用した場合、インポートする秘密キーはありません。秘密キーは Catalyst Center 内に保存されます)。

      (注)  

       

      秘密キーには、有効な秘密キー形式の拡張子(.key)が必須です。秘密キーの最大ファイルサイズは 1 MB です。

      アップロードに成功すると、秘密キーが検証されます。

      • 秘密キーの [Encrypted] 領域から、暗号化オプションを選択します。

      • 暗号化を選択した場合、[Password] フィールドに秘密キーのパスワードを入力します。

  4. [Save] をクリックします。


証明書の設定に関する考慮事項

Catalyst Center 展開用の openssl.cnf 構成ファイルを作成する場合は、次の考慮事項に留意してください。

  • alt_names セクションに、Web ブラウザまたは PnP や Cisco ISE などの自動プロセスで Catalyst Center へのアクセスに使用するすべての DNS 名(Catalyst Center の FQDN を含む)が含まれている必要があります。

  • alt_names セクションに、最初の DNS エントリとして Catalyst Center の FQDN(DNS.1 = FQDN-of-Catalyst-Center)が含まれている必要があります。これは、Catalyst Center の設定時に設定ウィザード(クラスタのホスト名入力フィールド)で設定した Catalyst Center ホスト名(FQDN)と一致している必要があります。

    Catalyst Center の FQDN の代わりにワイルドカード DNS エントリを追加することはできませんが、alt-names セクションの後続の DNS エントリ(PnP およびその他の DNS エントリ)にはワイルドカードを使用できます。たとえば、*.domain.com は有効なエントリです。

    Catalyst Center では、現在のところ、すべてのインターフェイスに対して 1 つのホスト名(FQDN)のみがサポートされています。

  • 認証局管理チームから 2048/sha256 を求められた場合は、default_bitsdefault_md を調整します。

  • req_distinguished_name セクションと alt_names セクションのすべてのフィールドの値を指定します。唯一の例外は OU フィールドで、このフィールドは省略可能です。認証局管理チームから求められていなければ、OU フィールドは省略します。

  • emailAddress フィールドは省略可能です。認証局管理チームから求められていなければ省略します。

  • クラウドインターフェイスを設定していない場合は、クラウドポートのフィールドを省略します。

    • extendedKeyUsage 拡張の属性 serverAuth と clientAuth は必須です。いずれかの属性を省略すると、Catalyst Center で SSL 証明書が拒否されます。

    • 自己署名証明書をインポートする場合(非推奨)、X.509 の基本制約の「CA:TRUE」拡張を含める必要があり、keyUsage 拡張には keyCertSign が含まれる必要があります。

  • クロスサイト スクリプティング(XSS)攻撃に対して脆弱な小なり記号「<」は、証明書フィールドでは使用できません。

サンプル構成ファイル

次の openssl.cnf 構成ファイルの例を参照し、展開に合わせて必要な変更を行います。


重要


証明書の [keyUsage] パラメータに [digitalSignature] が指定されていることを確認します。


IP または FQDN を使用した openssl.cnf の例

req_extensions = v3_req
distinguished_name = req_distinguished_name
default_bits = 4096
default_md = sha512
prompt = no
[req_distinguished_name]
C = <two-letter-country-code>
ST = <state-or-province>
L = <city>
O = <company-name>
OU = MyDivision
CN = FQDN-of-Catalyst-Center
emailAddress = responsible-user@mycompany.tld

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = FQDN-of-Catalyst-Center
DNS.2 = pnpserver.DomainAssignedByDHCPDuringPnP.tld
DNS.3 = *.domain.com

PKI 認証局

クライアントでは、Catalyst Center との HTTPS 接続を確立する際、アイデンティティを確認して認証を完了するためにサーバー CA を使用します。Catalyst Center では、クライアントとの接続を確立するために、サーバー CA に加えて公開キーインフラストラクチャ(PKI)CA(ルート CA または下位 CA として設定)も使用します。PKI CA を使用すると、Catalyst Center のサーバー CA に関連付けられているものとは別のレルム信頼(署名 CA)を使用できます。

認証局のロールをルートから下位に変更

デバイス CA は Catalyst Center のプライベート CA であり、サーバーとクライアントの間の接続の確立と保護に使用される証明書やキーを管理します。デバイス CA のロールをルート CA から下位 CA に変更するには、この手順を実行します。

[Certificate Authority] ウィンドウの GUI を使用して、プライベート(内部)Catalyst Center CA のロールをルート CA から下位 CA に変更できます。この変更を行う際は、以下のようになります。

  • Catalyst Center が下位 CA の役割を果たすようにする場合、すでにルート CA(たとえば Microsoft CA)があり、Catalyst Center を下位 CA として認めているものと見なされます。

  • 下位 CA が完全に設定されていない限り、Catalyst Center は内部ルート CA としての役割を継続します。

  • Catalyst Center 用の証明書署名要求ファイルを生成し(この手順の記述に従う)、手動で外部ルート CA に署名させる必要があります。


    (注)  


    Catalyst Center は、この期間中は内部ルート CA として実行し続けます。


  • 証明書署名要求が外部ルート CA によって署名された後、GUI を使用してこの署名ファイルを Catalyst Center にインポートし直す必要があります(この手順の記述に従う)。

    インポート後、Catalyst Center は下位 CA として自身を初期化し、下位 CA の既存機能をすべて提供します。

  • CA のロールをルートから下位に切り替えると、古い CA は廃止され、新しい下位 CA の PKI チェーンが引き継がれます。失効リストは CA によって公開されます。CA が廃止されると、信頼を確立できないため、失効が無意味になります。未使用の証明書を最初に失効させることが組織のポリシーで規定されている場合は、CA のロールをルートから下位に切り替える前に、GUI の [Device Certificates] ウィンドウから証明書を失効させることができます。

    デバイスの可制御性(デフォルトで有効)は、下位 CA から提供された新しい証明書チェーンでデバイスを自動的に更新します。新しいテレメトリ接続は、この新しい証明書チェーンでのみ認証されます。これは、オーセンティケータ側の信頼できる下位 CA と一致します。

  • GUI に表示されている下位 CA 証明書有効期間は、証明書から読み取られたもので、システム時刻を使って計算されたものではありません。したがって今日、証明書を有効期間 1 年でインストールして来年の同じ時間に GUI で見ると、証明書の有効期間は 1 年間と表示されます。

  • 下位 CA 証明書として PEM または DER 形式のみを使用できます。

  • 下位 CA は上位の CA と連携しないため、上位レベルの証明書がある場合は、その失効に注意してください。このため、下位 CA からネットワークデバイスに対して、証明書の失効に関する情報が通知されることもありません。下位 CA にはこの情報がないため、すべてのネットワークデバイスは下位 CA を Cisco Discovery Protocol(CDP)送信元としてのみ使用します。

  • プラグアンドプレイ(PnP)の AP プロファイルに EAP-Transport Level Security(EAP-TLS)認証を使用する場合は、下位 CA を使用できないことに注意してください。ルート CA のみを使用できます。

始める前に

ルート CA 証明書のコピーが必要です。

手順


ステップ 1

メインメニューから次を選択します。 [System] > [Settings] > [Certificate Authority] の順に選択します。

ステップ 2

[CA Management] タブをクリックします。

ステップ 3

GUI で既存のルートまたは下位 CA 証明書の設定情報を確認します。

  • [Root CA Certificate]:現在のルート CA 証明書(外部または内部)を表示します。

  • [Root CA Certificate Lifetime]:現在のルート CA 証明書の最新の有効期間を表示します(日数)。

  • [Current CA Mode]:現在の CA モードを表示します(ルート CA または下位 CA)。

  • [SubCA mode]:ルート CA から下位 CA に変更できます。

ステップ 4

[CA Management] タブで、[Enable SubCA Mode] ボタンをクリックします。

ステップ 5

表示される警告内容を確認します。

次に例を示します。

  • ルート CA から下位 CA に変更するプロセスは元に戻すことができません。

  • ルート CA モードで登録された、または証明書が発行されたネットワーク デバイスがないことを確認する必要があります。ネットワークデバイスを誤ってルート CA モードで登録した場合は、ルート CA から下位 CA に変更する前に、取り消しをする必要があります。

  • 下位 CA の設定プロセスが終了しなければ、ネットワークデバイスをオンラインにできません。

ステップ 6

[OK] をクリックして続行します。

ステップ 7

[Import External Root CA Certificate Chain] フィールドにルート CA 証明書をドラッグアンドドロップして、[Upload] をクリックします。

ルート CA 証明書が Catalyst Center にアップロードされ、証明書署名要求の生成に使用されます。

アップロードプロセスが完了すると、「Certificate Uploaded Successfully」というメッセージが表示されます。

ステップ 8

[Next] をクリックします。

Catalyst Center で証明書署名要求が生成されて表示されます。

ステップ 9

Catalyst Center で生成された証明書署名要求を GUI で確認し、次のアクションのいずれかを実行します。

  • [Download] リンクをクリックして、証明書署名要求ファイルのローカルコピーをダウンロードします。

    その後、この証明書署名要求ファイルを電子メールに添付して、ルート CA に送信することができます。

  • [Copy to the Clipboard] リンクをクリックして、証明書署名要求ファイルの内容をコピーします。

    その後、この証明書署名要求の内容を電子メールに貼り付けるか、電子メールに添付ファイルとして添付して、ルート CA に送信することができます。

ステップ 10

証明書署名要求ファイルをルート CA に送信します。

ルート CA から下位 CA ファイルが返されます。このファイルを Catalyst Center にインポートし直す必要があります。

ステップ 11

ルート CA から下位 CA ファイルを受信した後、Catalyst Center の GUI に再度アクセスし、[Certificate Authority] ウィンドウに戻ります。

ステップ 12

[CA Management] タブをクリックします。

ステップ 13

[Change CA mode] ボタンの [Yes] をクリックします。

[Yes] をクリックすると、GUI に証明書署名要求が表示されます。

ステップ 14

[Next] をクリックします。

[Certificate Authority ] ウィンドウに、[Import SubCA Certificate] フィールドが表示されます。

ステップ 15

[Import SubCA Certificate] フィールドに下位 CA 証明書をドラッグアンドドロップして、[Apply] をクリックします。

下位 CA 証明書が Catalyst Center にアップロードされます。

アップロードが完了すると、GUI の [CA Management] タブに、下位 CA モードが表示されます。

ステップ 16

[CA Management] タブのフィールドを確認します。

  • [Sub CA Certificate]:現在の下位 CA 証明書を表示します。

  • [External Root CA Certificate]:ルート CA 証明書を表示します。

  • [Sub CA Certificate Lifetime]:下位 CA 証明書の有効期間を表示します(日数)。

  • [Current CA Mode]:SubCA モードを表示します。


ロールオーバー下位 CA 証明書のプロビジョニング

Catalyst Center では、既存の下位 CA の有効期間が 70% 以上経過している場合に、ユーザーがロールオーバー下位 CA として下位証明書を適用することができます。

始める前に

  • 下位 CA ロールオーバー プロビジョニングを開始するには、認証局のロールを下位 CA モードに変更しておく必要があります。認証局のロールをルートから下位に変更を参照してください。

  • 現在の下位 CA 証明書の有効期限が 70 % 以上経過していることが必要です。この状態になると、Catalyst Center の [CA Management] タブの下に [Renew] ボタンが表示されます。

  • ロールオーバー下位 CA の署名付き証明書のコピーが必要です。

手順


ステップ 1

メインメニューから次を選択します。[System] > [Settings] > [Certificate] > [Certificate Authority] の順に選択します。

ステップ 2

[CA Management] タブで、CA 証明書の設定情報を確認します。

  • [Subordinate CA Certificate]:現在の下位 CA 証明書を表示します。

  • [External Root CA Certificate]:ルート CA 証明書を表示します。

  • [Subordinate CA Certificate Lifetime]:現在の下位 CA 証明書の有効期間(日数)を表示します。

  • [Current CA Mode]:SubCA モードを表示します。

ステップ 3

[Renew] をクリックします。

Catalyst Center は既存の下位 CA を使用して、ロールオーバー下位 CA の証明書署名要求を生成し、表示します。

ステップ 4

生成された証明書署名要求を GUI で確認し、次のアクションのいずれかを実行します。

  • [Download] リンクをクリックして、証明書署名要求ファイルのローカルコピーをダウンロードします。

    その後、この証明書署名要求ファイルを電子メールに添付して、ルート CA に送信することができます。

  • [Copy to the Clipboard] リンクをクリックして、証明書署名要求ファイルの内容をコピーします。

    その後、この証明書署名要求の内容を電子メールに貼り付けるか、電子メールに添付ファイルとして添付して、ルート CA に送信することができます。

ステップ 5

証明書署名要求ファイルをルート CA に送信します。

次にルート CA がロールオーバー下位 CA ファイルを返送してくると、それを Catalyst Center にインポートし直す必要があります。

下位 CA ロールオーバーの証明書署名要求は、RootCA モードから SubCA モードに切り替えた際にインポートした下位 CA に署名したルート CA と同じルート CA によって署名される必要があります。

ステップ 6

ルート CA からロールオーバー下位 CA ファイルを受信した後、[Certificate Authority] ウィンドウに戻ります。

ステップ 7

[CA Management] タブをクリックします。

ステップ 8

証明書署名要求が表示されている GUI で [Next] をクリックします。

[Certificate Authority ] ウィンドウに、[Import Sub CA Certificate] フィールドが表示されます。

ステップ 9

下位ロールオーバー CA 証明書を [Import Sub CA Certificate] フィールドにドラッグアンドドロップし、[Apply] をクリックします。

ロールオーバー下位 CA 証明書が Catalyst Center にアップロードされます。

アップロードが終了すると、GUI が変更され、[CA Management] タブの [Renew] ボタンが無効になります。


デバイス証明書の有効期間の設定

Catalyst Center では、Catalyst Center のプライベート(内部)CA で管理および監視しているネットワークデバイスの証明書の有効期間を変更できます。Catalyst Center での証明書の有効期間のデフォルト値は 365 日です。Catalyst Center GUI を使用して証明書の有効期間を変更すると、それ以降に Catalyst Center に対して証明書を要求するネットワークデバイスにその有効期間の値が割り当てられます。


(注)  


デバイス証明書のライフタイム値を CA 証明書のライフタイム値より大きくすることはできません。さらに、CA 証明書の残りの有効期間が設定されたデバイスの証明書の有効期間より短い場合、デバイス証明書の有効期間の値は CA 証明書の残りの有効期間と同じになります。


手順


ステップ 1

メインメニューから次を選択します。[System] > [Settings] > [Certificate] > [Device Certificates] の順に選択します。

ステップ 2

デバイス証明書と現在のデバイス証明書の有効期間を確認します。

ステップ 3

[Device Certificates] ウィンドウで、[Modify] をクリックします。

ステップ 4

[Device Certificates Lifetime] ダイアログボックスに、新しい値を入力します(日数)。

ステップ 5

[Save] をクリックします。


Catalyst Center trustpool のサポート

Catalyst Center および Cisco IOS デバイスは、trustpool と呼ばれる特別な PKI 証明書ストアをサポートします。trustpool は信頼できる CA を特定する X.509 証明書を保持します。Catalyst Center およびネットワークのデバイスは trustpool バンドルを使用して、相互の信頼関係、およびそれらの CA との信頼関係を管理します。Catalyst Center はこの PKI 証明書ストアを管理します。プール内の証明書が失効したり、再発行されたりした場合、またはその他の理由で変更する必要がある場合は、管理者(ROLE_ADMIN)が Catalyst Center GUI を使って証明書を更新することができます。


(注)  


Catalyst Center は、trustpool 機能を使用して、GUI でアップロードする証明書ファイルが有効な trustpool CA 署名付き証明書であるかどうかも判別します。


Catalyst Center には、ios.p7b という名前のシスコの署名付き trustpool バンドルがデフォルトでプリインストールされています。この trustpool バンドルは、シスコのデジタル署名証明書で署名されているので、サポートされているシスコのネットワークデバイスによりネイティブで信頼されます。この trustpool バンドルは、シスコのネットワーク デバイスが純正のアプリケーションおよびサービスとの信頼を確立するために重要です。この Cisco PKI trustpool バンドルファイルは https://www.cisco.com/security/pki/ にあります。

Catalyst Center の PnP 機能にアクセスするために、Catalyst Center で管理および監視するサポート対象のシスコデバイスに Cisco PKI trustpool バンドルファイルをインポートする必要があります。サポートされているシスコデバイスは最初のブート時に、Catalyst Center にアクセスしてこのファイルをインポートします。

Catalyst Center trustpool の管理機能は次のように動作します。

  1. PnP 機能をサポートするネットワーク内のシスコデバイスをブートします。

    すべてのシスコデバイスが PnP をサポートするわけではありません。サポート対象のシスコデバイスの一覧については、「Cisco Catalyst Center Compatibility Matrix」[英語] を参照してください。

  2. PnP の最初のフローの一部として、サポート対象のシスコデバイスは、HTTP を使用して trustpool バンドルを Catalyst Center から直接ダウンロードします。

  3. シスコデバイスは、PnP トラフィックフローに従って詳細なデバイス設定およびプロビジョニングを取得するために Catalyst Center と通信できる状態になります。

    Catalyst Center とそれらのシスコデバイスの間に HTTP プロキシゲートウェイが存在する場合は、Catalyst Center にプロキシゲートウェイの証明書をインポートする必要があることに注意してください。


    (注)  


    trustpool 内の一部の証明書の期限切れ、再発行、またはその他の理由で、trustpool バンドルの新しいバージョンへの更新が必要になる場合があります。trustpool バンドルの更新が必要な場合は、Catalyst Center の GUI を使用して更新します。Catalyst Center は Cisco Cloud(シスコ認定の trustpool バンドルが含まれている)にアクセスして最新の trustpool バンドルをダウンロードできます。ダウンロード後に、Catalyst Center は、現在のまたは古い trustpool バンドルファイルを上書きします。ベストプラクティスとして、CA から新しい証明書をインポートする前に trustpool バンドルを更新することをお勧めします。


PnP 証明書の要件のチェック

このセクションでは、ゼロタッチ展開で Cisco IOS および Cisco IOS XE デバイスの PnP エージェントの証明書を確認する方法について説明します。

Catalyst Center(PnP サーバーとして実行される)から提供される証明書には、サーバーアイデンティティを確認するための有効なサブジェクト代替名(SAN)フィールドが含まれている必要があります。

このチェックは、PnP プロファイルの設定で使用されるサーバーの DNS 名または IP アドレスに適用されます。

pnp profile SOME_NAME
transport https ipv4 IP_ADDRESS port 443

pnp profile SOME_NAME
transport https host DNS_NAME port 443

強制は、証明書の SAN フィールドをデバイスで設定されている PnP プロファイルで使用される値と比較することによって適用されます。

次の表に、適用される措置の概要を示します。

PnP プロファイルの設定 証明書の要件

DHCP オプション 43 またはオプション 17 による明示的な IPv4 または IPv6 アドレスを使用した PnP サーバーの検出。

サーバー証明書の SAN フィールドにオプション 43 またはオプション 17 で使用される明示的な IPv4 または IPv6 アドレスが含まれている必要があります。

DHCP オプション 43 またはオプション 17 による DNS 名を使用した PnP サーバーの検出。

サーバー証明書の SAN フィールドに特定の DNS 名が含まれている必要があります。

DNS による PnP サーバーの検出。

サーバー証明書の SAN フィールドに pnpserver.<local-domain> が含まれている必要があります。

Cisco.com による PnP サーバーの検出。

次のいずれかの条件が適用されます。
  • クラウド リダイレクション プロファイル設定で IP アドレスが使用されている場合、サーバー証明書の SAN フィールドに明示的な IP アドレスが含まれている必要があります。

  • クラウド リダイレクション プロファイル設定で DNS 名が使用されている場合、サーバー証明書の SAN フィールドに特定の DNS 名が含まれている必要があります。

Day-2(手動設定)の PnP プロファイル作成。

サーバー証明書の SAN フィールドに PnP プロファイル設定で使用される IP アドレスまたは DNS 名が含まれている必要があります。

IP アドレスに変更があっても機能に影響しないため、DNS 名に基づく検出方法を使用することを推奨します。

手順


ステップ 1

PnP サービスログを使用して問題を診断します。デバイスへのトラストポイントのインストール後、デバイスとの HTTPS 接続が確立されているかどうかを確認します。

PnP サービスログに、デバイスが CERTIFICATE_INSTALL_REQUESTED ステージから FILESYSTEM_INFO_REQUESTED ステージに移行し、それ以上は進まないことが示されています。次に例を示します。

2018-11-28 12:05:40,711 |   INFO | qtp226594800-88458        |  | com.cisco.enc.pnp.state.ZtdState | 
Device state has changed from CERTIFICATE_INSTALL_REQUESTED to FILESYSTEM_INFO_REQUESTED | 
sn=SOME_SN, address=SOME_IP

その後、PnP プロビジョニングが次の例のようなエラーで失敗します。

2018-11-28 12:25:56,289 |  ERROR | eHealthCheckFirstBucket-2 |  | c.c.e.z.impl.ZtdHistoryServiceImpl | 
Failed health check since device is stuck in non-terminal state FILESYSTEM_INFO_REQUESTED for more than threshold time: 
0 hours, 16 minutes, 0 seconds | sn=SOME_SN

ステップ 2

デバイス側のデバッグで、次の推奨出力を使用して、問題がサーバー ID の確認に関連しているかどうかを特定します。

debug crypto pki val
debug crypto pki api
debug crypto pki call
debug crypto pki tr
debug ssl openssl error
debug ssl openssl msg
debug ssl openssl state
debug ssl openssl ext

show crypto pki certificate
show running
show pnp tech

ステップ 3

デバッグを有効にしてから PnP の検出を開始します。

ステップ 4

Linux ワークステーションまたは Mac 端末の CLI から次のコマンドを入力して、サーバー証明書の SAN フィールドを確認します。SERVER_IPCatalyst Center クラスタアドレスに置き換えてください。

echo | openssl s_client -showcerts -servername SERVER_IP -connect 
SERVER_IP:443 2>/dev/null | openssl x509 -inform pem -noout -text

ステップ 5

出力の X509v3 extensions にある X509v3 Subject Alternative Name を確認します。このフィールドを Catalyst Center(PnP サーバーとして実行されている)の詳細と照合する必要があります。

出力は次の例のようになります。

[username@toolkit ~]$ echo | openssl s_client -showcerts -servername SERVER_IP -connect 
SERVER_IP:443 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:92:63:49:41:36:99:43:00:57:43:86:06:10:44:57:32:48:65:00
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=e328c7fc-3495-4bc1-81a4-66a31d0507f6, C=US, ST=California, L=SanJose, OU=server-cert, O=Cisco
        Validity
            Not Before: Aug 24 05:55:29 2017 GMT
            Not After : Aug 23 05:55:29 2022 GMT
        Subject: CN=SERVER_IP, ST=California, C=US, O=Cisco, OU=server-cert
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a2:21:ba:52:b4:9e:50:02:c0:68:2e:b3:43:0a:
                    <snip>
                    9e:1b:ef:19:96:f9:2b:e3:6a:58:05:b3:c5:b3:d3:
                    24:ab
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                IP Address:SERVER_IP

ステップ 6

使用している証明書のタイプに応じて、次のいずれかのタスクを実行します。


Catalyst Center とピア接続するシステムの証明書

Catalyst Center が通信する外部システム(Cisco ISE、IPAM、Stealthwatch セキュリティ分析 など)の証明書を設定する際は、システムの証明書用に HTTP タイプの CRL 配布ポイントがサポートされ、LDAP の前に配置されている(LDAP の配布ポイントが複数ある場合)ことを確認してください。

CRL 配布ポイントを LDAP の前に配置しないと、LDAP タイプの CRL エントリについての外部システムによる認証が失敗する可能性があります。

SFTP 互換モードの有効化または無効化

SSH ファイル転送プロトコル(SFTP)互換モードを使用すると、レガシー ネットワーク デバイスは、安全ではない古い暗号スイートを使用して Catalyst Center に接続できます。デフォルトで、SFTP 互換モードは新しい Catalyst Center 展開で有効になっています。

  • ネットワークにレガシーデバイスがない場合は、クラスタの初期設定時に SFTP 互換モードを無効にすることを推奨します。

  • ネットワークにレガシーデバイスがある場合は、SFTP 互換モードを最大 3 日間有効にすることを推奨します。この期間で、プロビジョニングタスクを完了するのに十分な時間が得られます。


重要


次のアルゴリズムは、バージョン 2.3.7.6 以降を実行している Catalyst Center アプライアンスのポート 22 で SFTP 互換モードが有効になっている場合に有効になります。

  • キー交換(KEX)アルゴリズム:diffie-hellman-group1-sha1、diffie-hellman-group-exchange-sha1、diffie-hellman-group14-sha1

  • SSH サーバー ホスト キー アルゴリズム:ssh-dss

  • 暗号化アルゴリズム:aes128-cbc、aes192-cbc、aes256-cbc

  • メッセージ認証コード(MAC)アルゴリズム:hmac-sha2-256-etm、hmac-sha2-512-etm、hmac-sha1-etm、hmac-sha1、hmac-sha1-96


SFTP 互換モードを有効または無効にするには、次の手順を実行します。

手順


ステップ 1

メインメニューから次を選択します。[System] > [Settings] > [Device Settings] > [Image Distribution Servers]

ステップ 2

[Host] 列で、関連するサーバーを見つけ、対応する [i] アイコンをクリックします。

当該サーバーで SFTP 互換モードが現在有効か無効かを示すメッセージが表示されます。

ステップ 3

必要に応じて、メッセージに記載されているリンクをクリックして、このモードを有効または無効にします。


ブラウザベースのアプライアンス設定ウィザード

Catalyst Center の最初のリリースで提供されたアプライアンス設定ウィザードに加えて、ブラウザベースのアプライアンス設定ウィザードも提供されています。このウィザードを無効化または再有効化する方法については、以降のトピックを参照してください。

ウィザードの無効化

Catalyst Center アプライアンスには自己署名証明書が付属しています。実稼働環境で自己署名証明書の使用が許容されない場合は、ブラウザベースのアプライアンス設定ウィザードに関連するサービスをシャットダウンすることを推奨します。ウィザードを使用してアプライアンスの設定を開始した直後に、次の手順を実行します。


(注)  


この手順はルート権限を持つユーザーのみが実行できます。


手順


ステップ 1

SSH クライアントで、設定時に入力した IP アドレスを使用して Catalyst Center アプライアンスにログインします。

入力画面が表示されたら、ユーザー名とパスワードを入力します。

ステップ 2

(任意) ブラウザベースのアプライアンス設定ウィザードを無効化または再有効化するために実行する必要があるコマンドの使用方法に関する情報を表示するには、maglev-config webinstall コマンドを実行します。

この出力が表示されます。

Usage: maglev-config webinstall [OPTIONS] COMMAND [ARGS]...
Enable/Disable Maglev web install feature
Options:
--help  Show this message and exit.
Commands:
disable  Stops and disables Maglev webinstall service...
enable   Enables Maglev webinstall feature service

ステップ 3

maglev-config webinstall disable コマンドを実行して、ブラウザベースの設定ウィザードを無効にします。

操作が終了すると、次のメッセージが表示されます。

Maglev Web install feature disabled

ウィザードの再有効化

このタスクを実行する際、ブラウザベースの設定ウィザードがアプライアンスで現在無効になっている場合は再度有効にしてから実行します。

  • 高可用性(HA)を有効にする予定の 3 ノード Catalyst Center クラスタにノードを追加する。

  • HA が有効になっている 3 ノードクラスタからノードを削除して新しいノードと交換する。この場合は、他の 2 つのクラスタノードの少なくとも 1 つでブラウザベースの設定ウィザードが有効になっていることを確認してください。


(注)  


この手順はルート権限を持つユーザーのみが実行できます。


手順


ステップ 1

SSH クライアントで、設定時に入力した IP アドレスを使用して Catalyst Center アプライアンスにログインします。

入力画面が表示されたら、ユーザー名とパスワードを入力します。

ステップ 2

maglev-config webinstall enable コマンドを実行して、ウィザードを再度有効にします。

操作が終了すると、次のメッセージが表示されます。

Maglev Web install feature enabled

レガシーデバイスのアップグレード

レガシー ネットワーク デバイスがある場合は、最新のデバイスソフトウェアにアップグレードする必要があります。

Cisco Aironet 1800 シリーズ アクセス ポイント バージョン 8.5 などの一部のデバイスでは TLSV1 を使用しており、セキュアではありません。TLS のバージョンをアップグレードするには、デバイスのソフトウェアバージョンを 8.8 にアップグレードする必要があります。

ネットワークデータの保護

Catalyst Center では、データ匿名化機能を使用して、有線および無線のエンドクライアントのアイデンティティを Cisco Catalyst Assurance ダッシュボードに表示されないようにすることができます。詳細については、『Cisco Catalyst Assurance User Guide』の「View or Update Collector Configuration Information」を参照してください。

Syslog 管理

Catalyst Center では、ユーザー名、パスワード、IP アドレスなど、ユーザーの機密データの syslog が保護されます。

監査ログの表示

監査ログは、Catalyst Centerで実行されているさまざまなアプリケーションに関する情報を取得します。さらに、監査ログは、デバイス Public Key Infrastructure(PKI)通知についての情報も取得します。これらの監査ログの情報は、アプリケーションまたはデバイス CA 証明書に関連する問題(ある場合)のトラブルシューティングを支援するために使用できます。

監査ログは、発生したシステムイベント、発生した場所、開始したユーザーを記録するシステムでもあります。監査ログを使用すると、監査用の別のログ ファイルにシステムの設定変更が記録されます。

手順


ステップ 1

メインメニューから次を選択します。[Activities] > [Audit Logs] の順に選択します。

[Audit Logs] ウィンドウが開きます。このウィンドウで、ネットワーク内の現在のポリシーに関するログを表示できます。これらのポリシーは、Catalyst Center にインストールされているアプリケーションによってネットワークデバイスに適用されます。

ステップ 2

タイムラインスライダをクリックして、ウィンドウに表示するデータの時間範囲を次のとおり指定します。

  1. [Time Range] 領域で、[Last 2 Weeks]、[Last 7 Days]、[Last 24 Hours]、または [Last 3 Hours] の時間範囲を選択します。

  2. カスタム範囲を指定するには、[By date] をクリックし、開始日時と終了日時を指定します。

  3. [Apply] をクリックします。

ステップ 3

対応する子監査ログを表示するには、監査ログの横にある矢印をクリックします。

各監査ログは、いくつかの子監査ログの親になることができます。矢印をクリックすると、一連の追加の子監査ログを表示できます。

(注)  

 

監査ログは、Catalyst Center によって実行されたタスクに関するデータをキャプチャします。子監査ログは、Catalyst Center によって実行されたタスクのサブタスクです。

ステップ 4

(任意)左側のペインに表示された監査ログのリストで特定の監査ログメッセージをクリックします。右側のペインで[Event ID] > [Copy Event ID to Clipboard]をクリックします。コピーされた ID を API で使用すると、イベント ID に基づく監査ログメッセージを取得できます。

監査ログの右側のペインに各ポリシーの [Description][User][Interface][Destination] が表示されます。

(注)  

 

監査ログには、ペイロード情報を含む POST、DELETE、PUT などのノースバウンド操作の詳細と、デバイスにプッシュされた設定などのサウスバウンド操作の詳細が表示されます。Cisco DevNet の API の詳細については、『Catalyst Center Platform Intent APIs』[英語] を参照してください。

ステップ 5

(任意)[Filter] をクリックして、[User ID]、[Log ID]、または [Description] でログをフィルタリングします。

ステップ 6

鉛筆アイコンをクリックして監査ログイベントを登録します。

syslog サーバーのリストが表示されます。

ステップ 7

接続する syslog サーバーのチェックボックスをオンにし、[Save] をクリックします。

(注)  

 

監査ログイベントの登録を解除するには、syslog サーバーのチェックボックスをオフにして [Save] をクリックします。

ステップ 8

右側のペインで、[Search] フィールドを使用して、ログメッセージ内の特定のテキストを検索します。

ステップ 9

メインメニューから次を選択します。[Activities] > [Tasks] で、OS の更新やデバイスの交換などの予定、進行中、完了および失敗したタスクと、既存、レビュー保留、および失敗した操作項目を確認します。


Syslog サーバーへの監査ログのエクスポート

セキュリティに関する推奨事項:より安全で簡単なログモニタリングのために、監査ログを Catalyst Center からネットワーク内のリモート syslog サーバーにエクスポートすることを推奨します。

複数の syslog サーバーに接続することで、監査ログを Catalyst Center から複数の syslog サーバーにエクスポートできます。

始める前に

[System] > [Settings] > [External Services] > [Destinations] > [Syslog] 領域で syslog サーバーを設定します。

手順


ステップ 1

メインメニューから次を選択します。[Activities] > [Audit Logs] の順に選択します。

ステップ 2

ウィンドウの上部にある鉛筆アイコンをクリックします。

ステップ 3

接続する syslog サーバーを選択し、[Save] をクリックします。

ステップ 4

(任意) syslog サーバーから切断するには、選択を解除して [Save] をクリックします。


API を使用した Syslog サーバーでの監査ログの表示

Catalyst Center プラットフォーム では、API を使用して Syslog サーバーの監査ログを表示できます。[Developer Toolkit] の [Create Syslog Event Subscription] API を使用して、監査ログイベントの syslog サブスクリプションを作成できます。

監査ログイベントが発生するたびに、Syslog サーバーで監査ログイベントがリストされます。

セキュリティ アドバイザリ レポートの表示

Catalyst Center には、セキュリティ アドバイザリ レポートを作成する機能が用意されています。関連するセキュリティアドバイザリについてシスコのネットワークデバイスがスキャンされ、公開されている脆弱性に関する情報が提供されます。

セキュリティに関する推奨事項:このレポートを定期的に確認および実行して、公開されているシスコ セキュリティ アドバイザリでネットワークに影響があるものがないかどうかを確認することを強くお勧めします。必要に応じて、適切な措置を講じることができます。

セキュリティ アドバイザリ レポートには、デバイスデータに加え、デバイス名、IP アドレス、デバイスタイプ、シリアル番号、イメージバージョン、サイト、アドバイザリ ID、CVSS スコア、影響などの関連するアドバイザリデータが表示されます。


(注)  


  • デバイスとアドバイザリは 1 対多の関係になることもあるため、レポートの各行にデバイスとアドバイザリの一意の組み合わせが示されます。

  • スキャンされなかったデバイスもレポートに含まれ、未スキャンのラベルが付けられます。

  • スキャンされてアドバイザリが見つからなかったデバイスについては、アドバイザリなしのラベルが付けられます。

セキュリティ アドバイザリ レポートの実行方法については、『Cisco Catalyst Center Platform User Guide』の「Run a Security Advisories Report」[英語] のセクションを参照してください。