PL-400 · Modello di sicurezza Dataverse

Fondamenti: privilegi e access level

In Dataverse l’autorizzazione ruota attorno ai security role, che aggregano privilegi su tabelle e azioni. Ogni ruolo definisce, per ciascuna tabella, i sette privilegi base (Create, Read, Write, Delete, Append, Append To, Share) e, per ciascuno, un access level che ne stabilisce l’ampiezza:

None – nessun accesso.
User (Basic) – solo record posseduti dall’utente o condivisi con lui.
Business Unit – record posseduti dalla business unit dell’utente.
Parent: Child Business Units – la propria BU e tutte quelle discendenti.
Organization – tutti i record del tenant.

Il punto chiave per l’esame: i privilegi sono cumulativi. Se assegni più ruoli, l’utente ottiene l’unione (il livello più permissivo) di tutti i privilegi; non esiste una logica di “deny” che sovrascrive un permesso concesso da un altro ruolo. Per togliere un accesso devi rimuovere il ruolo che lo concede, non aggiungerne uno più restrittivo.

Business unit e ownership

Le business unit formano una gerarchia organizzativa e sono la chiave di volta dell’access level Business Unit / Parent: Child. Ogni utente appartiene a una BU; ogni record ha un owner (utente o team). Un privilegio con livello Business consente di vedere i record posseduti da owner della stessa BU, non “i record creati in un reparto”. Spostare un utente in un’altra BU quindi ridisegna concretamente cosa vede.

I team possono essere owner team (possiedono record e portano i propri ruoli a tutti i membri) oppure, più spesso oggi, access team.

Sharing manuale (Share): concede accesso puntuale a un singolo record verso utenti/team specifici. Flessibile ma non scala: ogni condivisione è un record PrincipalObjectAccess e la gestione diventa ingestibile su grandi volumi.
Access team con template: definisci un team template sulla tabella con i diritti (Read/Write/Delete/Share…). A runtime, aggiungendo un utente alla sotto-griglia del record, Dataverse crea/gestisce automaticamente un team e la condivisione. È la scelta corretta quando la membership cambia record per record (es. “team di progetto” su ogni opportunità) senza voler creare migliaia di team statici.

Regola pratica: sharing per eccezioni sporadiche; access team per collaborazione dinamica ricorrente sullo stesso pattern.

Column-level security

Quando serve proteggere campi specifici (es. IBAN, retribuzione) indipendentemente dall’accesso al record, si usa la column security: si abilita IsSecured sulla colonna e si definisce un column security profile che assegna, a utenti/team, i diritti Read / Update / Create sul campo. Chi non è nel profilo vede il valore mascherato pur potendo aprire il record. È l’unico meccanismo che opera sotto il livello di riga.

Hierarchy security: manager e position

La hierarchy security aggiunge accesso lungo una gerarchia, in aggiunta ai ruoli:

Manager hierarchy: basata sul campo Manager; un manager accede ai record dei subordinati solo nella propria BU o in BU discendenti. Adatta quando i confini gerarchici coincidono con quelli organizzativi.
Position hierarchy: basata su posizioni custom, ignora i confini di BU; adatta a matrici/organizzazioni trasversali.

Si configura il numero di livelli di profondità (depth) e i diritti (di norma sola lettura, o read/write/append). Non sostituisce i ruoli: se l’utente non ha il privilegio base sulla tabella, la gerarchia non gli dà nulla.

Combinare gli elementi

Un requisito reale tipicamente si compone così: ruolo con access level Business come base per reparto → hierarchy security per far vedere ai manager i team sottostanti → access team per la collaborazione cross-funzionale sui singoli record → column security per proteggere i campi sensibili. Si parte sempre dal livello più ampio (ruolo) e si aggiungono meccanismi più granulari.

Trappole tipiche d’esame

Scenario: due ruoli, uno concede Read User e l’altro Read Organization → l’utente vede tutti i record: vince il livello più alto, i privilegi si sommano, non si sottraggono.
Scenario: un utente deve vedere i record di un altro reparto ma il suo ruolo ha Read Business → la risposta è spostarlo/aggiungere un team o alzare a Parent:Child, non “creare un ruolo che nega”: Dataverse non ha deny.
Scenario: collaborazione che cambia su ogni record con membership dinamica → access team con template, non lo sharing manuale né owner team statici.
Scenario: nascondere solo il campo “stipendio” lasciando visibile il record → column-level security, non un access level più basso sulla tabella.
Scenario: un manager deve vedere i record dei collaboratori in un’altra BU → serve position hierarchy (attraversa le BU), perché la manager hierarchy resta confinata alla propria BU e discendenti.