Freigeben über

Migrieren einer Anwendung zur Verwendung von kennwortlosen Verbindungen mit Azure Database for PostgreSQL

  • Artikel

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 kennwortlose Verbindungen in Ihren Anwendungen priorisieren, wenn möglich.

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 Database for PostgreSQL unter Verwendung von Identitäten, die in Microsoft Entra ID definiert sind. 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 möchten, werden diese Anmeldeinformationen in der user-Tabelle gespeichert. Da diese Kennwörter in PostgreSQL gespeichert sind, müssen Sie die Rotation 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 ein 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 Verbindungszeichenfolge zu verwendenDefaultAzureCredential.

DefaultAzureCredential unterstützt mehrere Authentifizierungsmethoden und bestimmt automatisch, welche Methode zur Laufzeit verwendet werden soll. Mit diesem Ansatz kann Ihre App unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen (lokale Entwicklung gegenüber Produktion) 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, wechselt DefaultAzureCredential automatisch zur Verwendung einer verwalteten Identität. Für diesen Übergang sind keine Änderungen am Code erforderlich.

Um sicherzustellen, dass Verbindungen kennwortlos sind, müssen Sie sowohl die lokale Entwicklung als auch die Produktionsumgebung berücksichtigen. Wenn an beiden Stellen ein 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 bietet eine Sicherheitsidentität zur Darstellung einer App oder eines Diensts. Da die Identität von der Azure-Plattform verwaltet wird, müssen Sie keine Geheimnisse bereitstellen oder rotieren. 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

Richten Sie zunächst mithilfe des folgenden Befehls einige Umgebungsvariablen ein.

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. Er muss innerhalb von Azure eindeutig 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, auf dem Sie die Spring Boot-Anwendung ausführen. Sie können sie ganz einfach ermitteln, indem Sie whatismyip.akamai.com ö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 Microsoft Entra-Administratorbenutzer können Benutzer für die Microsoft Entra ID-basierte Authentifizierung erstellen/aktivieren.

Führen Sie zum Einrichten eines Microsoft Entra-Administrators nach dem Erstellen des Servers die Schritte unter Verwalten von Microsoft Entra-Rollen in Azure Database for PostgreSQL – Flexibler 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 Database for PostgreSQL-Instanzen sind standardmäßig gesichert. Sie besitzen eine Firewall, die keine eingehenden Verbindungen zulässt. Damit Sie die Datenbank verwenden können, müssen Sie eine Firewallregel hinzufügen, die den Zugriff der lokalen IP-Adresse auf den Datenbankserver zulässt.

Da Sie die lokale IP-Adresse zu Beginn 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 von 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 das Skript 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 zum Erstellen des/der Microsoft Entra-Benutzers/-Benutzerin ohne Administratorrechte auszuführen:

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 Database for 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

Führen Sie die Anwendung lokal aus, nachdem Sie diese Codeänderungen vorgenommen haben. 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 es 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 Dienstinstanz 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.

Wichtig

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

Zuweisen der verwalteten Identität mithilfe der Azure-Portal

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 auf sichere Weise eine Verbindung mit anderen Azure-Diensten herstellen.

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

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

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

Sie können einer Azure-App Dienstinstanz 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 einer Rolle 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. Denken Sie daran, dass es einige Minuten dauern kann, bis die Rollenzuweisungen in der Azure-Umgebung weitergegeben werden. Ihre Anwendung ist jetzt so konfiguriert, dass sie lokal und in einer Produktionsumgebung ausgeführt werden kann, ohne dass die Entwickler Geheimnisse in der Anwendung selbst verwalten müssen.

Nächste Schritte

In diesem Tutorial 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: