Перевод приложения на использование подключений без паролей с базой данных Azure для PostgreSQL

В этой статье объясняется, как перенести традиционные методы проверки подлинности на более безопасные, без пароля подключения к Базе данных Azure для PostgreSQL.

Запросы приложений к Базе данных Azure для PostgreSQL должны проходить проверку подлинности. База данных Azure для PostgreSQL предоставляет несколько различных способов безопасного подключения приложений. Одним из способов является использование паролей. Однако по возможности следует определить приоритеты подключений без пароля в приложениях.

Сравнение параметров проверки подлинности

Когда приложение проходит проверку подлинности с помощью Базы данных Azure для PostgreSQL, оно предоставляет пару имени пользователя и пароля для подключения к базе данных. В зависимости от того, где хранятся удостоверения, существует два типа проверки подлинности: проверка подлинности Microsoft Entra и проверка подлинности PostgreSQL.

Аутентификация Microsoft Entra

Проверка подлинности Microsoft Entra — это механизм подключения к базе данных Azure для PostgreSQL с помощью удостоверений, определенных в идентификаторе Microsoft Entra. С помощью проверки подлинности Microsoft Entra можно управлять удостоверениями пользователей базы данных и другими службами Майкрософт в центральном расположении, что упрощает управление разрешениями.

Использование идентификатора Microsoft Entra для проверки подлинности обеспечивает следующие преимущества:

Проверка подлинности пользователей в службах Azure в единообразном режиме.
Управление политиками паролей и сменой паролей в одном месте.
Несколько форм проверки подлинности, поддерживаемых идентификатором Microsoft Entra, что может устранить необходимость хранения паролей.
Клиенты могут управлять разрешениями базы данных с помощью внешних групп (Microsoft Entra ID).
Аутентификация Microsoft Entra использует пользователей базы данных PostgreSQL для удостоверения личностей на уровне базы данных.
Поддержка проверки подлинности на основе маркеров для приложений, подключающихся к Базе данных Azure для PostgreSQL.

Проверка подлинности PostgreSQL

Учетные записи можно создать в PostgreSQL. Если вы решили использовать пароли в качестве учетных данных для учетных записей, эти учетные данные будут храниться в user таблице. Так как эти пароли хранятся в PostgreSQL, вам нужно самостоятельно управлять сменой паролей.

Хотя можно подключиться к Базе данных Azure для PostgreSQL с паролями, их следует использовать с осторожностью. Вы должны быть старательными, чтобы никогда не предоставлять пароли в небезопасном расположении. Любой, кто получает доступ к паролям, может пройти проверку подлинности. Например, существует риск того, что злоумышленник может получить доступ к приложению, если строка подключения случайно добавляется в систему управления исходным кодом, отправляется через незащищенное сообщение электронной почты, вставляется в неправильный чат или просматривается кем-то, кто не должен иметь разрешения. Вместо этого попробуйте обновить приложение для использования бессерверных подключений.

Знакомство с бессерверными подключениями

С помощью бессерверного подключения можно подключиться к службам Azure, не сохраняя учетные данные в коде приложения, его файлах конфигурации или переменных среды.

Многие службы Azure поддерживают безпарольные подключения, например с помощью управляемой идентификации Azure. Эти методы предоставляют надежные функции безопасности, которые можно реализовать с помощью DefaultAzureCredential из клиентских библиотек удостоверений Azure. В этом руководстве вы узнаете, как обновить существующее приложение для использования DefaultAzureCredential вместо альтернативных вариантов, таких как строки подключения.

DefaultAzureCredential поддерживает несколько методов проверки подлинности и автоматически определяет, какие из них следует использовать во время выполнения. Этот подход позволяет приложению использовать различные методы проверки подлинности в разных средах (локальная среда разработки и рабочая среда) без реализации кода для конкретной среды.

Порядок и расположения поиска учетных данных с помощью DefaultAzureCredential описаны в обзоре библиотеки идентификации Azure. Например, при локальной работе проверка подлинности обычно будет выполняться с использованием учетной записи разработчика, DefaultAzureCredential применяемой для входа в Visual Studio. При развертывании приложения в Azure DefaultAzureCredential автоматически переключается на использование управляемого удостоверения. Для этого перехода изменения кода не требуются.

Чтобы обеспечить без пароля подключения, необходимо учитывать как локальную разработку, так и рабочую среду. Если строка подключения требуется в любом месте, приложение не является безпарольным.

В локальной среде разработки можно пройти проверку подлинности с помощью Azure CLI, Azure PowerShell, Visual Studio или подключаемых модулей Azure для Visual Studio Code или IntelliJ. В этом случае вы можете использовать эти учетные данные в приложении вместо настройки свойств.

