Guida alla gestione degli accessi cloud per l’IT

La gestione degli accessi cloud efficace si ottiene con un programma di identity management centrato sul principio del minimo privilegio, un sistema di Privileged Access Management (PAM) per gli account critici, l’automazione del provisioning e del deprovisioning e un sistema di logging pronto per l’audit. Non è un progetto che si conclude, ma un processo che va governato ogni giorno, e le prime azioni contano più delle successive.

Nelle prime 24-72 ore, sei interventi riducono la superficie di rischio più immediata, quella legata agli account con privilegi elevati e ai punti di accesso alle console di gestione. Il perimetro tradizionale, nel cloud, non esiste più: l’identità di ogni utente e servizio è diventata il vero confine da proteggere, ed è per questo che IAM e PAM sono controlli critici richiesti da NIS2 e DORA.

• Abilitare l’autenticazione a più fattori (MFA) su tutte le console di gestione, senza eccezioni per gli amministratori.
• Revocare immediatamente gli account inattivi con privilegi elevati, partendo da chi non accede da oltre 90 giorni.
• Costruire un inventario completo degli account privilegiati, umani e non umani (chiavi API, account di servizio).
• Attivare un sistema di logging centralizzato per tutti gli eventi di accesso alle risorse cloud critiche.
• Applicare il minimo privilegio sui ruoli esistenti, eliminando permessi ereditati e non più necessari.
• Collegare il provisioning degli account al sistema HR, così che un’uscita dal personale generi automaticamente la revoca degli accessi.

Un consiglio: prima di intervenire su qualsiasi policy, stampa (anche solo in un foglio di calcolo) l’elenco di chi ha accesso amministrativo a ciascun servizio cloud. Molte aziende che affrontano questo esercizio per la prima volta scoprono account che nessuno ricordava di aver creato.

Questi sei passaggi non sono arbitrari: riflettono le priorità indicate da ENISA nella guida alla sicurezza del cloud per le PMI e sono coerenti con i controlli richiesti da ISO 27001 e ISO 27017 per la gestione degli accessi ai servizi cloud.

Punti chiave

La gestione degli accessi cloud funziona quando combina MFA obbligatoria, PAM sugli account critici, automazione del ciclo di vita delle identità e logging centralizzato collegato a revisioni periodiche documentate.

1. Primi 30 giorni: inventario completo delle identità, attivazione MFA sulle console di gestione, revoca degli account inattivi privilegiati.
2. 30-90 giorni: implementazione dell’Identity Provider centrale, federazione SSO, primo deploy del PAM sugli account amministrativi.
3. 90-180 giorni: automazione completa di provisioning e deprovisioning collegata all’HR, prima revisione periodica formale degli accessi privilegiati.

• KPI da monitorare: percentuale di account con MFA attiva, tempo medio di deprovisioning dopo un’uscita, numero di account privilegiati residui dopo la razionalizzazione, tempo medio per la rotazione delle credenziali.
• Evidenze da raccogliere per audit e clienti: registro privilegiati aggiornato, verbali di revisione firmati, report delle sessioni registrate, configurazione MFA documentata.

Indice

• Come costruire una roadmap operativa per la gestione accessi cloud
• Quali sono le basi tecniche dell’autenticazione cloud?
• RBAC o ABAC: quale modello di autorizzazione scegliere?
• Come gestire gli accessi privilegiati con il PAM
• Come gestire il ciclo di vita delle identità: joiner, mover, leaver
• Cosa loggare e come trasformare i log in evidenza di audit
• Come si mappano gli accessi cloud a ISO 27001, ISO 27017, GDPR e NIS2
• Quali strumenti servono per governare gli accessi cloud
• Quali checklist e template servono davvero alle PMI italiane
• Perché gli errori sulla gestione degli accessi si ripetono sempre uguali
• Come Securityhub supporta l’implementazione della gestione accessi cloud
• Fonti

Come costruire una roadmap operativa per la gestione accessi cloud

Passare da una gestione degli accessi improvvisata a un sistema maturo richiede una sequenza precisa, non un elenco di buone intenzioni. Ogni fase ha un responsabile diverso e una finestra temporale realistica, e saltare un passaggio per “guadagnare tempo” è la causa più comune di implementazioni fallite.

1. Inventario delle identità (0-15 giorni). Il team IT mappa ogni account umano e non umano, con relativi privilegi, su tutti i servizi cloud in uso.
2. Progettazione del modello di autorizzazione (15-30 giorni). Si definisce se adottare RBAC, ABAC o un approccio misto, coinvolgendo i proprietari dei servizi.
3. Implementazione di Identity Provider e MFA (30-60 giorni). Gli amministratori cloud configurano la federazione con un IdP centrale e attivano l’autenticazione a più fattori.
4. Deploy del PAM per gli account critici (60-90 giorni). Si introduce vaulting delle credenziali e accesso just in time per amministratori e account di servizio.
5. Automazione di provisioning e deprovisioning (90-120 giorni). HR e IT collegano i sistemi per sincronizzare automaticamente onboarding, cambio ruolo e uscita.
6. Attivazione di logging e monitoraggio (120-150 giorni). Il SOC (interno o esterno) riceve i log centralizzati e configura gli alert.
7. Prima revisione periodica degli accessi (150-180 giorni). Il responsabile GDPR e i manager di linea certificano formalmente i permessi assegnati.
8. Consolidamento e audit interno (oltre 180 giorni). Si verifica la copertura documentale in vista della certificazione ISO 27001 o ISO 27017.

Una matrice di responsabilità semplificata aiuta a evitare che ogni fase resti orfana di un proprietario. Il SOC gestisce il monitoraggio e la risposta agli incidenti; gli amministratori cloud sono responsabili della configurazione tecnica di IdP e PAM; l’HR fornisce i segnali di ingresso, cambio ruolo e uscita; il responsabile GDPR valida gli aspetti di trattamento dati; i proprietari di servizio approvano i permessi specifici per le loro applicazioni.

Le attività di emergenza vanno chiuse nei primi 30 giorni, il rollout di MFA e IdP tra 30 e 90 giorni, mentre PAM e automazione richiedono in genere 90-180 giorni per un’azienda di medie dimensioni. Chi vuole una sequenza già strutturata per l’implementazione tecnica può appoggiarsi ai 7 passi chiave della checklist sicurezza cloud elaborata da Securityhub.

Quali sono le basi tecniche dell’autenticazione cloud?

MFA, SSO e autenticazione passwordless non sono sinonimi, e confonderli porta a scelte implementative sbagliate. L’MFA richiede almeno due fattori distinti (qualcosa che si conosce, si possiede o si è) per confermare l’identità; il Single Sign-On (SSO) permette di autenticarsi una sola volta per accedere a più applicazioni federate; l’autenticazione passwordless elimina del tutto la password a favore di chiavi crittografiche, token biometrici o dispositivi hardware.

MFA dovrebbe essere obbligatoria senza eccezioni per tutte le console di gestione cloud, per gli account con privilegi amministrativi e per l’accesso da reti non aziendali. Per gli amministratori con accesso alle console più critiche, un token hardware (tipo FIDO2) resiste meglio a phishing e SIM swapping rispetto a un semplice codice via SMS o app authenticator.

• SAML resta la scelta più diffusa per applicazioni legacy e ambienti enterprise che devono federarsi con Active Directory tradizionale.
• OIDC (OpenID Connect), costruito su OAuth 2.0, è preferibile per applicazioni moderne, API e architetture cloud native.
• SCIM automatizza il provisioning: quando un utente viene creato o modificato nell’IdP, gli attributi si propagano automaticamente alle applicazioni collegate, senza intervento manuale.

L’integrazione con un Identity Provider centrale richiede di mappare correttamente i claim, cioè gli attributi che l’IdP trasmette all’applicazione (ruolo, dipartimento, livello di autorizzazione) e su cui si basano le policy di accesso. Un mapping incompleto è una delle cause più frequenti di permessi troppo ampi assegnati per default.

Un consiglio: imposta timeout di sessione più aggressivi per le console di amministrazione rispetto alle applicazioni operative standard. Quindici minuti di inattività su una console con privilegi elevati sono ragionevoli; sullo stesso limite per un’applicazione di reporting rischi solo di irritare gli utenti senza guadagno di sicurezza reale.

RBAC o ABAC: quale modello di autorizzazione scegliere?

RBAC (Role-Based Access Control) assegna i permessi in base al ruolo organizzativo dell’utente: un contabile ha accesso al sistema finanziario, un amministratore di sistema alle console cloud. È il modello più semplice da implementare e da spiegare a un auditor, ed è la scelta giusta per la maggior parte delle PMI con strutture organizzative stabili.

ABAC (Attribute-Based Access Control) valuta invece un insieme di attributi al momento della richiesta: chi sta chiedendo l’accesso, da dove, a che ora, su quale risorsa. È più granulare ma anche più complesso da progettare e testare, e conviene solo quando servono policy dinamiche, ad esempio limitare l’accesso a dati sensibili solo durante l’orario lavorativo e da reti aziendali riconosciute.

• RBAC funziona bene quando i ruoli sono stabili e ben definiti, e la priorità è la semplicità di gestione e audit.
• ABAC è preferibile quando le condizioni di accesso cambiano frequentemente in base al contesto (geolocalizzazione, dispositivo, sensibilità del dato).
• Un approccio misto, RBAC come base e ABAC per eccezioni puntuali, è spesso il compromesso più pragmatico.

Il principio del minimo privilegio impone che ogni identità abbia solo i permessi strettamente necessari per svolgere le proprie funzioni, non un grammo di più. Il problema più diffuso è il privilege creep: un dipendente cambia ruolo tre volte in due anni e accumula i permessi di ogni posizione precedente, perché nessuno li revoca quando non servono più.

Tra gli anti-pattern più comuni ci sono l’assegnazione di ruoli “amministratore” generici per comodità, l’uso di account condivisi tra più persone (che rende impossibile attribuire un’azione a un individuo specifico) e la creazione di eccezioni “temporanee” mai più revocate. Testare periodicamente le policy con simulazioni di permission gap, verificando cioè se un utente può accedere a risorse che non dovrebbe, è l’unico modo concreto per scoprire questi problemi prima di un auditor esterno.

Come gestire gli accessi privilegiati con il PAM

Gli account con privilegi elevati sono il bersaglio preferito di ogni attaccante, perché un solo account amministrativo compromesso vale più di decine di account standard. Un sistema PAM ben progettato riduce drasticamente questa esposizione attraverso controlli specifici, distinti da quelli applicati agli utenti ordinari.

• Vaulting delle credenziali: le password degli account privilegiati non sono mai conosciute dagli utenti, ma custodite in un archivio cifrato e recuperate solo al momento dell’uso.
• Rotazione automatica: le credenziali privilegiate cambiano periodicamente o dopo ogni utilizzo, riducendo la finestra di validità di una credenziale rubata.
• Accesso just in time (JIT): i privilegi elevati vengono concessi solo per la durata necessaria a completare un’attività, poi revocati automaticamente.
• Registrazione e riproduzione delle sessioni: ogni sessione privilegiata viene tracciata integralmente, permettendo di ricostruire esattamente cosa è stato fatto in caso di incidente.
• Workflow di approvazione: l’accesso a risorse particolarmente sensibili richiede un’approvazione formale, non solo l’inserimento di una password.

Gli account di servizio e le chiavi API meritano la stessa disciplina delle credenziali umane. La gestione delle credenziali non umane richiede vaulting, rotazione e scoping degli accessi: scrivere una chiave API direttamente nel codice sorgente è una delle vulnerabilità più frequenti e più facilmente evitabili nelle architetture cloud moderne.

Un consiglio: tieni un registro separato, aggiornato mensilmente, dei soli account con privilegi elevati. Un auditor ISO 27001 chiederà quasi certamente di vederlo, e ricostruirlo al momento dell’audit richiede giorni di lavoro che un aggiornamento mensile evita del tutto.

Per dimostrare la conformità durante un audit ISO 27001 o ISO 27017 servono prove concrete: l’implementazione PAM efficace richiede vaulting, rotazione automatica, registrazione delle sessioni e integrazione con i sistemi HR per garantire che il ciclo di vita degli account privilegiati segua automaticamente i cambiamenti organizzativi. L’elenco degli account privilegiati, i report delle sessioni registrate e le evidenze di MFA attiva sono i tre documenti che un revisore chiederà quasi sempre.

Come gestire il ciclo di vita delle identità: joiner, mover, leaver

Il momento più pericoloso nella vita di un’identità digitale non è la creazione, ma la transizione: un cambio di ruolo o un’uscita dall’azienda che non si traduce immediatamente in una modifica dei permessi. Il modello joiner/mover/leaver collega ogni evento del ciclo lavorativo a un’azione automatica sugli accessi.

Quando un nuovo dipendente entra in azienda (joiner), il sistema HR genera un segnale che attiva automaticamente la creazione dell’account con i permessi corrispondenti al ruolo assegnato, senza intervento manuale dell’IT. Quando cambia funzione (mover), lo stesso segnale dovrebbe rimuovere i vecchi permessi prima di assegnare i nuovi, non semplicemente aggiungerli sopra quelli esistenti. Quando lascia l’azienda (leaver), la disattivazione dell’account deve avvenire lo stesso giorno, non “alla prima occasione utile”.

• Gli account temporanei per fornitori esterni devono avere una scadenza automatica impostata al momento della creazione, non lasciata alla memoria di chi li ha creati.
• Ogni accesso esterno dovrebbe richiedere l’approvazione del proprietario dell’asset coinvolto, non solo un’autorizzazione IT generica.
• L’offboarding sicuro prevede la revoca immediata dei token attivi, la rotazione delle credenziali condivise che l’utente potrebbe aver conosciuto e una verifica degli accessi residui su tutti i sistemi collegati.

Le revisioni periodiche degli accessi devono coinvolgere i manager di linea, non solo l’IT: senza questa evidenza documentata, la conformità ISO 27001 può risultare compromessa anche quando i controlli tecnici funzionano correttamente. Un manager che certifica trimestralmente i permessi del proprio team individua discrepanze che un sistema automatizzato, da solo, non può cogliere.

Cosa loggare e come trasformare i log in evidenza di audit

Un sistema di logging che registra tutto senza criterio è quasi peggio di uno che non registra nulla: produce rumore che nasconde i segnali importanti. Gli eventi da tracciare con priorità sono quelli che riguardano direttamente l’identità e i privilegi, non ogni singola richiesta HTTP.

• I log devono essere protetti da modifica e cancellazione non autorizzata, anche da parte di chi ha privilegi amministrativi sul sistema che li genera.
• La retention va calibrata sui requisiti di ISO 27001, ISO 27017 e NIS2, che richiedono tracciabilità sufficiente a ricostruire un incidente a distanza di mesi.
• Un playbook di incident response per identità compromesse dovrebbe includere: sospensione immediata dell’account, revoca dei token attivi, analisi dei log delle ultime 72 ore e notifica ai referenti coinvolti.

Un consiglio: configura alert automatici per accessi fuori orario lavorativo o da geolocalizzazioni nuove rispetto allo storico dell’utente. Sono i due segnali più semplici da implementare e tra i più efficaci per intercettare un account compromesso prima che venga usato per movimenti laterali.

Come si mappano gli accessi cloud a ISO 27001, ISO 27017, GDPR e NIS2

Ogni controllo tecnico descritto finora corrisponde a un requisito specifico negli standard di riferimento, e conoscere questa mappatura è quello che trasforma un buon sistema tecnico in un sistema certificabile.

ENISA elenca obiettivi di sicurezza specifici che includono il controllo degli accessi e la gestione dei privilegi tra le misure minime per i fornitori digitali, un riferimento utile per costruire la mappatura interna verso NIS2. Per le aziende che operano in contesti regolati italiani, il manuale AGID sull’abilitazione al cloud fornisce indicazioni operative sull’integrazione tra amministrazioni e provider cloud, applicabili per analogia anche a molte PMI del settore privato.

Sul fronte della responsabilità condivisa, ogni provider cloud gestisce la sicurezza “del” cloud (infrastruttura fisica, isolamento hardware), mentre l’azienda cliente resta responsabile della sicurezza “nel” cloud, cioè configurazione degli accessi, gestione delle identità e classificazione dei dati. Chiedere al proprio provider evidenza formale sull’isolamento del tenant e sulla capacità di supportare audit esterni è un passaggio che troppe aziende saltano, dando per scontato che sia già incluso nel contratto. Chi vuole approfondire i criteri di selezione del provider su questi aspetti può consultare la guida di Securityhub su fornitori cloud e sicurezza dati.

Quali strumenti servono per governare gli accessi cloud

Non esiste un singolo prodotto che risolve la gestione degli accessi: serve un insieme di categorie di strumenti che lavorano insieme, ognuna con un compito preciso.

• Identity Provider / SSO: il punto centrale di autenticazione federata, da cui dipendono MFA e mapping dei claim verso le applicazioni.
• PAM: vaulting, rotazione e accesso just in time per gli account con privilegi elevati.
• Identity Governance & Administration (IGA): gestisce il ciclo di vita completo delle identità e automatizza le certificazioni periodiche degli accessi.
• Secret Management: custodisce chiavi API, token e credenziali applicative separatamente dalle credenziali umane.
• SIEM/CSPM: raccoglie i log per correlazione degli eventi e individua configurazioni cloud non conformi.
• Strumenti di provisioning basati su SCIM: sincronizzano automaticamente gli attributi delle identità tra HR, IdP e applicazioni.

Nella scelta di ciascuno strumento contano soprattutto l’integrazione nativa con il sistema HR esistente, il supporto effettivo di SAML, OIDC e SCIM (non solo dichiarato in scheda tecnica, ma verificato in un ambiente di test), la capacità di generare report pronti per un audit senza rielaborazione manuale, e la scalabilità in termini di SLA per l’accesso alle console più critiche.

Per evitare il vendor lock-in delle identità, la scelta architetturale più solida è mantenere una directory di identità sincronizzata ma indipendente dal singolo cloud provider, con claim mapping portabile tra ambienti. Un’azienda che federa le proprie identità direttamente e solo dentro l’ecosistema di un singolo provider rischia di dover ricostruire da zero l’intero sistema di autorizzazione se decide di cambiare fornitore o di adottare un’architettura multi cloud. Le best practice su registri centralizzati e revisioni periodiche indicate da NIS2Lab confermano che la portabilità dei dati identitari è un requisito, non un’opzione accessoria.

Quali checklist e template servono davvero alle PMI italiane

Una PMI con risorse limitate non ha bisogno di un sistema perfetto, ma di un sistema minimo che funzioni davvero e che possa essere dimostrato a un auditor senza dover ricostruire tutto all’ultimo momento.

• Inventario identità aggiornato, con distinzione chiara tra account standard e privilegiati.
• Procedure documentate di provisioning e deprovisioning collegate agli eventi HR.
• Template di revisione periodica degli accessi, con firma del manager di linea responsabile.
• Registro degli account privilegiati, aggiornato con frequenza almeno mensile.
• Playbook di incident response specifico per identità compromesse, testato almeno una volta.

Una clausola di policy MFA tipica, da inserire nel proprio documento di sicurezza, può essere formulata così: «L’autenticazione a più fattori è obbligatoria per tutti gli accessi alle console di amministrazione cloud e per ogni account con privilegi elevati, senza eccezioni concesse su base individuale». Una riga di RACI semplificata per il provisioning potrebbe indicare: HR (segnalatore dell’evento), IT (esecutore tecnico), responsabile GDPR (validatore per i dati personali coinvolti).

Integrare questi documenti nel proprio Sistema di Gestione della Sicurezza delle Informazioni (ISMS) è quello che li trasforma da buone intenzioni a evidenza verificabile per ISO 27001 e ISO 27017. Per le PMI con budget limitato, la priorità di investimento va sempre a MFA e logging centralizzato: sono i due controlli con il miglior rapporto costo/beneficio, perché riducono immediatamente il rischio più alto con un investimento tecnico contenuto. La checklist sicurezza dati cloud elaborata da Securityhub offre un modello di partenza già strutturato per questo tipo di percorso.

Perché gli errori sulla gestione degli accessi si ripetono sempre uguali

Nella pratica delle aziende italiane, gli errori nella gestione degli accessi cloud si ripetono con una regolarità quasi sorprendente. Il primo, e il più diffuso, è l’account condiviso: due o tre persone usano le stesse credenziali amministrative “per comodità”, e quando succede un incidente nessuno può dire con certezza chi ha fatto cosa. È un problema di attribuzione, non solo di sicurezza, e mina qualsiasi tentativo di audit serio.

Molte aziende compilano un foglio di revisione una volta all’anno, in fretta, senza che nessun manager verifichi davvero se quei permessi hanno ancora senso. Il risultato è un documento che esiste ma non protegge nulla, e che un auditor esperto individua in pochi minuti.

Il terzo, più insidioso, è la gestione manuale dei permessi in aziende che sono cresciute troppo velocemente per continuare a gestirla così. Un’azienda con quindici dipendenti può permettersi di assegnare i permessi a mano; un’azienda con cento persone e cinque servizi cloud diversi, no. Chi continua a farlo manualmente sta scommettendo che nessuno si accorgerà del ritardo tra un cambio di ruolo e l’aggiornamento dei permessi corrispondenti, e prima o poi perde quella scommessa.

Il modo più efficace per evitare questi tre errori non è comprare più strumenti, ma imporre disciplina sui processi esistenti: automatizzare il collegamento tra HR e sistema di identità, programmare revisioni trimestrali per gli account privilegiati (non annuali) e vietare per policy scritta gli account condivisi, con controlli tecnici che ne impediscano la creazione. Per chi deve preparare la documentazione da presentare a un auditor o a un cliente che chiede prove di conformità, la regola più utile è semplice: ogni controllo tecnico deve avere una prova scritta associata, prodotta nel momento in cui il controllo viene eseguito, non ricostruita a posteriori quando arriva la richiesta.

Come Securityhub supporta l’implementazione della gestione accessi cloud

Costruire un sistema di gestione degli accessi cloud conforme a ISO 27001 e ISO 27017 richiede competenze specifiche che raramente sono disponibili internamente in una PMI, specialmente quando serve tradurre i controlli tecnici in documentazione che un auditor accetta senza riserve. Securityhub affianca i responsabili IT proprio in questo passaggio, quello più delicato: trasformare MFA, PAM e procedure di provisioning già attivi in un fascicolo di evidenze pronto per la certificazione.

Il percorso di supporto comprende un assessment del divario rispetto ai requisiti ISO 27001 e ISO 27017, l’assistenza nell’implementazione tecnica di PAM e automazione del provisioning, audit interni condotti prima della verifica ufficiale e pacchetti di formazione dedicati sia agli amministratori cloud sia agli utenti finali.

Chi vuole capire in che punto del percorso si trova la propria azienda può partire dalla pagina sui passaggi per la certificazione ISO 27001 e richiedere una valutazione preliminare gratuita tramite la pagina dedicata alla certificazione ISO 27001 di Securityhub.

Fonti

Per chi vuole verificare direttamente i requisiti normativi citati in questa guida, alcune fonti ufficiali meritano una lettura diretta prima di redigere policy interne o rispondere a un cliente che chiede evidenze di conformità.

• Manuale di abilitazione al cloud – AGID

Chi affronta per la prima volta un audit dovrebbe partire dalle fonti ISO e AGID per capire il linguaggio richiesto dai revisori, per poi usare le linee guida ENISA per calibrare le misure sulla dimensione reale della propria azienda. Per la gestione documentale HR collegata al provisioning, una risorsa utile complementare è la guida ai rimborsi spese dipendenti, che aiuta a inquadrare i processi amministrativi collegati ai segnali di ingresso e uscita del personale.

Questo articolo fornisce informazioni generali e non sostituisce il parere di un avvocato qualificato. Consulta un professionista legale qualificato riguardo al tuo caso specifico prima di agire in base a questo contenuto.

Raccomandati

• Procedura di valutazione dei rischi cloud: guida per responsabili IT – Security Hub
• Processo policy sicurezza cloud: guida completa alla gestione – Security Hub
• Checklist sicurezza dati cloud: guida operativa per PMI italiane – Security Hub
• Popolari Standard Sicurezza Cloud: Guida Completa – Security Hub