CIEM cloud: cos'è e come tagliare i permessi eccessivi

La risposta breve: il CIEM (cloud infrastructure entitlement management) è la disciplina, e la categoria di strumenti, che risponde a una domanda sola: chi può fare cosa nel tuo cloud. Scopre tutte le identità, persone, service account, ruoli delle macchine e pipeline, calcola i permessi effettivi di ciascuna, li confronta con quelli usati davvero e indica cosa togliere per arrivare al privilegio minimo.

Qui trovi perché i permessi sono il punto debole del cloud, cosa calcola un CIEM, cosa offrono già i provider e come ridurre i permessi senza fermare la produzione.

Perché i permessi sono il punto debole del cloud

Nel cloud ogni azione è un'identità che chiama un'API. Chi ottiene una credenziale valida può fare tutto quello che quella credenziale permette, senza sfruttare nessuna vulnerabilità: i permessi di ciascuna identità decidono quanto è grave un furto di credenziali.

I dati di chi gli incidenti li segue vanno in questa direzione. Il Cloud Threat Horizons Report H1 2026 di Google Cloud, sulla base degli interventi di Mandiant nella seconda metà del 2025, riporta 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. Fra le raccomandazioni dello stesso rapporto c'è applicare il principio del privilegio minimo e rimuovere con regolarità i permessi eccessivi.

Il principio non è nuovo: nel catalogo NIST SP 800-53 è il controllo AC-6, Least Privilege. Quello che è cambiato è la scala: ruoli e permessi crescono a ogni rilascio.

Come si accumulano i permessi eccessivi

I permessi eccessivi nascono per strade ragionevoli:

• Si parte larghi per far funzionare le cose. La stessa guida IAM di AWS lo descrive: si può cominciare con permessi ampi mentre si capisce cosa serve, e restringerli quando il caso d'uso matura.
• Si usano ruoli pronti. AWS avverte che le sue policy gestite valgono per tutti i clienti e quindi possono non essere a privilegio minimo per il tuo caso. Google Cloud scrive che i ruoli di base (Admin, Writer e Reader, più i ruoli storici Owner, Editor e Viewer) contengono migliaia di permessi su tutti i servizi e che in produzione non vanno assegnati se esiste un'alternativa.
• Le identità non umane nascono da sole. Su Google Cloud, a seconda della policy dell'organizzazione, il service account predefinito può ricevere in automatico il ruolo Editor sul progetto. Il vincolo che lo impedisce è attivo per default solo nelle organizzazioni create dopo il 3 maggio 2024.
• Le persone cambiano ruolo, i permessi restano, e i fornitori che hanno chiuso un lavoro mantengono ruoli che nessuno ricorda.

Gli errori di configurazione più comuni, identità comprese, sono raccolti nella nostra guida agli errori di configurazione cloud. Qui ci concentriamo sui permessi.

Permessi concessi e permessi effettivi

Leggere una policy alla volta non basta. Quello che un'identità può fare davvero nasce dalla combinazione di più livelli, e Wiz, nella sua Academy dedicata al CIEM, lo chiama accesso effettivo: i permessi espliciti, quelli ereditati dai gruppi, le relazioni tra service account e i ruoli che si possono assumere da un account all'altro.

In pratica un CIEM deve tenere conto di:

• ereditarietà: un permesso dato su una cartella o su un'unità organizzativa vale per tutto quello che contiene;
• assunzione di ruoli e impersonificazione: un'identità con pochi permessi può diventarne un'altra con molti. Google Cloud segnala come rischio di movimento laterale il caso di un service account che può impersonare un service account di un altro progetto;
• limiti che restringono: permissions boundaries e service control policy su AWS non concedono permessi, ma tagliano quelli concessi altrove;
• policy sulle risorse: un bucket può aprirsi a un'identità che dal lato IAM non sembra avere accessi.

Le identità non umane: un caso reale

Service account, ruoli delle macchine, chiavi delle applicazioni, identità delle pipeline: sono le identità che nessuno rivede.

Il Cloud Threat Horizons Report ne racconta un esempio concreto. Nel 2025 Mandiant ha seguito un incidente iniziato da un pacchetto NPM compromesso, che ha rubato il token GitHub di uno sviluppatore. Il gruppo che Google traccia come UNC6426 ha poi sfruttato la relazione di fiducia OIDC tra GitHub e AWS, quella che permette alla pipeline di assumere un ruolo cloud senza credenziali statiche. Il ruolo usato per i deployment aveva permessi troppo ampi: è bastato per creare un nuovo ruolo IAM con privilegi di amministratore. Dal token rubato ai permessi di amministratore su AWS sono passate meno di 72 ore, seguite da sottrazione di file dai bucket e distruzione di istanze in produzione.

Fra le raccomandazioni del rapporto, quelle su identità e accessi riguardano i permessi: privilegio minimo per i service account delle pipeline e per i ruoli collegati a OIDC, nessun permesso permanente per azioni ad alto rischio come la creazione di ruoli o l'aggancio di policy, accesso temporaneo con approvazione per le modifiche all'infrastruttura. Tutte presuppongono di sapere quali ruoli hanno quei permessi, ed è il lavoro del CIEM.

Cosa fa un CIEM, in pratica

1. Inventario delle identità su tutti gli account, le subscription e i progetti, umane e non umane, comprese quelle federate da un identity provider esterno.
2. Calcolo dei permessi effettivi, attraverso tutti i livelli di policy visti sopra.
3. Confronto con l'uso reale: permessi, ruoli e chiavi concessi ma mai usati in una finestra di tempo, da togliere o da ridurre.
4. Priorità: un ruolo largo su un ambiente di test vuoto conta meno di un ruolo largo assegnato a una macchina esposta su internet che può leggere il database dei clienti.
5. Proposta di correzione: policy ridotte generate dall'attività osservata, da provare prima di applicarle.
6. Controllo nel tempo: nuovi permessi, nuove identità, deriva rispetto alla situazione corretta.

