Авторизация доступа к очередям с помощью идентификатора Microsoft Entra

Служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным очереди. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем, группой или субъектом-службой приложений. Принципал безопасности проходит проверку подлинности с помощью Microsoft Entra ID, чтобы вернуть токен OAuth 2.0. Затем токен можно использовать для авторизации запроса к службе очереди.

Авторизация с помощью идентификатора Microsoft Entra обеспечивает более высокую безопасность и простоту использования при авторизации общего ключа. Корпорация Майкрософт рекомендует использовать авторизацию Microsoft Entra с приложениями для обработки очередей по возможности, чтобы обеспечить доступ с минимально необходимыми привилегиями.

Авторизация с помощью идентификатора Microsoft Entra доступна для всех учетных записей хранения общего назначения во всех общедоступных регионах и национальных облаках. Только учетные записи хранения, созданные с помощью модели развертывания Azure Resource Manager, поддерживают авторизацию Microsoft Entra.

Обзор идентификатора Microsoft Entra для очередей

Если субъект безопасности (пользователь, группа или приложение) пытается получить доступ к ресурсу очереди, запрос должен быть авторизован, если только это очередь, доступная для анонимного доступа. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом:

  1. Вначале удостоверение участника безопасности проходит аутентификацию, которая возвращает токен OAuth 2.0.

    Для этапа аутентификации требуется, чтобы приложение запросило маркер доступа OAuth 2.0 во время выполнения. Если приложение выполняется из сущности Azure, например виртуальной машины Azure, масштабируемого набора виртуальных машин или приложения Функций Azure, оно может использовать управляемое удостоверение для доступа к данным очереди.

  2. Затем маркер передается в рамках запроса в службу очередей и используется службой для авторизации доступа к указанному ресурсу.

    Шаг авторизации требует, чтобы одна или несколько ролей Azure RBAC были назначены субъекту безопасности, выполняющим запрос. Дополнительные сведения см. в статье Назначение ролей Azure для прав доступа.

Использование учетной записи Microsoft Entra с порталом, PowerShell или Azure CLI

Сведения о доступе к данным на портале Azure с учетной записью Microsoft Entra см. на портале Azure. Сведения о вызове команд Azure PowerShell или Azure CLI с учетной записью Microsoft Entra см. в статье "Доступ к данным" из PowerShell или Azure CLI.

Использование идентификатора Microsoft Entra для авторизации доступа в коде приложения

Чтобы авторизовать доступ к службе хранилища Azure с помощью идентификатора Microsoft Entra, можно использовать одну из следующих клиентских библиотек для получения маркера OAuth 2.0:

Клиентская библиотека удостоверений Azure

Клиентская библиотека удостоверений Azure упрощает процесс получения токена доступа OAuth 2.0 для авторизации с Microsoft Entra ID через Azure SDK. Последние версии клиентских библиотек службы хранилища Azure для .NET, Java, Python, Java, JavaScript и Go интегрируются с библиотеками удостоверений Azure для каждого из этих языков, чтобы предоставить простые и безопасные средства для получения маркера доступа для авторизации запросов службы хранилища Azure.

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

Токен доступа, возвращенный клиентской библиотекой удостоверений Azure, инкапсулируется в учетные данные токена. Затем можно использовать учетные данные токена для получения объекта клиента службы для выполнения авторизованных операций в службе хранилища Azure. Простой способ получить токен доступа и учетные данные токена — использовать класс DefaultAzureCredential, предоставляемый клиентской библиотекой Azure Identity. DefaultAzureCredential пытается получить токен учетных данных, последовательно проверяя несколько различных типов учетных данных. DefaultAzureCredential работает как в среде разработки, так и в Azure.

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

Язык .СЕТЬ Ява JavaScript Питон Иди
Обзор проверки подлинности с помощью идентификатора Microsoft Entra Проверка подлинности приложений .NET с помощью служб Azure Аутентификация Azure с помощью Java и Azure Identity Проверка подлинности приложений JavaScript в Azure с помощью пакета SDK Azure Проверка подлинности приложений Python в Azure с помощью пакета SDK Azure
Аутентификация с помощью учетных данных сервисов для разработчиков Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью субъектов-служб Аутентификация Azure с помощью служебного принципала Авторизация JS-приложений к службам Azure с помощью служебного принципала Аутентификация приложений Python в Azure-сервисах во время локальной разработки с помощью учетных записей служб Аутентификация Azure SDK для Go с помощью учетной записи службы
Проверка подлинности с помощью учетных записей разработчика или пользователей Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков Проверка подлинности Azure с учетными данными пользователя Аутентификация приложений JS в службах Azure с учетными записями разработки Проверка подлинности приложений Python в службах Azure во время локальной разработки с помощью учетных записей разработчиков Аутентификация в Azure с помощью Azure SDK для Go
Аутентификация приложений, размещенных в Azure Проверка подлинности размещенных в Azure приложений в ресурсах Azure с помощью пакета SDK Azure для .NET Проверка подлинности размещенных в Azure приложений Java Проверка подлинности размещенных в Azure приложений JavaScript в ресурсах Azure с помощью пакета SDK Azure для JavaScript Проверка подлинности размещенных в Azure приложений в ресурсах Azure с помощью пакета SDK Azure для Python Аутентификация с использованием Azure SDK для Go и управляемого удостоверения
Проверка подлинности из локальных приложений Аутентификация в ресурсах Azure из приложений .NET, размещенных локально Проверка подлинности локальных приложений JavaScript в ресурсах Azure Аутентификация к ресурсам Azure из приложений Python, размещённых локально
Общие сведения о клиентской библиотеке идентификации Библиотека клиентской идентификации Azure для .NET Клиентская библиотека идентификации Azure для Java Клиентская библиотека идентификации Azure для JavaScript Клиентская библиотека идентификации Azure для Python Клиентская библиотека идентификации Azure для Go

Библиотека проверки подлинности Microsoft (MSAL)

Хотя корпорация Майкрософт рекомендует при возможности использовать клиентскую библиотеку удостоверений Azure, библиотека MSAL может быть подходящей в определенных продвинутых сценариях. Дополнительные сведения см. в разделе "Сведения о MSAL".

При использовании MSAL для получения токена OAuth для доступа к Azure Storage необходимо указать идентификатор ресурса MICROSOFT ENTRA. Идентификатор ресурса Microsoft Entra указывает аудиторию, для которой можно использовать маркер, выданный для предоставления доступа к ресурсу Azure. В случае службы хранилища Azure идентификатор ресурса может быть конкретным для одной учетной записи хранения или может применяться к любой учетной записи хранения.

Если указать идентификатор ресурса, относящийся к одной учетной записи хранения и службе, идентификатор ресурса используется для получения маркера для авторизации запросов только к указанной учетной записи и службе. В следующей таблице перечислены значения, используемые для идентификатора ресурса, в зависимости от облака, с которым вы работаете. Замените <account-name> именем своей учетной записи хранения.

Облако ИД ресурса
Глобальная служба Azure https://<account-name>.queue.core.windows.net
Azure для государственных организаций https://<account-name>.queue.core.usgovcloudapi.net
Azure China 21Vianet https://<account-name>.queue.core.chinacloudapi.cn

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

Облако ИД ресурса
Глобальная служба Azure
Azure для государственных организаций
Azure China 21Vianet
 https://storage.azure.com/

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

Microsoft Entra разрешает доступ к защищенным ресурсам через Azure RBAC. Служба хранилища Azure определяет набор встроенных ролей RBAC, охватывающих общие наборы разрешений, используемых для доступа к данным очереди. Можно также определить пользовательские роли для доступа к данным очереди. Дополнительные сведения о назначении ролей Azure для доступа к очередям см. в статье "Назначение роли Azure для доступа к данным очереди".

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

В некоторых случаях может потребоваться включить детализированный доступ к ресурсам очереди или упростить управление разрешениями, когда есть большое количество назначений ролей для ресурса хранилища. Для настройки условий назначений ролей можно использовать управление доступом на основе атрибутов Azure (Azure ABAC). Вы можете использовать условия с настраиваемой ролью или выбрать встроенные роли. Дополнительные сведения о настройке условий для ресурсов хранилища Azure с помощью ABAC см. в статье "Авторизация доступа к очередям с помощью условий назначения ролей Azure". Дополнительные сведения о поддерживаемых условиях для выполнения операций с данными в очереди можно найти в разделе "Действия и атрибуты для условий назначения ролей Azure для очередей Azure".

Примечание.

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

Область ресурсов

Прежде чем назначить роль RBAC Azure участнику безопасности, определите область его доступа. Наилучшие практики предписывают всегда предоставлять максимально узкую область доступа. Роли RBAC Azure, определенные на более высоком уровне, наследуются подчиненными ресурсами.

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

  • Отдельная очередь. В этой области назначение роли применяется к сообщениям в очереди, а также к свойствам очереди и метаданным.
  • Аккаунт хранения. На этом уровне назначение роли распространяется на все очереди и их сообщения.
  • Группа ресурсов. В этой области назначение роли применяется ко всем очередям во всех учетных записях хранения в группе ресурсов.
  • Подписка. В этой области назначение роли применяется ко всем очередям во всех учетных записях хранения во всех группах ресурсов в подписке.
  • Группа управления. Назначение роли на этом уровне применяется ко всем очередям во всех учетных записях хранения, расположенных во всех группах ресурсов и подписках в соответствующей группе управления.

