Zona grigia della sicurezza Cloud : a chi appartiene il rischio delle identità gestite
Si possono spendere innumerevoli ore per applicare l'MFA e bloccare le autorizzazioni. Ma che dire delle identità che non gestite? Quelle che il vostro cloud provider crea e gestisce per voi?
Queste "identità non umane gestite dal CSP" sono i robot automatizzati che eseguono i servizi in background. Sebbene siano essenziali, il modo in cui AWS, Google Cloud e Microsoft li hanno progettati crea rischi di sicurezza unici e non ovvi. Se pensate che una configurazione sicura in AWS sia sicura anche in Azure, potreste rimanere sorpresi.
Analizziamo per un attimo i rischi specifici di ciascun cloud.
AWS: Il problema dell'"agente confuso" (è colpa vostra)
In AWS, i servizi sono globali e condivisi da tutti. Questo crea un classico rischio di "vice confuso" multi-tenant. Un aggressore con il proprio account può potenzialmente ingannare un servizio AWS e utilizzare le sue autorizzazioni per accedere alle risorse del vostro account.
- Il problema: L'unica cosa che impedisce questa operazione è un'impostazione speciale nei criteri delle risorse IAM chiamata chiave di condizione (ad esempio, aws:SourceArn).
- La realtà: Può essere molto difficile usare correttamente le chiavi di condizione. Questo lascia un buco enorme, spesso trascurato, che fa ricadere l'onere della prevenzione sulle vostre spalle.
Google Cloud: Il problema della "scatola nera" (è colpa loro)
Google adotta l'approccio opposto. Le identità non umane gestite dal CSP (agenti di servizio) sono single-tenant e bloccate in progetti controllati da Google. Non si possono toccare, il che impedisce l'abuso di credenziali che si riscontra in altri cloud.
- Il problema: Questo crea un altro problema: l'abuso dell'accesso transitivo. Un servizio potrebbe essere così intrinsecamente potente da costituire un bersaglio ghiotto. Un aggressore può indurlo ad agire per suo conto, aggirando il controllo dei propri permessi.
- La realtà: Questa stessa cosa è accaduta con il servizio Document AI. Anche se Google ha risolto il problema, in questo caso non avete alcun controllo diretto. Dovete fidarvi del fatto che il provider abbia progettato tutti i suoi servizi in modo sicuro.
Microsoft Entra ID: "Service Principal Hijacking" (un rischio del giorno d'oggi)
Microsoft utilizza un modello ibrido in cui un Principal locale per l'applicazione di prima parte di proprietà di Microsoft risiede nel tenant. Storicamente, questo design aveva un difetto critico: un amministratore (come l'Application Admin) poteva aggiungere le proprie credenziali al Service Principal e scalare le proprie autorizzazioni.
- Il problema: Microsoft ha una soluzione chiamata appInstancePropertyLock. Se abilitato, 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 i ricercatori, le applicazioni critiche come Office 365 Exchange Online rimangono non protette, rendendo questo il rischio più immediato e ad alto impatto dei tre.
Il risultato?
La sicurezza non è unica nel cloud. La minaccia che deve ossessionare AWS non è un problema per Google, mentre il rischio maggiore di Entra ID ha una causa completamente diversa.
- In AWS? Controllate i vostri criteri IAM per verificare la presenza di chiavi di condizione mancanti. I problemi dei Deputy confusi possono essere evitati.
- In Google Cloud? La sicurezza degli agenti di servizio è esclusivamente nelle mani di Google. Rimanete aggiornati sulle vulnerabilità, attivate solo i servizi minimamente necessari e monitorate le attività insolite.
- In Microsoft Entra ID? Monitorare l'aggiunta di credenziali ai Service Principal locali. Rimanete aggiornati sulle segnalazioni di Service Principal Hijacking in circolazione.
Le minacce non sono uniformi. La minaccia più critica in un cloud può essere un non problema 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 un ambiente cloud .
Per approfondire la ricerca alla base di ciascuno di questi modelli di minaccia e delle diverse architetture, consultare il whitepaper "A Comparative Threat Model of CSP-Managed Machine Identities".