Comprender la autenticación OPC-UA en entornos aislados
Una red aislada no puede alcanzar una autoridad de certificación externa ni descargar una lista de revocación de certificados (CRL) desde internet. Entonces, ¿cómo se ejecuta OPC-UA con una autenticación adecuada cuando toda la infraestructura de clave pública (PKI) debe residir dentro del enclave? Ese es el reto concreto que aborda este artículo: implementar la autenticación de OPC-UA en redes aisladas (air-gapped) donde los patrones conectados a la nube, que asume la mayoría de la documentación, sencillamente no existen.
Lo primero que conviene dejar claro es que OPC-UA autentica en dos niveles distintos, y confundirlos es la causa más común de configuración incorrecta. El protocolo separa la autenticación de la aplicación, que establece la confianza entre un proceso cliente y un proceso servidor, de la autenticación del usuario, que establece la identidad de la persona o cuenta de servicio que está detrás de una sesión. Ambos niveles se definen en el modelo de seguridad de la OPC Foundation. Consulte OPC UA Part 2: Security Model para la descripción normativa de cómo interactúan, incluido el modelo de amenazas para el que se diseñó el estándar.
Nivel uno: autenticación de la aplicación con certificados de instancia
Toda aplicación OPC-UA conforme, ya sea cliente o servidor, posee un certificado de instancia de aplicación (Application Instance Certificate). Se trata de un certificado X.509 que vincula una clave pública a una instancia de software concreta, identificada por su ApplicationUri. Cuando un cliente abre un SecureChannel hacia un servidor, ambas aplicaciones intercambian certificados y cada una decide si confía en la otra. Esa decisión no se toma consultando un directorio en línea. Se toma localmente, frente a una lista de confianza (trust list).
Una lista de confianza es el conjunto de certificados, almacenado en disco, que una aplicación aceptará. Se divide en dos almacenes. El almacén de confianza contiene bien los certificados hoja de los pares en los que confía explícitamente, bien los certificados de CA cuyos certificados emitidos acepta por cadena. El almacén de emisores contiene los certificados de CA intermedios y raíz necesarios solo para completar la validación de cadena, además de las CRL. La mecánica de esta validación, y la estructura de la propia lista de confianza, se especifican en OPC UA Part 6: Mappings, que define los formatos de archivo y los pasos de validación que una pila debe ejecutar antes de aceptar un canal.
En un despliegue conectado, un Global Discovery Server (GDS) automatiza la distribución de las listas de confianza y la inscripción de certificados en toda la planta. En un despliegue aislado, no hay un GDS alcanzable, por lo que la gestión de las listas de confianza se convierte en una operación manual y deliberada. Esta es la diferencia arquitectónica central, y de ella se deriva el resto del artículo.
Nivel dos: autenticación del usuario y tokens de identidad
Una vez que dos aplicaciones confían entre sí y existe un SecureChannel, el cliente abre una Session y presenta un token de identidad de usuario (user identity token). OPC-UA define tres tipos de token, en orden ascendente de garantía:
- Anónimo: no se afirma ninguna identidad de usuario. La sesión hereda únicamente los permisos que el servidor concede a los llamantes no autenticados. Aceptable solo para datos no sensibles de solo lectura, y preferiblemente deshabilitado en producción.
- Usuario y contraseña: el cliente envía un nombre de usuario y una contraseña cifrados con la clave pública del servidor. Es sencillo, pero hereda todas las debilidades operativas de los secretos compartidos: rotación, almacenamiento y el riesgo de reutilización de credenciales entre sistemas.
- Certificado X.509: el usuario presenta un certificado y demuestra la posesión de la clave privada. Esto proporciona identidad criptográfica por usuario, capacidad de revocación y un rastro de auditoría limpio, a cambio de gestionar una segunda población de certificados junto a la de las aplicaciones.
El punto crítico para el diseño en entornos aislados es que estos dos niveles son independientes. Puede ejecutar seguridad de aplicación SignAndEncrypt con tokens de usuario Anónimo, o un transporte de aplicación sin asegurar con tokens de usuario y contraseña, y ambas son configuraciones incorrectas. Una autenticación fuerte asegura ambos niveles a la vez: certificados de aplicación de confianza que establecen un canal cifrado y, sobre él, un token de usuario no anónimo que establece la rendición de cuentas.
Políticas de seguridad y SignAndEncrypt
La protección aplicada al propio SecureChannel se rige por el MessageSecurityMode y la SecurityPolicy elegida. Existen tres modos de seguridad: None, Sign y SignAndEncrypt. None no ofrece protección alguna y nunca debe usarse fuera de un laboratorio. Sign garantiza la integridad y la autenticidad, pero deja las cargas útiles legibles en la red. SignAndEncrypt garantiza la integridad, la autenticidad y la confidencialidad, y es el único modo adecuado para el tráfico OT en producción.
La SecurityPolicy selecciona la suite criptográfica efectiva. Las políticas antiguas basadas en SHA-1 y RSA-15, como Basic128Rsa15 y Basic256, están obsoletas y deben deshabilitarse. Los despliegues actuales deben exigir Aes256_Sha256_RsaPss o, donde sea compatible, las políticas basadas en ECC. El catálogo completo de políticas y sus primitivas criptográficas se mantiene en OPC UA Part 2: Security Model. Fijar los servidores a SignAndEncrypt con una política moderna, y rechazar explícitamente None y las suites obsoletas, cierra la principal vía de degradación que de otro modo un atacante intentaría sondear.
Gestión de certificados sin un GDS en la nube
Aquí es donde los despliegues aislados se apartan claramente de la teoría. Sin una autoridad de certificación alcanzable por internet ni un GDS en línea, todo el ciclo de vida de los certificados debe diseñarse como un flujo de trabajo sin conexión.
Operar una autoridad de certificación sin conexión
Establezca una autoridad raíz dedicada y sin conexión dentro del enclave, sobre hardware que nunca toque una red externa. Mantenga la clave raíz sin conexión y úsela únicamente para firmar una autoridad emisora intermedia; la intermedia realiza la emisión cotidiana. Este diseño de dos niveles limita la exposición de la clave raíz y permite revocar y reemitir la intermedia sin reconstruir cada extremo. Las recomendaciones del NIST sobre seguridad de sistemas de control industrial consideran este tipo de PKI administrada internamente, con una gestión de claves documentada, como un control básico para redes aisladas. Consulte NIST SP 800-82 Rev. 3, Guide to Operational Technology Security.
Distribuir las listas de confianza manualmente
Como no hay un GDS alcanzable, las listas de confianza se distribuyen manualmente. Exporte el certificado de la autoridad y los certificados de aplicación de cada extremo, transfiéralos a través del enclave en un soporte extraíble controlado y analizado, conforme a su procedimiento de manejo de soportes, e instálelos en los almacenes de confianza y de emisores de cada aplicación. Trate esta operación como un cambio controlado, con un inventario registrado de qué certificado reside en qué extremo, porque ese inventario será el único mapa del que dispondrá durante un incidente.
Resolver la revocación sin conexión
Los puntos de distribución de CRL y los respondedores OCSP asumen ambos una infraestructura alcanzable, de modo que ninguno funciona a través de un enclave de forma predeterminada. Tiene dos opciones realistas. O bien generar las CRL en la autoridad sin conexión y distribuirlas con la misma cadencia controlada que las listas de confianza, aceptando que la latencia de revocación equivale a su intervalo de distribución, o bien, para la postura más robusta, tratar la propia lista de confianza como la autoridad de referencia: eliminar directamente un certificado comprometido de cada almacén de confianza. Tanto el NIST SP 800-82 como las recomendaciones más amplias del NIST SP 800-57 sobre gestión de claves subrayan que un proceso de revocación debe existir y probarse, no solo diseñarse, antes de confiar en la PKI.
Planificar la renovación en torno a las ventanas de mantenimiento
Los certificados caducan, y un certificado de aplicación caducado romperá silenciosamente un SecureChannel. Realice un seguimiento centralizado de la ventana de validez de cada certificado, programe la rotación antes de la caducidad y ensaye la rotación durante una ventana de mantenimiento planificada en lugar de descubrir la dependencia en plena producción. La renovación sin conexión es un ciclo manual de reemisión y redistribución, por lo que necesita un margen de tiempo previsto en el calendario de mantenimiento.
Reunir los niveles
Un despliegue OPC-UA aislado defendible se presenta así en la práctica. Los servidores exigen el MessageSecurityMode SignAndEncrypt con una SecurityPolicy moderna y rechazan todo lo más débil. Los certificados de instancia de aplicación los emite la autoridad intermedia sin conexión y están presentes en ambos extremos, con listas de confianza que contienen únicamente los certificados que deben estar ahí. El token de usuario Anónimo está deshabilitado, y las sesiones se autentican por usuario y contraseña o, preferiblemente, por certificado X.509, de modo que cada acción se vincule a una identidad. La revocación y la renovación siguen una cadencia sin conexión documentada, respaldada por un proceso probado.
Superar los retos habituales
Sistemas heredados
Algunos extremos antiguos solo admiten políticas obsoletas, o ninguna seguridad de mensajes en absoluto. En lugar de debilitar toda la planta para adaptarse a ellos, coloque estos dispositivos detrás de una pasarela que termine un canal seguro en su nombre, o dentro de un enclave estrictamente delimitado que restrinja quién puede alcanzarlos. El objetivo es contener el eslabón débil, no rebajar el nivel para todo lo demás.
Cumplimiento y normas
Una PKI administrada internamente, una gestión de claves documentada y un proceso de revocación probado se corresponden directamente con los controles que esperan marcos como NIS2 y CMMC, así como con las recomendaciones específicas de OT del NIST SP 800-82. Diseñar el ciclo de vida sin conexión de forma deliberada es también lo que hace posible una auditoría limpia más adelante.
Formación y concienciación
La distribución manual de listas de confianza y la renovación sin conexión son procedimientos, y los procedimientos fallan cuando las personas que los ejecutan no comprenden por qué existe cada paso. Invierta en los runbooks y la formación que los acompañan, porque en una PKI aislada el proceso humano es el control.
Conclusión
La conclusión clave: en los entornos aislados, su autoridad de certificación sin conexión y la disciplina de su distribución manual de listas de confianza son los componentes de seguridad más críticos. Domine la gestión de claves de la autoridad sin conexión, el procedimiento de distribución de listas de confianza, la vía de revocación y el calendario de renovación antes de desplegar la autenticación OPC-UA en toda la planta. Fije cada servidor a SignAndEncrypt con una política moderna, deshabilite el acceso anónimo y autentique a los usuarios por certificado siempre que pueda. Pruebe la rotación de certificados durante una ventana de mantenimiento, no en producción. Una vez que la PKI sin conexión sea sólida, el modelo de seguridad integrado de OPC-UA es plenamente utilizable sin ninguna conexión a internet.
