Seguridad

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

PilarQué protege
CifradoConfidencialidad: nadie puede leer el tráfico
FirmaIntegridad: los mensajes no se pueden manipular
AutenticaciónIdentidad, de la aplicación (certificado) y del usuario
AutorizaciónPermisos: 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
El fallo clásico de la primera conexión:el certificado del par acaba enrejected/. 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

  1. Use Sign & Encrypt con una política moderna; desactive None y las políticas obsoletas.
  2. Sustituya los certificados por defecto o autofirmados por otros gestionados; fije una caducidad razonable y rote.
  3. Exija usuarios nominales; desactive el anónimo cuando sea posible.
  4. Aplique autorización de mínimo privilegio: solo lectura salvo que la escritura sea realmente necesaria.
  5. Mantenga las CRL al día; elimine los certificados obsoletos de trusted/.
  6. Ponga OPC UA en una red segmentada; restrinja el puerto a clientes conocidos.
  7. Parchee su stack de OPC UA: trátelo como cualquier otro servicio en red.
¿Atascado en un error de handshake ahora mismo? Salte adiagnóstico de conexión.

Última actualización: 4 de septiembre de 2026 · Recurso educativo.

Siguiente: herramientas y servidores de prueba →

Descarga gratuita
Lista de comprobación de diagnóstico e integración OPC UA
La lista de comprobación probada en campo que usan los ingenieros para diagnosticar rápido problemas de certificados, puertos y espacios de nombres, más una plantilla de cliente en Python (asyncua).
Obtenga la lista gratuita →
Gratis, sin curso, sin registro