Segregazione dei dati: guida pratica per responsabili IT
La segregazione dei dati è la pratica di separare e controllare l’accesso alle informazioni in base alla loro sensibilità, proprietà e scopo: ogni insieme di dati è accessibile solo agli utenti, sistemi o processi che ne hanno una necessità documentata. Non va confusa con la Segregation of Duties (SoD), che riguarda invece la separazione dei compiti tra persone diverse per prevenire frodi ed errori. La SoD risponde alla domanda «chi può fare cosa»; la segregazione dei dati risponde a «chi può vedere o modificare quali informazioni». Entrambi i principi trovano riferimento in standard come ISO 27001 e nel Regolamento Generale sulla Protezione dei Dati (GDPR), e l’Agenzia per la Cybersicurezza Nazionale (ACN) li tratta come pilastri distinti ma complementari della gestione del rischio informatico.
Punti chiave
La segregazione dei dati è efficace solo se costruita su classificazione documentata, ruoli definiti e processi di revisione periodica: la tecnologia da sola non è sufficiente.
| Punto | Dettagli |
|---|---|
| Classificazione prima di tutto | Senza classificare i dati per sensibilità, nessun controllo di accesso può essere applicato correttamente. |
| Least privilege come regola base | Ogni ruolo deve avere accesso solo ai dati strettamente necessari alla sua funzione, verificato periodicamente. |
| Controlli compensativi dove serve | Dove la segregazione completa non è praticabile, documentare dual authorization, revisione post-transazione e logging indipendente. |
| Riferimenti normativi obbligatori | GDPR (art. 25 e 32) e ISO 27001 (Annex A) sono i riferimenti principali per audit e conformità in Italia. |
| Securityhub per l’implementazione | Securityhub supporta le aziende italiane nell’assessment, nella documentazione ISMS e nella preparazione alla certificazione ISO 27001. |
Indice
- Cos’è, tecnicamente, la segregazione dei dati?
- SoD e segregazione dei dati: qual è la differenza concreta?
- Perché la segregazione dei dati conta per rischio, conformità e audit
- Come implementare la segregazione dei dati in azienda
- Esempi pratici: procurement, ERP/SAP e ambienti di sviluppo
- Quali rischi si nascondono in un’implementazione mal gestita?
- Come verificare e mantenere la segregazione nel tempo
- Come integrare la segregazione dei dati in un ISMS ISO 27001
- Conclusioni e piano d’azione a 90 giorni
- La segregazione dei dati vista da chi lavora sul campo
- Securityhub per la segregazione dei dati e la certificazione ISO 27001
- Risorse utili e normative di riferimento
- Fonti
Cos’è, tecnicamente, la segregazione dei dati?
La segregazione dei dati limita l’impatto di un breach circoscrivendo il perimetro di ciò che un attaccante, o un utente interno non autorizzato, può raggiungere. Le modalità tecniche principali sono quattro.
- Segregazione fisica: i dati risiedono su hardware distinto, storage separato o data center differenti. Usata per dati classificati o soggetti a requisiti normativi stringenti, garantisce isolamento assoluto ma comporta costi infrastrutturali elevati.
- Segregazione logica: i dati condividono la stessa infrastruttura ma sono separati tramite controlli software: database distinti, schemi separati, Virtual Machine o container con policy di accesso dedicate. È la modalità più diffusa in ambienti cloud e multi tenant.
- Segregazione di rete: VLAN, firewall interni e micro-segmentazione impediscono che il traffico tra segmenti diversi avvenga senza autorizzazione esplicita. Un server che ospita dati finanziari non dovrebbe comunicare direttamente con workstation di sviluppo.
- Segregazione a livello applicativo e crittografico: chiavi di cifratura distinte per dataset diversi (key management separato), Data Loss Prevention (DLP) per bloccare l’esfiltrazione, e controlli di accesso a livello di campo o riga nei database.
I controlli tecnici che rendono operativa la segregazione includono la classificazione dei dati (prerequisito indispensabile), i sistemi di Identity & Access Management (IAM) con modelli RBAC (Role-Based Access Control) o ABAC (Attribute-Based Access Control), il principio del minimo privilegio, la crittografia dei dati a riposo e in transito, e il logging immodificabile degli accessi. Senza classificazione, non è possibile sapere quali dati segregare con quale priorità: è il punto di partenza, non un’aggiunta successiva.
Un consiglio: In ambienti multi-tenant, la gestione separata delle chiavi crittografiche per ciascun tenant è spesso più efficace di qualsiasi isolamento logico basato solo su permessi: anche in caso di compromissione dell’account di un tenant, i dati degli altri rimangono cifrati con chiavi inaccessibili.
SoD e segregazione dei dati: qual è la differenza concreta?
I due concetti si sovrappongono nella terminologia ma operano su piani diversi. ISACA descrive la SoD come il principio che separa autorizzazione, esecuzione e registrazione di un’operazione tra attori distinti, con l’obiettivo primario di ridurre il rischio di frode e di errore non rilevato. La segregazione dei dati si applica invece agli insiemi informativi stessi: chi accede a quali record, tabelle, file o ambienti.
I due concetti si intersecano quando un ruolo SoD mal disegnato consente a un singolo utente di accedere a dataset che non dovrebbe vedere, oppure quando la segregazione dei dati non è allineata alla matrice dei compiti e un operatore può leggere log che dovrebbe solo generare.
| Dimensione | Segregation of Duties (SoD) | Segregazione dei dati |
|---|---|---|
| Oggetto | Compiti e transazioni | Insiemi di dati e accessi |
| Obiettivo principale | Prevenire frodi ed errori | Limitare esposizione e breach |
| Controlli tipici | Matrice SoD, dual approval, workflow | IAM, RBAC/ABAC, crittografia, DLP |
| Esempio pratico | Chi crea un fornitore non può approvare il pagamento | Chi approva ordini non accede ai dati salariali |
| Standard di riferimento | ISACA, COSO, ISO 27001 Annex A | ISO 27001, GDPR |
La distinzione ha conseguenze pratiche: un’azienda può avere una SoD ben strutturata e tuttavia lasciare dataset sensibili accessibili a ruoli che non ne hanno bisogno, semplicemente perché la classificazione dei dati non è mai stata fatta. I due controlli vanno progettati insieme, non in sequenza.
Perché la segregazione dei dati conta per rischio, conformità e audit
Il GDPR impone misure tecniche e organizzative adeguate a proteggere i dati personali (art. 25 e art. 32): la segregazione è una delle misure più dirette per soddisfare il principio di minimizzazione dell’accesso. ISO 27001, nell’Annex A, richiede controlli espliciti su accesso alle informazioni, separazione degli ambienti e gestione dei privilegi. Per i fornitori SaaS multi-tenant, ISO 27001 richiede controlli che garantiscano la separazione logica o fisica dei dati dei tenant, rendendo la segregazione una misura di compliance non opzionale.
Dal punto di vista della gestione del rischio, la segregazione riduce tre vettori critici: la superficie d’attacco disponibile a un account compromesso, il volume di dati esfiltrabili in un singolo incidente, e il rischio di cross-tenant leakage in ambienti condivisi. Il Verizon Data Breach Investigations Report identifica configurazioni errate e privilegi eccessivi tra le cause più frequenti di perdita di dati: la segregazione riduce direttamente entrambi questi vettori.
Gli auditor ISO 27001 cercano evidenze concrete: una policy di accesso ai dati documentata, un registro dei ruoli e dei permessi assegnati, log di accesso conservati in modo immodificabile, e prove di access review periodiche. Non basta dichiarare di applicare il minimo privilegio: occorre dimostrarlo con record verificabili. La sicurezza dei dati si costruisce su questi strati documentali, non solo su controlli tecnici.
Come implementare la segregazione dei dati in azienda
Un’implementazione efficace richiede passi organizzativi e tecnici coordinati. La tecnologia da sola non è sufficiente: l’ACN sottolinea che l’Identity & Access Management è l’insieme di processi, tecnologie e controlli per garantire accessi autorizzati, e che la gestione dell’accesso è il meccanismo fondamentale per applicare la segregazione in modo sostenibile.
- Mappatura degli asset e dei flussi informativi: identificare tutti i dataset, i sistemi che li trattano e i flussi tra di essi. Senza questa mappa, qualsiasi controllo successivo è incompleto.
- Classificazione dei dati: assegnare a ogni dataset un livello di sensibilità (es. pubblico, interno, riservato, segreto) e un owner responsabile. La classificazione dei dati sensibili è il prerequisito per qualsiasi decisione di accesso.
- Disegno dei ruoli e delle responsabilità: definire ruoli funzionali con permessi minimi necessari (least privilege), evitando ruoli generici o ereditati da configurazioni storiche.
- Implementazione dei controlli tecnici: configurare IAM con RBAC o ABAC, abilitare MFA per tutti gli accessi a dati riservati, segmentare la rete, cifrare i dati a riposo e in transito, attivare DLP e logging immodificabile.
- Formalizzazione delle policy: documentare le regole di accesso, i criteri di classificazione, le procedure di provisioning e deprovisioning, e il processo di gestione delle eccezioni.
- Revisione e test: eseguire un access review iniziale per identificare permessi in eccesso, verificare che i controlli tecnici funzionino come atteso, e documentare i risultati per l’audit.
Un consiglio: Per gli accessi temporanei a dati sensibili, adottare il modello Just-In-Time (JIT): l’accesso viene concesso per un periodo definito, con approvazione esplicita, e revocato automaticamente alla scadenza. Questo elimina il rischio degli accessi permanenti non revocati, che sono tra le eccezioni più difficili da tracciare in un audit.
Esempi pratici: procurement, ERP/SAP e ambienti di sviluppo
Procurement e ciclo ordine-pagamento
Nel processo di acquisto, i dati coinvolti includono l’anagrafica fornitori, gli ordini di acquisto, le fatture e i dati di pagamento. Una corretta segregazione prevede che chi crea o modifica l’anagrafica fornitore non abbia accesso ai dati di pagamento, e che chi approva gli ordini non possa modificare i record del fornitore. A livello tecnico, questo si traduce in ruoli distinti nel sistema ERP con accesso a tabelle e transazioni specifiche, log separati per ciascuna operazione, e alert automatici per operazioni che attraversano i confini di ruolo.
Ambienti ERP e SAP
In contesti SAP, la segregazione dei ruoli è critica perché le autorizzazioni sono granulari e spesso accumulate nel tempo. Un utente che ha ricevuto accesso a una transazione per un progetto specifico può ritrovarsi, anni dopo, con permessi su tabelle finanziarie sensibili che non usa più. La soluzione passa per role mining periodico, revisione delle autorizzazioni attive, e isolamento delle tabelle contenenti dati salariali o finanziari in schemi separati con accesso ristretto.
Sviluppo software e promozione in produzione
L’ambiente di sviluppo non deve mai contenere dati di produzione reali, e gli sviluppatori non devono avere accesso diretto all’ambiente di produzione. La pipeline CI/CD deve gestire le credenziali e i segreti tramite vault dedicati (es. HashiCorp Vault), con accesso controllato e auditato. La promozione del codice in produzione deve richiedere approvazione separata da chi ha scritto il codice, applicando SoD anche al ciclo di sviluppo. Questo riduce sia il rischio di errori non rilevati sia la superficie di attacco in caso di compromissione di un account sviluppatore.
Quali rischi si nascondono in un’implementazione mal gestita?
L’implementazione della segregazione porta con sé criticità concrete che vanno anticipate.
- Accumulo di accessi (access creep): gli utenti accumulano permessi nel tempo, soprattutto dopo cambi di ruolo o progetti temporanei. Senza deprovisioning automatico, i permessi storici rimangono attivi indefinitamente.
- Ruoli troppo permissivi: ruoli generici creati per comodità operativa (es. «admin» o «superuser») annullano qualsiasi logica di segregazione. Ogni ruolo deve avere un perimetro definito.
- Eccezioni non documentate: un accesso temporaneo concesso verbalmente e mai revocato è un’eccezione permanente non tracciata. Gli auditor le cercano attivamente.
- Over-segmentation: una segregazione eccessiva può rendere i processi operativi impraticabili, spingendo gli utenti a trovare workaround informali che aggirano i controlli. Il trade-off tra sicurezza e operatività va misurato e documentato.
- Impatti su ambienti cloud multi-tenant: in assenza di isolamento logico adeguato, un errore di configurazione può esporre dati di un tenant a un altro. La protezione dei dati nelle PMI SaaS richiede attenzione specifica a questo rischio.
Le mitigazioni più efficaci sono l’automazione del provisioning e deprovisioning tramite IAM, la revisione periodica degli accessi (almeno semestrale per i ruoli critici), e la documentazione formale di ogni eccezione con scadenza e approvazione esplicita. Quando la segregazione perfetta non è praticabile, gli auditor accettano controlli compensativi documentati: revisione post-transazione, dual authorization sopra soglie definite, e logging indipendente.
Come verificare e mantenere la segregazione nel tempo
La segregazione non è un progetto con una data di fine: è un processo continuo. Gli strumenti principali per mantenerla efficace nel tempo sono la SoD matrix, le metriche di controllo e i processi di audit.
Una SoD matrix mappa attività, attori e permessi in una griglia che evidenzia i conflitti: ogni cella che incrocia due attività incompatibili assegnate allo stesso ruolo è un rischio documentato. La matrice va aggiornata a ogni modifica organizzativa o di sistema.
| Metrica | Descrizione | Frequenza di rilevazione |
|---|---|---|
| % di eccezioni attive | Rapporto tra eccezioni documentate e totale accessi privilegiati | Mensile |
| Tempo medio di revoca accesso | Giorni tra la cessazione di un ruolo e la revoca dei permessi associati | Mensile |
| Numero di privilegi elevati attivi | Conteggio degli account con accesso amministrativo o a dati riservati | Settimanale |
| Esito access review | Percentuale di accessi confermati vs. revocati nell’ultima revisione | Semestrale |
Il logging immodificabile è il requisito tecnico che rende verificabili tutte le altre misure: senza log che non possano essere alterati dall’utente che li genera, qualsiasi evidenza di audit è contestabile. L’integrazione tra IAM, SIEM e strumenti di access review automatizzati consente di rilevare anomalie in tempo reale e di produrre report pronti per l’audit senza intervento manuale.
Come integrare la segregazione dei dati in un ISMS ISO 27001
Integrare la segregazione dei dati in un Sistema di Gestione della Sicurezza delle Informazioni (ISMS) richiede che i controlli non restino isolati ma siano collegati alla documentazione formale richiesta da ISO 27001.
Il punto di partenza è l’asset register: ogni dataset deve essere censito con il suo livello di classificazione, l’owner, i sistemi che lo trattano e i controlli di accesso applicati. Questo registro è la base su cui costruire il resto della documentazione.
Nel Statement of Applicability (SoA), i controlli relativi alla segregazione vanno mappati esplicitamente: controllo degli accessi (A.9), crittografia (A.10), sicurezza delle operazioni (A.12) e sicurezza delle comunicazioni (A.13) sono i riferimenti principali nell’Annex A. Per ciascuno, il SoA deve indicare se il controllo è applicato, con quale modalità e con quale evidenza.
La documentazione operativa minima comprende: una policy di controllo degli accessi, procedure di provisioning e deprovisioning, un registro delle eccezioni con scadenze e approvazioni, e i log di access review. Per le PMI, l’approccio più efficace è priorizzare i processi critici (quelli che trattano dati personali, finanziari o segreti commerciali) e applicare i controlli più stringenti solo dove il rischio lo giustifica. Estendere la stessa granularità a tutti i sistemi fin dall’inizio è spesso controproducente.
Un consiglio: Per le PMI che si avvicinano alla certificazione ISO 27001, un approccio minimo ma documentato vale più di un sistema complesso non tracciabile. Tre ruoli ben definiti con permessi verificabili sono più difendibili in audit di dieci ruoli generici con accessi sovrapposti.
Conclusioni e piano d’azione a 90 giorni
Le azioni immediate, da completare entro le prime due settimane, sono tre: censire i dataset critici e assegnare un owner, bloccare gli accessi amministrativi non necessari, e avviare una revisione degli account con privilegi elevati.
- Giorni 1–30: completare la mappatura degli asset informativi e la classificazione dei dati per livello di sensibilità. Identificare i conflitti di accesso più critici tramite una prima SoD matrix.
- Giorni 31–60: implementare o rafforzare i controlli IAM (RBAC/ABAC, MFA, least privilege). Formalizzare la policy di accesso e il processo di gestione delle eccezioni. Avviare il logging immodificabile per i sistemi critici.
- Giorni 61–90: eseguire il primo access review formale, documentare i risultati, revocare gli accessi in eccesso. Integrare i controlli nel SoA dell’ISMS e pianificare la prima revisione semestrale.
Per i successivi 6–12 mesi, le priorità sono: automatizzare il provisioning e deprovisioning tramite IAM, estendere la classificazione a tutti i sistemi, implementare DLP per i canali di uscita dei dati, e condurre un audit interno sulla segregazione prima della verifica esterna.
La segregazione dei dati vista da chi lavora sul campo
Uno degli errori più ricorrenti che si osserva nelle aziende italiane non è la mancanza di tecnologia: è la mancanza di classificazione. Le organizzazioni investono in IAM, firewall e SIEM, poi scoprono in audit che nessuno ha mai deciso formalmente quali dati siano «riservati» e quali «interni». Senza quella distinzione, qualsiasi controllo tecnico è costruito su fondamenta instabili.
Le eccezioni esistono in ogni organizzazione: il problema non è la loro esistenza, ma la loro invisibilità.
La segregazione dei dati non è un progetto da completare prima della certificazione e poi dimenticare. È un processo che richiede manutenzione continua, revisioni periodiche e una cultura organizzativa in cui l’accesso ai dati è considerato un privilegio da giustificare, non un diritto acquisito. Chi affronta questo lavoro con metodo, partendo dalla classificazione e costruendo i controlli per strati, ottiene risultati verificabili e sostenibili nel tempo.
Securityhub per la segregazione dei dati e la certificazione ISO 27001
Securityhub affianca le aziende italiane nell’implementazione concreta della segregazione dei dati all’interno di un ISMS certificato ISO 27001. Il percorso parte da un assessment iniziale che identifica i gap di accesso e classificazione, prosegue con la definizione dei ruoli, la documentazione delle policy e l’integrazione dei controlli tecnici, e si conclude con la preparazione all’audit di certificazione.
I servizi includono: assessment SoD e data segregation, supporto all’implementazione IAM, redazione della documentazione ISMS (policy, SoA, registro eccezioni) e affiancamento durante le verifiche di terza parte. Per chi parte da zero, Securityhub propone un workshop di scoping iniziale per definire perimetro e priorità in mezza giornata. Per avviare il percorso verso la certificazione ISO 27001 o per richiedere un audit rapido sulla segregazione dei dati, è possibile contattare direttamente il team di Securityhub.
Risorse utili e normative di riferimento
Le principali risorse citate in questo articolo, utili per approfondimento e verifica operativa:
- ISO 27001 (Annex A): standard internazionale per i sistemi di gestione della sicurezza delle informazioni; definisce i controlli su accesso, crittografia e separazione degli ambienti. Disponibile tramite UNI e ISO.
- GDPR (Regolamento UE 2016/679): artt. 25 e 32 stabiliscono i requisiti di protezione by design e misure tecniche adeguate. Testo ufficiale disponibile su EUR-Lex.
- ACN – Agenzia per la Cybersicurezza Nazionale: dominio Identity & Access Management con linee guida operative su IAM e segregazione dei compiti.
- ISACA Journal: guida step-by-step alla SoD con modelli di role mining e identity governance.
- Securityhub – risorse interne: guida alla sicurezza del dato, classificazione dei dati sensibili, policy di sicurezza per aziende certificate e misure tecniche ISO 27018.
Fonti
- Domini della cybersicurezza – Identity and access management
- A step‑by‑step SoD implementation guide — ISACA Journal
- Understanding The Importance Of Data Segregation And Access Control
Raccomandati
