Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

セキュアなゼロタッチプロビジョニング

手記：

セキュア ゼロタッチ プロビジョニング(SZTP)をサポートするプラットフォームを確認するには、 機能エクスプローラーに移動します。[Feature Explorer] ページの [ Explore Features ] セクションで、[ All Features] を選択します。[ 機能ファミリーでグループ化された機能 ] ボックスで、[セキュア ZTP] を選択します。[ フィーチャの検索 ] 編集ボックスにフィーチャの名前を入力することもできます。ZTP サポートがどのように拡張されたかについて詳しくは、このトピックの最後にある「リリース履歴」の表を参照してください。

概要

手記：

Phone-Home Client(PHC)プロセスは、セキュア ゼロ タッチ プロビジョニング(SZTP)をサポートします。

RFC-8572ベースのSZTPを使用して、工場出荷時のデフォルト状態にあるリモートの場所にあるネットワークデバイスをブートストラップできます。SZTP は、リモート ネットワーク デバイスをプロビジョニングする前に、ブートストラップ サーバーとネットワーク デバイス間の相互認証を有効にします。

相互認証を有効にするには、一意のデジタルバウチャーとDevID(デジタルデバイスIDまたは暗号化されたデジタルID)プログラムされたネットワークデバイスが必要です。DevIDは、ネットワークデバイス上のTrusted Platform Module(TPM)2.0チップ内に埋め込まれています。ジュニパーネットワークスでは、対象となるネットワークデバイスごとにデジタルバウチャーをお客様に発行しています。

管理インターフェイスとWANインターフェイスでSZTPをサポートしています。

手記：

DHCP ベースのレガシー ZTP は無効です。SZTP をサポートするハードウェアでは、DHCP ベースのレガシー ZTP はサポートされていません。

SZTP は RFC 8572 に準拠しており、ネットワーク デバイスの ID と信頼性を確保するために次のインフラストラクチャが必要です。

  • トラステッド プラットフォーム モジュール (TPM) 2.0

  • デジタルデバイスID(DevID)

  • DevID証明書

  • X.509 固定ドメイン証明書 (PDC)

  • 所有者証明書

  • DevIDトラストアンカー

  • バウチャー

    バウチャーの生成方法については、「 バウチャー証明書の生成」を参照してください。

セキュア ZTP を使用してジュニパーデバイスをオンボーディングするには、『 セキュア ZTP クイックスタートガイド』を参照してください。

利点

  • 手動による介入なしでリモートネットワークデバイスをプロビジョニングできます。

  • ネットワーク デバイスを中央の場所から安全にプロビジョニングできるため、許可されていないエンティティがネットワーク デバイスを制御するのを防ぐことができます。

  • リダイレクトサーバーとブートストラップサーバーは、ネットワークデバイスのTPMにプログラムされているDevIDに基づいて、ネットワークデバイスの信頼性を検証します。

  • ネットワークデバイスは、デバイスのバウチャーに基づいて、リダイレクトサーバーとブートストラップサーバーの信頼性、およびブートストラップ情報を検証します。

ユースケース

工場出荷時のネットワーク デバイスの場合、ネットワーク デバイスに手動で触れることなく、安全かつリモートの両方でネットワーク デバイスを動作させることができます。ネットワークデバイスは、動的ホスト構成プロトコル(DHCP)を使用してネットワーク接続情報を取得し、リモートブートストラップサーバーに接続できる必要があります。

SZTP 要件

ネットワークに SZTP を展開するには、以下のタスクを実行する必要があります。

  1. DHCPサーバーとDNSサーバーを展開します。

  2. DHCP サーバーで DHCP V4 オプション 143 または DHCP V6 オプション 136 を構成して、DHCP サーバーがリダイレクト サーバーおよびブートストラップ サーバーの名前をアドバタイズできるようにします。

  3. リダイレクトサーバーとブートストラップサーバーをデプロイします。

  4. ジュニパーネットワークスからDevIDトラストアンカーを取得します。

  5. 1つのネットワークデバイスまたはネットワークデバイスグループの所有者証明書を生成します。

  6. ネットワーク ドメインごとにピン留めされたドメイン証明書 (PDC) を生成します。

  7. ジュニパーネットワークスからバウチャーを取得します。

  8. 各ネットワークデバイスのリダイレクトとブートストラップ情報を生成します。

  9. リダイレクトサーバーとブートストラップサーバーが提供するリダイレクトとブートストラップの情報を使用して、ネットワークデバイスをプロビジョニングします。

ネットワークに SZTP を展開し、新しいネットワーク デバイスを展開すると、ネットワーク デバイスが自動的にブートストラップされます。

SZTP インフラストラクチャ コンポーネント

トラステッド プラットフォーム モジュール (TPM) 2.0

TPMは、セキュリティ関連の機能を提供するマイクロチップです。ジュニパーネットワークスは、製造プロセスにおいて、デジタルデバイスID(DevID)と非対称キーペア(公開キーと秘密キー)を使用してTPMをプログラムします。TPM は、非対称ペアの秘密キーを改ざん防止の場所にロックします。

DevID

DevIDは秘密鍵に対応し、秘密鍵を保護します。署名または暗号化を必要とするアプリケーションでは、DevIDプライベートキーを使用します。

ネットワーク デバイスで実行されているアプリケーションは、ネットワーク デバイスの TPM の DevID 秘密キーを使用して、リモート検証者にネットワーク デバイスの ID を証明します。

DevID証明書

ジュニパーネットワークスは、プライベートキーのDevIDに対応するパブリックキーのDevID証明書(X.509証明書)を生成します。DevID証明書には、DevIDが作成されたネットワークデバイスのシリアル番号が含まれています。DevID証明書は、IEEE 802.1AR規格に準拠して生成されます。

手記：IDevID をサポートしています。LDevIDはサポートしていません。

X.509 固定ドメイン証明書 (PDC)

すべてのネットワーク ドメインに対して X.509 ピン留めドメイン証明書 (PDC) を作成します。PDC は、ルート CA 証明書または中間 CA 証明書のいずれかです。PDC を Distinguished Encoding Rules (DER) から Base 64 エンコードに変換します。PDC が証明機関 (CA) であり、X.509 に準拠していることを確認します。

所有者証明書

所有者証明書は、ネットワークデバイスを購入または所有しているベンダーを確認します。ネットワークデバイスまたはネットワークデバイスのグループごとに、非対称キーペア(公開キーと秘密キー)を生成します。鍵ペアは、Rivest-Shamir-Adleman(RSA)または楕円曲線暗号(ECC)のいずれかを使用する必要があります。秘密鍵は安全な場所に保護してください。ピン留めされたドメイン証明書 (PDC) は、所有者証明書の CA である必要があります。

DevIDトラストアンカー

ジュニパーネットワークスは、DevIDトラストアンカーを提供しています。リダイレクトサーバーとブートストラップサーバーにDevIDトラストアンカーをインストールして、TLSセッションの確立中にデバイスまたはクライアントが提示するDevID証明書を確認します。

バウチャー証明書

バウチャー証明書を受け取るには、PDCとネットワークデバイスのシリアル番号をジュニパーアジャイルライセンシング(JAL)ポータルに入力します。バウチャー証明書を受け取ったら、ブートストラップサーバーのブートストラップ情報の一部としてバウチャー証明書を含めます。ブートストラップサーバーは、バウチャー証明書をネットワークデバイスに提供します。その後、ネットワークデバイスはブートストラップ情報を使用して、リダイレクトサーバーが提供するトラストアンカーを検証します。

バウチャーの受け取り方法の詳細な手順については、「 バウチャー証明書の生成」を参照してください。

DevIDワークフロー

  1. アプリケーションがDevIDを使用する署名または暗号化を必要とする場合、アプリケーションはブートストラップサーバーとのTLSセッションを要求します。

  2. ブートストラップ サーバーは、ネットワーク デバイスに TLS 応答を送信し、ネットワーク デバイスに次の操作を行うように要求します。
    • DevID証明書を提供する
    • 秘密鍵があることを証明する

  3. ネットワークデバイスは、秘密キーのDevIDを使用してセッションデータに署名します。

  4. ネットワーク デバイスは、デジタル署名と DevID 証明書をブートストラップ サーバーに送信します。

  5. ブートストラップ サーバーは、DevID 証明書を使用してデジタル署名を検証します。

  6. ブートストラップサーバーは、ジュニパーネットワークスが提供するDevIDトラストアンカーを使用して、DevID証明書を検証します。

オンボーディング情報

ネットワーク デバイスがそれ自体をブートストラップし、他のシステムとのセキュアな接続を確立するには、オンボーディング情報を提供する必要があります。オンボーディング情報とは、ネットワークデバイスが自身をブートストラップして他のシステムに接続するために使用するデータです。ネットワーク デバイスがこのデータを送信する場合、RFC 8572 に準拠した形式でデータをエンコードする必要があります。

ブート イメージ情報

ブート イメージ情報には、OS の名前と OS のバージョンが含まれます。OSバージョンとして「Junos」を指定することをお勧めします。ネットワーク デバイスがソフトウェアを継続的にダウンロードおよびインストールしないように、正しい OS バージョンを指定してください。

ダウンロードURI

ダウンロード URI は、ブート イメージの場所を提供します。

画像検証

イメージ検証フィールドには、ソフトウェアイメージのセキュアハッシュの生成に使用するハッシュアルゴリズムと、ソフトウェアイメージのダイジェスト値が含まれます。SZTP は SHA256 をサポートしています。ダイジェスト値を 16 進数の文字列としてエンコードします。

設定処理

SZTP は、コンフィギュレーションをマージまたは置換できます。XML でコンフィギュレーションを作成し、コンフィギュレーションを Base 64 形式にエンコードします。設定は、ブートストラップサーバーがブートストラップ情報に含めることができるように、Base64形式にする必要があります。

事前設定スクリプト

SZTP は、Bourne シェル・スクリプトと Python スクリプトをサポートしています。Bourne シェル・スクリプト・インタープリターのパスは #!/bin/sh で、Python インタープリターのパスは #!/usr/bin/python です。

スクリプトが Bourne スクリプトの場合、SZTP はスクリプトの終了値を検査します。スクリプトがゼロ以外の値で終了すると、SZTP プロセスは再始動します。スクリプトが Python スクリプトの場合、SZTP はスクリプトの終了値を確認しません。スクリプトの出力には、スクリプトが正常に実行された場合でもエラーが含まれる可能性があります。

XML でのオンボード情報の例を次に示します。

設定後スクリプト

事前設定スクリプトの要件は、設定後スクリプトにも適用されます。設定後スクリプトが失敗した場合、デバイスは事前設定スクリプトが実行される前に実行していた設定にロールバックします。SZTP プロセスが再始動します。

DHCP v4 オプション 143

DHCP クライアントが DHCP クライアントに IP アドレスを提供できるようになる前に、DHCP サーバーで DHCP V4 オプション 143 を構成します。

MXシリーズのデバイスをDHCPサーバーとして使用する場合は、DHCP V4オプション143を有効にします。

次に、構成例を示します。

DHCP v6 オプション 135

次に、構成例を示します。

16進数形式からASCIIテキスト形式への変換

たとえば、DHCP V6 オプション 135 のこの 16 進数のテキスト文字列は、ASCII テキスト形式の 26 バイトに相当します。16 進数形式では、26 は 001a と表されます。各 16 進数は 1 バイトに等しく、各バイトは ASCII 文字の組み合わせに等しくなります。

001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 16 進文字列を ASCII 文字に変換するには、16 進数の文字と数字を ASCII の文字、数字、記号にマッピングする必要があります。

この例では、DHCP オプション 135 に使用される URL をマッピングしています。DHCP オプション 143 で使用した URL にも同じプロセスを使用できます。

以下は、16進形式とASCII形式のマッピングを示すURLの例です。各 16 進数字が ASCII 形式の文字と記号にマッピングされていることがわかります。

最終ページ URL は https://ab-cde-server.net.

16進数からASCIIへのコンバーターを使用し、その逆を使用して、結果が正しいことを確認します。

SZTP ワークフロー

手記：このトピックには、許可されたワークフローの 1 つだけが含まれています。Appendix-Bを含むRFC 8572標準のすべてをサポートしています。

デバイスがまだ工場出荷時のデフォルトの状態でない場合は、次のコマンドのいずれかを発行して、デバイスを工場出荷時のデフォルトの状態にします。

  • Junos OSを実行しているネットワークデバイスで、 request vmhost zeroize コマンドを発行します。

  • Junos OS Evolvedを実行しているネットワークデバイスの場合は、 request system zeroize コマンドを発行します。

デバイスが工場出荷時のデフォルトの状態で起動すると、次のイベントが発生します。

  1. DHCP クライアントは、DHCP サーバーに要求を送信して、ブートストラップ サーバーまたはカスタマー リダイレクト サーバーの名前、IP アドレス、またはホスト名を取得します。

    V4 には DHCP オプション 143 を、V6 には DHCP オプション 135 を設定します。DHCPクライアントは、デバイスがブートストラップを完了するまで、各ブートストラップまたはリダイレクトサーバーのIPアドレスを要求します。

  2. DHCP サーバーは、ブートストラップ サーバーまたはカスタマー リダイレクト サーバーのサーバー ホスト名を DHCP クライアントに送信します。

  3. デバイス上のPhone-Homeクライアント(PHC)は、DHCPオプションから学習したサーバーにブートストラップ要求を送信します。DHCPオプションに複数のサーバーを指定した場合、デバイスは各サーバーとのブートストラップを順番に試行します。

    デバイスは、PHC が DHCP オプションを通じて学習したブートストラップ、カスタマー リダイレクト、または DNS サーバーでブートストラップを試みます。デバイスは、正常にブートストラップされるまで、ラウンドロビン方式でサーバーへのブートストラップを試みます。

  4. ブートストラップ サーバーは、署名されたオンボーディング情報と、所有者証明書および所有権バウチャーで応答します。

  5. PHC は、所有者証明書と所有権バウチャーの情報を使用して、署名されたオンボーディング情報を確認します。

  6. PHC は、イメージと構成情報を抽出します。

  7. デバイスで別のイメージが実行されている場合、デバイスはイメージをダウンロードし、新しいイメージを使用してアップグレードし、新しいイメージで再起動します。

    再起動後、SZTP シーケンス全体が繰り返されますが、必要なイメージがすでにあるため、デバイスは再起動しません。

  8. PHC が設定をコミットします。

  9. (オプション)PHC は、設定後スクリプトを実行します。

  10. PHC は、ブートストラップ完了メッセージを PHS に送信します。

  11. デバイスは、PHC 関連の設定とリソースをクリーンアップします。

  12. PHC は終了します。

表 1: SZTP でサポートされるスクリプト

スクリプトの種類

インタプリタパス

プラットフォームのサポート

シェルスクリプト

#!/bin/sh

すべてのネットワークデバイス

Python スクリプト

#!/usr/bin/python

Junos OSを実行するネットワークデバイスと自動化の強化

Junos OS Evolvedを実行するネットワークデバイス

デュアルルーティングエンジンを搭載したネットワークデバイス用のSZTP

Junos OSソフトウェアを実行するネットワークデバイスのバックアップルーティングエンジンでソフトウェアをアップグレードする前に、プライマリルーティングエンジンの[edit system]階層でsecure-ztp provision-backup-reステートメントを有効にします

Junos OSソフトウェアを実行するネットワークデバイスで、プライマリルーティングエンジンの[edit system]階層でprovision-backup-reステートメントを有効にして、バックアップルーティングエンジンをブートストラップできるようにします。

Junos OS Evolvedソフトウェアを実行するネットワークデバイスでは、[edit system]階層でauto-sw-syncステートメントを有効にして、プライマリルーティングエンジンがアップグレードまたはダウングレード時にバックアップルーティングエンジンに同じイメージバージョンがあることを確認します。

デュアルルーティングエンジンを搭載したJunos OSベースのシステムでは、プライマリルーティングエンジンがすでに必要なイメージバージョンを実行している場合でも、プライマリルーティングエンジンがイメージをダウンロードします。デバイスがイメージをダウンロードすることで、必要に応じてプライマリ ルーティングエンジンがバックアップ ルーティングエンジンをアップグレードできるようになります。

Junos OS Evolvedベースのシステムでは、プライマリルーティングエンジンが常に実行中のイメージのコピーを保持します。

[edit system]階層でsynchronizeステートメントを有効にしていない場合、またはプライマリルーティングエンジンでグレースフルリスタートエンジンスイッチオーバー(GRES)を有効にしていない場合、プライマリルーティングエンジンは設定と状態をバックアップルーティングエンジンに同期しません。この場合、プライマリルーティングエンジンは、データをバックアップルーティングエンジンと同期する前に、バックアップルーティングエンジンの信頼性を検証します。

プライマリルーティングエンジンがバックアップルーティングエンジンをプロビジョニングする前に、プライマリルーティングエンジンはバックアップルーティングエンジンの信頼性を検証します。プライマリルーティングエンジンは、バックアップルーティングエンジンのDevIDをチェックして、バックアップルーティングエンジンがジュニパー認定のルーティングエンジンであることを確認します。

手記：

プライマリルーティングエンジンは、バックアップルーティングエンジンがプライマリルーティングエンジンから情報を受信する権限を持っているかどうかをチェックしません。また、バックアップのルーティングエンジンは、プライマリのルーティングエンジンの信頼性や認可を検証しません。

プライマリ ルーティングエンジンは、以下の状況でバックアップ ルーティングエンジンをプロビジョニングします。

  • プライマリ ルーティングエンジンが SZTP を使用してブートストラップされている場合。

  • バックアップ ルーティングエンジンがある場合、プライマリ ルーティングエンジンがブートストラップ中である場合、または SZTP プロセス中に挿入されます。

  • バックアップ ルーティングエンジンが再起動したとき、または交換されたとき。

プライマリ ルーティングエンジンがバックアップ ルーティングエンジンの真正性を検証し、プロビジョニングの要件を満たした場合、プライマリ ルーティングエンジンはバックアップ ルーティングエンジンで実行されているソフトウェアのバージョンを確認します。バックアップ ルーティングエンジンのソフトウェア バージョンがプライマリ ルーティングエンジンのソフトウェア バージョンと異なる場合、プライマリ ルーティングエンジンはバックアップ ルーティングエンジンをプライマリ ルーティングエンジンが稼働しているのと同じソフトウェア バージョンにアップグレードします。

両方のルーティング エンジンが同じソフトウェアを実行している場合、プライマリ ルーティングエンジンはその設定をバックアップ ルーティングエンジンと同期します。

関連資料