Snowflake sta abbandonando l'autenticazione tramite password per gli account di servizio, costringendo le aziende a rivedere la governance delle identità e la gestione degli accessi mentre migrano verso metodi più sicuri.
La recente ondata di attacchi informatici che ha coinvolto Snowflake non è stata causata da una vulnerabilità tecnica, ma dall'uso di credenziali valide, spesso obsolete, che hanno permesso a criminali come Connor Moucka di accedere a oltre 165 organizzazioni clienti. Il furto di miliardi di dati, tra cui i registri di chiamate e messaggi di quasi tutti i clienti wireless di AT&T, ha messo in luce una falla ben nota: credenziali rimaste attive per anni, assenza di autenticazione a due fattori e mancanza di restrizioni di rete.
Per rispondere a questa minaccia, Snowflake sta obbligando i clienti a gestire il cosiddetto "debito di identità", concentrandosi sulle identità non umane. Con la Fase 3 del suo piano di autenticazione, l'azienda sta migrando gli account legacy al tipo SERVICE, che non consente più l'uso di password. Sostituire le password è solo il primo passo: la vera sfida è ricostruire la mappatura degli account, assegnare un responsabile e valutare i reali permessi necessari.
Account legacy: il rischio delle credenziali dimenticate
Presto tutti gli account di servizio non potranno più autenticarsi tramite password. Il tipo utente LEGACY_SERVICE sarà completamente deprecato e gli account esistenti migreranno a SERVICE, che non può memorizzare password. La deprecazione avviene in tre fasi:
- Settembre 2025-gennaio 2026: obbligo di secondo fattore per utenti umani su Snowsight, nessun cambiamento per i servizi.
- Maggio 2026-luglio 2026: i nuovi utenti non umani devono essere di tipo SERVICE, senza password.
- Agosto 2026-ottobre 2026: gli account legacy devono migrare prima della data di enforcement specifica per ogni account.
Gli account più vecchi sono i più a rischio: credenziali mai ruotate, proprietari cambiati e dipendenze non documentate.
Governance delle identità: come prepararsi alla scadenza
La sicurezza degli agenti parte dall'identità. Soluzioni come Token Security permettono di scoprire tutti gli agenti, mappare gli accessi rischiosi e applicare policy basate sull'intento, aiutando a scalare l'AI senza perdere il controllo.
Per affrontare la migrazione, è fondamentale costruire subito un inventario degli account di servizio, senza aspettare la scadenza di ottobre. Tre domande chiave: quali account si autenticano su Snowflake, chi ne è il proprietario e cosa smetterà di funzionare quando la password verrà disabilitata. Snowflake fornisce strumenti per identificare gli account attivi e la cronologia degli accessi, ma la responsabilità di ricostruire la proprietà e le dipendenze resta alle aziende.
Assegnare un proprietario nominativo a ogni account è essenziale: la responsabilità non può essere solo una riga su un foglio di calcolo. Se nessuno risponde agli alert, l'account non dovrebbe più esistere. In caso di dubbi, si consiglia una finestra di disabilitazione controllata prima della cancellazione definitiva.
Scelta del metodo di autenticazione: nessuna soluzione unica
Snowflake offre quattro alternative senza password per gli utenti SERVICE, ognuna con costi e complessità diversi:
- Workload identity federation: opzione raccomandata, senza segreti da gestire, ma richiede che il workload possa presentare un'identità federabile.
- External OAuth: sicuro, ma necessita di competenze per configurare un IdP esterno.
- Key-pair authentication: senza password, ma con segreti a lunga durata e senza scadenza forzata.
- Programmatic access tokens: sostituto diretto della password, con policy di rete e restrizioni di ruolo obbligatorie, ma la rotazione non verifica automaticamente i prerequisiti.
Non esiste una soluzione unica: la federazione è ideale dove possibile, mentre key-pair o token sono il fallback, ma vanno sempre accompagnati da policy di rete e rotazione programmata.
Gestire le vecchie password e il rischio di riutilizzo
Le password sostituite vanno considerate compromesse: secondo Snowflake e Mandiant, quasi l'80% degli account coinvolti nell'attacco UNC5537 aveva già subito esposizione delle credenziali. La sola disabilitazione su Snowflake non elimina le copie in altri sistemi o variabili CI: è necessario cercare riutilizzi, revocare credenziali dipendenti e ridurre il perimetro dei ruoli.
AI agent e il futuro della governance delle identità
La scadenza di Snowflake anticipa un problema che crescerà con la diffusione degli agenti AI. L'azienda ha già introdotto il tipo SERVICE_AGENT per distinguere queste identità automatizzate, ma le domande restano le stesse: chi è il proprietario, quale identità usa, cosa può accedere e quando deve essere revocato l'accesso?
La gestione proattiva delle identità è ormai centrale anche per la sicurezza cloud, come dimostrato anche da altri casi di violazione come quello che ha coinvolto Sakura Internet (dove un attacco ha messo a rischio oltre un milione di account), sottolineando l'urgenza di strategie di governance robuste prima che le scadenze imposte dalle piattaforme rendano obbligatorie le migrazioni.
Articolo sponsorizzato e redatto da Token Security.
