Oltre 9.300 chiavi AWS esposte erano ancora attive: 768 davano il controllo completo di account aziendali

La distinzione è importante: una credenziale presente in un repository pubblico non è necessariamente ancora pericolosa. Il rischio diventa concreto quando la chiave non è stata revocata, continua ad autenticarsi e conserva permessi significativi. Nell’indagine, queste tre condizioni si sono sovrapposte con frequenza.

768 chiavi aziendali offrivano il controllo amministrativo completo

Tra le chiavi attive collegate ad account aziendali, 817 sono state attribuite a imprese. Il gruppo comprendeva:

• 526 chiavi dell’account root di AWS;
• 242 chiavi di utenti IAM associate alla policy AWS AdministratorAccess;
• 768 chiavi in totale in grado di offrire il controllo amministrativo completo di un account AWS aziendale.

Le credenziali root rappresentano il livello di controllo più elevato disponibile per un cliente AWS. Un’identità IAM con AdministratorAccess, invece, può operare su tutti i servizi AWS con permessi molto estesi. Una chiave valida a uno di questi livelli può aprire la strada alla compromissione dell’account, all’accesso ai dati, alla creazione non autorizzata di risorse o all’abuso della fatturazione cloud.

Il problema, quindi, non riguarda soltanto l’igiene del codice sorgente, ma anche la gestione dei permessi e del ciclo di vita delle credenziali. Cancellare una chiave da un file pubblico non protegge l’account se qualcuno l’ha già copiata: la credenziale deve essere revocata o ruotata.

Hugging Face è stata la principale fonte individuale

Hugging Face ha rappresentato 8.482 esposizioni di credenziali AWS, risultando la singola fonte più rilevante individuata nell’analisi. Truffle Security ha riferito che il 17,9% di queste credenziali AWS era costituito da credenziali root.

Il dato si inserisce in una scansione più ampia dei contenuti pubblici di Hugging Face. Truffle Security ha dichiarato di aver esaminato 7,6 petabyte di dataset pubblici, trovando credenziali attive distribuite in migliaia di dataset. Il risultato mostra come i segreti possano sopravvivere al di fuori dei normali repository software e finire all’interno di dati distribuiti pubblicamente.

Per i team di sicurezza, la conseguenza è chiara: controllare solo i repository correnti non basta. Cronologie Git, artefatti di build, immagini container, registri, dataset pubblicati e output dei sistemi CI possono conservare credenziali anche dopo che gli sviluppatori pensano di averle rimosse.

Molte chiavi avevano anni e venivano ruotate raramente

L’età mediana delle credenziali risultava di circa 1.831 giorni, cioè quasi cinque anni. La chiave più vecchia aveva 17,4 anni. Solo il 13,7% delle voci aveva una chiave associata più recente, un’indicazione del fatto che la maggior parte non fosse stata sostituita attraverso un normale processo di rotazione.

Le chiavi di lunga durata aumentano il tempo a disposizione per un eventuale uso non autorizzato e rendono più difficile capire chi ne sia ancora responsabile. Possono inoltre sopravvivere a cambi di personale, migrazioni applicative, pulizie dei repository e passaggi di consegne operative.

L’età deve quindi essere considerata un segnale di rischio. Una chiave esposta da diversi anni non va trattata automaticamente come obsoleta: va verificata, revocata e analizzata, a meno che il proprietario non possa dimostrare che non è più valida.

Pochi account avevano attivato il monitoraggio del budget

Truffle Security è riuscita a leggere le informazioni relative a 2.754 account, ma soltanto 262 avevano attivi gli avvisi sul budget AWS.

Gli avvisi di budget non sostituiscono la revoca delle credenziali o il rilevamento delle minacce, ma possono fornire un primo segnale quando una chiave esposta viene usata per creare risorse costose, ad esempio per attività di cryptomining o altre forme di abuso del cloud. Senza un sistema di notifica che raggiunga qualcuno in grado di intervenire, una spesa anomala può continuare anche dopo la compromissione dell’account.

Cosa risolvono — e cosa non risolvono — le notifiche AWS

Il resoconto descrive protezioni AWS in grado di individuare chiavi di accesso divulgate, avvisare i clienti interessati e applicare restrizioni o misure di quarantena. Tuttavia, il fatto che così tante chiavi verificate fossero ancora valide suggerisce che il rilevamento non abbia portato con costanza a una revoca o a una rotazione tempestiva da parte dei clienti.

Il rilevamento è solo il primo passaggio della risposta a una fuga di credenziali. Occorre anche identificare il proprietario, stabilire a quali risorse la chiave possa accedere, verificare eventuali abusi e invalidarla. Truffle Security descrive la propria verifica come di sola lettura: i ricercatori hanno controllato l’autenticazione e i metadati relativi ad account e permessi, senza modificare le risorse dei clienti. Questa metodologia è riportata da Truffle Security, ma non è confermata in modo indipendente da tutte le fonti disponibili.

Cosa fare dopo la fuga di una chiave AWS

1. Revocare o ruotare subito la credenziale

Disabilitare o eliminare ogni credenziale pubblicata e crearne una sostitutiva solo se l’accesso è ancora necessario. Rimuovere il segreto da un repository, cancellare un file o riscrivere la cronologia Git non invalida le copie già realizzate.

2. Eliminare le chiavi di accesso root

Le chiavi dell’utente root AWS non dovrebbero essere usate per l’accesso programmatico ordinario. Vanno eliminate, spostando i carichi di lavoro verso identità controllate e dotate soltanto dei permessi necessari.

3. Verificare permessi e proprietario

Occorre stabilire a quale account, utente, servizio e risorse appartenesse la credenziale. La priorità va alle chiavi con privilegi root, policy AdministratorAccess, accesso esteso ai dati o autorizzazioni per creare infrastrutture.

4. Analizzare l’attività prima e dopo la revoca

È necessario controllare gli accessi, i log di CloudTrail, le modifiche IAM, le risorse create di recente e la fatturazione alla ricerca di comportamenti sospetti. Revocare una chiave impedisce ulteriori utilizzi, ma non chiarisce se sia già stata sfruttata.

5. Sostituire le chiavi permanenti con identità temporanee

Quando possibile, è preferibile usare ruoli IAM a breve durata e identità associate ai carichi di lavoro, invece di chiavi di accesso permanenti. I permessi minimi riducono i danni potenziali di una fuga.

6. Configurare avvisi sul budget e un percorso di risposta

Bisogna attivare gli avvisi di AWS Budgets e il monitoraggio delle anomalie di costo, indirizzando le notifiche a contatti in grado di intervenire rapidamente. Il monitoraggio finanziario è una rete di sicurezza, non un sostituto della scansione dei segreti, della rotazione delle credenziali e della revisione degli accessi.

La lezione più ampia per la sicurezza cloud

Il dato più importante dell’indagine non è soltanto il numero grezzo di segreti. È la combinazione di esposizione pubblica, validità persistente, privilegi elevati, età estrema e monitoraggio insufficiente. Gli archivi pubblici possono conservare credenziali molto tempo dopo che un’organizzazione ha dimenticato dove venivano usate, mentre una chiave copiata può restare utile fino alla revoca esplicita.

Per i team cloud, l’approccio più prudente è semplice: trattare ogni credenziale AWS esposta come compromessa, verificare a cosa può accedere, revocarla o ruotarla immediatamente e sostituire gli accessi di lunga durata con identità temporanee e basate sul principio del minimo privilegio.