Indietro

Prossima

Accesso a Dataverse

Completato

I dati devono sempre essere considerati una risorsa preziosa. Pertanto, nella fase di progettazione della sicurezza è importante creare un modello di sicurezza che garantisca l'accesso appropriato a questa preziosa risorsa, così come appropriato deve essere il suo utilizzo. Microsoft Dataverse archivia i dati per Microsoft Power Platform e fornisce servizi per le app. Microsoft Power Platform adotta più livelli di sicurezza per controllare l'accesso a un ambiente Dataverse, ma una volta che un utente ha ottenuto l'accesso all'ambiente, l'Architetto di soluzioni deve controllare l'accesso all'interno del database. Una caratteristica fondamentale di Dataverse è il modello di sicurezza avanzato, in grado di adattarsi a numerosi scenari di utilizzo aziendale.

Autorizzazione

L'autorizzazione è la funzione che permette di specificare i diritti di accesso, o privilegi, alle risorse. La progettazione della sicurezza implementerà l'autorizzazione per accedere a dati e funzionalità. Decidere chi può avere accesso e a quali dati e servizi è una parte essenziale della progettazione di qualsiasi soluzione.

Una progettazione inadeguata della sicurezza può incidere negativamente sulla progettazione del sistema e questi fattori possono avere un impatto di vasta portata ed essere costosi da correggere:

• Gestibilità: difficoltà nella gestione degli accessi individuali.
• Prestazioni: ad esempio, la crescita della tabella PrincipalAccessObject (POA) durante la condivisione.
• Usabilità: procedure macchinose per concedere l'accesso.
• Visibilità: impossibilità di sapere chi ha avuto accesso al record.

Ogni soluzione presenta requisiti specifici, ma è possibile identificare e riusare funzionalità e modelli comuni.

Modelli comuni

I modelli di utilizzo comuni all'interno di molte app aziendali includono:

• Coinvolgimento attivo: coinvolgimento regolare e significativo direttamente con il cliente/i dati. Azioni informate, basate sulla conoscenza del cliente/dei dati e dell'attività correlata corrente, e azioni personali, basate su una relazione diretta con le persone coinvolte.
• Coinvolgimento secondario: coinvolgimento informato, mantenendo una conoscenza attiva dell'attività ma senza partecipare né operare direttamente sui dati o interagire con il cliente, ad esempio fornendo copertura in caso di assenza di personale attivamente coinvolto. Supportare altri che hanno una relazione personale con il cliente, ad esempio fornendo consigli o supporto alle persone che sono attivamente coinvolte o fornendo conoscenze specialistiche per dati o clienti specifici.
• Interazione transazionale: coinvolgimento specifico orientato all'attività, ad esempio ricezione di una richiesta di aggiornamento dell'indirizzo di un cliente e successivo intervento. Nessun coinvolgimento personale o continuo, come in un contact center.
• Supervisione della gestione: responsabilità manageriale o di governance in un'area di attività o geografica. Visione e coordinamento del coinvolgimento degli altri, anziché un coinvolgimento specifico.
• Creazione di report: creazione di report aziendali aggregati. I dati sono organizzati per preservare l'anonimato anziché fornire accesso diretto a clienti/trattative.
• Conformità: accesso in sola lettura per supervisione a tutti i record per un'area di attività.

Al momento di progettare la sicurezza, l'Architetto di soluzioni deve avere un'idea chiara di come lavorano gli utenti. In altre parole, deve capire se gli utenti lavorano in autonomia, nell'ambito di un team statico oppure in team dinamici che cambiano in base a determinate regole. Questi fattori influenzeranno la progettazione della sicurezza. Dopo aver determinato questi fattori, l'Architetto di soluzioni deve comprendere in che modo gli altri membri del personale forniscono assistenza. Ad esempio, l'Architetto di soluzioni deve sapere se gli utenti dispongono di personale assegnato per l'assistenza e se il personale è condiviso con altri utenti. Inoltre, l'Architetto di soluzioni deve chiedere cosa accadrebbe in caso di non disponibilità del personale di assistenza, cosa succede nell'orario notturno e durante i fine settimana e come viene gestita la supervisione.

Principi di progettazione

Quando si progetta la sicurezza, gli architetti di soluzioni devono seguire alcuni principi:

• La responsabilità assegnata non richiede sempre un accesso limitato.
• Le eccezioni vanno trattate come tali, favorendo i modelli di accesso frequenti.
• Non è possibile revocare l'accesso per un record nel caso di concessione dell'accesso a un set di dati più ampio che lo contiene.
• Usare le Business Unit per la gestibilità e il contenimento, non in modo che corrispondano alla struttura organizzativa.
• Usare la progettazione più semplice, che offra prestazioni all'altezza e soddisfi i requisiti.

Nota

Occasionalmente, la struttura organizzativa è allineata alla struttura di sicurezza richiesta; tuttavia, si tratta di un evento raro. Quando si progetta la sicurezza, non limitarsi a usare la struttura organizzativa come unica base predefinita.

Funzionalità di sicurezza

Dataverse fornisce numerose funzionalità di sicurezza per l'accesso ai dati:

• Proprietà delle tabelle
• Utenti
• Team
• Business Unit
• Ruoli di sicurezza
• Condivisione
• Gruppi di sicurezza Microsoft Entra ID
• Sicurezza a livello di colonna
• Sicurezza gerarchica
• Controllo

Gli architetti di soluzioni devono comprendere ognuna di queste funzionalità e il modo in cui si combinano per creare il modello di sicurezza per la loro soluzione. In questa unità non vengono illustrate in dettaglio le singole funzionalità di sicurezza, ma viene spiegato come possono essere utilizzate insieme per creare un modello di sicurezza per la soluzione.

Proprietà delle tabelle

Le tabelle in Dataverse possono essere di proprietà di un utente/team oppure dell'organizzazione. Le tabelle di proprietà dell'utente/team prevedono un campo Proprietario e ogni riga della tabella può essere assegnata a un proprietario. Il proprietario di una riga, insieme alle altre funzionalità di sicurezza, consente di determinare chi ha accesso alla riga; altrimenti detto, l'accesso alle righe è granulare e può essere partizionato orizzontalmente. Se così non fosse, l'accesso a singole righe nelle tabelle di proprietà dell'organizzazione non potrebbe essere limitato e gli utenti avrebbero accesso a tutti i record o a nessuno di essi.

Nota

Una volta creata la tabella, non è più possibile modificare il tipo di proprietà. In caso di dubbio, specificare il tipo di proprietà Utente/team durante la creazione delle tabelle.

Team

I team sono raccolte di utenti che permettono agli utenti stessi di accedere ai dati. I team sono un modo estremamente pratico per concedere autorizzazioni a dei gruppi di utenti senza dover gestire l'accesso a livello di singolo utente. Gli utenti possono essere membri di più team.

I team possono essere di tre tipi:

• Proprietario: questi team possono avere la proprietà delle righe, il che consente a qualsiasi membro del team di accedere direttamente a quella riga.
• Accesso: un metodo per consentire agli utenti di condividere facilmente una riga con un altro utente dall'interno di un modulo.
• Gruppo Microsoft Entra ID: simile ai team Proprietario, ma l'appartenenza al team viene controllata in Microsoft Entra ID.

Ruoli di sicurezza

I ruoli di sicurezza sono fondamentali per la sicurezza dei dati in Dataverse. Anziché concedere privilegi specifici agli utenti, si creano dei ruoli di sicurezza. Dataverse usa la sicurezza basata sui ruoli per raggruppare una raccolta di privilegi.

I ruoli di sicurezza possono essere assegnati agli utenti e ai team. I team e gli utenti possono avere ruoli di sicurezza che forniscono privilegi aggregati.

Importante

Tutte le concessioni di privilegi sono cumulative e i privilegi di accesso più ampio prevalgono. Se si è concesso l'accesso completo in lettura a livello di organizzazione a tutti i record dei contatti, non è possibile tornare indietro e nascondere un singolo record.

Business Unit

Le Business Unit contengono utenti e team e fungono da limiti di sicurezza. Le Business Unit sono il metodo principale per controllare l'accesso ai sottoinsiemi di dati all'interno di una tabella, ovvero il partizionamento orizzontale dei dati. Le Business Unit permettono di segmentare gli utenti e i relativi dati.

Ogni database di Dataverse è caratterizzato da un'unica Business Unit radice. È possibile creare Business Unit figlio per rappresentare gruppi di utenti in una rigida gerarchia.

Nota

Le Business Unit prevedono un team predefinito che contiene tutti gli utenti nella Business Unit stessa. Non è possibile aggiungere o rimuovere manualmente utenti dai team predefiniti, che pertanto possono rivelarsi dei fattori di blocco per alcuni scenari man mano che la soluzione si evolve.

Importante

È la combinazione di ruoli di sicurezza e Business Unit che costituisce la base del modello di sicurezza per Dataverse.

Le Business Unit forniscono un modo efficiente per gestire numerosi utenti e l'accesso ai record. Le Business Unit non sono visibili agli utenti nelle applicazioni, ma solo agli amministratori. Oltre a rispecchiare l'organigramma di un'organizzazione, occorre anche progettare la gerarchia delle Business Unit per soddisfare i requisiti di sicurezza. Questo approccio a volte può implicare la creazione di Business Unit per soddisfare un requisito di sicurezza, come la creazione di una Business Unit che agisca da padre delle Business Unit Sales e Marketing, in modo da consentire ad alcuni utenti di accedere a tali unità impedendo però l'accesso alla Business Unit Operations.

Condivisione di righe

Le singole righe possono essere condivise con utenti e team. Questa funzionalità consente agli utenti di accedere ai record limitati dal modello di sicurezza generato dalle Business Unit. La condivisione consente di accedere alle righe al di fuori della rigida gerarchia delle Business Unit.

Ruoli di sicurezza e team

I ruoli di sicurezza possono essere associati ai team. Gli utenti possono quindi essere associati al team; pertanto, tutti gli utenti associati al team potranno sfruttare i privilegi del ruolo. Gli utenti avranno accesso alle righe di proprietà del team e, a seconda delle altre funzionalità di sicurezza, potrebbero avere accesso alle righe di proprietà di altri utenti del team.

Le opzioni per il ruolo di sicurezza che controllano il modo in cui il ruolo di sicurezza opera con un team sono:

• Predefinito: solo i privilegi del team
• Privilegi del team e livello di accesso utente diretto (di base)

Con l'opzione Utente diretto, i privilegi vengono trattati come se fossero assegnati direttamente all'utente. L'uso di questa opzione permette di evitare di assegnare ruoli di sicurezza agli utenti, usando invece i team e i ruoli di sicurezza assegnati ai team stessi.

Nota

I team proprietari appartengono alle Business Unit. Un utente può appartenere solo a una Business Unit alla volta, ma un utente può essere aggiunto a un team in un'altra Business Unit. Questa funzionalità consente agli utenti di accedere ai dati in una Business Unit non inclusa nella propria gerarchia.

Sicurezza a livello di colonna

I privilegi forniti dai ruoli di sicurezza operano a livello di riga. Se un utente dispone dei privilegi di aggiornamento su una riga, può aggiornare tutte le colonne su quella riga. Occasionalmente, il controllo dell'accesso a livello di riga può rivelarsi inadeguato, ad esempio per le colonne che contengono informazioni di identificazione personale. Dataverse prevede una funzionalità di sicurezza a livello di colonna per consentire un controllo più granulare della sicurezza a livello di colonna.

La sicurezza a livello di colonna opera in modo separato rispetto ai ruoli di sicurezza. I profili di sicurezza delle colonne definiscono il privilegio di lettura/scrittura sulle colonne e vengono assegnati a utenti e team.

Nota

Se un utente non dispone dei privilegi per leggere una colonna protetta, può comunque vedere la colonna nel modulo ma non sarà in grado di visualizzarne il contenuto, ovvero il valore dei dati. Quando si usa il codice per accedere a un campo protetto, il valore sarà null se l'utente non dispone dei privilegi di lettura.

Sicurezza gerarchica

Un problema legato all'uso delle Business Unit è la loro rigida gerarchia. L'accesso ai dati può solo seguire la gerarchia delle Business Unit. Nel diagramma delle Business Unit, a un utente in Sales può essere concesso l'accesso alle Business Unit North, Central e South. Al contrario, un utente nella Business Unit Operations non può accedere ai dati che appartengono a Sales senza avere accesso a tutti i dati nell'organizzazione.

Nella sicurezza gerarchica, l'utente nella posizione di cui sopra può leggere e scrivere tutti i dati per i propri subordinati. Inoltre, può leggere i dati per gli utenti che si trovano più in basso nella gerarchia.

La sicurezza gerarchica è un modello di sicurezza alternativo progettato per scenari in cui un utente che richiede la supervisione da parte di un responsabile non si trova nella stessa parte della gerarchia delle Business Unit. La sicurezza gerarchica è utile in situazioni in cui i responsabili risiedono in paesi/aree geografiche o reparti diversi rispetto ai loro subordinati diretti.

La sicurezza gerarchica prevede due opzioni:

• Gerarchia responsabile: questa opzione utilizza la gerarchia degli utenti nella tabella systemuser. La limitazione è che un responsabile nella stessa Business Unit o nella catena diretta di Business Unit di cui sopra non può leggere e scrivere dati da utenti in reparti diversi.
• Gerarchia posizioni: questa opzione utilizza la tabella Position. Questa opzione è più flessibile e ignora la struttura delle Business Unit. La gerarchia delle posizioni ammette inoltre più di una persona in una posizione.

È possibile usare solo uno dei tipi di gerarchia alla volta.

Controllo

Il controllo acquisisce tutte le modifiche ai dati. Permette inoltre di monitorare chi ha apportato le modifiche e semplifica l'analisi di come gli utenti stanno effettivamente utilizzando il sistema. La funzionalità di controllo all'interno di Dataverse non acquisisce letture di dati o azioni sui dati stessi, come l'esportazione in Microsoft Excel.

Un altro controllo disponibile è denominato registrazione delle attività e si trova nel Centro sicurezza e conformità di Microsoft 365. La registrazione delle attività include letture di dati e altre operazioni. La registrazione delle attività deve essere abilitata e facilita il conseguimento degli obiettivi di conformità.

Gestione della sicurezza in più ambienti

I ruoli di sicurezza e i profili di sicurezza delle colonne possono essere impacchettati in soluzioni e trasportati in altri ambienti. I modelli del team di accesso fanno parte dei metadati della tabella e sono inclusi nella tabella quando vengono aggiunti alla soluzione. Altre funzionalità di sicurezza, quali Business Unit e team, non possono essere impacchettate in soluzioni e l'Architetto di soluzioni dovrà pianificarne la popolazione negli ambienti.

Strategie per la definizione dei ruoli di sicurezza

Sono previste tre strategie di base per la creazione di ruoli di sicurezza:

• Specifica per la posizione
• Base + posizione
• Base + funzionalità

La strategia specifica per la posizione è la creazione di un unico ruolo di sicurezza che contiene tutti i privilegi richiesti dal ruolo professionale o dalla mansione. I ruoli predefiniti sono specifici per la posizione e prendono il nome dai ruoli professionali, ad esempio Venditore. È possibile seguire questo modello di ruolo per ruoli professionali specifici, ma ci si potrebbe ritrovare con numerosi ruoli di sicurezza simili da gestire. Ad esempio, l'aggiunta di una nuova tabella personalizzata significherà cambiare molti, se non tutti, i ruoli.

Un approccio più moderno consiste nell'usare un modello di sicurezza a più livelli. In questo modello, si copia un ruolo predefinito, come Venditore o Utente base, quindi si modificano i livelli di accesso in base ai livelli comuni o minimi richiesti da tutti gli utenti. Questo ruolo potrebbe essere denominato Base. A questo punto si potranno creare nuovi ruoli e impostare i livelli di accesso per i pochi privilegi richiesti da ogni gruppo di utenti oltre al ruolo di base. Questi ruoli minimi contengono gli altri privilegi necessari per la posizione o la funzionalità richiesta.

Nel diagramma seguente, il ruolo di base è denominato All Staff e a tutti gli utenti verrà assegnato questo ruolo. A tutti gli utenti in Sales verrà assegnato anche il ruolo denominato Sales, un ruolo di posizione, con alcuni utenti delle vendite cui verrà assegnato il ruolo Mobile, un ruolo di funzionalità con il privilegio Accesso mobile e un responsabile cui vengono assegnati i ruoli Sales e Manager.

Anche se potrebbe non essere ovvio, i ruoli di sicurezza sono collegati alle Business Unit. I ruoli creati nella Business Unit radice vengono ereditati da tutte le Business Unit figlio. È possibile creare un ruolo di sicurezza per una specifica Business Unit se si desidera limitare tale ruolo agli utenti in quella Business Unit. Tuttavia, occorre tenere presente che i ruoli di sicurezza nelle soluzioni vengono sempre aggiunti alla Business Unit radice quando la soluzione viene importata.

Team del gruppo Microsoft Entra ID

Un team del gruppo Microsoft Entra ID è simile a un team proprietario in quanto può avere la proprietà dei record e avere ruoli di sicurezza assegnati al team. La differenza è che l'appartenenza al team in Dataverse deriva in modo dinamico dall'appartenenza al gruppo Microsoft Entra ID associato. L'appartenenza al gruppo Microsoft Entra ID può essere assegnata manualmente o ulteriormente derivata da un'assegnazione basata su regole in funzione degli attributi dell'utente in Microsoft Entra ID.

La combinazione dei team dei gruppi Microsoft Entra ID con l'assegnazione di ruoli di sicurezza ai team con l'opzione Utente diretto permette di semplificare notevolmente la gestione dell'aggiunta di nuovi utenti.

I gruppi di sicurezza e i gruppi di Office 365 possono essere usati per i team dei gruppi Microsoft Entra ID.

Continua