При развертывании приложений, например на виртуальной машине, в облаке Azure, можно назначить управляемое удостоверение в рамках этой среды. Затем вам не потребуется предоставить учетные данные для подключения к службам Azure.

Замечание

Управляемая учетная запись предоставляет удостоверение безопасности для представления приложения или службы. Идентичность управляется платформой Azure и не требует выделения или смены секретов. Дополнительные сведения об управляемых удостоверениях можно найти в разделе обзор документации.

Перенос существующего приложения на использование бессерверных подключений

В следующих шагах объясняется, как перенести существующее приложение для использования бессерверных подключений вместо решения на основе паролей.

0) Подготовка рабочей среды

Сначала используйте следующую команду, чтобы настроить некоторые переменные среды.

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)

Замените заполнители следующими значениями, которые используются в этой статье:

<YOUR_RESOURCE_GROUP>: имя группы ресурсов, в которые находятся ваши ресурсы.
<YOUR_DATABASE_SERVER_NAME>: имя сервера PostgreSQL. Он должен быть уникальным в Azure.
<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: отображаемое имя пользователя Microsoft Entra, не являющегося администратором. Убедитесь, что имя является действительным пользователем в клиенте Microsoft Entra.
<YOUR_LOCAL_IP_ADDRESS>: IP-адрес локального компьютера, с которого будет запущено приложение Spring Boot. Один из удобных способов найти его — открыть whatismyip.akamai.com.

1) Настройка базы данных Azure для PostgreSQL

1.1) Включение проверки подлинности на основе идентификатора Microsoft Entra

Чтобы использовать доступ к идентификатору Microsoft Entra с базой данных Azure для PostgreSQL, сначала необходимо задать пользователя администратора Microsoft Entra. Только пользователь Microsoft Entra Admin может создавать и включать пользователей для проверки подлинности на основе идентификаторов Майкрософт.

Чтобы настроить администратора Microsoft Entra после создания сервера, выполните действия по управлению ролями Microsoft Entra в Базе данных Azure для PostgreSQL — гибкий сервер.

Замечание

Гибкий сервер PostgreSQL может создавать несколько администраторов Microsoft Entra.

2) Настройка базы данных Azure для PostgreSQL для локальной разработки

2.1) Настройка правила брандмауэра для локального IP-адреса

Экземпляры Базы данных Azure для PostgreSQL защищены по умолчанию. У них есть брандмауэр, который не разрешает входящие подключения. Чтобы использовать базу данных, необходимо добавить правило брандмауэра, которое позволит локальному IP-адресу получить доступ к серверу базы данных.

Так как вы настроили локальный IP-адрес в начале этой статьи, можно открыть брандмауэр сервера, выполнив следующую команду:

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

Если вы подключаетесь к серверу PostgreSQL из подсистемы Windows для Linux (WSL) на компьютере Windows, необходимо добавить идентификатор узла WSL в брандмауэр.

Получите IP-адрес хост-компьютера, выполнив следующую команду в WSL:

cat /etc/resolv.conf

Скопируйте IP-адрес после термина nameserver, а затем используйте следующую команду, чтобы задать переменную среды для IP-адреса WSL:

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

Затем используйте следующую команду, чтобы открыть брандмауэр сервера в приложении на основе 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) Создание пользователя, отличного от администратора PostgreSQL, и предоставление разрешения

Затем создайте пользователя Microsoft Entra без администратора и предоставьте ему все разрешения для $AZ_DATABASE_NAME базы данных. Имя базы данных $AZ_DATABASE_NAME можно изменить в соответствии с вашими потребностями.

Создайте скрипт SQL с именем create_ad_user_local.sql для создания пользователя без администратора. Добавьте следующее содержимое и сохраните его локально:

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

Затем используйте следующую команду для запуска SQL-скрипта с целью создания не администраторского пользователя Microsoft Entra.

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

Теперь используйте следующую команду, чтобы удалить временный файл скрипта SQL:

rm create_ad_user_local.sql

Замечание

Дополнительные сведения о создании пользователей PostgreSQL см. в статье "Создание пользователей в Базе данных Azure для PostgreSQL".

Для локальной разработки убедитесь, что вы аутентифицированы с той же учетной записью Microsoft Entra, которой вы назначили роль на вашем PostgreSQL. Вы можете пройти проверку подлинности с помощью Azure CLI, Visual Studio, Azure PowerShell или других средств, таких как IntelliJ.

Войдите в Azure с помощью Azure CLI, выполнив следующую команду:

az login

Войдите в Azure с помощью PowerShell с помощью следующей команды:

Connect-AzAccount

Затем выполните следующие действия, чтобы обновить код для использования подключений без пароля. Хотя и концептуально аналогично, каждый язык использует различные сведения о реализации.

Java
Весна

В проекте добавьте следующую ссылку на azure-identity-extensions пакет. Эта библиотека содержит все сущности, необходимые для реализации подключений без пароля.
```
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity-extensions</artifactId>
    <version>1.0.0</version>
</dependency>
```
Включите плагин аутентификации Azure PostgreSQL в URL JDBC. Определите участки в вашем коде, которые в настоящее время создают java.sql.Connection для подключения к Azure Database для PostgreSQL. Обновите url и user в файле application.properties , чтобы соответствовать следующим значениям:
```
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
```
Замените $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME и две переменные $AZ_DATABASE_SERVER_NAME значением, которое вы настроили в начале этой статьи.

В проекте добавьте следующую ссылку на spring-cloud-azure-starter-jdbc-postgresql пакет. Эта библиотека содержит все сущности, необходимые для реализации подключений без пароля.
```
<dependency>
    <groupId>com.azure.spring</groupId>
    <artifactId>spring-cloud-azure-starter-jdbc-postgresql</artifactId>
</dependency>
```
Замечание

Дополнительные сведения об управлении версиями библиотеки Azure Spring Cloud с помощью счета за материалы (BOM) см. в разделе " Начало работы " руководства разработчика Azure Spring Cloud.
Обновите файл application.yaml или application.properties , как показано в следующем примере. Измените spring.datasource.username так, чтобы он соответствовал пользователю Microsoft Entra, удалите свойство spring.datasource.password и добавьте spring.datasource.azure.passwordless-enabled=true.
```
spring:
  datasource:
    url: jdbc:postgresql://${AZ_DATABASE_SERVER_NAME}.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require
    username: ${AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME}
    azure:
      passwordless-enabled: true
```

Локальное выполнение приложения

После внесения этих изменений в код запустите приложение локально. Новая конфигурация должна получить локальные учетные данные, если вы вошли в совместимую интегрированную среду разработки или средство командной строки, например Azure CLI, Visual Studio или IntelliJ. Роли, назначенные локальному пользователю разработки в Azure, позволяют приложению подключаться к службе Azure локально.

4) Настройка среды размещения Azure

После настройки приложения на использование беспарольных подключений, которое выполняется локально, тот же код может аутентифицироваться в службах Azure после его развертывания в Azure. Например, приложение, развернутое в экземпляре Службы приложений Azure с назначенным управляемым удостоверением, может подключиться к службе хранилища Azure.

В этом разделе описано, как разрешить приложению выполняться в среде размещения Azure без пароля:

Назначьте управляемое удостоверение для среды размещения Azure.
Назначьте роли управляемому удостоверению.

Замечание

Azure также предоставляет соединитель служб, который поможет вам подключить службу размещения к PostgreSQL. С помощью коннектора сервисов для настройки среды размещения можно опустить шаг назначения ролей управляемому удостоверению, так как коннектор сервисов сделает это за вас. В следующем разделе описывается, как настроить среду размещения Azure двумя способами: один через соединитель службы и другой путем настройки каждой среды размещения напрямую.

Это важно

Для команд соединителя служб требуется Azure CLI 2.41.0 или более поздней версии.

Назначьте управляемое удостоверение с помощью портала Azure

Ниже показано, как назначить управляемое удостоверение, назначаемое системой, для различных веб-хостинговых служб. Управляемое удостоверение может безопасно подключаться к другим службам Azure с помощью конфигураций приложений, настроенных ранее.

На странице основного обозрения экземпляра Azure App Service выберите Удостоверение в навигационной панели.
На вкладке «Назначаемая системой» убедитесь, что поле «Состояние» переведено в положение «включено». Назначенное системой удостоверение управляется Azure внутренне и обрабатывает административные задачи. Сведения и идентификаторы личности никогда не раскрываются в вашем коде.

Вы также можете назначить управляемое удостоверение в среде хостинга Azure с помощью Azure CLI.

Управляемую идентичность можно назначить экземпляру службы приложений Azure с помощью команды az webapp identity assign, как показано в примере ниже.

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

Соединитель служб можно использовать для создания подключения между средой размещения вычислений Azure и целевой службой с помощью Azure CLI. Соединитель служб в настоящее время поддерживает следующие вычислительные службы:

Служба приложений Azure
Azure Spring Apps
Приложения контейнеров Azure

Сначала установите расширение Service Connector для входа в Azure CLI без пароля:

az extension add --name serviceconnector-passwordless --upgrade

Если вы используете службу приложений Azure, используйте az webapp connection команду, как показано в следующем примере:

az webapp connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Если вы используете Azure Spring Apps, используйте the az spring connection команду, как показано в следующем примере:

az spring connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --service <service-name> \
    --app <service-instance-name> \
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Если вы используете приложения контейнеров Azure, используйте az containerapp connection команду, как показано в следующем примере:

