Capítulo 22 — Infraestructura crítica y seguridad sectorial: automatización | Tecnólogo Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 22 publicada. Mapa, ejemplo, EX064.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["22.1 La configuración como código"]
  N2["22.2 Planificar y después actuar"]
  N3["22.3 Autocorrección segura frente a incidencia"]
  N4["22.5 La automatización es código: trátela como tal"]
  N5["22.7 Actividad práctica: plan de deriva"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX064"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["22.1 La configuración como código"]
  N2["22.2 Planificar y después actuar"]
  N3["22.3 Autocorrección segura frente a incidencia"]
  N4["22.5 La automatización es código: trátela como tal"]
  N5["22.7 Actividad práctica: plan de deriva"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX064"]

[Resultados de aprendizaje y conexión]
    |
    v
[22.1 La configuración como código]
    |
    v
[22.2 Planificar y después actuar]
    |
    v
[22.3 Autocorrección segura frente a incidencia]
    |
    v
[22.5 La automatización es código: trátela como tal]
    |
    v
[22.7 Actividad práctica: plan de deriva]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX064]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted debería ser capaz de:

expresar la configuración deseada como código y compararla automáticamente con el estado real;
diseñar una automatización que planifique antes de actuar, separe las autocorrecciones seguras de los cambios que necesitan aprobación y limite su propio radio de impacto;
reconocer cuándo la propia fuente de verdad puede estar equivocada, y detenerse;
mantener la automatización dentro del control de cambios y obtener evidencia de ella.

Los capítulos 6 y 14 describieron las líneas base y las comprobaciones de integridad hechas a mano. Con tres retransmisores y un parque creciente, la comprobación manual deja de hacerse. La automatización hace fiables las comprobaciones rutinarias, y también hace que los errores sean rápidos y amplios. Este capítulo trata de conseguir lo primero sin lo segundo.

22.1 La configuración como código

Escriba el estado deseado de cada clase de equipo como datos bajo control de versiones: ajustes de SSH, direcciones de escucha, servidores de hora, reenvío de registros, versiones de paquetes. Un recopilador lee el estado real de cada equipo (en modo de solo lectura), y una comparación produce la deriva: las claves cuyo valor real difiere del deseado. La guía del NIST sobre gestión de la configuración describe la vigilancia de las configuraciones frente a las líneas base como una actividad central (NIST SP 800-128); el marco de desarrollo seguro de software del NIST aplica disciplinas similares (control de versiones, revisión, cadenas de compilación protegidas) al código que la implementa (NIST SP 800-218).

22.2 Planificar y después actuar

Una buena automatización separa el plan de la aplicación. El plan enumera cada cambio previsto: equipo, ajuste, valor actual, valor deseado y modo. El paso de aplicación ejecuta un plan aprobado, no un cálculo nuevo. Esto da a una persona la oportunidad de ver lo que va a ocurrir, da al registro de cambio algo concreto que aprobar y produce evidencia después. El plan del Lab 22 para RLY-02 enumera dos cambios, SSH con contraseña y servidores de hora públicos, con sus valores actuales y deseados.

El servicio de depuración a la escucha de RLY-03 aparece en el plan como una incidencia y no como una acción, porque eliminarlo podría destruir la evidencia de quién lo habilitó.

22.3 Autocorrección segura frente a incidencia

Parte de la deriva puede corregirse automáticamente con seguridad: ajustes de bajo riesgo, reversibles y bien comprendidos (volver a deshabilitar la autenticación por contraseña de SSH; restaurar los servidores de hora aprobados; restaurar el reenvío de registros). Otra deriva debe pasar por el control de cambios: todo lo que pueda cambiar el comportamiento del servicio (una versión de paquete), todo lo que pueda ser evidencia (un servicio de depuración a la escucha inesperado, que puede ser de un atacante o de un ingeniero y debe conservarse antes de eliminarlo, capítulo 20) y todo lo que afecte al proceso físico. Escriba la lista de autocorrecciones de forma explícita y manténgala corta.

22.4 Límites al radio de impacto

La automatización debe protegerse de sus propios errores. Límites habituales: aplicar a un equipo cada vez, verificando cada uno antes del siguiente; detenerse en el primer fallo; y detenerse y escalar si se encuentra demasiada deriva: si la mayor parte del parque parece haber derivado, la explicación más probable es que el estado deseado sea erróneo (una confirmación defectuosa, una rama equivocada), y autocorregir extendería el error a todas partes. Una gran interrupción causada por una actualización defectuosa distribuida a la vez a muchos sistemas (como el incidente de julio de 2024 que afectó a equipos Windows con un producto de seguridad y que, según Microsoft, afectó a unos 8,5 millones de dispositivos (Microsoft, 20 de julio de 2024)) ilustra por qué el despliegue escalonado y las condiciones de detención importan en cualquier distribución automatizada.

22.5 La automatización es código: trátela como tal

El propio código de la automatización y los archivos de estado deseado son de alto valor: quien pueda cambiarlos puede cambiar todos los equipos. Protéjalos con revisión antes de la fusión, acceso de escritura restringido, confirmaciones firmadas o ramas protegidas, y registros de cada ejecución. Las credenciales de la automatización para leer y cambiar los equipos son cuentas privilegiadas (capítulo 7). La fusión de NTP del capítulo 25 es la advertencia: una sola confirmación revisada cambió la hora en todos los retransmisores. Trate la cuenta que usa la automatización para llegar a RLY-01, RLY-02 y RLY-03 como vendor-kell: limitada en el tiempo cuando sea posible, registrada y revisada en la revisión trimestral de accesos del capítulo 7.

22.6 Ejemplo resuelto: una ejecución en seco sobre tres retransmisores (sintético)

El Lab 22 compara el estado deseado con tres retransmisores. RLY-01 cumple. RLY-02 tiene la autenticación por contraseña de SSH de nuevo habilitada y servidores de hora públicos, ambos en la lista de autocorrecciones. RLY-03 tiene un servicio de depuración a la escucha en todas las interfaces, un paquete del retransmisor más antiguo y ningún reenvío de registros. Dos de los tres equipos han derivado, más de la mitad del parque, así que la salvaguarda detiene la ejecución. Aquí la detención es, en cierto sentido, una falsa alarma (la fuente de verdad está bien), pero la regla acierta al detenerse: una persona confirma el estado deseado y después aprueba aplicar las tres autocorrecciones equipo a equipo, mientras el servicio de depuración y la versión del paquete pasan a incidencias. El servicio de depuración a la escucha de RLY-03 es el mismo síntoma que encontró la comprobación de integridad en RLY-01 en el capítulo 6: dos veces es un patrón, y se aplica el método de resolución de problemas del capítulo 20.

Observe también que la falta de reenvío de registros en RLY-03 significa que sus propios registros sobre el servicio de depuración pueden no haber llegado nunca al SIEM: otro motivo para conservar la evidencia local antes de corregir.

22.7 Actividad práctica: plan de deriva

Lab 22 (guárdelo como lab22.py y ejecútelo con python3 lab22.py):

# Lab 22 - automated configuration-drift check with a dry-run plan (offline, standard library only)
# Synthetic desired state (from version control) and actual state (as collected from three relay hosts).
import json
desired = {"ssh.password_auth": False, "ssh.permit_root": False, "relay.listen": "10.30.0.5:8443",
           "relay.debug_listen": None, "ntp.servers": ["10.30.0.1", "10.30.0.2"], "log.forward": "siem-01:6514",
           "pkg.relayd": "2.4.1"}
actual = {
 "rly-01": {**desired},
 "rly-02": {**desired, "ssh.password_auth": True, "ntp.servers": ["pool.example.net"]},
 "rly-03": {**desired, "relay.debug_listen": "0.0.0.0:9000", "pkg.relayd": "2.3.9", "log.forward": None},
}
SAFE_AUTOFIX = {"ssh.password_auth", "ssh.permit_root", "ntp.servers", "log.forward"}  # low-risk, reversible
def plan(host, state):
    steps = []
    for k, want in desired.items():
        have = state.get(k)
        if have != want:
            mode = "auto" if k in SAFE_AUTOFIX else "ticket"
            steps.append({"host": host, "key": k, "have": have, "want": want, "mode": mode})
    return steps
all_steps = [s for h, st in actual.items() for s in plan(h, st)]
for s in all_steps:
    print(f"{s['host']} {s['key']:<20} have={json.dumps(s['have']):<22} want={json.dumps(s['want']):<26} -> {s['mode']}")
print("hosts compliant:", [h for h, st in actual.items() if not plan(h, st)])
print("dry run only: %d auto-fix steps, %d need a change ticket" % (sum(s['mode'] == 'auto' for s in all_steps), sum(s['mode'] == 'ticket' for s in all_steps)))
# Guard: never auto-apply to more than one host at a time, and stop if the host count with drift exceeds half the fleet
drifted = {s['host'] for s in all_steps}
print("guard: drifted hosts %d of %d -> %s" % (len(drifted), len(actual), "HALT and escalate (possible bad source of truth)" if len(drifted) > len(actual) / 2 else "proceed one host at a time"))

Salida esperada (Python 3.13.5):

rly-02 ssh.password_auth    have=true                   want=false                      -> auto
rly-02 ntp.servers          have=["pool.example.net"]   want=["10.30.0.1", "10.30.0.2"] -> auto
rly-03 relay.debug_listen   have="0.0.0.0:9000"         want=null                       -> ticket
rly-03 log.forward          have=null                   want="siem-01:6514"             -> auto
rly-03 pkg.relayd           have="2.3.9"                want="2.4.1"                    -> ticket
hosts compliant: ['rly-01']
dry run only: 3 auto-fix steps, 2 need a change ticket
guard: drifted hosts 2 of 3 -> HALT and escalate (possible bad source of truth)

Lea primero la detención. Dos de los tres retransmisores derivaron, más de la mitad del parque, así que la ejecución se detuvo antes de aplicar nada. Después lea el plan por equipo: la autenticación por contraseña y los servidores de hora públicos de RLY-02, y la falta de reenvío de registros de RLY-03, están en la lista de autocorrecciones; el servicio de depuración a la escucha y el paquete del retransmisor más antiguo de RLY-03 no lo están, y se convierten en incidencias. Antes de aprobar cualquier corrección en RLY-03, copie sus registros locales, porque sin reenvío pueden ser el único registro de cuándo apareció el servicio de depuración.

22.8 Errores frecuentes y límites

Automatización que aplica cambios sin un plan que pueda revisarse.
Listas de autocorrecciones largas, que incluyen ajustes que pueden ser evidencia o cambiar el comportamiento.
Aplicar a todos los equipos a la vez.
Ninguna condición de detención por «demasiada deriva».
Código y credenciales de la automatización menos protegidos que los equipos que gestionan.
Tratar el cumplimiento automatizado como prueba de seguridad; solo demuestra los ajustes que comprueba.

La detención del Lab 22 con dos de tres retransmisores derivados es el cuarto punto bien resuelto.

Una lista de autocorrecciones que incluyera el servicio de depuración habría eliminado la evidencia de quién lo configuró en RLY-03.

Ejercicios — capítulo 22

EX064 — Apruebe el plan. Objetivo: revisar un plan de automatización como aprobador de cambios. Entradas: la salida del Lab 22. Restricciones: apruebe, modifique o rechace cada paso. Pasos: (1) decida sobre cada uno de los cinco pasos; (2) indique el orden de aplicación; (3) indique la verificación tras cada equipo. Evidencia esperada: tabla. Rúbrica: 3 = autocorrecciones aprobadas equipo a equipo (RLY-02 y después RLY-03), servicio de depuración conservado y después eliminado mediante una incidencia tras la investigación, actualización del paquete como cambio normal con canario (capítulo 27), reenvío de registros restaurado pronto en RLY-03 para recuperar la visibilidad; comprobaciones de verificación nombradas; 2 = falta el orden o la conservación; 1 = aprobarlo todo; 0 = nada.

EX065 — Ajuste la salvaguarda. Objetivo: razonar sobre los umbrales de detención. Entradas: la salvaguarda se detiene cuando más de la mitad del parque tiene deriva. Restricciones: el parque crecerá hasta 12 retransmisores. Pasos: (1) indique si «más de la mitad» sigue siendo razonable con 12; (2) proponga una salvaguarda mejor que use el tipo de deriva, no solo el número de equipos. Evidencia esperada: párrafo. Rúbrica: 3 = reconoce que la misma clave derivando en muchos equipos sugiere una fuente de verdad defectuosa, mientras que claves distintas en equipos distintos sugieren cambios locales; propone detenerse cuando una clave difiere en más de una proporción fijada de equipos, o cuando hay una confirmación reciente y sin revisar en el estado deseado; 2 = parcial; 1 = mantiene «la mitad»; 0 = nada.

EX066 — Proteja la cadena. Objetivo: proteger la propia automatización. Entradas: el repositorio del estado deseado y la cuenta de la automatización. Restricciones: cinco controles. Pasos: enumérelos con su evidencia. Evidencia esperada: tabla. Rúbrica: 3 = rama protegida con revisión obligatoria, mantenedores restringidos con MFA, confirmaciones o etiquetas firmadas, cuenta de la automatización limitada a los equipos gestionados con las credenciales en una bóveda, registros de ejecución reenviados al SIEM con una alerta ante ejecuciones fuera de calendario; evidencia para cada uno; 2 = cuatro; 1 = genéricos; 0 = nada.

Síntesis del capítulo

Exprese el estado deseado como código, recopile el estado real en modo de solo lectura y calcule la deriva. Planifique antes de actuar; autocorrija solo una lista corta de ajustes de bajo riesgo y reversibles, y envíe todo lo demás (en especial, todo lo que pueda ser evidencia) al control de cambios. Limite el radio de impacto: un equipo cada vez, detenerse ante un fallo, detenerse cuando la deriva parezca una fuente de verdad defectuosa. Proteja la automatización con tanto cuidado como los equipos que gestiona.