Безопасное подключение к службам и базам данных Azure из службы приложение Azure

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

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

Способ подключения	Когда использовать
Подключение с помощью удостоверения приложения	* Вы хотите полностью удалить учетные данные, ключи или секреты из приложения. * Нижестоящей службе Azure поддерживается проверка подлинности Microsoft Entra, например Microsoft Graph. * Подчиненный ресурс не должен знать текущего вошедшего пользователя или не требует детализированной авторизации текущего вошедшего пользователя.
Подключение от имени вошедшего пользователя	* Приложение должно получить доступ к нижестоящему ресурсу от имени вошедшего пользователя. * Нижестоящей службе Azure поддерживается проверка подлинности Microsoft Entra, например Microsoft Graph. * Подчиненный ресурс должен выполнять детализированную авторизацию текущего вошедшего пользователя.
Подключение с помощью секретов	* Для нижестоящего ресурса требуются секреты подключения. * Приложение подключается к службам, отличным от Azure, например локальному серверу базы данных. * Нижестоящей службе Azure пока не поддерживается проверка подлинности Microsoft Entra.

Подключение с помощью удостоверения приложения

Если приложение уже использует один набор учетных данных для доступа к нижестоящей службе Azure, вы можете быстро преобразовать подключение для использования удостоверения приложения. Управляемое удостоверение из идентификатора Microsoft Entra позволяет Служба приложений доступ к ресурсам без секретов и управлять доступом с помощью управления доступом на основе ролей (RBAC). Управляемое удостоверение может подключаться к любому ресурсу Azure, который поддерживает проверку подлинности Microsoft Entra, и проверка подлинности выполняется с короткими маркерами.

На следующем изображении показана Служба приложений, которая подключается к другим службам Azure:

• А: пользователь посещает веб-сайт службы приложений Azure.
• B. Безопасное подключение из Служба приложений к другой службе Azure с помощью управляемого удостоверения.
• C. Безопасное подключение из Служба приложений к Microsoft Graph с помощью управляемого удостоверения.

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

• Учебник. Подключение к базам данных Azure из Службы приложений без секретов с помощью управляемого удостоверения
• Учебник. Подключение к Базе данных SQL из Службы приложений .NET без секретов с помощью управляемого удостоверения
• Руководство. Подключение к Postgre База данных SQL из Java Tomcat Служба приложений без секретов с помощью управляемого удостоверения

Подключение от имени вошедшего пользователя

Возможно, приложению потребуется подключиться к подчиненной службе от имени пользователя, выполнившего вход. Служба приложений позволяет легко проходить проверку подлинности пользователей с помощью наиболее распространенных поставщиков удостоверений (см. сведения о проверке подлинности и авторизации в службе приложение Azure и Функции Azure). Если вы используете поставщик Майкрософт (проверка подлинности Microsoft Entra), вы можете передавать пользователя, выполнившего вход, в любую нижестоящей службе. Например:

• Запустите запрос базы данных, возвращающий конфиденциальные данные, которые пользователь, выполнившего вход, разрешено читать.
• Получение персональных данных или выполнение действий в качестве пользователя, выполнившего вход в Microsoft Graph.

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

Ниже описываются наиболее типичные сценарии применения:

• Подключение к Microsoft Graph от имени пользователя
• Подключение к базе данных SQL от имени пользователя
• Подключение к другому приложению Служба приложений от имени пользователя
• Поток пользователя, выполнившего вход, через несколько уровней подчиненных служб

Подключение с помощью секретов

В приложении рекомендуется использовать два способа использования секретов: использование секретов, хранящихся в Azure Key Vault или секретах в параметрах приложения Служба приложений.

Использование секретов из Key Vault

Azure Key Vault можно использовать для безопасного хранения секретов и ключей, мониторинга доступа и использования секретов, а также упрощения администрирования секретов приложений. Если нижестоящей службе не поддерживается проверка подлинности Microsoft Entra или требуется строка подключения или ключ, используйте Key Vault для хранения секретов и подключения приложения к Key Vault с помощью управляемого удостоверения и получения секретов. Приложение может получить доступ к секретам хранилища ключей в качестве ссылок на Key Vault в параметрах приложения.

Преимущества управляемых удостоверений, интегрированных с Key Vault, включают:

• Доступ к секрету хранилища ключей ограничен приложением.
• Участники приложений, такие как администраторы, могут иметь полный контроль над ресурсами Служба приложений и в то же время не имеют доступа к секретам хранилища ключей.
• Если код приложения уже обращается к секретам подключения с использованием параметров приложения, никакое изменение ему не требуется.
• Key Vault обеспечивает мониторинг и аудит доступа к секретам.
• Смена секретов хранилища ключей не требует изменений в Служба приложений.

На следующем рисунке показано, Служба приложений подключение к Key Vault с помощью управляемого удостоверения, а затем доступ к службе Azure с помощью секретов, хранящихся в Key Vault:

Использование секретов в параметрах приложения

Для приложений, подключающихся к службам с помощью секретов (таких как имена пользователей, пароли и ключи API), Служба приложений безопасно хранить их в параметрах приложения. Эти секреты внедряются в код приложения в качестве переменных среды при запуске приложения. Параметры приложения всегда шифруются при хранении. Для более расширенного управления секретами, таких как смена секретов, политики доступа и журнал аудита, попробуйте использовать Key Vault.

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

• Руководство. Развертывание приложения ASP.NET Core и База данных SQL Azure в службе приложение Azure
• Руководство. Развертывание приложения ASP.NET в Azure с помощью База данных SQL Azure
• Руководство по развертыванию приложения PHP, MySQL и Redis в службе приложение Azure
• Развертывание веб-приложения Node.js + MongoDB в Azure
• Развертывание веб-приложения Python (Django или Flask) с помощью PostgreSQL в Azure
• Руководство. Создание веб-приложения Tomcat с помощью службы приложение Azure в Linux и MySQL
• Руководство. Создание веб-приложения Java Spring Boot с помощью службы приложение Azure в Linux и Azure Cosmos DB

Следующие шаги

Вы узнаете, как выполнять следующие задачи:

• Безопасно храните секреты в Azure Key Vault.
• Доступ к ресурсам с помощью управляемого удостоверения.
• Храните секреты с помощью параметров приложения Служба приложений.
• Подключитесь к Microsoft Graph от имени пользователя.
• Подключитесь к базе данных SQL от имени пользователя.
• Подключитесь к другому приложению Служба приложений от имени пользователя.
• Подключитесь к другому приложению Служба приложений, а затем нижестоящей службе в качестве пользователя.