SCADA moderno en contenedores: ventajas y riesgos

Actualizado: 2026-05-03

Los sistemas SCADA (Supervisory Control and Data Acquisition) nacieron como software monolítico sobre Windows Server con bases de datos propietarias. Hoy, la tendencia es contenerizar esas cargas para aprovechar despliegue declarativo, escalado horizontal y observabilidad estándar. La pregunta no es si tiene sentido, sino en qué capas sí lo tiene y cuáles deben permanecer fuera del contenedor.

Puntos clave

• Los PLCs siguen siendo la base del control determinista; los contenedores modernizan las capas superiores.
• Productos como Ignition 8 y PTC ThingWorx soportan containerización de forma oficial.
• El mayor riesgo no es técnico sino cultural: aplicar patrones DevOps sin respetar el contexto OT produce incidentes.
• Air-gap, policy enforcement estricta y monitoring OT-específico son requisitos, no opciones.
• NIS2 exige cumplimiento en infraestructura crítica independientemente de si se usan contenedores.

Por qué contenerizar SCADA

Las ventajas concretas están en las capas superiores de la arquitectura:

• Despliegue reproducible: el mismo setup en dev, staging y producción elimina el “funciona en mi máquina” de los entornos OT históricos.
• Actualizaciones incrementales: un rolling update reemplaza el tradicional “apagar sistema y migrar”, que en plantas continuas puede costar millones.
• Escalado de frontends HMI: múltiples instancias con balanceo sin duplicar licencias ni hardware.
• Observabilidad estándar: Prometheus, Grafana y Loki funcionan sobre Kubernetes igual que sobre cualquier workload IT.

Los productos que soportan containerización

No todos los SCADA son iguales frente a contenedores:

• Inductive Automation Ignition^[1]: Ignition 8+ tiene imágenes Docker oficiales. El ecosistema de módulos funciona en contenedor.
• PTC ThingWorx^[2]: Kubernetes en despliegues enterprise con helm charts mantenidos.
• FUXA^[3] (open-source): nativo en contenedores, ideal para instalaciones pequeñas.
• AVEVA System Platform: opciones emergentes con soporte parcial.

El problema fundamental: OT no es IT

SCADA opera maquinaria física. Un fallo no produce un 500 en un log, produce parada de planta, riesgo para personas o daños en equipos. Esta diferencia invalida la mayor parte de los supuestos DevOps:

• Un kubectl rollout restart no es aceptable si afecta el control de un reactor.
• El modelo de “siempre disponible con reintentos” choca con el determinismo temporal de los PLCs.
• Los upgrades de dependencias automáticos pueden romper invariantes de seguridad funcional.

Consecuencia: la decisión de qué contenerizar y qué no debe empezar por la criticidad, no por la moda técnica.

Arquitecturas que funcionan

Capa de edge con contenedores + PLC real

La arquitectura más pragmática separa control y supervisión:

• Los PLCs (Siemens, Rockwell, Omron) controlan el hardware directamente con determinismo duro.
• Un gateway containerizado agrega datos vía OPC UA y los expone al historian.
• El HMI corre en contenedor con acceso web: actualizaciones sencillas, sin licencias por puesto.
• El historian containerizado acumula datos históricos sin depender de servidores dedicados.

Cluster Kubernetes OT dedicado

Para instalaciones más grandes:

• Kubernetes on-premise dedicado a cargas OT, físicamente separado del Kubernetes IT corporativo.
• GitOps para deploys de HMI y historian: cada cambio trazable y reversible.
• Prometheus en el mismo cluster para métricas de aplicación y operativas.

Transición híbrida

La secuencia más segura para modernizar sin parar la planta:

1. Nuevas HMIs en contenedores primero.
2. Historians migran a contenedores manteniendo la escritura original.
3. Interfaces de PLC permanecen bare-metal hasta que exista un plan validado.
4. Dashboard agregado sobre todo desde el primer día.

Riesgos de seguridad OT

Ser honesto sobre lo que se abre al contenerizar:

• Docker socket expuesto equivale a control total del host; en OT eso significa control de la red operativa.
• Kubernetes API accesible por error de red policy da acceso al cluster completo.
• Imágenes no firmadas abren la puerta a supply chain attacks, críticos en infraestructura que opera maquinaria.
• Red overlay mal segmentada facilita movimiento lateral desde IT hacia OT.

La ISA/IEC 62443 define el modelo Purdue (L0 campo, L1 control, L2 HMI, L3 operaciones, L4 empresa). Los contenedores pueden borrar esos límites si no hay disciplina de red y policy. Ver también cómo Kubernetes gestiona seguridad de red con Cilium y eBPF para reforzar el aislamiento.

Mitigaciones esenciales

Cinco prácticas que reducen el riesgo a niveles operativos aceptables:

• Air-gap real entre el cluster OT y cualquier red IT o internet.
• Infraestructura inmutable: ningún cambio en caliente; todo rebuild y redespliegue.
• Policy enforcement estricta con Kyverno o Gatekeeper: qué imágenes pueden correr, qué capabilities tienen, qué namespaces hablan entre sí.
• Monitoring OT-específico con herramientas como Claroty o Nozomi superpuestas al Prometheus estándar.
• Runbook de degradación: protocolo escrito para operar en manual si hay incidente en el cluster.

Cumplimiento NIS2

En la UE, NIS2 obliga a infraestructura crítica a gestionar vulnerabilidades, mantener inventario de activos, tener plan de incident response y asegurar la cadena de suministro. Contenerizar no exime del cumplimiento: el contenedor es un activo más del inventario, y el registro de imágenes es parte de la cadena de suministro. Los frameworks IEC 62443 tratan los contenedores como componentes de la arquitectura total, con los mismos requisitos que el software tradicional. Para más detalle sobre supply chain en contenedores, ver Chainguard Images y seguridad en la cadena de distribución.

Cuándo no contenerizar

Situaciones donde no compensa el esfuerzo:

• Sin cultura OT madura alrededor de contenedores y sin equipo dedicado a formarse.
• El SCADA existente funciona correctamente y no hay un driver claro de modernización.
• Instalaciones pequeñas de 2-3 máquinas donde el overhead de Kubernetes no se justifica.
• Cuando no se puede garantizar aislamiento de red estricto entre OT y el resto.

Observabilidad adaptada a OT

El stack que mejor funciona en la práctica combina capas IT estándar con capa OT específica:

• Prometheus + Grafana para métricas de aplicación y Kubernetes.
• Loki para logs centralizados de todos los contenedores.
• Claroty o Nozomi superpuestos para visibilidad de protocolos OT (Modbus, OPC UA, PROFINET).
• Alertas en dos canales: IT ops y OT ops, porque los criterios de escalado son diferentes.

La seguridad y la observabilidad en contenedores OT no se improvisan: requieren planning desde el diseño. Para instalaciones que están empezando la modernización, comenzar en parques renovables o instalaciones nuevas —menos críticos que una planta química— es la secuencia más prudente.

Conclusión

Contenerizar SCADA tiene sentido en las capas correctas: HMI, historians y gateways de datos. El control crítico sigue perteneciendo a los PLCs hasta que existan estándares maduros y casos probados. El viaje vale la pena para la mayoría de organizaciones con una planta moderna, pero exige respetar el contexto OT en cada decisión de diseño.

1. Inductive Automation Ignition
2. PTC ThingWorx
3. FUXA