Gestione delle identità e degli accessi
Questo articolo illustra le considerazioni di progettazione e le raccomandazioni per la gestione delle identità e degli accessi. Si concentra sulla distribuzione di una piattaforma di analisi su scala cloud in Microsoft Azure. Poiché l'analisi su scala cloud è un componente cruciale, è consigliabile seguire le indicazioni sulle aree di progettazione della zona di destinazione di Azure quando si progetta la soluzione.
Questo articolo si basa su considerazioni e consigli sulle zone di destinazione di Azure. Per ulteriori informazioni, vedere l'area di progettazione della gestione delle identità e degli accessi .
Progettazione della zona di atterraggio dei dati
L'analisi su scala cloud supporta un modello di controllo di accesso usando le identità di Microsoft Entra. Il modello usa il controllo degli accessi in base al ruolo di Azure e gli elenchi di controllo di accesso.
Esaminare le attività di amministrazione e gestione di Azure eseguite dai team. Valutare l'analisi su scala cloud in Azure. Determinare la migliore distribuzione possibile delle responsabilità all'interno dell'organizzazione.
Assegnazioni di ruolo
Per sviluppare, distribuire e gestire i prodotti dati in modo autonomo all'interno della piattaforma dati, i team dell'applicazione dati richiedono diversi diritti di accesso all'interno dell'ambiente Azure. È importante notare che è consigliabile usare modelli di accesso diversi per gli ambienti di sviluppo e di livello superiore. Usare i gruppi di sicurezza quando possibile per ridurre il numero di assegnazioni di ruolo e semplificare la gestione e il processo di revisione dei diritti RBAC. Questo passaggio è fondamentale a causa della numero limitato di assegnazioni di ruolo che è possibile creare per ogni sottoscrizione.
L'ambiente di sviluppo deve essere accessibile al team di sviluppo e alle rispettive identità utente. Questo accesso consente loro di scorrere più rapidamente, ottenere informazioni su determinate funzionalità all'interno dei servizi di Azure e risolvere i problemi in modo efficace. L'accesso a un ambiente di sviluppo consente di sviluppare o migliorare l'infrastruttura come codice e altri artefatti di codice.
Dopo aver verificato che un'implementazione funziona come previsto nell'ambiente di sviluppo, può essere implementata continuamente in ambienti più elevati. Gli ambienti più elevati, come i test e la produzione, devono essere riservati per il team dell'applicazione dati. Solo un principale del servizio deve avere accesso a questi ambienti. Di conseguenza, tutte le distribuzioni devono essere eseguite tramite il principale del servizio usando pipeline di integrazione continua e consegna continua (CI/CD). Nell'ambiente di sviluppo, fornire diritti di accesso sia a un'entità servizio che alle identità utente. Negli ambienti più elevati limitare i diritti di accesso solo all'identità dell'entità servizio.
Per creare risorse e assegnazioni di ruolo tra le risorse all'interno dei gruppi di risorse dell'applicazione dati, è necessario fornire diritti di Contributor e User Access Administrator. Questi diritti consentono ai team di creare e controllare i servizi nel proprio ambiente entro i limiti dei criteri di Azure.
Per ridurre il rischio di esfiltrazione dei dati, è una buona pratica utilizzare endpoint privati per l'analisi cloud. Il team della piattaforma Azure blocca altre opzioni di connettività tramite criteri, quindi i team delle applicazioni dati devono disporre dei diritti di accesso alla rete virtuale condivisa di una zona di destinazione dei dati. Questo accesso è essenziale per configurare la connettività di rete necessaria per i servizi che intende usare.
Per seguire il principio dei privilegi minimi, evitare conflitti tra team di applicazioni dati diversi e avere una netta separazione dei team. Le migliori pratiche per l'analisi su scala cloud prevedono di creare una subnet dedicata per ciascun team dell'applicazione dati e assegnare un ruolo Network Contributor a quella subnet o al relativo ambito delle risorse secondarie. Questa assegnazione di ruolo consente ai team di partecipare alla subnet usando endpoint privati.
Queste prime due assegnazioni di ruolo consentono la distribuzione self-service dei servizi dati all'interno di questi ambienti. Per risolvere i problemi di gestione dei costi, le organizzazioni devono aggiungere un tag del centro di costo ai gruppi di risorse per abilitare la gestione incrociata e la proprietà dei costi distribuiti. Questo approccio aumenta la consapevolezza all'interno dei team e consente di prendere decisioni informate sugli SKU e sui livelli di servizio necessari.
Per abilitare l'uso self-service di altre risorse condivise all'interno della zona di destinazione dei dati, sono necessarie alcune assegnazioni di ruolo aggiuntive. Se è necessario l'accesso a un ambiente Azure Databricks, le organizzazioni dovrebbero utilizzare SCIM sync da Microsoft Entra ID per fornire l'accesso. Questo meccanismo di sincronizzazione è importante perché sincronizza automaticamente utenti e gruppi da Microsoft Entra ID al piano dati di Azure Databricks. Rimuove automaticamente anche i diritti di accesso quando un individuo lascia l'organizzazione o l'azienda. In Azure Databricks assegnare ai team dell'applicazione dati i diritti di accesso Can Restart a un cluster predefinito in modo che possano eseguire carichi di lavoro all'interno dell'area di lavoro.
I singoli team richiedono l'accesso all'account Microsoft Purview per individuare gli asset di dati all'interno delle rispettive zone di destinazione dei dati. I team spesso devono modificare gli asset di dati catalogati di cui sono proprietari per fornire dettagli aggiuntivi, ad esempio le informazioni di contatto dei proprietari dei dati e degli esperti. Teams richiede anche la possibilità di fornire informazioni più granulari su ciò che ogni colonna in un set di dati descrive e include.
Riepilogo dei requisiti RBAC
Per automatizzare la distribuzione delle zone di destinazione dei dati, sono necessari i ruoli seguenti:
Nome ruolo
Descrizione
Ambito
Distribuire tutte le zone DNS private per tutti i servizi dati in una singola sottoscrizione e in un singolo gruppo di risorse. L'entità servizio deve essere Private DNS Zone Contributor nel gruppo di risorse DNS globale creato durante la distribuzione della zona di destinazione di gestione dei dati. Questo ruolo è necessario per distribuire record A per gli endpoint privati.
(Ambito del gruppo di risorse) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
collaboratore alla rete
Per configurare il peering di rete virtuale tra la rete della zona di approdo dei dati e la rete della zona di approdo della gestione dei dati, l'entità servizio deve avere i diritti di accesso Network Contributor per il gruppo di risorse della rete virtuale remota.
(Ambito del gruppo di risorse) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Questa autorizzazione è necessaria per condividere il runtime di integrazione self-hosted che viene distribuito nel gruppo di risorse integration-rg con altre data factory. È necessario anche assegnare l'accesso alle identità gestite di Azure Data Factory e Azure Synapse Analytics nei rispettivi file system dell'account di archiviazione.
(L'ambito della risorsa) /subscriptions/{{dataLandingZone}subscriptionId}
Nota
In uno scenario di produzione è possibile ridurre il numero di assegnazioni di ruolo. Il ruolo Network Contributor è necessario solo per configurare il peering di rete virtuale tra la zona di destinazione di gestione dei dati e la zona di destinazione dei dati. Senza questo ruolo, la risoluzione DNS ha esito negativo. Inoltre, il traffico in ingresso e in uscita viene interrotto perché non c'è alcuna linea di visibilità su Azure Firewall.
Il ruolo Private DNS Zone Contributor non è necessario se la distribuzione di record DNS A per gli endpoint privati viene automatizzata tramite i criteri di Azure con l'effetto deployIfNotExists. Lo stesso vale per il ruolo User Access Administrator perché è possibile automatizzare la distribuzione usando i criteri di deployIfNotExists.
Assegnazioni di ruolo per i prodotti dati
Per distribuire un prodotto dati all'interno di una zona di destinazione dati sono necessarie le assegnazioni di ruolo seguenti:
Nome ruolo
Descrizione
Ambito
Distribuire tutte le zone DNS private per tutti i servizi dati in una singola sottoscrizione e in un singolo gruppo di risorse. L'entità servizio deve essere Private DNS Zone Contributor nel gruppo di risorse DNS globale creato durante la distribuzione della zona di destinazione di gestione dei dati. Questo ruolo è richiesto per distribuire i record A ai rispettivi endpoint privati.
(Ambito del gruppo di risorse) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Distribuire tutti i servizi di streaming di integrazione dei dati in un singolo gruppo di risorse all'interno della sottoscrizione della zona di destinazione dei dati. L'entità principale del servizio richiede un'assegnazione di ruolo Contributor sul gruppo di risorse.
(Ambito del gruppo di risorse) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
collaboratore alla rete
Per distribuire endpoint privati nella subnet di Collegamento privato di Azure specificata creata durante la distribuzione della zona di atterraggio dei dati, il principale del servizio richiede l'accesso Network Contributor su tale subnet.
(Ambito della risorsa figlio) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Accesso ad altre risorse
All'esterno di Azure, i team dell'applicazione dati richiedono l'accesso a un repository per archiviare gli artefatti del codice, collaborare in modo efficace e implementare gli aggiornamenti e le modifiche in modo coerente in ambienti più elevati tramite CI/CD. È necessario fornire una bacheca del progetto per consentire lo sviluppo agile, la pianificazione dello sprint, il rilevamento delle attività e la gestione dei commenti e delle richieste di funzionalità degli utenti.
Per automatizzare CI/CD, stabilire una connessione ad Azure. Questo processo viene eseguito nella maggior parte dei servizi tramite entità servizio. A causa di questo requisito, i team devono avere accesso a un'entità servizio per ottenere l'automazione nel progetto.
Gestire l'accesso ai dati
Gestire l'accesso ai dati usando i gruppi di Microsoft Entra. Aggiungere nomi principali utente o nomi principali servizio ai gruppi di Microsoft Entra. Aggiungere quindi tali gruppi ai servizi e concedere le autorizzazioni al gruppo. Questo approccio consente il controllo di accesso con granularità fine.
Per ulteriori informazioni su come gestire la sicurezza per le zone di atterraggio per la gestione dei dati e le zone di atterraggio dei dati che gestiscono il patrimonio dati, vedere Authentication for cloud-scale analytics in Azure.