Architetture e procedure consigliate per le raccolte di Microsoft Purview

Alla base delle soluzioni di governance dei dati unificate di Microsoft Purview, la mappa dati è un componente PaaS (Platform as a Service) che mantiene una mappa aggiornata degli asset e dei relativi metadati nell'intero patrimonio dati. Per idratare la mappa dati, è necessario registrare ed analizzare le origini dati. In un'organizzazione potrebbero essere presenti migliaia di origini di dati gestite e gestite da team centralizzati o decentralizzati.

Le raccolte in Microsoft Purview supportano il mapping aziendale dei metadati. Usando le raccolte, è possibile gestire e gestire origini dati, analisi e asset in una gerarchia anziché in una struttura flat. Le raccolte consentono di creare un modello gerarchico personalizzato del panorama dei dati in base al modo in cui l'organizzazione prevede di usare Microsoft Purview per gestire il panorama.

Una raccolta fornisce anche un limite di sicurezza per i metadati nella mappa dati. L'accesso a raccolte, origini dati e metadati viene configurato e gestito in base alla gerarchia delle raccolte in Microsoft Purview, seguendo un modello con privilegi minimi:

  • Gli utenti hanno la quantità minima di accesso di cui hanno bisogno per eseguire il proprio lavoro.
  • Gli utenti non hanno accesso ai dati sensibili di cui non hanno bisogno.

Perché è necessario definire raccolte e un modello di autorizzazione per l'account Microsoft Purview?

Prendere in considerazione la distribuzione di raccolte in Microsoft Purview per soddisfare i requisiti seguenti:

  • Organizzare le origini dati, distribuire gli asset ed eseguire analisi in base ai requisiti aziendali, alla distribuzione geografica dei dati e ai team, ai reparti o alle funzioni aziendali di gestione dei dati.

  • Delegare la proprietà delle origini dati e degli asset ai team corrispondenti assegnando ruoli alle raccolte corrispondenti.

  • Cercare e filtrare gli asset in base alle raccolte.

Definire una gerarchia di raccolta

Consigli per la progettazione

  • È consigliabile progettare l'architettura della raccolta in base ai requisiti di sicurezza e alla struttura di gestione e governance dei dati dell'organizzazione. Esaminare gli archetipi di raccolte consigliati in questo articolo.

  • Per la scalabilità futura, è consigliabile creare una raccolta di primo livello per l'organizzazione sotto la raccolta radice. Assegnare ruoli pertinenti nella raccolta di primo livello anziché nella raccolta radice.

  • Prendere in considerazione la gestione della sicurezza e degli accessi come parte del processo decisionale di progettazione quando si compilano raccolte in Microsoft Purview.

  • Ogni raccolta ha un attributo name e un attributo di nome descrittivo. Se si usa il portale di governance di Microsoft Purview per distribuire una raccolta, il sistema assegna automaticamente un nome casuale di sei lettere alla raccolta per evitare la duplicazione. Per ridurre la complessità, evitare di usare nomi descrittivi duplicati nelle raccolte, soprattutto nello stesso livello.

  • Attualmente, un nome di raccolta può contenere fino a 36 caratteri e un nome descrittivo della raccolta può avere fino a 100 caratteri.

  • Quando è possibile, evitare di duplicare la struttura organizzativa in una gerarchia di raccolta profondamente annidata. Se non è possibile evitare di farlo, assicurarsi di usare nomi diversi per ogni raccolta nella gerarchia per semplificare la distinzione delle raccolte.

  • Automatizzare la distribuzione delle raccolte usando l'API se si prevede di distribuire raccolte e assegnazioni di ruolo in blocco.

  • Usare un nome dell'entità servizio dedicato (SPN) per eseguire operazioni sulle raccolte e l'assegnazione di ruolo usando l'API. L'uso di un nome SPN riduce il numero di utenti con diritti elevati e segue le linee guida sui privilegi minimi.

Considerazioni sulla progettazione

  • Ogni account Microsoft Purview viene creato con una raccolta radice predefinita. Il nome della raccolta radice corrisponde al nome dell'account Microsoft Purview. La raccolta radice non può essere rimossa. Per modificare il nome descrittivo della raccolta radice, è possibile modificare il nome descrittivo dell'account Microsoft Purview da Microsoft Purview Management Center.

  • Le raccolte possono contenere origini dati, analisi, asset e assegnazioni di ruolo.

  • Una raccolta può avere il numero di raccolte figlio necessarie. Ogni raccolta può tuttavia avere una sola raccolta padre. Non è possibile distribuire raccolte sopra la raccolta radice.

  • Le origini dati, le analisi e gli asset possono appartenere a una sola raccolta.

  • Una gerarchia di raccolte in Microsoft Purview può supportare fino a 256 raccolte, con un massimo di otto livelli di profondità. Questa operazione non include la raccolta radice.

  • Per impostazione predefinita, non è possibile registrare più volte le origini dati in un singolo account Microsoft Purview. Questa architettura consente di evitare il rischio di assegnare livelli diversi di controllo di accesso a una singola origine dati. Se più team utilizzano i metadati di una singola origine dati, è possibile registrare e gestire l'origine dati in una raccolta padre. È quindi possibile creare analisi corrispondenti in ogni sottoraccolta in modo che gli asset pertinenti vengano visualizzati in ogni raccolta figlio.

  • Le connessioni di derivazione e gli artefatti vengono collegati alla raccolta radice anche se le origini dati sono registrate in raccolte di livello inferiore.

  • Quando si esegue una nuova analisi, per impostazione predefinita l'analisi viene distribuita nella stessa raccolta dell'origine dati. Facoltativamente, è possibile selezionare una sottoraccolta diversa per eseguire l'analisi. Di conseguenza, gli asset appartengono alla sottoraccolta.

  • È possibile eliminare una raccolta se non dispone di asset, analisi associate, origini dati o raccolte figlio.

  • Le origini dati, le analisi e gli asset devono appartenere a una raccolta se esistono nella mappa dati di Microsoft Purview.

  • Lo spostamento di origini dati tra raccolte è consentito se all'utente viene concesso il ruolo Amministrazione origine dati per le raccolte di origine e di destinazione.

  • Lo spostamento di asset tra raccolte è consentito se all'utente viene concesso il ruolo Curatore dati per le raccolte di origine e di destinazione.

  • Per eseguire operazioni di spostamento e ridenominazione in una raccolta, esaminare le raccomandazioni e le considerazioni seguenti:

    1. Per rinominare una raccolta, è necessario essere membri del ruolo di amministratore della raccolta.

    2. Per spostare una raccolta, è necessario essere membri del ruolo di amministratore della raccolta nelle raccolte di origine e di destinazione.

Definire un modello di autorizzazione

I ruoli del piano dati di Microsoft Purview vengono gestiti in Microsoft Purview. Dopo aver distribuito un account Microsoft Purview, all'autore dell'account Microsoft Purview vengono assegnati automaticamente i ruoli seguenti nella raccolta radice. È possibile usare il portale di governance di Microsoft Purview o un metodo programmatico per assegnare e gestire direttamente i ruoli in Microsoft Purview.

  • Gli amministratori della raccolta possono modificare le raccolte di Microsoft Purview e i relativi dettagli e aggiungere sottoraccolte. Possono anche aggiungere utenti ad altri ruoli di Microsoft Purview nelle raccolte in cui sono amministratori.
  • Gli amministratori dell'origine dati possono gestire le origini dati e le analisi dei dati.
  • I curatori dei dati possono creare, leggere, modificare ed eliminare gli asset di dati del catalogo e stabilire relazioni tra gli asset.
  • I lettori di dati possono accedere ma non modificare gli asset di dati del catalogo.

Consigli per la progettazione

  • Prendere in considerazione l'implementazione dell'accesso di emergenza o di una strategia di interruzione per il ruolo Collection Amministrazione a livello di raccolta radice di Microsoft Purview per evitare blocchi a livello di account Microsoft Purview. Documentare il processo per l'uso degli account di emergenza.

    Nota

    In alcuni scenari, potrebbe essere necessario usare un account di emergenza per accedere a Microsoft Purview. Potrebbe essere necessario questo tipo di account per risolvere i problemi di accesso a livello di organizzazione quando nessun altro può accedere a Microsoft Purview o quando altri amministratori non possono eseguire determinate operazioni a causa di problemi di autenticazione aziendale. È consigliabile seguire le procedure consigliate di Microsoft per l'implementazione di account di accesso di emergenza usando utenti solo cloud.

    Seguire le istruzioni in questo articolo per ripristinare l'accesso alla raccolta radice di Microsoft Purview se la raccolta precedente Amministrazione non è disponibile.

  • Ridurre al minimo il numero di amministratori della raccolta radice. Assegnare un massimo di tre utenti collection Amministrazione nella raccolta radice, inclusi l'SPN e gli account break-glass. Assegnare la raccolta Amministrazione ruoli alla raccolta di primo livello o alle sottoraccolte.

  • Assegnare ruoli ai gruppi anziché ai singoli utenti per ridurre il sovraccarico amministrativo e gli errori nella gestione dei singoli ruoli.

  • Assegnare l'entità servizio nella raccolta radice a scopo di automazione.

  • Per aumentare la sicurezza, abilitare l'accesso condizionale di Azure AD con l'autenticazione a più fattori per almeno amministratori della raccolta, amministratori dell'origine dati e curatori dei dati. Assicurarsi che gli account di emergenza siano esclusi dai criteri di accesso condizionale.

Considerazioni sulla progettazione

  • La gestione degli accessi di Microsoft Purview è stata spostata nel piano dati. I ruoli di Azure Resource Manager non vengono più usati, quindi è consigliabile usare Microsoft Purview per assegnare i ruoli.

  • In Microsoft Purview è possibile assegnare ruoli a utenti, gruppi di sicurezza ed entità servizio (incluse le identità gestite) da Azure Active Directory (Azure AD) nello stesso tenant di Azure AD in cui viene distribuito l'account Microsoft Purview.

  • È prima necessario aggiungere account guest al tenant di Azure AD come utenti B2B prima di poter assegnare i ruoli di Microsoft Purview agli utenti esterni.

  • Per impostazione predefinita, gli amministratori della raccolta non hanno accesso agli asset di lettura o modifica. Ma possono elevare l'accesso e aggiungersi a più ruoli.

  • Per impostazione predefinita, tutte le assegnazioni di ruolo vengono ereditate automaticamente da tutte le raccolte figlio. È tuttavia possibile abilitare Limita le autorizzazioni ereditate per qualsiasi raccolta, ad eccezione della raccolta radice. Limitare le autorizzazioni ereditate rimuove i ruoli ereditati da tutte le raccolte padre, ad eccezione del ruolo Raccolta Amministrazione.

  • Per Azure Data Factory connessione: per connettersi a Azure Data Factory, è necessario essere una raccolta Amministrazione per la raccolta radice.

  • Se è necessario connettersi a Azure Data Factory per la derivazione, concedere il ruolo Curatore dati all'identità gestita della data factory a livello di raccolta radice di Microsoft Purview. Quando si connette Data Factory a Microsoft Purview nell'interfaccia utente di creazione, Data Factory tenta di aggiungere automaticamente queste assegnazioni di ruolo. Se si dispone del ruolo Collection Amministrazione nella raccolta radice di Microsoft Purview, questa operazione funzionerà.

Archetipi delle raccolte

È possibile distribuire la raccolta di Microsoft Purview in base a modelli di governance e gestione dei dati centralizzati, decentralizzati o ibridi. Basare questa decisione sui requisiti aziendali e di sicurezza.

Esempio 1: organizzazione a area singola

Questa struttura è adatta alle organizzazioni che:

  • Si basano principalmente in un'unica posizione geografica.
  • Avere un team centralizzato di gestione e governance dei dati in cui il livello successivo di gestione dei dati rientra in reparti, team o progetti.

La gerarchia della raccolta è costituita da questi verticali:

  • Raccolta radice (impostazione predefinita)
  • Contoso (raccolta di primo livello)
  • Reparti (raccolta delegata per ogni reparto)
  • Teams o progetti (ulteriore separazione in base ai progetti)

Ogni origine dati viene registrata e analizzata nella raccolta corrispondente. Gli asset vengono quindi visualizzati anche nella stessa raccolta.

Le origini dati condivise a livello di organizzazione vengono registrate e analizzate nella raccolta Hub-Shared.

Le origini dati condivise a livello di reparto vengono registrate e analizzate nelle raccolte di reparti.

Screenshot che mostra il primo esempio di raccolte di Microsoft Purview.

Esempio 2: Organizzazione multiregione

Questo scenario è utile per le organizzazioni:

  • Presenza in più aree.
  • Posizione in cui il team di governance dei dati è centralizzato o decentralizzato in ogni area.
  • Posizione in cui i team di gestione dei dati vengono distribuiti in ogni posizione geografica.

La gerarchia della raccolta è costituita da questi verticali:

  • Raccolta radice (impostazione predefinita)
  • FourthCoffee (raccolta di primo livello)
  • Posizioni geografiche (raccolte di livello intermedio in base alle posizioni geografiche in cui si trovano origini dati e proprietari dei dati)
  • Reparti (raccolta delegata per ogni reparto)
  • Teams o progetti (ulteriore separazione in base a team o progetti)

In questo scenario, ogni area ha una propria sottoraccolta nella raccolta di primo livello nell'account Microsoft Purview. Le origini dati vengono registrate e analizzate nelle sottoraccolte corrispondenti nelle rispettive posizioni geografiche. Gli asset vengono quindi visualizzati anche nella gerarchia di sottoraccolta per l'area.

Se si dispone di team centralizzati di gestione e governance dei dati, è possibile concedere loro l'accesso dalla raccolta di primo livello. In questo caso, ottengono la supervisione per l'intero patrimonio di dati nella mappa dati. Facoltativamente, il team centralizzato può registrare ed analizzare tutte le origini dati condivise.

I team di gestione e governance dei dati basati sull'area possono ottenere l'accesso dalle raccolte corrispondenti a un livello inferiore.

Le origini dati condivise a livello di reparto vengono registrate e analizzate nelle raccolte di reparti.

Screenshot che mostra il secondo esempio di raccolte di Microsoft Purview.

Esempio 3: Multiregione, trasformazione dei dati

Questo scenario può essere utile se si vuole distribuire la gestione dell'accesso ai metadati in base alle posizioni geografiche e agli stati di trasformazione dei dati. I data scientist e i data engineer che possono trasformare i dati per renderli più significativi possono gestire le zone raw e refine. Possono quindi spostare i dati in aree Produce o Curate.

La gerarchia della raccolta è costituita da questi verticali:

  • Raccolta radice (impostazione predefinita)
  • Fabrikam (raccolta di primo livello)
  • Posizioni geografiche (raccolte di livello intermedio in base alle posizioni geografiche in cui si trovano origini dati e proprietari dei dati)
  • Fasi di trasformazione dei dati (Raw, Refine, Produce/Curated)

I data scientist e i data engineer possono avere il ruolo di curatori dei dati nelle zone corrispondenti in modo da poter curare i metadati. L'accesso di Lettore dati alla zona curata può essere concesso a interi utenti di dati e utenti aziendali.

Screenshot che mostra il terzo esempio di raccolte di Microsoft Purview.

Esempio 4: Multiregione, funzioni aziendali

Questa opzione può essere usata dalle organizzazioni che devono organizzare i metadati e la gestione degli accessi in base alle funzioni aziendali.

La gerarchia della raccolta è costituita da questi verticali:

  • Raccolta radice (impostazione predefinita)
  • AdventureWorks (raccolta di primo livello)
  • Posizioni geografiche (raccolte di livello intermedio in base alle posizioni geografiche in cui si trovano origini dati e proprietari dei dati)
  • Principali funzioni aziendali o client (ulteriore separazione in base a funzioni o client)

Ogni area ha una propria sottoraccolta sotto la raccolta di primo livello nell'account Microsoft Purview. Le origini dati vengono registrate e analizzate nelle sottoraccolte corrispondenti nelle rispettive posizioni geografiche. Di conseguenza, gli asset vengono aggiunti alla gerarchia di sottoraccolta per l'area.

Se si dispone di team centralizzati di gestione e governance dei dati, è possibile concedere loro l'accesso dalla raccolta di primo livello. In questo caso, ottengono la supervisione per l'intero patrimonio di dati nella mappa dati. Facoltativamente, il team centralizzato può registrare ed analizzare tutte le origini dati condivise.

I team di gestione e governance dei dati basati sull'area possono ottenere l'accesso dalle raccolte corrispondenti a un livello inferiore. Ogni business unit ha il proprio sottocollection.

Screenshot che mostra il quarto esempio di raccolte di Microsoft Purview.

Opzioni di gestione degli accessi

Se si vuole implementare la democratizzazione dei dati in un'intera organizzazione, assegnare il ruolo Lettore dati alla raccolta di primo livello alla gestione dei dati, alla governance e agli utenti aziendali.If you want to implement data democrat across an entire organization, assign the Data Reader role at the top-level collection to data management, governance, and business users. Assegnare i ruoli Amministrazione e Curatore dati a livello di sottoraccolta ai team di gestione e governance dei dati corrispondenti.

Se è necessario limitare l'accesso alla ricerca e all'individuazione dei metadati nell'organizzazione, assegnare i ruoli Lettore dati e Curatore dati a livello di raccolta specifico. Ad esempio, è possibile limitare i dipendenti degli Stati Uniti in modo che possano leggere i dati solo a livello di raccolta degli Stati Uniti e non nella raccolta LATAM.

È possibile applicare una combinazione di questi due scenari nella mappa dati di Microsoft Purview se è necessaria la democratizzazione totale dei dati con alcune eccezioni per alcune raccolte. È possibile assegnare ruoli di Microsoft Purview nella raccolta di primo livello e limitare l'ereditarietà alle raccolte figlio specifiche.

Assegnare il ruolo Raccolta Amministrazione al team di gestione e sicurezza dei dati centralizzato nella raccolta di primo livello. Delegare un'ulteriore gestione delle raccolte di livello inferiore ai team corrispondenti.

Passaggi successivi