Errori di configurazione cloud comuni

Le misconfigurazioni sono la principale causa delle violazioni dei dati nel cloud. A differenza delle vulnerabilità tradizionali on-premise, che richiedono lo sfruttamento di bug del software, le misconfigurazioni cloud sono spesso causate dagli stessi utenti e possono essere sfruttate facilmente da chiunque su Internet.

I bucket S3 con accesso pubblico in lettura espongono a Internet tutti i dati archiviati. Gli attaccanti cercano i bucket aperti utilizzando strumenti come GrayhatWarfare. Prevenzione: abiliti S3 Block Public Access a livello di account e S3 Object Ownership, quindi verifichi regolarmente le policy dei bucket.

I gruppi di sicurezza con 0.0.0.0/0 sulla porta 22 (SSH), 3389 (RDP) o su porte amministrative creano superfici di attacco enormi. Limiti le regole in ingresso a intervalli CIDR specifici. Utilizzi AWS Systems Manager Session Manager invece di esporre SSH.

La condivisione accidentale di snapshot RDS pubblici espone l'intero contenuto del database. Gli snapshot automatici sono privati per impostazione predefinita, ma le condivisioni manuali possono esporre dati sensibili. Verifichi la visibilità degli snapshot con describe-db-snapshots --include-public.

Gli sviluppatori eseguono il commit di chiavi di accesso AWS, password dei database e token API nei repository Git. Gli attaccanti analizzano GitHub e GitLab con strumenti come TruffleHog e GitLeaks. Prevenzione: utilizzi secret manager, hook pre-commit git-secrets e la scansione dei segreti a livello dell'organizzazione.

Senza CloudTrail abilitato in tutte le regioni, le chiamate API non vengono registrate. Gli attaccanti sfruttano le lacune nei log per operare senza essere rilevati. Abiliti CloudTrail a livello dell'organizzazione e invii i log a un bucket S3 in un account di sicurezza separato, con S3 Object Lock per proteggerli dalle manomissioni.

IMDSv1 consente a qualsiasi processo su un'istanza EC2 di interrogare il servizio di metadati senza autenticazione, rendendo possibili attacchi SSRF per sottrarre le credenziali dell'istanza. Imponga IMDSv2 (con token obbligatorio) su tutte le istanze, così da richiedere un'autenticazione basata sulla sessione.

I gruppi di sicurezza consentono in genere tutto il traffico in uscita. Ciò permette l'esfiltrazione dei dati e le comunicazioni C2 dalle istanze compromesse. Utilizzi il filtraggio in uscita tramite gruppi di sicurezza, NACL o un'appliance firewall per limitare le connessioni in uscita a destinazioni note.

Dashboard Kubernetes, cluster Elasticsearch, istanze MongoDB e notebook Jupyter esposti senza autenticazione su IP pubblici vengono regolarmente compromessi. Ogni interfaccia di gestione deve richiedere l'autenticazione e avere l'accesso limitato a livello di rete.

Gli eventi dati S3 e gli eventi di gestione CloudTrail, considerati da soli, non registrano le operazioni a livello di oggetto (GetObject, PutObject). Abiliti S3 Server Access Logging e gli eventi dati S3 di CloudTrail per i bucket sensibili, così da rilevare i tentativi di esfiltrazione dei dati.

Le regole AWS Config con correzione automatica, tramite documenti SSM Automation o Lambda, possono correggere automaticamente le violazioni: rendere privati i bucket, chiudere le regole dei gruppi di sicurezza o mettere in quarantena le credenziali, riducendo il tempo di esposizione da giorni a minuti.

Qual è il rischio principale di lasciare IMDSv1 abilitato sulle istanze EC2?

Le misconfigurazioni cloud — bucket pubblici, gruppi di sicurezza permissivi, credenziali codificate nel codice e log mancanti — sono la causa più comune delle violazioni del cloud. La scansione automatizzata, i guardrail obbligatori e il monitoraggio continuo sono misure difensive essenziali.