Truffle Security ha passato al setaccio oltre 430.000 fonti pubbliche — repository Git, dataset di training, immagini Docker, log di CI — e ne ha estratto 64.024 coppie di chiavi AWS uniche, distribuite su oltre 50.000 account. Il dato che dovrebbe far drizzare le antenne a qualsiasi sistemista non è tanto il numero in sé, quanto quello che è successo quando i ricercatori hanno riverificato un campione di 10.616 chiavi ad agosto 2026: l’88% era ancora valido. Non credenziali di test dimenticate in un branch morto: chiavi vive, utilizzabili, spesso con privilegi amministrativi completi su account aziendali.

È un caso di studio quasi perfetto su come l’igiene delle credenziali cloud si degradi silenziosamente nel tempo, e su cosa si può fare concretamente — oggi, con gli strumenti che AWS mette già a disposizione — per non finire nella prossima ricerca di questo tipo.

I numeri che contano davvero

La metodologia merita una menzione: i ricercatori non hanno letto policy IAM né toccato dati applicativi, ma hanno usato esclusivamente chiamate di sola lettura come sts:GetCallerIdentity, iam:ListAccessKeys e budgets:DescribeBudgets per confermare che una chiave fosse autentica e capire a cosa desse accesso. Un approccio pulito, che rende i numeri difficili da liquidare come esagerazioni.

Il quadro che emerge sul campione riverificato:

• 768 chiavi aziendali con controllo amministrativo totale sull’account che le ospitava.
• 526 di queste erano chiavi di root, cioè l’identità con poteri illimitati che AWS stessa raccomanda di non usare mai in produzione.
• 130 chiavi root appartenevano addirittura all’account di gestione dell’intera organizzazione AWS, con potenziale impatto su tutti gli account figli collegati via AWS Organizations.
• 242 utenti IAM avevano la policy AdministratorAccess allegata direttamente o tramite un gruppo.
• Su un sottoinsieme di 1.157 utenti IAM di cui è stato possibile enumerare le policy, il 976, cioè l’84%, risultava amministratore.

Ma il dato più interessante per chi fa capacity planning della propria postura di sicurezza è un altro: l’età mediana delle chiavi ancora attive era di circa 5 anni, con punte fino a 17,4 anni. E solo il 13,7% aveva accanto una chiave più recente, segno che il resto — l’86% — non era mai stato ruotato dal giorno della creazione. Le chiavi AWS non scadono da sole: se nessuno le ruota o le revoca attivamente, restano valide per sempre, anche dopo che la persona che le ha create ha lasciato l’azienda o dimenticato il progetto in cui erano incluse.

Da dove escono le chiavi

La fonte principale identificata non è GitHub, come ci si aspetterebbe, ma Hugging Face: 8.482 chiavi uniche trovate in 3.394 dataset pubblici, con la percentuale più alta di chiavi root fra tutte le sorgenti analizzate (17,9%). Il meccanismo è subdolo: uno sviluppatore include per errore un file di configurazione o un notebook con credenziali hardcoded in un dataset poi scaricato, clonato e reimpacchettato migliaia di volte per l’addestramento di modelli. A quel punto cancellare il file originale non serve a nulla, perché la credenziale è ormai disseminata in decine di copie derivate. Le altre fonti classiche — cronologia Git, immagini Docker, registri dei package manager, log di CI esposti — restano comunque significative.

Perché l’impatto economico è il segnale più sottovalutato

Un altro dato da isolare: sui soli account con spesa mensile leggibile, il totale ammontava a oltre 420.000 dollari al mese, con nove account sopra i 10.000 dollari/mese. La parte più scomoda: solo il 9,5% degli account leggibili aveva un budget alert configurato, anche minimo. La maggior parte delle organizzazioni coinvolte non avrebbe quindi ricevuto alcun segnale automatico in caso di abuso delle credenziali per cryptomining o exfiltration, se non la fattura di fine mese — e un budget alert a 10 dollari costa letteralmente nulla da configurare. È probabilmente il controllo con il miglior rapporto sforzo/beneficio dell’intero articolo, eppure resta il più trascurato.

Il piano d’azione per chi gestisce account AWS in produzione

1. Eliminare le chiavi di root, senza eccezioni

Come ricordano gli stessi ricercatori, nel 2026 non esiste più alcuna ragione legittima per avere una chiave di accesso root attiva. Ogni operazione che un tempo richiedeva le credenziali root può oggi essere delegata a un utente o ruolo IAM con permessi granulari. Il primo passo è un inventario:

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

Se il valore restituito è diverso da zero, esiste ancora una chiave di accesso root da eliminare dalla console IAM (sezione «Credenziali di sicurezza» dell’account root). Questo controllo va ripetuto su ogni account collegato via AWS Organizations, inclusi quelli storici creati anni fa e magari dimenticati.

2. Fare l’inventario e la rotazione delle chiavi IAM

Per ogni utente IAM, un comando come questo restituisce l’età di ciascuna chiave attiva:

aws iam list-access-keys --user-name nome-utente \
  --query 'AccessKeyMetadata[].{Id:AccessKeyId,Status:Status,Created:CreateDate}'

Per farlo su scala, conviene generare il credential report integrato di IAM, che include per ogni utente la data dell’ultima rotazione e dell’ultimo utilizzo:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > credential-report.csv

Da qui è possibile costruire una policy interna semplice ma efficace: nessuna chiave IAM viva più di 90 giorni senza rotazione, e nessuna chiave inutilizzata da oltre 45 giorni resta attiva. Questi controlli si possono automatizzare con AWS Config, usando le regole gestite access-keys-rotated e iam-user-unused-credentials-check, che segnalano automaticamente le credenziali fuori policy.

3. Sostituire le chiavi statiche con credenziali temporanee dove possibile

La causa profonda del problema non è solo la disattenzione nel pubblicare codice: è l’uso stesso di chiavi statiche a lunga durata dove non servirebbero. Per workload su EC2, ECS o Lambda, i ruoli IAM associati all’istanza o alla funzione eliminano la necessità di distribuire chiavi: le credenziali vengono generate automaticamente, durano poche ore e non finiscono mai su disco. Per l’accesso umano da riga di comando, IAM Identity Center (ex AWS SSO) con aws sso login ottiene lo stesso risultato: credenziali temporanee via autenticazione federata, mai una coppia access key/secret key permanente da custodire.

4. Restringere il raggio d’azione con permission boundary e Access Analyzer

Dove le chiavi IAM restano necessarie, i permission boundary impongono un tetto massimo ai privilegi che una policy può concedere a un utente, indipendentemente da eventuali policy troppo permissive aggiunte in futuro per errore. AWS IAM Access Analyzer va usato in modo proattivo per capire chi, all’esterno dell’account, può potenzialmente raggiungere le risorse tramite trust policy troppo larghe:

aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:eu-west-1:123456789012:analyzer/nome-analyzer \
  --filter '{"status":{"eq":["ACTIVE"]}}'

5. Impedire che le chiavi finiscano nel commit, non solo dopo

Trattare ogni commit come una potenziale fuga di dati è l’unico approccio realistico: il 43% delle chiavi individuate nella ricerca era presente in più posizioni contemporaneamente, segno che, una volta trapelata, una credenziale si propaga rapidamente in fork, mirror e archivi di terze parti. Strumenti come gitleaks o TruffleHog vanno integrati come pre-commit hook, così da bloccare il problema prima che raggiunga il repository remoto:

# installazione di un pre-commit hook con gitleaks
gitleaks protect --staged -v

GitHub, GitLab e Gitea offrono inoltre scanning nativo dei secret sui push, con notifica automatica ad AWS quando viene rilevata una chiave valida: è da qui che nasce la policy AWSCompromisedKeyQuarantine, applicata automaticamente da AWS quando una chiave viene rilevata esposta pubblicamente. Nella ricerca, il 12% delle chiavi la portava già — un segnale che, se ignorato, lascia comunque la chiave tecnicamente valida per operazioni di sola lettura in molti casi, e va trattato come un incidente da chiudere subito, non come un avviso a bassa priorità.

Conclusione

Il dato più utile di questa ricerca non è il numero assoluto di chiavi esposte, ma la fotografia di cosa succede quando la rotazione delle credenziali non è un processo automatizzato ma una buona intenzione: dopo cinque anni, in media, nessuno se ne ricorda più. Per chi amministra infrastrutture AWS, il valore pratico sta tutto nella lista di controlli sopra — nessuno dei quali richiede strumenti terzi costosi o una rewrite dell’architettura. Un inventario delle chiavi, un budget alert, un permission boundary e un pre-commit hook sono interventi che si implementano in un pomeriggio e che, secondo questi numeri, la maggior parte delle organizzazioni non ha ancora messo in pratica.

Fonte: Truffle Security — «768 Leaked Corporate AWS Keys Held Full Admin Rights», ripreso da Petri.com.