セキュアなゼロタッチプロビジョニング
セキュアゼロタッチプロビジョニング(SZTP)をサポートするプラットフォームを確認するには、 機能エクスプローラに移動します。機能エクスプローラーページの 機能の探索 セクションで、 すべての機能を選択します。機能 ファミリー別にグループ化された機能 ボックスで、セキュアZTPを選択します。[ フィーチャの検索 ] 編集ボックスにフィーチャの名前を入力することもできます。ZTPサポートがどのように拡張されたかの詳細については、このトピックの最後にあるリリース履歴の表を参照してください。
概要
電話ホームクライアント(PHC)プロセスは、セキュアゼロタッチプロビジョニング(SZTP)をサポートします。
RFC-8572ベースのSZTPを使用して、工場出荷時のデフォルト状態にある遠隔地にあるネットワークデバイスをブートストラップできます。SZTPを使用すると、リモートネットワークデバイスをプロビジョニングする前に、ブートストラップサーバーとネットワークデバイス間の相互認証が可能になります。
相互認証を有効にするには、一意のデジタルバウチャーとDevID(デジタルデバイスIDまたは暗号デジタルID)プログラムされたネットワークデバイスが必要です。DevIDは、ネットワークデバイスのTPM(Trusted Platform Module)2.0チップ内に組み込まれています。ジュニパーネットワークスでは、対象となるネットワークデバイスごとにデジタルバウチャーをお客様に発行しています。
管理インターフェイスとWANインターフェイスでSZTPをサポートします。
DHCPベースのレガシーZTPは無効です。SZTPをサポートするハードウェアでは、DHCPベースのレガシーZTPはサポートされません。
SZTPはRFC 8572に準拠しており、ネットワークデバイスのIDと信頼性を確保するために、以下のインフラストラクチャが必要です。
Trusted Platform Module(TPM)2.0
デジタルデバイスID(DevID)
DevID証明書
X.509ピン留めドメイン証明書(PDC)
所有者証明書
DevIDトラストアンカー
バウチャー
バウチャーの生成方法については、 バウチャー証明書の生成を参照してください。
セキュアZTPを使用してジュニパーデバイスをオンボーディングする方法については、 『セキュアZTPクイックスタートガイド』を参照してください。
利点
手動操作なしでリモートネットワークデバイスをプロビジョニングできます。
中央の場所からネットワークデバイスを安全にプロビジョニングできるため、権限のないエンティティがネットワークデバイスを制御するのを防ぎます。
リダイレクト サーバーとブートストラップ サーバーは、ネットワーク デバイスの TPM でプログラムされた DevID に基づいて、ネットワーク デバイスの信頼性を検証します。
ネットワークデバイスは、デバイスのバウチャーに基づいて、リダイレクトサーバーとブートストラップサーバー、およびブートストラップ情報の信頼性を検証します。
ユースケース
工場出荷時から出荷されるネットワークデバイスの場合、ネットワークデバイスに手動で触れることなく、ネットワークデバイスを安全かつリモートで動作させることができます。ネットワークデバイスは、ダイナミックホスト構成プロトコル(DHCP)を使用してネットワーク接続情報を取得し、リモートブートストラップサーバーに接続できる必要があります。
SZTPの要件
ネットワークにSZTPを展開するには、以下のタスクを実行する必要があります。
DHCPサーバーとDNSサーバーを展開します。
DHCP サーバーで DHCP V4 オプション 143 または DHCP V6 オプション 136 を設定して、DHCP サーバーがリダイレクト サーバーとブートストラップ サーバーの名前をアドバタイズできるようにします。
リダイレクトサーバーとブートストラップサーバーを展開します。
ジュニパーネットワークスからDevIDトラストアンカーを入手します。
1つのネットワークデバイスまたはネットワークデバイスのグループの所有者証明書を生成します。
ネットワークドメインごとにピン留めされたドメイン証明書(PDC)を生成します。
ジュニパーネットワークスからバウチャーを入手します。
ネットワークデバイスごとにリダイレクト情報とブートストラップ情報を生成します。
リダイレクトサーバーとブートストラップサーバーが提供するリダイレクトとブートストラップの情報を使用して、ネットワークデバイスをプロビジョニングします。
SZTPをネットワークに展開し、新しいネットワークデバイスを展開すると、ネットワークデバイスが自動的にブートストラップされます。
SZTPインフラストラクチャコンポーネント
Trusted Platform Module(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規格に準拠して生成されます。
X.509ピン留めドメイン証明書(PDC)
ネットワークドメインごとにX.509ピン留めドメイン証明書(PDC)を作成します。PDC には、ルート CA 証明書または中間 CA 証明書のいずれかがあります。PDCを識別エンコーディングルール(DER)からベース64エンコーディングに変換します。PDC が認証機関(CA)であり、X.509 に準拠していることを確認します。
所有者証明書
所有者証明書は、ネットワークデバイスを購入または所有しているベンダーを確認します。ネットワークデバイスまたはネットワークデバイスのグループごとに、非対称キーペア(公開キーと秘密キー)を生成します。キーペアは、Rivest-Shamir-Adleman(RSA)または楕円曲線暗号(ECC)のいずれかを使用する必要があります。秘密キーは安全な場所で保護します。ピン留めされたドメイン証明書(PDC)は、所有者証明書のCAである必要があります。
DevIDトラストアンカー
ジュニパーネットワークスは、DevIDトラストアンカーを提供しています。リダイレクトサーバーとブートストラップサーバーにDevIDトラストアンカーをインストールして、TLSセッションを確立する際にデバイスまたはクライアントが提示するDevID証明書を確認します。
バウチャー証明書
バウチャー証明書を受け取るには、ジュニパーアジャイルライセンシング(JAL)ポータルにPDCとネットワークデバイスのシリアル番号を入力します。バウチャー証明書を受け取ったら、それらをブートストラップサーバーのブートストラップ情報の一部として含めます。ブートストラップサーバーは、ネットワークデバイスにバウチャー証明書を提供します。その後、ネットワークデバイスはブートストラップ情報を使用して、リダイレクトサーバーが提供するトラストアンカーを検証します。
バウチャーを受け取る方法の詳細な手順については、「 バウチャー証明書を生成する」を参照してください。
DevIDワークフロー
アプリケーションが DevID を使用する署名または暗号化を必要とする場合、アプリケーションはブートストラップ サーバーとの TLS セッションを要求します。
- ブートストラップサーバーは、TLS応答をネットワークデバイスに送信し、ネットワークデバイスに次のことを要求します。
- DevID証明書を入力します
- プライベートキーがあることを証明する
ネットワークデバイスは、プライベートキーのDevIDでセッションデータに署名します。
ネットワークデバイスは、デジタル署名とDevID証明書をブートストラップサーバーに送信します。
- ブートストラップサーバーは、DevID証明書を使用してデジタル署名を検証します。
ブートストラップサーバーは、ジュニパーネットワークスが提供するDevIDトラストアンカーを使用して、DevID証明書を検証します。
オンボーディング情報
ネットワークデバイスがそれ自体をブートストラップし、他のシステムとの安全な接続を確立するには、オンボーディング情報を提供する必要があります。オンボーディング情報とは、ネットワークデバイスがそれ自体をブートストラップして他のシステムに接続するために使用するデータです。ネットワークデバイスがこのデータを送信する場合、データはRFC 8572に準拠した形式でエンコードする必要があります。
ブートイメージ情報
ブートイメージ情報には、OSの名前とOSバージョンが含まれます。OSバージョンとして「Junos」を指定することをお勧めします。ネットワークデバイスが継続的にソフトウェアをダウンロードおよびインストールしないように、正しいOSバージョンを指定してください。
URIをダウンロード
ダウンロードURIは、ブートイメージの場所を提供します。
イメージ検証
イメージ検証フィールドには、ソフトウェアイメージのセキュアハッシュを生成するために使用するハッシュアルゴリズムと、ソフトウェアイメージのダイジェスト値が含まれます。SZTPはSHA256をサポートしています。ダイジェスト値を 16 進文字列としてエンコードします。
設定処理
SZTPは、設定をマージすることも置換することもできます。XML で設定を作成し、Base 64 形式にエンコードします。ブートストラップサーバーがブートストラップ情報に含めることができるように、設定をBase 64形式にする必要があります。
アップグレード前のスクリプト
デバイスをプロビジョニングする前に、アップグレード前のスクリプトを実行して、サードパーティアプリケーションの署名キーまたは証明書をダウンロードできます。
SZTPは、BourneシェルスクリプトとPythonスクリプトをサポートします。Bourne シェルスクリプトのインタプリタパスは #!/bin/sh で、Python インタプリタパスは #!/usr/bin/python です。
スクリプトがBourneスクリプトの場合、SZTPはスクリプトの終了値をチェックします。スクリプトがゼロ以外の値で終了すると、SZTPプロセスが再起動します。スクリプトが Python スクリプトの場合、SZTP はスクリプトの終了値をチェックしません。スクリプトが正常に実行された場合でも、スクリプトの出力にエラーが発生する可能性があります。
事前構成スクリプト
SZTPは、BourneシェルスクリプトとPythonスクリプトをサポートします。Bourne シェルスクリプトのインタプリタパスは #!/bin/sh で、Python インタプリタパスは #!/usr/bin/python です。
スクリプトがBourneスクリプトの場合、SZTPはスクリプトの終了値をチェックします。スクリプトがゼロ以外の値で終了すると、SZTPプロセスが再起動します。スクリプトが Python スクリプトの場合、SZTP はスクリプトの終了値をチェックしません。スクリプトが正常に実行された場合でも、スクリプトの出力にエラーが発生する可能性があります。
XML でのオンボーディング情報の例を次に示します。
=============================
<onboarding-information>
<boot-image>
<os-name>Junos</os-name>
<os-version>22.2R1</os-version>
<download-uri>https://example.com/path/to/image/file,https://example-1.com/path/to/image/file</download-uri>
<image-verification>
<hash-algorithm> </hash-algorithm>
<hash-value>ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33</hash-value>
</image-verification>
</boot-image>
<configuration-handling>merge</configuration-handling>
<pre-upgrade-script>base64encodedvalue</pre-upgrade-script>
<configuration>base64encodedvalue</configuration>
<post-configuration-script>base64encodedvalue</post-configuration-script>
</onboarding-information>
=========================================
=============================
<onboarding-information>
<boot-image>
<os-name>Junos</os-name>
<os-version>22.2R1</os-version>
<download-uri>https://example.com/path/to/image/file,https://example-1.com/path/to/image/file</download-uri>
<image-verification>
<hash-algorithm> </hash-algorithm>
<hash-value>ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33</hash-value>
</image-verification>
</boot-image>
<configuration-handling>merge</configuration-handling>
<pre-upgrade-script>base64encodedvalue</pre-upgrade-script>
<pre-configuration-script>base64encodedvalue</pre-configuration-script>
<configuration>base64encodedvalue</configuration>
<post-configuration-script>base64encodedvalue</post-configuration-script>
</onboarding-information>
=========================================
構成後のスクリプト
事前設定スクリプトの要件は、設定後のスクリプトにも適用されます。設定後スクリプトが失敗した場合、デバイスは設定前スクリプトが実行される前に実行していた設定にロールバックします。SZTPプロセスが再起動します。
DHCP v4 オプション 143
DHCP クライアントに IP アドレスを提供できるようになる前に、DHCP サーバーで DHCP V4 オプション 143 を設定してください。
MXシリーズデバイスをDHCPサーバーとして使用する場合は、DHCP V4オプション143を有効にします。
以下に設定例を示します。
access {
address-assignment {
pool p1 {
family inet {
network 192.168.2.0/24;
range r1 {
low 192.168.2.2;
high 192.168.2.254;
}
dhcp-attributes {
maximum-lease-time 2419200;
server-identifier 192.168.2.1;
router {
192.168.2.1;
}
}
option 143 hex-string 001368747470733a2f2f6578616d706c652e636f6d;
}
}
}
DHCP v6 オプション 136
以下に設定例を示します。
access {
address-assignment {
neighbor-discovery-router-advertisement p2;
pool p2 {
family inet6 {
prefix 2001:db8:::/64;
range r1 {
low 2001:db8:::200/128;
high 2001:db8:::299/128;
}
dhcp-attributes {
dns-server {
2001:db8:::8888;
}
}
option 136 hex-string 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574;
}
}
}
16進形式からASCIIテキスト形式への変換
たとえば、DHCP V6 オプション 136 のこの 16 進数のテキスト文字列は、ASCII テキスト形式では 26 バイトに相当します。16進形式では、26は001aとして表されます。各 16 進数は 1 バイトに相当し、各バイトは ASCII 文字の組み合わせに相当します。
001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 16進文字列をASCII文字に変換するには、16進文字と数字をASCII文字、数字、および記号にマッピングする必要があります。
この例では、DHCP オプション 136 に使用する URL をマッピングしています。DHCP オプション 143 で使用する URL にも同じプロセスを使用できます。
16進形式とASCII形式間のマッピングを示すURLの例を次に示します。各 16 進数が ASCII 形式の文字と記号にマッピングされていることがわかります。
68(h) 74(t) 74(t) 70(p) 73(s) 3A(:) 2F(/) 2F(/) 61(a) 62(b) 2D(-) 63(c) 64(d) 65(e) 2D(-) 73(s) 65(e) 72(r) 76(v) 65(e) 72(r) 36(.) 2E (n)6E 65(e) 74(t)
最終URLは https://ab-cde-server.net.
16進数からASCIIへのコンバーター、またはその逆を使用して、結果が正しいことを確認します。
SZTPワークフロー
デバイスがまだ工場出荷時のデフォルト状態になっていない場合は、次のいずれかのコマンドを発行してデバイスを工場出荷時のデフォルト状態にします。
Junos OSを実行しているネットワークデバイスで、
request vmhost zeroizeコマンドを発行します。Junos OS Evolvedを実行しているネットワークデバイスの場合は、
request system zeroizeコマンドを発行します。
デバイスが工場出荷時のデフォルト状態で起動すると、以下のイベントが発生します。
DHCP クライアントは、ブートストラップ サーバーまたはカスタマー リダイレクト サーバーの名前、IP アドレス、またはホスト名を取得するリクエストを DHCP サーバーに送信します。
V4にはDHCPオプション143、V6にはDHCPオプション136のいずれかを設定します。DHCP クライアントは、デバイスがブートストラップを完了するまで、各ブートストラップまたはリダイレクト サーバーの IP アドレスを要求します。
DHCP サーバーは、ブートストラップ サーバーまたはカスタマー リダイレクト サーバーのサーバー ホスト名を DHCP クライアントに送信します。
デバイス上の電話ホームクライアント(PHC)は、DHCP オプションから学習したサーバーにブートストラップ要求を送信します。DHCP オプションで複数のサーバーを指定した場合、デバイスは各サーバーとのブートストラップを順次試みます。
デバイスは、PHCがDHCPオプションを通じて学習したブートストラップ、カスタマーリダイレクト、またはDNSサーバーでブートストラップを試みます。デバイスは、正常にブートストラップするまで、ラウンドロビン方式でサーバーへのブートストラップを試みます。
ブートストラップサーバーは、署名されたオンボーディング情報とともに、所有者証明書および所有権バウチャーを返します。
- PHCは、所有者証明書と所有権バウチャーの情報を使用して、署名されたオンボーディング情報を確認します。
(オプション)PHCは、オンボーディング情報の一部として提供されたアップグレード前のスクリプトを実行します。
PHCは、画像と設定情報を抽出します。
デバイスが別のイメージを実行している場合、デバイスはイメージをダウンロードし、新しいイメージを使用してアップグレードした後、新しいイメージで再起動します。
再起動後、必要なイメージがすでにあるためデバイスが再起動しないことを除いて、SZTPシーケンス全体が繰り返されます。
(オプション)PHCが事前設定スクリプトを実行します。
SZTPは、BourneおよびPythonスクリプトをサポートします。
RFC 8572に従って、設定前スクリプトと設定後スクリプトのXMLタグ値をエンコードします。
PHCが設定をコミットします。
(オプション)PHCは、設定後のスクリプトを実行します。
PHCは、ブートストラップ完了メッセージをPHSに送信します。
デバイスは、PHC 関連の設定とリソースをクリーンアップします。
PHCは終了します。
スクリプトタイプ |
インタープリターパス |
プラットフォームのサポート |
|---|---|---|
シェルスクリプト |
|
すべてのネットワークデバイス |
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プロセス中に挿入されたときに、バックアップルーティングエンジンが存在する場合。
バックアップのルーティングエンジンが再起動したとき、または交換されたとき。
プライマリルーティングエンジンがバックアップルーティングエンジンの真正性を検証し、プロビジョニングの要件を満たした後、プライマリルーティングエンジンはバックアップルーティングエンジンで実行されているソフトウェアのバージョンを確認します。バックアップルーティングエンジンのソフトウェアバージョンがプライマリルーティングエンジンのソフトウェアバージョンと異なる場合、プライマリルーティングエンジンはバックアップルーティングエンジンをプライマリルーティングエンジンが実行しているのと同じソフトウェアバージョンにアップグレードします。
両方のルーティングエンジンが同じソフトウェアを実行している場合、プライマリルーティングエンジンはバックアップルーティングエンジンと設定を同期します。