CompTIA SY0-701: Sicurezza di Cloud, Virtualizzazione e Container — Guida allo studio
Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.
Le aziende moderne raramente operano in un unico data center autonomo. I carichi di lavoro si estendono su provider di cloud pubblico, cluster di virtualizzazione privati, orchestratori di container e funzioni serverless effimere. Ogni livello di astrazione modifica il modello di minaccia, la superficie di controllo e, aspetto fondamentale, chi è responsabile per quali controlli di sicurezza.
Il Modello di Responsabilità Condivisa
Ogni principale provider di cloud pubblica un modello di responsabilità condivisa che ripartisce i compiti di sicurezza tra il cliente e il provider di servizi cloud (CSP). La linea di demarcazione si sposta in base al livello di servizio.
In un modello Infrastructure as a Service (IaaS) — Amazon EC2, Azure Virtual Machines, Google Compute Engine — il CSP si occupa della sicurezza delle strutture fisiche, dell’hardware, dell’hypervisor e dell’infrastruttura di rete (network fabric). Tutto ciò che si trova al di sopra dell’hypervisor è di competenza del cliente: il sistema operativo guest, l’applicazione delle patch, i firewall basati su host, il middleware, il runtime, il codice dell’applicazione, la configurazione delle identità e i dati stessi. Se un’azienda implementa un database MySQL su un’istanza EC2, la messa in sicurezza di quel database è interamente responsabilità del cliente.
In un modello Platform as a Service (PaaS) — AWS RDS, Azure App Service, Google App Engine — il provider gestisce inoltre il sistema operativo, l’applicazione delle patch al motore del database e il runtime. Il cliente rimane responsabile del codice dell’applicazione, della classificazione dei dati, dei controlli di accesso, delle regole di esposizione sulla rete e della gestione delle identità.
In un modello Software as a Service (SaaS) — Microsoft 365, Salesforce, Workday — il provider gestisce quasi l’intero stack. Le responsabilità rimanenti del cliente non sono banali: il provisioning e il deprovisioning degli account, l’imposizione dell’MFA, la classificazione dei dati, i permessi di condivisione, la configurazione DLP e l’integrazione con l’identity provider aziendale. Un sito SharePoint configurato in modo errato che espone i dati delle buste paga a “Tutti” (Everyone) non è una violazione di Microsoft, ma dell’amministratore del tenant.
Un’idea errata e persistente è che la migrazione al cloud trasferisca tutta la responsabilità della sicurezza al provider. Le violazioni di dati che coinvolgono bucket S3 configurati male, cluster Elasticsearch esposti e chiavi API trapelate sono quasi universalmente riconducibili a errori da parte del cliente, non a una compromissione del CSP.
Virtualizzazione e Rischio dell’Hypervisor
La virtualizzazione raggruppa l’hardware fisico in guest logici utilizzando un hypervisor. Gli hypervisor di Tipo 1 (bare-metal) come VMware ESXi, Microsoft Hyper-V e KVM vengono eseguiti direttamente sull’hardware. Gli hypervisor di Tipo 2 (hosted) come VirtualBox vengono eseguiti su un sistema operativo generico e non sono adatti per i carichi di lavoro di produzione.
Le minacce dominanti specifiche della virtualizzazione sono la VM escape e la compromissione dell’hypervisor. La VM escape si verifica quando un codice malevolo all’interno di un guest esce dai confini della virtualizzazione e viene eseguito sull’hypervisor o su una VM adiacente. Esempi storici includono CVE-2015-3456 (VENOM, nel controller floppy di QEMU) e varie vulnerabilità di VMware Tools. Poiché un singolo hypervisor può ospitare centinaia di carichi di lavoro su più zone di fiducia (trust zone), una escape riuscita garantisce un accesso sproporzionato.
Le mitigazioni includono l’applicazione rigorosa delle patch all’hypervisor, la riduzione al minimo delle guest addition e dell’hardware emulato non utilizzato, la separazione dei carichi di lavoro per livello di sensibilità su cluster distinti e l’isolamento del piano di gestione (management plane). Il server vCenter, le interfacce di gestione di ESXi e le API del cluster devono risiedere su una rete di gestione dedicata, raggiungibile solo da jump host privilegiati con MFA.
Ulteriori preoccupazioni includono la VM sprawl (VM orfane e non aggiornate che si accumulano nel tempo) e il riutilizzo delle risorse (resource reuse), dove la memoria o lo storage di una VM dismessa non vengono correttamente azzerati prima di essere allocati a un altro tenant.
Container, Microservizi e Condivisione del Kernel
I container impacchettano un’applicazione con le sue dipendenze ma, a differenza delle VM, condividono il kernel del sistema operativo host. Docker, containerd e CRI-O gestiscono i cicli di vita dei container; Kubernetes li orchestra su larga scala. Questo isolamento leggero è una caratteristica — avvio in millisecondi, alta densità (dense packing) — ma anche il rischio principale.
L’isolamento dei container non è equivalente all’isolamento delle VM. Una vulnerabilità del kernel sfruttata dall’interno di un container può compromettere l’host e ogni altro container su di esso. I namespace (PID, network, mount, UTS, IPC, user) e i cgroup forniscono isolamento, ma sono costrutti software che condividono un’unica superficie di attacco.
La sicurezza dei container richiede controlli lungo tutta la pipeline:
# Example: Pod security context enforcing hardening
securityContext:
runAsNonRoot: true
runAsUser: 10001
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefault
Le immagini devono essere scansionate alla ricerca di vulnerabilità prima del deployment (Trivy, Snyk, Clair), costruite a partire da immagini di base minime (distroless o Alpine) e scaricate solo da registri affidabili con la firma delle immagini applicata (Cosign, Notary). Gli strumenti di protezione a runtime (Falco, Aqua, Sysdig) monitorano il comportamento dei container e segnalano anomalie come l’esecuzione di processi o connessioni di rete inaspettate.
Postura di Sicurezza Cloud e IAM
L’IAM del cloud si differenzia dall’Active Directory on-premise per aspetti importanti. In AWS, le policy IAM sono documenti JSON associati a utenti, gruppi o ruoli, e il permesso effettivo è l’intersezione delle policy basate sull’identità e delle policy basate sulle risorse, con le negazioni esplicite (explicit deny) che prevalgono sempre:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::company-data/*",
"Condition": {
"StringEquals": {"aws:RequestedRegion": "us-east-1"}
}
}]
}
Gli strumenti di Cloud Security Posture Management (CSPM) scansionano continuamente le configurazioni cloud confrontandole con benchmark di sicurezza (CIS AWS Foundations, NIST), segnalando bucket S3 pubblici, security group eccessivamente permissivi, logging di CloudTrail disabilitato e volumi EBS non crittografati. I Cloud Access Security Broker (CASB) si interpongono tra gli utenti e i servizi cloud, applicando policy DLP, policy di accesso e rilevamento delle minacce per le applicazioni SaaS.
Caso pratico: Errata configurazione di un bucket S3 che espone PII
Una startup del settore sanitario archiviava i moduli di ammissione dei pazienti in un bucket S3 che era stato creato con accesso pubblico in lettura durante uno sprint di sviluppo e mai messo in sicurezza prima di andare in produzione. Il bucket è stato scoperto da un ricercatore di sicurezza utilizzando una combinazione di DNS brute-forcing e della tecnica di enumerazione dei bucket AWS S3. Circa 87.000 cartelle di pazienti — inclusi nomi, date di nascita, ID assicurativi e descrizioni del disturbo principale — erano accessibili senza autenticazione. La startup non disponeva di alcuno strumento CSPM né di scansioni automatizzate della configurazione. Una semplice regola di AWS Config per il controllo s3-bucket-public-read-prohibited avrebbe segnalato l’errata configurazione pochi minuti dopo la sua creazione. L’incidente ha portato a un’indagine da parte dell’HHS, a un accordo extragiudiziale da 450.000 $ e a un danno reputazionale che ha contribuito all’acquisizione dell’azienda a una valutazione di realizzo.
← Sicurezza delle Applicazioni e del Web · Tutti i domini · Sicurezza dei Dati →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →