Zero Trust en IT funciona instalando agentes en los endpoints. El agente verifica el estado del dispositivo, aplica políticas y reporta telemetría. Este modelo no funciona en OT. Los PLCs ejecutan firmware propietario. Los CNCs corren sistemas operativos embebidos de 2005. Los HMIs funcionan con Windows XP Embedded sin posibilidad de actualización. No se puede instalar un agente en ninguno de estos dispositivos. Se necesita un enfoque diferente.
Por qué los agentes no funcionan en OT
Sistemas operativos propietarios
La mayoría de los PLCs y controladores industriales ejecutan sistemas operativos de tiempo real propietarios. Allen-Bradley usa ControlLogix OS. Siemens usa el runtime de Step 7. Los controladores CNC de Fanuc corren su propio firmware. Ninguno de estos admite la instalación de software de terceros.
Restricciones de tiempo real
Los controladores industriales operan en ciclos deterministas medidos en milisegundos. Un PLC que escanea I/O cada 10 ms no puede tolerar la carga de CPU ni el jitter de temporización que introduce un agente de seguridad. Incluso un retraso momentáneo puede provocar un fallo de seguridad o una parada de producción.
Sin ruta de actualización
Muchos dispositivos OT llevan ejecutando el mismo firmware durante 10 o 20 años. Es posible que el fabricante ya no exista. Incluso cuando hay actualizaciones disponibles, aplicarlas requiere tiempo de inactividad en producción y recalificación. El coste de parchear suele superar el valor del dispositivo.
Certificación y garantía
Los equipos industriales suelen estar certificados para configuraciones específicas. Instalar software no autorizado anula la garantía y puede invalidar las certificaciones de seguridad. En sectores regulados, esto es inviable.
La alternativa en la capa de red
En lugar de asegurar el dispositivo, se asegura el camino hacia él. Un proxy con reconocimiento de identidad se sitúa entre el usuario y el activo OT. Toda conexión pasa por el proxy, que:
- Autentica al usuario con MFA antes de establecer la sesión
- Autoriza la sesión según rol, activo, protocolo y ventana temporal
- Registra la sesión con identidad del usuario, marca de tiempo y carga útil
- Cifra la conexión entre el usuario y el proxy
- Aísla el activo en un microsegmento con reglas de denegación por defecto
El dispositivo OT continúa operando exactamente igual que siempre. Ve el mismo protocolo, los mismos patrones de tráfico, la misma temporización. La aplicación de controles ocurre en el proxy, no en el dispositivo.
Qué se obtiene sin agentes
| Capacidad | Basado en agente | Capa de red |
|---|---|---|
| Verificación de identidad | Sí | Sí (en el proxy) |
| Aplicación de MFA | Sí | Sí (en el proxy) |
| Registro de sesiones | Sí | Sí (en el proxy) |
| Inspección de protocolos | Limitada | Sí (inspección profunda de paquetes) |
| Verificación del estado del dispositivo | Sí | No |
| Funciona en OT heredado | No | Sí |
| Impacto en producción | Riesgo de interrupción | Ninguno |
La única capacidad que se pierde es la atestación del estado del dispositivo. No es posible verificar el estado interno de un PLC desde la red. Pero sí se puede verificar y controlar cada conexión hacia y desde él, que es lo que CMMC, NIS2 e IEC 62443 realmente exigen.
La arquitectura superpuesta
Access Gate se despliega como appliance físico o VM adyacente a la red existente. Crea una red superpuesta usando el espacio de direcciones 100.64.0.0/16. Cada activo OT obtiene un endpoint proxy. La capa superpuesta gestiona identidad, control de acceso, registro y cifrado. La capa subyacente (switches, VLANs y cableado existentes) permanece intacta.
A veces se denomina "arquitectura lollipop" porque cada activo tiene un único camino controlado (el palo) hacia su proxy (el caramelo). Sin movimiento lateral entre activos. Sin conexiones no autenticadas. Sin sesiones sin registrar.
Para más recursos sobre Zero Trust en OT, guías de arquitectura y comparativas, visita el centro de recursos Zero Trust para redes OT.
