Gestione delle identità e degli accessi
Questo articolo esamina 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 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 consigli sulle zone di destinazione di Azure. Per altre informazioni, vedere 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 sia il controllo degli accessi in base al ruolo di Azure che gli elenchi di controllo di accesso (ACL).
Esaminare le attività di amministrazione e gestione di Azure eseguite dai team. Considera la tua analisi su scala cloud su 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 pochi diritti di accesso all'interno dell'ambiente Azure. Prima di discutere dei rispettivi requisiti di controllo degli accessi in base al ruolo, è importante evidenziare che i diversi modelli di accesso devono essere usati per gli ambienti di sviluppo e di livello superiore. Inoltre, i gruppi di sicurezza dovrebbero essere usati laddove possibile per ridurre il numero di assegnazioni di ruolo e per semplificare il processo di gestione e revisione dei diritti RBAC. Questo passaggio è fondamentale a causa del 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 aiuta nello sviluppo o nel miglioramento dell'infrastructure as code (IaC) e di altri artefatti di codice. Dopo che 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 principale deve avere accesso a questi ambienti e pertanto tutte le distribuzioni devono essere eseguite tramite l'identità dell'entità servizio principale 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 risorse dell'applicazione dati, è necessario fornire diritti di Contributor e User Access Administrator. Questi diritti consentono ai team di creare e gestire servizi all'interno del proprio ambiente entro i limiti di Azure Policy. 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à vengono bloccate dal team della piattaforma Azure tramite criteri, i team delle applicazioni dati richiedono 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 di applicazioni 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 di ruolo Network Contributor 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 consentono la distribuzione self-service dei servizi dati all'interno di questi ambienti. Per affrontare la questione della gestione dei costi, le organizzazioni dovrebbero aggiungere un tag del centro di costo ai gruppi di risorse per abilitare l'addebito incrociato e la distribuzione della proprietà dei costi. 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 il SCIM Synch da Microsoft Entra ID per fornire l'accesso. Questo è importante perché questo meccanismo sincronizza automaticamente utenti e gruppi da Microsoft Entra ID al piano dati di Databricks e rimuove automaticamente anche i diritti di accesso quando un utente lascia l'organizzazione o l'azienda. All'interno di Azure Databricks, ai team delle applicazioni dati devono essere assegnati Can Restart diritti di accesso a un cluster predefinito per poter eseguire i 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. 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 questi ruoli:
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 atterraggio dei dati e la rete della zona di atterraggio della gestione dei dati, l'entità servizio deve avere i diritti di accesso Network Contributor sul gruppo di risorse della rete virtuale remota.
(Ambito 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
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 rete virtuale tra la zona di destinazione di 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 eliminato perché non è presente alcuna linea di visione verso il Firewall di Azure.
La Private DNS Zone Contributor non è necessaria anche se la distribuzione dei record A DNS degli endpoint privati viene automatizzata tramite i criteri di Azure con effetto deployIfNotExists. Lo stesso vale per il User Access Administrator perché la distribuzione può essere automatizzata 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. Il principale del servizio deve essere Private DNS Zone Contributor nel gruppo di risorse DNS globale che è stato creato durante l'implementazione della zona di atterraggio per la 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. Il principale del servizio richiede un'assegnazione di ruolo Contributor su quel gruppo di risorse.
L'ambito del gruppo di risorse /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Per distribuire endpoint privati nella subnet di collegamento privato specificata, che è stata creata durante la distribuzione della zona di destinazione dei dati, il principale del servizio richiede l'accesso Network Contributor a tale subnet.
(Ambito risorsa figlio) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Accesso ad altre risorse
All'esterno di Azure, i team delle applicazioni 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 richiede la configurazione di una connessione ad Azure, che viene eseguita nella maggior parte dei servizi tramite i principi del servizio. Di conseguenza, i team richiedono l'accesso a un principio di servizio per implementare l'automazione all'interno del loro 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 il controllo di accesso con granularità fine.
Per ulteriori informazioni su come garantire la sicurezza delle landing zone per la gestione dei dati e delle landing zone per i dati, e su come gestire efficacemente il patrimonio di dati, consultare Authentication for cloud-scale analytics in Azure.
Passaggi successivi
- topologia di rete e connettività