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 característica en el cuadro de edición Buscar características . Consulte la tabla Historial de versiones al final de este tema para obtener más detalles sobre cómo se ha ampliado la compatibilidad con ZTP.
Visión general
El proceso de cliente de teléfono a domicilio (PHC) admite el aprovisionamiento seguro sin intervención (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 permite 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 segura (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 se admiten ZTP heredados basados 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 segura (TPM) 2.0
ID de dispositivo digital (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 Secure ZTP, consulte la Guía de inicio rápido de Secure ZTP.
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 evita 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 los servidores de arranque, así como la información del programa 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 necesidad de 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 los servidores DHCP y DNS.
Configure DHCP V4 opción 143 o DHCP V6 opción 136 en su servidor DHCP, para que el servidor DHCP pueda anunciar los nombres de sus 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 los dispositivos de red.
Después de implementar SZTP en la red y, a continuación, implementar un nuevo dispositivo de red, el dispositivo de red se inicia automáticamente.
Componentes de infraestructura SZTP
- Módulo de plataforma segura (TPM) 2.0
- DevID
- Certificados DevID
- Certificados de dominio anclados (PDC) X.509
- Certificados de propietario
- Anclajes de confianza de DevID
- Certificados de vales
Módulo de plataforma segura (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.
DevID
El DevID corresponde a la clave privada y protege la clave privada. Las aplicaciones que requieren firma o cifrado utilizan 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 CA raíz o un certificado de CA intermedio. Convierta el PDC de reglas de codificación distinguidas (DER) a codificación base 64. Asegúrese de que el PDC es una autoridad de certificación (CA) y cumple con X.509.
Certificados de propietario
El certificado de propietario verifica el proveedor que compró o posee el 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 CA del certificado de propietario.
Anclajes de confianza de DevID
Juniper Networks proporciona anclajes de confianza de DevID. Instale los anclajes de confianza de DevID en 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 vales
Para recibir certificados de cupones, 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 inicio.
- El servidor de arranque envía una respuesta TLS al dispositivo de red pidiéndole que haga lo siguiente:
- Proporcionar su certificado DevID
- Demostrar que tiene una clave privada
El dispositivo de red firma los datos de 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 inicio.
- 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 verificar el certificado DevID.
Información de incorporación
Para que un dispositivo de red se inicie 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 la 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 la 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 utiliza para generar un hash seguro para la imagen de software y el valor de síntesis de la imagen de software. SZTP admite SHA256. Codifique el valor de síntesis como una cadena hexadecimal.
Manejo de la configuración
SZTP puede combinar 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 soporta scripts de shell 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 el script sale 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. El resultado de un script podría tener errores incluso si el script se ejecutó correctamente.
Este es 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 script 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.
Esta es 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 135 de DHCP V6
Esta es 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 135 hex-string 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574;
}
}
}
Conversión de formato hexadecimal a formato de texto ASCII
Esta cadena de texto hexadecimal en la opción 135 de DHCP V6, por ejemplo, es igual 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 y números hexadecimales a letras, números y símbolos ASCII.
En este ejemplo, estamos asignando la URL utilizada para la opción 135 de DHCP. Puede utilizar el mismo proceso para la URL utilizada en la opción 143 de DHCP.
Esta es 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 conversor hexadecimal a ASCII y viceversa para asegurarse de que los resultados sean correctos.
Flujo de trabajo SZTP
Si el dispositivo aún no está en un estado predeterminado de fábrica, emita uno de los siguientes comandos para llevarlo a un estado predeterminado de fábrica.
En dispositivos de red que ejecuten Junos OS, ejecute el
request vmhost zeroizecomando.Para los 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 135 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 un servidor de redirección de cliente al cliente DHCP.
El cliente phone-home (PHC) de su 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 arranque, redirección de cliente o servidor DNS que el PHC aprende a través de la opción DHCP. El dispositivo intenta arrancar a un servidor de forma redonda hasta que el dispositivo se inicia 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 en el 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 nueva imagen para actualizar y, a continuación, se reinicia con la nueva imagen.
Después del reinicio, toda la secuencia SZTP se repite, excepto que el dispositivo no se reinicia porque ya tiene la imagen requerida.
La APS 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.
La APS 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 en el motor de enrutamiento de reserva en un dispositivo de red que ejecute software Junos OS, habilite la secure-ztp provision-backup-re instrucción en la [edit system] jerarquía del motor de enrutamiento principal
En los dispositivos de red que ejecutan el 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 reserva.
En los dispositivos de red que ejecutan el software Junos OS Evolved, 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 reserva mediante una actualización o una 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 reserva, si es necesario.
En los sistemas basados en Junos OS Evolved, el motor de enrutamiento principal siempre guarda una copia de la imagen que está ejecutando.
Si no ha habilitado la instrucción en la [edit system] jerarquía o el synchronize cambio correcto del 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 reserva. En esta situación, el motor de enrutamiento principal comprueba la autenticidad del motor de enrutamiento de reserva antes de sincronizar los datos con el motor de enrutamiento de reserva.
Antes de que el motor de enrutamiento principal aprovisione el motor de enrutamiento de reserva, el motor de enrutamiento principal verifica la autenticidad del motor de enrutamiento de reserva. El motor de enrutamiento principal comprueba el DevID del motor de enrutamiento de reserva para asegurarse de que el motor de enrutamiento de reserva es un motor de enrutamiento autorizado por Juniper.
El motor de enrutamiento principal no comprueba si el motor de enrutamiento de reserva está autorizado para recibir información del motor de enrutamiento principal. Además, el motor de enrutamiento de reserva no verifica la autenticidad ni la autorización del motor de enrutamiento principal.
El motor de enrutamiento principal aprovisiona el motor de enrutamiento de reserva en las siguientes situaciones:
Cuando el motor de enrutamiento principal se ha iniciado mediante SZTP.
Cuando el motor de enrutamiento de reserva está presente cuando el motor de enrutamiento principal está arrancando o insertado durante el proceso SZTP.
Cuando el motor de enrutamiento de reserva se reinicia o se reemplaza.
Una vez que el motor de enrutamiento principal verifica la autenticidad del motor de enrutamiento de reserva y cumple los requisitos de aprovisionamiento, el motor de enrutamiento principal comprueba la versión del software que se ejecuta en el motor de enrutamiento de reserva. Si la versión de software del motor de enrutamiento de copia de seguridad es diferente de la versión de software del motor de enrutamiento principal, el motor de enrutamiento principal actualiza el motor de enrutamiento de reserva 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 reserva.