Argomenti del workshop sulla sicurezza
Questa unità descrive gli argomenti consigliati che dovrebbero essere trattati nel workshop sul modello di sicurezza.
Panoramica sul modello di sicurezza
Nella sezione Panoramica sul modello di sicurezza del modello va fornita una descrizione generale del modello di sicurezza dei partecipanti. Non è necessario approfondire i dettagli perché ogni area specifica verrà trattata in modo particolareggiato più avanti nel modello.
Successivamente, è necessario rispondere alla domanda riguardante la modalità di gestione dell'accesso ai record. Queste informazioni sono utili per sapere se esistono specifiche restrizioni sui dati (ad esempio, ai venditori è consentito visualizzare solo i dati dei propri clienti) o se altre informazioni speciali sull'accesso ai dati possono avere un impatto sul modello di sicurezza. Inoltre, questa sezione può includere dettagli tecnici, come il requisito dell'autenticazione a più fattori per l'accesso ai dati di sistema.
Informazioni di base
Due diapositive nel modello coprono le informazioni di base sul modello di sicurezza. Queste diapositive includono le domande seguenti.
Quanti sono gli utenti (destinazione)? - Il numero di utenti ha un impatto significativo sulla scalabilità del modello di sicurezza. Ad esempio, se il cliente fa affidamento sulla condivisione dei record per fornire l'accesso, deve essere consapevole del potenziale impatto sulle prestazioni quando molti record vengono condivisi tra molti utenti. Alcuni modelli di sicurezza accettabili per un numero ridotto di utenti diventano inadatti all'aumentare di questo numero. Per questo motivo, è importante considerare la crescita attuale e futura prevista del numero di utenti.
Quanti schemi o configurazioni di sicurezza distinte sono presenti nel modello e quanti utenti sono inclusi in ogni configurazione di schema? - Lo schema di sicurezza riguarda le diverse configurazioni di sicurezza che il cliente desidera implementare per soddisfare i requisiti. Ad esempio, le persone nel reparto vendite adotteranno i ruoli di sicurezza utente in modo standard, le persone nel servizio clienti useranno una combinazione di ruoli utente e gerarchia del responsabile e le persone nel marketing useranno solo i team di accesso. Determinando il numero previsto di schemi, si comprenderà se il modello di sicurezza sarà eccessivamente complicato o difficile da mantenere nel lungo termine.
Quale percentuale di utenti ha potenzialmente requisiti di sicurezza più complessi rispetto al resto? - I clienti a volte complicano eccessivamente i loro modelli di sicurezza progettando il processo standard in base a eccezioni limitate. Quando si identificano molti requisiti non standard differenti, è necessario mettere in discussione il requisito e consigliare la standardizzazione sul processo principale.
È necessario limitare o filtrare l'accesso ai dati? - Questa domanda distingue tra filtri di praticità e requisiti di sicurezza reali. Voler fornire agli utenti una visualizzazione semplificata dei dati più rilevanti per la loro attività è un buon obiettivo; tuttavia, non è un obiettivo che dovrebbe essere raggiunto attraverso la sicurezza. Usare le visualizzazioni per filtrare i dati, lasciando disponibile l'accesso ad altri record.
Quanti ruoli di sicurezza sono necessari? - Mantenere al minimo il numero di ruoli di sicurezza semplifica la gestione delle attività amministrative. Dynamics 365 include molti ruoli di sicurezza standard per tipi di utenti standard come Direttore commerciale, Rep servizio clienti e Amministratore di sistema. Questi ruoli devono essere usati come base per i ruoli di sicurezza del cliente.
Se i requisiti differiscono dai ruoli standard, prendere in considerazione la creazione di copie dei ruoli standard ed eseguire l'iterazione da essi.
Sono stati creati nuovi ruoli di sicurezza invece di personalizzare quelli esistenti? - Una procedura consigliata consiste nel salvare una copia di uno dei ruoli di sicurezza standard anziché crearne uno nuovo.
I ruoli di sicurezza includono molte autorizzazioni necessarie per accedere all'applicazione e la creazione di un nuovo ruolo è problematica perché il cliente probabilmente non disporrà di tutte le autorizzazioni di base necessarie.
Ricordare al cliente che le nuove autorizzazioni vengono spesso aggiunte ai ruoli di sicurezza standard tramite aggiornamenti regolari dell'applicazione e non vengono aggiunte automaticamente ai ruoli di sicurezza personalizzati esistenti. Se si usano ruoli di sicurezza personalizzati, qualcuno dovrà ricordarsi di identificare le autorizzazioni appena aggiunte e aggiornare i ruoli di sicurezza personalizzati dopo ogni aggiornamento per garantire la continuità dell'accesso al sistema dopo gli aggiornamenti.
Si è provato a ridurre il più possibile il numero di ruoli di sicurezza? - Più ruoli di sicurezza si usano in una distribuzione di Dynamics 365, più difficile risulterà l'amministrazione nel lungo termine. Quando si aggiunge una nuova funzionalità, se sono disponibili 25 ruoli di sicurezza separati e la funzionalità è necessaria a tutti, il creatore dovrà aggiornare 25 ruoli di sicurezza per fornire l'accesso alla nuova funzionalità.
Una strategia diffusa consiste nell'usare un ruolo di base, che fornisce la linea di base delle funzionalità necessarie per accedere all'applicazione e a tutte le tabelle disponibili per tutti gli utenti. Il passaggio successivo è integrare quel ruolo con ruoli aggiuntivi con le funzionalità specifiche necessarie per il ruolo stesso.
Ad esempio, se tutti gli utenti devono leggere gli account, ma solo i direttori commerciali possono crearne di nuovi, il ruolo di base conterrà l'autorizzazione alla lettura degli account a livello di organizzazione e il ruolo del direttore commerciale includerà solo l'autorizzazione alla creazione degli account. Quindi, una nuova funzionalità di cui tutti gli utenti hanno bisogno può essere aggiunta solo al ruolo di base.
Qual è il numero di ruoli di sicurezza di cui una singola persona ha bisogno? - Maggiore il numero di ruoli di sicurezza da aggiungere a un singolo utente, più complicato sarà l'onboarding dell'utente e maggiore sarà la probabilità che qualcuno commetta errori. Se esistono molti ruoli necessari, questi dovrebbero essere consolidati per facilitare la regolare amministrazione.
Un altro approccio che può aiutare è l'uso di team di gruppo di sicurezza Microsoft Entra ID o di gruppo ufficio Microsoft Entra ID. In tal modo è possibile concedere i ruoli una sola volta al team e gli utenti ereditano automaticamente i ruoli del team (quindi, nel contesto della Business Unit del team), dopo essere stati aggiunti all'appropriato gruppo Microsoft Entra ID.
I ruoli di sicurezza vengono creati a livello di Business Unit radice o a livello figlio? - Sebbene sia possibile creare ruoli specifici per una Business Unit figlio, è consigliabile creare e modificare i ruoli di sicurezza a livello di Business Unit radice.
La creazione di ruoli a livello di Business Unit radice rende il ruolo disponibile a tutte le Business Unit, mentre i ruoli delle Business Unit figlio sono disponibili solo a livello della singola Business Unit. Se un ruolo è specifico per una Business Unit, quando si sposta un utente in un'altra Business Unit, quel ruolo non sarà disponibile. In caso contrario, si avrebbero versioni diverse dello stesso ruolo in diverse Business Unit, rendendo difficile l'amministrazione del sistema.
Qual è la strategia usata per aggiornare i ruoli di sicurezza durante la distribuzione di nuove tabelle e funzionalità? - In un ambiente in rapida evoluzione con sviluppo continuo, può essere facile dimenticare di aggiornare i ruoli o testare solo l'accesso dell'amministratore di sistema e mancare di aggiornare i ruoli di sicurezza per includere la nuova funzionalità. La strategia del cliente dovrebbe includere un processo per l'aggiornamento dei ruoli di sicurezza e il test di una combinazione dei ruoli di ogni utente tipo ogni volta che si distribuisce una nuova versione della configurazione.
Motivi per acquisire queste informazioni
I motivi per cui vanno chieste le informazioni precedenti ai partecipanti sono i seguenti:
È raro che un unico schema di sicurezza soddisfi le esigenze e i ruoli di tutti gli utenti. È necessario comprendere quanti schemi diversi bisognerà implementare nel progetto.
Modelli di sicurezza complessi sono spesso progettati per soddisfare le esigenze di una piccola parte di utenti che non rientra nel modello principale. In tal caso, potrebbe crearsi un'opportunità di contestazione se tali utenti non potessero accedere ai dati desiderati in un modo diverso o altrove, ad esempio tramite la creazione di report.
Business Unit
In questa sezione va fornita una descrizione della struttura gerarchica dell'organizzazione interna del cliente e della struttura delle Business Unit in Dynamics 365. Dovrebbe esistere una relazione tra la struttura delle Business Unit e la struttura dell'organizzazione, ma la struttura delle Business Unit non deve essere così dettagliata come quella dell'organizzazione. Il fatto che due gruppi si trovino in diverse divisioni della società non significa che sarà necessario limitare la visibilità dei record tra i due gruppi. Spesso più reparti possono condividere la stessa Business Unit.
Usare uno strumento come Microsoft Visio o un'altra applicazione di creazione di diagrammi/grafici visivi per creare una rappresentazione visiva della struttura. Se è già disponibile un documento che visualizza la gerarchia organizzativa della società, è possibile incollare uno screenshot del diagramma nel documento.
Occorre tenere presenti due potenziali problemi: le Business Unit possono essere in numero eccessivo o in numero insufficiente.
Business Unit in numero eccessivo
Se il modello di sicurezza proposto evidenzia che saranno presenti centinaia o migliaia di Business Unit, questo problema dovrebbe essere contrassegnato come un rischio. Le Business Unit sono come grandi massi di granito, progettate per essere permanenti e spostate molto raramente. Invece gli utenti possono essere spostati tra Business Unit; non è una questione banale, soprattutto se possiedono molti record.
Quando si sposta un utente dalla Business Unit 1 alla Business Unit 2, l'associazione tra Business Unit e ogni record di proprietà dell'utente cambia. Ciò può causare sorprese agli altri utenti membri della Business Unit originale dell'utente, se dispongono dell'autorizzazione di lettura a livello di Business Unit. I record di proprietà dell'utente spostato non saranno più disponibili per loro, ma se questi utenti sono proprietari di record figlio di tali record, ad esempio di attività, potrebbero verificarsi strani scenari. Inoltre, se l'utente possiede molti record, lo spostamento tra Business Unit può richiedere molto tempo.
Un altro potenziale impatto del gran numero di Business Unit è l'estrema lentezza degli aggiornamenti dei ruoli di sicurezza. Ogni ruolo non è un solo record. Una copia di ogni ruolo viene aggiunta a ciascuna Business Unit. Pertanto, se si creano migliaia di Business Unit, apportare una piccola modifica a un ruolo di sicurezza potrebbe richiedere ore.
Una buona pratica è ridurre al minimo le Business Unit. Usarne il numero minimo per facilitare i reali requisiti di sicurezza delle Business Unit. Per una segmentazione più granulare degli utenti, prendere in considerazione l'uso dei team. I team sono più flessibili, possono essere usati per controllare l'accesso di sicurezza ai record e gli utenti possono essere membri di più team.
Business Unit in numero insufficiente
Se si sta implementando una soluzione per un singolo gruppo, è pratica comune voler usare solo la Business Unit radice per tutti gli utenti.
Sebbene l'approccio orientato alla semplicità sia ottimo, esiste una forte possibilità che il cliente possa, a un certo punto, avere alcuni dati che desidera tenere segreti a un sottoinsieme di utenti.
Considerare gli scenari seguenti:
Si estende l'uso di Dynamics 365 ad altre parti della società.
La società viene acquisita da una grande azienda multinazionale.
Il CEO decide di tenere traccia dei messaggi e-mail e non vuole che li leggano tutti.
Il vicepresidente delle vendite scopre diversi contatti nella rubrica che devono essere in Dynamics 365 ma è meglio non divulgarli al resto della società.
Spostare le persone tra Business Unit è difficile ed è un processo che si vorrà eseguire solo quando necessario. Se il cliente inizia con tutti gli utenti nella Business Unit di base, qualora si verifichi un cambiamento che richiede la separazione di un sottoinsieme di dati, sarà necessario trasferire buona parte o la totalità degli utenti perché non è possibile riassociare la Business Unit radice a un nuovo elemento padre.
Per evitare questa eventualità, potrebbe essere una buona idea creare inizialmente una Business Unit figlio e inserirvi tutti gli utenti. Se i cambiamenti aziendali richiedono un'ulteriore segmentazione dei dati, questo approccio semplificherà le cose la Business Unit con la maggior parte degli utenti può essere riassociata a un nuovo elemento padre o utenti selezionati, come il CEO, possono essere spostati nella Business Unit di base. È possibile evitare uno spostamento su vasta scala di tutti gli utenti dalla Business Unit.
Team
La sezione Team del modello di sicurezza acquisisce i dettagli relativi all'uso pianificato dei record dei team per la sicurezza in Dynamics 365.
In questa sezione vanno fornite risposte alle seguenti domande:
Si usano team proprietari per assegnare ruoli agli utenti? - I team proprietari (inclusi i team di gruppo di sicurezza Microsoft Entra ID e di gruppo ufficio Microsoft Entra ID) costituiscono un ottimo modo per assegnare ruoli di sicurezza agli utenti e per ridurre il carico di lavoro amministrativo. Quando si assegna un ruolo di sicurezza a un team, il ruolo viene ereditato dagli utenti membri ma si applica nell'ambito della Business Unit del team.
Si usano team proprietari per possedere record? - La proprietà dei record da parte dei team può essere considerata per gestire l'associazione di un record a una Business Unit separatamente dall'altrimenti standard Business Unit dell'utente proprietario. Questo approccio può essere utile quando l'associazione funzionale di un record e una Business Unit è diversa dall'associazione dell'utente a una Business Unit.
La proprietà dei record da parte dei team presenta alcuni lati negativi e rischi da tenere presenti. In genere, deve essere automatizzata per essere coerente e di facile uso. Alcune funzionalità, come gli obiettivi e le previsioni, si basano sulla proprietà dei record da parte dell'utente. Inoltre, la possibilità di riassegnare i record di un utente in blocco (ad esempio quando un nuovo venditore ne sostituisce un altro in pensione ed eredita il suo portafoglio clienti) non è disponibile per i team proprietari.
La proprietà dei record da parte dei team può essere usata per semplificare modelli di sicurezza complessi e ridurre la necessità di un'eccessiva condivisione dei record. I ruoli di un team proprietario concedono autorizzazioni di sicurezza speciali nel contesto dei record di proprietà del team. Pertanto, se i membri di un team di vendita devono avere il diritto di modificare le opportunità a cui sono associati, ma l'autorizzazione di sola lettura per le opportunità a cui non sono associati, i team di sicurezza proprietari possono abilitare questa eccezione senza dover usare una condivisione complessa.
L'assegnazione dei record è automatizzata e in che modo? - Quando si crea un nuovo account, è necessario determinare come assegnare il record. Inoltre, è necessario considerare se il coordinatore delle vendite ricorderà di assegnare accuratamente il record in modo manuale. Per i tipi di record importanti, come gli account, è consigliabile predisporre un processo automatizzato che assegni automaticamente i record quando vengono creati, per semplificare la regolare amministrazione del sistema. Un approccio potrebbe essere archiviare l'assegnazione del venditore in base allo stato nel record del territorio in Dynamics 365. Quindi, quando si crea un nuovo account, si esegue un flusso Microsoft Power Automate. Il flusso confronta lo stato dell'indirizzo 1 con il campo dello stato del territorio e assegna l'account al territorio e al venditore appropriati. Quindi, invia un messaggio e-mail di notifica al venditore perché contatti il nuovo potenziale cliente.
Si usano team di accesso (gestiti dal sistema o manualmente)? - I team di accesso sono un'ottima soluzione per la gestione di autorizzazioni speciali per i record. Ad esempio, se un assistente alle vendite deve disporre di autorizzazioni di modifica su 25 account diversi, anziché condividere gli account manualmente con tale utente, è possibile aggiungere l'assistente a una griglia secondaria del team di accesso nel record. L'assistente alle vendite, quindi, erediterà le autorizzazioni di modifica in base al modello del team di accesso associato alla griglia. I team di accesso sono una soluzione eccellente perché nella tabella POA viene creato un solo record di condivisione per l'intero team di accesso anziché record individuali per ogni persona, come avviene con la condivisione dei record (vedere la sezione Condivisione precedente in questo modulo). Questo approccio consente inoltre agli amministratori di vedere chi ha accesso al record.
Se lo stesso gruppo di persone necessita dell'accesso a più record, i team di accesso possono essere usati anche per condividere i record con tale team. Tuttavia, tenere presente che un team di accesso non può essere proprietario di record e non può essere assegnatario di ruoli di sicurezza.
L'appartenenza al team di accesso è automatizzata? - È frequente avere una combinazione di persone che hanno bisogno di accedere ai record. Ad esempio, un progetto di produzione richiede un ingegnere, un elettricista e un tecnico della sicurezza. Spesso, queste assegnazioni vengono mantenute in un altro sistema.
In questo caso, è necessario usare il team di accesso perché la combinazione di individui è diversa per ciascun record e l'accesso di sicurezza è necessario per i membri del team. È possibile automatizzare l'appartenenza al team di accesso usando approcci come integrazione, azioni o plug-in.
Come vengono distribuiti i modelli del team di accesso nei diversi ambienti? - Le autorizzazioni per i record del team di accesso vengono stabilite attraverso un modello del team di accesso. Il modello determina quali autorizzazioni vengono condivise con i membri del team.
Una criticità sta nel fatto che i record del modello del team di accesso non riconoscono la soluzione, il che significa che non possono essere aggiunti alle soluzioni. Quando le personalizzazioni vengono spostate da un ambiente all'altro, il modello del team di accesso deve essere spostato o ricreato manualmente nell'ambiente di destinazione. Se si sta automatizzando l'appartenenza a un team di accesso, i modelli devono avere GUID identici nei vari ambienti, poiché la logica vi fa riferimento.
Sono disponibili diversi approcci per la migrazione dei modelli del team di accesso, tra cui l'utilità di migrazione dei dati di configurazione, strumenti ETL come Scribe o SSIS o le utilità in XrmToolBox.
Si usano gruppi sincronizzati Microsoft Entra ID per gestire i diritti di accesso? - I team di gruppo di sicurezza Microsoft Entra ID o i team di gruppo ufficio Microsoft Entra ID sono ideali per automatizzare l'assegnazione delle autorizzazioni di ruolo agli utenti e dovrebbero essere presi in considerazione per le distribuzioni più grandi o complesse.
Con Microsoft Entra ID è possibile avere il controllo completo delle autorizzazioni da un'unica origine.
Sono presenti requisiti non soddisfatti dal modello standard? - Identificare i requisiti di sicurezza non standard. Nella sezione dei risultati e dei suggerimenti consigliare approcci per standardizzare i requisiti non standard.
Meccanismi di sicurezza implementati
In questa sezione vanno identificati i metodi usati per automatizzare la sicurezza. Questi includono la condivisione automatizzata, la sicurezza a livello di campo, la sicurezza gerarchica, i plug-in e i comportamenti delle relazioni. Fare riferimento alla sezione degli strumenti di sicurezza di questo modulo se non si ha familiarità con qualcuno di questi approcci.
Motivi per acquisire queste informazioni:
Possono verificarsi problemi di prestazioni se si automatizza la condivisione su larga scala. La tabella PrincipalObjectAccess o POA è piena di eccezioni al modello di sicurezza standard.
La condivisione dovrebbe in genere rimanere un processo manuale, in modo da concedere eccezioni al modello di sicurezza implementato, e dovrebbe essere evitata su larga scala.
Mentre è facile modificare la Business Unit, i team e i ruoli di un utente, può essere complicato eseguire una migrazione dei dati basata su regole di condivisione personalizzate dopo una riorganizzazione.
La sicurezza a livello di campo non riconosce l'utente o la Business Unit.
La sicurezza gerarchica può causare problemi di prestazioni in configurazioni complesse se la profondità della gerarchia include troppi livelli.
Il comportamento a catena nelle relazioni è conveniente, ma a volte può avere conseguenze indesiderate (come la riassegnazione di attività chiuse quando si riassegna un account). L'assegnazione o la condivisione a catena può essere disabilitata o modificata nelle singole relazioni oppure usando l'impostazione DisableImplicitSharingOfCommunicationActivities di ORG DB.
Interfaccia utente
Molti componenti di Dynamics 365 sono abilitati per i ruoli di sicurezza, cioè l'accesso a un determinato elemento può essere limitato a uno o più ruoli di sicurezza. Questa funzionalità è importante perché utenti diversi richiedono esperienze diverse durante l'uso di tabelle comuni e, impedendo l'accesso ai componenti dell'app che non sono necessari, si offrirà un'esperienza più semplice e personalizzata.
Gli elementi in Dynamics 365 che possono essere abilitati per i ruoli includono:
App basate su modello
Dashboard
Moduli
Flussi dei processi di business
Aree secondarie della mappa del sito
Pulsanti della barra dei comandi
Modelli di documento
In questa sezione del modello va capito se i ruoli vengono usati per semplificare l'accesso a queste aree.
Motivi per acquisire queste informazioni:
I ruoli di sicurezza e i privilegi di tabella possono essere usati per personalizzare e rifinire l'esperienza degli utenti.
Meno elementi vedono gli utenti, più facile sarà l'esperienza.
Le app basate su modello possono essere associate ai ruoli di sicurezza per semplificare l'esperienza utente complessiva, riducendo l'elenco di visualizzazioni, grafici, dashboard, moduli e flussi di processi di business.
I clienti senza una strategia in quest'area potrebbero riscontrare problemi imprevisti. Ad esempio, le app Microsoft comuni come Hub delle vendite, Hub del servizio clienti e App per Outlook controlleranno l'accesso usando gli appositi ruoli di sicurezza. Se un cliente esegue i test solo con un ruolo di amministratore di sistema, potrebbe non rilevare che gli utenti senza questo ruolo necessitano del ruolo di accesso all'app per usare l'app (oppure l'app deve essere condivisa con i loro ruoli di sicurezza personalizzati). Questo scenario può determinare l'impossibilità degli utenti di accedere alle app di cui hanno bisogno durante la distribuzione.
Scalabilità, prestazioni e manutenibilità
In questa sezione del modello si esaminano domande che hanno lo scopo di rilevare se potrebbero verificarsi problemi potenziali quando l'applicazione viene ridimensionata per utenti aggiuntivi e la quantità di dati aumenta.
Domande sulla manutenzione e perché sono importanti
Rispondere alle seguenti domande sulla manutenzione nel modello.
Sono stati identificati scenari in cui il record non deve essere di proprietà di un utente o di un team? - Quando si creano nuove tabelle che rappresentano dati referenziali interaziendali e non avranno mai bisogno di granularità per ogni Business Unit, team o utente, è opportuno considerare di crearle come tabelle di proprietà dell'organizzazione.
La proprietà del record è importante quando è necessario concedere visibilità o autorizzazioni di modifica variabili a utenti diversi. Tuttavia, se esistono record generali che devono essere visibili a tutti gli utenti e tutti gli utenti condividono lo stesso livello di autorizzazioni di modifica (come i record generati usando un'integrazione), è opportuno prendere in considerazione una strategia come l'assegnazione di record al team della Business Unit, in modo che questi record non debbano essere riassegnati quando qualcuno lascia la società.
Sono stati identificati potenziali problemi di scalabilità nella progettazione della sicurezza a volumi più elevati? - Strategie come la condivisione dei record possono funzionare adeguatamente in distribuzioni più piccole, ma possono rapidamente diventare inefficienti se adattate a un numero elevato di utenti.
Inoltre, avere utenti membri di migliaia di team in migliaia di Business Unit può essere una sfida in termini di prestazioni e scalabilità.
È stato considerato l'impatto dei dati e dei modelli di sicurezza sulla tabella POA? - Una condivisione eccessiva porta a una tabella POA di grandi dimensioni e può ridurre le prestazioni del sistema.
I record di utenti, team o Business Unit vengono aggiornati regolarmente? - Come regola generale, dovrebbero essere evitati aggiornamenti regolari alle tabelle di utenti, team o Business Unit. Ad esempio, l'aggiornamento di un attributo in una tabella di utenti può causare lo svuotamento della cache di sicurezza con un potenziale impatto sulle prestazioni.
È stato considerato l'impatto di una grande riorganizzazione di utenti, team, Business Unit e record? - Le strutture aziendali cambiano. Vengono acquisite nuove società, cedute divisioni e le persone lasciano o si trasferiscono in altri reparti. La struttura aziendale dovrebbe essere sufficientemente flessibile da poter aggiungere o rimuovere facilmente utenti, team o Business Unit senza richiedere una riprogettazione completa del modello di sicurezza.
Per gli utenti che hanno già accesso a una grande percentuale di record, è stata presa in considerazione la possibilità di fornire un accesso globale per migliorare le prestazioni? - Fornire l'accesso in lettura globale/a livello dell'intera organizzazione ai record può ottimizzare le prestazioni per l'implementazione di una visualizzazione perché il sistema non deve considerare i principi di sicurezza che si applicano a un utente (ruoli individuali, ruoli del team, record condivisi, gerarchia) durante il recupero dei record.
Sebbene un utente possa avere accesso a tutti i record dal punto di vista della sicurezza, è necessario personalizzare le visualizzazioni di sistema che filtreranno il numero di record, in modo da presentare solo ciò che è pertinente all'attività dell'utente.
Quando un utente esce dall'organizzazione, i record vengono riassegnati in blocco? È stato considerato l'impatto di una relazione a catena? - Le impostazioni a catena delle relazioni per le attività e altri record comuni possono causare risultati imprevisti quando si riassegnano i record e questo comportamento deve essere modificato se non si desidera che le attività chiuse vengano riassegnate quando si riassegnano i record degli account cliente e dei contatti.
Test della sicurezza
Il modello di sicurezza è composto da più parti che lavorano sinergicamente e ha più aree in cui potrebbe non funzionare. In questa sezione del modello si esamina l'approccio da usare per testare la sicurezza, si individua il piano per monitorare l'accesso a Dynamics 365 e si verifica che la progettazione dei ruoli di sicurezza sia ben documentata e semplice da mantenere nel lungo termine.
Domande sulla sicurezza e perché sono importanti
Nella sezione del modello relativa ai test della sicurezza, rispondere alle seguenti domande.
Si dispone di ambienti di test per convalidare i dati nel contesto dei requisiti di sicurezza? - Per testare adeguatamente i ruoli di sicurezza, il cliente richiederà un ambiente non di produzione con la stessa configurazione dell'ambiente di produzione e un'approssimazione fedele del set di dati di produzione. Sebbene non sia necessario il 100% dei dati dalla produzione, i dati devono essere sufficientemente simili per testare accuratamente il comportamento dei ruoli di sicurezza. È anche importante avere utenti di test distinti e non riassegnare ruoli agli stessi utenti di test. Il motivo sta nel fatto che gli utenti che originariamente dispongono di autorizzazioni più elevate potrebbero mantenere l'accesso a determinati record quando si rimuove tale ruolo usando la proprietà o la condivisione dei record.
Si dispone del foglio Excel della matrice di sicurezza con i livelli e i privilegi di accesso definiti dalla propria azienda o dal cliente? È importante disporre di una documentazione sulla progettazione della sicurezza al di fuori del ruolo di sicurezza di Dynamics 365, nel caso in cui qualcuno modifichi il ruolo di sicurezza in Dynamics 365 e si desideri ricordare come era stato progettato. Questo documento può essere un foglio di calcolo di Excel che indica il livello di autorizzazioni appropriato per ogni tabella.
Si dispone di test case relativi alla matrice di sicurezza per tutti i ruoli di sicurezza? - I requisiti di sicurezza del cliente probabilmente derivano dai requisiti raccolti durante i precedenti workshop del progetto e questi requisiti creano la base dei test case sulla sicurezza. Ogni restrizione di sicurezza dovrebbe avere un test case ed essere testata a fondo prima di essere applicata. Quindi, le restrizioni dovrebbero essere testate nel contesto di ogni ruolo di sicurezza o utente tipo interessato.
Sono stati considerati test negativi su team e campi con sicurezza a livello di campo? - È importante verificare se qualcuno con un ruolo può vedere i campi protetti e può accedere ai record assegnati al proprio team. Inoltre, è necessario verificare che gli utenti senza questi ruoli o assegnazioni di team non possano accedere a questi elementi.
Verranno eseguiti test di penetrazione sulla piattaforma? - Per ambienti altamente sicuri, il test di penetrazione è un'opzione. Tenere presente che i test di penetrazione devono seguire le regole di impegno di Microsoft Cloud per i test di penetrazione. Per altre informazioni, consultare Regole di impegno per i test di penetrazione.
Altre domande sulla sicurezza di Dynamics 365
In questa sezione del modello si esamina la sicurezza relativa alle funzioni correlate all'interno di Dynamics 365.
Domande sulla sicurezza in Dynamics 365 e perché sono importanti
Fornire risposte alle seguenti domande.
È stato considerato il privilegio Esportazione in Excel? - Esportazione in Excel è una straordinaria e pratica funzionalità di creazione di report, ma può anche rappresentare un rischio perché in alcune società è capitato che i dipendenti portassero con sé i dati dei clienti all'uscita dall'azienda.
È importante essere prudenti e consapevoli che, sebbene il privilegio Esportazione in Excel possa impedire ad alcuni utenti di scaricare facilmente i dati da Dynamics 365 con il pulsante Esporta in Excel, chiunque abbia accesso in lettura a un record può accedere a quei dati tramite API e infine esportarli.
Se applicabile, come si prevede di controllare la sicurezza nel Servizio di esportazione dati, in Azure SQL o Esporta in data lake e Power BI? - Quando i dati escono da Microsoft Dataverse a scopo di creazione di report o integrazione, non sono più protetti dalla sicurezza di Dynamics 365. Le organizzazioni devono essere consapevoli di questo parametro e pianificare la sicurezza quando i dati lasciano il sistema.
Se applicabile, qual è la strategia del modello di sicurezza per i portali Power Pages e Unified Service Desk? - Power Pages consente di esporre i dati all'esterno e permette a parti esterne di aggiornare i dati di Dynamics 365. Tuttavia, è importante considerare le implicazioni di sicurezza di questa funzionalità e assicurarsi che i dati protetti e sensibili non vengano esposti alle persone sbagliate.
Se gli utenti ereditano i loro ruoli di sicurezza esclusivamente dai team, è stato preso in considerazione l'uso dell'impostazione Ereditarietà all'utente diretto nei ruoli di sicurezza? Quando si assegna un ruolo di sicurezza a un team proprietario (inclusi team del gruppo di sicurezza Microsoft Entra ID o team del gruppo ufficio Azure AD), è necessario controllare l'impostazione Ereditarietà privilegi dei membri per assicurarsi che sia impostata correttamente. Questa impostazione può consentire agli utenti membri del team di ereditare i privilegi a livello di utente (e non a livello di Business Unit o superiore) come se il ruolo di sicurezza fosse stato loro assegnato direttamente.
Questa funzionalità è utile nel consentire agli utenti di essere proprietari di record a loro nome, anche se non hanno un ruolo di sicurezza assegnato direttamente. Ad esempio, con questa impostazione, gli utenti possono essere proprietari di visualizzazioni personali. Con i team proprietari, non è necessario che i ruoli di sicurezza vengano concessi direttamente ai singoli utenti, il che aiuta a ridurre il carico di lavoro amministrativo.
Se si prevede di usare tabelle virtuali, è stata presa in considerazione la creazione di un modello di sicurezza basato su di esse? - Le tabelle virtuali consentono la creazione di tabelle che non archiviano dati in Dataverse ma puntano a un'origine dati esterna. Sebbene questa funzionalità sia utile e in molti casi preferibile a sovraccaricare di dati Dynamics 365, è necessario comprendere che la connessione della tabella virtuale usa un'unica origine dati, cioè tutti gli utenti che hanno accesso alla tabella virtuale vedranno gli stessi record. Se si dispone di record sensibili che non devono essere visibili a tutti gli utenti, si consiglia l'integrazione dei dati.
Monitoraggio della sicurezza
In questa sezione del modello si esamina la strategia del cliente per il monitoraggio dei diritti di accesso appropriati e si identifica l'uso improprio dell'applicazione. Se i controlli delle attività sono abilitati in Dynamics 365, molte attività degli utenti vengono registrate nell'interfaccia di amministrazione di Microsoft 365. Usando questi log, è possibile identificare attività insolite o potenzialmente dannose nel sistema, comprese azioni comuni come:
Chi ha pubblicato le personalizzazioni
Chi è stato aggiunto a un team
Chi ha aggiunto una soluzione
Chi ha pubblicato le personalizzazioni
Chi ha esportato in Excel
Chi ha visualizzato un report
Chi ha esportato un report
I log di controllo standard monitorano quando gli utenti accedono al sistema. Strumenti come Microsoft Power Automate possono segnalare quando si verificano determinate attività e Microsoft Entra ID può segnalare quando persone al di fuori delle normali aree geografiche tentano di accedere al sistema.
In questa sezione del modello del workshop sul modello di sicurezza si riepiloga la strategia per il monitoraggio e la segnalazione di comportamenti anomali e si indicano i piani per verificare regolarmente le autorizzazioni utente in Dynamics 365.
Normative e conformità
In questa sezione del modello si rileva se sono state implementate normative governative o di conformità che potrebbero influire sul modello di sicurezza per Dynamics 365. Queste normative includono regolamenti sulla protezione dei dati dei consumatori come HIPAA e SEC e aspetti di interesse dei revisori come la segmentazione aziendale. Completare le informazioni nella diapositiva su normative e conformità.
Sicurezza oltre Dynamics 365
In questa sezione del modello si esaminano altri sistemi che si integrano con Dynamics 365 e la sicurezza associata. Dynamics 365 non è autonomo: interagisce o è integrato con altri sistemi. È pertanto necessario adottare una visione olistica della sicurezza e non guardare semplicemente alla sicurezza dei singoli componenti. Aggiornare le diapositive Sicurezza oltre Dynamics 365 per rispondere alle seguenti domande.
Gli ambienti applicativi sono stati associati a un gruppo di sicurezza per controllare gli utenti che vi hanno accesso? - Associare un ambiente Dynamics 365 a un gruppo di sicurezza Microsoft Entra ID impedirà l'accesso all'ambiente agli utenti esterni al gruppo e limiterà gli utenti che verranno visualizzati come abilitati nel sistema. Inoltre, semplificherà l'esperienza per gli utenti perché solo gli ambienti a cui hanno accesso appariranno nell'elenco degli ambienti.
Si usa l'accesso condizionale in Microsoft Entra ID per controllare il modo in cui gli utenti accedono ai dati di Office 365/Dynamics 365? - L'accesso condizionale in Microsoft Entra ID può essere usato per limitare da dove e da quale dispositivo è possibile usare l'ambiente e quali servizi e connettori possono essere usati.
Si usa la gestione di dispositivi mobili per gestire una flotta di dispositivi (telefoni cellulari e così via)? - Usando soluzioni di gestione di dispositivi mobili (MDM), come Microsoft Intune, è possibile applicare la sicurezza, gestire da remoto la distribuzione delle app Dynamics 365 per dispositivi mobili e anche rimuovere i dati da remoto in caso di smarrimento o furto del dispositivo.
Si esegue l'integrazione con SharePoint? Se sì, come viene gestita la sicurezza in SharePoint rispetto alla sicurezza in Dynamics 365? - L'integrazione dei documenti di SharePoint automatizza la creazione di raccolte di documenti in SharePoint dai record di Dynamics 365 e fornisce agli utenti di Dynamics 365 un accesso rapido ai documenti archiviati in SharePoint. Potrebbero verificarsi problemi perché la sicurezza delle raccolte di documenti di SharePoint non rispecchia la sicurezza di Dynamics 365. Se qualcuno ha accesso al sito di SharePoint in cui sono archiviati i documenti di Dynamics 365, può visualizzare i documenti nella raccolta, anche se non dispone dell'accesso al record di Dynamics 365 correlato. Se questa situazione è può costituire un problema, è opportuno prendere in considerazione alternative in cui i diritti di accesso sono più ristretti sul lato SharePoint (ad esempio con più siti di SharePoint, l'integrazione di OneDrive for Business o l'integrazione di Teams).
Si esegue l'integrazione con Microsoft Power BI? Se sì, come viene gestita la sicurezza in Power BI rispetto alla sicurezza in Dynamics 365? - Quando si crea un report in Power BI direttamente da Dataverse tramite il connettore Microsoft Dataverse standard, in tale report vengono riflessi solo i dati a cui l'utente ha accesso nel sistema. Tuttavia, se si condivide il report di Power BI con altri utenti, questi vedranno i dati del proprietario del report.
È possibile implementare la sicurezza a livello di riga per applicare la sicurezza sul lato Power BI, ma un'altra opzione consiste nel creare un report SQL DirectQuery in Power BI che eseguirà il rendering nel contesto dell'utente connesso. Quindi, la condivisione di un report comporterà solo la condivisione della rappresentazione dei dati, non dei dati effettivi, e il modello di sicurezza di Dynamics 365 verrà applicato completamente.
Si usano altri meccanismi di sicurezza? - Altri meccanismi di sicurezza possono essere l'autenticazione a più fattori, provider di autenticazione esterni come OKTA e così via.
Il modello di sicurezza contiene dipendenze da soluzioni ISV (fornitori di software indipendenti)? Se sì, quali sono? - Gli ISV forniscono soluzioni preziose che possono migliorare la distribuzione di Dynamics 365, ma possono anche introdurre dipendenze e rischi per la sicurezza. È importante capire come verrà distribuita questa soluzione, come verrà aggiornata e quale tipo di accesso di sicurezza richiederanno gli ISV.
Quali sono i requisiti per gli schemi di sicurezza dell'integrazione dei dati? - Quando i dati fluiscono tra i sistemi, è importante capire quando sarà necessario controllare la sicurezza a livello di flusso. Assicurarsi di determinare quale accesso di sicurezza sarà necessario per l'integrazione al sistema di origine, quale accesso di sicurezza richiederà l'integrazione in Dynamics 365 e con quale account verrà eseguito il processo di integrazione. Si consiglia di usare gli utenti dell'applicazione (non interattivi) per controllare l'accesso per gli account di integrazione.
Se si usano altre funzionalità di Microsoft Power Platform, come Power Automate e Power Apps, quali sono i requisiti e la progettazione della sicurezza? - Power Apps e Power Automate usano connettori per l'integrazione con centinaia di sistemi diversi e questi strumenti fanno parte della stessa piattaforma di Dynamics 365. Le app canvas in Power Apps e i flussi Power Automate usano Dataverse, così come Dynamics 365, e app e flussi possono essere gestiti nelle soluzioni insieme agli altri componenti di Dynamics 365. L'introduzione di altri connettori nel processo richiede una serie di considerazioni aggiuntive sulla sicurezza, tra cui l'accesso ai dati e la sicurezza in quei sistemi e la strategia ambientale nei luoghi in cui si creano app e flussi che entrano in contatto con l'ambiente Dynamics 365 di produzione. Altre considerazioni sulla sicurezza riguardano l'accesso per i creatori che si connettono all'ambiente Dataverse di produzione e i criteri di prevenzione della perdita di dati che determinano quali connettori possono essere usati insieme. L'architetto della soluzione dovrebbe porre domande per chiarire quali siano la strategia ambientale e di prevenzione della perdita dei dati in Microsoft Power Platform, quindi identificare le autorizzazioni che avranno gli utenti per creare app e flussi.
Esistono specifici requisiti di sicurezza dell'infrastruttura (crittografia e così via)? - Dynamics 365 offre opzioni di crittografia avanzate, incluse chiavi gestite dal cliente per scenari idonei. Capire se queste opzioni vengono usate e se il cliente ha stabilito una strategia per mantenere questi metodi nel lungo termine.