Oltre 9.300 chiavi di accesso AWS pubblicate per errore su internet fra agosto 2022 e agosto 2026 sono ancora attive e funzionanti. Non si tratta di credenziali dimenticate su repository di hobbisti: 817 sono riconducibili ad aziende identificabili e 768 di queste danno il controllo completo dell'account cloud. È il risultato di quattro anni di monitoraggio pubblicati da Truffle Security e ripresi il 21 agosto da BleepingComputer.

I numeri della ricerca

I ricercatori hanno raccolto 431.875 segreti AWS distribuiti su repository di codice, cronologia Git, dataset, immagini Docker, registri di container e log di CI/CD. Dopo la deduplicazione restano 64.024 chiavi uniche, riferite a 50.654 account AWS distinti.

Solo per un sottoinsieme — 10.616 chiavi di cui era disponibile la coppia completa di credenziali — è stato possibile verificare se fossero ancora valide. Al 10 agosto 2026 l'88% autenticava ancora.

Il dettaglio sui privilegi è la parte che deve preoccupare:

  • 526 chiavi root, l'identità più privilegiata di un account AWS, quella che nessuna policy IAM può limitare;
  • 242 utenti IAM con policy AdministratorAccess, con facoltà di creare, modificare, eliminare e leggere praticamente ogni risorsa dell'account;
  • età mediana delle chiavi: 1.831 giorni, circa cinque anni. La più vecchia era in circolazione da 17,4 anni;
  • solo il 13,7% aveva una chiave più recente associata allo stesso utente, segno che nella quasi totalità dei casi non è mai stata fatta una rotazione;
  • appena 262 account su 2.754 leggibili avevano configurato un alert di budget.

La singola fonte più prolifica di chiavi esposte è Hugging Face, la piattaforma di condivisione di modelli e dataset AI, con 8.482 esposizioni uniche; il 17,9% di quelle chiavi era di tipo root.

Interpellata da BleepingComputer, AWS ha ricordato di notificare i clienti ogni volta che rileva chiavi esposte e di applicare policy di quarantena per contenere il rischio, richiamando il modello di responsabilità condivisa.

Il dato che conta non è 9.300

Il numero assoluto colpisce, ma il vero segnale sono altri due: l'88% e i cinque anni. Un segreto esposto non è un incidente istantaneo che si esaurisce: è una porta lasciata aperta che nessuno chiude, perché nessuno sa che esiste. Tre dinamiche ricorrenti la spiegano.

Chiavi statiche al posto dei ruoli. Creare un utente IAM con una access key permanente è la strada più rapida per far funzionare una pipeline o uno script. Usare invece ruoli IAM, federazione OIDC o instance profile richiede di capire come funziona STS e di spendere mezza giornata in più. Quella mezza giornata è esattamente il debito che queste 9.300 chiavi rappresentano.

Nessun inventario dei segreti. La chiave viene rimossa dal file sorgente, il commit di rimozione viene pubblicato e tutti si sentono a posto. Ma la chiave resta nella cronologia Git, leggibile da chiunque cloni il repository. Lo stesso vale per i layer intermedi di un'immagine Docker e per i log di build.

Nessun controllo sui costi. Il cryptomining su istanze GPU è l'uso più immediato di una chiave rubata, e senza un budget alert la scoperta avviene alla fattura di fine mese. Con 262 account su 2.754 monitorati, il rapporto è impietoso.

Sulla chiave root vale la pena essere netti: AWS ne sconsiglia l'uso da anni proprio perché non è vincolabile da alcuna policy. 526 chiavi root esposte significa 526 account privi di qualunque rete di sicurezza.

Cosa significa per le aziende italiane

Il modello organizzativo prevalente nel tessuto produttivo italiano amplifica esattamente questo rischio. Molte PMI e software house hanno l'intero carico cloud in un unico account AWS, con un utente amministrativo condiviso fra due o tre persone e una access key incollata nei file di configurazione. Non c'è separazione fra ambiente di sviluppo e produzione, quindi una chiave che serviva per un test tocca anche i dati reali.

A questo si somma la pratica diffusa dell'esternalizzazione dello sviluppo: le credenziali vengono consegnate a un fornitore o a un freelance e finiscono su repository che l'azienda non controlla e non può nemmeno scansionare. Quando il rapporto si chiude, la chiave resta.

Il dato su Hugging Face segnala poi un vettore nuovo che riguarda già le aziende, non solo i ricercatori. Chi sperimenta con modelli AI carica notebook e dataset per condividerli con colleghi o clienti, e le credenziali che servivano a leggere un bucket S3 restano dentro il file. Nel 2026 questa è una superficie di attacco aziendale a tutti gli effetti.

L'impatto economico, infine, non si limita all'esfiltrazione. Un attaccante con controllo completo può cancellare i dati, creare utenti amministrativi per la persistenza e generare costi di calcolo a cinque cifre in pochi giorni — costi che non vengono stornati automaticamente.

Il profilo normativo

Una chiave che apre bucket S3 contenenti dati personali è prima di tutto un problema di sicurezza del trattamento ai sensi dell'articolo 32 del GDPR: misure tecniche adeguate significa, in concreto, gestione del ciclo di vita delle credenziali e cifratura, non solo firewall.

Il punto delicato riguarda la dimostrabilità. Se non riuscite a escludere che il bucket sia stato letto — perché CloudTrail non era attivo, o la retention è troppo breve — vi trovate nella posizione peggiore: dovete valutare una notifica senza poter circoscrivere l'evento. Il principio di accountability dell'articolo 5(2) impone al titolare di dimostrare la conformità, non all'autorità di dimostrare la violazione.

Se la chiave è stata esposta dal fornitore di sviluppo, entra in gioco l'articolo 28: l'obbligo del responsabile del trattamento di informare tempestivamente il titolare deve essere scritto nel contratto, con tempi espliciti. Per i soggetti in perimetro NIS2 (D.Lgs. 138/2024), gestione delle credenziali e sicurezza della supply chain ICT rientrano fra le misure minime richieste dall'articolo 21 della direttiva.

Cosa fare subito

  • Fate l'inventario delle chiavi e della loro età: generate il credential report con aws iam generate-credential-report e leggete le colonne access_key_1_last_rotated e access_key_1_last_used_date. Le chiavi non usate da mesi sono le prime da eliminare.
  • Eliminate tutte le access key root, senza eccezioni. L'utente root si usa solo con MFA e solo per le pochissime operazioni che lo richiedono.
  • Sostituite gli utenti IAM con ruoli: federazione OIDC per GitHub Actions e GitLab CI, instance profile per EC2, IRSA per i workload su EKS. È il modo strutturale per far sparire il problema, non per mitigarlo.
  • Scansionate la cronologia Git, non il solo branch corrente, con strumenti come trufflehog o gitleaks. Includete immagini Docker, artefatti e log di build.
  • Trattate come compromesso ogni segreto finito su un repository pubblico, anche per un solo minuto. Si ruota, non si "controlla se qualcuno l'ha usato".
  • Attivate CloudTrail su tutte le region con una retention coerente con i tempi di risposta a incidente. Senza log non esiste indagine, e senza indagine ogni sospetto diventa una notifica.
  • Configurate AWS Budgets con alert via email: è il rilevatore di cryptomining più economico che esista.
  • Bloccate a monte: hook di pre-commit e scanner di segreti come step obbligatorio della pipeline CI, con build che fallisce in caso di rilevamento.