Cloud Misconfigurations — Gli Errori che Espongono la Tua Infrastruttura e Come Evitarli

Hai mai aperto la console AWS e scoperto che un bucket S3 era accessibile a tutto il mondo? O che un database RDS non aveva restrizioni IP? Noi di Meteora Web lo vediamo almeno una volta al mese nei progetti che ci arrivano. Le cloud misconfigurations sono la prima causa di violazione dei dati nel cloud — non un attacco sofisticato, ma una porta lasciata aperta. E in un ambiente dove ogni risorsa costa, un errore di configurazione significa anche soldi buttati.

Questa guida è per chi gestisce infrastrutture cloud (AWS, Azure, GCP) e vuole capire dove si sbaglia più spesso e come sistemare. Non teoria: comandi, script, policy pronte.

Quali sono le cloud misconfigurations più pericolose per una PMI?

Partiamo dalle statistiche. Secondo il OWASP Cloud Security Project, le prime tre cause di incidenti cloud sono: bucket storage pubblici, gruppi di sicurezza troppo permissivi, e credential leak. Noi aggiungiamo un quarto: mancata rotazione delle chiavi API. Vediamole una per una.

Bucket S3 pubblici (e Azure Blob, GCP Storage)

Un bucket configurato per "public-read" permette a chiunque di scaricare i dati. Sembra banale, ma ogni anno ci sono aziende che espongono milioni di record così. Noi abbiamo recuperato un cliente che aveva il database dei clienti in un bucket pubblico: bastava un URL per vedere nome, email, indirizzo.

Come evitarlo: usa policy esplicite di blocco pubblico. Su AWS, attiva "Block Public Access" a livello di account.

# AWS CLI: blocca tutto l'accesso pubblico per un bucketaws s3api put-public-access-block --bucket nome-bucket --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Gruppi di sicurezza con regole 0.0.0.0/0

Aprire una porta (es. 22, 3306) a tutto il mondo è l'errore più comune. Ci spieghiamo: lo fanno per "testare" e poi dimenticano. Noi usiamo sempre un minimo di CIDR restrittivo anche in sviluppo.

# Terraform esempio per security group correttoresource "aws_security_group" "db_sg" {  name        = "db-security-group"  description = "Only allow MySQL from specific IP"  ingress {    from_port   = 3306    to_port     = 3306    protocol    = "tcp"    cidr_blocks = ["192.168.1.0/24"] # MAI 0.0.0.0/0  }}

Come evitare bucket S3 pubblici accidentali?

La risposta è: policy preventive e scanning automatico. Non basta una policy scritta bene: va verificata periodicamente. Il servizio AWS Config ha regole pronte per rilevare bucket pubblici. Noi lo abilitiamo sempre nei progetti che seguiamo.

Checklist operativa:

• Abilita Block Public Access a livello di account (su AWS è un flag globale).
• Usa bucket policy esplicite: nega pubblici, permetti solo da ruoli specifici.
• Scansiona con aws s3api list-buckets e controlla le policy ogni settimana.
• Implementa least privilege: ogni bucket ha accesso solo a chi serve.

Perché i gruppi di sicurezza sbagliati sono un rischio concreto?

Un gruppo di sicurezza che permette SSH (porta 22) da 0.0.0.0/0 espone il server a tentativi di brute force. Basta un'ora perché un bot inizi a provare. Noi abbiamo visto un server EC2 prendere 10.000 tentativi di login in una notte. Soluzione: usare bastion host o VPN, mai aprire SSH al mondo.

Approccio operativo:

• Regola d'oro: nessuna porta esposta a 0.0.0.0/0 tranne HTTP/HTTPS se necessario.
• Per amministrazione, usa AWS Systems Manager Session Manager (non richiede SSH).
• Controlla con aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0

Come gestire le chiavi di accesso senza esporle?

Le credential leak sono la terza causa. Mai hardcodare chiavi nel codice. Usa variabili d'ambiente o AWS Secrets Manager. Noi abbiamo un cliente che teneva le chiavi in un file .env dentro il repository Git: un errore da principiante che costa caro.

# Python example: use environment variables, not hardcodedimport osAWS_ACCESS_KEY = os.environ.get("AWS_ACCESS_KEY_ID")AWS_SECRET_KEY = os.environ.get("AWS_SECRET_ACCESS_KEY")

Best practice:

• Usa IAM Roles per EC2 e Lambda – nessuna chiave statica.
• Ruota le chiavi ogni 90 giorni.
• Scansiona il repository con git secrets o trufflehog prima del push.

Quale strumento di scanning usare per rilevare cloud misconfigurations?

Strumenti open source: CloudSploit, Trivy (per Kubernetes e cloud), Prowler (specializzato AWS). Noi usiamo Prowler nei nostri audit: esegue centinaia di controlli CIS benchmark. Basta un comando:

# Install Prowler (AWS) e avvia scansione basepip install prowlerprowler aws -M html

Genera un report HTML con tutte le risorse non conformi. Per Azure, usa azscanner. Per GCP, Forseti Security.

Cosa fare adesso

Azioni immediate per ridurre le cloud misconfigurations:

1. Blocca l'accesso pubblico a tutti i bucket storage – se non serve, non deve essere pubblico.
2. Revoca ogni regola di security group con 0.0.0.0/0 – sostituisci con CIDR aziendale o bastion.
3. Abilita AWS Config (o equivalente Azure/GCP) con regole di conformità.
4. Scansiona la tua infrastruttura oggi con Prowler o Trivy – il report ti dirà dove sei esposto.
5. Leggi la nostra guida pillar su Sicurezza Cloud e DevSecOps: Sicurezza Cloud e DevSecOps.

Noi di Meteora Web trattiamo la sicurezza cloud come un investimento, non un costo. I tool ci sono, le procedure anche. Il problema è la disattenzione. Noi partiamo sempre da una domanda: quanto costa un errore di configurazione? Il resto viene dopo.