Cada túnel TLS que construye Access Gate, y cada certificado de confianza que presenta en lugar de uno autofirmado que genera una advertencia del navegador, se apoya en una PKI (infraestructura de clave pública). La PKI es la cadena de confianza que permite a un cliente verificar que realmente está hablando con el Gate, y permite al Gate emitir certificados para los activos que protege. Esta página explica por qué importa, por qué la PKI suele ser la parte difícil y las dos formas de desplegarla con Access Gate.
Por qué importa una PKI
Un certificado por sí solo no prueba nada; lo que lo hace fiable es la autoridad que lo firmó. Una PKI es esa autoridad y toda la maquinaria que la rodea: emite certificados, responde por ellos mediante una cadena de firma y ofrece a cada parte una forma de comprobar que un certificado remonta hasta una raíz en la que confía.
Sin ella, queda gestionar a mano certificados autofirmados dispositivo a dispositivo. Cada dispositivo nuevo significa otro certificado no confiable, otra advertencia del navegador y otro operador entrenado para ignorar la advertencia que se supone debe detener un ataque de intermediario. Una PKI reemplaza eso por un único ancla de confianza: confíe en la raíz una vez y todos los certificados bajo ella se confían automáticamente.
Por qué la PKI es difícil
La criptografía no es el problema. Lo es el ciclo de vida. Un despliegue real tiene que resolver todo esto a la vez:
- Emisión y distribución. Cada punto final necesita el certificado correcto, y cada cliente debe confiar en el emisor. Llevar el material adecuado al lugar adecuado, a escala, es el grueso del trabajo.
- Listas de confianza. Ambos lados deben confiar en la cadena. Un intermedio que falta o una raíz no confiable, y la conexión se rechaza, a menudo con un error opaco.
- Rotación y caducidad. Los certificados caducan por diseño. Un certificado caducado es una interrupción, y renovar certificados a mano en toda una flota es lento y propenso a errores, así que se posterga.
- Revocación. Cuando una clave se ve comprometida, necesita una forma de retirar la confianza de su certificado antes de que el atacante lo use.
- Escala en OT. Los dispositivos de campo a menudo no pueden ejecutar un agente de certificados, o no se pueden tocar en absoluto. Una PKI por dispositivo es sencillamente impracticable para los equipos que más la necesitan.
Por eso tantas instalaciones despliegan el cifrado de forma insuficiente. No porque TLS sea difícil, sino porque asumir el ciclo de vida de los certificados para cientos de dispositivos lo es.
Cómo funciona la PKI de Access Gate
Access Gate ejecuta una PKI de forma predeterminada y usa un modelo de certificados de dos niveles que traslada el ciclo de vida fuera de los dispositivos y hacia el Gate:
- Un certificado intermedio, firmado por su autoridad de certificación, que nunca abandona el dispositivo.
- Certificados terminales, generados dinámicamente a partir del intermedio y entregados a activos y clientes para establecer cada túnel seguro.
Como los certificados terminales se emiten bajo demanda en el Gate, no aprovisiona certificados dispositivo a dispositivo. El Gate se convierte en el punto de emisión, y los activos heredados que están detrás de él permanecen intactos. Ese es el cambio que hace que la PKI sea practicable en un parque OT.
La emisión está conectada a su configuración. Las redes (vnets) que define en los ajustes de Access Gate, y sus subdominios, se usan de forma nativa para nombrar y firmar los certificados terminales que genera el Gate, de modo que no hay un paso aparte para indicar a la PKI para qué nombres emitir. Está integrado.
Despliegue: dos opciones
Elija según en qué raíz debe confiar el parque.
Opción 1: usar la PKI nativa de Access Gate
La PKI interna de Access Gate es una PKI completa que el propio Gate construye y mantiene: es la raíz y la autoridad de certificación, generando y manteniendo toda la cadena sin ninguna dependencia externa. Vaya a Settings → PKI Management y haga clic en Download TLS certificate. Instale ese certificado en las máquinas cliente para que confíen en los túneles seguros que establece el Gate.
Úselo para sitios que hoy no tienen cifrado y quieren la vía más simple: confía una vez en la raíz propia del Gate y la PKI se encarga de sí misma. Ideal para laboratorios, pilotos y sitios autónomos.
Opción 2: encadenar a su propia autoridad de certificación
La opción intermedia integra Access Gate con una PKI existente. En lugar de ser su propia raíz, el Gate se encadena a la autoridad de certificación de su organización, de modo que emite bajo una confianza que su parque ya reconoce. Access Gate gestiona la lista de dos niveles descrita arriba: el intermedio lo firma su CA y nunca abandona el dispositivo, y los certificados terminales se generan dinámicamente a partir de él.
Los túneles TLS se habilitan en la página Settings → Networking. Haga clic en Generate CSR (CSR = solicitud de firma de certificado) para obtener el documento de firma, fírmelo con su autoridad raíz y cargue el certificado intermedio resultante mediante Upload SCA.
Úselo en producción y en entornos regulados donde los certificados deben encadenarse a una raíz corporativa o de cumplimiento.
Rotación y ciclo de vida de los certificados
El modelo de dos niveles es lo que hace manejable la rotación:
- Los certificados terminales rotan por sí solos. Son de corta duración y se emiten bajo demanda, así que el Gate los reemite automáticamente. No hay nada que renovar por activo, lo que elimina el modo de fallo que causa la mayoría de las interrupciones por certificados.
- El intermedio es el único certificado que usted posee. Otórguele, junto con la raíz que lo firma, validez suficiente (una raíz de firma suele ser válida durante unos 10 años) y vuelva a firmar o renueve el intermedio antes de que caduque.
- Vigile la caducidad del intermedio y de la raíz. Un certificado de firma caducado impide la emisión de nuevos certificados terminales, lo que rompe silenciosamente los túneles nuevos aunque los existentes sobrevivan.
- Atienda la configuración de la CA. La CA de firma necesita suficiente profundidad de cadena para emitir un intermedio que a su vez emita certificados terminales (profundidad de al menos 2). Si usa restricciones de nombre o de dominio en la CA, una buena práctica, asegúrese de que cubran los nombres de vnets para los que emitirá el Gate.
Para saber cómo exigir TLS en un enclave una vez que la PKI está en su lugar, consulte Configurar cifrado TLS.
Resumen
Usó la PKI nativa de Access Gate (descargue su certificado y confíe en él en los clientes) o encadenó el Gate a su propia CA (genere una CSR, fírmela con su raíz y cargue el intermedio). En cualquier caso, el Gate emite certificados terminales dinámicamente y envuelve los activos en un TLS de confianza, de modo que usted gestiona un único intermedio en lugar de un certificado por dispositivo.
Recurra a esto antes de exigir TLS en los enclaves, cuando necesite certificados de confianza en todo el parque sin levantar y mantener a mano un certificado en cada dispositivo.