Capítulo 22 — Seguridad de TO, IoT y sistemas ciberfísicos: automatización
Mapa de la lección
Lección 22 publicada. Mapa, ejemplo, EX064.
flowchart TD
N0["Resultados de aprendizaje"]
N1["22.1 Qué automatizar"]
N2["22.2 Leer el informe"]
N3["22.3 Informar, no modificar"]
N4["22.4 Programación y registro"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX064"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["22.1 Qué automatizar"]
N2["22.2 Leer el informe"]
N3["22.3 Informar, no modificar"]
N4["22.4 Programación y registro"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]
[Resultados de aprendizaje]
|
v
[22.1 Qué automatizar]
|
v
[22.2 Leer el informe]
|
v
[22.3 Informar, no modificar]
|
v
[22.4 Programación y registro]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX064]
Resultados de aprendizaje
Usted será capaz de (1) automatizar comprobaciones rutinarias como la caducidad de los certificados; (2) diseñar automatizaciones que informan en lugar de modificar los sistemas de TO; (3) programar y registrar trabajos automatizados; y (4) gestionar los fallos de la propia automatización.
22.1 Qué automatizar
Los buenos candidatos son las comprobaciones repetitivas con reglas claras: caducidad de certificados, finalización de copias de seguridad, deriva del inventario (el capítulo 11 ejecutado cada semana), comparación de flujos (el capítulo 12 ejecutado a diario sobre capturas nuevas). Los malos candidatos son las acciones sobre controladores en servicio; esas siguen siendo manuales y aprobadas.
"""Lab 22: report days until expiry for synthetic IoT logger certificates."""
from datetime import date
today = date(2026, 10, 12)
certs = {"LOG-01": date(2026, 11, 2), "LOG-02": date(2027, 6, 30), "LOG-03": date(2026, 10, 5), "LOG-04": date(2026, 12, 20)}
for dev, exp in sorted(certs.items(), key=lambda kv: kv[1]):
d = (exp - today).days
flag = "EXPIRED" if d < 0 else "renew-now" if d <= 30 else "plan" if d <= 90 else "ok"
print(f"{dev} expires {exp} in {d:4} days -> {flag}")
Ejecútelo con python3 lab_certs.py. Salida verificada:
LOG-03 expires 2026-10-05 in -7 days -> EXPIRED
LOG-01 expires 2026-11-02 in 21 days -> renew-now
LOG-04 expires 2026-12-20 in 69 days -> plan
LOG-02 expires 2027-06-30 in 261 days -> ok
Las comprobaciones de Priya empiezan por la comprobación de caducidad de certificados anterior; su primera ejecución encontró un certificado caducado y otro pendiente de renovación.
La comprobación lee la fecha de caducidad del certificado de cada registrador en la exportación del proveedor y clasifica los registradores en EXPIRED, renew-now, plan y ok. Su primera ejecución dio LOG-03 caducado, LOG-01 a 21 días, LOG-04 a 69 días y LOG-02 correcto a 261 días.
22.2 Leer el informe
El certificado de LOG-03 caducó hace una semana, así que ese registrador probablemente no consigue conectarse y faltan lecturas. A LOG-01 le quedan 21 días y necesita renovarse ya, dados los plazos del proveedor. LOG-04 debe planificarse; LOG-02 está bien. Ordenar por fecha de caducidad pone primero lo urgente. Priya programó la comprobación a las 06:00 todos los días. Su primera ejecución abrió tiques para LOG-03 y LOG-01. El proveedor confirmó que LOG-03 había dejado de subir datos el 5 de octubre; el responsable de calidad registró un hueco de siete días en los registros de la nube para esa sala, cubierto por el historial de la sonda del PLC en HIST.
22.3 Informar, no modificar
El script imprime el informe y podría enviarlo por correo electrónico; no renueva certificados por sí mismo. La renovación pasa por el proceso del proveedor, porque una renovación automática que falle a medias podría dejar un registrador fuera de servicio. La comprobación de Priya abre tiques; no actúa. LOG-01, con 21 días por delante, se renovó mediante el proceso del proveedor en esa misma semana, y el tique registra la nueva fecha de caducidad. Si el script hubiera intentado renovar LOG-03 automáticamente y hubiera fallado a medias, NCS podría haber perdido un segundo registrador sin saberlo. Mantener el script en modo de solo informe también significa que no necesita acceso de escritura al portal del proveedor, así que sus credenciales valen menos si el equipo de gestión resulta comprometido.
22.4 Programación y registro
Ejecute la comprobación a diario desde un programador de tareas en un equipo de gestión de la VLAN de gestión de TO, escriba la salida en un registro con marcas de tiempo y alerte si el trabajo no se ejecutó. Un fallo silencioso de la automatización es peor que no tener automatización, porque la gente deja de comprobar a mano. En NCS el trabajo se ejecuta en el equipo de gestión de TO a las 06:00, registra cada ejecución con su marca de tiempo, y el programador lanza una alerta si a las 06:15 no ha aparecido ninguna línea en el registro. Esa alerta importa porque la comprobación de certificados es ahora la única razón por la que alguien mira las fechas de caducidad de los registradores.
Ejemplo resuelto (NCS sintética)
Priya programa la comprobación a las 06:00 todos los días. La primera ejecución genera un tique para LOG-03 (caducado) y LOG-01 (renovar ya). El proveedor confirma que LOG-03 dejó de subir datos el 5 de octubre; el responsable de calidad registra un hueco de siete días en los registros de la nube para esa sala, cubierto por el historial de la sonda del PLC en HIST.
Caso sintético — Northgate Cold Storage. Las fechas y los dispositivos son inventados.
Errores y límites
El script usa una fecha «de hoy» fija para que su salida sea reproducible; una versión de producción usaría la fecha actual. Las fechas de los certificados deben proceder de los dispositivos o del proveedor, no de una tabla tecleada a mano.
Ejercicios — capítulo 22
- EX064 — Cambiar los umbrales. Si
renew-nowse aplicara a ≤ 60 días, ¿qué dispositivos cambian de estado? Rúbrica: 3 = ningún estado cambia, con LOG-04 todavía enplana 69 días; 2 = conclusión correcta sin razón; 1 = dice que LOG-04 pasa arenew-now; 0 = nada. - EX065 — Usar la fecha real. ¿Qué cambio de línea hace que el script use la fecha actual y qué se pierde? Rúbrica: 3 =
today = date.today(); la reproducibilidad de la salida documentada; 2 = uno; 1 = vago; 0 = nada. - EX066 — Detectar un fallo silencioso. Describa cómo notaría NCS que el trabajo de las 06:00 ha dejado de ejecutarse. Rúbrica: 3 = una comprobación de latido o del registro esperado alerta cuando no consta ninguna ejecución a la hora límite; 2 = parcial; 1 = «alguien se dará cuenta»; 0 = nada.
Síntesis del capítulo
Automatice las comprobaciones que informan con claridad y fallan de forma ruidosa; deje los cambios en los dispositivos de TO en manos humanas y aprobadas.
Siga estudiando — capítulo 22 de 30
← Capítulo 21 (borrador) · Índice de capítulos del curso · Capítulo 23 (borrador) →