La cloud security è la disciplina che si occupa di proteggere i dati, le applicazioni e l’infrastruttura ospitati in ambienti cloud pubblici (AWS, Microsoft Azure, Google Cloud Platform) o ibridi. A differenza della sicurezza tradizionale on-premise — dove l’organizzazione controlla tutto lo stack — il cloud introduce il modello di responsabilità condivisa: il provider è responsabile della sicurezza dell’ infrastruttura cloud; il cliente è responsabile della sicurezza nel cloud. Comprendere esattamente dove finisce la responsabilità del provider e dove inizia quella del cliente è il punto di partenza di qualsiasi strategia di cloud security.
Il modello di responsabilità condivisa
La responsabilità si distribuisce diversamente a seconda del modello di servizio:
| Strato | IaaS (es. EC2) | PaaS (es. App Service) | SaaS (es. M365) |
|---|---|---|---|
| Dati | Cliente | Cliente | Cliente |
| Identità e accessi | Cliente | Cliente | Cliente |
| Applicazione | Cliente | Cliente | Provider |
| Runtime / OS | Cliente | Provider | Provider |
| Virtualizzazione | Provider | Provider | Provider |
| Rete fisica, datacenter | Provider | Provider | Provider |
Il confine più frainteso è quello dell’identità: indipendentemente dal modello, la gestione delle identità, dei permessi e delle chiavi è sempre responsabilità del cliente. La maggior parte delle violazioni cloud non sfrutta vulnerabilità dell’infrastruttura del provider — sfrutta IAM mal configurato, bucket S3 pubblici, chiavi API esposte o credenziali rubate.
Principali vettori di rischio nel cloud
Misconfigurazioni IAM: permessi eccessivamente permissivi, policy con *:* (accesso totale), ruoli con AdministratorAccess assegnati a workload che non ne hanno bisogno. Il CSPM (Cloud Security Posture Management) automatizza la rilevazione delle misconfigurazioni.
Storage pubblicamente esposto: bucket S3, Azure Blob Storage o GCS bucket configurati come pubblici per errore hanno esposto miliardi di record in breach documentati (Capital One, 2019: 100M record). La configurazione predefinita attuale dei principali provider è privata, ma procedure di migrazione o script legacy possono riaprirla.
Chiavi e segreti esposti: chiavi API AWS, connection string di database o token di servizio hardcodati nel codice sorgente e finiti su repository pubblici. Tools come truffleHog e git-secrets scansionano i repository alla ricerca di segreti. AWS ha un sistema di rilevamento automatico che notifica il proprietario quando una chiave attiva viene trovata su GitHub.
Metadata service SSRF: ogni VM in cloud ha un endpoint di metadati interno non autenticato (es. http://169.254.169.254 su AWS) che espone le credenziali temporanee del ruolo IAM associato. Un’applicazione vulnerabile a SSRF (Server-Side Request Forgery) può essere usata per interrogare questo endpoint e rubare le credenziali del ruolo.
Lateral movement cloud-native: ottenute credenziali IAM sufficienti, un attaccante può enumerare risorse, creare nuovi utenti/ruoli, accedere a database, segreti in AWS Secrets Manager, snapshot EBS — tutto tramite API cloud legittime, senza toccare il sistema operativo.
Controlli fondamentali
Identity and Access Management (IAM) con minimo privilegio: ogni identità (utente, ruolo, service account) deve avere solo i permessi strettamente necessari. Usare ruoli IAM per le applicazioni invece di chiavi API statiche — le credenziali temporanee si ruotano automaticamente.
Multi-Factor Authentication obbligatorio per tutti gli account umani, in particolare per i privilegi amministrativi.
Logging e monitoring centralizzato: AWS CloudTrail, Azure Activity Log, GCP Audit Logs registrano ogni chiamata API. Inviare i log a un SIEM separato dall’account principale — un attaccante con accesso all’account potrebbe altrimenti cancellare le sue tracce.
Cifratura at-rest e in-transit: abilitare la cifratura sui servizi di storage (S3 SSE, EBS encryption, RDS encryption) con chiavi gestite dal cliente (CMK) dove richiesto dalla compliance.
CSPM (Cloud Security Posture Management): strumenti come AWS Security Hub, Microsoft Defender for Cloud, o prodotti di terze parti (Wiz, Prisma Cloud) scansionano continuamente la configurazione dell’ambiente cloud alla ricerca di deviazioni dalle best practice e dai requisiti di compliance.
Sicurezza come codice
In ambienti cloud moderni, l’infrastruttura è definita come codice (Terraform, CloudFormation). I controlli di sicurezza devono essere integrati nella pipeline IaC: tfsec, Checkov e OPA (Open Policy Agent) analizzano staticamente i template prima del deployment, bloccando configurazioni insicure prima che raggiungano la produzione.