Introduzione

30 minuti

Per garantire che la distribuzione di Microsoft Dynamics 365 sia più sicura per il cliente, l'architetto di soluzioni pianifica e offre un workshop sul modello di sicurezza. L'obiettivo del workshop è valutare il modello di sicurezza proposto e fornire un feedback e i suggerimenti che evidenzino i rischi e i problemi tecnici e quindi identificare le procedure consigliate.

Il workshop sul modello di sicurezza deve essere pianificato e completato durante la fase di implementazione del progetto. Fornisce un riepilogo di tutte le aree relative alla sicurezza discusse durante i workshop precedenti.

È possibile scaricare esempi di modelli per ogni workshop sul modulo e usarli per condurre gli workshop per le soluzioni.

Perché la sicurezza è importante

Dynamics 365 guida le attività dei clienti. I dati aziendali sensibili relativi ai clienti, le informazioni finanziarie e i processi di business critici devono essere protetti per i clienti che adottano il sistema.

La strategia di sicurezza corretta bilancia i requisiti di sicurezza legittimi con le esigenze di accesso al sistema e di collaborazione tra le aziende. Durante l'implementazione di Dynamics 365 è necessario trovare un equilibrio tra due fattori essenziali, l'accesso degli utenti e la sicurezza del sistema.

Da un certo punto di vista, la problematica della sicurezza dei dati e del sistema è importante. I dati guidano il business. I clienti, gli ordini, le informazioni dei contatti commerciali chiave sono elementi che non possono cadere nelle mani della concorrenza. Con le normative relative ai dati personali, le società possono essere ritenute responsabili delle violazioni che interessano i dati personali.

Altri fattori importanti sono l'usabilità del sistema e l'adozione da parte degli utenti. Uno dei motivi principali per l'implementazione di Dynamics 365 è l'aumento della visibilità e della condivisione dei dati aziendali tra i gruppi, inclusa l'eliminazione dei silos di dati dell'organizzazione. Dando visibilità ai contatti e agli account nell'organizzazione, i team possono collaborare in modo efficace anziché competere tra loro, garantendo un'unica fonte di attendibilità quando si tratta di informazioni sui contatti e sugli account principali. Se ci si discosta troppo in entrambe le direzioni, si rischia il fallimento dell'implementazione.

Se si gestisce la sicurezza con troppa tolleranza, gli utenti possono modificare i dati che non dovrebbero essere in grado di modificare, inquinando così l'unica fonte di attendibilità e creando la percezione che i dati nel sistema non siano affidabili.

Se la sicurezza è troppo rigida e impone limitazioni eccessive agli utenti, che possono vedere solo un subset ridotto dei record nel sistema, il valore di Dynamics 365 come strumento di collaborazione risulterà limitato. Quindi, a livello di progettazione si torna ai vecchi silos di dati, solo in una posizione diversa.

Considerazioni sul modello di sicurezza

Prima di scoprire i dettagli del workshop, le sezioni seguenti illustrano i principali elementi di sicurezza comuni alla maggior parte delle implementazioni di Dynamics 365.

Creazione di una strategia di sicurezza

Sebbene ogni singola strategia di sicurezza sarà leggermente diversa, le seguenti linee guida possono essere utili per l'implementazione.

Maggiori restrizioni per la scrittura che per la lettura

Per mantenere una buona qualità dei dati, è consigliabile limitare chi può modificare o eliminare i record, ad esempio definire i diritti di modifica o eliminazione solo per i proprietari dei record. Spesso ha più senso essere meno restrittivi sui record che possono essere letti da altri utenti. Questo approccio preserva l'usabilità di Dynamics 365 e consente agli utenti di mantenere il contesto sulla relazione tra i propri e altri record, ad esempio gli account padre. Tuttavia, l'approccio elimina il rischio che gli utenti possano, per dolo o errore, modificare o eliminare record di cui non sono proprietari.

Semplificazione

Molti strumenti sono inclusi nella casella degli strumenti di sicurezza di Dynamics 365, tuttavia prima di decidere di usarli tutti, è opportuno considerare quanto potrebbe essere semplice gestire il modello di sicurezza a lungo termine. Se l'amministratore deve ricordarsi di assegnare quattro ruoli diversi a un nuovo utente e quindi aggiungerlo a più team affinché il modello di sicurezza funzioni, è improbabile che il cliente sia in grado di mantenere la strategia a lungo termine. L'architetto di soluzioni deve considerare l'impatto della progettazione della sicurezza nell'esperienza utente. Inoltre, deve determinare quanto complessa è la gestione della strategia di sicurezza per gli amministratori di sistema. Le migliori strategie di sicurezza sono semplici, ben documentate e riproducibili. Per questo motivo, l'uso di funzionalità come i gruppi di sicurezza di Active Directory è un'ottima idea per distribuzioni più grandi e complesse perché l'assegnazione di ruoli, team e Business Unit può essere automatizzata e la possibilità di errore umano è ridotta al minimo.

Progettazione della sicurezza sempre basata su requisiti aziendali legittimi

Determinare se le decisioni sulla progettazione della sicurezza derivano da una posizione di timore o da un legittimo interesse aziendale. Se per timore, forse la decisione è stata dettata da un errore che qualcuno ha commesso in passato. Il timore non è mai una buona motivazione per la progettazione, soprattutto il timore dei dipendenti. Fidarsi dei dipendenti che svolgono il loro lavoro, rappresentano l'azienda e vendono i prodotti. Occasionalmente, una progettazione della sicurezza eccessivamente rigorosa è indicazione di problemi di fiducia fondamentali tra la direzione e i dipendenti.

Documentazione e rivalutazione della progettazione della sicurezza

La progettazione della sicurezza è un concetto che viene preso in considerazione all'inizio di un'implementazione di Dynamics 365, ma in seguito può essere occasionalmente trascurato. Periodicamente, quando i modelli di uso del cliente o la base di utenti cambiano, le decisioni iniziali sulla progettazione della sicurezza non sono più la soluzione migliore e devono essere adattate.

Ad esempio, quando si dispone di una base di utenti ridotta, la progettazione di una singola Business Unit può essere adatta. Tuttavia, se la base di utenti cresce e comprende più reparti con requisiti diversi, potrebbe essere necessario aggiungere più unità per scalare la distribuzione a una base di utenti più ampia. Non è stata stabilita alcuna regola assoluta, la procedura consigliata consiste nel rivedere periodicamente la strategia e la progettazione della sicurezza, valutarne i punti di forza e di debolezza e quindi identificare le aree di miglioramento. Per questo motivo, documentare il modello di sicurezza come parte del framework Success by Design è importante perché crea la documentazione che può essere rivisitata in modo intermittente dal cliente e dal consulente e quindi aggiornata al variare dei requisiti di sicurezza.

La strategia di sicurezza alla base delle scelte di configurazione

Quando il cliente o il partner progetta la struttura della tabella deve tenere a mente la strategia di sicurezza. La configurazione della tabella supporta la strategia di sicurezza. Ad esempio, se le tabelle vengono create con la proprietà a livello di organizzazione, il cliente non è in grado di limitare l'accesso ai record della tabella in base alla proprietà o alla Business Unit. Anche se non si prevede di limitare l'accesso alla tabella, è consigliabile selezionare sempre la proprietà dell'utente o del team, a meno che la tabella non venga usata solo per i dati di riferimento interaziendali, ad esempio l'invio di un elenco di ricerca. Inoltre, occorre tenere presente come la sicurezza di una tabella influisce sulla sicurezza della tabella correlata. Se l'accesso a un record padre deve estendersi ai record figlio, è necessario usare i tipi di relazione a cascata configurabili o padre-figlio.

Sicurezza a livello di piattaforma e non a livello di app

Sono disponibili numerosi modi per controllare la lettura e la modifica dei dati. È possibile impostare i campi in sola lettura nel modulo basato su modello, usare JavaScript per mascherare i campi escludendoli dall'esperienza utente e nascondere campi e viste. Nessuno di questi approcci è considerato di sicurezza perché, sebbene determinino il comportamento degli utenti, non proteggono i dati. Gli utenti possono accedere ai dati in altri modi. Affinché si ottenga una vera sicurezza, è necessario usare le funzionalità di sicurezza come ruoli, team e Business Unit.

Componenti del modello di sicurezza

Dynamics 365 offre diversi strumenti che si possono usare collettivamente per soddisfare quasi tutti i requisiti di sicurezza. Questa sezione illustra brevemente gli strumenti principali a disposizione di un architetto di soluzioni per fornire un modello di sicurezza completo.

Business Unit

Le Business Unit forniscono un framework per definire la struttura organizzativa degli utenti e dei record in Dynamics 365. Le Business Unit raggruppano utenti e team in base a una gerarchia organizzativa e possono usare i ruoli di sicurezza per concedere o limitare l'accesso ai dati.

La capacità delle Business Unit deriva dalla natura gerarchica delle stesse. Gli utenti possono avere accesso ai record solo nella propria Business Unit oppure possono avere accesso alla propria Business Unit e alle Business Unit presenti sotto la propria. Ad esempio, la natura gerarchica delle Business Unit può consentire di limitare l'accesso ai record a livello di sito, distretto, area geografica e azienda.

I fattori più rilevanti sulle Business Unit sono:

La Business Unit radice viene creata quando viene eseguito il provisioning di un database Microsoft Dataverse.
Un utente o un team può essere membro di una sola Business Unit.
I record sono collegati a una sola Business Unit tramite l'utente o il team proprietario.
Un utente o un team può essere spostato in una Business Unit diversa. Quando si sposta un utente o un team tra le Business Unit, è possibile che si debbano riassociare tutti i record di proprietà dell'utente o del team alla nuova Business Unit e le persone con l'impostazione di sicurezza di lettura a livello di Business Unit nella precedente Business Unit perdono l'accesso ai record.
Quando si sposta un utente o un team in una nuova Business Unit, tutti i ruoli di sicurezza devono essere riapplicati all'utente o al team.
Le Business Unit non radice possono essere eliminate dopo essere state disabilitate.
Le Business Unit possono essere spostate nella gerarchia, ma la Business Unit radice non può essere riassociata a nuovo elemento padre.

La struttura della Business Unit tipica assomiglia all'organigramma di un'azienda, ma non è così granulare come un'organigramma, a meno che non vi sia un motivo aziendale specifico per farlo. Le Business Unit sono elementi costitutivi del modello di sicurezza. Nella maggior parte dei casi, non è necessario creare una Business Unit per ogni reparto dell'azienda. Ad esempio, i reparti vendite e marketing di un sito potrebbero condividere la stessa Business Unit se non si devono limitare i record tra i gruppi. Tenere presente che con le Business Unit si usano i ruoli di sicurezza, quindi anche se i reparti vendite e marketing si trovano nella stessa Business Unit, gli utenti non vedono tutti i record se i loro ruoli di sicurezza li limitano al livello di utente.

Ruoli di sicurezza

I ruoli di sicurezza determinano il livello di autorizzazione di cui dispongono gli utenti all'interno delle entità dell'organizzazione. I ruoli di sicurezza possono essere assegnati agli utenti o ai team. I ruoli di sicurezza determinano le entità a cui l'utente può accedere, su quali record della tabella può agire e quali autorizzazioni ha rispetto ai record.

Una volta assegnato a un utente o a un team, il ruolo di sicurezza si applica sempre nell'ambito della Business Unit dell'utente o del team. Pertanto, se un utente eredita un ruolo di sicurezza da un team, i privilegi concessi da tale ruolo di sicurezza vengono applicati nell'ambito della Business Unit del team e non dell'utente. Questo approccio può essere utile per estendere l'ambito dei diritti di accesso di un utente ad altre Business Unit. Ad esempio, usando il diagramma della Business Unit precedente, un utente della Business Unit dell'ufficio di Chicago può essere aggiunto a un team collegato alla Business Unit dell'ufficio di Atlanta e gli vengono concessi i diritti di lettura per i record della Business Unit.

