Cisco APIC-EMでは基本機能をサポートするためにマルチレイヤ アーキテクチャが必要です。マルチレイヤ アーキテクチャは、次のコンポーネントで構成されています。

• 外部ネットワーク：外部ネットワークは、ネットワークの一方の管理者とアプリケーション、もう一方の内部ネットワーク内またはクラウドのGrapevine rootとクライアント間に存在します。管理者とアプリケーションの両方がこの外部ネットワークを使用して Grapevine rootとクライアントにアクセスします。

• 内部ネットワーク：内部ネットワークは Grapevine rootおよびクライアント両方で構成されます。

• デバイス管理ネットワーク：このネットワークは、コントローラで管理および監視されるデバイスで構成されています。デバイス管理ネットワークは上記の外部ネットワークと基本的に同じであることに注意してください。これは管理者またはノースバウンド アプリケーションから物理的または論理的にセグメント化される可能性があります。

（注）	内部ネットワーク内のクライアントで動作するさまざまなサービスについては、第 3 章「Cisco APIC-EMのサービス」を参照してください。

Cisco APIC-EMは公開キー インフラストラクチャ（PKI）を基盤としてセキュアな通信を提供しています。PKI は、認証局、デジタル証明書、公開キーと秘密キーで構成されます。

証明機関（CA）は証明書要求を管理して、ホスト、ネットワーク デバイス、ユーザなどの参加エンティティにデジタル証明書を発行します。CA は参加エンティティに対して集中型のキー管理を行います。

デジタル署名は、公開キー暗号化に基づいて、ホスト、デバイスや個々のユーザをデジタル的に認証します。RSA 暗号化システムなどの公開キー暗号化では、各エンティティはキー ペアを持ち、これには秘密キーと公開キーが含まれています。秘密キーは秘密裡に保管し、これを知っているのは所有するホスト、デバイスまたはユーザだけです。一方、公開キーは誰もが知っているものです。これらのキーの一方で暗号化されたものは、他方のキーで復号化できます。署名は、送信者の秘密キーを使用してデータを暗号化したときに作成されます。受信側は、送信側の公開キーを使用してメッセージを復号化することで、署名を検証します。このプロセスは、受信者が送信者の公開キーのコピーを持っていて、これが本当に送信者のものであり、送信者を騙る他人のものではないことを高い確実性を持って知っていることを基盤としています。

デジタル証明書は、デジタル署名と送信者を結び付けるものです。デジタル証明書には、名前、シリアル番号、企業、部署または IP アドレスなど、ユーザまたはデバイスを特定する情報を含んでいます。また、エンティティの公開キーのコピーも含まれています。証明書に署名する CA は、受信者が明示的に信頼する第三者機関であり、アイデンティティの正当性を立証し、デジタル証明書を作成します。

CA の署名を検証するには、受信者は、CA の公開キーを認識している必要があります。一般的にはこのプロセスはアウト オブ バンドか、インストール時に行われる操作によって処理されます。たとえば、通常の Web ブラウザでは、デフォルトで、複数の CA の公開キーが設定されています。

Cisco APIC-EMはセッション（HTTPS）の認証に使用される PKI 証明書管理機能をサポートします。これらのセッションでは、認証局（CA）と呼ばれる一般に認められた信頼されたエージェントを使用します。Cisco APIC-EMは PKI 証明書管理機能を使用して、既知の CA から X.509 証明書をインポートし、保存して管理します。インポートされた証明書はコントローラ自体の ID 証明書になり、コントローラは認証用にクライアントにこの証明書を示します。クライアントは、NB API のアプリケーションやネットワーク デバイスです。

Cisco APIC-EMはコントローラの GUI を使用して次のファイル（PEM または PKCS ファイル形式）をインポートできます。

• X.509 証明書

• 秘密キー

（注）	秘密キーに対し、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 証明書をインポートすることをお勧めします。さらに、自己署名証明書（デフォルトで Cisco APIC-EMにインストールされた）を、ネットワーク PnP 機能が正しく動作するように、既知の認証局により署名された証明書に置き換える必要があります。

Cisco APIC-EMは一度にインポートされた 1 つの X.509 証明書と秘密キーのみサポートします。2 番目の証明書および秘密キーのインポート時に、最初に（既存の）インポートされた証明書および秘密キー値が上書きされます。

（注）	外部 IP アドレスがコントローラに対し何らかの理由で変更される場合、変更された、または新しい IP アドレスを含む新しい証明書をインポートし直す必要があります。

Cisco APIC-EMおよび Cisco IOS デバイスは trustpool と呼ばれる特別な PKI 証明書ストアをサポートします。trustpool は信頼できる認証局（CA）を特定する X.509 証明書を保持します。Cisco APIC-EMおよびネットワークのデバイスは trustpool バンドルを使用して、相互の、およびこれらの CA との信頼関係を制御します。コントローラは、プールの証明書が失効予定、再発行される、またはその他の理由で変更する必要がある場合に、GUI を通じて、この PKI 証明書ストアを制御し、これを更新することができます。

（注）	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 を使用して更新できます。コントローラは Cisco Cloud（シスコ認定の trustpool バンドルが含まれている）にアクセスして最新の trustpool バンドルをダウンロードできます。ダウンロード後に、コントローラは、現在の古い trustpool バンドル ファイルを上書きします。実際には、[Certificate]ウィンドウまたは [Proxy Gateway Certificate] ウィンドウを使用して、CA からの新しい証明書がインポートされる前、または [Update] ボタンがアクティブでグレーでなければいつでも、trustpool バンドルを更新できます。

Cisco APIC-EMtrustpool の管理機能は次のように動作します。

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

   すべてのシスコ デバイスがネットワーク PnP 機能をサポートするわけではないことに注意してください。サポート対象のシスコ デバイスのリストについては、『Release Notes for Cisco Network Plug and Play』を参照してください。

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

3. シスコ デバイスは、詳細なデバイス設定およびネットワーク PnP トラフィック フローごとのプロビジョニングを取得するために Cisco APIC-EMと通信する準備ができました。

   重要:

   HTTP プロキシ ゲートウェイがコントローラとこれらのシスコ デバイスの間に存在する場合、コントローラにプロキシ ゲートウェイの証明書をインポートするための追加の手順を実行します。プロキシ ゲートウェイ証明書のインポートを参照してください。

シスコ ネットワーク プラグ アンド プレイ（PnP）アプリケーションを使用して、Cisco APIC-EMはサポート対象のシスコ ネットワーク デバイスからの HTTPS 要求に応答し、これらのデバイスがイメージおよび目的の設定をダウンロードしてインストールすることを許可します。デバイスでコントローラからこれらのファイルをダウンロードできるようにするには、コントローラとデバイス間の最初のインタラクションで信頼関係を確立する必要があります。

PnP 対応デバイスとの最初のインタラクションでは、PnP 対応デバイスは、CA ルート証明書のバンドルまたは少なくともサーバ側の証明書を発行した CA の証明書が含まれる信頼情報を含むコントローラによってプロビジョニングされます。後者の場合は、CA が既知の CA になる場合もあればならない場合もあることに注意してください。

一部のシスコ ネットワーク プラグ アンド プレイのシナリオでは、ネットワーク設定でコントローラと PnP 対応デバイス間にプロキシ ゲートウェイを配置することができます。たとえば、IWAN 展開では、ブランチ ルータは最初のプロビジョニング時に DMZ でプロキシ ゲートウェイを通じてCisco APIC-EMと通信できます。プロキシ ゲートウェイが存在するかどうかに応じて、デバイスとの最初のトランザクション時にコントローラによって提供された信頼情報はプロキシ ゲートウェイまたはコントローラの証明書発行者に対応できます（対応するサーバ証明書が有効な CA 署名付きでない場合）。一方、プロキシまたは非プロキシのケースでは、証明書が単に自己署名証明書である場合は、その証明書はデバイスによって信頼ストアにダウンロードされます。

（注）	Cisco APIC-EMまたはプロキシ ゲートウェイに自己署名証明書を使用することは決して推奨しません。公的に検証可能な CA 発行の証明書を使用して、コントローラとプロキシ ゲートウェイ（存在する場合）にインストールすることを強く推奨します。

コントローラまたはプロキシ ゲートウェイ（存在する場合）に有効な CA 発行の証明書を使用すると、PnP 対応デバイスはすべての既知の CA ルート証明書を含む trustpool バンドル（ios.p7b）をダウンロードできます。これにより、デバイスはコントローラまたはプロキシ ゲートウェイへのセキュアな接続を確立でき、それらのデバイスのさらなるプロビジョニングと操作が可能になります。このような証明書に有効な CA 署名または自己署名がされていない場合、コントローラまたはコントローラの前にあるプロキシ ゲートウェイへのセキュアな接続を先に進めるために、デバイスは発行元の CA の証明書または自己署名証明書をダウンロードする必要があります。インストールされる証明書の特性に応じて、Cisco APIC-EMは、関連する信頼できる証明書のデバイスへの自動ダウンロードを促進します。ただし、プロキシ ゲートウェイが存在する場合は、コントローラによって同様の事前プロビジョニングを促進するためのプロビジョニング GUI が提供されます。

Cisco APIC-EMのパスワード ポリシーは、コントローラ GUI へのログイン、Grapevine ルートへの SSH ログイン、ノースバウンド API 要求およびトラブルシューティングのための Grapevine コンソールへのログインでのパスワード値を管理します。Cisco APIC-EMはパスワード ポリシーに従わないパスワードを拒否します。パスワードが拒否されると、コントローラが拒否理由を説明するエラー メッセージを表示します。

たとえば、Splunge! は、長さが 8 文字以上で、1 文字以上の大文字のアルファベット、1 文字以上の小文字のアルファベット、1 文字以上の特殊文字（!）が含まれているため、有効なパスワードです。