Выберите и настройте подходящий метод для доступа к очередям Azure

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

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

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

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

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

• Проверка подлинности: удостоверение субъекта безопасности проходит проверку подлинности и возвращается маркер OAuth 2.0. Для этапа аутентификации требуется, чтобы приложение запросило маркер доступа OAuth 2.0 во время выполнения. Если приложение выполняется из сущности Azure, например виртуальной машины Azure, масштабируемого набора виртуальных машин или приложения Функций Azure, оно может использовать управляемое удостоверение для доступа к данным очереди. Использование управляемых удостоверений — это рекомендуемый подход , так как он устраняет необходимость управления учетными данными.
• Авторизация: маркер передается в рамках запроса в службу очередей и используется службой для авторизации доступа к указанному ресурсу. Шаг авторизации требует, чтобы одна или несколько ролей Azure RBAC были назначены субъекту безопасности, выполняющим запрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Участник данных очереди хранилища: предоставляет разрешения на чтение, запись и удаление очередей в Azure. Используйте эту роль для приложений или пользователей, которым требуется полный доступ к сообщениям очереди.
• Средство чтения данных очереди хранилища: предоставляет разрешения только для чтения очередям Azure. Используйте эту роль для приложений или пользователей, которые должны просматривать только сообщения очереди без прав на изменение.
• Обработчик сообщений очереди хранилища: предоставляет возможность просмотра, извлечения и удаления разрешений для сообщений в очередях службы хранилища Azure. Используйте эту роль для рабочих приложений, обрабатывающих и удаляющих сообщения из очередей.
• Отправитель сообщений данных очереди хранилища: предоставляет разрешения на добавление сообщений в очередях Azure Storage. Используйте эту роль для приложений, которым нужно только ставить сообщения в очередь, без их чтения или удаления.

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

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

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

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

• Избегайте авторизации общего ключа: авторизация с общим ключом не рекомендуется, так как она предоставляет полный доступ к учетной записи хранения и не поддерживает расширенные функции безопасности, такие как условный доступ. Чтобы обеспечить оптимальную безопасность, отключите авторизацию посредством Shared Key для учетной записи хранения Azure, как описано в разделе "Запрет авторизации с использованием Shared Key для учетной записи хранения Azure".
• Ограничение использования ключа доступа. Использование ключей доступа и строк подключения должно быть ограничено первоначальным подтверждением основных приложений или прототипов разработки, которые не обращаются к рабочим или конфиденциальным данным. Для рабочих нагрузок всегда используйте классы проверки подлинности на основе маркеров, доступные в пакете SDK Azure.
• Предпочитать идентификатор Microsoft Entra: корпорация Майкрософт рекомендует клиентам использовать идентификатор Microsoft Entra для наиболее безопасного метода авторизации. Если требуется делегирование, используйте SAS делегирования пользователей для хранилища BLOB-объектов, защищенного учетными данными Microsoft Entra.

Доступ к данным с портала 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, предоставляющая доступ к ресурсам управления учетными записями хранения.

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

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

• Выбор способа авторизации доступа к данным очереди с помощью Azure CLI
• Выполнение команд PowerShell с учетными данными Microsoft Entra для доступа к данным очереди

Рекомендации по авторизации доступа к очереди

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

• Используйте управляемые удостоверения: для приложений, работающих в Azure (виртуальных машинах, службе приложений, Функциях Azure, экземплярах контейнеров, AKS), всегда используйте управляемые удостоверения вместо субъектов-служб с сохраненными учетными данными. Это устраняет затраты на управление учетными данными и повышает безопасность.
• Реализуйте наименьшие привилегии: назначьте самую ограничивающую роль, которая соответствует требованиям:
  • Используйте Читатель данных очереди хранения для приложений, которым необходимо просматривать только сообщения.
  • Используйте Storage Queue Data Message Sender для приложений, которые только добавляют сообщения в очередь.
  • Используйте Storage Queue Data Message Processor для рабочих приложений, которые обрабатывают и удаляют сообщения.
  • Использование участника данных очереди хранилища только в том случае, если требуется полный доступ
• Назначения областей соответствующим образом: применяйте назначения ролей на уровне очереди, если это возможно, а не на уровне учетной записи хранения или подписки. Это ограничивает доступ только к определенным очередям, которые нужны пользователям или приложениям.
• Отключить авторизацию с общим ключом. После перехода на проверку подлинности Идентификатора Microsoft Entra рекомендуется отключить авторизацию общего ключа на уровне учетной записи хранения, чтобы предотвратить несанкционированный доступ с помощью ключей учетных записей.
• Используйте пользовательские роли для точного управления. Если встроенные роли не соответствуют вашим требованиям, создайте пользовательские роли Azure RBAC только с необходимыми разрешениями.
• Мониторинг шаблонов доступа. Включите ведение журнала диагностики и регулярно просматривайте журналы Azure Monitor для отслеживания доступа к очередям и выявления подозрительных или несанкционированных действий.
• Применение политик условного доступа. Используйте политики условного доступа Microsoft Entra для применения дополнительных требований безопасности, таких как многофакторная проверка подлинности, соответствие устройств или ограничения на основе расположения.
• Реализуйте логику повторных попыток: приложения на основе очередей должны реализовать соответствующую логику повторных попыток с экспоненциальной паузой для обработки транзиторных сбоев аутентификации или авторизации.
• Регулярные проверки доступа. Периодически выполняйте аудит назначений ролей, чтобы пользователи и приложения по-прежнему требовали назначенных разрешений и удаляли ненужный доступ.
• Отдельные среды: используйте разные учетные записи хранения и назначения ролей для разработки, тестирования и рабочих сред, чтобы свести к минимуму риск случайного воздействия или изменения данных.