Seguridad TI/OT convergente con arquitectura de confianza cero
Actualizado: 12 oct
Un ingeniero necesita revisar una alarma HMI desde una estación administrada. Que esa estación esté dentro de la red corporativa no demuestra que deba acceder a esa máquina, qué acciones puede realizar ni cuándo debe terminar el permiso.
La arquitectura de confianza cero somete el acceso a un recurso a una decisión explícita sobre la persona, el dispositivo, la solicitud y la política. En tecnología operativa (OT), esa decisión también debe respetar la disponibilidad, la fiabilidad y la seguridad del proceso.
Puntos clave
Estar dentro de una red empresarial o de planta no confiere confianza por sí solo. El acceso a un recurso concreto exige autenticación y autorización [1].
La convergencia TI/OT no exige conectar cada controlador a un servicio de identidad o a la nube. Los límites de acceso administrados pueden proteger funciones de control que deben seguir siendo locales.
Un router, cortafuegos, VPN, servidor de salto o servicio de acceso puede aplicar una parte de la política. Ningún equipo, por sí solo, acredita una arquitectura completa de confianza cero.
La segmentación de red sigue siendo útil. Una VLAN o una regla de cortafuegos no decide por sí sola si una persona y su dispositivo pueden acceder a un recurso específico.
Empiece con un inventario de usuarios, activos, flujos, responsables y límites operativos. Pruebe los cambios de política por etapas antes de ampliarlos a producción.
Qué cambia la confianza cero
Según NIST, la ubicación física o de red y la propiedad del activo no otorgan confianza implícita al usuario o al equipo. Se autentican y autorizan el sujeto y el dispositivo antes de establecer una sesión con un recurso empresarial [1]. La atención se centra en el recurso y en la decisión de acceso, no en presumir que todo el tráfico de un segmento interno es seguro.
Esto no implica instalar un agente de identidad moderno en cada controlador industrial ni unir las redes sin límites. Muchos equipos OT tienen funciones fijas, ciclos de vida largos y ventanas de mantenimiento reducidas. Las directrices de NIST para OT resaltan sus requisitos particulares de rendimiento, fiabilidad y seguridad [2].
En una instalación industrial, aplique el principio en un límite que el equipo pueda operar. La ubicación exacta depende del activo, del diseño del control y de los servicios disponibles de identidad y supervisión. La expresión «confianza cero» en una ficha de producto no resuelve esa decisión de diseño.
Capacidades que deben verificarse en el límite entre TI y OT
Las cinco áreas de capacidad siguientes describen funciones que se deben evaluar en el despliegue, no características garantizadas en todos los routers industriales. Antes de confiar en una etiqueta comercial, identifique el componente responsable, el alcance que admite y quién se encarga de operarlo.
Área de capacidad | Función en el despliegue | Qué verificar |
|---|---|---|
Decisión y aplicación de políticas | Los servicios de identidad y políticas deciden el acceso; una pasarela o un host adecuados lo aplican. | Identifique los componentes que deciden, aplican y revocan el acceso, junto con sus entradas y registros; un router por sí solo no constituye toda la arquitectura. |
Segmentación basada en protocolos | Restringir los flujos industriales autorizados y, cuando se admita, operaciones concretas. | Compruebe las versiones exactas de los protocolos, la visibilidad de la inspección, los límites que impone el cifrado y las funciones permitidas. No dé por sentado que todos los routers inspeccionan comandos Modbus, PROFINET, DNP3 u OPC UA. |
Supervisión de amenazas y análisis | Recopilar registros pertinentes y evaluar la actividad frente a los flujos autorizados mediante componentes de supervisión adecuados. | Compruebe la telemetría, el alcance de detección, las integraciones y los recursos operativos. El aprendizaje automático integrado es una capacidad específica de cada producto, no una propiedad general de los routers. |
Respuesta controlada a incidentes | Revocar el acceso o contener una ruta afectada mediante un proceso operativo autorizado. | Valide los efectos sobre la operación y la seguridad funcional, quién aprueba y responde, los registros y el procedimiento de reversión antes de aplicar cambios automáticos; no dé por sentada la integración con SOAR ni que aislar automáticamente un PLC sea seguro. |
Acceso remoto específico por recurso | Dar a un usuario identificado y a un dispositivo administrado solo el acceso necesario para el recurso y la tarea aprobados. | Compruebe la autenticación, la autorización, la duración del acceso, el registro de sesiones y la revocación. Si un equipo OT no puede ejecutar un agente de identidad, utilice una pasarela compatible o un equipo de ingeniería. |
Antes de que una medida automática de contención modifique una ruta de comunicación OT, compruebe sus efectos sobre la disponibilidad del proceso y la seguridad funcional, designe a la persona responsable y pruebe cómo revertir el cambio.
Dibuje la ruta de acceso y asigne responsables
Antes de comprar una solución o cambiar rutas, represente el camino de una tarea real. Por ejemplo:
ingeniero identificado en dispositivo administrado → identidad y política de acceso → punto de aplicación supervisado → zona de acceso OT → estación de ingeniería o destino autorizado
Para la tarea concreta de mantenimiento, aplique el flujo de acceso remoto al PLC y al HMI y pruebe la ruta de la aplicación desde el ingeniero hasta el equipo.
En cada paso, registre la identidad del usuario o servicio, el estado exigido al dispositivo, el recurso de destino, el protocolo permitido, quién aprueba el trabajo, la duración del acceso y los registros que operaciones puede revisar. Distinga el sistema que toma la decisión del que la aplica y de la persona que puede revocarla.
La ruta puede incluir un proveedor de identidad, un servicio de acceso remoto, una pasarela VPN, un cortafuegos, una DMZ OT, un servidor de salto y una estación de ingeniería. Son funciones diferentes aunque un despliegue combine varias. En el modelo de NIST, el motor de políticas y el administrador de políticas intervienen en la decisión, mientras que el punto de aplicación habilita, supervisa y termina la conexión [1].
Mantenga el alcance reducido. Consultar una alarma no justifica una ruta general a todos los PLC y HMI. Separe el acceso de ingeniería de la telemetría habitual y de las rutas que puedan cambiar el proceso. Defina qué ocurrirá si falla el servicio de identidad, la pasarela o el enlace WAN; el control local no debe depender de un servicio de acceso remoto sin ensayar.
Segmente la red sin confundir segmento con confianza
Las zonas, los cortafuegos, las VLAN y las listas de control de acceso limitan qué sistemas pueden comunicarse. Ayudan a trazar fronteras entre TI empresarial, supervisión OT y redes de control.
Por sí solos no verifican quién y desde qué dispositivo solicita una sesión, ni si la operación prevista está autorizada.
Para implementar la red, diseñe las VLAN y el tráfico inter-VLAN permitido según los orígenes, destinos y servicios necesarios.
Utilice los controles de red para aplicar los caminos definidos en la política. En cada frontera permita solo el origen, destino, protocolo y sentido necesarios. Conserve la configuración y los registros para que la instalación pueda explicar por qué existe un camino y quién lo aprobó.
Si un equipo no admite autenticación individual, un servicio de acceso o una estación de ingeniería controlada puede servir de intermediario para aplicar y auditar la decisión. Compruebe que esa mediación respeta los requisitos de funcionamiento del fabricante.
Evite excepciones amplias para una «subred OT de confianza» que permitan a cualquier estación conectada alcanzar todos los controladores. Tampoco modifique la red de control sin una ventana de mantenimiento aprobada, una copia de seguridad probada y un responsable de la reversión. Las guías de OT consideran conjuntamente arquitectura, protección de fronteras y restricciones operativas [2].
Despliegue las políticas por etapas
Inventarie activos y accesos. Registre controladores, HMI, estaciones de ingeniería, pasarelas, servicios, usuarios, proveedores y flujos actuales. Señale los equipos que no pueden modificarse o supervisarse directamente.
Delimite el proceso. Identifique qué debe permanecer local por razones de control y seguridad, qué sistemas de supervisión consumen datos y qué caminos entre zonas están autorizados.
Asigne la decisión y su aplicación. Nombre quién verifica la identidad del usuario y dispositivo, quién aprueba el acceso al recurso, qué pasarela o estación hace cumplir la política y quién revisa registros y revocaciones.
Redacte una política mínima. Empiece con un usuario o servicio identificado, un recurso, el protocolo necesario y un periodo definido. Documente restricciones y requisitos de conexión para cada tipo de acceso remoto y autorice ese tipo antes de habilitarlo [3]. Asigne responsable a cada excepción.
Pruebe fuera de producción o durante mantenimiento. Verifique el acceso permitido, el bloqueo de otras rutas, la visibilidad en registros, el comportamiento del control local y la reversión. Incluya fallos representativos del equipo y del servicio de acceso.
Amplíe solo tras revisar resultados. Compare los flujos observados con el diseño aprobado. Elimine caminos y credenciales sin uso; repita los ensayos pertinentes tras cambios importantes de identidad, pasarelas, reglas, firmware o red de control.
Una pantalla que muestra menos rutas no constituye una aceptación. Los operadores autorizados deben poder realizar su trabajo, las rutas no autorizadas deben quedar bloqueadas, el control local debe conservar su funcionamiento previsto y los responsables deben poder detectar fallos y recuperarse de ellos.
Trate por separado las demás decisiones de red
La confianza cero no selecciona el protocolo VPN, el operador móvil ni el método de recuperación WAN. Cada elección requiere sus propias pruebas de extremos, rutas y fallos. Si varias redes de máquinas reutilizan las mismas direcciones IP, resuelva ese solapamiento antes de abrir el acceso entre instalaciones: un motor de políticas no vuelve inequívocas las rutas superpuestas. Consulte Cómo conectar varios PLC con la misma IP mediante NAT y VPN para el diseño de direccionamiento.
Si el acceso depende de varios enlaces WAN, pruebe la sesión remota y la recuperación de la instalación cuando falle una ruta. Los responsables de la aplicación y de operaciones deben determinar qué recuperación es aceptable; la redundancia no garantiza una transición transparente. La guía Failover, balanceo de carga y bonding para 5G y Starlink aborda esa decisión distinta.
Conclusión: haga explícita cada decisión de acceso
La confianza cero es una forma de decidir el acceso a recursos, no una etiqueta de función de router ni un sustituto del diseño de redes OT. Comience por una persona, un dispositivo, una tarea y un destino. Sitúe el punto de aplicación donde la instalación pueda mantenerlo, limite la ruta autorizada y valide tanto el acceso como la denegación sin alterar el control local.
Antes de extender una política a más equipos de producción, reúna a los responsables de control, seguridad y operaciones para revisar el inventario, los flujos permitidos, los escenarios de fallo y el plan de reversión.
Preguntas frecuentes
¿Confianza cero significa no confiar en nada de la red?
No. Significa que la ubicación de red o la propiedad de un equipo no conceden confianza implícita. El modelo de NIST exige autenticar y autorizar al sujeto y al dispositivo antes de una sesión con el recurso [1]. La política sigue definiendo qué solicitudes se permiten.
¿Sustituye a una VPN o a un cortafuegos?
No. Una VPN puede proteger una ruta de comunicación y un cortafuegos puede aplicar fronteras de red. Pueden formar parte del diseño, pero no proporcionan automáticamente todas las decisiones sobre identidad, dispositivo, recurso, registros y ciclo de vida del acceso.
¿Equivale una VLAN o una DMZ OT a confianza cero?
No. La segmentación limita la conectividad entre sistemas. Por sí sola no autentica a una persona y su dispositivo para solicitar un recurso concreto. Combínela con políticas de acceso y procedimientos operativos.
¿Puede un router industrial proporcionar la arquitectura completa?
No lo dé por hecho. Un router o cortafuegos puede aplicar parte de una ruta si el modelo y firmware exactos, la integración de identidad, el alcance de la política y los registros cumplen el requisito. El conjunto también depende de servicios de identidad, responsables del recurso, ciclo de vida del acceso, supervisión y operación OT.
¿Debe cada PLC o HMI ejecutar software de confianza cero?
No necesariamente. Algunos dispositivos OT no pueden alojar agentes de identidad modernos ni admitir actualizaciones frecuentes. Defina un límite de acceso controlado alrededor de esos recursos y compruebe que el intermediario respeta los requisitos del equipo y del proceso.
¿Por dónde puede empezar una fábrica?
Inventarie activos y flujos, elija una tarea remota que necesite un acceso más estricto y asigne un responsable. Diseñe una política y una ruta de aplicación acotadas. Pruebe la tarea autorizada, la denegación, los registros, el fallo del servicio y la reversión antes de ampliar el alcance.
