Sicurezza cloud per startup e scaleup SaaS: da dove partire

La risposta breve: per una startup o una scaleup SaaS la sicurezza del cloud si gioca su cinque cose. Sapere cosa gira negli account, chi ha quali permessi, cosa è raggiungibile da internet, dove stanno i dati dei clienti e quanto in fretta si chiudono le vulnerabilità. Sono le stesse domande che fanno clienti enterprise, due diligence e investitori: averle documentate accorcia i tempi di firma.

Il resto dell'articolo è per chi il cloud l'ha costruito, di solito il CTO o il primo ingegnere DevOps, e adesso deve rispondere di come lo tiene in ordine. Vediamo chi fa le domande, da dove entrano davvero gli attaccanti, cosa sistemare per primo e quali evidenze tenere pronte.

Perché il cloud di una scaleup diventa un tema commerciale

All'inizio la sicurezza del cloud è una questione tecnica, e la gestisce chi scrive il codice. Poi arrivano i clienti grandi, e diventa una questione di vendita. Il prodotto può essere ottimo, ma l'ufficio acquisti del cliente deve sapere dove finiranno i suoi dati e chi può arrivarci.

Per molti di quei clienti non è una curiosità: è un obbligo che ricade a cascata sui fornitori.

• Clienti soggetti alla NIS2. L'art. 24, comma 2, lettera d) del D.Lgs. 138/2024 mette la sicurezza della catena di approvvigionamento fra le misure minime, compresi i rapporti con i diretti fornitori. Il comma 3 aggiunge che i soggetti devono tenere conto della qualità delle pratiche di sicurezza dei fornitori, comprese le loro procedure di sviluppo sicuro. Il questionario che ti arriva è il modo in cui il cliente documenta quella valutazione.
• Banche, assicurazioni e altri soggetti DORA. L'art. 30 del regolamento (UE) 2022/2554 elenca cosa devono contenere almeno i contratti con i fornitori di servizi TIC: fra gli altri, le località in cui si trattano e si conservano i dati, le disposizioni su disponibilità, integrità e riservatezza dei dati e l'assistenza in caso di incidente. Se il servizio supporta funzioni essenziali o importanti, il paragrafo 3 aggiunge diritti di accesso, ispezione e audit.
• Investitori e acquirenti. In un round avanzato o in un'operazione straordinaria la due diligence tecnica guarda anche come è gestito il cloud: chi ha accesso amministrativo, se esiste un inventario, come si trattano i dati dei clienti. Non c'è una norma che lo imponga, ma una risposta vaga apre domande che rallentano l'operazione.

Di cosa rispondi tu e di cosa risponde il provider

AWS descrive la divisione con una formula che vale per tutti i grandi cloud: il provider è responsabile della sicurezza del cloud, il cliente della sicurezza nel cloud. Al provider spettano hardware, rete e data center. Al cliente, secondo la pagina di AWS sul modello di responsabilità condivisa, spettano il sistema operativo delle macchine con le sue patch, il software applicativo, la configurazione dei firewall, i dati con la loro cifratura e i permessi IAM. La ripartizione cambia con il servizio: un database gestito ti toglie le patch del sistema operativo, non la scelta di chi può leggerlo.

Per una scaleup la conseguenza pratica è semplice. La certificazione del provider non copre i tuoi errori di configurazione, e il cliente enterprise lo sa: per questo chiede di te, non di AWS o di Google Cloud.

Da dove entrano gli attaccanti nel cloud

Prima di decidere le priorità conviene guardare i dati di chi gli incidenti li vede. Il Cloud Threat Horizons Report H1 2026 di Google Cloud riporta, per la seconda metà del 2025, come sono stati ottenuti gli accessi iniziali negli ambienti Google Cloud osservati (un sottoinsieme dell'attività, avverte il rapporto):

• 44,5% sfruttando software di terze parti vulnerabile, per la prima volta il vettore principale;
• 27,2% con credenziali deboli o assenti, in calo dal 47,1% della prima metà dell'anno;
• 21% attraverso configurazioni sbagliate, in calo dal 29,4%.

Lo stesso rapporto, sulla base degli interventi di Mandiant nella seconda metà del 2025, scrive che negli incidenti che hanno coinvolto i principali ambienti cloud e SaaS gli attaccanti hanno sfruttato problemi di identità per l'accesso iniziale nell'83% dei casi, e che l'obiettivo erano i dati nel 73% degli incidenti legati al cloud.

La lettura per chi gestisce un SaaS: componenti di terze parti non aggiornati, identità e configurazioni restano le tre porte principali. Sono anche le tre cose che crescono più in fretta quando il team raddoppia.

Le cinque cose da sistemare per prime

Non serve un programma di sicurezza completo per partire. Serve ordine su questi punti, in questa sequenza.

1. Inventario di account e risorse

Quanti account AWS, progetti Google Cloud o subscription Azure esistono davvero? Nelle scaleup capita spesso di trovare l'ambiente di test di un progetto chiuso, o l'account aperto da un collaboratore che non c'è più. Una struttura con account separati per produzione, staging e sviluppo, sotto un'organizzazione unica, rende tutto il resto più semplice.

2. Identità e permessi

Autenticazione a più fattori per tutte le persone, nessun utente root o owner usato tutti i giorni, chiavi di accesso statiche ridotte al minimo e ruoli con i permessi che servono, non quelli comodi. Vale anche per le identità non umane: service account, ruoli delle macchine, token delle integrazioni SaaS. Sono quelle che nessuno rivede.

3. Esposizione su internet

Bucket pubblici, database con un indirizzo pubblico, pannelli di amministrazione raggiungibili da fuori, porte aperte rimaste da un test. Ogni risorsa esposta deve avere un motivo e un proprietario.

4. Vulnerabilità e componenti di terze parti

Immagini dei container, librerie, framework applicativi: è la porta che nei dati di Google Cloud è passata al primo posto. Serve sapere quali componenti girano in produzione, quali hanno vulnerabilità note e quali di quelle sono su risorse esposte. Quest'ultima informazione decide l'ordine delle correzioni.

5. Dati dei clienti e segreti

Dove stanno i dati personali e i dati dei clienti, in quali regioni, cifrati con quali chiavi, letti da chi. E dove sono finiti i segreti: password nel codice, token nei file di configurazione, chiavi copiate su un disco. Sono le prime cose che un attaccante cerca dopo essere entrato.

Un sesto punto attraversa tutti gli altri: i log di audit del cloud devono essere attivi, conservati fuori dall'account che registrano e letti da qualcuno. Un allarme che nessuno guarda non conta come controllo.

Cosa chiedono clienti enterprise, due diligence e investitori

Le domande cambiano forma, ma il contenuto si ripete. Conviene tenere pronte queste evidenze:

• l'inventario degli ambienti cloud, con regioni e servizi usati;
• la politica degli accessi: chi ha privilegi amministrativi, come si concedono e si revocano, con quale frequenza si rivedono;
• la gestione delle vulnerabilità: come si trovano, in quanto tempo si correggono quelle critiche, chi decide le eccezioni;
• la mappa dei dati: dove stanno quelli dei clienti, come sono cifrati, cosa succede alla fine del contratto;
• la procedura per gli incidenti: chi viene avvisato, in quanto tempo, come si informa il cliente;
• la continuità: backup, test di ripristino, dipendenza da un solo provider o da una sola regione.

Le prime quattro voci si documentano meglio con lo stato reale del cloud che con una policy. Un documento dice come dovrebbe essere, una fotografia dell'ambiente dice com'è oggi. Il cliente più attento chiede entrambe.

ISO 27001 e SOC 2 bastano?

Aiutano molto, ma rispondono a una domanda diversa. Una certificazione ISO 27001 o un report SOC 2 attestano che esiste un sistema di gestione e che i controlli funzionano nel perimetro dichiarato. La ISO/IEC 27001:2022 ha anche un controllo dedicato al cloud, il 5.23 sulla sicurezza delle informazioni nell'uso dei servizi cloud. Il percorso per una realtà piccola lo trovi in ISO 27001 per startup e SaaS.

Quello che il certificato non dice è cosa è esposto stamattina. Un audit guarda un campione in un periodo dato, mentre l'infrastruttura di un SaaS cambia a ogni rilascio. Per questo il questionario chiede comunque come controlli le configurazioni nel tempo, e un auditor apprezza evidenze che arrivano dall'ambiente e non da uno screenshot.

Strumenti nativi, piattaforma o servizio: cosa serve in base alla fase

La scelta dipende più dalla forma del cloud che dal numero di dipendenti.

• Un solo cloud, pochi account, un team piccolo. Gli strumenti del provider (AWS Security Hub, Security Command Center su Google Cloud, Microsoft Defender for Cloud) danno una base di controlli sulle configurazioni. Il limite, quando il cloud cresce, è che restituiscono liste lunghe da ordinare a mano.
• Più account o più cloud, Kubernetes, rilasci frequenti. Qui serve collegare i segnali: una vulnerabilità conta di più se la macchina è esposta e ha un ruolo che arriva ai dati. È il lavoro di una CNAPP, che mette configurazioni, workload, permessi e dati nello stesso modello e ne ricava i percorsi di attacco.
• Clienti regolati o un round in arrivo. Oltre allo strumento serve qualcuno che smaltisca la coda delle correzioni, tenga le evidenze aggiornate e risponda ai questionari. Se non c'è una persona dedicata, è il punto in cui un partner esterno fa la differenza sul tempo degli ingegneri.

Da dove partire: una fotografia del cloud

Il primo passo utile è vedere l'ambiente com'è, prima di comprare altro. Una valutazione della sicurezza del cloud fa l'inventario degli account, mette in relazione esposizione, vulnerabilità, permessi e dati, e restituisce una lista breve in ordine di priorità.

AmagisTech è partner Wiz e la fotografia la facciamo con Wiz. Il collegamento avviene via API, senza agenti: l'inventario usa permessi API in lettura, mentre l'analisi dei dischi lavora su snapshot temporanei e cifrati, quindi i permessi per crearli e cancellarli fanno parte del ruolo da concedere e conviene leggerli con chi amministra il cloud prima di partire. Google ha completato l'acquisizione di Wiz l'11 marzo 2026, mantenendo il marchio, e ha confermato che i prodotti Wiz continuano a funzionare su AWS, Microsoft Azure e Oracle oltre che su Google Cloud. Più dettagli su prodotto e acquisizione in Wiz, cos'è.

In sintesi

In sintesi: per una startup o una scaleup SaaS la sicurezza del cloud non è un progetto infinito. È ordine su inventario, identità, esposizione, vulnerabilità e dati, più le evidenze per dimostrarlo a clienti, due diligence e investitori. La certificazione dice che il processo esiste, la fotografia dell'ambiente dice com'è il cloud oggi, e i clienti più attenti chiedono entrambe. Se vuoi sapere cosa troverebbe nel tuo, parti dalla fotografia del cloud con Wiz.