Seguridad y certificados de OPC UA
La seguridad está integrada en OPC UA, no añadida a posteriori. Una conexión negocia una política de seguridad y un modo, y después cliente y servidor se autentican mutuamente con certificados X.509. Entender estas dos ideas (modos y confianza) resuelve la mayoría de las dudas de seguridad y de los fallos de conexión.
Los cuatro pilares
| Pilar | Qué protege |
|---|---|
| Cifrado | Confidencialidad: nadie puede leer el tráfico |
| Firma | Integridad: los mensajes no se pueden manipular |
| Autenticación | Identidad, de la aplicación (certificado) y del usuario |
| Autorización | Permisos: qué puede hacer un usuario autenticado |
Modos de seguridad
- None: sin firma ni cifrado. Solo para pruebas aisladas.
- Sign: los mensajes se firman (integridad + autenticación) pero no se cifran.
- Sign & Encrypt: firmado y cifrado. Use este modo en producción.
Cada modo se empareja con una política de seguridad (el conjunto de cifrado, p. ej. Basic256Sha256 o las políticas Aes256 más recientes). Prefiera políticas modernas y deshabilite las obsoletas.
Cómo funciona la confianza de certificados
Cada aplicación OPC UA tiene su propio certificado de instancia. Al conectar, cliente y servidor intercambian certificados; cada uno mantiene un pequeño almacén PKI:
pki/
├─ own/ # this application's own cert + private key
├─ trusted/certs # certificates we trust
├─ trusted/crl # certificate revocation lists
├─ issuer/ # CA certs (if using a CA)
└─ rejected/ # certs seen but not yet trusted
rejected/. Muévalo atrusted/certsen ambos extremos, y después reconecte. Este único paso arregla casi todos los errores "BadSecurityChecksFailed".Autofirmado frente a firmado por CA
Los certificados autofirmados valen para despliegues pequeños y estáticos, en los que se confía manualmente en cada uno. Para parques grandes, una autoridad de certificación (o el GDS de OPC UA, el Global Discovery Server) escala la confianza: se confía una vez en la CA y todos los certificados que emita quedan confiados automáticamente.
Autenticación de usuario
La identidad de aplicación (certificado) es distinta de la identidad de usuario. Un servidor puede aceptar tokens anónimos, de usuario/contraseña o de certificado de usuario. Ajústese a lo que espere el servidor, y prefiera usuarios con nombre al acceso anónimo en producción para que las acciones sean atribuibles.
Lista de bastionado
- Use Sign & Encrypt con una política moderna; desactive None y las políticas obsoletas.
- Sustituya los certificados por defecto o autofirmados por otros gestionados; fije una caducidad razonable y rote.
- Exija usuarios nominales; desactive el anónimo cuando sea posible.
- Aplique autorización de mínimo privilegio: solo lectura salvo que la escritura sea realmente necesaria.
- Mantenga las CRL al día; elimine los certificados obsoletos de
trusted/. - Ponga OPC UA en una red segmentada; restrinja el puerto a clientes conocidos.
- Parchee su stack de OPC UA: trátelo como cualquier otro servicio en red.
Última actualización: 4 de septiembre de 2026 · Recurso educativo.