~/bigdatastack

lección 5

Día 3 (tarde) -- El incidente de acceso no autorizado

Javier accedió a datos de pacientes sin autorización. El audit trail que acabas de implementar lo detecta. Gestión del incidente en tiempo real: contención, investigación, documentación y decisión sobre notificación a la AEPD.

⏱ 45 min

### Miércoles, 15:30 -- La alerta

Dataset de esta lección (en tu carpeta datos/): datos/access_log_sample.json (JSON Lines). Para la investigación forense del incidente de JFE-0024 te apoyarás en los campos user, timestamp, table, operation, query, rows_returned y source_ip de cada acceso, reconstruyendo la cronología de lo que hizo Javier. Es el mismo fichero de accesos del audit trail que preparaste por la mañana.

Estás terminando de desplegar los triggers de auditoría cuando tu correo recibe una alerta automática del sistema de detección de anomalías (que Laura configuró hace meses para queries sospechosas). El asunto dice: "ALERTA: acceso masivo a datos de pacientes - usuario JFE-0024". Te quedas frío. JFE-0024 es Javier.

1DE: alertas-seguridad@meditrack.es
2PARA: laura.sanchez@meditrack.es, tu@meditrack.es
3CC: rosa.martinez@meditrack.es
4ASUNTO: [ALERTA SEGURIDAD] Acceso anomalo detectado
5

6Timestamp: 2024-03-06 15:12:04 UTC
7Usuario: JFE-0024 (Javier Fernandez, Junior Data Engineer)
8Rol: data_engineer_junior
9

10Actividad detectada:
11- SELECT sobre tabla "historiales" -- 847 registros
12- SELECT sobre tabla "pacientes" -- 312 registros (JOIN con historiales)
13- Filtro: diagnostico_cie10 LIKE 'F%' (trastornos mentales)
14- Sin justificacion registrada
15- Sin finalidad declarada
16- IP: 10.0.3.47 (red interna, puesto de Javier)
17

18Contexto:
19El usuario JFE-0024 NO tiene asignada ninguna tarea que requiera
20acceso a datos de salud mental. Su rol actual limita acceso a 
21datos de wearables y operaciones basicas.
22

23ACCION REQUERIDA: Verificar legitimidad del acceso.

El audit trail FUNCIONA -- acaba de detectar algo que no deberia pasar

Laura aparece en tu puesto en 30 segundos. "Has visto el email?" Asientes. Laura cierra la puerta de la sala: "Javier ha accedido a datos de salud mental de 312 pacientes sin autorización. No tiene ninguna tarea asignada que justifique ese acceso. Esto es un incidente de seguridad. Tenemos que actuar ahora."

Sientes un nudo en el estómago. Javier es TU compañero. Le mentorizas. Es un chaval de 24 años que probablemente no sabía lo que estaba haciendo. Pero eso no cambia el hecho: ha accedido a datos de categoría especial sin consentimiento, sin finalidad declarada y sin autorización de su rol. En términos legales, es una brecha de confidencialidad interna.

### Fase 1: Contención inmediata

Laura toma el mando: "Primero contenemos. Después investigamos. No acuses a nadie hasta que sepamos qué pasó." Las acciones inmediatas:

  1. 01.Revocar acceso de Javier a tablas de pacientes e historiales (inmediato, sin explicación todavía)
  2. 02.Verificar si los datos fueron exportados fuera del sistema (downloads, copias, envíos por email)
  3. 03.Preservar evidencia: snapshot del audit trail con las queries exactas de Javier
  4. 04.Notificar a Rosa (DPO) -- ella decide si hay obligación de notificar a la AEPD en 72h
  5. 05.No confrontar a Javier todavía -- Rosa quiere hablar con él primero junto con RRHH
1Laura Sanchez  15:38 PM  DM a ti
2No le digas nada a Javier todavía. Se que es tu compañero y esto
3es incomodo. Pero Rosa tiene que evaluar la gravedad primero.
4

5Necesito que hagas:
61. Query al audit trail: TODO lo que hizo Javier hoy
72. Verificar si hizo COPY TO o pg_dump (exportación)
83. Comprobar si envio algo por email o Slack (esto lo hace IT)
94. Documentar la cronologia exacta
10

11Yo voy a revocarle acceso ahora. Si te pregunta, dile que hay
12un "mantenimiento de permisos" y que es temporal.
13

14Rosa Martinez  15:41 PM  DM a Laura
15Laura, necesito un informe del incidente en mi mesa antes de las 18h.
16Tengo 72 horas para decidir si notificamos a la AEPD (Art. 33).
17Si los datos NO salieron del sistema, puede que no sea obligatorio.
18Pero necesito estar SEGURA.

La tensión es real -- tu compañero puede estar en problemas serios

### Fase 2: Investigación

Tu rol ahora es técnico: investigar qué hizo Javier exactamente. Sin juicio, sin emoción. Los hechos primero. Ejecutas una serie de queries contra el audit trail para reconstruir la cronología:

1-- Investigacion: reconstruir TODA la actividad de JFE-0024 el día del incidente
2SELECT 
3    timestamp_utc,
4    operación,
5    tabla_afectada,
6    num_registros,
7    query_ejecutada,
8    finalidad,
9    justificacion,
10    ip_origen
11FROM audit_accesos_pacientes
12WHERE usuario_id = 'JFE-0024'
13  AND DATE(timestamp_utc) = '2024-03-06'
14ORDER BY timestamp_utc ASC;
15

16-- Resultado:
17-- 09:15  SELECT  wearables       45  "SELECT COUNT(*) FROM wear..."  operacional  tarea-WEA-001  10.0.3.47
18-- 09:47  SELECT  wearables      120  "SELECT * FROM wearables..."   operacional  tarea-WEA-001  10.0.3.47
19-- 11:30  SELECT  consultas       50  "SELECT tipo, COUNT(*) ..."    operacional  tarea-OPS-003  10.0.3.47
20-- 14:55  SELECT  pacientes        1  "SELECT * FROM pacientes..."   NULL         NULL           10.0.3.47  ← AQUI EMPIEZA
21-- 15:02  SELECT  historiales    200  "SELECT * FROM historiale..."   NULL         NULL           10.0.3.47
22-- 15:08  SELECT  historiales    647  "SELECT h.*, p.fecha_nac..."   NULL         NULL           10.0.3.47
23-- 15:12  SELECT  pacientes+hist 312  "SELECT p.nombre, h.diag..."   NULL         NULL           10.0.3.47  ← LA ALERTA

El audit trail muestra la cronología exacta -- de lo legítimo a lo no autorizado

El patrón es claro: hasta las 11:30, Javier hacía queries normales sobre wearables y consultas (sus tareas asignadas). A las 14:55 -- justo después de comer -- empezó a explorar tablas que no le corresponden. Sin finalidad, sin justificación. Y la última query es la más grave: un JOIN entre pacientes (con nombres) e historiales filtrado por diagnósticos F% (trastornos mentales y del comportamiento). Vio nombres de personas con diagnósticos psiquiátricos.

### La conversación con Javier (después)

Rosa habla con Javier al día siguiente junto con RRHH y Laura. Tú no estás en esa reunión, pero Laura te cuenta después. La versión de Javier:

1Laura Sanchez  (jueves mañana, después de la reunion con Javier)
2

3"Te cuento lo que pasó. Javier dice que el Dr. Martin le pidió
4directamente -- sin pasar por nosotros -- que le sacara 'unos datos
5rapidos' sobre pacientes con trastornos de ansiedad para una
6presentación interna. Javier, queriendo agradar, lo hizo sin
7preguntar si tenía permiso.
8

9Rosa está furiosa -- no con Javier (que es junior y no sabía),
10sino con el protocolo que permitía que esto pasara. Un junior
11NO deberia tener acceso a esas tablas en primer lugar.
12

13Consecuencias:
14- Javier: amonestacion verbal + formacion obligatoria en GDPR
15- Dr. Martin: Rosa va a tener una 'conversacion seria' con el
16- Nosotros: implementar RLS para que esto SEA IMPOSIBLE tecnicamente
17- Nadie ha sido despedido -- fue un error de ignorancia, no malicia
18

19La buena noticia: los datos NO salieron del sistema. Javier no
20copio nada, no envio nada. Solo hizo SELECTs en DBeaver y miro
21los resultados en pantalla. Eso significa que probablemente no
22hay obligacion de notificar a la AEPD (Art. 33.1 -- solo si hay
23'riesgo para los derechos y libertades'). Rosa decide que no."
24

25Tu: "Pobre Javier. Pero entiendo -- tiene que aprender que no
26puedes tocar datos de salud mental porque alguien te lo pide
27informalmente."
28

29Laura: "Exacto. Y por eso necesitamos RLS implementado MANANA.
30Que sea tecnicamente imposible repetir esto."

No hubo malicia -- pero eso no cambia que sea un incidente de seguridad

Consejo de senior: Los incidentes de seguridad más comunes no son hackers externos -- son empleados internos que cometen errores por desconocimiento. El 80% de las brechas de datos son internas. La solución no es castigar (Javier no tenía mala intención) sino hacer que sea TECNICAMENTE IMPOSIBLE repetir el error. Eso es Row-Level Security: no depender de que la gente "se acuerde" de no acceder a datos -- hacer que el sistema IMPIDA el acceso aunque lo intenten.

Art. 33 GDPR: Obligación de notificar brechas a la AEPD en 72 horas SI hay riesgo para los derechos de los interesados. En este caso, los datos no salieron del sistema (solo SELECTs sin exportación), no se compartieron con terceros y se detectó en minutos. Rosa decide que no hay obligación de notificar. PERO documenta la decisión y la justificación por si la AEPD pregunta posteriormente.

### El post-mortem del incidente

Laura te pide que redactes el post-mortem técnico del incidente. Es un documento interno que queda en el registro de seguridad. Debe ser factual, sin juicios de valor, y con acciones correctivas claras:

  • QUE pasó: un junior accedió a datos de salud mental sin autorización ni justificación
  • CUANDO: 6 de marzo 2024, 14:55-15:12 UTC
  • COMO se detectó: sistema de alertas automático sobre el audit trail (nuevo, implementado esa misma mañana)
  • IMPACTO: 312 pacientes afectados (nombres + diagnósticos psiquiátricos visualizados)
  • CONTENCION: acceso revocado en 26 minutos desde la detección
  • CAUSA RAIZ: permisos de BD excesivos para rol junior + petición directa de Dr. Martin sin pasar por protocolo
  • DATOS EXFILTRADOS: NO -- solo SELECT en cliente SQL local, sin exportación
  • NOTIFICACION AEPD: NO -- sin riesgo para derechos de interesados (datos no salieron del sistema)
  • ACCIONES CORRECTIVAS: implementar RLS, formación GDPR obligatoria, canal formal para peticiones de datos

## ejercicios

[01]

Investigacion forense del incidente

Usando el audit trail, escribe las queries necesarias para la investigacion completa: 1) cronologia de accesos de Javier el día del incidente, 2) verificar si hubo exportación (COPY, pg_dump), 3) identificar pacientes afectados, 4) determinar si el patron de acceso indica intencion o exploracion casual.

Cargando editor...
[02]

Informe post-mortem del incidente

Redacta el informe post-mortem técnico del incidente en formato estructurado. Incluye: resumen ejecutivo, cronologia, impacto, causa raiz, acciones tomadas, acciones correctivas pendientes y decisión sobre notificación a AEPD con justificacion legal.

Cargando editor...
[03]

Script de revocacion inmediata de acceso

Implementa una función SQL que revoque INMEDIATAMENTE todos los accesos de un usuario a tablas sensibles. Debe: 1) revocar GRANTs, 2) terminar sesiones activas del usuario, 3) registrar la revocacion en el audit trail, 4) notificar (simulado) al equipo. Es lo que Laura ejecuto en los 26 minutos de contencion.

Cargando editor...
[04]

Detector de patrones anomalos en accesos

Implementa una query SQL que detecte automaticamente accesos anomalos: 1) más de 50 pacientes distintos en 1 hora, 2) acceso fuera de horario a tablas críticas, 3) acceso a especialidades que no corresponden al medico, 4) queries sin justificacion sobre historiales.

Cargando editor...

Regístrate para guardar tu progreso.

## comentarios

Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.

Inicia sesión para comentar y responder.

cargando comentarios...