Valutazione di ambienti AWS, Azure, Google Cloud e Kubernetes: identità, esposizione in rete, archivi di dati e percorsi da un punto d’appoggio al controllo completo.
Nel cloud il perimetro è un documento di policy. Un ruolo che può passare un altro ruolo, un bucket di storage leggibile da qualsiasi utente autenticato, un servizio di metadati raggiungibile da un’applicazione web: presi da soli sembrano innocui, e insieme sono un percorso da internet ai dati.
Esaminiamo la configurazione con accesso in sola lettura e poi testiamo che cosa significa in pratica: partendo dalla posizione di un estraneo, di un workload compromesso e di un account di sviluppatore, seguiamo i permessi per vedere fin dove arriva ciascuno.
01Perimetro
Che cosa testiamo
Gestione delle identità e degli accessi: utenti, ruoli, policy, federazione, account di servizio
Percorsi di escalation dei privilegi e relazioni di fiducia tra account
Rete: gruppi di sicurezza, endpoint pubblici, peering, collegamenti privati
Storage e database: accesso pubblico, cifratura, backup, snapshot
Risorse di calcolo: metadati delle istanze, funzioni serverless, immagini di container
Kubernetes: RBAC, sicurezza dei pod, network policy, admission control, segreti
Segreti e chiavi: gestori, rotazione, segreti nel codice e nelle variabili di ambiente
Logging e rilevamento: che cosa può fare un attaccante senza essere registrato
Pipeline di distribuzione: permessi dei runner e dei ruoli di deploy
02Approccio
Come si svolge il lavoro
01
Revisione della configurazione
Con accesso in sola lettura raccogliamo la configurazione e la confrontiamo con i CIS Benchmarks e con le raccomandazioni del fornitore.
02
Analisi dei percorsi di attacco
I permessi vengono modellati come un grafo. Cerchiamo i percorsi che portano da un’identità con pochi privilegi al controllo amministrativo o ai dati.
03
Validazione
I percorsi che contano vengono seguiti davvero, entro i limiti delle regole di ingaggio, per separare ciò che è teorico da ciò che è sfruttabile.
04
Test dei workload
Dall’interno di un container o di una funzione testiamo che cosa può raggiungere un workload compromesso: metadati, servizi vicini, il control plane.
I grandi fornitori pubblicano politiche che consentono di testare le proprie risorse senza approvazione preventiva, con un elenco di azioni vietate come il denial of service (DoS). Prima dei test verifichiamo la politica vigente del tuo fornitore e restiamo entro i suoi limiti.
L’accesso in sola lettura è sufficiente?
Per la revisione della configurazione, sì. Per validare i percorsi di attacco ci servono le identità con pochi privilegi da cui i percorsi partono; vengono create per il test e rimosse al termine.
Usiamo uno strumento per la postura di sicurezza del cloud. Che cosa resta da trovare?
Gli strumenti di postura elencano gli errori di configurazione uno per uno. Raramente mostrano quali tre di essi si combinano in un percorso verso i dati, o quale di duecento avvertimenti conta davvero. Questo è lo scopo della valutazione.