El 88 % de las claves de AWS filtradas sigue funcionando

Una clave de acceso de AWS no caduca. No hay aviso a los noventa días, ni correo de renovación, ni nada que la apague sola: se crea una vez y sigue ahí hasta que alguien se acuerda de borrarla. El 10 de agosto, Truffle Security cogió 10.616 pares de credenciales que habían ido apareciendo en abierto desde agosto de 2022 y probó, una a una, cuáles seguían contestando. Contestó el 88 %.

Publicaron el trabajo el 19 de agosto y la prensa del sector lo recogió dos días después. Partieron de 431.875 hallazgos verificados, destilaron 64.024 claves únicas y reverificaron 10.616 de ellas. Contra cada uno hicieron solo llamadas de lectura — sts:GetCallerIdentity, iam:ListAccessKeys, las políticas asociadas, el contacto de la cuenta, Organizations, Budgets y una llamada a Cost Explorer por cuenta — y lo escriben sin adornos: no leyeron documentos de política, ni recursos, ni datos, y no modificaron nada. Dicen estar avisando, antes de publicar, a todos los propietarios que pudieron identificar: 10.260 de las 10.616 claves. Es una metodología que se puede criticar por otros sitios, pero está declarada entera, que es más de lo que suele traer un informe con estas cifras.

De las claves de empresa, el 94 % abría la cuenta entera

Que una clave siga viva no dice todavía cuánto duele. Lo interesante viene después: de las 9.308 claves activas que consiguieron clasificar, 817 se pudieron atribuir a una empresa cruzando el contacto de la cuenta con el patrón del usuario. Y de esas 817, el desglose es este: 526 eran claves de la cuenta raíz y 242 pertenecían a usuarios IAM con la política AdministratorAccess.

Y hay un subconjunto peor. 130 claves raíz activas estaban en cuentas de gestión de una organización, la cuenta desde la que cuelga el árbol entero en AWS Organizations. Ahí no se compromete una cuenta: se compromete la estructura que gobierna a las demás. Merece la pena recordar que la propia documentación de AWS tiene un apartado titulado «no crees claves de acceso para el usuario raíz» y recomienda eliminar las credenciales de raíz en las cuentas miembro de una organización. Aquí hay 526 que existían y que además estaban publicadas.

La clave más antigua es anterior a IAM

De 2.903 claves pudieron sacar la fecha de creación, y ahí es donde el estudio deja de hablar de un descuido y empieza a hablar de sedimento. La mediana de antigüedad es de 1.831 días: cinco años. Solo 25, el 0,9 %, se habían creado en los últimos treinta días. Esto no es «alguien metió la pata ayer»; es una capa de credenciales viejas que nadie ha vuelto a tocar. Lo confirma el dato de rotación: únicamente 398 de esas 2.903 —el 13,7 %— tenían una clave más nueva asociada al mismo usuario. Al resto no las ha sustituido nadie.

La clave más antigua que encontraron llevaba 17,4 años existiendo, lo que la sitúa en marzo de 2009. Hicimos la cuenta y luego fuimos a comprobar qué había en AWS por entonces: IAM no existía. El informe la despacha como «casi tan antigua como IAM»; con las dos fechas delante se queda corto. Amazon anunció la beta en vista previa el 2 de septiembre de 2010 y la disponibilidad general el 3 de mayo de 2011. Una credencial de 2009 no pudo nacer como clave de un usuario IAM porque no había usuarios IAM; era la credencial de la cuenta, de cuando la única identidad de una cuenta de AWS era la cuenta misma. Diecisiete años después sigue autenticando.

AWS ya había avisado, y la llave seguía abriendo

Este es el matiz que más nos interesó del informe, porque explica buena parte del 88 %. 929 de los 7.590 usuarios IAM activos, un 12 %, tenían adjunta la política AWSCompromisedKeyQuarantine: la que AWS engancha por su cuenta cuando detecta que una credencial anda por ahí fuera. Es decir, AWS ya lo sabía.

Conviene saber exactamente qué hace y qué no hace esa política, porque su nombre engaña. Según la propia documentación de AWS, deniega un conjunto concreto de acciones —crear claves de acceso, tocar usuarios, roles y grupos de IAM, lanzar instancias EC2, permisos de Lambda, consultas a CloudTrail— con el objetivo declarado de limitar el daño potencial sin afectar a los recursos existentes. Lo que no hace es invalidar la credencial: la clave sigue siendo válida y sigue autenticando. Contener no es cerrar.

AWS notifica a los clientes afectados siempre que tiene conocimiento de claves expuestas, y aplica esas políticas de cuarentena. Funciona. El agujero está en el otro lado del correo: alguien tiene que abrirlo, encontrar a quién pertenece esa clave de hace cinco años, comprobar qué se rompe si la borra, y borrarla. Ese trabajo no lo hace el proveedor.

Y luego está Hugging Face

El material venía de sitios previsibles: historiales de git públicos, imágenes de Docker, registros de paquetes, trazas de CI/CD. Y hay otro sitio que Truffle Security cuenta aparte, fuera de ese recuento: en Hugging Face, la plataforma donde se comparten modelos y datos de entrenamiento, las credenciales de AWS son el segundo tipo de secreto que más verifican, con 8.482 claves únicas y vivas repartidas en 3.394 conjuntos de datos públicos. Ahí, además, las claves escoran hacia el privilegio: el 17,9 % son de la cuenta raíz.

Tiene una explicación aburrida y por eso es peligrosa. Un repositorio de código pasa por una revisión, tiene quien lo mire en un merge request y, cada vez más, un escáner de secretos en el hook de pre-commit. Un conjunto de datos no pasa por nada de eso. Es un fichero grande que alguien sube porque el modelo lo necesita, y dentro van trazas, volcados, cuadernos y ficheros de configuración que nadie lee línea a línea porque son cuatro gigabytes. La revisión que sí existe para el código no se ha extendido al material de entrenamiento, y el resultado está en la cifra.

Esto es lo que hay detrás de una frase que repetimos mucho cuando montamos automatización con IA en una empresa: la primera pregunta no es qué modelo, sino qué sale de casa. Qué se sube a entrenar, a evaluar o a un proveedor externo, y con qué dentro. Ya escribimos sobre el otro extremo de esta cuerda, el día en que un título de issue acabó llevándose un token: el patrón es el mismo, un dato que nadie considera peligroso arrastrando una credencial detrás.

El detector más barato lo tiene una cuenta de cada diez

Hay un dato en el informe que a nosotros nos parece el más accionable de todos. De las cuentas que pudieron consultar, solo 262 —el 9,5 %— tenían configurada una alerta de presupuesto. Y la mediana de esas alertas está en 8 dólares. Mientras tanto, el gasto agregado de julio en las cuentas medidas fue de 420.631 dólares, con 50 cuentas por encima de los 1.000 y 9 por encima de los 10.000.

Lo que no te vamos a recomendar

La reacción de manual a un informe como este es comprar un gestor de secretos. No es lo que diríamos si nos llamas mañana. Un gestor de secretos montado encima de un inventario que no existe mueve el problema de sitio y añade una dependencia. Lo primero es la lista aburrida —cuántas credenciales de larga duración hay vivas, quién es el dueño de cada una, qué se rompe si desaparece— y esa lista casi nunca la tiene nadie completa. Cuando por fin existe, casi siempre aparecen claves que se pueden apagar sin que se entere nadie, porque ya no las usaba ningún sistema.

Y toca declarar el interés, o la falta de él. Nosotros no vivimos de AWS. Operamos Proxmox VE con Ceph en producción y hierro propio en datacenter, así que este post no es una invitación a mudarte de nube ni un argumento a favor de la nuestra. Lo escribimos porque el patrón no es de AWS: es de cualquier credencial que se crea una vez y no caduca nunca. Un token de la API de Proxmox sin fecha de caducidad, la clave de un Proxmox Backup Server metida en un script de 2021, un secreto de aplicación de Entra ID que renovó alguien que ya no trabaja allí. Escribiendo sobre la columna que estaba cifrada y guardaba texto plano ya nos salió la misma moraleja: el problema casi nunca es el algoritmo, es dónde acabó la llave. Y el token que nunca llega a pedir el segundo factor es el mismo animal con otra piel.

El orden en que lo hacemos nosotros

Con las cifras del estudio delante, este es el orden que defendemos en una consultoría — y lo defendemos porque no vendemos licencias de nadie, así que la lista no está sesgada por lo que nos toque de comisión:

Nada de esto es brillante y ninguno de los cuatro puntos se vende bien. Pero mira otra vez la distribución del estudio: mediana de cinco años y un 0,9 % creadas el mes pasado. Con esa forma, lo que te falta es el hábito de borrar.

La pregunta no es cuántas se filtran

Se filtran todos los días, en todas partes y en todas las plataformas, y quien diga que en su casa no ha pasado nunca es que no ha mirado. La pregunta útil es otra: cuánto tiempo sigue abriendo la puerta una llave que ya está fuera. De las que dejaron ver su fecha, la mediana lleva cinco años creada. Y el 88 % contestó el 10 de agosto, cuando alguien de fuera se molestó en probar. Eso, exactamente, es lo que puede hacer cualquiera.

Fuentes: metodología (431.875 hallazgos, 64.024 claves únicas, 10.616 pares reverificados el 10 de agosto con solo llamadas de lectura, 10.260 propietarios notificados), el 88 % que autentica, el desglose 817 / 526 / 242 / 768, las 130 claves raíz en cuentas de gestión de organización, la antigüedad (mediana 1.831 días, máxima 17,4 años, 25 claves de los últimos 30 días), la rotación del 13,7 % (398 de 2.903), los 929 usuarios con AWSCompromisedKeyQuarantine, las 8.482 claves en 3.394 conjuntos de datos de Hugging Face con un 17,9 % de raíz y las cifras de presupuesto (262 cuentas, mediana 8 $, 420.631 $ de gasto agregado en julio) — Truffle Security, 19 de agosto de 2026. Cobertura y respuesta de AWS — BleepingComputer, 21 de agosto de 2026. Alcance real de la política de cuarentena y recomendación sobre las claves de la cuenta raíz — documentación de AWS (AWSCompromisedKeyQuarantineV3 y buenas prácticas de la cuenta raíz). Fechas de IAM — anuncios de AWS de la beta en vista previa (2 de septiembre de 2010) y de la disponibilidad general (3 de mayo de 2011). Cálculos propios: el 94 % (768 sobre 817) y situar los 17,4 años de la clave más antigua en marzo de 2009, anterior a la existencia de IAM.