Migrowanie aplikacji do używania połączeń bez hasła z usługą Azure Database for PostgreSQL

W tym artykule wyjaśniono, jak przeprowadzić migrację z tradycyjnych metod uwierzytelniania do bezpieczniejszych połączeń bez hasła za pomocą usługi Azure Database for PostgreSQL.

Żądania aplikacji do usługi Azure Database for PostgreSQL muszą być uwierzytelnione. Usługa Azure Database for PostgreSQL oferuje kilka różnych sposobów bezpiecznego łączenia aplikacji. Jednym ze sposobów jest użycie haseł. Jednak w miarę możliwości należy określić priorytety połączeń bez hasła w aplikacjach.

Porównanie opcji uwierzytelniania

Gdy aplikacja uwierzytelnia się w usłudze Azure Database for PostgreSQL, udostępnia parę nazw użytkowników i haseł w celu nawiązania połączenia z bazą danych. W zależności od tego, gdzie są przechowywane tożsamości, istnieją dwa typy uwierzytelniania: uwierzytelnianie Firmy Microsoft Entra i uwierzytelnianie PostgreSQL.

Uwierzytelnianie Microsoft Entra

Uwierzytelnianie entra firmy Microsoft to mechanizm nawiązywania połączenia z usługą Azure Database for PostgreSQL przy użyciu tożsamości zdefiniowanych w identyfikatorze Entra firmy Microsoft. Dzięki uwierzytelnieniu firmy Microsoft Entra można zarządzać tożsamościami użytkowników bazy danych i innymi usługi firmy Microsoft w centralnej lokalizacji, co upraszcza zarządzanie uprawnieniami.

Korzystanie z identyfikatora Entra firmy Microsoft do uwierzytelniania zapewnia następujące korzyści:

  • Uwierzytelnianie użytkowników w usługach platformy Azure w jednolity sposób.
  • Zarządzanie zasadami haseł i rotacją haseł w jednym miejscu.
  • Wiele form uwierzytelniania obsługiwanych przez identyfikator Entra firmy Microsoft, co może wyeliminować konieczność przechowywania haseł.
  • Klienci mogą zarządzać uprawnieniami bazy danych przy użyciu grup zewnętrznych (Microsoft Entra ID).
  • Uwierzytelnianie firmy Microsoft Entra używa użytkowników bazy danych PostgreSQL do uwierzytelniania tożsamości na poziomie bazy danych.
  • Obsługa uwierzytelniania opartego na tokenach dla aplikacji łączących się z usługą Azure Database for PostgreSQL.

Uwierzytelnianie bazy danych PostgreSQL

Konta można tworzyć w usłudze PostgreSQL. Jeśli zdecydujesz się używać haseł jako poświadczeń dla kont, te poświadczenia będą przechowywane w user tabeli. Ponieważ te hasła są przechowywane w usłudze PostgreSQL, musisz samodzielnie zarządzać rotacją haseł.

Chociaż istnieje możliwość nawiązania połączenia z usługą Azure Database for PostgreSQL przy użyciu haseł, należy ich używać ostrożnie. Musisz być sumienny, aby nigdy nie ujawniać haseł w niezabezpieczonej lokalizacji. Każdy, kto uzyskuje dostęp do haseł, może się uwierzytelnić. Istnieje na przykład ryzyko, że złośliwy użytkownik może uzyskać dostęp do aplikacji, jeśli parametry połączenia zostanie przypadkowo zaewidencjonowany w kontroli źródła, wysłany za pośrednictwem niezabezpieczonej wiadomości e-mail, wklejony do nieprawidłowego czatu lub wyświetlony przez osobę, która nie powinna mieć uprawnień. Zamiast tego rozważ zaktualizowanie aplikacji w celu korzystania z połączeń bez hasła.

Wprowadzenie do połączeń bez hasła

Za pomocą połączenia bez hasła można nawiązać połączenie z usługami platformy Azure bez przechowywania poświadczeń w kodzie aplikacji, jego plikach konfiguracji lub zmiennych środowiskowych.

Wiele usług platformy Azure obsługuje połączenia bez hasła, na przykład za pośrednictwem tożsamości zarządzanej platformy Azure. Te techniki zapewniają niezawodne funkcje zabezpieczeń, które można zaimplementować przy użyciu wartości DefaultAzureCredential z bibliotek klienckich tożsamości platformy Azure. Z tego samouczka dowiesz się, jak zaktualizować istniejącą aplikację do użycia DefaultAzureCredential zamiast alternatyw, takich jak parametry połączenia.

DefaultAzureCredential obsługuje wiele metod uwierzytelniania i automatycznie określa, które powinny być używane w czasie wykonywania. Takie podejście umożliwia aplikacji używanie różnych metod uwierzytelniania w różnych środowiskach (lokalnych deweloperów i produkcji) bez implementowania kodu specyficznego dla środowiska.

Kolejność i lokalizacje, w których DefaultAzureCredential można wyszukiwać poświadczenia, można znaleźć w przeglądzie biblioteki tożsamości platformy Azure. Na przykład podczas pracy lokalnie DefaultAzureCredential zazwyczaj uwierzytelnia się przy użyciu konta, które deweloper użył do logowania się w programie Visual Studio. Po wdrożeniu aplikacji na platformie Azure DefaultAzureCredential nastąpi automatyczne przełączenie w celu użycia tożsamości zarządzanej. Do tego przejścia nie są wymagane żadne zmiany kodu.

Aby upewnić się, że połączenia są bez hasła, należy wziąć pod uwagę zarówno lokalne programowanie, jak i środowisko produkcyjne. Jeśli parametry połączenia jest wymagana w obu miejscach, aplikacja nie jest bez hasła.

W lokalnym środowisku projektowym możesz uwierzytelnić się za pomocą interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell, programu Visual Studio lub wtyczek platformy Azure dla programu Visual Studio Code lub IntelliJ. W takim przypadku można użyć tego poświadczenia w aplikacji zamiast konfigurowania właściwości.

Podczas wdrażania aplikacji w środowisku hostingu platformy Azure, takim jak maszyna wirtualna, można przypisać tożsamość zarządzaną w tym środowisku. Następnie nie trzeba podawać poświadczeń w celu nawiązania połączenia z usługami platformy Azure.

Uwaga

Tożsamość zarządzana zapewnia tożsamość zabezpieczeń reprezentującą aplikację lub usługę. Tożsamość jest zarządzana przez platformę Azure i nie wymaga aprowizacji ani rotacji żadnych wpisów tajnych. Więcej informacji na temat tożsamości zarządzanych można uzyskać w dokumentacji przeglądu .

Migrowanie istniejącej aplikacji do korzystania z połączeń bez hasła

W poniższych krokach wyjaśniono, jak przeprowadzić migrację istniejącej aplikacji w celu używania połączeń bez hasła zamiast rozwiązania opartego na hasłach.

0) Przygotowywanie środowiska roboczego

Najpierw użyj następującego polecenia, aby skonfigurować niektóre zmienne środowiskowe.

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)

Zastąp symbole zastępcze następującymi wartościami, które są używane w tym artykule:

  • <YOUR_RESOURCE_GROUP>: nazwa grupy zasobów, w których znajdują się zasoby.
  • <YOUR_DATABASE_SERVER_NAME>: nazwa serwera PostgreSQL. Powinna być ona unikatowa w obrębie platformy Azure.
  • <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: nazwa wyświetlana użytkownika innego niż administrator firmy Microsoft. Upewnij się, że nazwa jest prawidłowym użytkownikiem w dzierżawie firmy Microsoft Entra.
  • <YOUR_LOCAL_IP_ADDRESS>: adres IP komputera lokalnego, z którego będzie uruchamiana aplikacja Spring Boot. Jednym z wygodnych sposobów znalezienia go jest otwarcie whatismyip.akamai.com.

1) Konfigurowanie usługi Azure Database for PostgreSQL

1.1) Włączanie uwierzytelniania opartego na identyfikatorze Entra firmy Microsoft

Aby użyć dostępu do identyfikatora Entra firmy Microsoft z usługą Azure Database for PostgreSQL, należy najpierw ustawić użytkownika administratora firmy Microsoft Entra. Tylko użytkownik firmy Microsoft Entra Administracja może tworzyć/włączać użytkowników na potrzeby uwierzytelniania opartego na identyfikatorze Entra firmy Microsoft.

Aby skonfigurować administratora firmy Microsoft Entra po utworzeniu serwera, wykonaj kroki opisane w temacie Zarządzanie rolami firmy Microsoft Entra w usłudze Azure Database for PostgreSQL — serwer elastyczny.

Uwaga

Serwer elastyczny PostgreSQL może tworzyć wielu administratorów firmy Microsoft Entra.

2) Konfigurowanie usługi Azure Database for PostgreSQL na potrzeby programowania lokalnego

2.1) Konfigurowanie reguły zapory dla lokalnego adresu IP

Wystąpienia usługi Azure Database for PostgreSQL są domyślnie zabezpieczone. Ma ona zaporę, która nie zezwala na żadne połączenie przychodzące. Aby móc używać bazy danych, należy dodać regułę zapory, która umożliwi lokalnemu adresowi IP dostęp do serwera bazy danych.

Ponieważ na początku tego artykułu skonfigurowano lokalny adres IP, możesz otworzyć zaporę serwera, uruchamiając następujące polecenie:

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

Jeśli łączysz się z serwerem PostgreSQL z Podsystem Windows dla systemu Linux (WSL) na komputerze z systemem Windows, musisz dodać identyfikator hosta WSL do zapory.

Uzyskaj adres IP maszyny hosta, uruchamiając następujące polecenie w programie WSL:

cat /etc/resolv.conf

Skopiuj adres IP zgodnie z terminem nameserver, a następnie użyj następującego polecenia, aby ustawić zmienną środowiskową dla adresu IP WSL:

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

Następnie użyj następującego polecenia, aby otworzyć zaporę serwera w aplikacji opartej na protokole WSL:

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) Tworzenie użytkownika niebędącego administratorem bazy danych PostgreSQL i udzielanie uprawnień

Następnie utwórz użytkownika innego niż administrator Firmy Microsoft Entra i przyznaj $AZ_DATABASE_NAME mu wszystkie uprawnienia do bazy danych. Nazwę bazy danych $AZ_DATABASE_NAME można zmienić zgodnie z potrzebami.

Utwórz skrypt SQL o nazwie create_ad_user_local.sql na potrzeby tworzenia użytkownika niebędącego administratorem. Dodaj następującą zawartość i zapisz ją lokalnie:

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

Następnie użyj następującego polecenia, aby uruchomić skrypt SQL w celu utworzenia użytkownika innego niż administrator firmy Microsoft:

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

Teraz użyj następującego polecenia, aby usunąć tymczasowy plik skryptu SQL:

rm create_ad_user_local.sql

Uwaga

Więcej szczegółowych informacji na temat tworzenia użytkowników postgreSQL można znaleźć w temacie Tworzenie użytkowników w usłudze Azure Database for PostgreSQL.

3) Zaloguj się i zmigruj kod aplikacji, aby używać połączeń bez hasła

W przypadku programowania lokalnego upewnij się, że uwierzytelniono się przy użyciu tego samego konta Microsoft Entra, do którego przypisano rolę w usłudze PostgreSQL. Możesz uwierzytelnić się za pomocą interfejsu wiersza polecenia platformy Azure, programu Visual Studio, programu Azure PowerShell lub innych narzędzi, takich jak IntelliJ.

Zaloguj się do platformy Azure za pomocą interfejsu wiersza polecenia platformy Azure przy użyciu następującego polecenia:

az login

Następnie wykonaj następujące kroki, aby zaktualizować kod w celu używania połączeń bez hasła. Chociaż koncepcyjnie podobne, każdy język używa różnych szczegółów implementacji.

  1. W projekcie dodaj następujące odwołanie do azure-identity-extensions pakietu. Ta biblioteka zawiera wszystkie jednostki niezbędne do zaimplementowania połączeń bez hasła.

    <dependency>
        <groupId>com.azure</groupId>
        <artifactId>azure-identity-extensions</artifactId>
        <version>1.0.0</version>
    </dependency>
    
  2. Włącz wtyczkę uwierzytelniania usługi Azure PostgreSQL w adresie URL JDBC. Zidentyfikuj lokalizacje w kodzie, które obecnie tworzą element w celu nawiązania połączenia z usługą java.sql.Connection Azure Database for PostgreSQL. Zaktualizuj url plik application.properties i user w pliku application.properties , aby był zgodny z następującymi wartościami:

    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. $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME Zastąp wartości i dwie $AZ_DATABASE_SERVER_NAME zmienne wartością skonfigurowaną na początku tego artykułu.

Lokalne uruchamianie aplikacji

Po wprowadzeniu tych zmian w kodzie uruchom aplikację lokalnie. Nowa konfiguracja powinna pobierać poświadczenia lokalne, jeśli logujesz się do zgodnego środowiska IDE lub narzędzia wiersza polecenia, takiego jak interfejs wiersza polecenia platformy Azure, program Visual Studio lub IntelliJ. Role przypisane do lokalnego użytkownika deweloperskiego na platformie Azure umożliwiają aplikacji nawiązywanie połączenia z usługą platformy Azure lokalnie.

4) Konfigurowanie środowiska hostingu platformy Azure

Po skonfigurowaniu aplikacji do używania połączeń bez hasła i uruchomieniu go lokalnie ten sam kod może uwierzytelniać się w usługach platformy Azure po jej wdrożeniu na platformie Azure. Na przykład aplikacja wdrożona w wystąpieniu usługi aplikacja systemu Azure z przypisaną tożsamością zarządzaną może łączyć się z usługą Azure Storage.

W tej sekcji wykonasz dwa kroki, aby umożliwić uruchamianie aplikacji w środowisku hostingu platformy Azure w sposób bez hasła:

  • Przypisz tożsamość zarządzaną dla środowiska hostingu platformy Azure.
  • Przypisz role do tożsamości zarządzanej.

Uwaga

Platforma Azure udostępnia również usługę Service Połączenie or, która może pomóc w połączeniu usługi hostingowej z usługą PostgreSQL. Za pomocą Połączenie usługi w celu skonfigurowania środowiska hostingu można pominąć krok przypisywania ról do tożsamości zarządzanej, ponieważ usługa Połączenie or zrobi to za Ciebie. W poniższej sekcji opisano sposób konfigurowania środowiska hostingu platformy Azure na dwa sposoby: jeden za pośrednictwem usługi Połączenie or i drugi przez bezpośrednie skonfigurowanie każdego środowiska hostingu.

Ważne

Polecenia usługi Połączenie or wymagają interfejsu wiersza polecenia platformy Azure w wersji 2.41.0 lub nowszej.

Przypisywanie tożsamości zarządzanej przy użyciu witryny Azure Portal

W poniższych krokach pokazano, jak przypisać tożsamość zarządzaną przypisaną przez system dla różnych usług hostingu sieci Web. Tożsamość zarządzana może bezpiecznie łączyć się z innymi usługami platformy Azure przy użyciu skonfigurowanych wcześniej konfiguracji aplikacji.

  1. Na stronie głównej przeglądu wystąpienia usługi aplikacja systemu Azure wybierz pozycję Tożsamość w okienku nawigacji.

  2. Na karcie Przypisane przez system upewnij się, że pole Stan ma wartość włączone. Tożsamość przypisana przez system jest zarządzana przez platformę Azure wewnętrznie i obsługuje zadania administracyjne. Szczegóły i identyfikatory tożsamości nigdy nie są ujawniane w kodzie.

    Screenshot of Azure portal Identity page of App Service resource with System assigned tab showing and Status field highlighted.

Tożsamość zarządzaną można również przypisać w środowisku hostingu platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure.

Tożsamość zarządzaną można przypisać do wystąpienia usługi aplikacja systemu Azure za pomocą polecenia az webapp identity assign, jak pokazano w poniższym przykładzie:

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

Przypisywanie ról do tożsamości zarządzanej

Następnie przyznaj uprawnienia tożsamości zarządzanej przypisanej do uzyskiwania dostępu do wystąpienia usługi PostgreSQL.

Jeśli usługi zostały połączone przy użyciu usługi service Połączenie or, polecenia poprzedniego kroku już przypisano rolę, aby pominąć ten krok.

Testowanie aplikacji

Przed wdrożeniem aplikacji w środowisku hostingu należy wprowadzić jeszcze jedną zmianę w kodzie, ponieważ aplikacja będzie łączyć się z bazą danych PostgreSQL przy użyciu użytkownika utworzonego dla tożsamości zarządzanej.

Zaktualizuj kod, aby używał użytkownika utworzonego dla tożsamości zarządzanej:

Uwaga

Jeśli użyto polecenia Service Połączenie or, pomiń ten krok.

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

Po wprowadzeniu tych zmian w kodzie możesz skompilować i ponownie wdrożyć aplikację. Następnie przejdź do aplikacji hostowanej w przeglądarce. Aplikacja powinna mieć możliwość pomyślnego nawiązania połączenia z bazą danych PostgreSQL. Należy pamiętać, że propagowanie przypisań ról za pośrednictwem środowiska platformy Azure może potrwać kilka minut. Aplikacja jest teraz skonfigurowana do uruchamiania zarówno lokalnie, jak i w środowisku produkcyjnym bez konieczności zarządzania wpisami tajnymi w samej aplikacji.

Następne kroki

W tym samouczku przedstawiono sposób migrowania aplikacji do połączeń bez hasła.

Aby zapoznać się z pojęciami omówionymi w tym artykule, zapoznaj się z następującymi zasobami: