Risposta breve
Una piattaforma Privacy-IRM necessita di un sistema di autorizzazioni che vada oltre la semplice distinzione tra „amministratore“ e „utente“. Sono necessari, in particolare, diritti basati sui ruoli, relativi agli oggetti, multi-cliente e dipendenti dallo stato. Gli utenti dovrebbero poter accedere solo alle informazioni e alle funzioni necessarie per lo svolgimento delle rispettive mansioni. Ciò vale, ad esempio, per le attività di trattamento, i rischi, i fornitori di servizi, gli incidenti, le valutazioni d’impatto sulla protezione dei dati, i casi d’uso dell’IA, le misure e le autorizzazioni.
Occorre inoltre tenere conto delle autorizzazioni temporanee, dei processi amministrativi regolamentati, di una registrazione tracciabile, di controlli periodici dei diritti e di un’integrazione affidabile con il sistema di gestione delle identità e degli accessi.
Il software per la protezione dei dati contiene informazioni aziendali sensibili
I software per la protezione dei dati servono solitamente a Documentazione e la gestione delle attività di trattamento, delle misure tecniche e organizzative, dei responsabili del trattamento, delle richieste degli interessati, degli incidenti relativi alla protezione dei dati, delle valutazioni d’impatto sulla protezione dei dati, dei termini di cancellazione e della relativa documentazione.
Una piattaforma Privacy-IRM non contiene tuttavia solo dati amministrativi. Al suo interno vengono regolarmente trattate informazioni sensibili relative alle strutture di protezione dei dati, di gestione dei rischi e di governance di un’azienda.
La piattaforma permette di individuare quali sistemi Dati personali analizzare quali fornitori di servizi sono coinvolti e quali rischi, punti deboli o azioni ancora da intraprendere sussistono. A ciò si aggiungono, se del caso, informazioni relative a incidenti, reclami, situazioni poco chiare Base giuridica, i trasferimenti internazionali di dati e le decisioni interne. Nei processi di governance dell’IA possono essere fornite ulteriori informazioni sui casi d’uso dell’IA, sulle fonti dei dati, sui modelli, sui fornitori, sulle classi di rischio, sulle condizioni di autorizzazione, sul monitoraggio, sulla supervisione umana e sui possibili impatti su Parti interessate essere incluso.
In questo contesto, anche la piattaforma Privacy-IRM stessa deve essere considerata un sistema da proteggere. Se i diritti di accesso sono definiti in modo troppo ampio, alcune persone potrebbero visualizzare informazioni non necessarie per lo svolgimento del loro specifico incarico. I ruoli e i diritti non sono quindi solo una questione di gestione degli utenti, ma costituiscono una componente essenziale dell’architettura di sicurezza e governance di una piattaforma di questo tipo.
I software per la protezione dei dati possono a loro volta costituire un rischio per la privacy e la sicurezza
Un sistema di gestione della protezione dei dati ha lo scopo di aiutare le aziende a individuare, valutare e gestire i rischi. Allo stesso tempo, il sistema stesso può diventare fonte di rischi se le autorizzazioni vengono concesse in modo troppo ampio, a tempo indeterminato o senza un controllo adeguato.
Un reparto, ad esempio, potrebbe aver bisogno di accedere alle attività di trattamento di cui è responsabile. Da ciò non ne consegue tuttavia automaticamente che debbano essere consultabili anche tutte le attività di trattamento svolte da altri reparti aziendali. Un locale Coordinatore della protezione dei dati potrebbe, se necessario, aver bisogno di accedere alla società a lui assegnata o alla rispettiva sede, ma non necessariamente alle informazioni riservate relative ad altre società.
Lo stesso vale per gli altri ruoli. Il reparto Legale necessita in particolare di informazioni relative ai contratti e alle responsabilità. Il reparto Sicurezza IT necessita di dati tecnici. Il management necessita regolarmente di informazioni sintetiche sui rischi e sui processi decisionali. Un responsabile esterno della protezione dei dati deve poter accedere alle operazioni rilevanti per la sua attività, senza che ciò comporti automaticamente un accesso illimitato a tutti i contenuti documentati nel sistema.
Il GDPR richiede, per quanto riguarda la sicurezza della Elaborazione adatto misure tecniche e organizzative, che garantiscano un livello di protezione adeguato al rischio. A tal proposito occorre tenere conto in particolare di Riservatezza, Integrità, Disponibilità e la resilienza dei sistemi, nonché i rischi di divulgazione o accesso non autorizzati.
Tali requisiti non riguardano solo i sistemi documentati nell’elenco delle attività di trattamento, ma devono essere presi in considerazione anche nel sistema in cui vengono gestite le attività di trattamento, i rischi, gli incidenti e le misure adottate.
Principio del privilegio minimo nelle operazioni relative alla privacy
Il principio del "least privilege" prevede di limitare i diritti di accesso alla misura necessaria per lo svolgimento di un compito specifico. Il NIST descrive il "least privilege" come un principio di sicurezza in base al quale i diritti di accesso vengono limitati al minimo necessario per lo svolgimento del compito in questione.
Per il reparto Privacy Operations ciò significa che i ruoli non dovrebbero essere dotati di diritti illimitati solo per motivi di semplificazione.
Occorre verificare se un dipartimento necessiti di diritti di accesso completi, così come occorre valutare se un Coordinatore della protezione dei dati deve disporre di diritti di scrittura a livello dell'intera organizzazione oppure il reparto Legale dovrebbe avere accesso di default a tutte le pratiche. A seconda dell'ambito di competenza, potrebbero essere necessari accessi più estesi. Tuttavia, questi non dovrebbero essere previsti come impostazione predefinita senza un'adeguata valutazione.
Il principio del "privilegio minimo" non deve complicare inutilmente lo svolgimento delle mansioni. Ciò che conta, infatti, è quali informazioni e quali azioni un ruolo necessiti effettivamente per poter svolgere i compiti che gli sono stati assegnati.
Un modello di riferimento da solo spesso non basta
Molti sistemi prevedono un modello basato sui ruoli. Tuttavia, la semplice esistenza dei ruoli non dice ancora molto su quanto in realtà sia possibile gestire gli accessi in modo differenziato.
Un modello che distingua semplicemente tra amministratore, manager, utente e utente in sola lettura rischia di non essere sufficiente, nella maggior parte dei casi, per processi complessi di Privacy-IRM. Il ruolo di per sé, in particolare, non indica a quale oggetto si riferisca un'autorizzazione, a quale cliente sia applicabile, quale stato abbia un'operazione e quale azione concreta sia consentita.
Un utente può, ad esempio, essere il titolare di un’attività di trattamento e, allo stesso tempo, il revisore di una misura. In un’altra società, la stessa persona potrebbe avere accesso esclusivamente in lettura. Per un determinato incidente relativo alla protezione dei dati può essere necessaria, in via temporanea, un’autorizzazione aggiuntiva. Nell’ambito di un processo di approvazione, un utente può essere autorizzato a inserire commenti senza poter decidere autonomamente in merito all’approvazione. Un revisore può visionare la documentazione senza poterla modificare.
Tali configurazioni devono essere prese in considerazione regolarmente, in particolare nelle organizzazioni di grandi dimensioni. Una piattaforma Privacy-IRM necessita quindi, oltre ai ruoli, di un’architettura dei diritti che integri tra loro diverse dimensioni di accesso.
Diritti in base a ruoli, oggetti, mandanti, stati e azioni
Una logica di autorizzazione solida dovrebbe tenere conto di diverse dimensioni.
Occorre innanzitutto verificare il ruolo dell'utente. Può trattarsi, ad esempio, del responsabile di un dipartimento, del responsabile della protezione dei dati, di un revisore legale, di un revisore della sicurezza informatica, di un dirigente, di un revisore interno, di un consulente esterno o di un amministratore.
Inoltre, è determinante il singolo oggetto in questione. Un accesso può riguardare, ad esempio, un’attività di trattamento, un fornitore di servizi, un sistema, una misura, un incidente, una richiesta di un interessato, una Valutazione d'impatto sulla protezione dei dati, relativo a un caso d'uso dell'IA, a un rischio o a un rapporto.
Occorre inoltre tenere conto del contesto organizzativo. Un oggetto può essere assegnato a una società, a una sede, a un’unità aziendale, a un progetto o a un team. A seconda della struttura organizzativa, possono essere rilevanti contemporaneamente più di uno di questi livelli.
Anche lo stato dell'operazione può influire sulle azioni consentite. Si distingue, ad esempio, tra bozza, verifica, restituzione, approvazione, escalation, chiusura o archiviazione.
Infine, occorre stabilire quali azioni il ruolo in questione sia autorizzato a eseguire. Tra queste figurano in particolare la lettura, la modifica, l’inserimento di commenti, la verifica, l’approvazione, il rifiuto, l’escalation, l’esportazione, la cancellazione o l’assegnazione di diritti.
È solo dall'interazione di queste dimensioni che è possibile definire un sistema di autorizzazioni che rispecchi adeguatamente il rispettivo processo di governance.
Il responsabile di un’area funzionale può, ad esempio, modificare un’attività di trattamento all’interno della propria azienda, purché questa si trovi ancora in fase di bozza. Dopo l’invio per la revisione, potrebbe essere necessario limitare le modifiche. Deve comunque essere possibile presentare richieste di chiarimenti e integrazioni, mentre l’approvazione effettiva rimane di competenza del revisore o dell’approvatore responsabile. Una volta completato il processo, occorre inoltre stabilire in che modo sia possibile apportare modifiche a una versione già approvata.
La matrice delle autorizzazioni come base di verifica
Nella scelta di una piattaforma Privacy-IRM, quindi, non ci si dovrebbe limitare a chiedersi se il sistema supporti i ruoli. È più significativo chiedersi se i ruoli possano essere gestiti in base ad azioni, oggetti, clienti, stati e autorizzazioni.
Una matrice delle autorizzazioni semplificata può, ad esempio, essere strutturata come segue:
Una tabella di questo tipo non rappresenta un modello di autorizzazione universalmente valido. Tuttavia, evidenzia che i ruoli non dovrebbero essere considerati isolatamente, ma nel contesto di oggetti, azioni, stati e unità organizzative.
I diritti basati sullo stato garantiscono il corretto svolgimento del processo
Un altro aspetto rilevante è rappresentato dai diritti legati allo stato. Nel corso del suo ciclo di vita, un’operazione cambia il proprio stato tecnico e organizzativo. Di conseguenza, possono variare anche le persone autorizzate a compiere determinate azioni.
Un’attività di trattamento in fase di progettazione va trattata in modo diverso rispetto a un’attività di trattamento già approvata. Lo stesso vale per un caso d’uso dell’IA in fase di raccolta rispetto a un caso d’uso già in produzione con condizioni di approvazione, per una misura in fase di progettazione rispetto a una misura critica in ritardo o per un incidente relativo alla protezione dei dati in fase di valutazione iniziale rispetto a un incidente concluso con una decisione di segnalazione documentata.
Il modello di autorizzazioni dovrebbe quindi disciplinare in particolare chi è autorizzato a modificare una bozza, quali possibilità di modifica sono disponibili dopo l’invio e a quali condizioni una valutazione già approvata possa essere modificata o riaperta. Occorre inoltre stabilire chi può revocare le approvazioni, chiudere le pratiche escalate o contrassegnare le misure come completate.
In assenza di regole adeguate, gli utenti possono modificare lo stato del processo in modo involontario o intenzionale, anche se la fase di processo in questione non lo prevede. In questo caso, la sola registrazione a posteriori non sostituisce un’adeguata Controllo degli accessi ai dati.
Accessi mirati alle singole risorse anziché accessi completi generici
Per i sistemi Privacy-IRM è spesso necessario poter limitare l'accesso a singoli oggetti.
Se, ad esempio, un dipartimento deve aggiornare una determinata attività di trattamento, ciò non implica che tutte le attività di trattamento dell’azienda debbano essere accessibili. Un revisore esterno potrebbe dover verificare determinati documenti giustificativi senza per questo aver bisogno di accedere a tutti i rischi, agli incidenti e alle richieste degli interessati. Lo stesso vale per un referente locale che, in caso di una determinata Valutazione d'impatto sulla protezione dei dati collabora.
Una piattaforma dovrebbe quindi consentire di inviare inviti di accesso specifici per oggetto. È ipotizzabile, ad esempio, consentire a una persona esclusivamente di modificare una specifica attività di trattamento, di commentare una determinata misura, di accedere in lettura a documenti selezionati o di collaborare a un caso d’uso specifico dell’IA.
In questo modo è possibile favorire la collaborazione senza dover concedere contemporaneamente diritti di accesso completi al sistema.
Autorizzazioni temporanee
In molti casi, l’accesso è necessario solo per un periodo di tempo limitato. Ciò riguarda, ad esempio, i revisori, i consulenti esterni, i collaboratori dei reparti specializzati nell’ambito di una richiesta da parte di un interessato, l’ufficio legale in caso di verifica concreta di un contratto o il reparto di sicurezza informatica durante la valutazione di un sistema. Anche in caso di incidenti relativi alla protezione dei dati, può essere necessario concedere temporaneamente un accesso aggiuntivo a un team incaricato della gestione dell’incidente.
Tali autorizzazioni non dovrebbero rimanere valide automaticamente a tempo indeterminato.
Dovrebbe quindi essere possibile attribuire una data di scadenza ai diritti temporanei. Inoltre, occorre valutare se sia possibile prevedere una motivazione, la registrazione e la revoca automatica al termine di un’operazione o alla scadenza di un termine.
Nella pratica, può sorgere un rischio legato alle autorizzazioni soprattutto quando un accesso inizialmente giustificato non viene revocato una volta venuto meno il motivo che lo aveva determinato.
Accessi guidati per dipartimento
La gestione della protezione dei dati richiede regolarmente la collaborazione dei dipartimenti competenti. Questi ultimi devono fornire informazioni, aggiornare le attività di trattamento, attuare le misure necessarie, rispondere alle richieste di chiarimenti e supportare i processi di approvazione.
Una piattaforma Privacy-IRM non dovrebbe quindi rivolgersi esclusivamente agli esperti di protezione dei dati. Allo stesso tempo, occorre evitare che i reparti specialistici dispongano di informazioni, campi o diritti non necessari per lo svolgimento delle loro mansioni.
Un adeguato sistema di gestione dei diritti può indirizzare in modo mirato gli accessi dei reparti. Gli utenti visualizzano così le pratiche loro assegnate e i dati di cui sono responsabili. Richieste di chiarimenti, compiti, possibilità di modifica, informazioni sullo stato e scadenze possono essere messi a disposizione nell’ambito di tale ambito, senza che sia necessario un accesso completo all’intera struttura di gestione della protezione dei dati.
Ciò può favorire sia la sicurezza degli accessi sia l'utilizzo pratico del sistema. È fondamentale che sia possibile lavorare sull'oggetto di riferimento senza concedere autorizzazioni più ampie di quelle necessarie.
Distinguere i ruoli amministrativi
I diritti di amministratore richiedono particolare attenzione, data la loro portata solitamente ampia.
In alcuni sistemi, l'amministrazione tecnica e l'accesso completo ai contenuti specialistici sono collegati tra loro. Chi è in grado di creare utenti o configurare campi può, a seconda dei casi, ottenere contemporaneamente l'accesso a contenuti specialistici quali incidenti relativi alla protezione dei dati o attività di trattamento.
Un tale collegamento non è indispensabile. Una piattaforma Privacy-IRM dovrebbe piuttosto essere in grado di gestire diverse attività amministrative.
Gli amministratori tecnici non necessitano automaticamente di pieni diritti di accesso alle funzionalità specialistiche. Gli amministratori specialistici non devono necessariamente poter modificare tutte le configurazioni di sistema. Gli amministratori della sicurezza possono aver bisogno di autorizzazioni diverse rispetto agli amministratori della protezione dei dati. Anche gli accessi di supporto da parte del fornitore dovrebbero essere limitati in termini di ambito e durata, nonché poter essere registrati in modo tracciabile.
Soprattutto nelle organizzazioni di grandi dimensioni, una tale separazione può contribuire a limitare gli accessi privilegiati alla misura necessaria e a facilitarne il controllo.
Integrazione IAM come componente del modello operativo
L'integrazione con un sistema di gestione delle identità e degli accessi (IAM) non è solo una funzione di comodità per una piattaforma Privacy-IRM. È infatti di fondamentale importanza per la gestione a lungo termine degli utenti e delle autorizzazioni.
Se i ruoli e gli utenti vengono gestiti esclusivamente in modo manuale all’interno del software per la protezione dei dati, possono verificarsi discrepanze tra l’effettiva struttura organizzativa e i diritti di accesso registrati. I dipendenti cambiano mansione, le figure esterne abbandonano i progetti, le società o i team vengono riorganizzati e gli utenti lasciano l’azienda.
Se tali modifiche non vengono riportate nella piattaforma Privacy-IRM, potrebbero rimanere attive autorizzazioni non più necessarie.
A seconda dell'organizzazione, rientrano quindi in particolare Single sign-on, l'adozione di gruppi e ruoli, il provisioning e il deprovisioning automatizzati, il supporto agli utenti esterni, i controlli periodici dei diritti e la registrazione degli accessi privilegiati.
Tuttavia, il collegamento tecnico da solo non è sufficiente. Anche il modello di ruoli sottostante deve essere strutturato in modo adeguato. In caso contrario, gruppi IAM definiti in modo inadeguato porterebbero semplicemente al trasferimento automatico di autorizzazioni troppo estese in un altro sistema.
I gruppi IAM, i ruoli della piattaforma e i ruoli di governance dovrebbero quindi essere coordinati tra loro.
Verifiche periodiche dei diritti
Un sistema di autorizzazioni deve essere verificato e adeguato durante l'intero periodo di funzionamento. I ruoli cambiano, i progetti giungono al termine, le responsabilità vengono riassegnate e le figure esterne, una volta conclusa la loro attività, non necessitano più di alcun accesso.
Una piattaforma Privacy-IRM dovrebbe quindi consentire di effettuare controlli periodici delle autorizzazioni.
A questo proposito, ci si chiede, ad esempio, quali utenti possano accedere agli incidenti critici, chi disponga dei diritti di esportazione, chi sia autorizzato a concedere autorizzazioni e quali persone possiedano autorizzazioni amministrative. Occorre inoltre tenere conto dei diritti temporanei, degli account utente inattivi, degli account esterni ancora attivi e di ruoli potenzialmente troppo ampi.
Una piattaforma può supportare tali verifiche fornendo i relativi report, flussi di lavoro di verifica e documentazione. La verifica periodica dei diritti di accesso diventa così essa stessa parte integrante delle attività di protezione dei dati e di governance.
Requisiti specifici relativi ai diritti di esportazione
Nella progettazione di un sistema di autorizzazioni, oltre ai diritti di lettura e di modifica, occorre tenere in particolare considerazione i diritti di esportazione.
Tramite un’esportazione, le informazioni sensibili possono essere sottratte all’ambiente controllato della piattaforma. I ruoli, le regole di stato e le restrizioni di accesso vigenti all’interno della piattaforma non continuano quindi automaticamente ad applicarsi allo stesso modo ai dati esportati.
I diritti di esportazione dovrebbero quindi essere disciplinati separatamente. Un diritto di lettura non deve necessariamente comprendere anche un diritto di esportazione. Allo stesso modo, può essere necessario limitare le esportazioni a determinati insiemi di dati, clienti o società. Nel caso di dati particolarmente sensibili, si può prendere in considerazione la registrazione in un log o l’adozione di ulteriori processi di approvazione.
A seconda delle finalità, può essere necessario disporre di un volume di informazioni diverso. Il management potrebbe aver bisogno, a seconda dei casi, di una visione sintetica, mentre per gli audit potrebbero essere necessarie prove più dettagliate. I reparti specialistici, dal canto loro, necessitano solitamente solo di una selezione limitata di informazioni.
Nella definizione dei diritti, occorre quindi verificare non solo chi è autorizzato a visualizzare le informazioni all’interno del sistema, ma anche chi può esportarle dal sistema.
Autorizzazioni nella governance dell'IA
I processi di governance dell'IA consentono di applicare ulteriori requisiti alla Controllo degli accessi ai dati risultano.
Un caso d'uso dell'IA può contenere informazioni relative a modelli, fornitori, fonti di dati, rischi, ambiti di applicazione, gruppi di utenti, supervisione umana, condizioni di autorizzazione e monitoraggio. Non tutte queste informazioni sono necessarie per ogni ruolo.
Un dipartimento può, ad esempio, occuparsi del proprio caso d’uso. Il dipartimento di sicurezza informatica potrebbe aver bisogno di accedere a informazioni tecniche, quello legale ai dati relativi ai fornitori e ai contratti e il Protezione dei dati informazioni relative alle persone e sui rischi per Parti interessate. Il management, invece, potrebbe aver bisogno in particolare di informazioni relative allo stato e ai rischi.
Se le funzioni di IA vengono integrate direttamente in una piattaforma di governance, il modello di autorizzazione deve applicarsi anche a tali funzioni. Un agente di IA dovrebbe poter accedere solo alle informazioni e eseguire solo le azioni consentite dal ruolo del singolo utente e nel contesto specifico del processo.
L'utilizzo di un agente IA non deve quindi portare ad aggirare le restrizioni esistenti relative a ruoli, oggetti o stati. Allo stesso modo, nel caso di riepiloghi generati o azioni predisposte, occorre tenere conto delle informazioni che il ruolo richiedente è effettivamente autorizzato a visualizzare ed elaborare.
Interazione tra multitenancy e modello dei ruoli
Multitenancy e il controllo delle autorizzazioni devono essere considerati congiuntamente. Mentre la struttura dei mandanti separa le unità organizzative l’una dall’altra, il modello dei ruoli determina quali accessi sono consentiti all’interno di tali unità e, se del caso, anche tra di esse.
Ad esempio, la sede centrale di un gruppo può necessitare di un sistema di reporting trasversale, mentre le singole società gestiscono autonomamente le proprie operazioni operative. Un’unità aziendale può aver bisogno di informazioni che riguardino più società, mentre una sede può necessitare solo di misure a livello locale. I team di progetto, a loro volta, possono avere accesso a singoli casi d’uso dell’intelligenza artificiale. Per un responsabile della protezione dei dati a livello di gruppo può essere necessaria una visione trasversale e orientata al rischio.
Una separazione rigida tra i clienti può quindi rivelarsi altrettanto insufficiente quanto un modello di ruoli troppo ampio, che di fatto annulla i confini organizzativi esistenti.
Per le organizzazioni di grandi dimensioni, è quindi opportuno che i mandanti, gli oggetti, i ruoli, le autorizzazioni e le funzioni di reporting siano coordinati tra loro.
Modello di autorizzazioni in Ailance
Una piattaforma IRM per la privacy dovrebbe supportare in particolare le seguenti funzioni:
| Requisito | Significato |
|---|---|
| Basato sui ruoli Controllo degli accessi ai dati | I ruoli rispecchiano le mansioni tipiche e limitano i diritti generali. |
| Diritti relativi agli oggetti | Gli accessi possono essere limitati a specifiche operazioni di trattamento, rischi, misure o incidenti. |
| Riferimento al cliente e alla società | Le società, i paesi o le unità organizzative possono essere gestiti e analizzati separatamente. |
| Diritti dipendenti dallo stato | La fase di progettazione, verifica, approvazione, escalation e chiusura può essere associata a diverse autorizzazioni. |
| Diritti basati sull'azione | Le operazioni di lettura, modifica, verifica, approvazione, inoltro, esportazione ed eliminazione sono gestite separatamente. |
| Autorizzazioni temporanee | Progetto, Audit- oppure gli accessi in caso di incidenti possono essere concessi a tempo determinato e successivamente revocati. |
| Restrizioni relative a campi o aree | Le informazioni particolarmente sensibili possono essere ulteriormente protette. |
| Delega e rappresentanza | È possibile istituire delle deleghe senza conferire diritti più ampi a titolo permanente. |
| Separazione degli amministratori | L'amministrazione tecnica e l'accesso completo alle funzioni specialistiche possono essere separati l'uno dall'altro. |
| Integrazione IAM/SSO | È possibile associare utenti, gruppi e ruoli all'identità aziendale. |
| Verifica della conformità e ricertificazione | I diritti di accesso possono essere verificati e documentati regolarmente. |
| Audit Percorso per le autorizzazioni | Le modifiche apportate ai ruoli, ai diritti e agli accessi rimangono tracciabili. |
| Controllo delle esportazioni | Le esportazioni di dati possono essere regolate, registrate e limitate separatamente. |
| Autorizzazioni per gli agenti IA | Le funzioni di IA rimangono legate al ruolo, al contesto e al processo. |
La portata di tali requisiti dipende dalla natura delle informazioni trattate in una piattaforma Privacy-IRM. Il sistema contiene solitamente informazioni fondamentali relative ai processi di protezione dei dati, di gestione dei rischi e di governance di un’azienda e dovrebbe essere protetto di conseguenza.
Modello di autorizzazioni in Ailance
Ailance è concepita come piattaforma per i processi di governance. Il modello dei diritti dovrebbe quindi essere orientato agli oggetti e ai processi di governance gestiti all'interno della piattaforma.
Un’attività di trattamento, un rischio, un fornitore di servizi, un sistema, un caso d’uso dell’IA o una misura non sono semplicemente singoli record di dati. Essi sono correlati a ruoli, stati, responsabilità, autorizzazioni e documentazione.
Ne consegue che anche i diritti di accesso dovrebbero essere definiti in base agli oggetti e ai processi.
Per un accesso specifico occorre quindi determinare, tra l’altro, quale ruolo ricopra un utente, in quale mandante agisca, a quale oggetto si riferisca l’azione, quale stato presenti tale oggetto e quale azione concreta debba essere eseguita. Inoltre, può essere rilevante verificare se siano state ottenute le autorizzazioni necessarie, se l’accesso sia stato concesso in modo permanente o temporaneo e se si debbano esportare informazioni sensibili.
Anche la registrazione o l'escalation di determinate azioni può far parte di questo sistema di controllo.
In questo modo, un sistema di autorizzazioni di governance si distingue da una semplice gestione degli utenti, che sostanzialmente si limita a verificare se un utente ha effettuato l'accesso ed è assegnato a un determinato ruolo generico.
Verifica pratica delle autorizzazioni esistenti
Le aziende dovrebbero verificare regolarmente se i ruoli e le autorizzazioni esistenti corrispondano ancora alle effettive esigenze operative. Come punto di partenza si può considerare, in particolare, il ruolo che attualmente dispone dei diritti più ampi.
A tal proposito, andrebbero esaminate, tra le altre, le seguenti questioni:
- Esiste davvero la necessità di accedere a tutti i mandanti?
- È necessario avere accesso a tutti gli oggetti per svolgere l'attività in questione?
- Oltre ai diritti di lettura, sono necessari anche i diritti di modifica?
- È necessario esportare i dati in questione?
- Quando sono state verificate l'ultima volta le autorizzazioni assegnate?
Se non è possibile fornire risposte chiare a queste domande, ciò non riguarda solo la gestione degli utenti. Può anche indicare la necessità di una verifica della sicurezza e della governance del sistema di gestione della protezione dei dati.
Conclusione
In una piattaforma Privacy-IRM, i ruoli e i diritti costituiscono una componente essenziale dell'architettura di sistema e di governance.
La piattaforma elabora regolarmente informazioni sensibili relative alle attività di trattamento, ai sistemi, ai dati, ai rischi, ai fornitori di servizi, agli incidenti, Parti interessate, decisioni e documentazione. Di conseguenza, anche l'accesso a tali informazioni deve essere opportunamente limitato e gestito in modo tracciabile.
In particolare, occorre tenere conto del principio del “least privilege”, delle autorizzazioni relative agli oggetti, dei controlli di accesso specifici per cliente, dei diritti dipendenti dallo stato e dall’azione, degli accessi temporanei, delle autorizzazioni di esportazione separate, della separazione dei ruoli amministrativi e dell’integrazione con le strutture IAM esistenti.
È fondamentale che gli utenti ricevano le informazioni e le funzioni necessarie per svolgere il proprio compito, senza concedere accessi che vadano oltre tali limiti in modo permanente o generalizzato. Un sistema di autorizzazioni solido è quindi un prerequisito affinché una piattaforma Privacy-IRM possa supportare adeguatamente i processi di protezione dei dati e di governance di un’azienda.
Domande e risposte
Quali ruoli e funzioni relative ai diritti deve avere una piattaforma Privacy-IRM?
Una piattaforma Privacy-IRM richiede diritti basati sui ruoli, relativi agli oggetti, multi-cliente, dipendenti dallo stato e legati alle azioni. A ciò si aggiungono, in particolare, accessi temporanei, esportazioni controllate, separazione dei ruoli amministrativi, integrazione con IAM, Audit Tracciati e controlli periodici dei diritti.
Perché i software per la protezione dei dati possono costituire essi stessi un rischio per la privacy?
I software per la protezione dei dati contengono solitamente informazioni sensibili relative alle attività di trattamento, ai sistemi, ai fornitori di servizi, ai rischi, agli incidenti, alle misure adottate e alle decisioni. Se i diritti di accesso sono definiti in modo troppo ampio, possono insorgere rischi per la riservatezza e la sicurezza.
Cosa significa “privilegio minimo” nelle operazioni relative alla privacy?
Il principio del "privilegio minimo" implica che agli utenti vengano concessi solo le informazioni e le azioni necessarie per lo svolgimento del loro specifico compito. I diritti necessari possono quindi variare, ad esempio, a seconda che si tratti di reparti specialistici, revisori, responsabili della protezione dei dati, ufficio legale, sicurezza informatica, dirigenza e consulenti esterni.
Perché non bastano semplici ruoli come “Admin” e “User”?
I processi relativi alla privacy e all'IRM richiedono spesso un controllo più articolato. Oltre al ruolo, occorre tenere conto in particolare dell'oggetto in questione, del cliente, dello stato di un'operazione e dell'azione consentita.
Cosa sono i diritti relativi agli oggetti?
I diritti relativi a specifici oggetti limitano l'accesso a determinate attività di trattamento, rischi, misure, incidenti, fornitori di servizi o casi d'uso dell'IA. Ciò consente una collaborazione mirata senza concedere un accesso completo all'intero sistema.
Perché le autorizzazioni temporanee sono importanti?
In molti casi, l'accesso è necessario solo per progetti, audit, incidenti o singole verifiche. Una limitazione temporale impedisce che le autorizzazioni originariamente necessarie rimangano attive in modo permanente una volta venuto meno il loro scopo.
Che ruolo svolge l'integrazione IAM?
Un'integrazione IAM collega utenti, gruppi e ruoli della piattaforma Privacy-IRM al sistema di gestione delle identità e degli accessi già in uso nell'azienda. Ciò consente, in particolare, di gestire in modo più affidabile i cambiamenti di ruolo, le uscite dall'azienda, nonché le operazioni di provisioning e deprovisioning.
Perché occorre prestare particolare attenzione ai diritti di esportazione?
Con un’esportazione, i dati vengono estratti dall’ambiente controllato della piattaforma. Per questo motivo, i diritti di esportazione dovrebbero essere assegnati separatamente, limitati e registrati. Nel caso di dati sensibili, si può prendere in considerazione l’applicazione di ulteriori autorizzazioni.
In che modo la capacità multi-cliente e le autorizzazioni sono correlate?
Multitenancy rappresenta la separazione organizzativa delle unità. Il sistema di autorizzazioni stabilisce chi, all’interno di tali unità o trasversalmente ad esse, è autorizzato a leggere, modificare, verificare, approvare o generare report. Entrambi i livelli devono essere coordinati tra loro.
Cosa si intende per autorizzazione basata sullo stato?
Nel caso di un'autorizzazione basata sullo stato, l'azione consentita dipende dallo stato attuale di un'operazione. Per una bozza possono quindi valere diritti di modifica diversi rispetto a quelli applicabili a un'operazione approvata, inoltrata o completata.
Cosa significa "autorizzazione" per gli agenti di IA?
Un agente di intelligenza artificiale dovrebbe poter accedere solo alle informazioni e eseguire solo le azioni consentite in base al ruolo dell'utente, all'oggetto, allo stato del processo e al contesto di governance. Le funzioni di intelligenza artificiale non devono aggirare i limiti di autorizzazione esistenti.
Quali ruoli possono avere diritti particolarmente estesi?
A seconda del sistema e dell’organizzazione, in particolare gli amministratori, i coordinatori locali, i ruoli di progetto o i ruoli di power user sviluppatisi nel tempo possono disporre di autorizzazioni di ampia portata. È opportuno verificare regolarmente se tali diritti siano ancora Necessità devono essere verificati.
German 
English 
Italian 
French