Cloud Security Assessment per AWS, Azure e GCP.

Un posture assessment verifica come sono configurati i tuoi account cloud: identità e permessi, protezione dei dati, esposizione di rete, logging e monitoraggio. Confrontiamo la configurazione con le best practice di sicurezza del provider e con i CIS Benchmarks. Un cloud penetration test attacca ciò che hai in esercizio, come farebbe un attaccante esterno o un utente compromesso, per dimostrare quali debolezze sono sfruttabili nella pratica. I due approcci si completano: la review trova le configurazioni errate su tutto l'account, il test mostra quali si possono sfruttare davvero.

Amazon Web Services, Microsoft Azure e Google Cloud, su servizi IaaS, PaaS e SaaS. Valutiamo anche i workload containerizzati e le piattaforme che li eseguono, come Docker, Kubernetes e OpenShift, compresi i servizi Kubernetes gestiti di ciascun provider. Se le tue applicazioni girano in cloud, la cloud review si può combinare con un application security assessment delle applicazioni stesse.

Per la cloud security il team ha AWS Certified Security Specialty, CCSK (il certificato della Cloud Security Alliance, indipendente dai singoli provider) e CCSE (sicurezza di container e Kubernetes). L'elenco completo, che comprende anche penetration test e sviluppo sicuro, è nella pagina Chi siamo.

Nella maggior parte dei casi non serve un'approvazione preventiva, ma ogni provider ha le sue regole. AWS consente di testare senza approvazione un elenco di servizi ammessi, vieta attività come i test di denial of service e richiede un'approvazione preventiva per qualsiasi test che coinvolga command and control. Microsoft non richiede né approvazione né notifica per Azure, ma limita i test al tuo tenant, o alle risorse che sei esplicitamente autorizzato a testare, e vieta il denial of service. Google non va avvisato, purché il test riguardi solo i tuoi progetti e rispetti la sua Acceptable Use Policy e i Termini di servizio. Pianifichiamo ogni test nel rispetto di queste regole, solo su risorse che sono tue o che sei autorizzato a far testare.

Basta un accesso in sola lettura: un utente o un ruolo dedicato, che crei tu, con permessi di lettura e di audit di sicurezza, per esempio la managed policy SecurityAudit su AWS; i ruoli Reader e Security Reader sulle sottoscrizioni Azure, più un ruolo di directory in sola lettura in Microsoft Entra ID, come Global Reader; oppure i ruoli Viewer e Security Reviewer su Google Cloud. La review non modifica nulla nel tuo ambiente e puoi revocare l'accesso appena termina.

Sì, è proprio lo scopo di Cloud Security by Design. Rivediamo l'architettura prevista e i template di infrastructure as code (per esempio Terraform, CloudFormation o Bicep) prima del deployment, così le configurazioni errate vengono corrette prima di arrivare in produzione. È anche il momento giusto per decidere come gestire identità, segmentazione di rete, cifratura e logging, invece di doverli introdurre a posteriori.

Un report scritto e approvato dagli specialisti che hanno svolto l'attività: un executive summary, poi i problemi individuati, ordinati per rischio, ciascuno con le risorse coinvolte e i passi per risolverlo. Quando serve, colleghiamo i risultati ai requisiti che devi rispettare, come ISO/IEC 27001 o NIS2. Ripercorriamo i risultati con il tuo team, lo supportiamo durante le correzioni e con un retest verifichiamo che ogni problema sia stato risolto.