セキュリティ強化の概要
Catalyst Center は、シスコ ネットワーク プラットフォーム向けの非常に高度で機能豊富なエンタープライズ コントローラです。Catalyst Center は企業ネットワークの最も重要なインフラストラクチャ コンポーネントの 1 つであるため、安全に展開してください。
このガイドでは、セキュアな展開を確保するためのベストプラクティスについて説明します。ネットワーク インフラストラクチャの Catalyst Center について、マルチレイヤセキュリティに関する考慮事項を慎重に評価してください。このガイドで推奨されているアクションを実行し、潜在的なセキュリティリスクを軽減します。
![]() (注) |
|
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 Center と Cisco ISE はローカルデータセンター(キャンパスのヘッド)またはリモートデータセンターのいずれかのファイアウォールの背後に配置します。

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

通信ポート
表に、Catalyst Center が使用するポート、それらのポート上で通信するサービスの名前、およびポート使用における製品の目的を示します。「推奨処置」列は、ネットワークトラフィックを既知の IP アドレスまたは範囲に制限できるかどうか、Catalyst Center のポートやサービスとの間のネットワーク接続を Catalyst Center の機能に影響を与えることなくブロックできるかどうか、ポートを開いておく必要があるかどうかを示します。
![]() (注) |
インターネット宛トラフィックをルーティングするように設定されているアプライアンス インターフェイスは、すべての通信の送信元として機能します。 |
Catalyst Center の宛先ポートは一部重複しています。サブセクションに用途と関連するネットワークサービスを示してあります。ファイアウォールルールで送信元や宛先の IP アドレスまたは範囲を制限できるほか、Catalyst Center の展開で使用していないサービスについてはポートを開かないようにすることができます。
![]() 重要 |
3 ノードクラスタの場合は、各ノードの送信元エンタープライズ IP アドレスが許可されていることを確認します。 |
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 に対する発信トラフィックを許可するようにネットワークを設定します。 |
||
TCP 80 |
OCSP/CRL |
Catalyst Center は、OCSP/CRL を使用した SSL/TLS 証明書の失効ステータスを確認します。 |
上記の URL は、直接でも Catalyst Center で構成されているプロキシサーバー経由でも到達できるようにする必要があります。そうしないと、 Catalyst Center が cisco.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 Center は Cisco ISE XMP(PxGrid 用)を使用します。 |
Cisco ISE 用にポートを開いておく必要があります。 |
||
TCP 9060 |
Cisco ISE |
Catalyst Center は Cisco 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 インテリジェントキャプチャ機能を使用する任意のアクセスポイント)を使用します。
|
これらのポートでアクセス権限が付与されたホストまたはネットワークデバイスの送信元 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 例外リスト
エリア | 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」のトピックを参照してください。
![]() (注) |
|
ディザスタリカバリに 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
![]() (注) |
ディザスタリカバリポート
実稼働環境でディザスタリカバリを使用している場合は、ディザスタリカバリの設定を保護するファイアウォールとセキュリティポリシーを使用します。表に示されているポートを開き、ネットワークのデータセンター全体でディザスタリカバリを設定するために必要なアクセス権が 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 セッション
|
||
任意(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 |
必要なインターネット 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 |
特定の送信元からの着信トラフィックを制限するには、次のコマンドを入力します。
|
||
ステップ 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 バージョンを確認します。 次に例を示します。
|
||
ステップ 4 |
クラスタの TLS バージョンを変更する場合は、次のコマンドを入力します。たとえば、Catalyst Center 制御下のネットワークデバイスが既存の TLS バージョンをサポートできない場合は、現在の TLS バージョンを以前のバージョンに変更できます。 次の例は、TLS バージョン 1.1 から 1.0 に変更する方法を示しています。
次の例は、TLS バージョン 1.1 から 1.2 に変更(RC4-SHA を有効にしていない場合のみ可能)する方法を示しています。
|
||
ステップ 5 |
Catalyst Center と Catalyst 9000 デバイス間のストリーミングテレメトリ接続(TCP 25103 ポート経由)用の TLS バージョンを変更する場合は、次のコマンドを入力します。たとえば、Catalyst Center 管理下のネットワークデバイスが TLS バージョン 1.2 をサポートできる場合は、現在の TLS バージョンを変更できます。 次の例は、TLS バージョン 1.1 から 1.2 に変更する方法を示しています。
|
||
ステップ 6 |
クラスタで RC4-SHA を有効にするには、次のコマンドを入力します(セキュアでないため、必要な場合だけにしてください)。 TLS バージョン 1.2 が最小バージョンである場合、RC4-SHA 暗号を有効にすることはサポートされていません。 次の例は、TLS バージョン 1.2 が有効になっていないことを示しています。
|
||
ステップ 7 |
プロンプトで次のコマンドを入力して、TLS および RC4-SHA が設定されていることを確認します。 次に例を示します。
|
||
ステップ 8 |
以前に有効にした RC4-SHA 暗号を無効にするには、クラスタで次のコマンドを入力します。
|
||
ステップ 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 要求を送信します。
|
||
ステップ 2 |
Catalyst Center は CRL をチェックします。証明書に CRL Distribute Points フィールドがあり、そのフィールドに有効な CRL URI または URL のエントリが少なくとも 1 つ記載されていれば、Catalyst Center はその URI または URL から CRL をダウンロードし、ダウンロードした CRL と照合して証明書を検証します。
|
クレデンシャルとパスワードの管理
クラスタのパスワード
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 ユーザーのパスワードを変更するには、次の手順を実行します。 |
||
ステップ 2 |
GUI ユーザーパスワードを変更するには、次の手順を実行します。
|
証明書を管理する
デフォルトの証明書
セキュリティに関する推奨事項:Catalyst Center のデフォルトの Transport Layer Security 証明書を内部認証局の署名付き証明書に置き換えることを推奨します。
デフォルトでは、Catalyst Center は自己署名証明書を使用します。Catalyst Center によるデバイスの管理には、それ以外に展開されていなければ、デバイスの自己署名証明書が使用されます。展開時には内部認証局の署名付き証明書を使用することを強く推奨します。
![]() (注) |
|
証明書および秘密キーのサポート
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 サーバー証明書を更新するには、次の手順を実行します。
-
証明書署名要求(CSR)を生成します。
-
CSR を CA に送信して、署名付き証明書を取得します。
-
署名付き証明書とそのチェーンを Catalyst Center にインポートします。
この手順では、CA の例として Microsoft Active Directory 証明書サービスを使用します。別の CA を使用する場合は、それに応じて手順を調整してください。
![]() (注) |
Catalyst Center のサーバー証明書と秘密キーを更新する必要がある場合は、この手順を実行することをお勧めします。CLI ベースの手順で実行するには、『Catalyst Center セキュリティのベストプラクティスガイド』の「OpenSSL を使用した証明書要求の生成」のトピックを参照してください。 |
始める前に
秘密キーに対応する有効な X.509 証明書を内部 CA から取得する必要があります。
手順
ステップ 1 |
メインメニューから次を選択します。 の順に選択します。 このウィンドウには、Catalyst Center のサーバー証明書に関する情報が表示され、これらの証明書を管理するためのアクションが提供されます。[System Certificates] の表には、証明書ごとに次の情報が表示されます。
|
|||||||||||||||||||||||
ステップ 2 |
[+ New Certificate Request (CSR)] をクリックします。 CSR を初めて生成するときは、この [+ New Certificate Request (CSR)] リンクが有効になります。 既存の CSR を使用しない場合は、既存の要求を削除してください。
|
|||||||||||||||||||||||
ステップ 3 |
[New Certificate Request (CSR)] スライドインペインで、CSR を作成します。
|
|||||||||||||||||||||||
ステップ 4 |
[Certificate Signing Request] スライドインペインで、CSR のコピーをダウンロードします。
![]() |
|||||||||||||||||||||||
ステップ 5 |
証明書要求を CA に送信し、CA から発行元 CA チェーンをダウンロードします。 たとえば、Microsoft Active Directory 証明書サービスを使用して証明書要求を送信するには、次の手順を実行します。
|
|||||||||||||||||||||||
ステップ 6 |
証明書発行元から p7b で証明書の完全なチェーン(サーバーおよび CA)が提供されたことを確認します。不明な場合は、次の手順を実行し、チェーンを確認して組み立てます。 |
|||||||||||||||||||||||
ステップ 7 |
Catalyst Center GUI の [+ System Certificates] ウィンドウで、[+ Import Certificate] をクリックします。 |
|||||||||||||||||||||||
ステップ 8 |
[Import Certificate] スライドインペインで、その証明書署名付き認証局チェーンが連結された署名付き証明書を Catalyst Center にインポートします。
|
|||||||||||||||||||||||
ステップ 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)が設定されていることを確認します。このコマンドを実行するにはルート権限が必要です。
cluster_hostname 出力フィールドが空であるか目的のものと異なる場合は、以下の例に示すように、sudo maglev-config update コマンドを入力して Catalyst Center のホスト名(FQDN)を追加または変更します。このコマンドを実行するにはルート権限が必要です。
入力プロンプト [Cluster's hostname] を含む [MAGLEV CLUSTER DETAILS] という手順が表示されるまで、[Next] をクリックします。ホスト名を目的の Catalyst Center の FQDN に設定します。Catalyst Center が新しい FQDN で再設定されるまで [Next] と [Proceed] をクリックします。 |
ステップ 2 |
テキストエディタを使用して、openssl.cnf という名前の構成ファイルを作成します。
|
ステップ 3 |
次のコマンドを入力して秘密キーを作成します。認証局管理チームから求められた場合は、キーの長さを 2048 に調整します。
|
ステップ 4 |
openssl.cnf ファイルのフィールドの読み込みが完了したら、前の手順で作成した秘密キーを使用して証明書署名要求を生成します。
|
ステップ 5 |
証明書署名要求の内容を確認し、DNS 名が [subjectAltName] フィールドに正しく入力されていることを確認します。
|
ステップ 6 |
証明書署名要求をコピーし、CA(MS CA など)に貼り付けます。 ![]() 選択した証明書テンプレートがクライアント認証とサーバー認証の両方に設定されていることを確認します(手順 2 の openssl.cnf ファイルの例に示した extendedKeyUsage の行を参照)。 |
ステップ 7 |
発行された証明書とその発行元 CA チェーンの収集に進みます。 |
ステップ 8 |
証明書発行元から p7b で証明書の完全なチェーン(サーバーおよび CA)が提供された場合は、次の手順を実行します。 |
ステップ 9 |
証明書発行元からルーズファイルで証明書とその発行元 CA チェーンが提供された場合は、次の手順を実行します。 |
ステップ 10 |
csr.key および server-cert-chain.pem ファイルを Catalyst Center にインポートします。 |
証明書の設定に関する考慮事項
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_bits と default_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 |
メインメニューから次を選択します。 の順に選択します。 |
ステップ 2 |
[CA Management] タブをクリックします。 |
ステップ 3 |
GUI で既存のルートまたは下位 CA 証明書の設定情報を確認します。
|
ステップ 4 |
[CA Management] タブで、[Enable SubCA Mode] ボタンをクリックします。 |
ステップ 5 |
表示される警告内容を確認します。 次に例を示します。
|
ステップ 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 で確認し、次のアクションのいずれかを実行します。
|
ステップ 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] タブのフィールドを確認します。
|
ロールオーバー下位 CA 証明書のプロビジョニング
Catalyst Center では、既存の下位 CA の有効期間が 70% 以上経過している場合に、ユーザーがロールオーバー下位 CA として下位証明書を適用することができます。
始める前に
-
下位 CA ロールオーバー プロビジョニングを開始するには、認証局のロールを下位 CA モードに変更しておく必要があります。認証局のロールをルートから下位に変更を参照してください。
-
現在の下位 CA 証明書の有効期限が 70 % 以上経過していることが必要です。この状態になると、Catalyst Center の [CA Management] タブの下に [Renew] ボタンが表示されます。
-
ロールオーバー下位 CA の署名付き証明書のコピーが必要です。
手順
ステップ 1 |
メインメニューから次を選択します。 の順に選択します。 |
ステップ 2 |
[CA Management] タブで、CA 証明書の設定情報を確認します。
|
ステップ 3 |
[Renew] をクリックします。 Catalyst Center は既存の下位 CA を使用して、ロールオーバー下位 CA の証明書署名要求を生成し、表示します。 |
ステップ 4 |
生成された証明書署名要求を GUI で確認し、次のアクションのいずれかを実行します。
|
ステップ 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 |
メインメニューから次を選択します。 の順に選択します。 |
ステップ 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 の管理機能は次のように動作します。
-
PnP 機能をサポートするネットワーク内のシスコデバイスをブートします。
すべてのシスコデバイスが PnP をサポートするわけではありません。サポート対象のシスコデバイスの一覧については、「Cisco Catalyst Center Compatibility Matrix」[英語] を参照してください。
-
PnP の最初のフローの一部として、サポート対象のシスコデバイスは、HTTP を使用して trustpool バンドルを Catalyst Center から直接ダウンロードします。
-
シスコデバイスは、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 サーバーの検出。 |
次のいずれかの条件が適用されます。
|
Day-2(手動設定)の PnP プロファイル作成。 |
サーバー証明書の SAN フィールドに PnP プロファイル設定で使用される IP アドレスまたは DNS 名が含まれている必要があります。 |
IP アドレスに変更があっても機能に影響しないため、DNS 名に基づく検出方法を使用することを推奨します。
手順
ステップ 1 |
PnP サービスログを使用して問題を診断します。デバイスへのトラストポイントのインストール後、デバイスとの HTTPS 接続が確立されているかどうかを確認します。 PnP サービスログに、デバイスが CERTIFICATE_INSTALL_REQUESTED ステージから FILESYSTEM_INFO_REQUESTED ステージに移行し、それ以上は進まないことが示されています。次に例を示します。
その後、PnP プロビジョニングが次の例のようなエラーで失敗します。
|
ステップ 2 |
デバイス側のデバッグで、次の推奨出力を使用して、問題がサーバー ID の確認に関連しているかどうかを特定します。
|
ステップ 3 |
デバッグを有効にしてから PnP の検出を開始します。 |
ステップ 4 |
Linux ワークステーションまたは Mac 端末の CLI から次のコマンドを入力して、サーバー証明書の SAN フィールドを確認します。SERVER_IP を Catalyst Center クラスタアドレスに置き換えてください。
|
ステップ 5 |
出力の X509v3 extensions にある X509v3 Subject Alternative Name を確認します。このフィールドを Catalyst Center(PnP サーバーとして実行されている)の詳細と照合する必要があります。 出力は次の例のようになります。
|
ステップ 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 互換モードが有効になっている場合に有効になります。
|
SFTP 互換モードを有効または無効にするには、次の手順を実行します。
手順
ステップ 1 |
メインメニューから次を選択します。 。 |
ステップ 2 |
[Host] 列で、関連するサーバーを見つけ、対応する [i] アイコンをクリックします。 当該サーバーで SFTP 互換モードが現在有効か無効かを示すメッセージが表示されます。 |
ステップ 3 |
必要に応じて、メッセージに記載されているリンクをクリックして、このモードを有効または無効にします。 |
ブラウザベースのアプライアンス設定ウィザード
Catalyst Center の最初のリリースで提供されたアプライアンス設定ウィザードに加えて、ブラウザベースのアプライアンス設定ウィザードも提供されています。このウィザードを無効化または再有効化する方法については、以降のトピックを参照してください。
ウィザードの無効化
Catalyst Center アプライアンスには自己署名証明書が付属しています。実稼働環境で自己署名証明書の使用が許容されない場合は、ブラウザベースのアプライアンス設定ウィザードに関連するサービスをシャットダウンすることを推奨します。ウィザードを使用してアプライアンスの設定を開始した直後に、次の手順を実行します。
![]() (注) |
この手順はルート権限を持つユーザーのみが実行できます。 |
手順
ステップ 1 |
SSH クライアントで、設定時に入力した IP アドレスを使用して Catalyst Center アプライアンスにログインします。 入力画面が表示されたら、ユーザー名とパスワードを入力します。 |
ステップ 2 |
(任意) ブラウザベースのアプライアンス設定ウィザードを無効化または再有効化するために実行する必要があるコマンドの使用方法に関する情報を表示するには、maglev-config webinstall コマンドを実行します。 この出力が表示されます。
|
ステップ 3 |
maglev-config webinstall disable コマンドを実行して、ブラウザベースの設定ウィザードを無効にします。 操作が終了すると、次のメッセージが表示されます。
|
ウィザードの再有効化
このタスクを実行する際、ブラウザベースの設定ウィザードがアプライアンスで現在無効になっている場合は再度有効にしてから実行します。
-
高可用性(HA)を有効にする予定の 3 ノード Catalyst Center クラスタにノードを追加する。
-
HA が有効になっている 3 ノードクラスタからノードを削除して新しいノードと交換する。この場合は、他の 2 つのクラスタノードの少なくとも 1 つでブラウザベースの設定ウィザードが有効になっていることを確認してください。
![]() (注) |
この手順はルート権限を持つユーザーのみが実行できます。 |
手順
ステップ 1 |
SSH クライアントで、設定時に入力した IP アドレスを使用して Catalyst Center アプライアンスにログインします。 入力画面が表示されたら、ユーザー名とパスワードを入力します。 |
ステップ 2 |
maglev-config webinstall enable コマンドを実行して、ウィザードを再度有効にします。 操作が終了すると、次のメッセージが表示されます。
|
レガシーデバイスのアップグレード
レガシー ネットワーク デバイスがある場合は、最新のデバイスソフトウェアにアップグレードする必要があります。
-
Cisco SD-Access でサポートされるソフトウェアバージョンについては、「Cisco SD-Access Compatibility Matrix」[英語] を参照してください。
-
Catalyst Center の一般的なデバイスサポート情報を表示するには、「Cisco Catalyst Center Compatibility Matrix」[英語] を参照してください。
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 |
メインメニューから次を選択します。 の順に選択します。 [Audit Logs] ウィンドウが開きます。このウィンドウで、ネットワーク内の現在のポリシーに関するログを表示できます。これらのポリシーは、Catalyst Center にインストールされているアプリケーションによってネットワークデバイスに適用されます。 |
||
ステップ 2 |
タイムラインスライダをクリックして、ウィンドウに表示するデータの時間範囲を次のとおり指定します。
|
||
ステップ 3 |
対応する子監査ログを表示するには、監査ログの横にある矢印をクリックします。 各監査ログは、いくつかの子監査ログの親になることができます。矢印をクリックすると、一連の追加の子監査ログを表示できます。
|
||
ステップ 4 |
(任意)左側のペインに表示された監査ログのリストで特定の監査ログメッセージをクリックします。右側のペインで をクリックします。コピーされた ID を API で使用すると、イベント ID に基づく監査ログメッセージを取得できます。監査ログの右側のペインに各ポリシーの [Description]、[User]、[Interface]、[Destination] が表示されます。
|
||
ステップ 5 |
(任意)[Filter] をクリックして、[User ID]、[Log ID]、または [Description] でログをフィルタリングします。 |
||
ステップ 6 |
鉛筆アイコンをクリックして監査ログイベントを登録します。 syslog サーバーのリストが表示されます。 |
||
ステップ 7 |
接続する syslog サーバーのチェックボックスをオンにし、[Save] をクリックします。
|
||
ステップ 8 |
右側のペインで、[Search] フィールドを使用して、ログメッセージ内の特定のテキストを検索します。 |
||
ステップ 9 |
メインメニューから次を選択します。 で、OS の更新やデバイスの交換などの予定、進行中、完了および失敗したタスクと、既存、レビュー保留、および失敗した操作項目を確認します。 |
Syslog サーバーへの監査ログのエクスポート
セキュリティに関する推奨事項:より安全で簡単なログモニタリングのために、監査ログを Catalyst Center からネットワーク内のリモート syslog サーバーにエクスポートすることを推奨します。
複数の syslog サーバーに接続することで、監査ログを Catalyst Center から複数の syslog サーバーにエクスポートできます。
始める前に
領域で syslog サーバーを設定します。
手順
ステップ 1 |
メインメニューから次を選択します。 の順に選択します。 |
ステップ 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 スコア、影響などの関連するアドバイザリデータが表示されます。
![]() (注) |
セキュリティ アドバイザリ レポートの実行方法については、『Cisco Catalyst Center Platform User Guide』の「Run a Security Advisories Report」[英語] のセクションを参照してください。 |