Zona grigia Cloud : chi si assume il rischio delle identità gestite
Si possono dedicare innumerevoli ore all'applicazione dell'autenticazione a più fattori (MFA) e alla limitazione delle autorizzazioni. Ma che dire delle identità che non gestite? Quelle che cloud vostro cloud crea e gestisce per voi?
Queste "identità non umane gestite da CSP" sono robot automatizzati che eseguono servizi in background. Sebbene siano essenziali, il modo in cui AWS, Google Cloud e Microsoft li hanno progettati crea rischi per la sicurezza unici e non evidenti. Se pensate che una configurazione sicura in AWS sia sicura anche in Azure, potreste rimanere sorpresi.
Prendiamoci un momento per analizzare i rischi specifici di ciascun cloud.
AWS: Il problema del "vice confuso" (dipende da te)
In AWS, i servizi sono globali e condivisi da tutti. Ciò crea un classico rischio multi-tenant di "confused deputy". Un aggressore nel proprio account può potenzialmente ingannare un servizio AWS affinché utilizzi le sue autorizzazioni per accedere alle risorse del tuo account.
- Il problema: l'unica cosa che impedisce ciò è un'impostazione speciale nelle politiche delle risorse IAM chiamata chiave di condizione (ad esempio, aws:SourceArn).
- La realtà: può essere molto difficile utilizzare correttamente le chiavi di condizione. Ciò crea una lacuna enorme, spesso trascurata, che pone l'onere della prevenzione direttamente sulle vostre spalle.
Google Cloud: il problema della "scatola nera" (è una loro responsabilità)
Google adotta l'approccio opposto. Le sue identità non umane gestite dal CSP (Service Agents) sono single-tenant e bloccate in progetti controllati da Google. Non è possibile accedervi, il che impedisce l'abuso delle credenziali riscontrato in altri cloud.
- Il problema: questo crea un problema diverso: l'abuso dell'accesso transitivo. Un servizio potrebbe essere così potente da diventare un bersaglio appetibile. Un aggressore può ingannarlo facendogli agire per proprio conto, aggirando il controllo delle proprie autorizzazioni.
- La realtà: questo è esattamente ciò che è successo con il servizio Document AI. Anche se Google ha risolto il problema, in questo caso non hai alcun controllo diretto. Devi fidarti che il fornitore abbia progettato tutti i suoi servizi in modo sicuro.
Microsoft Entra ID: "Dirottamento dell'entità di servizio" (un rischio attuale)
Microsoft utilizza un modello ibrido in cui un'entità locale per l'applicazione proprietaria di Microsoft risiede nel tenant dell'utente. Storicamente, questo modello presentava un difetto critico: un amministratore (come l'amministratore dell'applicazione) poteva aggiungere le proprie credenziali all'entità di servizio e aumentare i propri permessi.
- Il problema: Microsoft ha una soluzione chiamata appInstancePropertyLock. Quando è abilitata, impedisce questo tipo di dirottamento.
- La realtà: la correzione non è retroattiva. Microsoft deve aggiornare manualmente le oltre 300 applicazioni predefinite installate nei tenant dei clienti. Sebbene molte siano state reinstallate con questa proprietà abilitata, come hanno recentemente dimostrato alcuni ricercatori, applicazioni critiche come Office 365 Exchange Online rimangono non protette , rendendo questo il rischio più immediato e di maggiore impatto tra i tre.
Il punto chiave?
La sicurezza nel cloud non è uguale per tutti. La minaccia di cui bisogna preoccuparsi in AWS non è un problema in Google, mentre il rischio maggiore in Entra ID ha una causa completamente diversa.
- In AWS? Controlla le tue politiche IAM per verificare la presenza di chiavi di condizione mancanti. È tuo compito prevenire i problemi di Deputy.
- In Google Cloud? La sicurezza degli agenti di servizio è affidata esclusivamente a Google. Rimani aggiornato sulle vulnerabilità, abilita solo i servizi strettamente necessari e monitora eventuali attività insolite.
- In Microsoft Entra ID? Controlla le credenziali aggiunte alle entità di servizio locali. Rimani aggiornato sui casi di dirottamento delle entità di servizio segnalati in circolazione.
Le minacce non sono uniformi. La minaccia più critica in un cloud non essere rilevante in un altro. I difensori e i ricercatori devono adattare le loro strategie, riconoscendo che non esiste un approccio "1 a 1" ai controlli di sicurezza in uncloud .
Per approfondire la ricerca alla base di ciascuno di questi modelli di minaccia e delle diverse architetture, consultare il white paper allegato "Un modello comparativo di minaccia delle identità delle macchine gestite dai CSP".