Aprovisionamiento seguro sin intervención
Para ver qué plataformas admiten el aprovisionamiento seguro sin intervención (SZTP), vaya al Explorador de características. En la sección Explorar características de la página Explorador de características, seleccione Todas las características. En el cuadro Características agrupadas por familia de características , seleccione ZTP seguro. También puede escribir el nombre de la entidad en el cuadro de edición Buscar entidades . Consulte la tabla de historial de versiones al final de este tema para obtener más detalles sobre cómo se ha expandido el soporte de ZTP.
Descripción general
El proceso de cliente de teléfono a casa (PHC) admite el aprovisionamiento sin intervención seguro (SZTP).
Puede usar SZTP basado en RFC-8572 para arrancar dispositivos de red ubicados remotamente que se encuentran en un estado predeterminado de fábrica. SZTP habilita la autenticación mutua entre el servidor de arranque y el dispositivo de red antes de aprovisionar el dispositivo de red remoto.
Para habilitar la autenticación mutua, necesita un cupón digital único y un dispositivo de red programado DevID (ID de dispositivo digital o identidad digital criptográfica). El DevID está integrado en el chip del módulo de plataforma de confianza (TPM) 2.0 en el dispositivo de red. Juniper Networks emite un cupón digital a los clientes por cada dispositivo de red elegible.
Admitimos SZTP en interfaces de administración y WAN.
El ZTP heredado basado en DHCP está deshabilitado. No admitimos ZTP heredado basado en DHCP en hardware que admita SZTP.
SZTP cumple con RFC 8572 y requiere la siguiente infraestructura para garantizar la identidad y autenticidad de sus dispositivos de red:
módulo de plataforma de confianza (TPM) 2.0
ID de dispositivos digitales (DevID)
Certificados DevID
Certificados de dominio anclados (PDC) X.509
Certificados de propietario
Anclajes de confianza de DevID
Vales
Para obtener información sobre cómo generar cupones, consulte Generar certificado de cupón.
Para incorporar sus dispositivos Juniper con ZTP seguro, consulte la Guía de inicio rápido de ZTP seguro.
Beneficios
Puede aprovisionar un dispositivo de red remoto sin intervención manual.
Puede aprovisionar un dispositivo de red de forma segura desde una ubicación central, lo que impide que entidades no autorizadas tomen el control de su dispositivo de red.
Los servidores de redireccionamiento y arranque comprueban la autenticidad del dispositivo de red en función del DevID programado en el TPM del dispositivo de red.
El dispositivo de red verifica la autenticidad de los servidores de redireccionamiento y de los servidores de arranque, así como de la información de arranque, en función de los cupones de los dispositivos.
Caso de uso
En el caso de los dispositivos de red que se envían de fábrica, puede hacer que los dispositivos de red funcionen de forma segura y remota sin tocar manualmente el dispositivo de red. El dispositivo de red debe poder usar el protocolo de configuración dinámica de host (DHCP) para obtener información de conectividad de red y conectarse a un servidor de arranque remoto.
Requisitos de SZTP
Para implementar SZTP en su red, debe realizar las siguientes tareas:
Implemente sus servidores DHCP y DNS.
Configure la opción 143 de DHCP V4 o la opción 136 de DHCP V6 en el servidor DHCP para que el servidor DHCP pueda anunciar los nombres de los servidores de redireccionamiento y arranque.
Implemente sus servidores de redireccionamiento y arranque.
Adquiera anclajes de confianza de DevID de Juniper Networks.
Genere certificados de propietario para un dispositivo de red o un grupo de dispositivos de red.
Genere certificados de dominio anclados (PDC) para cada dominio de red.
Adquiera cupones de Juniper Networks.
Genere información de redireccionamiento y arranque para cada dispositivo de red.
Utilice la información de redireccionamiento y arranque que proporcionan los servidores de redireccionamiento y arranque para aprovisionar sus dispositivos de red.
Después de implementar SZTP en la red y, luego, implementar un nuevo dispositivo de red, el dispositivo de red se inicia automáticamente.
Componentes de infraestructura SZTP
- módulo de plataforma de confianza (TPM) 2.0
- ID de desarrollo
- Certificados DevID
- Certificados de dominio anclados (PDC) X.509
- Certificados de propietario
- Anclajes de confianza de DevID
- Certificados de cupón
módulo de plataforma de confianza (TPM) 2.0
El TPM es un microchip que proporciona funciones relacionadas con la seguridad. Durante el proceso de fabricación, Juniper Networks programa el TPM con un ID de dispositivo digital (DevID) y un par de claves asimétricas (clave pública y clave privada). El TPM bloquea la clave privada del par asimétrico en una ubicación a prueba de manipulaciones.
ID de desarrollo
El DevID corresponde a la clave privada y protege la clave privada. Las aplicaciones que requieren firma o cifrado usan la clave privada de DevID.
Las aplicaciones que se ejecutan en el dispositivo de red usan la clave privada DevID en el TPM del dispositivo de red para demostrar la identidad del dispositivo de red a un comprobador remoto.
Certificados DevID
Juniper Networks genera un certificado DevID (certificado X.509) para la clave pública que corresponde al DevID de la clave privada. El certificado DevID contiene el número de serie del dispositivo de red para el que se creó el DevID. El certificado DevID se genera de conformidad con el estándar IEEE 802.1AR.
Certificados de dominio anclados (PDC) X.509
Cree un certificado de dominio anclado (PDC) X.509 para cada dominio de red. El PDC puede ser un certificado de AC raíz o un certificado de AC intermedio. Convierta el PDC de reglas de codificación distinguidas (DER) a codificación de base 64. Asegúrese de que el PDC sea una autoridad de certificación (AC) y cumpla con X.509.
Certificados de propietario
El certificado de propietario verifica el proveedor que compró o es propietario del dispositivo de red. Genere un par de claves asimétricas (clave pública y clave privada) para cada dispositivo de red o grupo de dispositivos de red. El par de claves debe utilizar Rivest-Shamir-Adleman (RSA) o criptografía de curva elíptica (ECC). Mantenga la clave privada protegida en un lugar seguro. El certificado de dominio anclado (PDC) debe ser la AC para el certificado de propietario.
Anclajes de confianza de DevID
Juniper Networks proporciona anclajes de confianza de DevID. Instale los anclajes de confianza de DevID en los servidores de redireccionamiento y arranque para comprobar el certificado de DevID que presenta el dispositivo o cliente mientras establece una sesión TLS.
Certificados de cupón
Para recibir certificados de cupón, ingrese el PDC y el número de serie del dispositivo de red en el portal de Juniper Agile Licensing (JAL). Una vez que reciba los certificados de cupón, inclúyalos como parte de la información de arranque en su servidor de arranque. El servidor de arranque proporciona los certificados de cupón a sus dispositivos de red. A continuación, los dispositivos de red utilizan la información de arranque para comprobar los anclajes de confianza que proporciona el servidor de redireccionamiento.
Para obtener instrucciones paso a paso sobre cómo recibir cupones, consulte Generar certificado de cupón.
Flujo de trabajo de DevID
Cuando una aplicación requiere firma o cifrado que utiliza el DevID, la aplicación solicita una sesión TLS con el servidor de arranque.
- El servidor de arranque envía una respuesta TLS al dispositivo de red pidiéndole que haga lo siguiente:
- Proporcionar su certificado de DevID
- Demostrar que tiene una clave privada
El dispositivo de red firma los datos de la sesión con el DevID de la clave privada.
El dispositivo de red envía la firma digital y el certificado DevID al servidor de arranque.
- El servidor de arranque utiliza el certificado DevID para comprobar la firma digital.
El servidor de arranque utiliza el anclaje de confianza DevID que Juniper Networks proporciona para comprobar el certificado DevID.
Información de incorporación
Para que un dispositivo de red se inicie solo y establezca conexiones seguras con otros sistemas, debe proporcionar información de incorporación. La información de incorporación son datos que un dispositivo de red utiliza para arrancarse y conectarse con otros sistemas. Cuando un dispositivo de red envía estos datos, los datos deben codificarse en un formato que cumpla con RFC 8572.
- Información de la imagen de arranque
- Descargar URI
- Verificación de imagen
- Manejo de configuración
- Scripts de preconfiguración
- Scripts posteriores a la configuración
Información de la imagen de arranque
La información de la imagen de arranque incluye el nombre del sistema operativo y la versión del sistema operativo. Le recomendamos que especifique "Junos" como versión del sistema operativo. Asegúrese de especificar la versión correcta del sistema operativo para evitar que el dispositivo de red descargue e instale software continuamente.
Descargar URI
El URI de descarga proporciona la ubicación de la imagen de arranque.
Verificación de imagen
El campo de verificación de imagen incluye el algoritmo hash que se utiliza para generar un hash seguro para la imagen de software y el valor de resumen de la imagen de software. SZTP admite SHA256. Codifique el valor de resumen como una cadena hexadecimal.
Manejo de configuración
SZTP puede fusionar o reemplazar una configuración. Cree la configuración en XML y codifique la configuración en formato Base 64. La configuración debe estar en formato Base 64 para que el servidor de arranque pueda incluirla en su información de arranque.
Scripts de preconfiguración
SZTP admite scripts de shell de Bourne y scripts de Python. La ruta del intérprete de scripts de shell de Bourne es #!/bin/sh, y la ruta del intérprete de Python es #!/usr/bin/python.
Si el script es un script Bourne, SZTP comprueba el valor final del script. Si la secuencia de comandos se cierra con un valor distinto de cero, el proceso SZTP se reinicia. Si el script es un script de Python, SZTP no comprueba el valor final del script. La salida de un script podría tener errores incluso si el script se ejecutó correctamente.
A continuación, se muestra un ejemplo de la información de incorporación 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>
=========================================
Scripts posteriores a la configuración
Los requisitos de scripts de preconfiguración también se aplican a los scripts posteriores a la configuración. Si se produce un error en algún script posterior a la configuración, el dispositivo vuelve a la configuración que estaba ejecutando antes de que se ejecutara el script de preconfiguración. El proceso SZTP se reinicia.
Opción 143 de DHCP v4
Configure la opción 143 de DHCP V4 en el servidor DHCP antes de que pueda proporcionar direcciones IP al cliente DHCP.
Si utiliza un dispositivo de la serie MX como servidor DHCP, habilite la opción 143 de DHCP V4.
A continuación, se muestra una configuración de ejemplo:
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;
}
}
}
Opción 136 de DHCP v6
A continuación, se muestra una configuración de ejemplo:
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;
}
}
}
Conversión de formato hexadecimal a formato de texto ASCII
Esta cadena de texto hexadecimal en la opción 136 de DHCP V6, por ejemplo, equivale a 26 bytes en formato de texto ASCII. En formato hexadecimal, 26 se representa como 001a. Cada número hexadecimal es igual a un byte y cada byte es igual a una combinación de caracteres ASCII.
Para convertir la cadena hexadecimal 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 a caracteres ASCII, debe asignar las letras hexadecimales y los números a letras, números y símbolos ASCII.
En este ejemplo, estamos asignando la URL usada para la opción 136 de DHCP. Puede utilizar el mismo proceso para la URL utilizada en la opción 143 de DHCP.
A continuación, se muestra una URL de ejemplo que muestra la asignación entre el formato hexadecimal y el formato ASCII. Puede ver que cada número hexadecimal está asignado a letras y símbolos en formato 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)
La URL final es https://ab-cde-server.net.
Utilice un convertidor hexadecimal a ASCII y viceversa para asegurarse de que sus resultados sean correctos.
Flujo de trabajo de SZTP
Si el dispositivo aún no está en un estado predeterminado de fábrica, emita uno de los siguientes comandos para que el dispositivo vuelva a un estado predeterminado de fábrica.
En dispositivos de red que ejecuten Junos OS, ejecute el
request vmhost zeroizecomando.Para dispositivos de red que ejecutan Junos OS Evolved, ejecute el
request system zeroizecomando.
Cuando un dispositivo se inicia en un estado predeterminado de fábrica, se producen los siguientes eventos.
El cliente DHCP envía una solicitud al servidor DHCP para obtener el nombre, la dirección IP o el nombre de host del servidor de arranque o del servidor de redireccionamiento del cliente.
Configure la opción 143 de DHCP para V4 o la opción 136 de DHCP para V6. El cliente DHCP solicita la dirección IP para cada servidor de arranque o redireccionamiento hasta que el dispositivo complete el arranque.
El servidor DHCP envía el nombre de host del servidor de un servidor de arranque o de redireccionamiento del cliente al cliente DHCP.
El cliente de teléfono doméstico (PHC) del dispositivo envía una solicitud de arranque al servidor que aprendió de la opción DHCP. Si proporcionó varios servidores en la opción DHCP, el dispositivo intenta arrancar con cada servidor secuencialmente.
El dispositivo intenta arrancar con cualquier servidor de arranque, redireccionamiento de cliente o DNS que el PHC aprende a través de la opción DHCP. El dispositivo intenta arrancar en un servidor de forma rotativa hasta que el dispositivo se inicie correctamente.
El servidor de arranque responde con información de incorporación firmada junto con el certificado de propietario y el comprobante de propiedad.
- El PHC utiliza la información del certificado de propietario y el comprobante de propiedad para verificar la información de incorporación firmada.
El PHC extrae la imagen y la información de configuración.
Si el dispositivo ejecuta una imagen diferente, el dispositivo descarga la imagen, utiliza la imagen nueva para actualizar y, luego, se reinicia con la imagen nueva.
Después del reinicio, se repite toda la secuencia de SZTP, excepto que el dispositivo no se reinicia porque ya tiene la imagen requerida.
El PHC confirma la configuración.
(Opcional) El PHC ejecuta scripts posteriores a la configuración.
El PHC envía un mensaje de arranque completo al PHS.
El dispositivo limpia las configuraciones y los recursos relacionados con la PHC.
El PHC termina.
Tipo de script |
Ruta del intérprete |
Soporte de plataforma |
|---|---|---|
Script de shell |
|
Todos los dispositivos de red |
Script de Python |
|
Dispositivos de red que ejecutan Junos OS con automatización mejorada Dispositivos de red que ejecutan Junos OS Evolved |
SZTP para dispositivos de red con motores de enrutamiento dual
Antes de actualizar el software del motor de enrutamiento de respaldo en un dispositivo de red que ejecute software de Junos OS, habilite la secure-ztp provision-backup-re instrucción en la [edit system] jerarquía del motor de enrutamiento principal
En dispositivos de red que ejecuten software Junos OS, habilite la provision-backup-re instrucción en la [edit system] jerarquía del motor de enrutamiento principal para que pueda arrancar el motor de enrutamiento de respaldo.
En dispositivos de red que ejecuten software Junos OS evolucionado, habilite la auto-sw-sync instrucción en la [edit system] jerarquía, de modo que el motor de enrutamiento principal garantice que la misma versión de imagen esté en el motor de enrutamiento de respaldo a través de una actualización o degradación.
En los sistemas basados en Junos OS con motores de enrutamiento duales, el motor de enrutamiento principal descarga la imagen incluso si el motor de enrutamiento principal ya está ejecutando la versión de imagen requerida. El dispositivo descarga la imagen para que el motor de enrutamiento principal esté listo para actualizar el motor de enrutamiento de respaldo, si es necesario.
En los sistemas basados en Junos OS evolucionado, el motor de enrutamiento principal siempre conserva una copia de la imagen que está ejecutando.
Si no habilitó la synchronize instrucción en la jerarquía o el [edit system] cambio normal de motor de reinicio (GRES) en el motor de enrutamiento principal, el motor de enrutamiento principal no sincroniza la configuración y el estado con el motor de enrutamiento de respaldo. En esta situación, el motor de enrutamiento principal comprueba la autenticidad del motor de enrutamiento de respaldo antes de sincronizar los datos con el motor de enrutamiento de respaldo.
Antes de que el motor de enrutamiento principal aprovisione el motor de enrutamiento de respaldo, el motor de enrutamiento principal verifica la autenticidad del motor de enrutamiento de respaldo. El motor de enrutamiento principal comprueba el DevID del motor de enrutamiento de respaldo para asegurarse de que el motor de enrutamiento de respaldo sea un motor de enrutamiento autorizado por Juniper.
El motor de enrutamiento principal no comprueba si el motor de enrutamiento de respaldo está autorizado para recibir información del motor de enrutamiento principal. Además, el motor de enrutamiento de respaldo no comprueba la autenticidad ni la autorización del motor de enrutamiento principal.
El motor de enrutamiento principal aprovisiona el motor de enrutamiento de respaldo en las siguientes situaciones:
Cuando el motor de enrutamiento principal se ha iniciado mediante SZTP.
Cuando el motor de enrutamiento de respaldo está presente, cuando el motor de enrutamiento principal está arrancando o insertado durante el proceso SZTP.
Cuando el motor de enrutamiento de respaldo se reinicia o se reemplaza.
Una vez que el motor de enrutamiento principal verifica la autenticidad del motor de enrutamiento de respaldo y cumple con los requisitos para el aprovisionamiento, el motor de enrutamiento principal comprueba la versión del software que se ejecuta en el motor de enrutamiento de respaldo. Si la versión de software del motor de enrutamiento de respaldo es diferente de la versión de software del motor de enrutamiento principal, el motor de enrutamiento principal actualiza el motor de enrutamiento de respaldo a la misma versión de software que ejecuta el motor de enrutamiento principal.
Cuando ambos motores de enrutamiento ejecutan el mismo software, el motor de enrutamiento principal sincroniza su configuración con el motor de enrutamiento de respaldo.