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

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

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

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

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

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

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

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

• Проверка подлинности пользователей в службах Azure в единообразном режиме.
• Управление политиками паролей и сменой паролей в одном месте.
• Несколько форм проверки подлинности, поддерживаемых идентификатором Microsoft Entra, что может устранить необходимость хранения паролей.
• Клиенты могут управлять разрешениями базы данных с помощью внешних (Microsoft Entra ID) групп.
• Используйте пользователей базы данных PostgreSQL с аутентификацией Microsoft Entra для аутентификации удостоверений на уровне базы данных.
• Поддержка проверки подлинности на основе маркеров для приложений, подключающихся к База данных 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 ID для База данных Azure для PostgreSQL, сначала назначьте пользователя-администратора Microsoft Entra. Только пользователь-администратор Microsoft Entra может создавать пользователей или включать их учетные записи для аутентификации на основе Microsoft Entra ID.

Чтобы настроить администратора 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".

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

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

Azure CLI

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

az login

PowerShell

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

Connect-AzAccount

Visual Studio

Нажмите кнопку входа в правом верхнем углу Visual Studio.

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

Visual Studio Code

Убедитесь, что у вас установлено расширение учетной записи Azure .

Чтобы открыть палитру команд, используйте сочетание клавиш CTRL+SHIFT+P . Выполните поиск в Azure: выполните команду входа и следуйте инструкциям по проверке подлинности. Убедитесь, что вы используете учетную запись Microsoft Entra, которой вы ранее назначили роль, из вашей учетной записи хранилища Blob.

IntelliJ

Дополнительные сведения см. в разделе "Установка набора средств Azure для IntelliJ " и инструкции по входу в Набор средств Azure для IntelliJ.

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

Java

1. В проекте добавьте следующую ссылку на azure-identity-extensions пакет. Эта библиотека содержит все сущности, необходимые для реализации подключений без пароля.

   <dependency>
       <groupId>com.azure</groupId>
       <artifactId>azure-identity-extensions</artifactId>
       <version>1.0.0</version>
   </dependency>
   

2. Включите плагин аутентификации 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
   

3. Замените $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME и две переменные $AZ_DATABASE_SERVER_NAME значением, которое вы настроили в начале этой статьи.

Весна

1. В проекте добавьте следующую ссылку на 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.

2. Обновите файл 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. Используя Service Connector для настройки вашей среды размещения, вы можете пропустить шаг назначения ролей управляемому удостоверению, так как Service Connector назначает их автоматически. В следующем разделе описывается, как настроить среду размещения Azure двумя способами: один через соединитель службы и другой путем настройки каждой среды размещения напрямую.

Это важно

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

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

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

Служба приложений

1. На странице основного обозрения экземпляра Служба приложений Azure выберите Удостоверение в навигационной панели.

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

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

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

Контейнерные приложения

1. На главной странице обзора вашего экземпляра службы "Контейнеры приложений Azure" выберите «Удостоверение» в области навигации.

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

   

Приложения Azure Spring

1. На главной странице обзора экземпляра Приложения Azure Spring выберите Identity в области навигации.

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

   

виртуальные машины

1. На главной странице обзора виртуальной машины выберите "Удостоверение" в области навигации.

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

   

AKS

Для кластера Службы Azure Kubernetes (AKS) требуется удостоверение для доступа к ресурсам Azure, таким как подсистемы балансировки нагрузки и управляемые диски. Это удостоверение может быть либо управляемым удостоверением, либо служебным принципалом. По умолчанию при создании кластера AKS 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
• Приложения контейнеров 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, используйте 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 с помощью команды 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

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

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)

AKS

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

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

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

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

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

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

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

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

• Авторизуйте доступ к данным объектов BLOB с помощью управляемых удостоверений для ресурсов Azure.
• Авторизация доступа к blob-объектам с помощью идентификатора Microsoft Entra