Проверка подлинности приложения с помощью идентификатора Microsoft Entra для доступа к ресурсам Центров событий

2025-04-01

Microsoft Azure предоставляет интегрированное управление доступом для ресурсов и приложений на основе идентификатора Microsoft Entra. Ключевым преимуществом использования Microsoft Entra ID с Azure Event Hubs заключается в том, что вам больше не нужно хранить учетные данные в коде. Вместо этого можно запросить маркер доступа OAuth 2.0 из платформы удостоверений Майкрософт. Имя ресурса для запроса токена — https://eventhubs.azure.net/, и оно одинаково для всех облаков и арендаторов (для клиентов Kafka ресурс для запроса токена — https://<namespace>.servicebus.windows.net). Microsoft Entra проверяет подлинность субъекта безопасности (пользователя, группы, субъекта-службы или управляемого удостоверения), выполняющего приложение. Если проверка подлинности выполнена успешно, Microsoft Entra ID возвращает токен доступа приложению, и приложение может использовать этот токен доступа для авторизации запросов к ресурсам Azure Event Hubs.

Когда роль назначается субъекту безопасности Microsoft Entra, Azure предоставляет доступ к этим ресурсам для этого субъекта безопасности. Доступ может быть ограничен уровнем подписки, группой ресурсов, пространством имен концентраторов событий или любым ресурсом под ним. Безопасность Microsoft Entra может назначать роли пользователю, группе, субъекту-службе приложений или управляемой идентичности для ресурсов Azure.

Примечание.

Определение роли представляет собой коллекцию разрешений. Управление доступом на основе ролей в Azure (Azure RBAC) управляет применением этих разрешений с помощью назначения ролей. Назначение ролей состоит из трех элементов: субъект безопасности, определение роли и область действия. Для получения дополнительной информации см. раздел Понимание различных ролей.

Встроенные роли для концентраторов событий Azure

Azure предоставляет следующие встроенные роли Azure для авторизации доступа к данным Центров событий с помощью идентификатора Microsoft Entra и OAuth:

Владелец данных концентраторов событий Azure. Используйте эту роль, чтобы предоставить полный доступ к ресурсам концентраторов событий.
Отправитель данных в Azure Event Hubs: субъект безопасности, которому назначена эта роль, может отправлять события в конкретный концентратор событий или во все концентраторы событий в области имен.
Диспетчер данных для Azure Event Hubs: учетная запись безопасности, назначенная на эту роль, может получать события из определенного центра событий или всех центров событий в пространстве имен.

Встроенные роли реестра схем см. в разделе Роли реестра схем.

Внимание

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

Аутентификация из приложения

Ключевым преимуществом использования идентификатора Microsoft Entra с центрами событий является то, что учетные данные больше не должны храниться в коде. Вместо этого вы можете запросить токен доступа OAuth 2.0 у платформы идентификации Майкрософт. Microsoft Entra выполняет проверку подлинности субъекта безопасности (пользователя, группы или субъекта-службы). Если проверка подлинности выполнена успешно, идентификатор Microsoft Entra возвращает маркер доступа приложению, а приложение может использовать маркер доступа для авторизации запросов на Центры событий Azure.

В следующих разделах показано, как настроить собственное приложение или веб-приложение для аутентификации с помощью платформы удостоверений Майкрософт 2.0. Дополнительные сведения о платформе удостоверений Майкрософт 2.0 см. в разделе Обзор Платформы удостоверений Майкрософт (v2.0).

Общие сведения о потоке предоставления кода OAuth 2.0 см. в разделе "Авторизация доступа к веб-приложениям Microsoft Entra" с помощью потока предоставления кода OAuth 2.0.

Регистрация приложения в клиенте Microsoft Entra

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

При регистрации клиентского приложения вы предоставляете сведения о приложении. Затем идентификатор Microsoft Entra предоставляет идентификатор клиента (также называемый идентификатором приложения), который можно использовать для связывания приложения с средой выполнения Microsoft Entra. Дополнительные сведения об идентификаторе клиента см. в разделе «Объекты приложения и субъекта-службы в Microsoft Entra ID».

Примечание.

Если вы зарегистрируете свое приложение как собственное приложение, вы можете указать любой допустимый URI для URI перенаправления. Для собственных приложений это значение не обязательно должно быть действительным URL-адресом. Для веб-приложений URI перенаправления должен быть допустимым URI, так как он указывает URL-адрес, на который предоставляются токены.

После регистрации приложения вы увидите идентификатор приложения (клиента) в разделе "Параметры":

Создание секрета клиента

Приложению требуется секрет клиента для подтверждения своей личности при запросе токена. Выполните действия, описанные в разделе "Добавление секрета клиента" для создания секрета клиента для приложения в идентификаторе Microsoft Entra.

Назначение ролей Azure с помощью портала Azure

Назначьте субъекту-службе приложения одну из ролей Центров событий в нужной области (пространство имен Центров событий, группа ресурсов, подписка). Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.

Определив роль и ее область действия, вы можете протестировать данный алгоритм действий с помощью примеров в данном расположении GitHub. Дополнительные сведения об управлении доступом к ресурсам Azure с помощью управления доступом на основе ролей Azure (RBAC) и портала Azure см. в этой статье.

Клиентские библиотеки для приобретения токенов

После регистрации приложения и предоставления ему разрешений на отправку и получение данных в Центры событий Azure можно добавить код в приложение для проверки подлинности субъекта безопасности и получения маркера OAuth 2.0. Для аутентификации и получения токена можно использовать либо одну из библиотек аутентификации платформы идентификации Майкрософт, либо другую библиотеку с открытым исходным кодом, которая поддерживает OpenID или Connect 1.0. Приложение может использовать маркер доступа для авторизации запросов к концентраторам событий Azure.

Для сценариев, в которых поддерживается получение токенов, смотрите раздел «Сценарии» в репозитории Microsoft Authentication Library (MSAL) для .NET на GitHub.

Примеры

Примеры RBAC с использованием устаревшего пакета .NET Microsoft.Azure.EventHubs. Мы работаем над созданием новой версии этого примера с помощью последнего пакета Azure.Messaging.EventHubs. Просмотрите уже преобразованное Управляемое Удостоверение.
Пример RBAC с использованием устаревшего пакета Java com.microsoft.azure.eventhubs. Вы можете использовать руководство по миграции для переноса этого примера для использования нового пакета (com.azure.messaging.eventhubs). Дополнительные сведения об использовании нового пакета см. здесь.

Дополнительные сведения о Azure RBAC см. в статье Что такое управление доступом на основе ролей (Azure RBAC)?
Сведения о назначении ролей Azure и управлении ими с помощью Azure PowerShell, Azure CLI или REST API см. в следующих статьях:

См. следующие статьи по этой теме:

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