Una clau d'accés d'AWS no caduca. No hi ha avís als noranta dies, ni correu de renovació, ni res que l'apagui sola: es crea un cop i continua allà fins que algú se'n recorda d'esborrar-la. El 10 d'agost, Truffle Security va agafar 10.616 parells de credencials que havien anat apareixent en obert des de l'agost del 2022 i va provar, una a una, quines continuaven contestant. Va contestar el 88 %.
Van publicar el treball el 19 d'agost i la premsa del sector el va recollir dos dies després. Van partir de 431.875 troballes verificades, van destil·lar 64.024 claus úniques i en van reverificar 10.616. Contra cadascun van fer només crides de lectura — sts:GetCallerIdentity, iam:ListAccessKeys, les polítiques associades, el contacte del compte, Organizations, Budgets i una crida a Cost Explorer per compte — i ho escriuen sense adorns: no van llegir documents de política, ni recursos, ni dades, i no van modificar res. Diuen que estan avisant, abans de publicar, tots els propietaris que van poder identificar: 10.260 de les 10.616 claus. És una metodologia que es pot criticar per altres costats, però està declarada sencera, que és més del que sol portar un informe amb aquestes xifres.
De les claus d'empresa, el 94 % obria el compte sencer
Que una clau continuï viva encara no diu quant fa mal. L'interessant ve després: de les 9.308 claus actives que van aconseguir classificar, 817 es van poder atribuir a una empresa creuant el contacte del compte amb el patró de l'usuari. I d'aquestes 817, el desglossament és aquest: 526 eren claus del compte arrel i 242 pertanyien a usuaris IAM amb la política AdministratorAccess.
526 més 242 són 768. Sobre 817, això és el 94 %. La divisió és nostra, no de l'informe: de cada cent claus filtrades que es van poder posar cara d'empresa, noranta-quatre donaven control total del compte sencer, i no accés a un bucket o permís de lectura sobre una cua.
I hi ha un subconjunt pitjor. 130 claus arrel actives eren a comptes de gestió d'una organització, el compte des del qual penja l'arbre sencer a AWS Organizations. Allà no es compromet un compte: es compromet l'estructura que governa els altres. Val la pena recordar que la mateixa documentació d'AWS té un apartat titulat «no creïs claus d'accés per a l'usuari arrel» i recomana eliminar les credencials d'arrel als comptes membre d'una organització. Aquí n'hi ha 526 que existien i que a sobre estaven publicades.
La clau més antiga és anterior a IAM
De 2.903 claus en van poder treure la data de creació, i és aquí on l'estudi deixa de parlar d'un descuit i comença a parlar de sediment. La mediana d'antiguitat és de 1.831 dies: cinc anys. Només 25, el 0,9 %, s'havien creat els darrers trenta dies. Això no és «algú va ficar la pota ahir»; és una capa de credencials velles que ningú no ha tornat a tocar. Ho confirma la dada de rotació: únicament 398 d'aquestes 2.903 —el 13,7 %— tenien una clau més nova associada al mateix usuari. La resta no les ha substituït ningú.
La clau més antiga que van trobar feia 17,4 anys que existia, cosa que la situa al març del 2009. Vam fer el compte i després vam anar a comprovar què hi havia a AWS aleshores: IAM no existia. L'informe la despatxa com a «gairebé tan antiga com IAM»; amb les dues dates al davant es queda curt. Amazon va anunciar la beta en vista prèvia el 2 de setembre del 2010 i la disponibilitat general el 3 de maig del 2011. Una credencial del 2009 no va poder néixer com a clau d'un usuari IAM perquè no hi havia usuaris IAM; era la credencial del compte, de quan l'única identitat d'un compte d'AWS era el compte mateix. Disset anys després continua autenticant.
AWS ja havia avisat, i la clau continuava obrint
Aquest és el matís que més ens va interessar de l'informe, perquè explica bona part del 88 %. 929 dels 7.590 usuaris IAM actius, un 12 %, tenien adjunta la política AWSCompromisedKeyQuarantine: la que AWS enganxa pel seu compte quan detecta que una credencial circula per aquí fora. És a dir, AWS ja ho sabia.
Convé saber exactament què fa i què no fa aquesta política, perquè el nom enganya. Segons la mateixa documentació d'AWS, denega un conjunt concret d'accions —crear claus d'accés, tocar usuaris, rols i grups d'IAM, engegar instàncies EC2, permisos de Lambda, consultes a CloudTrail— amb l'objectiu declarat de limitar el dany potencial sense afectar els recursos existents. El que no fa és invalidar la credencial: la clau continua sent vàlida i continua autenticant. Contenir no és tancar.
AWS notifica els clients afectats sempre que té coneixement de claus exposades, i aplica aquestes polítiques de quarantena. Funciona. El forat és a l'altre costat del correu: algú l'ha d'obrir, trobar a qui pertany aquesta clau de fa cinc anys, comprovar què es trenca si l'esborra, i esborrar-la. Aquesta feina no la fa el proveïdor.
I després hi ha Hugging Face
El material venia de llocs previsibles: historials de git públics, imatges de Docker, registres de paquets, traces de CI/CD. I hi ha un altre lloc que Truffle Security compta a part, fora d'aquest recompte: a Hugging Face, la plataforma on es comparteixen models i dades d'entrenament, les credencials d'AWS són el segon tipus de secret que més verifiquen, amb 8.482 claus úniques i vives repartides en 3.394 conjunts de dades públics. Allà, a més, les claus escoren cap al privilegi: el 17,9 % són del compte arrel.
Té una explicació avorrida i per això és perillosa. Un repositori de codi passa per una revisió, té qui el miri en un merge request i, cada cop més, un escàner de secrets al hook de pre-commit. Un conjunt de dades no passa per res d'això. És un fitxer gran que algú puja perquè el model el necessita, i a dins hi van traces, bolcats, quaderns i fitxers de configuració que ningú no llegeix línia a línia perquè són quatre gigabytes. La revisió que sí que existeix per al codi no s'ha estès al material d'entrenament, i el resultat és a la xifra.
Això és el que hi ha darrere d'una frase que repetim molt quan muntem automatització amb IA en una empresa: la primera pregunta no és quin model, sinó què surt de casa. Què es puja a entrenar, a avaluar o a un proveïdor extern, i amb què a dins. Ja vam escriure sobre l'altre extrem d'aquesta corda, el dia que un títol d'issue va acabar emportant-se un token: el patró és el mateix, una dada que ningú no considera perillosa arrossegant una credencial al darrere.
El detector més barat el té un compte de cada deu
Hi ha una dada a l'informe que a nosaltres ens sembla la més accionable de totes. Dels comptes que van poder consultar, només 262 —el 9,5 %— tenien configurada una alerta de pressupost. I la mediana d'aquestes alertes és de 8 dòlars. Mentrestant, la despesa agregada de juliol als comptes mesurats va ser de 420.631 dòlars, amb 50 comptes per sobre dels 1.000 i 9 per sobre dels 10.000.
Una alerta de pressupost no és una eina de seguretat i per això ningú no la compta com a tal. Però és el més semblant a un detector d'intrusió barat que existeix en un núvol públic: l'ús típic d'una credencial robada —mineria, enviament massiu, instàncies grans en una regió que no fas servir— apareix a la factura abans que en cap registre que estiguis mirant. Un pressupost de deu euros amb avís per correu no evita absolutament res, només avisa, i això és justament el que faltava en nou de cada deu comptes d'aquest estudi.
El que no et recomanarem
La reacció de manual a un informe com aquest és comprar un gestor de secrets. No és el que diríem si ens truques demà. Un gestor de secrets muntat damunt d'un inventari que no existeix mou el problema de lloc i afegeix una dependència. El primer és la llista avorrida —quantes credencials de llarga durada hi ha vives, qui és l'amo de cadascuna, què es trenca si desapareix— i aquesta llista gairebé mai no la té ningú completa. Quan per fi existeix, gairebé sempre hi apareixen claus que es poden apagar sense que se n'assabenti ningú, perquè ja no les feia servir cap sistema.
I toca declarar l'interès, o la manca d'interès. Nosaltres no vivim d'AWS. Operem Proxmox VE amb Ceph en producció i ferro propi al datacenter, així que aquest post no és una invitació a mudar-te de núvol ni un argument a favor del nostre. L'escrivim perquè el patró no és d'AWS: és de qualsevol credencial que es crea un cop i no caduca mai. Un token de l'API de Proxmox sense data de caducitat, la clau d'un Proxmox Backup Server ficada en un script del 2021, un secret d'aplicació d'Entra ID que va renovar algú que ja no hi treballa. Escrivint sobre la columna que estava xifrada i desava text pla ja ens va sortir la mateixa moralitat: el problema gairebé mai no és l'algorisme, és on va acabar la clau. I el token que no arriba mai a demanar el segon factor és el mateix animal amb una altra pell.
L'ordre en què ho fem nosaltres
Amb les xifres de l'estudi al davant, aquest és l'ordre que defensem en una consultoria — i el defensem perquè no venem llicències de ningú, així que la llista no està esbiaixada pel que ens toqui de comissió:
- 1.Comptar. Quantes credencials de llarga durada existeixen, en quines plataformes i des de quan. Amb la xarxa fem això mateix recolzant-nos en NetBox com a font de veritat; per a les credencials la idea és idèntica, una llista viva en comptes d'un Excel de fa dues fires.
- 2.Posar amo a cadascuna. Una credencial sense amo no es rota mai, perquè ningú no gosa tocar una cosa que no sap què trenca. D'aquí surt el 13,7 %.
- 3.Treure-les dels portàtils. Els nostres desplegaments van per CI/CD GitOps amb GitLab sobre Docker Swarm, i el que més s'agraeix d'això, més fins i tot que la reproductibilitat, és que el secret viu en un lloc i no en catorze màquines de catorze persones.
- 4.Posar el canari de la despesa. L'alerta de pressupost de què parlàvem més amunt, en tot compte de núvol que tinguis, encara que sigui el de proves. Sobretot si és el de proves.
Res d'això no és brillant i cap dels quatre punts no es ven bé. Però mira una altra vegada la distribució de l'estudi: mediana de cinc anys i un 0,9 % creades el mes passat. Amb aquesta forma, el que et falta és l'hàbit d'esborrar.
La pregunta no és quantes se'n filtren
Se'n filtren cada dia, arreu i en totes les plataformes, i qui digui que a casa seva no ha passat mai és que no ho ha mirat. La pregunta útil és una altra: quant de temps continua obrint la porta una clau que ja és fora. De les que van deixar veure la seva data, la mediana fa cinc anys que es va crear. I el 88 % va contestar el 10 d'agost, quan algú de fora es va molestar a provar-ho. Això, exactament, és el que pot fer qualsevol.
Fonts: metodologia (431.875 troballes, 64.024 claus úniques, 10.616 parells reverificats el 10 d'agost només amb crides de lectura, 10.260 propietaris notificats), el 88 % que autentica, el desglossament 817 / 526 / 242 / 768, les 130 claus arrel en comptes de gestió d'organització, l'antiguitat (mediana 1.831 dies, màxima 17,4 anys, 25 claus dels darrers 30 dies), la rotació del 13,7 % (398 de 2.903), els 929 usuaris amb AWSCompromisedKeyQuarantine, les 8.482 claus en 3.394 conjunts de dades de Hugging Face amb un 17,9 % d'arrel i les xifres de pressupost (262 comptes, mediana 8 $, 420.631 $ de despesa agregada al juliol) — Truffle Security, 19 d'agost de 2026. Cobertura i resposta d'AWS — BleepingComputer, 21 d'agost de 2026. Abast real de la política de quarantena i recomanació sobre les claus del compte arrel — documentació d'AWS (AWSCompromisedKeyQuarantineV3 i bones pràctiques del compte arrel). Dates d'IAM — anuncis d'AWS de la beta en vista prèvia (2 de setembre de 2010) i de la disponibilitat general (3 de maig de 2011). Càlculs propis: el 94 % (768 sobre 817) i situar els 17,4 anys de la clau més antiga al març del 2009, anterior a l'existència d'IAM.
Quantes credencials de llarga durada tens vives ara mateix?
Si no ho saps contestar de memòria, és el lloc per on començar. A everyWAN fem aquest inventari en una consultoria agnòstica —no venem llicències de ningú— i revisem quines credencials viatgen als fluxos d'automatització amb IA abans que res surti de casa. Si ja ho tens bé, també t'ho diem.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN