Il principio del need to know è raccomandato da tutti gli standard e prescritto da numerose normative.
Per comprenderne l’importanza basti considerare che, unitamente a quanto prescritto dall’art. 32.4 (formazione in materia di sicurezza) del GDPR, è l’unica misura di sicurezza obbligatoriamente prevista dal Regolamento europeo (art. 25.2, così detta privacy by default).
Tale articolo introduce il principio di minimizzazione, applicabile a diversi aspetti del trattamento dei dati e vincola i titolari a effettuare i trattamenti di dati personali utilizzandone solo la quantità strettamente necessaria, limitando inoltre il numero di soggetti autorizzati al loro trattamento (in pratica questo è tecnicamente fattibile definendo adeguati profili autorizzativi).
Indice degli argomenti
Need to know, un requisito difficile da implementare
Un concetto quindi assolutamente scontato e consolidato, che tuttavia non è così semplice perseguire, salvo il caso che l’organizzazione utilizzi un sistema informativo particolarmente semplice e che faccia uso di un limitato numero di applicazioni.
In questo caso, una volta definiti i ruoli e definite le informazioni a cui tali ruoli devono accedere per poter svolgere il proprio compito, è necessario abilitare per ogni ruolo le sole applicazioni e le sole funzioni necessarie per poter svolgere tali attività.
Ma in realtà, nemmeno in questo caso tutto è così semplice.
Ad esempio, le poche applicazioni che è necessario utilizzare potrebbero non disporre di un profilo che si abbini alle esigenze di uno specifico ruolo e tecnicamente non risulta possibile configurarne uno che rispecchi effettivamente le abilitazioni teoricamente definite per esso.
I motivi di tale limitazione potrebbero essere diversi, fra i quali il fatto che i profili abilitativi sono stati creati da chi ha sviluppato l’applicazione secondo la propria esperienza e che siano, ad esempio, cablati nel codice.
Non tutte le applicazioni dispongono infatti della possibilità di definire in modo parametrico[1] cosa può fare o non può fare un profilo e quindi a quali funzioni può accedere, che operazioni può compiere sulle informazioni, quale sia il perimetro dei dati che può vedere (ad esempio in ambito bancario gli addetti una filiale vedono solo i clienti della loro filiale, per cui anche se gli addetti di tutte le filiali hanno i medesimi privilegi di accesso, possono vedere solo i dati relativi ai propri clienti).
Quanto fin qui descritto può sembrare semplice ed intuitivo, ma in realtà non è affatto così, ed anzi, la quasi totalità delle organizzazioni non dispone delle informazioni per quella che, a prima vista, sembra un’attività relativamente semplice.
Come limitare l’accesso ai dati strettamente necessari
Analizziamo nel dettaglio quanto sopra riportato.
Il primo punto riguarda la descrizione delle attività da svolgere che sono collegate al singolo ruolo, e quindi cosa, nella pratica, debba svolgere ad esempio chi si occupa del personale, o della contabilità, o della produzione.
Descrivere le attività da svolgere
La descrizione delle attività deve avere un livello di dettaglio tale da consentire di individuare quali informazioni è necessario che siano accessibili ad un determinato ruolo, e quali operazioni tale ruolo deve compiere su tali informazioni.
Devono essere quindi mappate e note le informazioni disponibili, in quali database sono presenti, quali sono le applicazioni disponibili, quali sono le funzioni presenti nelle varie applicazioni, quali sono le informazioni gestite dalle varie funzioni delle varie applicazioni.
La stessa cosa dovrebbe riguardare tutti gli altri asset indispensabili per svolgere una determinata attività, ma limitiamoci in questo contesto alle sole applicazioni, funzioni e informazioni…
Se stiamo parlando di due o tre applicazioni, tali informazioni potrebbero essere patrimonio di chi gestisce il sistema informativo e forse sono documentate in qualche manuale.
Ma se le applicazioni aumentano sarà necessario disporre di appositi database nel quale mappare tali informazioni e qui iniziano i problemi.
Abbinare le attività ai ruoli
Lo stesso discorso vale per la descrizione delle attività abbinate ai ruoli.
Forse un’organizzazioni ha un organigramma; più difficilmente troveremo un funzionigramma che descriva il compito assegnato ai vari uffici e in questo caso, di norma, la descrizione delle attività lì riportate non arriva ad un livello di dettaglio tale da comprendere a quali dati quel ruolo deve accedere.
Spesso tale carenza di informazione è giustificata dalla volontà di non voler ingessare l’organizzazione con documenti ufficiali troppo dettagliati, che potrebbero subire continue variazioni per rispecchiare fedelmente la realtà, ma al riguardo ci si scontra con lo stesso problema presente nel rispetto della normativa privacy.
Un conto è documentare nel registro delle attività di trattamento (documento ufficiale previsto da regolamento) quanto specificatamente richiesto dalla normativa, diverso è avere una analitica descrizione di come si svolgono i trattamenti, senza la quale è impossibile rispettare tutti gli altri adempimenti previsti dalla normativa.
Analogamente le organizzazioni dovrebbero avere una descrizione molto dettagliata su come si svolgono i loro processi e degli asset necessari per compierli.
Fra gli altri, in assenza di tale livello di dettaglio, è impossibile costruire un adeguato piano di resilienza e continuità operativa, requisito normativo questo sempre più richiesto dalle normative (ad esempio da DORA, che ha esteso tale requisito anche ai fornitori di banche e assicurazioni).
Quindi difficilmente chi si occupa della definizione e/o implementazione dei profili autorizzativi in un’organizzazione troverà, da un lato una descrizione sufficientemente analitica dei ruoli e, dall’altro, una mappatura delle funzioni disponibili nelle varie applicazioni, dei dati presenti nei vari database, delle funzioni disponibili nelle varie applicazioni e dei dati da queste accessibili.
La mancanza di queste informazioni rende di fatto impossibile definire in modo corretto dei profili che rispettino il requisito del minimo privilegio di accesso, in quanto è impossibile avere una chiara visione di quali siano le informazioni alle quali un determinato profilo consenta l’accesso e quali operazioni lo stesso consenta di fare sui vari dati.
Al più, sarà possibile avere una visione di questi elementi relativamente ad ogni singola applicazione da parte di quanti ne hanno la gestione tecnica ed amministrativa, ma questo di per sé non basta.
I rischi di una non coerenza dei profili applicativi
Una visione parcellizzata, senza un controllo centrale che garantisca la coerenza dei profili, comporta diversi rischi.
Ad esempio, sempre restando in ambito bancario, se si vincolano i profili in modo tale che non sia possibile accedere ai dati del conto corrente di un collega da parte di un addetto tramite la procedura conti correnti, si deve avere l’avvertenza di limitare l’accesso alla stessa tipologia di informazioni se la stessa è accessibile da altre applicazioni (ad esempio l’applicazione che gestisce l’archiviazione degli estratti conto inoltrati alla clientela).
L’esempio evidenzia come la stessa informazione (non necessariamente lo stesso dato fisico o logico) possa essere accessibile da applicazioni diverse.
Se nessuno è a conoscenza di questo fatto (se non di dispone quindi di un repository complessivo di quanto sopra evidenziato) si rischia, da un lato di vanificare la volontà di limitare l’accesso ad alcuni dati, dall’altro di violare diverse normative.
Quindi, anche in presenza di un presidio di buon livello su singole applicazioni svolto da chi le gestisce, senza una visione centralizzata che abbia un presidio su tutte le applicazioni (e le infrastrutture) non è possibile una corretta gestione del minimo privilegio di accesso.
I sistemi di Identity Management non risolvono i problemi
Evidenzio che i sistemi di Identity Management in uso presso le aziende di medie e grandi dimensioni non risolvono i problemi sopra evidenziati.
Tali sistemi infatti permettono solitamente di abbinare profili autorizzativi alle varie applicazioni o transazioni (se sono presenti anche ambienti host), ma non dispongono (perché questa non è una funzionalità necessaria per la loro finalità) dei cataloghi delle informazioni sopra citate.
In altre parole, tali sistemi consentono di gestire la parte finale del processo per una corretta gestione dei profili abilitativi, ma non supportano l’analisi necessaria alla corretta definizione degli stessi che, come sopra evidenziato, richiede la presenza di un rilevante numero di informazioni, che solitamente non sono disponibili.
Quindi, se ritenete di aver tutto sotto controllo in quanto avete un sistema di Identity Management vi invito ad effettuare una verifica nei termini sopra indicati.
A titolo puramente esemplificativo, nel mio libro “AUDIT e GDPR” (FrancoAngeli, 2019) ho riportato l’esempio di un ipotetico audit sui profili autorizzati e i relativi possibili rilievi che qui sintetizzo:
- la formulazione delle procedure aziendali non è così analitica da consentire una mappatura sufficientemente dettagliata delle attività svolte dai singoli uffici;
- la mancanza di una specifica procedura per la gestione e censimento delle autorizzazioni ad personam;
- la mancanza del censimento delle singole funzioni disponibili sulle applicazioni, indispensabile per la corretta gestione dei profili;
- la mancanza di regole condivise per il censimento dei profili abilitativi (sempre che esista tale censimento), per l’attribuzione di una nomenclatura univoca ai profili e la mancanza di una descrizione sufficientemente analitica del contenuto di ogni profilo.
La probabilità che tali rilievi sia riscontrabile in qualunque organizzazione è talmente elevata che è possibili attribuirli anche senza svolgere nella pratica alcuna verifica specifica (come mi risulta sia stato fatto da qualche mio lettore).
Conclusioni
Limitare l’accesso ai soli dati necessari è molto più difficile di quanto si creda e la corretta profilazione degli utenti necessità di una serie di prerequisiti informativi raramente disponibili.
Per evitare violazioni normative, ma soprattutto per evitare i problemi di sicurezza che tutto questo comporta, invito quindi ad un’attenta valutazione della conformità della propria organizzazione.
NOTE
Questo requisito dovrebbe essere inserito fra quelli indispensabili per valutare l’acquisizione di un applicazione. ↑
