Hai Ereditato un Pasticcio Cloud. Da Dove Cominci?

Hai appena preso il controllo di un account cloud (o dieci) che qualcuno ha costruito nel corso di tre anni senza documentazione, con una squadra rotante di contractor, e un canale Slack chiamato #aws-help che non è attivo dal 2022. Questa è una delle situazioni più comuni nel lavoro di cloud security, ed è scomoda perché sei responsabile di qualcosa che non riesci ancora a spiegare.

Ecco come passare da visibilità zero a una posizione difendibile senza affrontare tutto in una volta.

Smetti di indovinare e fai prima un inventario

Non puoi proteggere quello che non vedi. Prima di toccare anche una sola policy IAM, esegui un inventario:

• AWS: aws organizations list-accounts per vedere la struttura completa degli account, poi Steampipe o AWS Config aggregators per estrarre le risorse da tutti gli account in una vista unica interrogabile.
• Azure: Resource Graph queries (az graph query) tra sottoscrizioni, poiché il modello tenant/subscription di Azure nasconde facilmente la proliferazione.
• GCP: gcloud asset search-all-resources a livello di organizzazione.

Incrocia questi dati con i dati di fatturazione. La fatturazione non mente su ciò che è in esecuzione, anche quando i tag e la documentazione lo fanno. Se vedi spesa su un servizio che nessuno ha menzionato durante l'onboarding, questo è il tuo primo risultato.

Scopri chi può fare cosa prima di scoprire cosa è rotto

Le configurazioni errate fanno notizia, ma l'identità è il punto dove di solito vive la vera esposizione in un ambiente ereditato. Estrai ogni utente IAM, ruolo e service account e fatti tre domande: deve ancora esistere, ha accesso che non usa, ed è umano o automatico.

Esegui AWS IAM Access Analyzer o tooling di stile iam-lint per segnalare le autorizzazioni non utilizzate negli ultimi 90 giorni. In pratica, gli account ereditati hanno quasi sempre almeno un utente IAM con chiavi di accesso di lunga durata che avrebbero dovuto