Eseguire la migrazione di un'applicazione Java per usare connessioni senza password con database SQL di Azure
Questo articolo illustra come eseguire la migrazione da metodi di autenticazione tradizionali a connessioni senza password più sicure con database SQL di Azure.
Le richieste dell'applicazione al database SQL di Azure devono essere autenticate. database SQL di Azure offre diversi modi per consentire alle app di connettersi in modo sicuro. Uno dei modi consiste nell'usare le password. Tuttavia, è consigliabile assegnare priorità alle connessioni senza password nelle applicazioni, quando possibile.
Confrontare le opzioni di autenticazione
Quando l'applicazione esegue l'autenticazione con database SQL di Azure, fornisce una coppia nome utente e password per connettersi al database. A seconda della posizione in cui sono archiviate le identità, esistono due tipi di autenticazione: autenticazione di Microsoft Entra e autenticazione database SQL di Azure.
Autenticazione Microsoft Entra
L'autenticazione di Microsoft Entra è un meccanismo per la connessione a database SQL di Azure usando le identità definite in Microsoft Entra ID. Con l'autenticazione di Microsoft Entra, è possibile gestire le identità utente del database e altre servizi Microsoft in una posizione centrale, semplificando la gestione delle autorizzazioni.
L'uso di Microsoft Entra ID per l'autenticazione offre i vantaggi seguenti:
- Autenticazione degli utenti nei servizi di Azure in modo uniforme.
- Gestione dei criteri password e della rotazione delle password in un'unica posizione.
- Più forme di autenticazione supportate da Microsoft Entra ID, che possono eliminare la necessità di archiviare le password.
- I clienti possono gestire le autorizzazioni del database usando gruppi esterni (Microsoft Entra ID).
- L'autenticazione di Microsoft Entra usa gli utenti del database SQL di Azure per autenticare le identità a livello di database.
- Supporto dell'autenticazione basata su token per le applicazioni che si connettono a database SQL di Azure.
Autenticazione del database SQL di Azure
È possibile creare account in database SQL di Azure. Se si sceglie di usare le password come credenziali per gli account, queste credenziali verranno archiviate nella sys.database_principals
tabella. Poiché queste password vengono archiviate in database SQL di Azure, è necessario gestire manualmente la rotazione delle password.
Anche se è possibile connettersi a database SQL di Azure con le password, è consigliabile usarle con cautela. È necessario essere diligenti per non esporre mai le password in una posizione non sicura. Chiunque possa accedere alle password è in grado di eseguire l'autenticazione. Ad esempio, esiste il rischio che un utente malintenzionato possa accedere all'applicazione se un stringa di connessione viene accidentalmente archiviato nel controllo del codice sorgente, inviato tramite un messaggio di posta elettronica non sicuro, incollato nella chat sbagliata o visualizzato da un utente che non deve avere l'autorizzazione. Prendere invece in considerazione l'aggiornamento dell'applicazione per usare connessioni senza password.
Introduzione alle connessioni senza password
Con una connessione senza password, è possibile connettersi ai servizi di Azure senza archiviare credenziali nel codice dell'applicazione, nei relativi file di configurazione o nelle variabili di ambiente.
Molti servizi di Azure supportano connessioni senza password, ad esempio tramite Identità gestita di Azure. Queste tecniche forniscono funzionalità di sicurezza affidabili che è possibile implementare usando DefaultAzureCredential dalle librerie client di Identità di Azure. In questa esercitazione si apprenderà come aggiornare un'applicazione esistente da usare DefaultAzureCredential
invece di alternative, ad esempio stringa di connessione.
DefaultAzureCredential
supporta più metodi di autenticazione e determina automaticamente quali devono essere usati in fase di esecuzione. Questo approccio consente all'app di usare metodi di autenticazione diversi in ambienti diversi (sviluppo locale e produzione) senza implementare codice specifico dell'ambiente.
L'ordine e le posizioni in cui DefaultAzureCredential
cercare le credenziali sono disponibili nella panoramica della libreria di identità di Azure. Ad esempio, quando si lavora in locale, DefaultAzureCredential
in genere si esegue l'autenticazione usando l'account usato dallo sviluppatore per accedere a Visual Studio. Quando l'app viene distribuita in Azure, DefaultAzureCredential
passerà automaticamente all'uso di un'identità gestita. Per questa transizione non sono necessarie modifiche al codice.
Per garantire che le connessioni siano senza password, è necessario prendere in considerazione sia lo sviluppo locale che l'ambiente di produzione. Se una stringa di connessione è necessaria in entrambe le posizioni, l'applicazione non è senza password.
Nell'ambiente di sviluppo locale è possibile eseguire l'autenticazione con l'interfaccia della riga di comando di Azure, Azure PowerShell, Visual Studio o plug-in di Azure per Visual Studio Code o IntelliJ. In questo caso, è possibile usare tali credenziali nell'applicazione anziché configurare le proprietà.
Quando si distribuiscono applicazioni in un ambiente di hosting di Azure, ad esempio una macchina virtuale, è possibile assegnare un'identità gestita in tale ambiente. Non sarà quindi necessario fornire le credenziali per connettersi ai servizi di Azure.
Nota
Un'identità gestita fornisce un'identità di sicurezza per rappresentare un'app o un servizio. L'identità viene gestita dalla piattaforma Azure e non è necessario eseguire il provisioning o ruotare alcun segreto. Per altre informazioni sulle identità gestite, vedere la documentazione di panoramica .
Nota
Poiché il driver JDBC per database SQL di Azure non supporta ancora connessioni senza password da ambienti locali, questo articolo si concentrerà solo sulle applicazioni distribuite negli ambienti di hosting di Azure e su come eseguirne la migrazione per usare connessioni senza password.
Eseguire la migrazione di un'applicazione esistente per usare connessioni senza password
La procedura seguente illustra come eseguire la migrazione di un'applicazione esistente per usare connessioni senza password anziché una soluzione basata su password.
0) Preparare l'ambiente di lavoro
Usare prima di tutto il comando seguente per configurare alcune variabili di ambiente.
export AZ_RESOURCE_GROUP=<YOUR_RESOURCE_GROUP>
export AZ_DATABASE_SERVER_NAME=<YOUR_DATABASE_SERVER_NAME>
export AZ_DATABASE_NAME=demo
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)
export CURRENT_USER_OBJECTID=$(az ad signed-in-user show --query id --output tsv)
Sostituire i segnaposto con i valori seguenti, che vengono usati nell'intero articolo:
<YOUR_RESOURCE_GROUP>
: nome del gruppo di risorse in cui si trovano le risorse.<YOUR_DATABASE_SERVER_NAME>
: il nome del server di database SQL di Azure. Deve essere univoco in Azure.
1) Configurare database SQL di Azure
1.1) Abilitare l'autenticazione basata su ID di Microsoft Entra
Per usare l'accesso a Microsoft Entra ID con database SQL di Azure, è necessario impostare prima l'utente amministratore di Microsoft Entra. Solo un utente di Microsoft Entra Admin può creare/abilitare gli utenti per l'autenticazione basata su ID di Microsoft Entra.
Se si usa l'interfaccia della riga di comando di Azure, eseguire il comando seguente per assicurarsi che disponga di autorizzazioni sufficienti:
az login --scope https://graph.microsoft.com/.default
Eseguire quindi il comando seguente per impostare l'amministratore di Microsoft Entra:
az sql server ad-admin create \
--resource-group $AZ_RESOURCE_GROUP \
--server $AZ_DATABASE_SERVER_NAME \
--display-name $CURRENT_USERNAME \
--object-id $CURRENT_USER_OBJECTID
Questo comando imposta l'amministratore di Microsoft Entra sull'utente connesso corrente.
Nota
È possibile creare un solo amministratore di Microsoft Entra per database SQL di Azure server. La selezione di un'altra sovrascriverà l'amministratore di Microsoft Entra esistente configurato per il server.
2) Eseguire la migrazione del codice dell'app per usare connessioni senza password
Usare quindi la procedura seguente per aggiornare il codice per usare connessioni senza password. Anche se concettualmente simile, ogni linguaggio usa dettagli di implementazione diversi.
All'interno del progetto aggiungere il riferimento seguente al
azure-identity
pacchetto. Questa libreria contiene tutte le entità necessarie per implementare connessioni senza password.<dependency> <groupId>com.azure</groupId> <artifactId>azure-identity</artifactId> <version>1.5.4</version> </dependency>
Abilitare l'autenticazione dell'identità gestita di Microsoft Entra nell'URL JDBC.v Identificare i percorsi nel codice che attualmente creano un
java.sql.Connection
oggetto per connettersi a database SQL di Azure. Aggiornare il codice in modo che corrisponda all'esempio seguente:String url = "jdbc:sqlserver://$AZ_DATABASE_SERVER_NAME.database.windows.net:1433;databaseName=$AZ_DATABASE_NAME;authentication=ActiveDirectoryMSI;" Connection con = DriverManager.getConnection(url);
Sostituire le due
$AZ_DATABASE_SERVER_NAME
variabili e una$AZ_DATABASE_NAME
variabile con i valori configurati all'inizio di questo articolo.Rimuovere e
user
password
dall'URL JDBC.
3) Configurare l'ambiente di hosting di Azure
Dopo aver configurato l'applicazione per l'uso di connessioni senza password, lo stesso codice può eseguire l'autenticazione ai servizi di Azure dopo la distribuzione in Azure. Ad esempio, un'applicazione distribuita in un'istanza del servizio app Azure con un'identità gestita assegnata può connettersi a Archiviazione di Azure.
In questa sezione verranno eseguiti due passaggi per consentire l'esecuzione dell'applicazione in un ambiente di hosting di Azure in modo senza password:
- Assegnare l'identità gestita per l'ambiente di hosting di Azure.
- Assegnare ruoli all'identità gestita.
Nota
Azure offre anche Service Connector, che consente di connettere il servizio di hosting con SQL Server. Con Service Connector per configurare l'ambiente di hosting, è possibile omettere il passaggio di assegnazione dei ruoli all'identità gestita perché Service Connector lo eseguirà automaticamente. La sezione seguente descrive come configurare l'ambiente di hosting di Azure in due modi: uno tramite Service Connector e l'altro configurando direttamente ogni ambiente di hosting.
Importante
I comandi di Service Connector richiedono l'interfaccia della riga di comando di Azure 2.41.0 o versione successiva.
Assegnare l'identità gestita usando il portale di Azure
I passaggi seguenti illustrano come assegnare un'identità gestita assegnata dal sistema per vari servizi di hosting Web. L'identità gestita può connettersi in modo sicuro ad altri servizi di Azure usando le configurazioni dell'app configurate in precedenza.
- Servizio app
- Connettore servizio
- App contenitore
- Azure Spring Apps
- Macchine virtuali
- servizio Azure Kubernetes
Nella pagina di panoramica principale dell'istanza del servizio app Azure selezionare Identità nel riquadro di spostamento.
Nella scheda Assegnata dal sistema assicurarsi di impostare il campo Stato su attivato. Un'identità assegnata dal sistema viene gestita internamente da Azure e gestisce automaticamente le attività amministrative. I dettagli e gli ID dell'identità non vengono mai esposti nel codice.
È anche possibile assegnare un'identità gestita in un ambiente di hosting di Azure usando l'interfaccia della riga di comando di Azure.
- Servizio app
- Connettore servizio
- App contenitore
- Azure Spring Apps
- Macchine virtuali
- servizio Azure Kubernetes
È possibile assegnare un'identità gestita a un'istanza del servizio app Azure con il comando az webapp identity assign, come illustrato nell'esempio seguente:
export AZ_MI_OBJECT_ID=$(az webapp identity assign \
--resource-group $AZ_RESOURCE_GROUP \
--name <service-instance-name> \
--query principalId \
--output tsv)
Assegnare ruoli all'identità gestita
Concedere quindi le autorizzazioni all'identità gestita creata per accedere al database SQL.
Se i servizi sono stati connessi tramite Service Connector, i comandi del passaggio precedente hanno già assegnato il ruolo, quindi è possibile ignorare questo passaggio.
Testare l'app
Dopo aver apportato queste modifiche al codice, è possibile compilare e ridistribuire l'applicazione. Passare quindi all'applicazione ospitata nel browser. L'app dovrebbe essere in grado di connettersi correttamente al database SQL di Azure. Tenere presente che la propagazione delle assegnazioni di ruolo nell'ambiente di Azure potrebbe richiedere alcuni minuti. L'applicazione è ora configurata per l'esecuzione sia in locale che in un ambiente di produzione senza che gli sviluppatori debbano gestire i segreti nell'applicazione stessa.
Passaggi successivi
In questa esercitazione si è appreso come eseguire la migrazione di un'applicazione a connessioni senza password.
È possibile leggere le risorse seguenti per esplorare i concetti illustrati in questo articolo in modo più approfondito: