Freigeben über


Migrieren einer Anwendung zur Verwendung kennwortloser Verbindungen mit Azure-Datenbank für PostgreSQL

In diesem Artikel wird erläutert, wie Sie von herkömmlichen Authentifizierungsmethoden zu sichereren, kennwortlosen Verbindungen mit Azure Database for PostgreSQL migrieren.

Anwendungsanforderungen an Azure Database für PostgreSQL müssen authentifiziert werden. Azure Database for PostgreSQL bietet verschiedene Möglichkeiten, wie Apps eine sichere Verbindung herstellen können. Eine der Möglichkeiten besteht darin, Kennwörter zu verwenden. Sie sollten jedoch nach Möglichkeit kennwortlose Verbindungen in Ihren Anwendungen priorisieren.

Vergleichen von Authentifizierungsoptionen

Wenn sich die Anwendung bei Azure Database für PostgreSQL authentifiziert, stellt sie ein Benutzernamen- und Kennwortpaar bereit, um die Datenbank zu verbinden. Je nachdem, wo die Identitäten gespeichert werden, gibt es zwei Arten von Authentifizierung: Microsoft Entra-Authentifizierung und PostgreSQL-Authentifizierung.

Microsoft Entra-Authentifizierung

Die Microsoft Entra-Authentifizierung ist ein Mechanismus zum Herstellen einer Verbindung mit Azure-Datenbank für PostgreSQL mithilfe von In Microsoft Entra ID definierten Identitäten. Mit der Microsoft Entra-Authentifizierung können Sie Datenbankbenutzeridentitäten und andere Microsoft-Dienste an einem zentralen Ort verwalten, wodurch die Berechtigungsverwaltung vereinfacht wird.

Die Verwendung der Microsoft Entra-ID für die Authentifizierung bietet die folgenden Vorteile:

  • Authentifizierung von Benutzern über Azure Services hinweg auf einheitliche Weise.
  • Verwaltung von Kennwortrichtlinien und Kennwortrotation an einem zentralen Ort.
  • Mehrere Von Microsoft Entra ID unterstützte Authentifizierungsformen, die die Notwendigkeit zum Speichern von Kennwörtern vermeiden können.
  • Kunden können Datenbankberechtigungen mithilfe externer Gruppen (Microsoft Entra ID) verwalten.
  • Die Microsoft Entra-Authentifizierung verwendet Benutzer der PostgreSQL-Datenbank, um Identitäten auf Datenbankebene zu authentifizieren.
  • Unterstützung der tokenbasierten Authentifizierung für Anwendungen, die eine Verbindung mit Azure-Datenbank für PostgreSQL herstellen.

PostgreSQL-Authentifizierung

Sie können Konten in PostgreSQL erstellen. Wenn Sie Kennwörter als Anmeldeinformationen für die Konten verwenden, werden diese Anmeldeinformationen in der user Tabelle gespeichert. Da diese Kennwörter in PostgreSQL gespeichert sind, müssen Sie die Drehung der Kennwörter selbst verwalten.

Obwohl es möglich ist, eine Verbindung mit Azure Database for PostgreSQL mit Kennwörtern herzustellen, sollten Sie sie mit Vorsicht verwenden. Sie müssen fleißig sein, die Kennwörter niemals an einem unsicheren Speicherort verfügbar zu machen. Jeder, der Zugriff auf die Kennwörter erhält, kann sich authentifizieren. So besteht beispielsweise das Risiko, dass ein böswilliger Benutzer auf die Anwendung zugreifen kann, wenn eine Verbindungszeichenfolge versehentlich in die Quellcodeverwaltung eingecheckt, über eine unsichere E-Mail gesendet, in den falschen Chat eingefügt oder von jemandem angezeigt wird, der nicht über die Berechtigung verfügen sollte. Erwägen Sie stattdessen, Ihre Anwendung so zu aktualisieren, dass kennwortlose Verbindungen verwendet werden.

Einführung kennwortloser Verbindungen

Mit einer kennwortlosen Verbindung können Sie eine Verbindung mit Azure-Diensten herstellen, ohne Anmeldeinformationen im Anwendungscode, den zugehörigen Konfigurationsdateien oder in Umgebungsvariablen zu speichern.

Viele Azure-Dienste unterstützen kennwortlose Verbindungen, z. B. über Azure Managed Identity. Diese Techniken bieten robuste Sicherheitsfeatures, die Sie mithilfe von DefaultAzureCredential aus den Azure Identity-Clientbibliotheken implementieren können. In diesem Lernprogramm erfahren Sie, wie Sie eine vorhandene Anwendung aktualisieren, um sie anstelle von Alternativen wie Verbindungszeichenfolgen zu verwenden DefaultAzureCredential .

DefaultAzureCredential unterstützt mehrere Authentifizierungsmethoden und bestimmt automatisch, welche zur Laufzeit verwendet werden sollen. Mit diesem Ansatz kann Ihre App unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen (lokaler Entwicklungs- und Produktionsumgebung) verwenden, ohne umgebungsspezifischen Code zu implementieren.

Die Reihenfolge und Die Speicherorte, in denen nach Anmeldeinformationen gesucht wird, DefaultAzureCredential finden Sie in der Übersicht über die Azure Identity-Bibliothek. Wenn Sie beispielsweise lokal arbeiten, authentifiziert sich der Entwickler in der Regel mithilfe des Kontos, DefaultAzureCredential das der Entwickler für die Anmeldung bei Visual Studio verwendet hat. Wenn die App in Azure bereitgestellt wird, DefaultAzureCredential wechselt automatisch zur Verwendung einer verwalteten Identität. Für diesen Übergang sind keine Codeänderungen erforderlich.

Um sicherzustellen, dass Verbindungen kennwortlos sind, müssen Sie sowohl die lokale Entwicklung als auch die Produktionsumgebung berücksichtigen. Wenn an beiden Stellen eine Verbindungszeichenfolge erforderlich ist, ist die Anwendung nicht kennwortlos.

In Ihrer lokalen Entwicklungsumgebung können Sie sich mit Azure CLI, Azure PowerShell, Visual Studio oder Azure-Plug-Ins für Visual Studio Code oder IntelliJ authentifizieren. In diesem Fall können Sie diese Anmeldeinformationen in Ihrer Anwendung verwenden, anstatt Eigenschaften zu konfigurieren.

Wenn Sie Anwendungen in einer Azure-Hostingumgebung bereitstellen, z. B. einem virtuellen Computer, können Sie verwaltete Identitäten in dieser Umgebung zuweisen. Anschließend müssen Sie keine Anmeldeinformationen angeben, um eine Verbindung mit Azure-Diensten herzustellen.

Hinweis

Eine verwaltete Identität stellt eine Sicherheitsidentität bereit, die eine App oder einen Dienst darstellt. Die Identität wird von der Azure-Plattform verwaltet und erfordert keine Bereitstellung oder Drehung geheimer Schlüssel. Weitere Informationen zu verwalteten Identitäten finden Sie in der Übersichtsdokumentation .

Migrieren einer vorhandenen Anwendung zur Verwendung kennwortloser Verbindungen

In den folgenden Schritten wird erläutert, wie Sie eine vorhandene Anwendung migrieren, um kennwortlose Verbindungen anstelle einer kennwortbasierten Lösung zu verwenden.

0) Vorbereiten der Arbeitsumgebung

Verwenden Sie zunächst den folgenden Befehl, um einige Umgebungsvariablen einzurichten.

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)

Ersetzen Sie die Platzhalter durch die folgenden Werte, die in diesem Artikel verwendet werden:

  • <YOUR_RESOURCE_GROUP>: Der Name der Ressourcengruppe, in der sich Die Ressourcen befinden.
  • <YOUR_DATABASE_SERVER_NAME>: Der Name Ihres PostgreSQL-Servers. Es sollte in Azure einzigartig sein.
  • <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: Der Anzeigename Ihres Nicht-Administratorbenutzers von Microsoft Entra. Stellen Sie sicher, dass der Name ein gültiger Benutzer in Ihrem Microsoft Entra-Mandanten ist.
  • <YOUR_LOCAL_IP_ADDRESS>: Die IP-Adresse Ihres lokalen Computers, von dem Aus Sie Ihre Spring Boot-Anwendung ausführen. Eine bequeme Möglichkeit, es zu finden, besteht darin, whatismyip.akamai.com zu öffnen.

1) Konfigurieren der Azure-Datenbank für PostgreSQL

1.1) Aktivieren der microsoft Entra ID-basierten Authentifizierung

Um den Microsoft Entra ID-Zugriff mit Azure Database für PostgreSQL zu verwenden, sollten Sie zuerst den Microsoft Entra-Administratorbenutzer festlegen. Nur ein Microsoft Entra-Administratorbenutzer kann Benutzer für die microsoft Entra ID-basierte Authentifizierung erstellen/aktivieren.

Um einen Microsoft Entra-Administrator nach dem Erstellen des Servers einzurichten, führen Sie die Schritte unter Verwalten von Microsoft Entra-Rollen in Azure Database for PostgreSQL – Flexible Server aus.

Hinweis

PostgreSQL Flexible Server kann mehrere Microsoft Entra-Administratoren erstellen.

2) Konfigurieren der Azure-Datenbank für PostgreSQL für die lokale Entwicklung

2.1) Konfigurieren einer Firewallregel für lokale IP

Azure-Datenbank für PostgreSQL-Instanzen sind standardmäßig gesichert. Sie verfügen über eine Firewall, die keine eingehende Verbindung zulässt. Um Ihre Datenbank verwenden zu können, müssen Sie eine Firewallregel hinzufügen, mit der die lokale IP-Adresse auf den Datenbankserver zugreifen kann.

Da Sie Ihre lokale IP-Adresse am Anfang dieses Artikels konfiguriert haben, können Sie die Firewall des Servers öffnen, indem Sie den folgenden Befehl ausführen:

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

Wenn Sie eine Verbindung mit Ihrem PostgreSQL-Server über das Windows-Subsystem für Linux (WSL) auf einem Windows-Computer herstellen, müssen Sie der Firewall die WSL-Host-ID hinzufügen.

Rufen Sie die IP-Adresse Ihres Hostcomputers ab, indem Sie den folgenden Befehl in WSL ausführen:

cat /etc/resolv.conf

Kopieren Sie die IP-Adresse nach dem Ausdruck nameserver, und verwenden Sie dann den folgenden Befehl, um eine Umgebungsvariable für die WSL-IP-Adresse festzulegen:

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

Verwenden Sie dann den folgenden Befehl, um die Firewall des Servers für Ihre WSL-basierte App zu öffnen:

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) Erstellen eines Nicht-Administratorbenutzers von PostgreSQL und Erteilen von Berechtigungen

Erstellen Sie als Nächstes einen Nichtadministrator-Microsoft Entra-Benutzer, und erteilen Sie ihm alle Berechtigungen für die $AZ_DATABASE_NAME Datenbank. Sie können den Datenbanknamen $AZ_DATABASE_NAME entsprechend Ihren Anforderungen ändern.

Erstellen Sie ein SQL-Skript namens create_ad_user_local.sql zum Erstellen eines Nicht-Administratorbenutzers. Fügen Sie den folgenden Inhalt hinzu, und speichern Sie ihn lokal:

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

Verwenden Sie dann den folgenden Befehl, um das SQL-Skript auszuführen, um den Nicht-Administratorbenutzer Von Microsoft Entra zu erstellen:

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

Verwenden Sie nun den folgenden Befehl, um die temporäre SQL-Skriptdatei zu entfernen:

rm create_ad_user_local.sql

Hinweis

Ausführlichere Informationen zum Erstellen von PostgreSQL-Benutzern finden Sie unter "Erstellen von Benutzern in Azure-Datenbank für PostgreSQL".

3) Melden Sie sich an, und migrieren Sie den App-Code, um kennwortlose Verbindungen zu verwenden.

Stellen Sie für die lokale Entwicklung sicher, dass Sie mit demselben Microsoft Entra-Konto authentifiziert sind, dem Sie die Rolle in Ihrer PostgreSQL zugewiesen haben. Sie können sich über die Azure CLI, Visual Studio, Azure PowerShell oder andere Tools wie IntelliJ authentifizieren.

Melden Sie sich mit dem folgenden Befehl bei Azure über die Azure CLI an:

az login

Führen Sie als Nächstes die folgenden Schritte aus, um Ihren Code so zu aktualisieren, dass kennwortlose Verbindungen verwendet werden. Obwohl konzeptionell ähnlich, verwendet jede Sprache unterschiedliche Implementierungsdetails.

  1. Fügen Sie in Ihrem Projekt den folgenden Verweis auf das azure-identity-extensions Paket hinzu. Diese Bibliothek enthält alle Entitäten, die zum Implementieren kennwortloser Verbindungen erforderlich sind.

    <dependency>
        <groupId>com.azure</groupId>
        <artifactId>azure-identity-extensions</artifactId>
        <version>1.0.0</version>
    </dependency>
    
  2. Aktivieren Sie das Azure PostgreSQL-Authentifizierungs-Plug-In in DER URL VON URL. Identifizieren Sie die Speicherorte in Ihrem Code, die derzeit eine java.sql.Connection Verbindung mit Azure-Datenbank für PostgreSQL erstellen. Aktualisieren Sie url die user Datei "application.properties" so, dass sie den folgenden Werten entspricht:

    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. Ersetzen Sie die $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME beiden Variablen durch $AZ_DATABASE_SERVER_NAME den Wert, den Sie am Anfang dieses Artikels konfiguriert haben.

Lokales Ausführen der App

Nachdem Sie diese Codeänderungen vorgenommen haben, führen Sie Ihre Anwendung lokal aus. Die neue Konfiguration sollte Ihre lokalen Anmeldeinformationen übernehmen, wenn Sie bei einer kompatiblen IDE oder einem Befehlszeilentool wie azure CLI, Visual Studio oder IntelliJ angemeldet sind. Die Rollen, die Sie Ihrem lokalen Entwicklerbenutzer in Azure zugewiesen haben, ermöglichen Ihrer App, eine lokale Verbindung mit dem Azure-Dienst herzustellen.

4) Konfigurieren der Azure-Hostingumgebung

Nachdem Ihre Anwendung für die Verwendung kennwortloser Verbindungen konfiguriert und lokal ausgeführt wird, kann sich derselbe Code bei Azure-Diensten authentifizieren, nachdem sie in Azure bereitgestellt wurde. Beispielsweise kann eine Anwendung, die in einer Azure App Service-Instanz bereitgestellt wird, die über eine verwaltete Identität verfügt, eine Verbindung mit Azure Storage herstellen.

In diesem Abschnitt führen Sie zwei Schritte aus, um die Ausführung Ihrer Anwendung in einer Azure-Hostingumgebung auf kennwortlose Weise zu ermöglichen:

  • Weisen Sie die verwaltete Identität für Ihre Azure-Hostingumgebung zu.
  • Weisen Sie der verwalteten Identität Rollen zu.

Hinweis

Azure stellt auch Service Connector bereit, der Ihnen dabei helfen kann, Ihren Hostingdienst mit PostgreSQL zu verbinden. Mit Service Connector zum Konfigurieren Ihrer Hostingumgebung können Sie den Schritt zum Zuweisen von Rollen zu Ihrer verwalteten Identität weglassen, da Service Connector dies für Sie tut. Im folgenden Abschnitt wird beschrieben, wie Sie Ihre Azure-Hostingumgebung auf zwei Arten konfigurieren: eine über Service Connector und die andere, indem Sie jede Hostingumgebung direkt konfigurieren.

Von Bedeutung

Die Befehle von Service Connector erfordern Azure CLI 2.41.0 oder höher.

Zuweisen der verwalteten Identität mithilfe des Azure-Portals

Die folgenden Schritte zeigen, wie Sie eine vom System zugewiesene verwaltete Identität für verschiedene Webhostingdienste zuweisen. Die verwaltete Identität kann mithilfe der zuvor eingerichteten App-Konfigurationen sicher eine Verbindung mit anderen Azure-Diensten herstellen.

  1. Wählen Sie auf der Hauptübersichtsseite Ihrer Azure App Service-Instanz im Navigationsbereich "Identität" aus.

  2. Stellen Sie auf der Registerkarte "System zugewiesen " sicher, dass das Feld "Status " aktiviert ist. Eine vom System zugewiesene Identität wird von Azure intern verwaltet und verwaltet Administrative Aufgaben für Sie. Die Details und IDs der Identität werden in Ihrem Code nie verfügbar gemacht.

Sie können auch verwaltete Identitäten in einer Azure-Hostingumgebung mithilfe der Azure CLI zuweisen.

Sie können einer Azure App Service-Instanz eine verwaltete Identität mit dem Befehl "az webapp identity assign" zuweisen , wie im folgenden Beispiel gezeigt:

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

Zuweisen von Rollen zur verwalteten Identität

Erteilen Sie als Nächstes Berechtigungen für die verwaltete Identität, die Sie für den Zugriff auf Ihre PostgreSQL-Instanz zugewiesen haben.

Wenn Sie Ihre Dienste mit Service Connector verbunden haben, haben ihnen die Befehle des vorherigen Schritts bereits die Rolle zugewiesen, sodass Sie diesen Schritt überspringen können.

Testen der App

Bevor Sie die App in der Hostingumgebung bereitstellen, müssen Sie eine weitere Änderung am Code vornehmen, da die Anwendung mithilfe des benutzers, der für die verwaltete Identität erstellt wurde, eine Verbindung mit PostgreSQL herstellen wird.

Aktualisieren Sie Ihren Code so, dass der für die verwaltete Identität erstellte Benutzer verwendet wird:

Hinweis

Wenn Sie den Befehl "Service Connector" verwendet haben, überspringen Sie diesen Schritt.

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

Nachdem Sie diese Codeänderungen vorgenommen haben, können Sie die Anwendung erstellen und erneut bereitstellen. Navigieren Sie dann im Browser zu Ihrer gehosteten Anwendung. Ihre App sollte erfolgreich eine Verbindung mit der PostgreSQL-Datenbank herstellen können. Beachten Sie, dass es mehrere Minuten dauern kann, bis die Rollenzuweisungen über Ihre Azure-Umgebung verteilt werden. Ihre Anwendung ist jetzt so konfiguriert, dass sie sowohl lokal als auch in einer Produktionsumgebung ausgeführt wird, ohne dass entwickler geheime Schlüssel in der Anwendung selbst verwalten müssen.

Nächste Schritte

In diesem Lernprogramm haben Sie gelernt, wie Sie eine Anwendung zu kennwortlosen Verbindungen migrieren.

Sie können die folgenden Ressourcen lesen, um die in diesem Artikel erläuterten Konzepte ausführlicher zu erkunden: