Авторизация доступа к очередям с помощью идентификатора Microsoft Entra
служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным очереди. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем, группой или субъектом-службой приложений. Субъект безопасности проходит проверку подлинности с помощью идентификатора Microsoft Entra для возврата маркера OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе очередей.
Авторизация с помощью идентификатора Microsoft Entra обеспечивает более высокую безопасность и простоту использования при авторизации общего ключа. Корпорация Майкрософт рекомендует использовать авторизацию Microsoft Entra с приложениями очереди, если это возможно, чтобы обеспечить доступ с минимальными необходимыми привилегиями.
Авторизация с помощью идентификатора Microsoft Entra доступна для всех учетных записей хранения общего назначения во всех общедоступных регионах и национальных облаках. Только учетные записи хранения, созданные с помощью модели развертывания Azure Resource Manager, поддерживают авторизацию Microsoft Entra.
Обзор идентификатора Microsoft Entra для очередей
Если субъект безопасности (пользователь, группа или приложение) пытается получить доступ к ресурсу очереди, запрос должен быть авторизован, если только это очередь, доступная для анонимного доступа. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом:
Вначале удостоверение участника безопасности проходит аутентификацию, которая возвращает токен OAuth 2.0.
Для этапа аутентификации требуется, чтобы приложение запросило маркер доступа OAuth 2.0 во время выполнения. Если приложение выполняется из сущности Azure, например виртуальной машины Azure, масштабируемого набора виртуальных машин или приложения Функции Azure, оно может использовать управляемое удостоверение для доступа к данным очереди.
Затем маркер передается как часть запроса в службу очередей и используется этой службой для авторизации доступа к указанному ресурсу.
На этапе авторизации субъекту безопасности, выполняющему запрос, необходимо назначить одну или несколько ролей 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 рекомендуется для большинства сценариев разработки.
- Библиотека проверки подлинности Майкрософт (MSAL) может подходить для определенных сложных сценариев.
Клиентская библиотека удостоверений Azure
Клиентская библиотека удостоверений Azure упрощает процесс получения маркера доступа OAuth 2.0 для авторизации с помощью идентификатора Microsoft Entra с помощью пакета SDK Azure. Последние версии клиентских библиотек службы хранилища Azure для .NET, Java, Python, JavaScript и Go интегрируются с библиотеками удостоверений Azure для каждого из этих языков, чтобы предоставлять простые и безопасные способы получения маркера доступа для авторизации запросов Cлужбы хранилища Azure.
Преимущество клиентских библиотек удостоверений Azure заключается в том, что они позволяют использовать один и тот же код для получения маркера доступа независимо от того, выполняется приложение в среде разработки или в Azure. Клиентская библиотека удостоверений Azure возвращает маркер доступа для субъекта безопасности. Когда ваш код работает в Azure, основным лицом системы безопасности может быть управляемое удостоверение для ресурсов Azure, основной службы, пользователь или группа. В среде разработки клиентская библиотека предоставляет маркер доступа для пользователя или директора службы в целях тестирования.
Маркер доступа, возвращенный клиентской библиотекой удостоверений Azure, инкапсулируется в учетные данные маркера. Затем учетные данные маркера можно использовать для получения объекта клиента-службы для выполнения авторизованной операции со Службой хранилища Azure. Простой способ получить маркер доступа и учетные данные маркера — воспользоваться классом DefaultAzureCredential, который предоставляется клиентской библиотекой удостоверений Azure. DefaultAzureCredential пытается получить учетные данные токена, последовательно пытаясь выполнить несколько различных типов учетных данных. DefaultAzureCredential работает как в среде разработки, так и в Azure.
В следующей таблице приведены дополнительные сведения для авторизации доступа к данным в различных сценариях:
Библиотека проверки подлинности Майкрософт (MSAL)
Хотя корпорация Майкрософт рекомендует использовать клиентская библиотека удостоверений Azure, если это возможно, библиотека MSAL может использоваться в определенных сложных сценариях. Дополнительные сведения см. в разделе "Сведения о MSAL".
При использовании MSAL для получения маркера OAuth для доступа к служба хранилища Azure необходимо указать идентификатор ресурса 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 не назначаются автоматически. Для доступа к очередям служба хранилища необходимо явно назначить роль Azure. Вы можете назначить ее на уровне подписки, группы ресурсов, учетной записи хранения или очереди.
Область ресурса
Прежде чем назначить роль RBAC Azure субъекту безопасности, определите для него область доступа. Рекомендуется всегда предоставлять максимально узкие области. Роли RBAC Azure, определенные в более широкой области, наследуются охватываемыми ресурсами.
Вы можете ограничить доступ к ресурсам очередей Azure на следующих уровнях, начиная с самой узкой области:
- Отдельная очередь. На этом область назначение роли применяется к сообщениям в очереди, а также к свойствам и метаданным очереди.
- Учетная запись хранения. В этой области назначение ролей применяется ко всем очередям и их сообщениям.
- Группа ресурсов. В этой области назначение ролей применяется ко всем очередям во всех учетных записях хранения в группе ресурсов.
- Подписка. В этой области назначение ролей применяется ко всем очередям во всех учетных записях хранения во всех группах ресурсов в подписке.
- Группа управления. В этой области назначение ролей применяется ко всем очередям во всех учетных записях хранения во всех группах ресурсов во всех подписках в группе управления.
Дополнительные сведения об области для назначения ролей Azure RBAC см. в статье Сведения об области действия для Azure RBAC.
Встроенные роли Azure для очередей
Azure RBAC предоставляет несколько встроенных ролей для авторизации доступа к данным очереди с помощью идентификатора Microsoft Entra и OAuth. Некоторые примеры ролей, которые предоставляют разрешения для ресурсов данных в хранилище Azure, включают:
- Участник для данных очереди хранилища. Предоставляет разрешения (чтение, запись и удаление) к очередям Azure.
- Модуль чтения данных очереди хранилища. Предоставляет разрешения только для чтения к очередям Azure.
- Обработчик сообщений данных в очереди хранилища. Предоставляет разрешения (просмотр, получение и удаление) к сообщениям в очередях службы хранилища Azure.
- Отправитель сообщений данных в очередь хранилища. Предоставляет разрешения на добавление к сообщениям в очередях службы хранилища Azure.
Сведения о назначении встроенной роли Azure субъекту безопасности см. в статье Назначение роли Azure для получения доступа к данным очереди. Чтобы узнать, как составить список ролей RBAC Azure и их разрешений, см. Список определений ролей Azure.
Дополнительные сведения о том, как встроенные роли определяются для службы хранилища Azure, см. в статье, посвященной обзору определений ролей. Дополнительные сведения о создании настраиваемых ролей Azure см. в разделе Настраиваемые роли Azure.
Только роли, явно определенные для доступа к данным, позволяют субъекту безопасности получать доступ к данным очереди. Встроенные роли, такие как владелец, участник и служба хранилища участник учетной записи, позволяют субъекту безопасности управлять учетной записью хранения, но не предоставлять доступ к данным очереди в этой учетной записи с помощью идентификатора Microsoft Entra. Однако, если роль включает Microsoft.Storage/storageAccounts/listKeys/action, то пользователь, которому назначена данная роль, может получить доступ к данным в учетной записи хранения с помощью авторизации общего ключа при помощи ключей доступа к учетной записи. Дополнительные сведения см. в разделе Выбор способа авторизации доступа к данным очереди на портале Azure.
Подробные сведения о встроенных ролях Azure для службы хранилища Azure, как для служб данных, так и для службы управления, см. в разделе Хранилище статьи Встроенные роли Azure. Кроме того, сведения о различных типах ролей, которые предоставляют разрешения в Azure, см. в ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки.
Важно!
Назначение ролей Azure может занимать до 30 минут.
Разрешения доступа к операциям с данными
Дополнительные сведения о разрешениях, необходимых для вызова конкретных операций службы очередей, см. в разделе о разрешениях на вызов операций с данными.
Доступ к данным с помощью учетной записи Microsoft Entra
Доступ к данным очереди с помощью портал Azure, PowerShell или Azure CLI можно авторизовать с помощью учетной записи Microsoft Entra пользователя или с помощью ключей доступа к учетной записи (авторизация общего ключа).
Внимание
Авторизация с помощью общего ключа не рекомендуется, так как она может быть менее безопасной. Чтобы обеспечить оптимальную безопасность, отключите авторизацию через общий ключ для учетной записи хранения, как описано в разделе "Запрет авторизации общего ключа" для учетной записи служба хранилища Azure.
Использование ключей доступа и строка подключения должно быть ограничено первоначальным подтверждением концепции приложений или прототипов разработки, которые не обращаются к рабочим или конфиденциальным данным. В противном случае классы проверки подлинности на основе маркеров, доступные в пакете SDK Azure, всегда должны быть предпочтительнее при проверке подлинности в ресурсах Azure.
Корпорация Майкрософт рекомендует клиентам использовать идентификатор Microsoft Entra или подписанный URL-адрес (SAS), чтобы авторизовать доступ к данным в служба хранилища Azure. Дополнительные сведения см. в разделе "Авторизация операций для доступа к данным".
Доступ к данным с портала Azure
Портал Azure могут использовать учетную запись Microsoft Entra или ключи доступа учетной записи для доступа к данным очереди в учетной записи хранения Azure. Схема авторизации, используемая порталом Azure, зависит от назначенных вам ролей Azure.
При попытке получить доступ к данным очереди портал Azure сначала проверка, назначена ли роль Azure с помощью Microsoft.служба хранилища/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. После входа в систему сеанс выполняется под этими учетными данными. Дополнительные сведения см. в следующих статьях:
- Выбор способа авторизации доступа к данным очереди с помощью Azure CLI
- Выполнение команд PowerShell с учетными данными Microsoft Entra для доступа к данным очереди