Capítulo 12 — Infraestructura crítica y seguridad sectorial: flujos de datos
Mapa de la lección
Lección 12 publicada. Mapa, ejemplo, EX034.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["12.1 El registro"]
N2["12.2 Clases de datos"]
N3["12.3 Verificar el registro"]
N4["12.4 Los flujos nuevos necesitan revisión antes de e"]
N5["12.6 Actividad práctica: comprobación del registro"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX034"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["12.1 El registro"]
N2["12.2 Clases de datos"]
N3["12.3 Verificar el registro"]
N4["12.4 Los flujos nuevos necesitan revisión antes de e"]
N5["12.6 Actividad práctica: comprobación del registro"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX034"]
[Resultados de aprendizaje y conexión]
|
v
[12.1 El registro]
|
v
[12.2 Clases de datos]
|
v
[12.3 Verificar el registro]
|
v
[12.4 Los flujos nuevos necesitan revisión antes de e]
|
v
[12.6 Actividad práctica: comprobación del registro]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX034]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- mantener un registro de flujos de datos que recoja, para cada flujo, su origen, destino, clase de datos, protección y conservación;
- clasificar los datos de un servicio crítico: telemetría operativa, configuración, datos personales y vinculados a pacientes, registros de seguridad;
- verificar el registro frente a lo que los sistemas realmente envían y conservan;
- reconocer cuándo un flujo nuevo necesita una revisión de privacidad, contractual o de seguridad física antes de empezar.
El capítulo 2 comparó los flujos de red con los conductos declarados. Un conducto dice que un camino está permitido; un registro de flujos de datos dice qué datos viajan por él, cómo se protegen y cuánto tiempo se conservan en el otro extremo. En los servicios compartidos, la segunda pregunta suele ser la que mete en problemas a una organización, porque los datos sobreviven al motivo por el que se recogieron.
12.1 El registro
Cada entrada del registro de LANTERN recoge: identificador; origen y destino (sistemas, no solo direcciones); clase de datos; si el flujo va cifrado en tránsito; cuánto tiempo conserva los datos el destino; el propósito; el responsable; y, para los datos personales, la base jurídica registrada por el responsable de los datos. El registro es un documento que las personas leen durante un incidente («¿qué salió de la pasarela clínica?») y ante una solicitud de privacidad («¿a dónde van los datos de la bomba de este paciente?»). DF5 es una entrada modelo: de la pasarela clínica a Halden Cloud, vinculada a pacientes, cifrada, 30 días registrados.
12.2 Clases de datos
Para un implementador, cuatro clases cubren la mayor parte de un servicio crítico compartido:
- Telemetría operativa: lecturas y estados (niveles, caudales, cloro). Normalmente no es personal, pero su integridad es crítica y a veces es sensible en conjunto (revela cómo funciona la red).
- Datos de configuración e ingeniería: programas de los controladores, diagramas de red, puntos de consigna, configuración del retransmisor. Muy sensibles: son un mapa para un atacante.
- Datos personales y vinculados a pacientes: cualquier cosa sobre una persona identificable. En el hospital, los registros de eventos de las bombas de infusión vinculados a una planta y una hora pueden identificar a un paciente. Se aplica la legislación de protección de datos; en la UE, el RGPD (Regulation (EU) 2016/679) exige, entre otros principios, que los datos personales no se conserven más tiempo del necesario para su finalidad. Nota para el lector hispanohablante: en España, el RGPD se complementa con la Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales; en América Latina rige la ley de cada país, por ejemplo la Ley 25.326 en Argentina o la Ley 1581 de 2012 en Colombia.
- Registros de seguridad: autenticación, flujos, alertas. A menudo contienen datos personales (nombres de usuario, direcciones) y deben protegerse y conservarse según la política.
El Marco de Privacidad del NIST ofrece una estructura para gestionar el riesgo de privacidad junto con el riesgo de ciberseguridad (NIST Privacy Framework).
12.3 Verificar el registro
Los registros se degradan igual que los inventarios. Verifíquelos muestreando lo que ocurre de verdad: qué sistemas envían a cuáles (flujos), qué clase de datos va en las cargas útiles (muestreo de metadatos por parte del responsable de los datos, no leyendo historias de pacientes), si el transporte va cifrado y cuánto tiempo conserva realmente los datos el destino (su configuración de conservación y la antigüedad de sus registros más antiguos). Las diferencias son de tipos conocidos: flujos no registrados; flujos que envían una clase distinta de la registrada; cifrado registrado pero ausente; conservación más larga que la registrada.
12.4 Los flujos nuevos necesitan revisión antes de empezar
La mayoría de los problemas de flujos de datos empiezan con una petición razonable: un proveedor quiere telemetría para diagnóstico remoto; un equipo de informes quiere una copia de los eventos de la pasarela clínica. Antes de que empiece un flujo así, se redacta y se revisa la entrada del registro: la revisan el responsable de los datos, seguridad (protección y conducto) y, cuando hay datos personales, la función de privacidad. Si transporta datos de control o de configuración, se aplica la regla de arquitectura del capítulo 8. La petición de Kell de recibir telemetría horaria de los retransmisores es el caso de Fallowmere: la entrada debe redactarse y revisarse antes de que se envíe la primera hora.
12.5 Ejemplo resuelto: el registro frente a la realidad (sintético)
El Lab 12 compara cinco entradas del registro con siete flujos observados. Cuatro flujos registrados coinciden. Tres diferencias importan:
- DF5 (de la pasarela clínica a Halden Cloud) conserva datos vinculados a pacientes durante 400 días frente a los 30 registrados. El flujo está registrado y cifrado, pero la conservación en el destino no coincide. Es una cuestión de privacidad y de contrato; hay que informar al responsable de los datos del hospital y cotejar la configuración de conservación de Halden con el contrato.
- Un flujo no registrado del historiador a un sistema de soporte del proveedor, en texto claro. Transporta telemetría (no personal, pero sensible desde el punto de vista operativo) sin cifrado y sin que nadie lo haya aprobado.
- Un flujo no registrado de la pasarela clínica al servidor de informes que transporta datos vinculados a pacientes. Cifrado, pero nadie lo aprobó, y el servidor de informes está en la zona corporativa que usa el personal de agua.
El tercero es el más grave pese a ir cifrado: los datos vinculados a pacientes han llegado a un sistema y a un público sin ninguna finalidad registrada. El cifrado en tránsito protege el trayecto, no el destino.
12.6 Actividad práctica: comprobación del registro
Lab 12 (guárdelo como lab12.py y ejecútelo con python3 lab12.py):
# Lab 12 - checking a data-flow register against what the service actually sends (offline, standard library only)
# Synthetic: Fallowmere shared services. Each register entry: id, source, destination, data class, encrypted, retention days.
register = [
("DF1", "PS-*", "RLY-01", "telemetry", False, 0),
("DF2", "RLY-01", "HIST-01", "telemetry", True, 730),
("DF3", "HIST-01", "REPORTS", "telemetry-aggregate", True, 365),
("DF4", "WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("DF5", "CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 30),
]
observed = [ # source, destination, data class seen by sampling payload metadata, tls?, stored days at destination
("PS-04", "RLY-01", "telemetry", False, 0), ("RLY-01", "HIST-01", "telemetry", True, 730),
("HIST-01", "REPORTS", "telemetry-aggregate", True, 365), ("WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 400), ("HIST-01", "VENDOR-SUPPORT", "telemetry", False, None),
("CLIN-GW", "REPORTS", "patient-linked", True, 365),
]
sensitive = {"patient-linked"}
def match(src, dst):
for r in register:
if (r[1] == src or (r[1].endswith("*") and src.startswith(r[1][:-1]))) and r[2] == dst:
return r
for src, dst, cls, enc, keep in observed:
r = match(src, dst)
if r is None:
sev = "HIGH" if cls in sensitive else "MED"
print(f"{sev:<4} unregistered flow {src}->{dst} ({cls}, encrypted={enc})")
continue
issues = []
if r[3] != cls: issues.append(f"class {cls} != registered {r[3]}")
if r[4] and not enc: issues.append("registered encrypted but sent clear")
if keep is not None and keep > r[5]: issues.append(f"kept {keep} d > registered {r[5]} d")
print(f"{'OK ' if not issues else 'HIGH' if cls in sensitive else 'MED '} {r[0]} {src}->{dst} {'; '.join(issues)}")
Salida esperada (Python 3.13.5):
OK DF1 PS-04->RLY-01
OK DF2 RLY-01->HIST-01
OK DF3 HIST-01->REPORTS
OK DF4 WARD-PUMPS->CLIN-GW
HIGH DF5 CLIN-GW->HALDEN-CLOUD kept 400 d > registered 30 d
MED unregistered flow HIST-01->VENDOR-SUPPORT (telemetry, encrypted=False)
HIGH unregistered flow CLIN-GW->REPORTS (patient-linked, encrypted=True)
La salida reproduce las tres diferencias anteriores. Antes de actuar, decida quién recibe cada una: la conservación de 400 días de DF5 va al responsable de los datos del hospital y a quien gestione el contrato con Halden; el flujo en texto claro del historiador al sistema de soporte del proveedor va al responsable de los datos de Agua y a FSTS Security; y el flujo no registrado de datos vinculados a pacientes hacia el servidor de informes va primero a la función de privacidad del hospital, porque un público de la zona corporativa puede haber visto ya los datos.
12.7 Errores frecuentes y límites
- Registrar caminos (conductos), pero no clases de datos ni conservación.
- Suponer que «cifrado» significa «aceptable».
- Tratar la telemetría operativa como inofensiva porque no es personal.
- Verificar las clases de datos leyendo usted mismo datos personales, en lugar de pedir al responsable de los datos que muestree metadatos.
- Dejar que empiece un flujo de proveedor o de informes antes de revisar la entrada.
El registro muestra lo que se conoce; los flujos que salen por rutas inesperadas (soportes extraíbles, el portátil de un proveedor) necesitan otros controles. El flujo no registrado de la pasarela clínica al servidor de informes es el segundo error en acción: cifrado y, aun así, inaceptable.
Ejercicios — capítulo 12
EX034 — Clasifique las diferencias por prioridad. Objetivo: priorizar los hallazgos sobre flujos de datos. Entradas: la salida del Lab 12. Restricciones: una acción y un responsable por hallazgo. Pasos: (1) ordene los tres hallazgos; (2) indique la primera acción y el responsable; (3) indique cuál debe comunicarse a alguien ajeno a FSTS. Evidencia esperada: tabla. Rúbrica: 3 = CLIN-GW→REPORTS primero (datos vinculados a pacientes no aprobados ante un público equivocado: detener el flujo con el acuerdo del responsable de los datos del hospital, evaluar), la conservación de DF5 segundo (responsable de los datos del hospital y contrato con Halden), el texto claro hacia el soporte del proveedor tercero (detener o cifrar, registrar); reconoce que la necesidad de comunicarlo externamente la deciden el responsable de los datos y la función de privacidad; 2 = orden defendible, responsables vagos; 1 = ordena solo por cifrado; 0 = nada.
EX035 — Redacte una entrada del registro. Objetivo: especificar un flujo nuevo antes de que empiece. Entradas: Kell Instruments pide telemetría horaria de PS-09 para diagnóstico remoto. Restricciones: todos los campos del capítulo 12 («El registro»); incluya el conducto y la protección. Pasos: redacte la entrada y enumere quién debe aprobarla. Evidencia esperada: entrada y aprobadores. Rúbrica: 3 = origen y destino concretos (exportación del retransmisor o del historiador, no la RTU directamente), clase de datos telemetría operativa, transporte cifrado, campos y frecuencia mínimos, conservación limitada y contractual, propósito, responsable, aprobaciones del responsable de los datos de Agua y de seguridad de FSTS, con fecha de caducidad; 2 = un campo débil; 1 = «enviar datos a Kell»; 0 = nada.
EX036 — Amplíe la comprobación. Objetivo: añadir una comprobación a la herramienta. Entradas: el Lab 12. Restricciones: solo la biblioteca estándar. Pasos: (1) añada una comprobación que señale cualquier flujo de datos patient-linked cuyo destino no esté en una lista aprobada {"CLIN-GW", "HALDEN-CLOUD"}, aunque esté registrado; (2) registre ("DF6", "CLIN-GW", "REPORTS", "patient-linked", True, 365) y vuelva a ejecutar; (3) explique por qué el mero registro no debería hacer aceptable ese flujo. Evidencia esperada: código, salida y explicación. Rúbrica: 3 = el flujo hacia REPORTS sigue señalado tras registrarlo; explicación de que el registro recoge decisiones, y de que un flujo registrado hacia un público no aprobado es una mala decisión que hay que revisar, no un resultado limpio; 2 = el código funciona, explicación escasa; 1 = no se ejecutó; 0 = nada.
Síntesis del capítulo
Un registro de flujos de datos recoge qué datos viajan a dónde, cómo se protegen y cuánto tiempo se conservan. Clasifique los datos (telemetría, configuración, datos personales y vinculados a pacientes, registros de seguridad) y verifique el registro frente a lo que los sistemas realmente envían y conservan. El cifrado protege el trayecto, no el destino. Los flujos nuevos se revisan antes de empezar: los revisan el responsable de los datos, seguridad y, cuando hay datos personales, la función de privacidad.
Siga estudiando — capítulo 12 de 30
← Capítulo 11 · Índice de capítulos del curso · Capítulo 13 →
Continúe con la siguiente lección escrita.