Cloud penetration test: cosa include e come sceglierlo

Punti chiave

Un cloud penetration test è un test offensivo autorizzato sugli account AWS, Azure o Google Cloud: prova a sfruttare identità e permessi, configurazioni, carichi di lavoro e API per mostrare dove arriverebbe un attaccante.
Il perimetro è la parte che il modello di responsabilità condivisa lascia al cliente: sistema operativo, applicazioni, regole di rete, dati e permessi IAM. L'infrastruttura del provider non si testa.
AWS, Microsoft e Google consentono i test ordinari senza approvazione preventiva, purché riguardino solo le proprie risorse; AWS e Microsoft vietano in modo esplicito il denial of service, e AWS rimanda al supporto per i servizi fuori elenco e a un modulo per alcuni eventi simulati.
Il cloud security assessment lavora in ampiezza e non sfrutta niente, il pentest lavora in profondità e dimostra i percorsi: fatto dopo la fotografia del cloud, il pentest è più mirato.
Per scegliere il fornitore conta che il perimetro parli di identità e non solo di IP, che le regole d'ingaggio citino le policy dei provider, che il report descriva percorsi e che il retest sia incluso.

Un cloud penetration test è un test offensivo autorizzato sui tuoi account AWS, Azure o Google Cloud: prova a sfruttare identità e permessi (IAM), configurazioni, carichi di lavoro e API per mostrare dove arriverebbe un attaccante. Il fornitore si sceglie guardando perimetro, metodo e report. Per i test ordinari sulle tue risorse nessuno dei tre provider chiede un'approvazione preventiva, purché si rispettino le loro regole.

Questa pagina serve a chi deve commissionarne uno: cosa entra nel perimetro, cosa permettono AWS, Microsoft e Google, in cosa si distingue da un cloud security assessment e quali domande fare a chi lo eseguirà.

Cos'è un penetration test del cloud

La logica è quella di ogni penetration test: un'attività offensiva concordata, delimitata e documentata, che non si ferma a elencare le debolezze ma prova a sfruttarle. Nel cloud cambia il bersaglio. Non ci sono solo server e porte aperte: c'è un piano di controllo governato da API, dove un permesso di troppo pesa quanto una vulnerabilità non corretta.

Il perimetro lo disegna il modello di responsabilità condivisa. AWS lo descrive distinguendo la sicurezza of the Cloud, che resta al provider (hardware, rete, strutture fisiche), dalla sicurezza in the Cloud, che resta al cliente: sistema operativo delle macchine, software applicativo, regole dei security group, gestione e cifratura dei dati, permessi assegnati con IAM. AWS precisa anche che la parte del cliente dipende dai servizi scelti: su una macchina virtuale gestisci quasi tutto, su un servizio gestito come lo storage a oggetti ti restano soprattutto dati e accessi (AWS, Shared Responsibility Model).

Il test lavora su quella parte. L'infrastruttura del provider non è un bersaglio, e le regole che vedremo più avanti lo dicono in modo esplicito.

Cosa si testa

Identità e permessi

È l'area che distingue di più un test cloud da uno tradizionale. Il tester parte da un'identità concreta (un utente a basso privilegio, una chiave trovata in un repository, il ruolo di una funzione serverless) e cerca la strada verso privilegi più alti: un ruolo che può modificare le proprie policy, un service account che può impersonarne un altro, una relazione di fiducia tra account troppo larga. Il tema dei permessi accumulati e mai rivisti è quello che trattiamo nella guida al CIEM e ai permessi cloud: il pentest dice quali di quei permessi portano davvero da qualche parte.

Configurazioni

Bucket e storage account leggibili dall'esterno, regole di rete aperte a tutto internet, log disattivati, snapshot condivisi pubblicamente. Molti di questi problemi li elenca già uno scanner di postura. Il test aggiunge la prova: cosa si riesce a leggere, scrivere o raggiungere davvero partendo da quella configurazione. I casi più comuni sono raccolti negli errori di configurazione del cloud.

Carichi di lavoro

Macchine virtuali, container, cluster Kubernetes e funzioni serverless: vulnerabilità del software, segreti lasciati nelle variabili d'ambiente o nelle immagini, possibilità di uscire dal container verso il nodo che lo ospita. Qui il test somiglia di più a un pentest classico, con una differenza: ogni carico di lavoro ha un'identità cloud associata, quindi compromettere una macchina spesso significa ottenere credenziali per le API del provider.

API e applicazioni esposte

Le applicazioni che girano nel cloud espongono API, ed è spesso da lì che si entra. L'OWASP API Security Top 10, edizione 2023, mette al primo posto la Broken Object Level Authorization e include la Server Side Request Forgery (API7:2023). La seconda ha un peso particolare nel cloud: un'applicazione vulnerabile può essere indotta a interrogare il servizio di metadati dell'istanza, che espone anche informazioni sul ruolo IAM associato. AWS rimanda per questo alla versione 2 del servizio (IMDSv2), basata su sessioni con token, come livello di sicurezza in più contro firewall aperti, reverse proxy e vulnerabilità SSRF (documentazione Amazon EC2, Use the Instance Metadata Service). Se il cuore del rischio è l'applicazione, il formato giusto è un web application penetration test, da affiancare a quello sull'account.

Le regole di AWS, Microsoft e Google

Ogni provider pubblica una policy sui test di sicurezza. Vanno lette prima dello scoping, non dopo: definiscono cosa si può fare senza chiedere e cosa no.

AWS

Per un elenco di servizi (tra cui EC2, RDS e Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS e Fargate) i clienti possono eseguire test sulle proprie risorse senza approvazione preventiva. Per i servizi non elencati si contatta il supporto. Sono vietati, tra gli altri, il DNS zone walking sulle zone ospitate in Route 53, i test di denial of service e le loro simulazioni, il flooding di porte, protocolli e richieste, il takeover di bucket S3 e di sottodomini. Le simulazioni avversarie in incognito, l'hosting di command and control, il phishing simulato e i test di malware passano dal modulo Simulated Events, da inviare almeno due settimane prima (AWS, Penetration Testing).

Microsoft Azure

Microsoft non chiede più un'approvazione preventiva per i test sulle risorse Azure (documentazione Microsoft Learn, Penetration testing) e rimanda alle Microsoft Security Testing Rules of Engagement, che limitano i test al proprio tenant o agli asset per cui si ha un'autorizzazione esplicita. Le regole vietano i test di denial of service, il fuzzing di rete che genera traffico eccessivo, l'accesso a dati e tenant di altri clienti e l'uso di credenziali non proprie, anche se trapelate. Se il test trova una vulnerabilità della piattaforma, ci si ferma alla prima dimostrazione e la si segnala a Microsoft. Il documento avverte anche che Microsoft può interrompere a sua discrezione un attacco in corso, anche se fa parte di un test legittimo.

Google Cloud

Nella Cloud Security FAQ, Google indica che per un penetration test sulla propria infrastruttura non è necessario contattarla. Restano due condizioni: rispettare l'Acceptable Use Policy e i Terms of Service, e fare in modo che i test riguardino solo i propri progetti. Una vulnerabilità della piattaforma va segnalata tramite il Vulnerability Reward Program di Google.

Il filo comune è chiaro: si testa ciò che è tuo, non si mette sotto carico l'infrastruttura condivisa, e una falla del provider si segnala invece di sfruttarla. Un fornitore serio porta queste regole nelle regole d'ingaggio scritte, servizio per servizio.

Cloud penetration test e cloud security assessment

Sono due lavori diversi, e spesso è utile farli in sequenza.

Il cloud security assessment lavora in ampiezza. Collega uno strumento agli account via API, fa l'inventario, legge configurazioni e permessi, mette in relazione esposizione, vulnerabilità e dati, e consegna una lista di rischi in ordine di priorità. Non sfrutta niente.
Il penetration test lavora in profondità. Prende alcune ipotesi e le prova fino in fondo: dimostra che un percorso esiste, fin dove porta, cosa si riesce a leggere o modificare.

Un assessment fatto prima rende il pentest più mirato: indica quali account, ruoli e risorse meritano le ore del tester. Un pentest fatto senza fotografia rischia di spendere tempo su ciò che uno scanner avrebbe trovato in pochi minuti. Da partner Wiz, facciamo la fotografia collegandoci agli account via API, senza agenti: è il percorso della fotografia del cloud.

Come si svolge

Lo schema resta quello del NIST SP 800-115 (pianificazione, discovery, attacco, reporting), con alcune scelte tipiche del cloud da fissare in partenza.

Perimetro. Quali account, subscription e progetti, quali regioni, quali servizi. Un account escluso resta fuori dal test, e nel cloud gli account dimenticati sono un classico.
Punto di partenza. Dall'esterno senza credenziali, da un'identità a basso privilegio (lo scenario della chiave rubata), oppure con accesso in lettura alle configurazioni per una revisione più completa. Nel cloud la seconda opzione è di solito la più istruttiva.
Regole d'ingaggio. Ambiente (produzione o copia fedele), finestre orarie, servizi esclusi, divieti dei provider, contatto per le emergenze, cosa fare se si trovano dati sensibili.
Esecuzione. Ricognizione, ricerca dei percorsi di escalation, sfruttamento verificato, tentativi di movimento tra account e servizi.
Report e retest. Catena riproducibile per ogni finding, priorità di correzione e verifica che le correzioni tengano. Come leggerlo è spiegato nella guida al report di penetration test.

Come scegliere chi lo fa

Le domande che separano un test sul cloud da un test di rete con un'etichetta diversa:

Il perimetro parla di identità o solo di indirizzi IP? Se la proposta elenca solo IP e porte, il piano di controllo resta fuori.
Il fornitore conosce i servizi che usi? Un ambiente costruito su funzioni serverless e Kubernetes gestito non si testa come uno fatto di macchine virtuali.
Le regole d'ingaggio citano le policy del provider? È un segnale semplice di metodo, e ti mette al riparo da attività che il provider vieta.
Il report racconta percorsi o elenca problemi? Il valore sta nella catena: da quale identità si parte, quali permessi si attraversano, a quali dati si arriva.
Il retest è incluso? Senza, nessuno sa se le correzioni hanno chiuso il percorso.
Cosa succede dopo? Un pentest fotografa un momento, il cloud cambia a ogni rilascio. Conviene sapere da subito come si tengono sotto osservazione postura e allarmi.

I fattori che pesano sull'impegno (numero di account, servizi, ruoli, ambienti, retest) sono gli stessi che guidano il preventivo: li trovi in quanto costa un penetration test.

Il pentest del cloud e la conformità

Nessuna norma nomina il penetration test del cloud come attività a sé, ma diversi quadri ci arrivano. Nell'Allegato A della ISO/IEC 27001:2022 il controllo 5.23 riguarda la sicurezza delle informazioni nell'uso dei servizi cloud e l'8.8 la gestione delle vulnerabilità tecniche. Per il settore finanziario, il Regolamento (UE) 2022/2554 (DORA) all'art. 25 include i test di penetrazione nel programma di test di resilienza operativa digitale, e all'art. 26 stabilisce che, quando i fornitori terzi di servizi TIC rientrano nel perimetro dei test avanzati basati su minacce (TLPT), l'entità finanziaria ne assicura la partecipazione e resta pienamente responsabile del rispetto del regolamento, con la possibilità di test congiunti tra più entità (pooled testing).

In sintesi

Un cloud penetration test prova a sfruttare ciò che nel modello di responsabilità condivisa resta a te: identità, configurazioni, carichi di lavoro e API. AWS, Microsoft e Google permettono i test ordinari sulle proprie risorse senza approvazione preventiva (AWS la chiede per i servizi fuori elenco e per alcuni eventi simulati, come le simulazioni avversarie in incognito), entro regole precise che vanno scritte nelle regole d'ingaggio. Funziona meglio dopo una fotografia del cloud, con un fornitore che ragiona per percorsi e include il retest.

AmagisTech affianca il mid-market italiano su pentest, postura cloud e monitoraggio 24/7. Se vuoi definire perimetro e punto di partenza del tuo test, trovi come lavoriamo nella pagina cybersecurity gestita.

Domande frequenti

Cosa include un cloud penetration test e come si sceglie chi lo fa?

Include i test su identità e permessi IAM, configurazioni, carichi di lavoro (macchine, container, funzioni serverless) e API degli account cloud, con lo sfruttamento verificato dei percorsi trovati. Il fornitore si sceglie guardando se il perimetro parla di identità e non solo di indirizzi IP, se le regole d'ingaggio rispettano le policy del provider, se il report descrive percorsi riproducibili e se il retest è incluso.

Serve l'autorizzazione di AWS, Azure o Google Cloud per fare un penetration test?

Per i test ordinari sulle proprie risorse no. AWS non chiede approvazione per un elenco di servizi pubblicato, ma la chiede per i servizi fuori elenco e, tramite il modulo Simulated Events, per attività come command and control o phishing simulato. Microsoft non chiede notifica ma limita i test al proprio tenant. Google indica che non serve contattarla, nel rispetto di Acceptable Use Policy e Terms of Service. AWS e Microsoft vietano in modo esplicito il denial of service.

Che differenza c'è tra cloud penetration test e cloud security assessment?

L'assessment collega uno strumento agli account via API, fa l'inventario e mette in relazione esposizione, vulnerabilità, permessi e dati, senza sfruttare niente. Il penetration test prende alcune ipotesi e le prova fino in fondo, dimostrando fin dove porta un percorso. Spesso conviene farli in sequenza: l'assessment indica dove concentrare il test.

Cosa resta escluso da un penetration test del cloud?

L'infrastruttura del provider, che nel modello di responsabilità condivisa resta a lui, e le risorse di altri clienti. Restano esclusi anche i test di denial of service, vietati in modo esplicito da AWS e Microsoft, e gli account non inclusi nel perimetro. Una vulnerabilità della piattaforma, se emerge, si segnala al provider invece di sfruttarla.

Il cloud penetration test è richiesto dalla conformità?

Nessuna norma lo nomina come attività a sé, ma diversi quadri ci arrivano. La ISO/IEC 27001:2022 ha nell'Allegato A il controllo 5.23 sull'uso dei servizi cloud e l'8.8 sulla gestione delle vulnerabilità tecniche. Per il settore finanziario DORA include i test di penetrazione nel programma di test (art. 25) e regola la partecipazione dei fornitori terzi di servizi TIC ai TLPT (art. 26).