Zero-Touch Provisioning sécurisé
Pour savoir quelles plateformes prennent en charge le Zero-Touch Provisioning sécurisé (SZTP), accédez à l’explorateur de fonctionnalités. Dans la section Explorer les entités de la page Explorateur d’entités, sélectionnez Toutes les entités. Dans la zone Fonctionnalités regroupées par famille de fonctionnalités , sélectionnez Sécuriser ZTP. Vous pouvez également saisir le nom de l’entité dans la zone d’édition Rechercher des entités . Consultez le tableau Historique des versions à la fin de cette rubrique pour plus de détails sur l’évolution de la prise en charge de ZTP.
Vue d’ensemble
Le processus de client téléphonique à domicile (PHC) prend en charge le Zero-Touch Provisioning sécurisé (SZTP).
Vous pouvez utiliser le SZTP basé sur RFC-8572 pour démarrer des périphériques réseau distants qui sont dans un état d’usine par défaut. SZTP permet l’authentification mutuelle entre le serveur d’amorçage et l’équipement réseau avant de provisionner l’équipement réseau distant.
Pour activer l’authentification mutuelle, vous avez besoin d’un bon numérique unique et d’un équipement réseau programmé DevID (Digital Device ID ou Cryptographic Digital Identity). Le DevID est intégré à la puce Trusted Platform Module (TPM) 2.0 de l’équipement réseau. Juniper Networks émet un bon d’achat numérique aux clients pour chaque équipement réseau éligible.
Nous prenons en charge SZTP sur les interfaces de gestion et de WAN.
L’ancien ZTP basé sur DHCP est désactivé. Nous ne prenons pas en charge le ZTP hérité basé sur DHCP sur le matériel qui prend en charge SZTP.
SZTP est conforme à la norme RFC 8572 et nécessite l’infrastructure suivante pour garantir l’identité et l’authenticité de vos équipements réseau :
Fonctionnalité TPM (Trusted Platform Module) 2.0
ID d’appareils numériques (DevID)
Certificats DevID
Certificats de domaine épinglés (PDC) X.509
Certificats de propriétaire
Ancres de confiance DevID
Bons d’achat
Pour plus d’informations sur la façon de générer des pièces justificatives, voir Générer un certificat de pièce justificative.
Pour intégrer vos appareils Juniper avec Secure ZTP, consultez le guide de démarrage rapide Secure ZTP.
Avantages
Vous pouvez provisionner un équipement réseau distant sans intervention manuelle.
Vous pouvez provisionner un équipement réseau en toute sécurité à partir d’un emplacement central, ce qui empêche les entités non autorisées de prendre le contrôle de votre équipement réseau.
Vos serveurs de redirection et d'amorçage vérifient l'authenticité de votre équipement réseau en fonction de l'ID DevID programmé dans le TPM de l'équipement réseau.
Votre équipement réseau vérifie l'authenticité de vos serveurs de redirection et de vos serveurs d'amorçage, ainsi que les informations d'amorçage, en fonction des bons des appareils.
Cas d’usage
Pour les équipements réseau expédiés de l’usine, vous pouvez les rendre opérationnels à la fois en toute sécurité et à distance sans toucher manuellement l’équipement réseau. L’équipement réseau doit être capable d’utiliser le protocole DHCP (Dynamic Host Configuration Protocol) pour obtenir des informations de connectivité réseau et se connecter à un serveur d’amorçage distant.
Exigences SZTP
Pour déployer SZTP dans votre réseau, vous devez effectuer les tâches suivantes :
Déployez vos serveurs DHCP et DNS.
Configurez DHCP V4 option 143 ou DHCP V6 option 136 sur votre serveur DHCP, afin que le serveur DHCP puisse annoncer les noms de vos serveurs de redirection et d’amorçage.
Déployez vos serveurs de redirection et d’amorçage.
Obtenez des ancres de confiance DevID auprès de Juniper Networks.
Générez des certificats de propriétaire pour un équipement réseau ou un groupe d’équipements réseau.
Générez des certificats de domaine épinglés (PDC) pour chaque domaine réseau.
Obtenez des bons auprès de Juniper Networks.
Générez des informations de redirection et d’amorçage pour chaque équipement réseau.
Utilisez les informations de redirection et d’amorçage fournies par les serveurs de redirection et d’amorçage pour provisionner vos équipements réseau.
Une fois que vous avez déployé SZTP dans votre réseau, puis déployé un nouvel équipement réseau, l’équipement réseau démarre automatiquement.
Composants de l’infrastructure SZTP
- Fonctionnalité TPM (Trusted Platform Module) 2.0
- DevID
- Certificats DevID
- Certificats de domaine épinglés (PDC) X.509
- Certificats de propriétaire
- Ancres de confiance DevID
- Bons d’achat
Fonctionnalité TPM (Trusted Platform Module) 2.0
Le TPM est une micropuce qui fournit des fonctions liées à la sécurité. Au cours du processus de fabrication, Juniper Networks programme le TPM avec un identifiant d’appareil numérique (DevID) et une paire de clés asymétrique (clé publique et clé privée). Le TPM verrouille la clé privée de la paire asymétrique dans un emplacement inviolable.
DevID
Le DevID correspond à la clé privée et protège la clé privée. Les applications qui nécessitent une signature ou un chiffrement utilisent la clé privée DevID.
Les applications qui s'exécutent sur votre équipement réseau utilisent la clé privée DevID dans le module TPM de l'équipement réseau pour prouver l'identité de l'équipement réseau à un vérificateur à distance.
Certificats DevID
Juniper Networks génère un certificat DevID (certificat X.509) pour la clé publique qui correspond au DevID de la clé privée. Le certificat DevID contient le numéro de série de l’équipement réseau pour lequel le DevID a été créé. Le certificat DevID est généré conformément à la norme IEEE 802.1AR.
Certificats de domaine épinglés (PDC) X.509
Créez un certificat de domaine épinglé (PDC) X.509 pour chaque domaine réseau. Il peut s’agir d’un certificat d’AC racine ou d’un certificat d’AC intermédiaire. Convertissez le PDC des règles de codage distinguées (DER) en codage en base 64. Assurez-vous que le PDC est une autorité de certification (AC) et qu’il est conforme à la norme X.509.
Certificats de propriétaire
Le certificat de propriétaire vérifie le fournisseur qui a acheté ou possède l’équipement réseau. Générez une paire de clés asymétrique (clé publique et clé privée) pour chaque périphérique réseau ou groupe de périphériques réseau. La paire de clés doit utiliser soit la cryptographie Rivest-Shamir-Adleman (RSA), soit la cryptographie à courbe elliptique (ECC). Conservez la clé privée protégée dans un endroit sûr. Le certificat de domaine épinglé (PDC) doit être l’AC du certificat propriétaire.
Ancres de confiance DevID
Juniper Networks fournit des ancres d’approbation DevID. Installez les ancres d’approbation DevID dans les serveurs de redirection et d’amorçage pour vérifier le certificat DevID que l’appareil ou le client présente lors de l’établissement d’une session TLS.
Bons d’achat
Pour recevoir les bons d'achat, saisissez le PDC et le numéro de série de l'équipement réseau sur le portail Juniper Agile Licensing (JAL). Une fois que vous avez reçu les bons d’achat, incluez-les dans les informations d’amorçage sur votre serveur d’amorçage. Le serveur d’amorçage fournit les bons d’achat à vos équipements réseau. Vos équipements réseau utilisent ensuite les informations d’amorçage pour vérifier les ancres de confiance fournies par votre serveur de redirection.
Pour obtenir des instructions étape par étape sur la façon de recevoir des bons, voir Générer un certificat de bon d’achat.
DevID Workflow
Lorsqu’une application nécessite une signature ou un chiffrement qui utilise le DevID, l’application demande une session TLS avec le serveur d’amorçage.
- Le serveur d’amorçage envoie une réponse TLS à l’équipement réseau lui demandant d’effectuer les opérations suivantes :
- Fournir son certificat DevID
- Prouver qu’il dispose d’une clé privée
L’équipement réseau signe les données de session avec le DevID de la clé privée.
L’équipement réseau envoie la signature numérique et le certificat DevID au serveur d’amorçage.
- Le serveur d’amorçage utilise le certificat DevID pour vérifier la signature numérique.
Le serveur d’amorçage utilise l’ancre d’approbation DevID fournie par Juniper Networks pour vérifier le certificat DevID.
Informations d’intégration
Pour qu’un équipement réseau s’amorce de lui-même et établisse des connexions sécurisées avec d’autres systèmes, vous devez fournir des informations d’intégration. Les informations d’intégration sont des données qu’un équipement réseau utilise pour s’amorcer et se connecter à d’autres systèmes. Lorsqu’un équipement réseau envoie ces données, elles doivent être encodées dans un format conforme à la norme RFC 8572.
- Informations sur l’image de démarrage
- Télécharger l’URI
- Vérification des images
- Gestion de la configuration
- Scripts de préconfiguration
- Post-configuration Scripts
Informations sur l’image de démarrage
Les informations de l’image de démarrage incluent le nom du système d’exploitation et la version du système d’exploitation. Nous vous recommandons de spécifier « Junos » comme version du système d’exploitation. Assurez-vous de spécifier la bonne version du système d’exploitation pour empêcher le périphérique réseau de télécharger et d’installer continuellement des logiciels.
Télécharger l’URI
L’URI de téléchargement fournit l’emplacement de l’image de démarrage.
Vérification des images
Le champ Vérification de l’image comprend l’algorithme de hachage que vous utilisez pour générer un hachage sécurisé pour l’image logicielle et la valeur digest de l’image logicielle. SZTP prend en charge SHA256. Encodez la valeur digest sous forme de chaîne hexadécimale.
Gestion de la configuration
SZTP peut fusionner ou remplacer une configuration. Créez la configuration en XML et encodez-la au format Base 64. La configuration doit être au format Base 64 pour que le serveur d’amorçage puisse l’inclure dans ses informations d’amorçage.
Scripts de préconfiguration
SZTP prend en charge les scripts shell Bourne et les scripts Python. Le chemin de l’interpréteur de script shell Bourne est # !/bin/sh, et le chemin de l’interpréteur Python est # !/usr/bin/python.
Si le script est un script Bourne, SZTP vérifie la valeur finale du script. Si le script se termine avec une valeur différente de zéro, le processus SZTP redémarre. Si le script est un script Python, SZTP ne vérifie pas la valeur finale du script. La sortie d’un script peut contenir des erreurs même si le script s’exécute correctement.
Voici un exemple d'informations d'intégration en 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>
=========================================
Post-configuration Scripts
Les exigences de script de préconfiguration s’appliquent également aux scripts de post-configuration. En cas d’échec d’un script de post-configuration, votre appareil revient à la configuration qu’il exécutait avant l’exécution du script de pré-configuration. Le processus SZTP redémarre.
DHCP v4 Option 143
Configurez l’option DHCP v4 143 sur votre serveur DHCP avant qu’il ne puisse fournir des adresses IP au client DHCP.
Si vous utilisez un périphérique MX Series comme serveur DHCP, activez DHCP V4 Option 143.
Voici un exemple de configuration :
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
Voici un exemple de configuration :
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;
}
}
}
Conversion d’un format hexadécimal en format texte ASCII
Cette chaîne de texte hexadécimale dans l’option DHCP V6 136, par exemple, est égale à 26 octets au format texte ASCII. Au format hexadécimal, 26 est représenté par 001a. Chaque nombre hexadécimal est égal à un octet et chaque octet est égal à une combinaison de caractères ASCII.
Pour convertir la chaîne hexadécimale 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 en caractères ASCII, vous devez mapper les lettres et les chiffres hexadécimaux en lettres, chiffres et symboles ASCII.
Dans cet exemple, nous mappons l'URL utilisée pour l'option DHCP 136. Vous pouvez utiliser le même processus pour l’URL utilisée dans l’option DHCP 143.
Voici un exemple d'URL qui montre le mappage entre le format hexadécimal et le format ASCII. Vous pouvez voir que chaque nombre hexadécimal est mappé à des lettres et des symboles au format 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)
L’URL finale est https://ab-cde-server.net.
Utilisez un convertisseur hexadécimal en ASCII et vice versa pour vous assurer que vos résultats sont corrects.
SZTP Workflow
Si votre appareil n'est pas déjà dans un état d'usine par défaut, exécutez l'une des commandes suivantes pour amener votre appareil dans un état d'usine par défaut.
Sur les équipements réseau exécutant Junos OS, exécutez la
request vmhost zeroizecommande.Pour les équipements réseau exécutant Junos OS Evolved, exécutez la
request system zeroizecommande.
Lorsqu’un appareil démarre dans un état d’usine par défaut, les événements suivants se produisent.
Le client DHCP envoie une requête au serveur DHCP pour obtenir le nom, l’adresse IP ou le nom d’hôte du serveur d’amorçage ou du serveur de redirection client.
Configurez l’option DHCP 143 pour la V4 ou l’option DHCP 136 pour la V6. Le client DHCP demande l’adresse IP de chaque serveur d’amorçage ou de redirection jusqu’à ce que l’équipement termine l’amorçage.
Le serveur DHCP envoie au client DHCP le nom d’hôte d’un serveur d’amorçage ou de redirection client.
Le client de connexion téléphonique (PHC) de votre appareil envoie une demande d’amorçage au serveur qu’il a appris à partir de l’option DHCP. Si vous avez fourni plusieurs serveurs dans l'option DHCP, l'appareil tente d'amorcer avec chaque serveur de manière séquentielle.
L’appareil tente d’amorcer avec n’importe quel serveur d’amorçage, redirection client ou DNS que le PHC apprend via l’option DHCP. L’appareil tente d’amorcer un serveur en mode Round Robin jusqu’à ce que l’équipement démarre avec succès.
Le serveur d’amorçage répond avec les informations d’intégration signées avec le certificat de propriétaire et le bon de propriété.
- Le PHC utilise les informations contenues dans le certificat de propriétaire et le bon de propriété pour vérifier les informations d’intégration signées.
Le PHC extrait les informations d’image et de configuration.
Si l’appareil exécute une image différente, l’appareil télécharge l’image, utilise la nouvelle image pour la mettre à niveau, puis redémarre avec la nouvelle image.
Après le redémarrage, toute la séquence SZTP se répète, sauf que l'appareil ne redémarre pas car il a déjà l'image requise.
Le PHC valide la configuration.
(Facultatif) Le PHC exécute des scripts de post-configuration.
Le PHC envoie un message d’amorçage complet au PHS.
L’équipement nettoie les configurations et les ressources liées aux PHC.
Le PHC se termine.
Script Type |
Chemin de l’interprète |
Assistance pour la plate-forme |
|---|---|---|
Script shell |
|
Tous les équipements réseau |
Script Python |
|
Équipements réseau exécutant Junos OS avec une automatisation améliorée Équipements réseau exécutant Junos OS Evolved |
SZTP pour les équipements réseau à double moteur de routage
Avant de mettre à niveau le logiciel sur le moteur de routage de secours sur un équipement réseau qui exécute le logiciel Junos OS, activez l’instruction secure-ztp provision-backup-re dans la [edit system] hiérarchie du moteur de routage principal
Sur les équipements réseau qui exécutent le logiciel Junos OS, activez l’instruction provision-backup-re dans la [edit system] hiérarchie du moteur de routage principal afin qu’il puisse amorcer le moteur de routage de secours.
Sur les équipements réseau qui exécutent le logiciel Junos OS Evolved, activez l’instruction auto-sw-sync dans la [edit system] hiérarchie, de sorte que le moteur de routage principal s’assure que la même version d’image se trouve sur le moteur de routage de secours via une mise à niveau ou une rétrogradation.
Sur les systèmes basés sur Junos OS avec deux moteurs de routage, le moteur de routage principal télécharge l’image même si le moteur de routage principal exécute déjà la version d’image requise. L’appareil télécharge l’image afin que le moteur de routage principal soit prêt à mettre à niveau le moteur de routage de secours, si nécessaire.
Sur les systèmes basés sur Junos OS Evolved, le moteur de routage principal conserve toujours une copie de l’image en cours d’exécution.
Si vous n'avez pas activé l synchronize 'instruction au niveau de la [edit system] hiérarchie ou du basculement GRES (Graceful Restart Engine Switchover) sur le moteur de routage principal, le moteur de routage principal ne synchronise pas la configuration et l'état avec le moteur de routage de secours. Dans ce cas, le moteur de routage principal vérifie l’authenticité du moteur de routage de secours avant de synchroniser des données avec le moteur de routage de secours.
Avant que le moteur de routage principal ne provisionne le moteur de routage de secours, le moteur de routage principal vérifie l’authenticité du moteur de routage de secours. Le moteur de routage principal vérifie le DevID du moteur de routage de secours pour s’assurer que le moteur de routage de secours est un moteur de routage autorisé par Juniper.
Le moteur de routage principal ne vérifie pas si le moteur de routage de secours est autorisé à recevoir des informations du moteur de routage principal. En outre, le moteur de routage de secours ne vérifie pas l'authenticité ou l'autorisation du moteur de routage principal.
Le moteur de routage principal provisionne le moteur de routage de secours dans les situations suivantes :
Lorsque le moteur de routage principal a démarré à l’aide de SZTP.
Lorsque le moteur de routage de secours est présent lorsque le moteur de routage principal est amorcé ou inséré pendant le processus SZTP.
Lorsque le moteur de routage de secours redémarre ou est remplacé.
Une fois que le moteur de routage principal vérifie l'authenticité du moteur de routage de secours et répond aux exigences de provisionnement, le moteur de routage principal vérifie la version du logiciel qui s'exécute sur le moteur de routage de secours. Si la version logicielle du moteur de routage de secours est différente de la version logicielle du moteur de routage principal, le moteur de routage principal met à niveau le moteur de routage de secours vers la même version logicielle que celle exécutée par le moteur de routage principal.
Lorsque les deux moteurs de routage exécutent le même logiciel, le moteur de routage principal synchronise sa configuration avec le moteur de routage de secours.