az containerapp connection create postgres-flexible \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Управляемую идентичность можно назначить экземпляру Azure Container Apps с помощью команды az containerapp identity assign, как показано в следующем примере.

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

Управляемое удостоверение можно назначить экземпляру Azure Spring Apps, как показано в следующем примере:

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

Вы можете назначить управляемое удостоверение виртуальной машине с помощью команды az vm identity assign, как показано в следующем примере:

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

Вы можете назначить управляемую личность экземпляру Службы Kubernetes Azure (AKS) с помощью команды az aks update, как показано в примере:

export AZ_MI_OBJECT_ID=$(az aks update \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <AKS-cluster-name> \
    --enable-managed-identity \
    --query identityProfile.kubeletidentity.objectId \
    --output tsv)

Назначить роли управляемому удостоверению

Затем предоставьте разрешения управляемому удостоверению, назначенному для доступа к экземпляру PostgreSQL.

Соединитель служб
Azure CLI

Если вы подключили службы с помощью соединителя служб, команды предыдущего шага уже назначили роль, поэтому вы можете пропустить этот шаг.

Следующие шаги показывают, как создать пользователя Microsoft Entra для управляемого идентификатора и предоставить ей все разрешения для базы данных $AZ_DATABASE_NAME. Имя базы данных $AZ_DATABASE_NAME можно изменить в соответствии с вашими потребностями.

Сначала создайте скрипт SQL с именем create_ad_user_mi.sql для создания пользователя, отличного от администратора. Добавьте следующее содержимое и сохраните его локально:

export AZ_POSTGRESQL_AD_MI_USERNAME=$(az ad sp show \
    --id $AZ_MI_OBJECT_ID \
    --query displayName \
    --output tsv)

cat << EOF > create_ad_user_mi.sql
select * from pgaadauth_create_principal_with_oid('$AZ_POSTGRESQL_AD_MI_USERNAME', '$AZ_MI_OBJECT_ID', 'service', false, false);
EOF

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_mi.sql

Теперь используйте следующую команду, чтобы удалить временный файл скрипта SQL:

rm create_ad_user_mi.sql

Тестирование приложения

Перед развертыванием приложения в среде размещения необходимо внести еще одно изменение в код, так как приложение будет подключаться к PostgreSQL с помощью пользователя, созданного для управляемого удостоверения.

Java
Весна

Обновите код, чтобы использовать пользователя, созданного для управляемого удостоверения:

Замечание

Если вы использовали команду Соединителя служб, пропустите этот шаг.

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

Обновите файл application.yaml или application.properties . Смените spring.datasource.username на пользователя, созданного для управляемого удостоверения.

spring:
  datasource:
    url: jdbc:postgresql://${AZ_DATABASE_SERVER_NAME}.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require
    username: ${AZ_POSTGRESQL_AD_MI_USERNAME}
    azure:
      passwordless-enabled: true

Если вы использовали команду Соединителя служб, удалите свойства spring.datasource.url и spring.datasource.username. Необходимо добавить только следующий параметр:

spring:
  datasource:
    azure:
      passwordless-enabled: true

После внесения этих изменений в код можно создать и повторно развернуть приложение. Затем перейдите к размещённому приложению в вашем браузере. Приложение должно успешно подключиться к базе данных PostgreSQL. Помните, что для распространения назначений ролей через среду Azure может потребоваться несколько минут. Ваше приложение теперь настроено для работы как локально, так и в производственной среде, позволяя разработчикам не управлять секретами в самом приложении.

Дальнейшие шаги

Из этого руководства вы узнали, как перенести приложение в бессерверные подключения.

Дополнительные сведения о концепциях, описанных в этой статье, см. в следующих ресурсах:

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-19

Поделиться через

Перевод приложения на использование подключений без паролей с базой данных Azure для PostgreSQL

Сравнение параметров проверки подлинности

Аутентификация Microsoft Entra

Проверка подлинности PostgreSQL

Знакомство с бессерверными подключениями

Перенос существующего приложения на использование бессерверных подключений

0) Подготовка рабочей среды

1) Настройка базы данных Azure для PostgreSQL

1.1) Включение проверки подлинности на основе идентификатора Microsoft Entra

2) Настройка базы данных Azure для PostgreSQL для локальной разработки

2.1) Настройка правила брандмауэра для локального IP-адреса

2.2) Создание пользователя, отличного от администратора PostgreSQL, и предоставление разрешения

3) Войдите в систему и мигрируйте код приложения для использования подключений без пароля

Локальное выполнение приложения

4) Настройка среды размещения Azure

Назначьте управляемое удостоверение с помощью портала Azure

Назначить роли управляемому удостоверению

Тестирование приложения

Дальнейшие шаги

Обратная связь

Дополнительные ресурсы