この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco APIC-EM では基本機能をサポートするためにマルチレイヤ アーキテクチャが必要です。マルチレイヤ アーキテクチャは、次のコンポーネントで構成されています。
外部ネットワーク:外部ネットワークは、ネットワークの一方の管理者とアプリケーション、もう一方の内部ネットワーク内またはクラウドの Grapevine root とクライアント間に存在します。管理者とアプリケーションの両方がこの外部ネットワークを使用して Grapevine root とクライアントにアクセスします。
内部ネットワーク:内部ネットワークは Grapevine root およびクライアント両方で構成されます。
デバイス管理ネットワーク:このネットワークは、コントローラで管理および監視されるデバイスで構成されています。デバイス管理ネットワークは上記の外部ネットワークと基本的に同じであることに注意してください。これは管理者またはノースバウンド アプリケーションから物理的または論理的にセグメント化される可能性があります。
あらゆるレイヤ間通信およびレイヤ内通信では、暗号化、認証およびセグメント化による保護が必要です。
(注) |
内部ネットワーク内のクライアントで動作するさまざまなサービスについては、第 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 ブローカ 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-EM Trustpool サポート」セクションを参照してください。
(注) |
自己署名証明書をコントローラで使用したり、コントローラにインポートすることはお勧めしません。既知の認証局(CA)から有効な X.509 証明書をインポートすることをお勧めします。さらに、自己署名証明書(デフォルトで Cisco APIC-EM にインストールされた)を、ネットワーク PnP 機能が正しく動作するように、既知の認証局により署名された証明書に置き換える必要があります。 |
Cisco APIC-EM は一度にインポートされた 1 つの X.509 証明書と秘密キーのみサポートします。2 番目の証明書および秘密キーのインポート時に、最初に(既存の)インポートされた証明書および秘密キー値が上書きされます。
(注) |
外部 IP アドレスがコントローラに対し何らかの理由で変更される場合、変更された、または新しい IP アドレスを含む新しい証明書をインポートし直す必要があります。 |
Cisco APIC-EM は GUI を介してコントローラに証明書および秘密キーをインポートできます。Cisco APIC-EMは、下位認証局(CA)から GUI を通じての下位証明書(中間証明書)のインポートもサポートします。
コントローラ(コントローラ証明書)にインポートされた証明書につながる証明書チェーンに関連する下位証明書がある場合、これらの下位 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 との信頼関係を制御します。コントローラは、プールの証明書が失効予定、再発行される、またはその他の理由で変更する必要がある場合に、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-EM trustpool の管理機能は次のように動作します。
ネットワーク 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 |