Team

I team sono un altro modo per raggruppare gli utenti e possono svolgere un ruolo nella strategia di sicurezza. Diversi tipi di team sono disponibili in Dynamics 365:

I team proprietari possono essere assegnati ai ruoli di sicurezza e possono essere usati come proprietari di record in Dynamics 365. Quando un utente viene aggiunto come membro di un team proprietario eredita il ruolo di sicurezza del team, ma il ruolo si applica nel contesto della Business Unit del team. I team proprietari possono essere utili quando si collega un record a una specifica Business Unit.
I team del gruppo di sicurezza di Microsoft Entra ID sono simili ai team proprietari, ma sono collegati a un gruppo di sicurezza di Microsoft Entra ID. Gli utenti che vengono aggiunti al gruppo di sicurezza di Microsoft Entra ID con una licenza Dynamics 365 vengono abilitati automaticamente nel sistema e vengono aggiunti al team Dynamics 365 collegato quando si connettono all'ambiente. Questa funzionalità è utile quando si gestiscono i diritti di accesso degli utenti al di fuori di Dynamics 365 perché gli utenti possono ereditare i ruoli di sicurezza assegnati ai team di Dynamics 365.
I team del gruppo ufficio Microsoft Entra ID sono simili ai team dei gruppi di sicurezza di Microsoft Entra ID, tranne per il fatto che usano un gruppo di Office 365 invece di un gruppo di sicurezza di Microsoft Entra ID. La differenza principale è che i gruppi di Office 365 possono essere creati e la gestione dei gruppi può essere eseguita da persone che non sono amministratori di Active Directory.
I team di accesso sono tipi speciali di team che non possono essere proprietari di record e non possono essere associati ai ruoli di sicurezza. Tuttavia, come i team proprietari, i team di accesso possono avere record condivisi. Se abilitati a livello di tabella, i team di accesso possono concedere autorizzazioni specifiche a livello di record al membro del team di accesso del record. Questa opzione è un'alternativa alla condivisione manuale del record con un utente o un team. Per le entità configurate per i team di accesso, la creazione di questi team è automatizzata tramite i modelli di team di accesso.

Quando si assegna un ruolo di sicurezza a un team proprietario (inclusi team del gruppo di sicurezza di Azure AD o team del gruppo ufficio Microsoft Entra ID), è necessario controllare l'impostazione dell'ereditarietà dei 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, come se il ruolo di sicurezza fosse stato loro assegnato direttamente. Questa funzione è utile quando si consente agli utenti di essere proprietari di record, 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.

Sicurezza gerarchica

La sicurezza gerarchica può essere usata per concedere visibilità ai record di proprietà degli utenti ai responsabili della gestione degli utenti e ai livelli superiori della gerarchia. Ad esempio, se un responsabile delle vendite con un team di cinque persone ha bisogno di vedere i record di proprietà di un membro del team, la sicurezza gerarchica può fornirgli l'accesso. La sicurezza gerarchica supporta due diversi modelli di gerarchia:

Gerarchia del responsabile: concede l'accesso in base alla relazione del responsabile. Con il modello di sicurezza della gerarchia del responsabile, un responsabile ha accesso ai record di proprietà dell'utente o del team di cui l'utente è membro e ai record condivisi direttamente con l'utente o il team di cui l'utente è membro.
Gerarchia delle posizioni: concede l'accesso in base a livelli di posizione definibili. Questo modello è utile quando è necessario fornire un accesso di sicurezza basato su strutture di subordinati indiretti. Con il modello di sicurezza della gerarchia delle posizioni, un utente in una posizione più alta ha accesso ai record di proprietà dell'utente in una posizione più bassa o del team di cui l'utente è membro e ai record condivisi direttamente con l'utente o il team di cui l'utente è membro.

Sicurezza del campo

La sicurezza del campo consente di proteggere i dati a livello di campo, ad esempio quando determinati utenti devono visualizzare o modificare un record ma non devono vedere specifici dettagli. Questa funzionalità è importante nelle situazioni in cui i dati devono essere veramente sicuri perché sono protetti a livello di piattaforma. In sostanza, se un utente accede a un'app basata su modello o a un'app canvas, esporta i dati in Microsoft Excel o esegue un report, i profili di sicurezza del campo proteggono i dati.

Dopo che a un utente è stato concesso l'accesso (ad esempio, in lettura) a un set di campi protetti tramite un profilo di sicurezza del campo, ha l'accesso ai campi su tutti i record a cui ha accesso con la configurazione di sicurezza o tramite condivisione.

La condivisione consente di concedere un accesso specifico a livello di record a utenti e team specifici. L'uso della condivisione deve essere limitato alla gestione delle eccezioni, se possibile. In precedenza era comune usare e automatizzare la condivisione dei record per scenari complessi di accesso ai record. La condivisione è un approccio vantaggioso perché offre agli amministratori e agli utenti, che dispongono delle autorizzazioni appropriate, la possibilità di concedere autorizzazioni specifiche a record specifici e per gestire le eccezioni alla regola. Ad esempio, se il venditore A deve gestire i clienti del venditore B mentre è fuori per un mese, la condivisione può essere utile per svolgere questa attività. La condivisione può anche essere automatizzata, pertanto in presenza di una condizione specifica per condividere automaticamente i record con un utente o un team, è possibile usare semplici plug-in, assembly di flussi di lavoro o strumenti ETL per farlo. Questa funzionalità è stata la risposta ai severi requisiti di sicurezza di molti clienti di Dynamics 365 in passato.

Sebbene la condivisione sia una funzionalità utile, crea anche molteplici potenziali problemi, tra cui:

Prestazioni: la condivisione è facilitata dalla tabella accesso a oggetti e entità. Quando condividi un record con un utente o un team, nella tabella accesso a oggetti e entità viene creato un record contenente l'ID dell'utente, l'ID del record e l'autorizzazione che deve avere. La natura a catena della condivisione significa che se esiste una relazione a catena padre-figlio o configurabile che è abilitata alla condivisione, anche i record figlio in tali relazioni verranno condivisi con l'utente o il team e ulteriori record vengono aggiunti alla tabella accesso a oggetti e entità. Anche gli scenari complessi di condivisione riassociata a un nuovo elemento padre o ereditata possono creare record e quindi le dimensioni della tabella accesso a oggetti e entità possono crescere rapidamente. Questo scenario diventa un problema di prestazioni quando la tabella si espande tra 20 milioni e 2 miliardi di record. Quando si esegue una query in Dynamics 365, ad esempio quando si apre una visualizzazione o una ricerca avanzata, o quando si visualizza un grafico, i risultati vengono filtrati in base alla tabella accesso a oggetti e entità. Se la tabella è grande o gli indici non sono ottimizzati, le prestazioni del sistema possono risultare rallentate.
Problematiche di amministrazione: non è possibile identificare facilmente quali record sono condivisi con un utente. Sebbene sia possibile selezionare un record e visualizzare con chi è condiviso direttamente, non esiste un metodo per svolgere questa attività per tutti i record. Inoltre, le condivisioni a catena o ereditate non vengono visualizzate nella finestra di dialogo di condivisione del record. Se non si apre ogni record nel contesto dell'utente, è quasi impossibile sapere se la strategia di condivisione funziona correttamente.
Condivisioni dimenticate: in precedenza è stato illustrato uno scenario in cui si condividevano i record del venditore B con il venditore A che gestiva i clienti del collega mentre era in ferie per un mese. È possibile che l'amministratore dimentichi di interrompere la condivisione dei record, il che potrebbe creare problemi se il venditore B ha bisogno di riconnettersi alle persone nel proprio flusso di lavoro.
Insoddisfazione: dopo che il cliente ha usato il sistema per un anno o due, potrebbe scoprire che è diventato impreciso o non aggiornato. Potrebbe anche decidere di apportare un cambiamento relativo all'ingrosso alla strategia di condivisione e pertanto vuole eseguire un processo batch per impostare e aggiornare tutti i record con l'autorizzazione di condivisione appropriata. Non esiste un metodo semplice per completare questa attività con la condivisione.

I passaggi disponibili per evitare problemi con la condivisione sono:

Uso della proprietà del team: con la proprietà del team è possibile assegnare i record ai team di utenti in più Business Unit.
Condivisione con i team, non con gli utenti: se si condivide un record con 10 utenti, vengono creati 10 record di accesso a oggetti e entità, moltiplicato per 10 record di accesso a oggetti e entità per ogni record figlio condiviso a cascata. Se si condivide il record con un team che ha 10 utenti, viene creato un solo record di accesso a oggetti e entità, insieme a un record di accesso a oggetti e entità per ogni condivisione a cascata. Questo approccio può ridurre drasticamente le dimensioni della tabella accesso a oggetti e entità. È possibile rimuovere le autorizzazioni di un utente dal team.
Uso dei team di accesso per la condivisione controllata: questo approccio è utile se non è possibile creare team proprietari ma si desidera comunque avere la possibilità di concedere un accesso speciale a record specifici per utenti specifici. In questo scenario, si concede a determinati utenti l'accesso solo per leggere il record, mentre si desidera che altri utenti possano leggere o scrivere nel record. I team di accesso possono gestire questa situazione con la possibilità di avere più modelli di team di accesso, uno per la lettura e uno per lettura e scrittura. I team di accesso sono progettati tenendo conto delle prestazioni, quindi non creano effettivamente il team e non condividono il record finché non si aggiunge il primo membro del team. Quando un record viene condiviso con un team di accesso, viene creato anche un record nella tabella accesso a oggetti e entità.

Scenario di sicurezza di esempio

Lo scenario seguente illustra come questi strumenti possono essere combinati per fornire un modello di sicurezza completo. In questo esempio, Contoso LTD è una società di prodotti di consumo che vuole che gli utenti abbiano accesso alle informazioni necessarie per svolgere il proprio lavoro proteggendo i dati sensibili. Combinando gli strumenti di sicurezza in Dynamics 365, l'azienda può affrontare ciascuno dei seguenti scenari.

Bob

La sicurezza a livello di campo impedisce a Bob di visualizzare informazioni sensibili su un record e la sicurezza del team o della business unit ne limita la visione solo ai problemi dell'azienda.

Tecnico di produzione
Deve essere in grado di esaminare i problemi di qualità segnalati dai clienti
Non deve essere in grado di vedere l'indirizzo e-mail e il telefono cellulare del cliente
Non deve essere in grado di vedere i problemi di altre società

Amy

La sicurezza della Business Unit significa che Amy può vedere i record di proprietà di qualcun altro nella sua divisione, ma che non può vedere o modificare i record in altre divisioni.

Rappresentante del servizio clienti
Crea casi di servizio clienti dai reclami
Deve essere in grado di vedere le informazioni sui clienti e la cronologia dei casi per i clienti che usano i prodotti della sua divisione
Non deve essere in grado di vedere i dati dei clienti di altre divisioni

Roy

La sicurezza gerarchica consente a Roy di vedere i record di proprietà dei suoi subordinati diretti o indiretti, ma non di altri utenti.

Responsabile delle vendite
Deve poter vedere i record dei suoi subordinati diretti
Non deve vedere i dati di altri responsabili delle vendite

Linda

Il ruolo di sicurezza di Linda fornisce la visibilità a livello di organizzazione dei dati in Dynamics 365.

Responsabile generale
Deve avere la visibilità di tutti i dati dei clienti e problemi correlati

Workshop sul modello di sicurezza

Il workshop sul modello di sicurezza deve essere limitato a circa un'ora ed è spesso condotto tramite una riunione di Microsoft Teams quando i partecipanti non sono tutti nella stessa sede. I partecipanti devono includere gli stakeholder chiave dei team dei clienti e dei partner. La partecipazione di architetti di soluzioni, lead funzionali e lead tecnici è obbligatoria.

È necessario fare riferimento ai dettagli di sicurezza del modello del workshop sul progetto iniziale della soluzione in preparazione per il workshop sul modello di sicurezza.