Dela via


Migrera ett program för att använda lösenordslösa anslutningar med Azure Database for PostgreSQL

Den här artikeln beskriver hur du migrerar från traditionella autentiseringsmetoder till säkrare, lösenordslösa anslutningar med Azure Database for PostgreSQL.

Programbegäranden till Azure Database for PostgreSQL måste autentiseras. Azure Database for PostgreSQL tillhandahåller flera olika sätt för appar att ansluta på ett säkert sätt. Ett av sätten är att använda lösenord. Du bör dock prioritera lösenordslösa anslutningar i dina program när det är möjligt.

Jämför autentiseringsalternativ

När programmet autentiseras med Azure Database for PostgreSQL tillhandahåller det ett användarnamn och lösenordspar för att ansluta databasen. Beroende på var identiteterna lagras finns det två typer av autentisering: Microsoft Entra-autentisering och PostgreSQL-autentisering.

Microsoft Entra-autentisering

Microsoft Entra-autentisering är en mekanism för att ansluta till Azure Database for PostgreSQL med hjälp av identiteter som definierats i Microsoft Entra-ID. Med Microsoft Entra-autentisering kan du hantera databasanvändares identiteter och andra Microsoft usluge på en central plats, vilket förenklar behörighetshanteringen.

Användning av Microsoft Entra-ID för autentisering ger följande fördelar:

  • Autentisering av användare i Azure Services på ett enhetligt sätt.
  • Hantering av lösenordsprinciper och lösenordsrotation på en enda plats.
  • Flera former av autentisering som stöds av Microsoft Entra-ID, vilket kan eliminera behovet av att lagra lösenord.
  • Kunder kan hantera databasbehörigheter med hjälp av externa (Microsoft Entra ID)-grupper.
  • Microsoft Entra-autentisering använder PostgreSQL-databasanvändare för att autentisera identiteter på databasnivå.
  • Stöd för tokenbaserad autentisering för program som ansluter till Azure Database for PostgreSQL.

PostgreSQL-autentisering

Du kan skapa konton i PostgreSQL. Om du väljer att använda lösenord som autentiseringsuppgifter för kontona lagras dessa autentiseringsuppgifter i user tabellen. Eftersom dessa lösenord lagras i PostgreSQL måste du hantera rotationen av lösenorden själv.

Även om det är möjligt att ansluta till Azure Database for PostgreSQL med lösenord bör du använda dem med försiktighet. Du måste vara noggrann för att aldrig exponera lösenorden på en osäker plats. Alla som får åtkomst till lösenorden kan autentisera. Det finns till exempel en risk att en obehörig användare kan komma åt programmet om en niska veze av misstag checkas in i källkontrollen, skickas via ett osäkert e-postmeddelande, klistras in i fel chatt eller visas av någon som inte borde ha behörighet. Överväg i stället att uppdatera ditt program för att använda lösenordslösa anslutningar.

Introduktion till lösenordslösa anslutningar

Med en lösenordslös anslutning kan du ansluta till Azure-tjänster utan att lagra några autentiseringsuppgifter i programkoden, dess konfigurationsfiler eller i miljövariabler.

Många Azure-tjänster stöder lösenordslösa anslutningar, till exempel via Azure Managed Identity. De här teknikerna ger robusta säkerhetsfunktioner som du kan implementera med hjälp av DefaultAzureCredential från Azure Identity-klientbiblioteken. I den här självstudien får du lära dig hur du uppdaterar ett befintligt program så att det kan användas DefaultAzureCredential i stället för alternativ som niska veze.

DefaultAzureCredential stöder flera autentiseringsmetoder och avgör automatiskt vilka som ska användas vid körning. Med den här metoden kan din app använda olika autentiseringsmetoder i olika miljöer (lokal utveckling jämfört med produktion) utan att implementera miljöspecifik kod.

Ordningen och platserna där DefaultAzureCredential sökningar efter autentiseringsuppgifter finns i översikten över Azure Identity Library. När du till exempel arbetar lokalt DefaultAzureCredential autentiseras vanligtvis med det konto som utvecklaren använde för att logga in i Visual Studio. När appen distribueras till Azure DefaultAzureCredential växlar den automatiskt till att använda en hanterad identitet. Inga kodändringar krävs för den här övergången.

För att säkerställa att anslutningarna är lösenordslösa måste du ta hänsyn till både lokal utveckling och produktionsmiljön. Om en niska veze krävs på något av dessa ställe är programmet inte lösenordslöst.

I din lokala utvecklingsmiljö kan du autentisera med Azure CLI, Azure PowerShell, Visual Studio eller Azure-plugin-program för Visual Studio Code eller IntelliJ. I det här fallet kan du använda autentiseringsuppgifterna i ditt program i stället för att konfigurera egenskaper.

När du distribuerar program till en Azure-värdmiljö, till exempel en virtuell dator, kan du tilldela hanterad identitet i den miljön. Sedan behöver du inte ange autentiseringsuppgifter för att ansluta till Azure-tjänster.

Kommentar

En hanterad identitet tillhandahåller en säkerhetsidentitet som representerar en app eller tjänst. Identiteten hanteras av Azure-plattformen och kräver inte att du etablerar eller roterar några hemligheter. Du kan läsa mer om hanterade identiteter i översiktsdokumentationen.

Migrera ett befintligt program för att använda lösenordslösa anslutningar

Följande steg beskriver hur du migrerar ett befintligt program för att använda lösenordslösa anslutningar i stället för en lösenordsbaserad lösning.

0) Förbereda arbetsmiljön

Använd först följande kommando för att konfigurera vissa miljövariabler.

export AZ_RESOURCE_GROUP=<YOUR_RESOURCE_GROUP>
export AZ_DATABASE_SERVER_NAME=<YOUR_DATABASE_SERVER_NAME>
export AZ_DATABASE_NAME=demo
export AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME=<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>
export AZ_LOCAL_IP_ADDRESS=<YOUR_LOCAL_IP_ADDRESS>
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)

Ersätt platshållarna med följande värden, som används i hela artikeln:

  • <YOUR_RESOURCE_GROUP>: Namnet på resursgruppen som resurserna finns i.
  • <YOUR_DATABASE_SERVER_NAME>: Namnet på PostgreSQL-servern. Det ska vara unikt i Azure.
  • <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: Visningsnamnet för din Microsoft Entra-användare som inte är administratör. Kontrollera att namnet är en giltig användare i din Microsoft Entra-klientorganisation.
  • <YOUR_LOCAL_IP_ADDRESS>: IP-adressen för den lokala datorn som du ska köra Spring Boot-programmet från. Ett praktiskt sätt att hitta det är att öppna whatismyip.akamai.com.

1) Konfigurera Azure Database for PostgreSQL

1.1) Aktivera Microsoft Entra ID-baserad autentisering

Om du vill använda Microsoft Entra ID-åtkomst med Azure Database for PostgreSQL bör du först ange Microsoft Entra-administratörsanvändaren. Endast en Microsoft Entra-administratörsanvändare kan skapa/aktivera användare för Microsoft Entra-ID-baserad autentisering.

Om du vill konfigurera en Microsoft Entra-administratör när du har skapat servern följer du stegen i Hantera Microsoft Entra-roller i Azure Database for PostgreSQL – flexibel server.

Kommentar

PostgreSQL – flexibel server kan skapa flera Microsoft Entra-administratörer.

2) Konfigurera Azure Database for PostgreSQL för lokal utveckling

2.1) Konfigurera en brandväggsregel för lokal IP-adress

Azure Database for PostgreSQL-instanser skyddas som standard. Databaserna har en brandvägg som inte tillåter inkommande anslutningar. För att kunna använda databasen måste du lägga till en brandväggsregel som gör att den lokala IP-adressen kan komma åt databasservern.

Eftersom du konfigurerade din lokala IP-adress i början av den här artikeln kan du öppna serverns brandvägg genom att köra följande kommando:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_LOCAL_IP_ADDRESS \
    --end-ip-address $AZ_LOCAL_IP_ADDRESS \
    --output tsv

Om du ansluter till PostgreSQL-servern från Windows podsistem za Linux (WSL) på en Windows-dator måste du lägga till WSL-värd-ID:t i brandväggen.

Hämta IP-adressen för värddatorn genom att köra följande kommando i WSL:

cat /etc/resolv.conf

Kopiera IP-adressen efter termen nameserveroch använd sedan följande kommando för att ange en miljövariabel för WSL IP-adressen:

export AZ_WSL_IP_ADDRESS=<the-copied-IP-address>

Använd sedan följande kommando för att öppna serverns brandvägg till din WSL-baserade app:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_WSL_IP_ADDRESS \
    --end-ip-address $AZ_WSL_IP_ADDRESS \
    --output tsv

2.2) Skapa en PostgreSQL-användare som inte är administratör och bevilja behörighet

Skapa sedan en Microsoft Entra-användare som inte är administratör och bevilja alla behörigheter för databasen till den $AZ_DATABASE_NAME . Du kan ändra databasnamnet $AZ_DATABASE_NAME så att det passar dina behov.

Skapa ett SQL-skript med namnet create_ad_user_local.sql för att skapa en icke-administratörsanvändare. Lägg till följande innehåll och spara det lokalt:

cat << EOF > create_ad_user_local.sql
select * from pgaadauth_create_principal('$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME', false, false);
EOF

Använd sedan följande kommando för att köra SQL-skriptet för att skapa microsoft Entra-användaren som inte är administratör:

psql "host=$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com user=$CURRENT_USERNAME dbname=postgres port=5432 password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) sslmode=require" < create_ad_user_local.sql

Använd nu följande kommando för att ta bort den tillfälliga SQL-skriptfilen:

rm create_ad_user_local.sql

Kommentar

Du kan läsa mer detaljerad information om hur du skapar PostgreSQL-användare i Skapa användare i Azure Database for PostgreSQL.

3) Logga in och migrera appkoden för att använda lösenordslösa anslutningar

För lokal utveckling kontrollerar du att du är autentiserad med samma Microsoft Entra-konto som du tilldelade rollen till på din PostgreSQL. Du kan autentisera via Azure CLI, Visual Studio, Azure PowerShell eller andra verktyg som IntelliJ.

Logga in på Azure via Azure CLI med hjälp av följande kommando:

az login

Använd sedan följande steg för att uppdatera koden för att använda lösenordslösa anslutningar. Även om de är konceptuellt lika använder varje språk olika implementeringsinformation.

  1. Lägg till följande referens till azure-identity-extensions paketet i projektet. Det här biblioteket innehåller alla entiteter som krävs för att implementera lösenordslösa anslutningar.

    <dependency>
        <groupId>com.azure</groupId>
        <artifactId>azure-identity-extensions</artifactId>
        <version>1.0.0</version>
    </dependency>
    
  2. Aktivera plugin-programmet för Azure PostgreSQL-autentisering i JDBC-URL:en. Identifiera de platser i koden som för närvarande skapar en java.sql.Connection för att ansluta till Azure Database for PostgreSQL. Uppdatera url och user i filen application.properties för att matcha följande värden:

    url=jdbc:postgresql://$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require&authenticationPluginClassName=com.azure.identity.extensions.jdbc.postgresql.AzurePostgresqlAuthenticationPlugin
    user=$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME
    
  3. Ersätt variablerna $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME $AZ_DATABASE_SERVER_NAME och med det värde som du konfigurerade i början av den här artikeln.

Köra appen lokalt

När du har gjort dessa kodändringar kör du programmet lokalt. Den nya konfigurationen bör hämta dina lokala autentiseringsuppgifter om du är inloggad på ett kompatibelt IDE- eller kommandoradsverktyg, till exempel Azure CLI, Visual Studio eller IntelliJ. De roller som du har tilldelat till din lokala utvecklingsanvändare i Azure gör att appen kan ansluta till Azure-tjänsten lokalt.

4) Konfigurera Azure-värdmiljön

När programmet har konfigurerats för att använda lösenordslösa anslutningar och det körs lokalt kan samma kod autentisera till Azure-tjänster när det har distribuerats till Azure. Ett program som distribueras till en Azure App Service-instans som har en tilldelad hanterad identitet kan till exempel ansluta till Azure Storage.

I det här avsnittet kör du två steg för att göra det möjligt för ditt program att köras i en Azure-värdmiljö på ett lösenordslöst sätt:

  • Tilldela den hanterade identiteten för din Azure-värdmiljö.
  • Tilldela roller till den hanterade identiteten.

Kommentar

Azure tillhandahåller även Service Connector, som kan hjälpa dig att ansluta din värdtjänst till PostgreSQL. Med Service Connector för att konfigurera din värdmiljö kan du utelämna steget att tilldela roller till din hanterade identitet eftersom Service Connector gör det åt dig. I följande avsnitt beskrivs hur du konfigurerar din Azure-värdmiljö på två sätt: en via Service Connector och den andra genom att konfigurera varje värdmiljö direkt.

Viktigt!

Service Connector-kommandon kräver Azure CLI 2.41.0 eller senare.

Tilldela den hanterade identiteten med hjälp av Azure-portalen

Följande steg visar hur du tilldelar en systemtilldelad hanterad identitet för olika webbvärdtjänster. Den hanterade identiteten kan på ett säkert sätt ansluta till andra Azure-tjänster med hjälp av de appkonfigurationer som du konfigurerade tidigare.

  1. På huvudöversiktssidan för din Azure App Service-instans väljer du Identitet i navigeringsfönstret.

  2. På fliken Systemtilldelat ser du till att ange fältet Status till . En systemtilldelad identitet hanteras av Azure internt och hanterar administrativa uppgifter åt dig. Informationen och ID:t för identiteten visas aldrig i din kod.

Du kan också tilldela hanterad identitet i en Azure-värdmiljö med hjälp av Azure CLI.

Du kan tilldela en hanterad identitet till en Azure App Service-instans med kommandot az webapp identity assign , enligt följande exempel:

export AZ_MI_OBJECT_ID=$(az webapp identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

Tilldela roller till den hanterade identiteten

Bevilja sedan behörigheter till den hanterade identitet som du tilldelade för att få åtkomst till postgreSQL-instansen.

Om du har anslutit dina tjänster med hjälp av Service Connector har föregående stegs kommandon redan tilldelat rollen, så du kan hoppa över det här steget.

Testa appen

Innan du distribuerar appen till värdmiljön måste du göra ytterligare en ändring i koden eftersom programmet kommer att ansluta till PostgreSQL med den användare som skapats för den hanterade identiteten.

Uppdatera koden så att den använder den användare som skapats för den hanterade identiteten:

Kommentar

Om du använde kommandot Service Connector hoppar du över det här steget.

properties.put("user", "$AZ_POSTGRESQL_AD_MI_USERNAME");

När du har gjort dessa kodändringar kan du skapa och distribuera om programmet. Bläddra sedan till ditt värdbaserade program i webbläsaren. Appen bör kunna ansluta till PostgreSQL-databasen. Tänk på att det kan ta flera minuter innan rolltilldelningarna sprids via din Azure-miljö. Ditt program är nu konfigurerat att köras både lokalt och i en produktionsmiljö utan att utvecklarna behöver hantera hemligheter i själva programmet.

Nästa steg

I den här självstudien har du lärt dig hur du migrerar ett program till lösenordslösa anslutningar.

Du kan läsa följande resurser för att utforska begreppen som beskrivs i den här artikeln mer ingående: