Gestione delle identità e dell'accesso
Questo articolo esamina le considerazioni sulla 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 elemento cruciale, anche le linee guida sulle aree di progettazione della zona di destinazione di Azure devono essere incluse nella progettazione.
Questo articolo si basa su considerazioni e raccomandazioni per le zone di destinazione di Azure. Per altre informazioni, vedere Gestione di identità e accessi.
Progettazione della zona di destinazione dei dati
L'analisi su scala cloud supporta un modello di controllo di accesso usando le identità di Microsoft Entra. Il modello usa sia il controllo degli accessi in base al ruolo di Azure che gli elenchi di controllo di accesso (ACL).
Rivedere le attività di amministrazione e gestione di Azure eseguite dal team. Prendere in considerazione l'analisi su scala cloud in Azure. Determinare la migliore distribuzione possibile delle responsabilità all'interno dell'organizzazione.
Assegnazioni di ruoli
Per sviluppare, distribuire e gestire i prodotti dati in modo autonomo all'interno della piattaforma dati, i team dell'applicazione dati richiedono pochi diritti di accesso all'interno dell'ambiente Azure. Prima di esaminare i rispettivi requisiti di controllo degli accessi in base al ruolo, è necessario evidenziare che è necessario usare modelli di accesso diversi per gli ambienti di sviluppo e di livello superiore. Inoltre, i gruppi di sicurezza devono essere usati laddove possibile per ridurre il numero di assegnazioni di ruolo e per semplificare il processo di gestione e revisione dei diritti di controllo degli accessi in base al ruolo. Ciò è fondamentale, a causa del numero limitato di assegnazioni di ruolo che è possibile creare per ogni sottoscrizione.
L'ambiente di sviluppo deve essere accessibile dal team di sviluppo e dalle rispettive identità utente per consentire 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 (IaC) e altri artefatti di codice. Quando un'implementazione all'interno dell'ambiente di sviluppo funziona come previsto, può essere implementata continuamente negli ambienti più elevati. Gli ambienti più elevati, ad esempio test e prod, devono essere bloccati per il team dell'applicazione dati. Solo un'entità servizio deve avere accesso a questi ambienti e pertanto tutte le distribuzioni devono essere eseguite tramite l'identità dell'entità servizio usando pipeline CI/CD. Per riepilogare, i diritti di accesso all'ambiente di sviluppo devono essere forniti a un'entità servizio E alle identità utente e in ambienti più elevati devono essere forniti solo a un'identità dell'entità servizio.
Per poter creare risorse e assegnazioni di ruolo tra le risorse all'interno dei gruppi di Contributor risorse dell'applicazione dati, è User Access Administrator necessario fornire i diritti. Ciò consentirà ai team di creare e controllare i servizi all'interno dell'ambiente entro i limiti di Criteri di Azure. L'analisi su scala cloud consiglia l'uso di endpoint privati per superare il rischio di esfiltrazione dei dati e, poiché altre opzioni di connettività devono essere bloccate dal team della piattaforma Azure tramite criteri, i team delle applicazioni dati richiederanno diritti di accesso alla rete virtuale condivisa di una zona di destinazione dei dati per poter configurare correttamente la connettività di rete necessaria per i servizi che stanno pianificando di usare. Per seguire il principio dei privilegi minimi, superare i conflitti tra team applicazione dati diversi e avere una netta separazione dei team, l'analisi su scala cloud propone di creare una subnet dedicata per ogni team dell'applicazione dati e creare un'assegnazione Network Contributor di ruolo a tale subnet (ambito delle risorse figlio). Questa assegnazione di ruolo consente ai team di partecipare alla subnet usando endpoint privati.
Queste due prime assegnazioni di ruolo consentiranno la distribuzione self-service dei servizi dati all'interno di questi ambienti. Per risolvere il problema di gestione dei costi, le organizzazioni devono aggiungere un tag del centro di costo ai gruppi di risorse per abilitare la proprietà dei costi distribuiti e di ricarica incrociata. Questo aumenta la consapevolezza all'interno dei team e li impone di prendere le decisioni appropriate in relazione agli SKU e ai livelli di servizio necessari.
Per abilitare anche 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 Databricks, le organizzazioni devono usare SCIM Synch da Microsoft Entra ID per fornire l'accesso. Questo è importante, poiché questo meccanismo sincronizza automaticamente utenti e gruppi da Microsoft Entra ID al piano dati di Databricks e rimuove automaticamente i diritti di accesso quando un individuo lascia l'organizzazione o l'azienda. Questo non può essere il caso, se in Azure Databricks vengono usati account utente separati. I team dell'applicazione dati devono essere aggiunti all'area di lavoro di Databricks in shared-product-rg e in shared-integration-rg. All'interno di Azure Databricks, ai team dell'applicazione dati devono essere concessi Can Restart diritti di accesso a un cluster predefinito per poter eseguire carichi di lavoro all'interno dell'area di lavoro.
I singoli team richiederanno l'accesso all'account Purview centrale per individuare gli asset di dati all'interno delle rispettive zone di destinazione dei dati. Di conseguenza, i team dovranno essere aggiunti alla Data Reader raccolta di primo livello di Purview. Inoltre, i team richiederanno nella maggior parte dei casi la possibilità di modificare gli asset di dati catalogati di cui sono proprietari per fornire dettagli aggiuntivi, ad esempio i dettagli di contatto dei proprietari dei dati e gli esperti, nonché dettagli più granulari sulle colonne all'interno di un set di dati e sulle informazioni incluse.
Riepilogo dei requisiti di controllo degli accessi in base al ruolo
Ai fini dell'automazione della distribuzione delle zone di destinazione dei dati, sono necessari i seguenti ruoli:
Nome ruolo
Descrizione
Scope
Distribuire tutte le zone DNS private per tutti i servizi dati in un'unica sottoscrizione e gruppo di risorse. L'entità servizio deve essere Private DNS Zone Contributor per il gruppo di risorse DNS globale creato durante la distribuzione della zona di destinazione per la gestione dei dati. Questo ruolo è necessario per distribuire record A per gli endpoint privati.
(Ambito del gruppo di risorse) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Per configurare il peering di reti virtuali tra la rete della zona di destinazione dei dati e la rete della zona di destinazione per la gestione dei dati, l'entità servizio deve avere 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 altri data factory. È anche necessario assegnare l'accesso delle identità gestite di Azure Data Factory e Azure Synapse Analytics nei rispettivi file system dell'account di archiviazione.
(Ambito delle risorse) /subscriptions/{{dataLandingZone}subscriptionId}
Nota
Il numero di assegnazioni di ruolo può essere ridotto in uno scenario di produzione. L'assegnazione di ruolo Network Contributor è necessaria solo per configurare il peering di reti virtuali tra la zona di destinazione per la gestione dei dati e la zona di destinazione dei dati. Senza questa considerazione, la risoluzione DNS non funziona. Il traffico in ingresso e in uscita viene rimosso perché non è presente una linea di vista per Firewall di Azure.
Private DNS Zone Contributor non è inoltre necessario se la distribuzione di record A DNS degli endpoint privati viene automatizzata tramite criteri di Azure con effetto deployIfNotExists. Lo stesso vale per User Access Administrator poiché la distribuzione può essere automatizzata tramite criteri 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
Scope
Distribuire tutte le zone DNS private per tutti i servizi dati in un'unica sottoscrizione e gruppo di risorse. L'entità servizio deve essere Private DNS Zone Contributor per il gruppo di risorse DNS globale creato durante la distribuzione della zona di destinazione per la gestione dei dati. Questo ruolo è necessario per distribuire record A per i 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à servizio richiede un'assegnazione di ruolo Contributor per quel gruppo di risorse.
(Ambito del gruppo di risorse) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Per distribuire endpoint privati nella subnet di collegamento privato specificata, creata durante la distribuzione della zona di destinazione dei dati, l'entità servizio richiede l'accesso Network Contributor a quella subnet.
(Ambito delle risorse figlio) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Accesso ad altre risorse
All'esterno di Azure, i team di data product e Integrazione dei dati richiedono anche 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 tramite CI/CD in ambienti più elevati. Inoltre, è necessario fornire una scheda di progetto per consentire lo sviluppo agile, la pianificazione dello sprint, il monitoraggio delle attività e nonché il feedback degli utenti e le richieste di funzionalità.
Infine, l'automazione CI/CD richiederà la configurazione di una connessione ad Azure, che viene eseguita nella maggior parte dei servizi tramite i principi del servizio. Di conseguenza, i team richiederanno l'accesso a un'entità servizio per ottenere l'automazione all'interno del progetto.
Gestione dell'accesso ai dati
La gestione dell'accesso ai dati deve essere eseguita usando i gruppi di Microsoft Entra. Aggiungere nomi di entità utente o nomi di entità servizio ai gruppi di Microsoft Entra. Aggiungere i gruppi ai servizi e concedere le autorizzazioni al gruppo. Questo approccio consente un controllo di accesso granulare.
Per i prodotti dati in Azure Data Lake, è consigliabile usare elenchi di controllo di accesso (ACL). Per altre informazioni, vedere Modello di controllo di accesso in Azure Data Lake Storage Gen2. L'uso del pass-through di Microsoft Entra con elenchi di controllo di accesso è supportato dalla maggior parte dei servizi nativi di Azure, tra cui Azure Machine Learning, Azure Synapse SQL Serverless, Apache Spark per Azure Synapse e Azure Databricks.
È probabile che venga usata un'altra risorsa di archiviazione poliglotta nell'analisi su scala cloud. Gli esempi includono Database di Azure per PostgreSQL, Database di Azure per MySQL, database SQL di Azure, Istanza gestita di SQL e pool dedicati di Azure Synapse SQL. Possono essere usati dai team dell'applicazione dati per archiviare i prodotti dati.
- Usare l'ID Microsoft Entra per l'autenticazione con Database di Azure per PostgreSQL
- Usare l'autenticazione di Microsoft Entra con database SQL di Azure, Istanza gestita di SQL e Azure Synapse Analytics
- Usare Microsoft Entra ID per l'autenticazione con Database di Azure per MySQL
È consigliabile usare i gruppi di Microsoft Entra per proteggere gli oggetti di database anziché i singoli account utente di Microsoft Entra. Questi gruppi di Microsoft Entra vengono usati per autenticare gli utenti e proteggere gli oggetti di database. Analogamente al modello data lake, è possibile usare l'onboarding di prodotti di dominio o dati per creare questi gruppi all'interno del servizio Microsoft Entra.
Questo approccio offre anche un'unica posizione di gestione e consente di esaminare i diritti di accesso all'interno di Azure Graph.
Per altre informazioni su come gestire la sicurezza per le zone di destinazione di gestione dei dati e le zone di destinazione dei dati che gestiscono il patrimonio di dati, vedere Effettuare il provisioning della sicurezza per l'analisi su scala cloud in Azure.