SCADA moderno en contenedores: ventajas y riesgos

javi
Panel industrial con pantallas de monitorización y luces indicadoras

Los sistemas SCADA (Supervisory Control and Data Acquisition) tradicionalmente han sido software monolítico sobre Windows Server con bases de datos propietarias. En los últimos años, la tendencia es contenerizar SCADA para aprovechar las ventajas devops modernas: despliegue declarativo, escalado, observabilidad. Este artículo cubre cuándo tiene sentido, qué riesgos introduce, y arquitecturas que funcionan.

Por qué contenerizar SCADA

Ventajas concretas:

  • Despliegue reproducible: mismo setup en dev, staging, producción.
  • Actualizaciones menos traumáticas: rolling update vs “apagar sistema y migrar”.
  • Escalado: múltiples frontends HMI con balanceo.
  • Observabilidad: métricas, logs, trazas estándar Kubernetes.
  • Costes: less hardware dedicado.

Los productos compatibles

Productos SCADA que soportan containerización:

El problema fundamental: OT ≠ IT

SCADA opera maquinaria física. Fallos tienen consecuencias reales: parada de planta, riesgo de seguridad, daños a equipos.

Consecuencia: no puedes aplicar patterns DevOps ingenuamente. Un kubectl rollout restart no es aceptable si afecta control de un reactor químico.

Arquitecturas que funcionan

Layer de edge con containers + PLC real

  • PLCs (Siemens, Rockwell, Omron) controlan el hardware directamente.
  • Gateway containerizado agrega datos via OPC UA.
  • HMI en container, acceso via web browser.
  • Historian containerizado para data histórica.

Los PLCs mantienen determinismo duro; containers se encargan de lo flexible.

Cluster dedicado OT Kubernetes

  • Kubernetes on-premise dedicado a OT workloads.
  • Segmentación estricta vs IT.
  • GitOps para deploys de HMI/historian.
  • Monitoring con Prometheus en el mismo cluster.

Separado del Kubernetes IT corporativo.

Híbrido: legacy + moderno

Transición gradual:

  1. HMIs nuevas en containers.
  2. Historians migran a containers.
  3. PLC interfaces se mantienen bare-metal inicialmente.
  4. Dashboard agregado sobre todo.

Riesgos de seguridad OT

Ser honesto con los riesgos nuevos:

Superficie de ataque ampliada

  • Docker socket expuesto = control de host.
  • Kubernetes API accesible por error = acceso al cluster.
  • Imagenes no firmadas = supply chain attacks.
  • Red overlay mal segmentada = pivot lateral fácil.

Pérdida del modelo Purdue

La ISA/IEC 62443 define niveles (Purdue): L0 field, L1 control, L2 HMI, L3 operations, L4 enterprise. Containers pueden borrar los límites si no tienes disciplina.

Responsabilidad sobre runtime

Kubernetes actualiza, cambia, evoluciona. Un cambio de CRI o default config puede romper invariantes OT. IT ops no suele entender criticidad.

Mitigaciones

Prácticas que reducen riesgo:

  • Air-gap real entre cluster OT y el resto.
  • Immutable infrastructure: no cambios en running; reconstruir siempre.
  • Policy enforcement (Kyverno, Gatekeeper) muy estricto.
  • Backups frecuentes de historian + config.
  • Monitoring específico OT (CrowdStrike, Claroty, Nozomi).
  • Runbook de emergencia: cómo degradar a operación manual si hay incidente.

Ciberseguridad: NIS2 y compliance

En UE, NIS2 obliga buenas prácticas en infraestructura crítica. Container-based SCADA debe cumplir:

  • Inventario de activos.
  • Gestión de vulnerabilidades.
  • Incident response.
  • Supply chain security.
  • Formación de personal.

Los frameworks reconocidos (IEC 62443) tratan containers como pieza de la arquitectura total — el cumplimiento no es automático por contenerizar.

Casos reales

  • Shell: modernización progresiva con containers para HMI.
  • Siemens: sus propios productos soportan containerización.
  • Operadoras de redes eléctricas: pilotos cautelosos en parques renovables (menos crítico que planta nuclear).
  • Plantas químicas: historian y dashboards contenedorizados; control fijo.

No hay casos de control directo crítico completamente en containers — todavía los PLCs son la base.

Cuándo NO contenerizar

  • Si no tienes cultura OT madura sobre containers.
  • Si el SCADA existente funciona bien y no hay driver de modernización.
  • En sistemas small (2-3 maquinas) donde overhead no se justifica.
  • Si no puedes garantizar aislamiento de red estricto.

Observabilidad adaptada

Stack que vemos funcionar:

  • Prometheus para métricas.
  • Grafana para dashboards operativos.
  • Loki/Elasticsearch para logs.
  • OT-specific monitoring superpuesto (Claroty, Nozomi).
  • Alertas dual-path (IT + OT channels).

Conclusión

Contenerizar SCADA es tendencia real con ventajas operativas claras, pero exige respetar el contexto OT. No es devops-as-usual. Arquitecturas que dejan control crítico en PLCs y modernizan las capas superiores (HMI, historian, dashboards) son pragmáticas. Air-gap, policy estricta y monitoring OT-específico son requisitos, no opciones. Para plantas que empiezan modernización, arrancar en renovables o instalaciones nuevas antes que migrar planta química crítica es secuencia sensata. El viaje vale la pena para la mayoría — solo hay que hacerlo con disciplina.

Síguenos en jacar.es para más sobre industria 4.0, SCADA y seguridad OT.

Entradas relacionadas