Sichere Zero-Touch-Bereitstellung
Um zu sehen, welche Plattformen Secure Zero Touch Provisioning (SZTP) unterstützen, wechseln Sie zum Feature-Explorer. Wählen Sie auf der Seite Feature-Explorer im Abschnitt Features erkunden die Option Alle Features aus. Wählen Sie im Feld Features gruppiert nach Featurefamilie die Option Secure ZTP aus. Sie können auch den Namen des Features in das Bearbeitungsfeld Features suchen eingeben. Weitere Informationen dazu, wie die ZTP-Unterstützung erweitert wurde, finden Sie in der Tabelle mit dem Versionsverlauf am Ende dieses Themas.
Überblick
Der Phone-Home-Client (PHC)-Prozess unterstützt Secure Zero Touch Provisioning (SZTP).
Sie können RFC-8572-basiertes SZTP verwenden, um entfernte Netzwerkgeräte zu booten, die sich in einem werkseitigen Standardzustand befinden. SZTP ermöglicht die gegenseitige Authentifizierung zwischen dem Bootstrap-Server und dem Netzwerkgerät vor der Bereitstellung des Remote-Netzwerkgeräts.
Um die gegenseitige Authentifizierung zu aktivieren, benötigen Sie einen eindeutigen digitalen Gutschein und ein mit DevID (Digital Device ID oder Cryptographic Digital Identity) programmiertes Netzwerkgerät. Die DevID ist in den TPM 2.0-Chip (Trusted Platform Module) des Netzwerkgeräts eingebettet. Juniper Networks stellt Kunden für jedes teilnahmeberechtigte Netzwerkgerät einen digitalen Gutschein aus.
Wir unterstützen SZTP auf Management- und WAN-Schnittstellen.
Das DHCP-basierte Legacy-ZTP ist deaktiviert. Wir unterstützen kein DHCP-basiertes Legacy-ZTP auf Hardware, die SZTP unterstützt.
SZTP ist RFC 8572-konform und erfordert die folgende Infrastruktur, um die Identität und Authentizität Ihrer Netzwerkgeräte sicherzustellen:
Trusted Platform Module (TPM) 2.0
Digitale Geräte-IDs (DevIDs)
DevID-Zertifikate
X.509 Angeheftete Domänenzertifikate (PDCs)
Zertifikate des Eigentümers
DevID-Vertrauensanker
Gutscheine
Informationen zum Generieren von Gutscheinen finden Sie unter Gutscheinzertifikat generieren.
Informationen zum Onboarding Ihrer Juniper Geräte mit Secure ZTP finden Sie in der Schnellstartanleitung für Secure ZTP.
Vorteile
Sie können ein Remote-Netzwerkgerät ohne manuelle Eingriffe Bereitstellung.
Sie können ein Netzwerkgerät sicher von einem zentralen Speicherort aus Bereitstellung, sodass verhindert wird, dass Unbefugte die Kontrolle über Ihr Netzwerkgerät übernehmen.
Ihre Umleitungs- und Bootstrap-Server überprüfen die Authentizität Ihres Netzwerkgeräts anhand der DevID, die im TPM des Netzwerkgeräts programmiert ist.
Ihr Netzwerkgerät überprüft die Authentizität Ihrer Umleitungsserver und Bootstrap-Server sowie der Bootstrap-Informationen anhand der Gerätebelege.
Anwendungsszenario
Netzwerkgeräte, die ab Werk ausgeliefert werden, können Sie die Netzwerkgeräte sowohl sicher als auch remote in Betrieb nehmen, ohne das Netzwerkgerät manuell zu berühren. Das Netzwerkgerät muss in der Lage sein, das Dynamic Host Configuration Protocol (DHCP) zu verwenden, um Netzwerkverbindungsinformationen zu erhalten und eine Verbindung zu einem Remote-Bootstrap-Server herzustellen.
SZTP-Anforderungen
Um SZTP in Ihrem Netzwerk bereitzustellen, müssen Sie die folgenden Aufgaben ausführen:
Stellen Sie Ihre DHCP- und DNS-Server bereit.
Konfigurieren Sie DHCP V4 Option 143 oder DHCP V6 Option 136 auf Ihrem DHCP-Server, damit der DHCP-Server die Namen Ihrer Umleitungs- und Bootstrap-Server ankündigen kann.
Stellen Sie Ihre Umleitungs- und Bootstrap-Server bereit.
Erwerben Sie DevID-Vertrauensanker von Juniper Networks.
Generieren von Besitzerzertifikaten für ein Netzwerkgerät oder eine Gruppe von Netzwerkgeräten.
Generieren Sie angeheftete Domänenzertifikate (PDCs) für jede Netzwerkdomäne.
Erwerben Sie Gutscheine von Juniper Networks.
Generieren Sie Umleitungs- und Bootstrap-Informationen für jedes Netzwerkgerät.
Verwenden Sie die Umleitungs- und Bootstrap-Informationen, die die Umleitungs- und Bootstrap-Server bereitstellen, um Ihre Netzwerkgeräte zu Bereitstellung.
Nachdem Sie SZTP in Ihrem Netzwerk und dann ein neues Netzwerkgerät bereitgestellt haben, wird das Netzwerkgerät automatisch gestartet.
SZTP-Infrastrukturkomponenten
- Trusted Platform Module (TPM) 2.0
- DevIDs
- DevID-Zertifikate
- X.509 Angeheftete Domänenzertifikate (PDCs)
- Zertifikate des Eigentümers
- DevID-Vertrauensanker
- Gutschein-Zertifikate
Trusted Platform Module (TPM) 2.0
Das TPM ist ein Mikrochip, der sicherheitsrelevante Funktionen bereitstellt. Während des Herstellungsprozesses programmiert Juniper Networks das TPM mit einer digitalen Geräte-ID (DevID) und einem asymmetrischen Schlüsselpaar (öffentlicher Schlüssel und privater Schlüssel). Das TPM sperrt den privaten Schlüssel des asymmetrischen Paares an einem manipulationssicheren Ort.
DevIDs
Die DevID entspricht dem privaten Schlüssel und schützt den privaten Schlüssel. Anwendungen, die eine Signatur oder Verschlüsselung erfordern, verwenden den privaten DevID-Schlüssel.
Anwendungen, die auf Ihrem Netzwerkgerät ausgeführt werden, verwenden den privaten DevID-Schlüssel im TPM des Netzwerkgeräts, um die Identität des Netzwerkgeräts gegenüber einer Remoteüberprüfung nachzuweisen.
DevID-Zertifikate
Juniper Networks generiert ein DevID-Zertifikat (X.509-Zertifikat) für den öffentlichen Schlüssel, das der DevID des privaten Schlüssels entspricht. Das DevID-Zertifikat enthält die Seriennummer des Netzwerkgeräts, für das die DevID erstellt wurde. Das DevID-Zertifikat wird in Übereinstimmung mit dem IEEE 802.1AR-Standard generiert.
X.509 Angeheftete Domänenzertifikate (PDCs)
Erstellen Sie für jede Netzwerkdomäne ein X.509-Domänenzertifikat (PDC). Das PDC kann entweder ein Root-CA-Zertifikat oder ein Zwischenzertifikat der CA sein. Konvertieren Sie den PDC von Distinguished Encoding Rules (DER) in Base 64-Codierung. Stellen Sie sicher, dass der PDC eine Zertifizierungsstelle (CA) ist und X.509-konform ist.
Zertifikate des Eigentümers
Das Besitzerzertifikat verifiziert den Anbieter, der das Netzwerkgerät gekauft hat oder besitzt. Generieren Sie ein asymmetrisches Schlüsselpaar (öffentlicher Schlüssel und privater Schlüssel) für jedes Netzwerkgerät oder jede Gruppe von Netzwerkgeräten. Das Schlüsselpaar muss entweder Rivest-Shamir-Adleman (RSA) oder Elliptic Curve Cryptography (ECC) verwenden. Bewahren Sie den privaten Schlüssel geschützt an einem sicheren Ort auf. Das angeheftete Domänenzertifikat (PDC) sollte die CA für das Besitzerzertifikat sein.
DevID-Vertrauensanker
Juniper Networks stellt DevID-Vertrauensanker bereit. Installieren Sie die DevID-Vertrauensanker in Umleitungs- und Bootstrapservern, um das DevID-Zertifikat zu überprüfen, das das Gerät oder der Client beim Einrichten einer TLS-Sitzung vorlegt.
Gutschein-Zertifikate
Um Gutscheinzertifikate zu erhalten, geben Sie im Juniper Agile Licensing (JAL) Portal den PDC und die Seriennummer des Netzwerkgeräts ein. Sobald Sie die Gutscheinzertifikate erhalten haben, fügen Sie sie als Teil der Bootstrap-Informationen auf Ihrem Bootstrap-Server hinzu. Der Bootstrap-Server stellt die Gutscheinzertifikate für Ihre Netzwerkgeräte bereit. Ihre Netzwerkgeräte verwenden dann die Bootstrap-Informationen, um die Vertrauensanker zu überprüfen, die Ihr Umleitungsserver bereitstellt.
Eine Schritt-für-Schritt-Anleitung zum Erhalt von Gutscheinen finden Sie unter Gutscheinzertifikat generieren.
DevID-Workflow
Wenn eine Anwendung eine Signatur oder Verschlüsselung erfordert, die die DevID verwendet, fordert die Anwendung eine TLS-Sitzung mit dem Bootstrap-Server an.
- Der Bootstrap-Server sendet eine TLS-Antwort an das Netzwerkgerät, in der das Netzwerkgerät aufgefordert wird, Folgendes zu tun:
- Bereitstellung des DevID-Zertifikats
- Nachweisen, dass es einen privaten Schlüssel hat
Das Netzwerkgerät signiert die Sitzungsdaten mit der DevID des privaten Schlüssels.
Das Netzwerkgerät sendet die digitale Signatur und das DevID-Zertifikat an den Bootstrap-Server.
- Der Bootstrap-Server verwendet das DevID-Zertifikat, um die digitale Signatur zu überprüfen.
Der Bootstrap-Server verwendet den DevID-Vertrauensanker, den Juniper Networks zur Überprüfung des DevID-Zertifikats bereitstellt.
Informationen zum Onboarding
Damit ein Netzwerkgerät sich selbst booten und sichere Verbindungen mit anderen Systemen aufbauen kann, müssen Sie Onboarding-Informationen bereitstellen. Onboarding-Informationen sind Daten, die ein Netzwerkgerät verwendet, um sich selbst zu booten und mit anderen Systemen zu verbinden. Wenn ein Netzwerkgerät diese Daten sendet, müssen die Daten in einem Format codiert werden, das RFC 8572 entspricht.
- Informationen zum Start-Image
- URI herunterladen
- Bild-Verifizierung
- Handhabung der Konfiguration
- Skripte vor der Konfiguration
- Skripte nach der Konfiguration
Informationen zum Start-Image
Zu den Startimageinformationen gehören der Name des Betriebssystems und die Betriebssystemversion. Wir empfehlen, dass Sie "Junos" als Betriebssystemversion angeben. Stellen Sie sicher, dass Sie die richtige Betriebssystemversion angeben, um zu verhindern, dass das Netzwerkgerät kontinuierlich Software herunterlädt und installiert.
URI herunterladen
Der Download-URI gibt den Speicherort des Startimages an.
Bild-Verifizierung
Das Feld "Imageüberprüfung" enthält den Hashalgorithmus, den Sie zum Generieren eines sicheren Hashs für das Softwareimage verwenden, sowie den Digestwert des Softwareimages. SZTP unterstützt SHA256. Codieren Sie den Digestwert als hexadezimale Zeichenfolge.
Handhabung der Konfiguration
SZTP kann eine Konfiguration entweder zusammenführen oder ersetzen. Erstellen Sie die Konfiguration in XML, und codieren Sie die Konfiguration im Base-64-Format. Die Konfiguration muss im Base-64-Format vorliegen, damit der Bootstrap-Server sie in seine Bootstrap-Informationen aufnehmen kann.
Skripte vor der Konfiguration
SZTP unterstützt Bourne-Shell-Skripte und Python-Skripte. Der Bourne-Shell-Skript-Interpreterpfad ist #!/bin/sh und der Python-Interpreterpfad ist #!/usr/bin/python.
Wenn es sich bei dem Skript um ein Bourne-Skript handelt, prüft SZTP den Endwert des Skripts. Wenn das Skript mit einem Wert ungleich Null beendet wird, wird der SZTP-Prozess neu gestartet. Wenn es sich bei dem Skript um ein Python-Skript handelt, überprüft SZTP den Endwert des Skripts nicht. Die Ausgabe eines Skripts konnte Fehler enthalten, selbst wenn das Skript erfolgreich ausgeführt wurde.
Hier ist ein Beispiel für die Onboarding-Informationen in 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>
=========================================
Skripte nach der Konfiguration
Die Anforderungen an Skripts vor der Konfiguration gelten auch für Skripte nach der Konfiguration. Wenn ein Skript nach der Konfiguration fehlschlägt, setzt Ihr Gerät auf die Konfiguration zurück, die es vor der Ausführung des Skripts vor der Konfiguration ausgeführt hat. Der SZTP-Prozess wird neu gestartet.
DHCP V4 Option 143
Konfigurieren Sie DHCP V4 Option 143 auf Ihrem DHCP-Server, bevor IP-Adressen für den DHCP-Client bereitgestellt werden können.
Wenn Sie ein Gerät der MX-Serie als DHCP-Server verwenden, aktivieren Sie DHCP V4 Option 143.
Hier ist eine Beispielkonfiguration:
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 Option 136
Hier ist eine Beispielkonfiguration:
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;
}
}
}
Konvertieren des Hexadezimalformats in das ASCII-Textformat
Diese hexadezimale Textzeichenfolge in der DHCP V6-Option 136 entspricht beispielsweise 26 Byte im ASCII-Textformat. Im Hexadezimalformat wird 26 als 001a dargestellt. Jede Hexadezimalzahl entspricht einem Byte, und jedes Byte entspricht einer Kombination von ASCII-Zeichen.
Um die 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 Hexadezimalzeichenfolge in ASCII-Zeichen zu konvertieren, müssen Sie die Hexadezimalbuchstaben und -zahlen ASCII-Buchstaben, -Zahlen und -Symbolen zuordnen.
In diesem Beispiel ordnen wir die URL zu, die für DHCP-Option 136 verwendet wird. Sie können den gleichen Prozess für die URL verwenden, die in DHCP-Option 143 verwendet wird.
Hier ist eine Beispiel-URL, die die Zuordnung zwischen dem hexadezimalen Format und dem ASCII-Format zeigt. Sie können sehen, dass jede Hexadezimalzahl Buchstaben und Symbolen im ASCII-Format zugeordnet ist:
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)
Die endgültige URL lautet https://ab-cde-server.net.
Verwenden Sie einen Hexadezimal-ASCII-Konverter und umgekehrt, um sicherzustellen, dass Ihre Ergebnisse korrekt sind.
SZTP-Workflow
Wenn sich Ihr Gerät noch nicht in einem werkseitigen Standardzustand befindet, führen Sie einen der folgenden Befehle aus, um Ihr Gerät in den werkseitigen Standardzustand zu versetzen.
Geben Sie auf Netzwerkgeräten mit Junos OS den
request vmhost zeroizeBefehl ein.Geben Sie für Netzwerkgeräte mit Junos OS Evolved den
request system zeroizeBefehl ein.
Wenn ein Gerät in einem werkseitigen Standardzustand gestartet wird, treten die folgenden Ereignisse auf.
Der DHCP-Client sendet eine Anforderung an den DHCP-Server, um den Namen, die IP-Adresse oder den Hostnamen des Bootstrap-Servers oder des Kundenumleitungsservers abzurufen.
Konfigurieren Sie entweder die DHCP-Option 143 für V4 oder die DHCP-Option 136 für V6. Der DHCP-Client fordert die IP-Adresse für jeden Bootstrap- oder Umleitungsserver an, bis das Gerät das Bootstrapping abgeschlossen hat.
Der DHCP-Server sendet den Serverhostnamen eines Bootstrap- oder eines Kundenumleitungsservers an den DHCP-Client.
Der Phone-Home-Client (PHC) auf Ihrem Gerät sendet eine Bootstrap-Anfrage an den Server, den er von der DHCP-Option gelernt hat. Wenn Sie mehrere Server in der DHCP-Option angegeben haben, versucht das Gerät, mit jedem Server nacheinander zu booten.
Das Gerät versucht, mit einem beliebigen Bootstrap-, Kundenumleitungs- oder DNS-Server zu bootstrappen, den der PHC über die DHCP-Option lernt. Das Gerät versucht, im Roundrobinverfahren zu einem Server zu booten, bis das Gerät erfolgreich gestartet wurde.
Der Bootstrap-Server antwortet mit signierten Onboarding-Informationen zusammen mit dem Besitzerzertifikat und dem Eigentumsnachweis.
- Das PHC verwendet die Informationen im Besitzerzertifikat und im Besitznachweis, um die signierten Onboardinginformationen zu überprüfen.
Der PHC extrahiert Bild- und Konfigurationsinformationen.
Wenn auf dem Gerät ein anderes Image ausgeführt wird, lädt das Gerät das Image herunter, verwendet das neue Image für das Upgrade und startet dann mit dem neuen Image neu.
Nach dem Neustart wird die gesamte SZTP-Sequenz wiederholt, mit der Ausnahme, dass das Gerät nicht neu gestartet wird, da es bereits über das erforderliche Image verfügt.
Der PHC führt einen Commit für die Konfiguration durch.
(Optional) Das PHC führt Skripts nach der Konfiguration aus.
Das PHC sendet eine Bootstrap-Abschlussnachricht an das PHS.
Das Gerät bereinigt die PHC-bezogenen Konfigurationen und Ressourcen.
Das PHC wird beendet.
Skript-Typ |
Pfad des Interpreters |
Plattform-Support |
|---|---|---|
Shell-Skript |
|
Alle Netzwerkgeräte |
Python-Skript |
|
Netzwerkgeräte mit Junos OS mit verbesserter Automatisierung Netzwerkgeräte mit Junos OS Evolved |
SZTP für Netzwerkgeräte mit Dual-Routing-Engines
Bevor Sie die Software auf der Backup-Routing-Engine auf einem Netzwerkgerät aktualisieren, auf dem Junos OS-Software ausgeführt wird, aktivieren Sie die secure-ztp provision-backup-re Anweisung in der [edit system] Hierarchie auf der primären Routing-Engine
Aktivieren Sie auf Netzwerkgeräten, auf denen Junos OS-Software ausgeführt wird, die provision-backup-re Anweisung in der [edit system] Hierarchie auf der primären Routing-Engine, damit die Backup-Routing-Engine gebootet werden kann.
Aktivieren Sie auf Netzwerkgeräten, auf denen Junos OS Evolved-Software ausgeführt wird, die auto-sw-sync Anweisung in der [edit system] Hierarchie, sodass die primäre Routing-Engine durch ein Upgrade oder Downgrade sicherstellt, dass sich dieselbe Image-Version auf der Backup-Routing-Engine befindet.
Auf Junos OS-basierten Systemen mit dualen Routing-Engines lädt die primäre Routing-Engine das Image auch dann herunter, wenn auf der primären Routing-Engine bereits die erforderliche Image-Version ausgeführt wird. Das Gerät lädt das Image herunter, sodass die primäre Routing-Engine bereit ist, die Backup-Routing-Engine bei Bedarf zu aktualisieren.
Auf Systemen mit Junos OS Evolved speichert die primäre Routing-Engine immer eine Kopie des aktuellen Images.
Wenn Sie die synchronize Anweisung in der [edit system] Hierarchie oder den Graceful Restart Engine Switchover (GRES) auf der primären Routing-Engine nicht aktiviert haben, synchronisiert die primäre Routing-Engine die Konfiguration und den Status nicht mit der Backup-Routing-Engine. In diesem Fall überprüft die primäre Routing-Engine die Authentizität der Backup-Routing-Engine, bevor sie Daten mit der Backup-Routing-Engine synchronisiert.
Bevor die primäre Routing-Engine die Backup-Routing-Engine bereitstellt, überprüft die primäre Routing-Engine die Authentizität der Backup-Routing-Engine. Die primäre Routing-Engine überprüft die DevID der Backup-Routing-Engine, um sicherzustellen, dass die Backup-Routing-Engine eine von Juniper autorisierte Routing-Engine ist.
Die primäre Routing-Engine prüft nicht, ob die Backup-Routing-Engine berechtigt ist, Informationen von der primären Routing-Engine zu empfangen. Außerdem überprüft die Backup-Routing-Engine nicht die Authentizität oder Autorisierung der primären Routing-Engine.
Die primäre Routing-Engine stellt die Backup-Routing-Engine in den folgenden Situationen bereit:
Wenn die primäre Routing-Engine mit SZTP gebootet wurde.
Wenn die Backup-Routing-Engine vorhanden ist, wenn die primäre Routing-Engine bootstrappt oder während des SZTP-Prozesses eingefügt wird.
Wenn die Backup-Routing-Engine neu gestartet oder ersetzt wird.
Sobald die primäre Routing-Engine die Authentizität der Backup-Routing-Engine überprüft und die Anforderungen für die Bereitstellung erfüllt hat, überprüft die primäre Routing-Engine die Version der Software, die auf der Backup-Routing-Engine ausgeführt wird. Wenn sich die Softwareversion der Backup-Routing-Engine von der Softwareversion der primären Routing-Engine unterscheidet, aktualisiert die primäre Routing-Engine die Backup-Routing-Engine auf dieselbe Softwareversion, die auf der primären Routing-Engine ausgeführt wird.
Wenn auf beiden Routing-Engines dieselbe Software ausgeführt wird, synchronisiert die primäre Routing-Engine ihre Konfiguration mit der Backup-Routing-Engine.