Las cuatro grandes filtraciones de datos de 2026 en Japón (KDDI, Aflac, Agencia Digital, Sakura): distintas vías de entrada, la misma solución — una mejor detección

Una de las causas que señaló Aflac fue que «faltaban funciones para supervisar y controlar las consultas masivas de datos en poco tiempo». Asigne a cada API o pantalla que devuelva datos de clientes un tope de registros por solicitud y por hora, además de una alerta a una persona cuando el uso se acerque al tope. Incluso con un inicio de sesión válido, extraer decenas de miles de registros en poco tiempo no se parece a cómo usan un sistema las personas. Cómo decidir qué contar, por quién y hasta qué número se trata en limitación de tasa y control del abuso.

Hay tres capas en las que puede medir.

En la aplicación: cuente los registros por cuenta dentro de las rutas de búsqueda, listado y exportación; es la única capa que sabe quién extrajo cuánto.
Delante de ella: limit_req de nginx o una regla de limitación de tasa en un CDN, que limite las solicitudes por segundo o por minuto en cada endpoint.
En la plataforma: el centro de alertas de Google Workspace y el registro de auditoría y las políticas de alerta de Microsoft 365 pueden notificar las descargas y exportaciones masivas (lo que obtiene depende de su plan).

Empiece por un solo endpoint: el que devuelve más registros. Asígnele un tope horario por cuenta y una alerta al 80 % de ese tope. Un solo endpoint que avise de verdad a una persona vale más que un diseño completo que todavía se está escribiendo.

La primera medida de la corrección de Aflac es una «autenticación en el acceso y autorización en la consulta de datos» más sólida. Que alguien pueda iniciar sesión (autenticación) y que pueda ver un registro concreto (autorización) son preguntas distintas, y si la segunda no se comprueba registro por registro, un usuario correctamente autenticado puede consultar los datos de otras personas. La diferencia se explica en autenticación frente a autorización, y el fallo clásico en IDOR.

En el caso de Sakura Internet, el acceso al sistema de gestión de ventas comenzó unos tres años antes de que saliera a la luz. Si los registros de ese periodo ya no existen cuando se detecta el problema, no se puede afirmar ni lo que pasó ni lo que no pasó. Sakura también incluyó una revisión del alcance y de la retención de registros. Si el almacenamiento solo permite unas pocas semanas, una división realista es conservar durante mucho más tiempo al menos los registros de autenticación y de consultas de datos.

Una cifra de referencia: el estándar de pagos con tarjeta (PCI DSS) exige 12 meses de retención, con los tres meses más recientes disponibles de inmediato. Aun fuera de los pagos, es un punto de partida útil.

Conserve al menos tres tipos: autenticación (éxitos y fallos), consultas y exportaciones de datos, y acciones administrativas. Los registros de acceso del servidor web por sí solos no permiten saber quién se llevó cuántos registros.

El fallo explotado en el caso de KDDI era uno que el propio proveedor desconocía cuando se encontró. En ese momento no existía ninguna solución. Como algunas intrusiones no pueden evitarse ni siquiera con parches perfectos, la capacidad de detectar actividad sospechosa y tráfico saliente en los servidores —el EDR que KDDI desplegó en todos los servidores es un ejemplo— es lo que queda.

Nada de esto significa que evitar la intrusión importe menos. El caso de la Agencia Digital entró a través de una vulnerabilidad en un dispositivo VPN. No dejar abiertas vulnerabilidades conocidas sigue siendo la defensa más rentable que existe. Para los dispositivos VPN, véase Los dispositivos VPN son la principal vía de entrada del ransomware; para ordenar el trabajo, véase priorizar con CVSS, EPSS y KEV.