この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco APIC-EMでは基本機能をサポートするためにマルチレイヤ アーキテクチャが必要です。マルチレイヤ アーキテクチャは、次のコンポーネントで構成されています。
外部ネットワーク:外部ネットワークは、ネットワークの一方の管理者およびアプリケーションと、もう一方の内部ネットワークまたはクラウド内のGrapevine ルートおよびクライアントの間に存在します。管理者とアプリケーションの両方がこの外部ネットワークを使用して Grapevine ルートとクライアントにアクセスします。
内部ネットワーク:内部ネットワークは Grapevine ルートとクライアントの両方で構成されます。
デバイス管理ネットワーク:このネットワークは、コントローラで管理および監視されるデバイスで構成されています。デバイス管理ネットワークは上記の外部ネットワークと基本的に同じであることに注意してください。これは管理者またはノースバウンド アプリケーションから物理的または論理的にセグメント化される可能性があります。
あらゆるレイヤ間通信およびレイヤ内通信では、暗号化、認証およびセグメント化による保護が必要です。
(注) | 内部ネットワーク内のクライアントで実行されるさまざまなサービスについては、第 3 章「Cisco APIC-EMサービス」を参照してください。 |
外部ネットワークから Cisco APIC-EM へのノースバウンド REST API 要求は TLS(バージョン 1.0、1.1 または 1.2)を使用して安全に行われます。
コントローラが提示する外部 X.509 証明書は、コントローラ自体によって動的に生成され、自己署名されたものであるか、または秘密キーでコントローラにインポートされた(ユーザの X.509 証明書)ものです。コントローラの自己署名 X.509 証明書を使用する方法と、自身の X.509 証明書および秘密キーをインポートして使用する方法があります。デフォルトでは、API 要求に対して提示された自己署名 X.509 証明書が Grapevine の内部認証局(CA)によって署名されます。この自己署名 X.509 証明書は、ホストで認識および承認されない場合があります。API 要求を続行するには、警告を無視し、証明書を信頼して続行する必要があります。
(注) | 自己署名証明書をコントローラで使用したり、コントローラにインポートすることはお勧めしません。既知の認証局(CA)から有効な X.509 証明書をインポートすることをお勧めします。 |
HTTP を使用するいくつかの重要な Grapevine 内通信は、内部公開キー インフラストラクチャ(PKI)を使用して SSL を介して送信されます。すべての内部 Grapevine サービス、データベース サーバと Cisco APIC-EMサービス自体は、これらのサービスのセグメント化と安全を維持するために内部ネットワークでのみリッスンします。
Cisco APIC-EMはデバイスにアクセスして、プログラミングするために、SSH バージョン 2、Telnet、SNMP v2c/v3 を採用しています。
デバイスは HTTP および HTTPS を使用してCisco APIC-EMと通信します。HTTP は機密性の低い通信用にサポートされます。デバイスでサポートされる場合、SSH および SNMP v3c を強く推奨します。SSH バージョン 1 接続はサポートされていません。
(注) | セキュリティのために、デバイス管理ネットワークへのアクセスは外部ネットワークから分離することを強く推奨します。 |
Cisco APIC-EMは公開キー インフラストラクチャ(PKI)を基盤としてセキュアな通信を提供しています。PKI は、認証局、デジタル証明書、公開キーと秘密キーで構成されます。
認証局(CA)は証明書要求を管理して、ホスト、ネットワーク デバイス、ユーザなどの参加エンティティにデジタル証明書を発行します。CA は参加エンティティに対して集中型のキー管理を行います。
公開キー暗号化に基づくデジタル署名は、ホスト、デバイス、個々のユーザをデジタル認証します。RSA 暗号化システムなどの公開キー暗号化では、各エンティティが秘密キーと公開キーの両方を含むキー ペアを持ちます。秘密キーは公開されず、これを所有するホスト、デバイスまたはユーザ以外は知りません。一方、公開キーは誰もが知っているものです。これらのキーの一方で暗号化されたものは、他方のキーで復号化できます。署名は、送信者の秘密キーを使用してデータを暗号化したときに作成されます。受信者は、送信者の公開キーを使用してメッセージを復号化することで、署名を検証します。このプロセスでは、受信者が送信者の公開キーのコピーを取得していて、そのキーが確実に送信者のものであり、送信者を装っている他者のものではないことを確信している必要があります。
デジタル証明書は、デジタル署名と送信者を結び付けるものです。デジタル証明書には、名前、シリアル番号、企業、部署または IP アドレスなど、ユーザまたはデバイスを特定する情報を含んでいます。また、エンティティの公開キーのコピーも含まれています。証明書に署名する CA は、受信者が明示的に信頼する第三者機関であり、アイデンティティの正当性を立証し、デジタル証明書を作成します。
CA の署名を検証するには、受信者は、CA の公開キーを認識している必要があります。一般的にはこのプロセスはアウト オブ バンドか、インストール時に行われる操作によって処理されます。たとえば、通常の Web ブラウザでは、デフォルトで、複数の CA の公開キーが設定されています。
Cisco APIC-EMでは、証明書、キーまたは CA を共有しない 2 つの独立した PKI プレーンを維持します。各 PKI プレーンは接続の特定のセットを保護します。
コントローラの接続
コントローラのサーバ証明書はクライアント側開始のコントローラへの接続(通信)を保護します。
コントローラは、NB REST API を使用してコントローラと通信しているサードパーティ アプリケーションなどの、NB REST API の発信者からの HTTPS 接続要求に応じてサーバ証明書を示します。さらに、ルータ、スイッチ、またはその他のコントロール プレーン デバイスが NB REST API の呼び出しや、ファイル(デバイス イメージ、コンフィギュレーションなど)のダウンロードを目的として、コントローラへの HTTPS 接続を開始するときに、サーバは接続を要求したデバイスに証明書を示します。
REST 発信者に代わってコントローラが実行するアクション(デバイスの検出、タグの管理、ポリシーのデバイスへのプッシュなど)を含む、コントローラによって開始されるデバイス インタラクションでは、現在 HTTPS は使用されていません。
(注) | この導入ガイドのセキュリティ コンテンツと説明では、この特定の PKI プレーンのみを扱います。 |
デバイス間の DMVPN 接続
IWAN 管理対象デバイスは、IWAN QoS ポリシーを実現するためにデバイス間のダイナミック マルチポイント VPN(DMVPN)接続を確立します。Cisco APIC-EMの組み込みプライベート CA は、これらの DMVPN 接続を保護する証明書およびキーをプロビジョニングします。Cisco APIC-EM に組み込まれた PKI ブローカは、IWAN GUI の管理者または pki-broker NB REST API を使用する REST 発信者の指示に従って、これらの証明書とキーを管理します。外部 CA はこれらの証明書とキーを管理できません。
現在、IWAN アプリケーションおよび DMVPN 接続でのみ内部 CA 発行の証明書が使用されます。今後、Cisco APIC-EMの内部 CA から証明書を入手する他のサービスが登場する可能性はあります。
(注) | この導入ガイドでは、IWAN ダイナミック マルチポイント VPN(DMVPN)の接続については説明しません。このトピックについては、該当する Cisco IWAN のドキュメントを参照してください。 |
Cisco APIC-EM に組み込まれた内部 CA は、外部 CA へのサブ/中間 CA にはできません。Cisco APIC-EM でそのサポートが追加されない限り、これら 2 つの PKI プレーン(1 つはコントローラの接続用、もう 1 つはデバイス間の DMVPN 接続用)は互いに完全に独立しています。現在のリリースでは、IWAN デバイスの相互対話の証明書は Cisco APIC-EM に組み込まれた CA でのみ管理されます。外部 CA では、デバイスが DMVPN トンネル作成および関連操作で互いに示す IWAN 固有の証明書を管理できません。
Cisco APIC-EMはセッション(HTTPS)の認証に使用される PKI 証明書管理機能をサポートします。これらのセッションでは、認証局(CA)と呼ばれる一般に認められた信頼されたエージェントを使用します。Cisco APIC-EMは PKI 証明書管理機能を使用して、既知の CA から X.509 証明書をインポートし、保存して管理します。インポートされた証明書はコントローラ自体の ID 証明書になり、コントローラは認証用にクライアントにこの証明書を示します。クライアントは、NB API のアプリケーションやネットワーク デバイスです。
Cisco APIC-EMはコントローラの GUI を使用して次のファイル(PEM または PKCS ファイル形式)をインポートできます。
(注) | 秘密キーに対し、Cisco APIC-EMは RSA キーのインポートをサポートします。DSA、DH、ECDH および ECDSA キー タイプをインポートしないでください。これらはサポートされません。 また、独自のキー管理システムで秘密キーを保護する必要があります。 |
インポート前に、既知の認証局(CA)から有効な X.509 証明書と秘密キーを取得するか、独自の自己署名証明書を作成する必要があります。インポートした後、X.509 証明書および秘密キーに基づいたセキュリティ機能が自動的に有効化されます。Cisco APIC-EMはこの証明書を要求するデバイスやアプリケーションに証明書を提供します。ノースバウンド API アプリケーションおよびネットワーク デバイスのどちらも、コントローラとの信頼関係の確立にこれらのクレデンシャルを使用できます。
IWAN の設定およびネットワーク PnP 機能では、ネットワーク内のデバイス間の信頼性を確保するために、PKI の trustpool を含む追加手順が使用されます。この手順については、次の「Cisco APIC-EMTrustpool サポート」の項を参照してください。
(注) | 自己署名証明書をコントローラで使用したり、コントローラにインポートすることはお勧めしません。既知の認証局(CA)から有効な X.509 証明書をインポートすることをお勧めします。さらに、ネットワーク PnP 機能が正しく動作するように、デフォルトで Cisco APIC-EMにインストールされている自己署名証明書を、既知の認証局により署名された証明書に置き換える必要があります。 |
Cisco APIC-EMはインポートされた X.509 証明書と秘密キーを一度に 1 つのみサポートします。2 番目の証明書および秘密キーのインポート時に、最初に(既存の)インポートされた証明書および秘密キー値が上書きされます。
(注) | 外部 IP アドレスがコントローラに対し何らかの理由で変更される場合、変更された、または新しい IP アドレスを含む新しい証明書をインポートし直す必要があります。 |
Cisco APIC-EMは GUI を介してコントローラに証明書および秘密キーをインポートできます。Cisco APIC-EMでは、GUI を介して下位認証局(CA)から下位証明書(中間証明書)をインポートすることもできます。
コントローラにインポートする証明書(コントローラ証明書)につながる証明書チェーンに関連する下位証明書は、これらの下位 CA のルート証明書と一緒に単一のファイルに追加してインポートする必要があります。これらの証明書を追加する場合は、認定の実際のチェーンと同じ順序で追加する必要があります。
たとえば、ルート証明書(ルート CA)で既知の信頼できる CA が中間 CA 証明書(CA1)に署名したと仮定します。次に、この証明書 CA1 が別の中間 CA 証明書(CA2)に署名するとします。最後に CA 証明書(CA2)がコントローラ証明書(Controller_Certificate)に署名した CA であると仮定します。この例では、コントローラに作成およびインポートする必要のある PEM ファイルは、次のファイルの上部(最初)からファイルの下部(最後)までの順序である必要があります。
単一ファイルの作成のためにコントローラの証明書にルートおよび下位証明書を追加する要件は、PEM ファイルにのみ適用されます。インポートのためにルート証明書にルートおよび中間証明書を追加する要件は、PKCS ファイルには必要ありません。
Cisco APIC-EMおよび Cisco IOS デバイスは trustpool と呼ばれる特別な PKI 証明書ストアをサポートします。trustpool は信頼できる認証局(CA)を特定する X.509 証明書を保持します。Cisco APIC-EMおよびネットワークのデバイスは trustpool バンドルを使用して、相互の信頼関係、およびそれぞれの CA との信頼関係を管理します。コントローラはこの PKI 証明書ストアを管理し、プール内の証明書が失効する、再発行される、またはその他の理由で変更が必要な場合に、GUI を通じてこれを更新することができます。
(注) | Cisco APIC-EMはまた trustpool 機能を使用して、GUI でアップロードする証明書ファイルが有効な CA 署名付き証明書であるかどうかを判別します。 |
Cisco APIC-EMには、ios.p7b という名前のシスコの署名付き trustpool バンドルがデフォルトでプリインストールされています。この trustpool バンドルは、シスコのデジタル署名証明書で署名されているので、サポートされているシスコのネットワーク デバイスによりネイティブで信頼されます。この trustpool バンドルは、シスコのネットワーク デバイスが純正のアプリケーションおよびサービスとの信頼を確立するために重要です。この Cisco PKI の trustpool バンドル ファイルは、シスコの Web サイト(Cisco InfoSec)にあります。
リンクは次の場所にあります。http://www.cisco.com/security/pki/
コントローラのネットワーク PnP 機能のために、コントローラにより制御および監視されているサポート対象のシスコ デバイスは、このファイルをインポートする必要があります。サポートされているシスコ デバイスは最初のブート時に、コントローラにアクセスしてこのファイルをインポートします。
(注) | trustpool 内の証明書の期限切れ、再発行、またはその他の理由で、trustpool バンドルの新しいバージョンへの更新が必要になる場合があります。コントローラに存在する trustpool バンドルの更新が必要になったときは、コントローラの GUI を使用していつでも更新できます。コントローラはシスコ クラウド(シスコ認定の trustpool バンドルが含まれている)にアクセスして最新の trustpool バンドルをダウンロードできます。ダウンロード後に、コントローラは、現在の古い trustpool バンドル ファイルを上書きします。実際には、[Certificate]ウィンドウまたは [Proxy Gateway Certificate] ウィンドウを使用して CA から新しい証明書をインポートする前、または [Update] ボタンがグレー表示ではなくアクティブな場合はいつでも、trustpool バンドルを更新できます。 |
Cisco APIC-EMtrustpool の管理機能は次のように動作します。
ネットワーク PnP 機能をサポートするネットワーク内のシスコ デバイスをブートします。
すべてのシスコ デバイスがネットワーク PnP 機能をサポートするわけではないことに注意してください。サポート対象のシスコ デバイスのリストについては、『Release Notes for Cisco Network Plug and Play』を参照してください。
PnP の最初のフローの一部として、これらのサポート対象のシスコ デバイスは、HTTP を使用して trustpool バンドルを Cisco APIC-EMから直接ダウンロードします。
シスコ デバイスは、ネットワーク PnP トラフィック フローごとの詳細なデバイス設定およびプロビジョニングを取得するために Cisco APIC-EMと通信できる状態になります。
HTTP プロキシ ゲートウェイがコントローラとこれらのシスコ デバイスの間に存在する場合、コントローラにプロキシ ゲートウェイの証明書をインポートするための追加の手順を実行します。プロキシ ゲートウェイ証明書のインポートを参照してください。
Cisco APIC-EMのパスワード ポリシーは、コントローラ GUI へのログイン、Grapevine ルートへの SSH ログイン、ノースバウンド API 要求およびトラブルシューティングのための Grapevine コンソールへのログインでのパスワード値を管理します。Cisco APIC-EMはパスワード ポリシーに準拠していないパスワードを拒否します。パスワードが拒否されると、コントローラが拒否理由を説明するエラー メッセージを表示します。
たとえば、Splunge! は、長さが 8 文字以上で、1 文字以上の大文字のアルファベット、1 文字以上の小文字のアルファベット、1 文字以上の特殊文字(!)が含まれているため、有効なパスワードです。
次の表に、着信トラフィックを許可する Cisco APIC-EMポートと、発信トラフィックに使用されるCisco APIC-EM ポートを示します。コントローラでこれらのポートが着信および発信の両方のトラフィック フローに対して開かれていることを確認する必要があります。
次の表に、コントローラへの着信トラフィックを許可する Cisco APIC-EM ポートを示します。
(注) | ネットワークでポート 22 および 14141 へのアクセスが適切に保護されていることを確認します。 |
ポート番号 |
許可されるトラフィック |
プロトコル(TCP または UDP) |
---|---|---|
22 |
SSH |
TCP |
67 |
bootps |
UDP |
80 |
HTTP |
TCP |
123 |
NTP |
UDP |
162 |
SNMP |
UDP |
443 1 |
HTTPS |
TCP |
500 |
ISAKMP 特定の導入でファイアウォールを介して複数のホストを導入するためには、IPSec ISAKMP(Internet Security Association and Key Management Protocol)UDP ポート 500 の通過が許可されている必要があります。 |
UDP |
14141 |
Grapevine コンソール |
TCP |
16026 |
SCEP |
TCP |
次の表に、コントローラからの発信トラフィックに使用される Cisco APIC-EM ポートを示します。
ポート番号 |
許可されるトラフィック |
プロトコル(TCP または UDP) |
||
---|---|---|---|---|
22 |
SSH(ネットワーク デバイスへ) |
TCP |
||
23 |
Telnet(ネットワーク デバイスへ) |
TCP |
||
53 |
DNS |
UDP |
||
80 |
ポート 80 は発信プロキシ設定に使用できます。 さらに、8080 など、その他の共通のポートもプロキシが Cisco APIC-EM 設定ウィザードで設定されているときに使用できます(プロキシがすでにネットワークで使用されている場合)。
|
TCP |
||
123 |
NTP |
UDP |
||
161 |
SNMP エージェント |
UDP |
||
443 2 |
HTTPS |
TCP |
||
500 |
ISAKMP 特定の導入でファイアウォールを介して複数のホストを導入するためには、IPSec ISAKMP(Internet Security Association and Key Management Protocol)UDP ポート 500 の通過が許可されている必要があります。 |
UDP |