Autenticazione per l'analisi su scala cloud in Azure
L'autenticazione è il processo che verifica l'identità di un utente o di un'applicazione. È preferibile un singolo provider di identità di origine, che si occupa della gestione e dell'autenticazione delle identità. Questo provider è noto come servizio directory. Consente di usare metodi per archiviare i dati della directory e renderli disponibili per gli utenti e gli amministratori della rete.
Qualsiasi soluzione di data lake deve usare e integrarsi con il servizio directory già in uso. Per la maggior parte delle organizzazioni, Active Directory è il servizio directory per tutti i servizi correlati alle identità. È il database primario e centralizzato per tutti gli account utente e del servizio.
Nel cloud, Microsoft Entra ID è un provider di identità centralizzato e l'origine preferita per la gestione delle identità. La delega dell'autenticazione e dell'autorizzazione a Microsoft Entra ID consente scenari come i criteri di accesso condizionale che richiedono che un utente si trova in una posizione specifica. Supporta l'autenticazione a più fattori per aumentare il livello di sicurezza degli accessi. Configurare i servizi data store data lake con l'integrazione di Microsoft Entra, quando possibile.
Per i servizi dati che non supportano Microsoft Entra ID, usare la chiave di accesso o il token per l'autenticazione. Il client deve archiviare la chiave di accesso in un archivio di gestione delle chiavi, ad esempio Azure Key Vault.
Gli scenari di autenticazione per l'analisi su scala cloud sono:
- Autenticazione dell'utente
- Autenticazione da applicazione a servizio e da servizio a servizio
Autenticazione dell'utente
Gli utenti che si connettono a un servizio dati o a una risorsa devono presentare le credenziali. Queste credenziali confermano l'identità dichiarata dagli utenti. Successivamente possono accedere al servizio o alla risorsa. L'autenticazione consente anche al servizio di conoscere l'identità degli utenti. Il servizio decide cosa può vedere e fare un utente dopo la verifica dell'identità.
Azure Data Lake Archiviazione Gen2, database SQL di Azure e Azure Synapse supportano l'integrazione di Microsoft Entra. La modalità di autenticazione utente interattiva richiede agli utenti di specificare le credenziali in una finestra di dialogo.
Importante
Non impostare le credenziali utente come hard coded in un'applicazione per l'autenticazione.
Autenticazione da applicazione a servizio e da servizio a servizio
Queste richieste non sono associate a un utente specifico oppure non c'è un utente che deve immettere le credenziali.
Autenticazione da servizio a servizio
Anche se un servizio accede a un altro servizio senza l'intervento umano, deve presentare un'identità valida. Questa identità dimostra che il servizio è reale. Il servizio a cui si accede può usare l'identità per decidere cosa può fare il servizio.
Per l'autenticazione da servizio a servizio, il metodo preferito per autenticare i servizi di Azure è l'identità gestita. Le identità gestite per le risorse di Azure consentono l'autenticazione a qualsiasi servizio che supporta l'autenticazione di Microsoft Entra senza credenziali esplicite. Per altre informazioni, vedere Informazioni sulle identità gestite per le risorse di Azure.
Le identità gestite sono entità servizio, che possono essere usate solo con le risorse di Azure. Ad esempio, un'identità gestita può essere creata direttamente per un'istanza di Azure Data Factory. Questa identità gestita è un oggetto registrato nell'ID Microsoft Entra. Rappresenta l'istanza di Data Factory. Questa identità può quindi essere usata per eseguire l'autenticazione a qualsiasi servizio, ad esempio Data Lake Storage, senza credenziali nel codice. Azure gestisce le credenziali usate dall'istanza del servizio. L'identità può concedere l'autorizzazione alle risorse del servizio di Azure, ad esempio una cartella in Azure Data Lake Storage. Quando si elimina questa istanza di Data Factory, Azure pulisce l'identità in Microsoft Entra ID.
Vantaggi dell'uso delle identità gestite
Le identità gestite devono essere usate per autenticare un servizio di Azure in un altro servizio o in una risorsa di Azure. Offrono i vantaggi seguenti:
- Un'identità gestita rappresenta il servizio per cui viene creata. Non rappresenta un utente interattivo.
- Le credenziali di identità gestite vengono mantenute, gestite e archiviate in Microsoft Entra ID. L'utente non deve conservare alcuna password.
- Con le identità gestite, i servizi client non usano le password.
- L'identità gestita assegnata dal sistema viene eliminata quando viene eliminata l'istanza del servizio.
Questi vantaggi indicano che le credenziali sono protette meglio e che è meno probabile che la sicurezza venga compromessa.
Autenticazione da applicazione a servizio
Un altro scenario di accesso è un'applicazione, ad esempio un'applicazione Web per dispositivi mobili, che accede a un servizio di Azure. Chiunque stia accedendo a un servizio di Azure deve specificare la propria identità e tale identità deve essere verificata.
Un'entità servizio di Azure è l'alternativa per le applicazioni e i servizi che non supportano le identità gestite per l'autenticazione alle risorse di Azure. Un'entità servizio di Azure è un'identità creata per l'uso con applicazioni, servizi in hosting e strumenti automatici per l'accesso alle risorse di Azure. L'accesso è limitato dai ruoli assegnati all'entità servizio. Per motivi di sicurezza, è consigliabile usare le entità servizio con strumenti o applicazioni automatizzati anziché consentire loro di accedere con un'identità utente. Per altre informazioni, vedere Oggetti applicazione e entità servizio in Microsoft Entra ID.
Nota
Sia le identità gestite che le entità servizio vengono create e mantenute solo in Microsoft Entra ID.
Differenza tra identità gestita ed entità servizio
| Entità servizio | Identità gestita |
|---|---|
| Un'identità di sicurezza creata manualmente in Microsoft Entra ID per l'uso da parte di applicazioni, servizi e strumenti per accedere a risorse di Azure specifiche. | Un tipo speciale di entità servizio. È un'identità automatica che viene creata quando viene creato un servizio di Azure. |
| Può essere usata da qualsiasi applicazione o servizio. Non è associata a un servizio di Azure specifico. | Rappresenta l'istanza del servizio di Azure stessa. Non può essere usata per rappresentare altri servizi di Azure. |
| Ha un ciclo di vita indipendente. È necessario eliminarla in modo esplicito. | Viene eliminata automaticamente quando viene eliminata l'istanza del servizio di Azure. |
| Autenticazione basata su password o basata su certificato. | Per l'autenticazione non è necessario inserire alcuna password esplicita. |
Autenticazione e autorizzazioni del database
L'analisi su scala cloud probabilmente contiene spazio di archiviazione poliglotta. Ad esempio PostgreSQL, MySQL, database SQL di Azure, Istanza gestita di SQL e Azure Synapse Analytics.
- Usare l'ID Entra di Microsoft per l'autenticazione con PostgreSQL
- Usare l'autenticazione di Microsoft Entra con database SQL di Azure, Istanza gestita di SQL e Azure Synapse Analytics
- Usare l'ID Microsoft Entra per l'autenticazione con MySQL
È consigliabile usare i gruppi di Microsoft Entra per proteggere gli oggetti di database anziché i singoli account utente di Microsoft Entra. Usare questi gruppi di Microsoft Entra per autenticare gli utenti e proteggere gli oggetti di database. Analogamente al modello data lake, è possibile usare l'onboarding dell'applicazione dati per creare questi gruppi.
Nota
Le applicazioni dati possono archiviare prodotti dati sensibili in pool database SQL di Azure, Istanza gestita di SQL o Azure Synapse Analytics. Per altre informazioni, vedere Dati sensibili.
Sicurezza di Azure Data Lake nell'analisi su scala cloud
Per controllare l'accesso ai dati nel data lake, è consigliabile usare l'elenco di controllo di accesso (ACL) a livello di file e cartelle. Azure Data Lake adotta anche un modello di elenco di controllo di accesso simile a POSIX. POSIX (interfaccia del sistema operativo portabile) è una famiglia di standard per i sistemi operativi. Uno standard definisce una struttura di autorizzazioni semplice ma potente per accedere a file e cartelle. POSIX è stato ampiamente adottato per le condivisioni file di rete e i computer Unix.
Analogamente alle procedure generali del Controllo degli accessi in base al ruolo di Azure, all'elenco di controllo di accesso devono essere applicate le regole seguenti:
Gestire l'accesso con i gruppi. Assegnare l'accesso ai gruppi di Microsoft Entra e gestire l'appartenenza ai gruppi per la gestione degli accessi in corso. Vedere Controllo di accesso e configurazioni data lake in Azure Data Lake Archiviazione.
Privilegi minimi. Nella maggior parte dei casi, gli utenti devono avere solo l'autorizzazione di lettura per le cartelle e i file necessari nel data lake. Un'identità gestita o un'entità servizio, ad esempio quella usata da Azure Data Factory, dispone di autorizzazioni di lettura, scrittura ed esecuzione. Gli utenti di dati non devono avere accesso al contenitore dell'account di archiviazione.
Allinearsi con lo schema di partizionamento dei dati. La progettazione dell'elenco di controllo di accesso e della partizione dei dati deve essere allineata per garantire un controllo di accesso ai dati efficace. Per altre informazioni, vedere [Partizionamento data lake].
Passaggi successivi
Gestione dei dati e controllo degli accessi in base al ruolo per l'analisi su scala cloud in Azure