Дополнительные сведения об области для назначения ролей Azure RBAC см. в статье Сведения об области действия для Azure RBAC.

Встроенные роли Azure для очередей

Azure RBAC предоставляет несколько встроенных ролей для авторизации доступа к данным очереди с помощью идентификатора Microsoft Entra и OAuth. Ниже приведены некоторые примеры ролей, которые предоставляют разрешения на ресурсы данных в службе хранилища Azure:

Сведения о назначении встроенной роли Azure субъекту безопасности см. в статье "Назначение роли Azure для доступа к данным очереди". Чтобы узнать, как составить список ролей RBAC Azure и их разрешений, см. Список определений ролей Azure.

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

Только роли, явно определенные для доступа к данным, позволяют субъекту безопасности получать доступ к данным очереди. Встроенные роли, такие как владелец, участник и участник учетной записи хранения , позволяют субъекту безопасности управлять учетной записью хранения, но не предоставлять доступ к данным очереди в этой учетной записи с помощью идентификатора Microsoft Entra. Однако, если роль включает Microsoft.Storage/storageAccounts/listKeys/action, то пользователь, которому назначена данная роль, может получить доступ к данным в учетной записи хранения с помощью авторизации общего ключа при помощи ключей доступа к учетной записи. Дополнительные сведения см. в разделе Выбор способа авторизации доступа к данным очереди на портале Azure.

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

Это важно

Назначение ролей Azure может требовать до 30 минут на распространение.

Разрешения доступа к операциям с данными

Дополнительные сведения о разрешениях, необходимых для вызова определенных операций службы очередей, см. в разделе "Разрешения для вызова операций с данными".

Доступ к данным с помощью учетной записи Microsoft Entra

Доступ к данным очереди через портал Azure, PowerShell или Azure CLI можно авторизовать с помощью учетной записи Microsoft Entra пользователя или с помощью ключей доступа к учетной записи (авторизация общего ключа).

Осторожность

Авторизация с помощью общего ключа не рекомендуется, так как она может быть менее безопасной. Чтобы обеспечить оптимальную безопасность, отключите авторизацию посредством Shared Key для учетной записи хранения Azure, как описано в разделе "Запрет авторизации с использованием Shared Key для учетной записи хранения Azure".

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

Microsoft рекомендует клиентам использовать Microsoft Entra ID или общий ключ доступа (SAS), чтобы авторизовать доступ к данным в службе хранилища Azure. Дополнительные сведения см. в разделе "Авторизация операций для доступа к данным".

Доступ к данным с портала Azure

Портал Azure может использовать учетную запись Microsoft Entra или ключи доступа к учетным записям для доступа к данным очереди в учетной записи хранения Azure. Схема авторизации, используемая порталом Azure, зависит от назначенных вам ролей Azure.

При попытке доступа к данным очереди портал Azure сначала проверяет, назначена ли роль Azure с помощью Microsoft.Storage/storageAccounts/listkeys/action. Если вам назначена роль с этим действием, портал Azure будет использовать ключ учетной записи для доступа к данным очереди через авторизацию с общим ключом. Если вам не была назначена роль с этим действием, то портал Azure попытается получить доступ к данным через вашу учетную запись Microsoft Entra.

Чтобы получить доступ к данным очереди на портале Azure с помощью учетной записи Microsoft Entra, вам потребуются разрешения на доступ к данным очереди, а также необходимы разрешения для перехода по ресурсам учетной записи хранения на портале Azure. Встроенные роли, предоставляемые службой хранилища Azure, предоставляют доступ к ресурсам очереди, но не предоставляют разрешения ресурсам учетной записи хранения. По этой причине для доступа к порталу также требуется назначение роли Azure Resource Manager, например роли Читателя, охватывающей уровень учетной записи хранения или выше. Роль Читатель предоставляет наиболее ограниченные разрешения, однако можно использовать и другую роль Azure Resource Manager, которая предоставляет доступ к ресурсам управления учетными записями хранения. Дополнительные сведения о назначении разрешений пользователям для доступа к данным на портале Azure с учетной записью Microsoft Entra см. в статье "Назначение роли Azure для доступа к данным очереди".

Портал Azure указывает, какая схема авторизации используется при переходе к очереди. Дополнительные сведения о доступе к данным на портале см. в статье "Выбор авторизации доступа к данным очереди" на портале Azure.

Доступ к данным из PowerShell или Azure CLI

Azure CLI и PowerShell поддерживают вход с помощью учетных данных Microsoft Entra. После входа сеанс запускается под этими учетными данными. Дополнительные сведения см. в одной из следующих статей:

Дальнейшие действия

  • Last updated on