Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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. Mithilfe 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.
- Verwenden Sie PostgreSQL-Datenbankbenutzer mit Microsoft-Entra-Authentifizierung, um Identitäten auf Datenbankebene zu authentifizieren.
- Unterstützung der tokenbasierten Authentifizierung für Anwendungen, die eine Verbindung mit Azure Database for PostgreSQL herstellen.
PostgreSQL-Authentifizierung
Sie können Konten in PostgreSQL erstellen. Wenn Sie Kennwörter als Anmeldeinformationen für die Konten verwenden möchten, speichern Sie diese Anmeldeinformationen in der user Tabelle. Da PostgreSQL diese Kennwörter speichert, müssen Sie die Rotation der Kennwörter selbst verwalten.
Obwohl Sie eine Verbindung mit Azure Database for PostgreSQL mit Kennwörtern herstellen können, verwenden Sie sie mit Vorsicht. Machen Sie die Kennwörter niemals an einem unsicheren Speicherort verfügbar. Jeder, der Zugriff auf die Kennwörter erhält, kann sich authentifizieren. Beispielsweise kann ein bösartiger Benutzer auf die Anwendung zugreifen, wenn Sie versehentlich eine Verbindungszeichenfolge in die Quellcodeverwaltung einchecken, sie per unsicherer E-Mail senden, in den falschen Chat einfügen oder wenn sie von einer unbefugten Person eingesehen wird. 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 DefaultAzureCredential anstelle von Alternativen wie Verbindungszeichenfolgen zu verwenden.
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 DefaultAzureCredential nach Anmeldeinformationen sucht, finden Sie in der Übersicht über die Azure Identity-Bibliothek. Wenn Sie beispielsweise lokal arbeiten, authentifiziert sich DefaultAzureCredential im Allgemeinen mit dem Konto, 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 weder die Bereitstellung noch die Rotation von Geheimnissen. 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 für Ihre Ressourcen. -
<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 es sich bei dem Namen um einen gültigen Benutzer in Ihrem Microsoft Entra-Mandanten handelt. -
<YOUR_LOCAL_IP_ADDRESS>: Die IP-Adresse Ihres lokalen Computers, von dem Aus Sie Die 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
Wenn Sie Microsoft Entra ID Zugriff mit Azure Database for PostgreSQL verwenden möchten, legen Sie zuerst den Microsoft Entra Administratorbenutzer fest. Nur ein Microsoft Entra Administratorbenutzer kann Benutzer für Microsoft Entra ID basierte Authentifizierung erstellen oder 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 zu verwenden, müssen Sie eine Firewallregel hinzufügen, mit der Ihre 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 und den Microsoft Entra Nicht-Administratorbenutzer 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
Weitere 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. Authentifizieren Sie sich über die Azure CLI, Visual Studio, Azure PowerShell oder andere Tools wie IntelliJ.
- Azure CLI
- PowerShell
- Visual Studio
- Visual Studio Code
- IntelliJ
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.
Fügen Sie in Ihrem Projekt den folgenden Verweis auf das
azure-identity-extensionsPaket 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>Aktivieren Sie das Azure PostgreSQL-Authentifizierungsplugin in der JDBC-URL. Identifizieren Sie die Stellen in Ihrem Code, an denen derzeit ein
java.sql.Connectionerstellt wird, um eine Verbindung mit Azure Database for PostgreSQL herzustellen. Aktualisieren Sieurlunduserin Ihrer Datei application.properties, damit 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_USERNAMEErsetzen Sie die
$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAMEund die beiden$AZ_DATABASE_SERVER_NAMEVariablen durch den Wert, den Sie zu Beginn 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 nimmt Ihre lokalen Anmeldeinformationen auf, wenn Sie bei einer kompatiblen IDE oder einem Befehlszeilentool wie dem Azure CLI, Visual Studio oder IntelliJ angemeldet sind. Die Rollen, die Sie Ihrem lokalen Entwicklerbenutzer zugewiesen haben, in Azure es Ihrer App ermöglichen, eine lokale Verbindung mit dem Azure Dienst herzustellen.
4) Konfigurieren der Azure-Hostingumgebung
Nachdem Sie Ihre Anwendung so konfiguriert haben, dass kennwortlose Verbindungen verwendet und lokal ausgeführt werden, kann sich derselbe Code bei Azure Diensten authentifizieren, nachdem Sie sie für Azure bereitgestellt haben. 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 ihrer Anwendung die Ausführung 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. Wenn Sie Service Connector zum Konfigurieren Ihrer Hostingumgebung verwenden, können Sie den Schritt zum Zuweisen von Rollen zu Ihrer verwalteten Identität weglassen, da Service Connector sie ihnen zuweist. 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.
Wählen Sie auf der Hauptübersichtsseite Ihrer Azure App Service-Instanz im Navigationsbereich "Identität" aus.
Stellen Sie auf der Registerkarte Systemseitig zugewiesen sicher, dass das Feld Status auf Ein gesetzt 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 offengelegt.
Sie können auch eine verwaltete Identität in einer Azure Hostingumgebung zuweisen, indem Sie die Azure CLI verwenden.
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 für die verwaltete 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.
- Service Connector
- Azure CLI
Wenn Sie Ihre Dienste mithilfe von Service Connector verbunden haben, haben ihnen die Befehle im vorherigen Schritt 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 eine Verbindung mit PostgreSQL herstellt, indem Sie den Benutzer verwenden, den Sie für die verwaltete Identität erstellt haben.
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. Es kann mehrere Minuten dauern, 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.
Weitere Informationen zu den in diesem Artikel erläuterten Konzepten finden Sie in den folgenden Ressourcen: