◇ OpenCyber Academy
Ingeniería · Capítulo 13 · Español

Capítulo 13 — Sistemas de datos

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.

Capítulo 13 — Sistemas de datos

Mapa de la lección

Lección 13 publicada. Mapa, ejemplo, EX025.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["13.1 Modelos para los datos operativos"]
  N2["13.2 Transacciones, consistencia y replicación"]
  N3["13.3 Integridad: qué detecta cada mecanismo"]
  N4["13.4 Sacar los datos sin dejar entrar los ataques"]
  N5["13.6 Actividad práctica: Lab 6"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX025"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["13.1 Modelos para los datos operativos"]
  N2["13.2 Transacciones, consistencia y replicación"]
  N3["13.3 Integridad: qué detecta cada mecanismo"]
  N4["13.4 Sacar los datos sin dejar entrar los ataques"]
  N5["13.6 Actividad práctica: Lab 6"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX025"]
[Resultados de aprendizaje y conexión]
    |
    v
[13.1 Modelos para los datos operativos]
    |
    v
[13.2 Transacciones, consistencia y replicación]
    |
    v
[13.3 Integridad: qué detecta cada mecanismo]
    |
    v
[13.4 Sacar los datos sin dejar entrar los ataques]
    |
    v
[13.6 Actividad práctica: Lab 6]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX025]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) diseñar modelos de datos relacionales y de series temporales para los datos operativos; (2) explicar las transacciones, la consistencia y la replicación; (3) proteger la integridad de los datos con restricciones, procedencia y cadenas de hashes, e indicar exactamente qué detecta cada una; y (4) planificar los flujos de datos entre los sistemas de control y la analítica corporativa sin abrir un camino hacia el control. Se apoya en los capítulos 9 y 11 y prepara los capítulos 22 (modelos de datos) y 29 (medición).

13.1 Modelos para los datos operativos

Codd (1970) introdujo el modelo relacional: los datos como relaciones (tablas) con claves, manipuladas mediante operaciones de conjuntos. Los registros de activos, las órdenes de trabajo y las cuentas de usuario encajan bien en él. Los datos de proceso (miles de etiquetas muestreadas cada segundo) suelen ir a un historiador, un almacén de series temporales optimizado para añadir datos y para consultas por rangos, a menudo con una compresión que descarta los cambios menores que una banda muerta. Sepa qué descarta su historiador: el análisis forense puede necesitar valores que nunca almacenó.

El historiador de LRWA almacena el nivel de Hollin Hill con compresión por banda muerta, así que los cambios menores que la banda muerta nunca se conservan.

13.2 Transacciones, consistencia y replicación

Una transacción agrupa operaciones de modo que todas ocurran o ninguna (atomicidad), dejando los datos válidos (consistencia), sin verse afectada por transacciones concurrentes (aislamiento) y sobreviviendo a las caídas (durabilidad). La replicación copia los datos para la disponibilidad; cuando las réplicas pueden discrepar, los sistemas eligen entre consistencia y disponibilidad durante una partición de la red. Para la operación: una alarma reconocida por un operador no debe reaparecer como no reconocida tras una conmutación por falla; un cambio de consigna no debe aplicarse dos veces.

En el par SCADA de LRWA, la conmutación por falla es el momento en que se ponen a prueba estas propiedades: las pruebas de integración deben confirmar que las alarmas reconocidas y las consignas aplicadas sobreviven al cambio exactamente una vez.

13.3 Integridad: qué detecta cada mecanismo

13.4 Sacar los datos sin dejar entrar los ataques

Los equipos corporativos quieren datos de control para informes y analítica. El patrón seguro es empujar los datos hacia fuera, desde la zona de control hasta una réplica del historiador en la DMZ, y dejar que los usuarios corporativos consulten la réplica, nunca el historiador de control. Donde la consecuencia de comprometer la zona de control es grave, las pasarelas unidireccionales (diodos de datos) imponen físicamente un flujo solo de salida. La infracción del Lab 5 (un script corporativo que sondea directamente una RTU) es el antipatrón.

En LRWA, la réplica del historiador en la DMZ atiende a los equipos de finanzas y de activos, y el script corporativo olvidado que encontró la revisión de flujos se está retirando en su favor.

13.5 Ejemplo resuelto: proteger la cronología del incidente (sintético)

Tras una caída inexplicada del nivel del depósito el 4 de marzo en el registro sintético, LRWA debe preservar el extracto del historiador para la investigación. El Lab 6 encadena con hashes seis lecturas diarias y guarda el hash de cabeza en el ticket del incidente (el ancla). La edición del valor del 4 de marzo se detecta en el índice 3 y en todos los registros posteriores. La eliminación del último registro no se detecta comparando solo las cabezas si el atacante también sustituye la cabeza guardada; por eso el ancla va a un sistema fuera del alcance del atacante, junto con el número de registros.

13.6 Actividad práctica: Lab 6

# Lab 6 - a hash-chained historian extract detects edits, not deletions at the tail (offline)
import hashlib, json
recs = [{"t": f"2026-03-0{d} 06:00", "tag": "HOLLIN_LVL", "v": v} for d, v in zip(range(1, 7), [78.1, 77.4, 79.0, 41.2, 76.5, 77.9])]
def chain(rs):
    prev, out = "0" * 64, []
    for r in rs:
        h = hashlib.sha256((prev + json.dumps(r, sort_keys=True)).encode()).hexdigest()
        out.append(h); prev = h
    return out
anchor = chain(recs)
print("head:", anchor[-1][:16])
tampered = [dict(r) for r in recs]; tampered[3]["v"] = 74.0
bad = [i for i, (a, b) in enumerate(zip(anchor, chain(tampered))) if a != b]
print("first mismatch at index:", bad[0], "mismatches:", len(bad))
print("truncated head matches stored index 4:", chain(recs[:5])[-1] == anchor[4])

Salida esperada:

head: a8407870e41914c1
first mismatch at index: 3 mismatches: 3
truncated head matches stored index 4: True

El hash de cabeza es lo que LRWA guarda en el ticket del incidente. Editar la lectura del 4 de marzo para ocultar la caída cambia el hash en el índice tres y en todos los registros posteriores, de modo que la edición se detecta dondequiera que ocurra. La última línea muestra la debilidad: una cadena construida con los cinco primeros registros coincide con el hash guardado en el índice cuatro, así que un atacante que elimine el registro final y sustituya la cabeza guardada pasaría desapercibido. El EX025 cierra esa brecha añadiendo el número de registros al ancla.

13.7 Errores comunes y límites

La investigación del 4 de marzo depende de evitar cada uno de estos errores, desde los huecos de compresión hasta la falta de zona horaria. Un historiador que descarta los cambios pequeños puede haber eliminado justo los valores que mostrarían con qué rapidez bajó el nivel; un ancla guardada en el servidor del historiador podría reescribirla el mismo administrador; y unas marcas de tiempo sin zona hacen imposible alinear la caída con el registro del operador.

Ejercicios — capítulo 13

EX025 — Truncamiento del final. Objetivo: cerrar la brecha del truncamiento. Entradas: Lab 6. Pasos: (1) muestre que chain(recs[:5]) coincide con el hash guardado en el índice 4; (2) modifique el ancla para incluir el número de registros y muestre que el truncamiento se detecta; (3) indique dónde debe guardarse el ancla en LRWA y por qué. Evidencia esperada: código y salida. Rúbrica: 3 = demostración y corrección correctas, ancla guardada fuera del alcance de los administradores del control y del historiador; 2 = corrección incompleta; 1 = no ejecutado; 0 = nada.

EX026 — Diseño del flujo de datos. Objetivo: diseñar con seguridad el acceso para la analítica. Entradas: el equipo de finanzas quiere datos horarios de energía de las bombas; el equipo de activos quiere datos de presión en vivo para un tablero. Pasos: describa (en texto) los flujos, las zonas y la dirección; indique qué componente impone la dirección y qué ocurre si se compromete la réplica de la DMZ. Evidencia esperada: descripción de los flujos y análisis de consecuencias. Rúbrica: 3 = envío hacia la DMZ, nada entrante hacia el control, consecuencia limitada a la confidencialidad e integridad de los datos de la réplica; 2 = la dirección no se impone; 1 = consulta directa al historiador de control; 0 = nada.

Síntesis del capítulo

Modele los datos operativos de forma deliberada, sepa qué descarta su historiador y use las transacciones y la replicación pensando en la conmutación por falla. Cada mecanismo de integridad detecta algo específico: las restricciones rechazan lo imposible, las cadenas de hashes detectan ediciones respecto de un ancla guardada de forma independiente, las firmas vinculan a quien posee una clave; ninguno prueba la verdad. Mueva los datos hacia fuera, a una DMZ, y nunca deje que los informes se conviertan en un camino hacia el control.

Siga estudiando — capítulo 13 de 50

← Capítulo 12 · Índice de capítulos del curso · Capítulo 14 →

Continúe con la siguiente lección escrita.