CIEM, IAM e PAM: chi fa cosa

L'IAM è il sistema del provider con cui si creano identità, ruoli e policy; il CIEM lavora sopra l'IAM e dice cosa quelle policy permettono in pratica. La PAM (privileged access management) governa gli accessi privilegiati delle persone; il CIEM copre anche service account, ruoli e workload. Sono strati diversi e convivono.

Cosa offrono già i provider

• AWS. IAM Access Analyzer segnala ruoli inutilizzati, chiavi di accesso e password inutilizzate e permessi inutilizzati a livello di servizio e di azione, entro una finestra di utilizzo che si configura. Può generare una policy a privilegio minimo partendo dall'attività registrata in CloudTrail, e le informazioni di ultimo accesso di IAM aiutano a togliere ciò che non serve più.
• Google Cloud. Le raccomandazioni di ruolo confrontano i permessi di ciascuna identità con quelli usati negli ultimi 90 giorni e propongono di sostituire o togliere i ruoli in eccesso; gli insight di movimento laterale segnalano i service account che possono impersonarne altri in progetti diversi.
• Microsoft. Defender for Cloud include funzioni CIEM nel piano Defender CSPM: analizza identità umane e non umane su Azure, AWS e Google Cloud e segnala permessi eccessivi, inutilizzati o configurati male. Microsoft precisa che la deprecazione di Entra Permissions Management non tocca queste funzioni.

Per un solo cloud, gli strumenti nativi sono un buon punto di partenza. Il CIEM come categoria a sé serve quando i cloud sono più di uno, quando le identità arrivano anche da identity provider e piattaforme SaaS, e quando i permessi vanno letti insieme a esposizione, vulnerabilità e dati. Per questo oggi il CIEM vive quasi sempre dentro una CNAPP, accanto al controllo delle configurazioni e dei workload.

Come arrivare al privilegio minimo senza rompere la produzione

Togliere permessi in blocco è il modo più rapido per fermare un servizio. Un percorso più sicuro:

1. Parti dalle identità con i permessi più ampi: amministratori, ruoli di base, service account delle pipeline. Sono poche e pesano più di tutte le altre.
2. Togli prima ciò che non viene usato da mesi: ruoli fermi, chiavi mai ruotate, account di persone e fornitori che non lavorano più con te.
3. Riduci i ruoli attivi in base all'uso osservato, provando le policy ridotte su un ambiente di test prima della produzione.
4. Sostituisci le chiavi statiche con credenziali temporanee, come chiede AWS per persone e workload, e federa le pipeline invece di salvare chiavi nei repository.
5. Togli i permessi permanenti sulle azioni critiche (creare ruoli, modificare policy) e concedili a tempo, con approvazione.
6. Metti un tetto a monte: limiti a livello di organizzazione e vincoli sui ruoli che i team possono creare, così il problema non si ricrea al prossimo rilascio.

CIEM e compliance: NIS2 e ISO 27001

Per chi rientra nella NIS2, l'art. 24, comma 2, lettera i), del D.Lgs. 138/2024 include fra gli elementi minimi delle misure di sicurezza le «politiche di controllo dell'accesso». La misura PR.AA-05 della Determinazione ACN 379907/2025, identica per soggetti importanti ed essenziali, scende nel dettaglio: «I permessi sono assegnati alle utenze in accordo ai principi del minimo privilegio e della separazione delle funzioni, tenuto anche conto della necessità di conoscere (need to know)».

Nella ISO/IEC 27001:2022 lo stesso tema attraversa i controlli 5.15 (Access control), 5.18 (Access rights) e 8.2 (Privileged access rights) dell'Annex A. Né la legge né la norma chiedono uno strumento. Chiedono di poter mostrare che i permessi sono assegnati e rivisti con criterio, e sul cloud un'analisi dei permessi effettivi è il modo pratico di produrre quell'evidenza.

Il CIEM con Wiz

AmagisTech è partner Wiz. Secondo la pagina che Wiz dedica al CIEM, la piattaforma costruisce la mappa dell'accesso effettivo fra identità umane, identità non umane e risorse, tenendo conto anche di boundaries, ACL e policy di organizzazione, genera policy a privilegio minimo e segnala permessi amministrativi inutilizzati, identità senza MFA o con permessi eccessivi. E collega i permessi a dati sensibili, vulnerabilità e configurazioni, per mettere in cima i percorsi che portano a permessi di amministratore o ai dati più critici.

Wiz si collega ai cloud via API, senza agenti, e dall'11 marzo 2026 fa parte di Google Cloud, che ha mantenuto il marchio e il supporto ai principali cloud, compresi AWS, Microsoft Azure e Oracle. Il punto di partenza che proponiamo è una fotografia dell'ambiente: come si svolge e cosa ricevi è spiegato in cloud security assessment.

In sintesi

In sintesi: nel cloud un furto di credenziali vale quanto i permessi dell'identità rubata. Il CIEM calcola i permessi effettivi di tutte le identità, persone e non, li confronta con l'uso reale e indica cosa togliere, in ordine di rischio. Con più cloud, e con permessi da leggere insieme a dati ed esposizione, serve una vista unica.

Se vuoi sapere quali identità del tuo cloud hanno più permessi del necessario, parti dalla fotografia del cloud con Wiz: via API, senza agenti, con i rischi in ordine di priorità.