OWASP Cloud Security Testing Guide

La Cloud Security Testing Guide (CSTG) è un manuale completo e neutrale rispetto al fornitore per testare la sicurezza degli ambienti cloud. È scritto per penetration tester, ingegneri cloud e di piattaforma, architetti della sicurezza, ingegneri della detection e auditor: chiunque debba valutare o difendere infrastrutture in esecuzione su un importante fornitore cloud.

I fornitori cloud rilasciano e modificano servizi più velocemente di quanto qualsiasi singolo team possa tenere traccia, e ogni nuovo servizio gestito porta con sé il proprio modello di identità, esposizione di rete e percorsi di abuso. Le metodologie tradizionali di test di rete e applicazioni non catturano questi rischi specifici del fornitore: una bucket policy di S3, un ruolo IAM con permessi eccessivi, un'identità gestita associata a una macchina virtuale o un bucket di deployment scrivibile non sono riscontri che un port scan o un proxy web possano portare alla luce. CSTG esiste per colmare questa lacuna con una metodologia di test strutturata, ripetibile e specifica per fornitore.

Cosa rende diverso CSTG

• Offensivo e difensivo. Ogni pagina di tecnica documenta non solo come enumerare e sfruttare una debolezza, ma anche l'impronta di rilevamento che lascia nei log del fornitore e il rimedio concreto che la chiude. La guida è utile tanto a un blue team che indurisce un ambiente quanto a un tester che lo attacca.
• Consapevole dell'accesso. Le valutazioni cloud sono condizionate dall'accesso che viene concesso al tester: da una posizione esterna anonima, una singola credenziale divulgata, un ruolo di audit in sola lettura o un principal con privilegi elevati. Ogni pagina dichiara l'accesso che presuppone, così un incarico può essere limitato a ciò che è realmente testabile con le credenziali disponibili.
• Atomico e strutturato. I contenuti sono organizzati come una matrice fase × servizio per fornitore, con una pagina autoesplicativa per ogni servizio e fase di test. Questo rende la guida facile da navigare, a cui contribuire e da consumare a livello programmatico.
• Esauriente. L'obiettivo è documentare l'insieme completo di tecniche reali per ogni servizio: i comandi di enumerazione, le misconfigurazioni che contano e i percorsi di privilege escalation, lateral movement, post-exploitation e persistenza che ne derivano.

Come è organizzata la guida

Ogni fornitore è suddiviso in fasi di test e, all'interno di ciascuna fase, l'unità atomica è una singola pagina di servizio:

Il confine più netto nella guida è il test non autenticato vs autenticato, che riflette la domanda più importante in qualsiasi verifica cloud: di quale accesso disponiamo fin dall'inizio?

Ogni pagina segue una struttura fissa - Sommario, Prerequisiti, Enumerazione, Misconfigurazioni e Riscontri, Exploitation, Detection e Logging, Remediation e Hardening, Strumenti, Riferimenti - e contiene frontmatter leggibile da macchina (fornitore, servizio, fase, accesso richiesto, permessi richiesti). Vedi STRUCTURE.md per il formato di redazione e le definizioni dei livelli di accesso.

Guide per fornitore

Amazon Web Services (AWS)

Identità (IAM/STS), storage (S3, EBS), calcolo (EC2, Lambda, ECS/EKS, ECR), dati (RDS, DynamoDB), applicazioni e integrazione (API Gateway, SNS/SQS, Cognito), infrastructure-as-code (CloudFormation), segreti e chiavi (Secrets Manager, SSM, KMS) e logging/monitoraggio (CloudTrail).

Microsoft Azure

Identità (Entra ID, RBAC, Managed Identities), storage (Storage Accounts), calcolo (Virtual Machines, AKS), applicazioni (App Service, Functions, Logic Apps), automazione (Automation Accounts, modelli ARM), segreti e chiavi (Key Vault) e networking.

Google Cloud Platform (GCP)

Identità (IAM, Service Accounts), storage (Cloud Storage), calcolo (Compute Engine, GKE, Cloud Run, Cloud Functions), dati (Cloud SQL), build e integrazione (Cloud Build, Pub/Sub), segreti e chiavi (Secret Manager, KMS) e pivoting su Workspace.

Piattaforme applicative gestite (PaaS / BaaS)

Servizi di piattaforma il cui modello di sicurezza si basa su chiavi API, token e controlli a livello applicativo piuttosto che sull'IAM dell'infrastruttura. Le relative fasi sono adattate di conseguenza.

• Supabase - il modello di chiave anon vs service_role, l'API PostgREST generata automaticamente e la Row Level Security (RLS) di PostgreSQL, oltre ad Auth, Storage e Edge Functions.
• Vercel - token di accesso e ruoli del team, segreti nelle variabili d'ambiente, protezione del deployment e deployment di anteprima, e funzioni serverless / edge.

Utilizzo della guida

1. Stabilisci l'accesso disponibile per l'incarico (fornitore, tipo di credenziale, livello di privilegio, ambito): questo determina quali fasi e pagine sono in gioco.
2. Svolgi le fasi in ordine: comprendi la piattaforma, testa la superficie esterna, poi (con le credenziali) enumera, scala i privilegi, muoviti lateralmente e valuta post-exploitation e persistenza.
3. Per ogni riscontro, usa le sezioni Detection & Logging e Remediation & Hardening per fornire al proprietario delle risorse un output difensivo e azionabile, non solo una narrazione dell'attacco.

Autorizzazione e regole di ingaggio. Il test di ambienti cloud è soggetto alle policy di utilizzo accettabile e di penetration testing di ciascun fornitore. Le azioni di denial-of-service e distruttive sono vietate per impostazione predefinita su AWS, Azure e GCP senza approvazione preventiva. Testa sempre solo ambienti che sei esplicitamente autorizzato a valutare, nell'ambito concordato.

Contribuire

CSTG è guidato dalla comunità. Nuove pagine di servizio, tecniche aggiuntive, correzioni e copertura di nuovi fornitori sono tutte benvenute: consulta STRUCTURE.md per il formato delle pagine e i modelli di issue nella cartella .github/ISSUE_TEMPLATE/. Tutti i contributi sono concessi sotto licenza CC BY-SA 4.0.

Responsabili di progetto

• Stefano Di Paola
• Jamieson O'Reilly

Licenza

Quest'opera è distribuita con licenza Creative Commons Attribuzione-Condividi allo stesso modo 4.0 Internazionale.