Sichere vollständig automatisierte Bereitstellung
Um zu sehen, welche Plattformen Secure Zero Touch Provisioning (SZTP) unterstützen, wechseln Sie zum Funktions-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 Feature-Familie die Option Secure ZTP aus. Sie können auch den Namen des Features in das Bearbeitungsfeld Nach Features suchen eingeben. In der Tabelle mit dem Versionsverlauf am Ende dieses Themas finden Sie weitere Informationen darüber, wie die ZTP-Unterstützung erweitert wurde.
Ü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, die sich in einem werkseitigen Standardzustand befinden, zu bootstrappen. 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 ermöglichen, benötigen Sie einen eindeutigen digitalen Gutschein und ein DevID-programmiertes Netzwerkgerät (Digital Device ID oder Cryptographic Digital Identity). Die DevID ist in den TPM 2.0-Chip (Trusted Platform Module) auf dem Netzwerkgerät eingebettet. Juniper Networks stellt Kunden für jedes teilnahmeberechtigte Netzwerkgerät einen digitalen Gutschein aus.
Wir unterstützen SZTP auf Verwaltungs- und WAN-Schnittstellen.
DHCP-basiertes Legacy-ZTP ist deaktiviert. DHCP-basiertes Legacy-ZTP wird auf Hardware, die SZTP unterstützt, nicht unterstützt.
SZTP ist konform mit RFC 8572 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-Zertifikate für angeheftete Domänen (PDCs)
Zertifikate des Eigentümers
DevID-Vertrauensanker
Belege
Informationen zum Generieren von Gutscheinen finden Sie unter Gutscheinzertifikat generieren.
Informationen zum Onboarding Ihrer Juniper Geräte mit Secure ZTP finden Sie in der Kurzanleitung für sicheres ZTP.
Nützt
Sie können ein Remote-Netzwerkgerät ohne manuelle Eingriffe bereitstellen.
Sie können ein Netzwerkgerät sicher von einem zentralen Standort aus bereitstellen, wodurch verhindert wird, dass nicht autorisierte Entitäten die Kontrolle über Ihr Netzwerkgerät übernehmen.
Ihre Umleitungs- und Bootstrapserver überprüfen die Authentizität Ihres Netzwerkgeräts basierend auf der DevID, die im TPM des Netzwerkgeräts programmiert ist.
Ihr Netzwerkgerät überprüft die Authentizität Ihrer Umleitungsserver und Bootstrap-Server sowie die Bootstrap-Informationen basierend auf den Gutscheinen der Geräte.
Anwendungsfall
Bei Netzwerkgeräten, die ab Werk ausgeliefert werden, können Sie die Netzwerkgeräte sowohl sicher als auch remote betriebsbereit machen, ohne das Netzwerkgerät manuell berühren zu müssen. Das Netzwerkgerät muss in der Lage sein, DHCP (Dynamic Host Configuration Protocol) zu verwenden, um Netzwerkkonnektivitätsinformationen abzurufen 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 Sie Besitzerzertifikate 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 von den Umleitungs- und Bootstrap-Servern bereitgestellt werden, um Ihre Netzwerkgeräte bereitzustellen.
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-Zertifikate für angeheftete Domänen (PDCs)
- Zertifikate des Eigentümers
- DevID-Vertrauensanker
- Gutschein-Gutscheine
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 (Public Key und Private Key). Das TPM sperrt den privaten Schlüssel des asymmetrischen Paars 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 gemäß dem Standard IEEE 802.1AR generiert.
X.509-Zertifikate für angeheftete Domänen (PDCs)
Erstellen Sie für jede Netzwerkdomäne ein X.509-Zertifikat für angeheftete Domänen (PDC). Bei dem PDC kann es sich entweder um ein Zertifikat der Stammzertifizierungsstelle oder um ein Zwischenzertifizierungsstellenzertifikat handeln. Konvertieren Sie den PDC von Distinguished Encoding Rules (DER) in die Base-64-Codierung. Stellen Sie sicher, dass es sich bei der PDC um eine Zertifizierungsstelle (Certificate Authority, CA) handelt, die X.509-konform ist.
Zertifikate des Eigentümers
Mit dem Besitzerzertifikat wird der Anbieter überprüft, 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-Kryptografie (RSA) oder Elliptic-Curve-Kryptografie (ECC) verwenden. Bewahren Sie den privaten Schlüssel geschützt an einem sicheren Ort auf. Das angeheftete Domänenzertifikat (PDC) sollte die Zertifizierungsstelle für das Besitzerzertifikat sein.
DevID-Vertrauensanker
Juniper Networks stellt DevID-Vertrauensanker bereit. Installieren Sie die DevID-Vertrauensanker auf Umleitungs- und Bootstrapservern, um das DevID-Zertifikat zu überprüfen, das das Gerät oder der Client beim Einrichten einer TLS-Sitzung vorlegt.
Gutschein-Gutscheine
Um Gutscheine zu erhalten, geben Sie den PDC und die Seriennummer des Netzwerkgeräts im Juniper Agile Licensing (JAL) Portal 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 Bootstrapserver an.
- Der Bootstrap-Server sendet eine TLS-Antwort an das Netzwerkgerät, in der das Netzwerkgerät aufgefordert wird, Folgendes zu tun:
- Bereitstellen des DevID-Zertifikats
- Weisen Sie nach, dass es über einen privaten Schlüssel verfügt
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.
Onboarding-Informationen
Damit ein Netzwerkgerät sich selbst booten und sichere Verbindungen zu anderen Systemen herstellen kann, müssen Sie Onboarding-Informationen bereitstellen. Onboarding-Informationen sind Daten, die ein Netzwerkgerät verwendet, um sich selbst zu booten und eine Verbindung zu anderen Systemen herzustellen. Wenn ein Netzwerkgerät diese Daten sendet, müssen die Daten in einem Format codiert werden, das RFC 8572 entspricht.
- Boot-Image-Informationen
- URI herunterladen
- Bild-Verifizierung
- Konfigurationshandhabung
- Vorkonfigurationsskripte
- Skripte nach der Konfiguration
Boot-Image-Informationen
Zu den Startabbildinformationen gehören der Name des Betriebssystems und die Betriebssystemversion. Es wird empfohlen, "Junos" als Betriebssystemversion anzugeben. Stellen Sie sicher, dass Sie die richtige Betriebssystemversion angeben, um zu verhindern, dass das Netzwerkgerät ständig Software herunterlädt und installiert.
URI herunterladen
Der Download-URI gibt den Speicherort des Startabbilds an.
Bild-Verifizierung
Das Feld "Image-Überprüfung" enthält den Hash-Algorithmus, mit dem Sie einen sicheren Hash für das Software-Image generieren, sowie den Digest-Wert des Software-Images. SZTP unterstützt SHA256. Codieren Sie den Digestwert als hexadezimale Zeichenfolge.
Konfigurationshandhabung
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.
Vorkonfigurationsskripte
SZTP unterstützt Bourne-Shell-Skripte und Python-Skripte. Der Bourne-Shell-Skript-Interpreter-Pfad ist #!/bin/sh und der Python-Interpreter-Pfad #!/usr/bin/python.
Wenn es sich bei dem Skript um ein Bourne-Skript handelt, überprü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 kann Fehler enthalten, auch 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 das Vorkonfigurationsskript gelten auch für Skripts 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 Vorkonfigurationsskripts ausgeführt hat. Der SZTP-Prozess wird neu gestartet.
DHCP v4 Option 143
Konfigurieren Sie die DHCP V4-Option 143 auf Ihrem DHCP-Server, bevor er dem DHCP-Client IP-Adressen zur Verfügung stellen kann.
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 135
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 135 hex-string 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574;
}
}
}
Konvertieren des Hexadezimalformats in das ASCII-Textformat
Diese hexadezimale Textzeichenfolge in der DHCP V6 Option 135 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 hexadezimale Zeichenfolge in ASCII-Zeichen zu konvertieren, müssen Sie die hexadezimalen Buchstaben und Zahlen ASCII-Buchstaben, Zahlen und Symbolen zuordnen.
In diesem Beispiel ordnen wir die URL zu, die für die DHCP-Option 135 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 Hexadezimalformat 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 finale 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 im Werkszustand befindet, geben Sie einen der folgenden Befehle aus, um es in den werkseitigen Standardzustand zu versetzen.
Geben Sie den
request vmhost zeroizeBefehl auf Netzwerkgeräten aus, auf denen Junos OS ausgeführt wird.Geben Sie für Netzwerkgeräte, auf denen Junos OS Evolved ausgeführt wird, den Befehl
request system zeroizeein.
Wenn ein Gerät im Werkszustand 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 135 für V6. Der DHCP-Client fordert die IP-Adresse für jeden Bootstrap- oder Umleitungsserver an, bis das Gerät den 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 über die 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 jedem Bootstrap, jeder Kundenumleitung oder jedem DNS-Server, den der PHC über die DHCP-Option lernt, ein Bootstrapping durchzuführen. Das Gerät versucht, im Round-Robin-Verfahren eine Bootstrapping-Verbindung zu einem Server herzustellen, bis das Gerät erfolgreich gebootet wird.
Der Bootstrap-Server antwortet mit signierten Onboarding-Informationen zusammen mit dem Besitzerzertifikat und dem Eigentumsgutschein.
- Der PHC verwendet die Informationen im Besitzerzertifikat und im Eigentumsgutschein, um die unterzeichneten Onboarding-Informationen zu überprüfen.
Der PHC extrahiert Image- und Konfigurationsinformationen.
Wenn auf dem Gerät ein anderes Abbild ausgeführt wird, lädt das Gerät das Abbild herunter, verwendet das neue Abbild zum Aktualisieren und startet dann mit dem neuen Abbild 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 übergibt die Konfiguration.
(Optional) Der PHC führt Skripte nach der Konfiguration aus.
Der PHC sendet eine Bootstrap-Complete-Nachricht an den PHS.
Das Gerät bereinigt die PHC-bezogenen Konfigurationen und Ressourcen.
Der PHC wird beendet.
Skripttyp |
Interpreter-Pfad |
Unterstützte Plattformen |
|---|---|---|
Shell-Skript |
|
Alle Netzwerkgeräte |
Python-Skript |
|
Netzwerkgeräte, auf denen Junos OS mit erweiterter Automatisierung ausgeführt wird Netzwerkgeräte, auf denen Junos OS Evolved ausgeführt wird |
SZTP für Netzwerkgeräte mit dualen 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 bei Bedarf ein Upgrade der Backup-Routing-Engine durchführen kann.
Auf Junos OS Evolved-basierten Systemen speichert die primäre Routing-Engine immer eine Kopie des ausgeführten Images.
Wenn Sie die synchronize Anweisung in der [edit system] Hierarchie oder GRES (Graceful Restart Engine Switchover) 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 Daten mit der Backup-Routing-Engine synchronisiert werden.
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 es sich bei der Backup-Routing-Engine um eine von Juniper autorisierte Routing-Engine handelt.
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 ein Bootstrapping mit SZTP durchgeführt hat.
Wenn die Backup-Routing-Engine vorhanden ist, wenn die primäre Routing-Engine während des SZTP-Prozesses gestartet oder 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, auf der die primäre 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.