Progettare il modello di sicurezza Dataverse

Il modello di sicurezza Dataverse come decisione architetturale

In PL-600 la sicurezza Dataverse non è un dettaglio implementativo delegato all’admin: è una decisione di architettura che impatta i pilastri Security e Operational Excellence del Well-Architected Framework. Il tuo obiettivo è garantire il least privilege (ogni utente vede e modifica solo ciò che gli serve) senza costruire un modello così granulare da diventare impossibile da governare. La domanda ricorrente d’esame è sempre la stessa: dato questo requisito organizzativo, quale combinazione di componenti raccomandi e perché?

I quattro livelli e come combinarli

Business Units (BU) definiscono i confini di ownership dei dati. Ogni BU eredita la struttura della root e crea automaticamente un team di default. Sono lo strumento giusto quando esiste una reale segregazione dei dati tra divisioni (es. filiali con dati clienti che non devono vedersi). Trade-off: le BU sono relativamente rigide e riorganizzarle è costoso, quindi non modellare l’intero organigramma HR come BU — moltiplichi la complessità senza guadagno.

Security Roles sono il cuore del modello: assegnano privilegi (Create/Read/Write/Delete/Append/Append To/Assign/Share) su ciascuna tabella con access levels a cerchi concentrici — User, Business Unit, Parent:Child BU, Organization. Raccomandazione di design: parti dai ruoli out-of-the-box come baseline, crea pochi ruoli additivi e componibili (i ruoli sono cumulativi: l’unione dei privilegi vince) invece di molti ruoli monolitici quasi identici. Questo è il punto chiave della manutenibilità: 5 ruoli combinabili scalano meglio di 30 ruoli per-persona.

Teams dividono in due famiglie con scopi diversi:

• Owner team: possiede i record. Utile quando l’ownership deve appartenere a un gruppo, non a un individuo, e per ridurre lo sharing esplicito.
• Access team (spesso via access team template): non possiede record ma concede accesso granulare e dinamico al singolo record condiviso. È la risposta corretta quando servono migliaia di condivisioni ad-hoc che, fatte manualmente, degraderebbero le performance del sistema di sharing (PrincipalObjectAccess).
• I Microsoft Entra ID group teams (Security/Office groups) sono la scelta consigliata per la governance moderna: l’appartenenza si gestisce in Entra ID, non manualmente in Dataverse.

Column e row-level security

La column-level security (Field Security Profiles) protegge singole colonne sensibili (retribuzione, codice fiscale) sovrapponendosi ai security role. Usala chirurgicamente: ogni colonna protetta aggiunge overhead e complessità di troubleshooting.

La row-level security si ottiene combinando ownership + access level + sharing. Per lo scenario “il manager deve vedere i dati del team” la leva corretta è la hierarchy security (Manager o Position hierarchy), che evita di gonfiare le BU. Attenzione al trade-off di performance citato nel WAF: la sicurezza gerarchica calcola l’accesso risalendo la catena e, con gerarchie profonde, introduce latenza. Best practice: limitare la profondità effettiva (parametro depth) e preferire la Position hierarchy quando la struttura non coincide con il reporting manageriale.

Bilanciare granularità e manutenibilità

Il principio guida è: least privilege con il minimo numero di componenti. Ogni ruolo, profilo di colonna, BU e team in più è debito operativo. Un modello sovra-ingegnerizzato rallenta l’onboarding (assegnare correttamente 20 ruoli a un nuovo assunto è error-prone), complica gli audit e degrada le query per l’esplosione di sharing e calcoli gerarchici. Raccomanda sempre la soluzione più semplice che soddisfa il requisito, documentata e testata con utenti di prova per persona.

Trappole tipiche d’esame

• Requisito: i manager devono accedere ai record dei loro report diretti senza duplicare dati per divisione → Soluzione: hierarchy security (Manager/Position), NON creare una BU per manager.
• Requisito: migliaia di condivisioni ad-hoc di singoli record a utenti esterni al team owner → Soluzione: access team con template, non sharing manuale (che gonfia POA e degrada le performance).
• Requisito: proteggere solo il campo “stipendio” lasciando visibile il resto del record → Soluzione: column-level security (Field Security Profile), non un nuovo security role né una nuova tabella.
• Requisito: molti ruoli quasi identici che rendono l’onboarding ingestibile → Soluzione: consolidare in pochi ruoli additivi e componibili sfruttando la natura cumulativa dei privilegi.
• Requisito: segregazione netta e permanente dei dati tra due business legali distinte → Soluzione: Business Units separate (con eventuale Modernized BU per ownership cross-BU), non solo access level “User”.
• Requisito: gestire l’appartenenza ai team dal reparto IT centrale già su Entra ID → Soluzione: Entra ID group teams, non team con membership manuale in Dataverse.