La sicurezza in Microsoft Dataverse è il cuore della configurazione che un Functional Consultant deve saper progettare. Il modello è role-based: non si assegnano permessi al singolo record uno per uno, ma si combinano business unit, team e security role per determinare cosa un utente può fare e su quali dati. Comprendere come questi tre elementi interagiscono è essenziale per applicare il principio del least privilege.

Business unit: la gerarchia organizzativa

Ogni ambiente Dataverse ha una root business unit creata automaticamente e non eliminabile. Da questa si diramano business unit figlie, formando un albero gerarchico che tipicamente rispecchia la struttura aziendale (divisioni, filiali, reparti).

Ogni utente appartiene a una sola business unit e ogni record ha un proprietario associato a una BU. La gerarchia diventa determinante quando un access level è impostato su Parent-Child: chi opera nella BU padre può accedere ai record delle BU figlie, ma non viceversa. Progettare bene l’albero delle BU è quindi il primo strumento per segmentare i dati tra reparti che non devono vedersi.

Team: raggruppare utenti e condividere accessi

I team servono a distribuire privilegi a gruppi di utenti. Esistono tre tipi principali:

  • Owner team: può possedere record (essere proprietario). Assegnare un security role a un owner team estende quei privilegi a tutti i membri. Utile quando più persone gestiscono gli stessi dati.
  • Access team: non possiede record e non ha security role. Serve a condividere record specifici con permessi granulari, spesso tramite access team template su un form. Ideale per collaborazioni ad hoc su singoli record.
  • Microsoft Entra ID group team: la membership è governata da un gruppo di Microsoft Entra ID. Aggiungendo o rimuovendo utenti dal gruppo si aggiornano automaticamente i membri e l’ereditarietà dei ruoli. Ottimo per governance centralizzata a scala.

Un utente eredita i privilegi di tutti i security role assegnati direttamente e quelli assegnati ai team di cui fa parte.

Security role: privilegi e access level

Un security role è una matrice: per ogni tabella definisce quali azioni (privilegi) sono consentite e con quale ampiezza (access level).

I privilegi

  • Create, Read, Write, Delete: le operazioni CRUD di base.
  • Append e Append To: governano le relazioni. Append permette di collegare un record a un altro; Append To permette di essere il record a cui altri vengono collegati. Servono entrambi per creare un’associazione (es. aggiungere una Contact a un Account).
  • Assign: cambiare il proprietario di un record.
  • Share: concedere accesso a un record a un altro utente o team.

I cinque access level

Rappresentati graficamente da cerchi che si riempiono progressivamente:

  • None: nessun accesso.
  • User (Basic): solo i record di cui l’utente è proprietario o che gli sono stati condivisi.
  • Business Unit (Local): tutti i record della propria BU.
  • Parent-Child (Deep): la propria BU e le BU figlie.
  • Organization (Global): tutti i record dell’ambiente, indipendentemente dalla BU.

Progettare con il least privilege

L’obiettivo è concedere il minimo access level che soddisfa lo scenario. Un venditore che deve vedere solo le proprie opportunità avrà Read = User; un team leader di filiale Read = Business Unit; un direttore regionale Read = Parent-Child; un amministratore di sistema Organization. Partire da un ruolo predefinito (es. copiando Basic User) e alzare i livelli solo dove serve è la strategia raccomandata, invece di partire da System Administrator e restringere.

Trappole tipiche d’esame

  • Più ruoli si sommano (union) → Se un utente ha due security role con access level diversi sulla stessa tabella, vince il più permissivo. I privilegi si aggregano: non esiste una revoca sottrattiva o un ruolo di “deny”. Per togliere accesso occorre rimuovere il ruolo, non aggiungerne uno restrittivo.
  • Utente non vede record di un’altra BU → Serve access level Parent-Child o Organization, non Business Unit. Ricorda che Business Unit copre solo la BU di appartenenza.
  • “Aggiungi Contact a un Account” fallisce → Mancano i privilegi Append/Append To, non Write. Le relazioni richiedono la coppia su entrambe le tabelle.
  • Condividere pochi record senza dare un ruolo → Usa un access team (o Share sul record), non un owner team né un access level più alto.
  • Membership che cambia spesso → Preferisci un Entra ID group team per far seguire automaticamente i ruoli alla membership del gruppo Entra.