Перенос приложения на использование бессерверных подключений с базой данных 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).
Проверка подлинности 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 для 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 выберите Удостоверение в области навигации.
На вкладке "Назначаемая системой" убедитесь, что поле "Состояние" включено. Назначенное системой удостоверение управляется 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

Сначала установите расширение без пароля соединителя службы для 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)

Вы можете назначить управляемое удостоверение экземпляру Службы Azure Kubernetes (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

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

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

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

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

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