Zero-Touch Provisioning sécurisé
Pour savoir quelles plates-formes prennent en charge le Zero-Touch Provisioning sécurisé (SZTP), accédez à l’Explorateur de fonctionnalités. Dans la section Explorer les fonctionnalités de la page Explorateur de fonctionnalités, sélectionnez Toutes les fonctionnalités. Dans la zone Features Grouped by Feature Family (Fonctionnalités regroupées par famille de fonctionnalités ), sélectionnez Secure ZTP (ZTP sécurisé). Vous pouvez également taper le nom de l’entité dans la zone d’édition Search for Features (Rechercher des entités ). Consultez le tableau de l’historique des versions à la fin de cette rubrique pour plus de détails sur la façon dont la prise en charge de ZTP a été étendue.
Aperçu
Le processus PHC (Phone-Home Client) prend en charge le Zero-Touch Provisioning sécurisé (SZTP).
Vous pouvez utiliser le protocole SZTP basé sur la norme RFC-8572 pour démarrer des périphériques réseau distants dont l’état est par défaut aux paramètres d’usine. 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é dans 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 appareil réseau éligible.
Nous prenons en charge le protocole SZTP pour la gestion et les interfaces WAN.
La fonctionnalité ZTP héritée basée sur DHCP est désactivée. 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 :
Trusted Platform Module (TPM) 2.0
ID d’appareils numériques (DevID)
Certificats DevID
Certificats de domaine épinglés (PDC) X.509
Certificats de propriétaire
Ancrages de confiance DevID
Bons
Pour plus d’informations sur la façon de générer des bons, reportez-vous à la section Générer un certificat de bon.
Pour intégrer vos appareils Juniper avec Secure ZTP, reportez-vous au Guide de démarrage rapide Secure ZTP.
Avantages
Vous pouvez provisionner un équipement réseau distant sans intervention manuelle.
Vous pouvez provisionner un périphérique 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 périphérique réseau.
Vos serveurs de redirection et d'amorçage vérifient l'authenticité de votre périphérique réseau en fonction du DevID programmé dans le TPM de l'équipement réseau.
Votre périphérique réseau vérifie l'authenticité de vos serveurs de redirection et serveurs d'amorçage, ainsi que les informations d'amorçage, en fonction des pièces justificatives des périphériques.
Cas d'utilisation
Pour les périphériques réseau expédiés de l’usine, vous pouvez les rendre opérationnels à distance et en toute sécurité, sans avoir à les toucher manuellement. L’équipement réseau doit pouvoir utiliser le protocole DHCP (Dynamic Host Configuration Protocol) pour obtenir des informations sur la connectivité réseau et se connecter à un serveur d’amorçage distant.
Exigences SZTP
Pour déployer SZTP sur 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.
Faites l’acquisition de points d’ancrage de confiance DevID auprès de Juniper Networks.
Générez des certificats de propriétaire pour un périphérique réseau ou un groupe d’équipements réseau.
Générez des certificats de domaine épinglés (PDC) pour chaque domaine réseau.
Achetez des bons d’achat 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 périphériques réseau.
Une fois que vous avez déployé SZTP dans votre réseau, puis déployé un nouveau périphérique réseau, celui-ci démarre automatiquement.
Composants de l’infrastructure SZTP
- Trusted Platform Module (TPM) 2.0
- DevID (ID DevID)
- Certificats DevID
- Certificats de domaine épinglés (PDC) X.509
- Certificats de propriétaire
- Ancrages de confiance DevID
- Certificats de bons d’achat
Trusted Platform Module (TPM) 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’équipement 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 (ID 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 périphérique réseau utilisent la clé privée DevID dans le TPM de l'équipement réseau pour prouver l'identité de l'équipement réseau à un vérificateur distant.
Certificats DevID
Juniper Networks génère un certificat DevID (certificat X.509) pour la clé publique qui correspond à l’ID Dev 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’autorité de certification racine ou d’un certificat d’autorité de certification intermédiaire. Convertissez le PDC des règles d’encodage distinguées (DER) à l’encodage en base 64. Assurez-vous que le PDC est une autorité de certification (CA) 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 de 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’autorité de certification du certificat propriétaire.
Ancrages de confiance DevID
Juniper Networks fournit des ancres de confiance 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.
Certificats de 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 certificats de bon, incluez-les dans les informations d’amorçage sur votre serveur d’amorçage. Le serveur d’amorçage fournit les certificats de bon à vos périphériques réseau. Vos périphériques 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 détaillées sur la façon de recevoir des bons, voir Générer un certificat de bon.
DevID Workflow
Lorsqu’une application nécessite une signature ou un chiffrement qui utilise l’ID Dev, l’application demande une session TLS avec le serveur d’amorçage.
- Le serveur d’amorçage envoie une réponse TLS au périphérique 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 l’ID 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 sur l’intégration
Pour qu’un équipement réseau puisse démarrer tout seul et établir 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 se démarrer et se connecter à d’autres systèmes. Lorsqu’un périphérique réseau envoie ces données, elles doivent être codées dans un format conforme à la norme RFC 8572.
- Informations sur l’image de démarrage
- Télécharger l’URI
- Vérification de l’image
- Gestion de la configuration
- Scripts de préconfiguration
- Post-configuration Scripts
Informations sur l’image de démarrage
Les informations sur l’image de démarrage comprennent 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 de l’image
Le champ de vérification d’image inclut l’algorithme de hachage que vous utilisez pour générer un hachage sécurisé pour l’image logicielle et la valeur de synthèse de l’image logicielle. SZTP prend en charge SHA256. Encodez la valeur de synthèse 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 d’accès à l’interpréteur de script shell Bourne est # !/bin/sh, et le chemin d’accès à l’interpréteur Python est # !/usr/bin/python.
S’il s’agit d’un script Bourne, SZTP vérifie la valeur de fin du script. Si le script se termine avec une valeur différente de zéro, le processus SZTP redémarre. S'il s'agit d'un script Python, SZTP ne vérifie pas la valeur de fin 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 au format 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 relatives aux scripts de préconfiguration s’appliquent également aux scripts de post-configuration. En cas d’échec d’un script de post-configuration, votre équipement 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 DHCP V4 option 143 sur votre serveur DHCP avant qu’il ne puisse fournir d’adresses IP au client DHCP.
Si vous utilisez un périphérique MX Series en tant que serveur DHCP, activez l’option 143 DHCP V4.
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 135
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 135 hex-string 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574;
}
}
}
Conversion du format hexadécimal au format texte ASCII
Cette chaîne de texte hexadécimale dans l’option 135 de DHCP V6, 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 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 chaîne hexadécimale en caractères ASCII, vous devez mapper les lettres et les chiffres hexadécimaux aux lettres, chiffres et symboles ASCII.
Dans cet exemple, nous mappons l'URL utilisée pour l'option DHCP 135. 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, émettez l'une des commandes suivantes pour le ramener dans un état d'usine par défaut.
Sur les périphériques réseau exécutant Junos OS, exécutez la
request vmhost zeroizecommande.Pour les périphériques réseau exécutant Junos OS Evolved, exécutez la
request system zeroizecommande.
Lorsqu’un périphérique 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 V4 ou l’option DHCP 135 pour V6. Le client DHCP demande l’adresse IP de chaque serveur d’amorçage ou de redirection jusqu’à ce que l’appareil termine l’amorçage.
Le serveur DHCP envoie le nom d’hôte du serveur d’amorçage ou de redirection client au client DHCP.
Le PHC (Phone-Home Client) de votre appareil envoie une requête 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 de démarrer avec chaque serveur de manière séquentielle.
L’appareil tente de démarrer avec n’importe quel serveur d’amorçage, de redirection client ou DNS que le PHC apprend via l’option DHCP. L’appareil tente de s’amorcer sur un serveur en mode Round-Robin jusqu’à ce que l’appareil démarre avec succès.
Le serveur d’amorçage répond avec des informations d’intégration signées ainsi que 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, il télécharge l’image, utilise la nouvelle image pour effectuer la mise à 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 possède 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’appareil nettoie les configurations et les ressources liées aux PHC.
Le PHC prend fin.
Script Type |
Parcours de l’interprète |
Prise en charge de la plate-forme |
|---|---|---|
Script shell |
|
Tous les périphériques réseau |
Script Python |
|
Périphériques réseau exécutant Junos OS avec automatisation améliorée Périphériques réseau exécutant Junos OS Evolved |
SZTP pour les équipements réseau avec deux moteurs de routage
Avant de mettre à niveau le logiciel du moteur de routage de sauvegarde sur un équipement réseau qui exécute le logiciel Junos OS, activez l’instruction secure-ztp provision-backup-re au niveau de la [edit system] hiérarchie du moteur de routage principal
Sur les périphériques réseau qui exécutent le logiciel Junos OS, activez l’instruction provision-backup-re au niveau de la [edit system] hiérarchie du moteur de routage principal afin qu’il puisse démarrer le moteur de routage de sauvegarde.
Sur les périphériques réseau qui exécutent le logiciel Junos OS Evolved, activez l’instruction auto-sw-sync au niveau de la [edit system] hiérarchie, afin que le moteur de routage principal garantisse que la même version d’image figure sur le moteur de routage de sauvegarde lors d’une mise à niveau ou d’une rétrogradation.
Sur les systèmes basés sur Junos OS dotés de 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 de sorte 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 hiérarchie ou GRES [edit system] (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 sauvegarde. Dans ce cas, le moteur de routage principal vérifie l’authenticité du moteur de routage de sauvegarde avant de synchroniser les 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 sauvegarde pour s’assurer que le moteur de routage de sauvegarde 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. De plus, le moteur de routage de sauvegarde 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 en cours d’amorçage ou inséré pendant le processus SZTP.
Lorsque le moteur de routage de sauvegarde redémarre ou est remplacé.
Une fois que le moteur de routage principal a vérifié l'authenticité du moteur de routage de sauvegarde et satisfait 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 sauvegarde. Si la version logicielle du moteur de routage de sauvegarde est différente de la version logicielle du moteur de routage principal, le moteur de routage principal met à niveau le moteur de routage de sauvegarde 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.