Proteggere un'infrastruttura cloud che non hai costruito

Ti hanno appena consegnato le chiavi di un account cloud che è cresciuto senza controllo per tre anni. Nessuno ha lasciato documentazione. IAM ha 40 ruoli con permessi wildcard, ci sono bucket S3 che nessuno ricorda di aver creato, e l'ultima persona che capiva la topologia di rete ha lasciato l'azienda nel 2022. Questo è più comune di quanto la maggior parte degli annunci di lavoro ammetterà, e il primo mese stabilisce il tono per tutto il resto.

Fai un inventario prima di toccare qualsiasi cosa

Resisti all'impulso di iniziare subito a proteggere le cose. Per prima cosa ti serve una mappa. Esegui aws resourcegroupstaggingapi get-resources su ogni regione, non solo us-east-1 — i team adorano avviare risorse di test in ap-southeast-2 e poi dimenticarsene. Combinalo con AWS Config se è già abilitato, oppure attivalo adesso se non lo è. Su Azure, az resource list --output table reindirizzato in un foglio di calcolo funziona bene per una prima passata. Su GCP, Cloud Asset Inventory e gcloud asset search-all-resources ti dà la stessa visione.

Fai un riscontro rispetto alla fatturazione. Qualsiasi cosa che costa denaro dovrebbe comparire nel tuo inventario di risorse; qualsiasi cosa nell'inventario con zero attività recente è candidata per l'archiviazione. Le discrepanze qui sono solitamente dove si nascondono le cose inquietanti — istanze EC2 orfane con IP pubblici, snapshot RDS dimenticati che rimangono non crittografati, load balancer che puntano al nulla.

Controlla IAM come se fosse una scena del crimine

Estrai ogni policy IAM e cerca "Action": "*" combinato con "Resource": "*". Questa combinazione non dovrebbe esistere al di fuori di una manciata di ruoli admin di emergenza, e nemmeno quelli dovrebbero farlo senza enforcing MFA e alerting CloudTrail collegati. Usa IAM Access Analyzer per trovare ruoli che concedono accesso ad account esterni — questo cattura sia le relazioni di trust cross-account intenzionali che gli errori di qualcuno che sta testando un modulo Terraform con l'ID account sbagliato.

Controlla le access key più vecchie di 90 giorni con aws iam generate-credential-report. Le infrastrutture ereditate hanno quasi sempre key di lunga durata collegate agli account di servizio, a volte codificate in una variabile di ambiente Lambda o in un job Jenkins. Ruotale, ma organizzalo — uccidere una key da cui dipende un job batch notturno alle 2 del mattino è come farsi contattare durante la tua prima settimana.

Trova l'esposizione pubblica prima che lo faccia un attaccante

Esegui un controllo di raggiungibilità di rete sui tuoi VPC. I security group con 0.0.0.0/0 su qualsiasi cosa diversa da 80/443 hanno bisogno di una giustificazione, non di un presupposto. Strumenti come ScoutSuite o Prowler analizzeranno un account in pochi minuti e sfrutteranno un report ordinato per gravità — parti da lì invece di costruire la tua lista di controllo da zero.

I bucket S3 meritano attenzione particolare perché sono la mina classica delle infrastrutture ereditate. Controlla sia le policy dei bucket che le impostazioni di Block Public Access a livello di account; qualcuno potrebbe aver disabilitato il default dell'account anni fa per un sito statico una tantum e non l'ha mai riattivato. aws s3api list-buckets combinato con un ciclo che controlla get-bucket-acl e get-bucket-policy-status su ognuno ti dà un'immagine pulita in meno di dieci minuti per la maggior parte degli account.

Stabilisci il logging prima di stabilire la fiducia

Se CloudTrail, VPC Flow Logs, o GuardDuty non sono già in esecuzione ovunque, attivali adesso, prima di apportare altri cambiamenti. Vuoi un record di ciò che accade da questo momento in poi, e lo vuoi prima di iniziare a eliminare le cose, perché l'eliminazione è esattamente quando gli errori vengono fatti e attribuiti al nuovo arrivato. Spedisci i log su un account o una sottoscrizione separata se possibile, in modo che un carico di lavoro compromesso non possa anche cancellare le sue stesse prove.

Configura GuardDuty o Azure Defender for Cloud con gli alert indirizzati a un posto che un umano effettivamente controlla — non un canale Slack con 400 messaggi non letti. Il valore degli strumenti di rilevamento è quasi zero se gli alert finiscono nel vuoto.

Risolvi prima i problemi più evidenti, documenta tutto

Non riuscirai a riparare un'infrastruttura ereditata in uno sprint. Triage per raggio di esplosione: esposizione dati pubblici prima, poi identità con troppi privilegi, poi segmentazione di rete, poi tutto il resto. Scrivi quello che trovi e quello che hai cambiato, anche in un semplice Google Doc, perché la persona successiva che eredita questo da te merita meglio di quello che hai ricevuto tu.

Aspettati resistenza quando stringe un security group e il test di integrazione di uno sviluppatore inizia a fallire. È normale — significa che il controllo sta funzionando. Parla con il team che possiede il carico di lavoro prima di cambiare qualsiasi cosa in produzione, e tieni pronto un piano di rollback per le prime due settimane.

Per ulteriori informazioni sugli strumenti e il ragionamento dietro gli audit cloud, dai un'occhiata ai segmenti di Korra Studio sull'hardening IAM e sull'ingegneria di detection cloud — entrambi si abbinano bene al workflow qui sopra.