Авторизация доступа к BLOB-объектам с помощью Microsoft Entra ID

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

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

Общие сведения об идентификаторе Microsoft Entra для больших двоичных объектов

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

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

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

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

   На этапе авторизации субъекту безопасности, выполняющему запрос, необходимо назначить одну или несколько ролей 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 ID, используйте одну из следующих клиентских библиотек для получения токена OAuth 2.0:

• Клиентская библиотека удостоверений Azure рекомендуется для большинства сценариев разработки.
• Microsoft Authentication Library (MSAL) может подходить для определенных сложных сценариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сведения о том, как назначить роли Azure для доступа к объектам BLOB, см. в статье Назначение роли Azure для доступа к данным BLOB.

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

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

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

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

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

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

Встроенные роли Azure для BLOB-объектов

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

• Владелец данных BLOB-объектов хранилища: используется для установки владения и управления доступом POSIX для Azure Data Lake Storage. Дополнительные сведения см. в статье "Управление доступом" в Azure Data Lake Storage.
• Участник данных хранилища BLOB: используйте для предоставления разрешений на чтение, запись и удаление ресурсов хранилища BLOB.
• Storage Blob Data Reader: Используйте для предоставления доступа только для чтения к ресурсам хранилища BLOB-объектов.
• Storage Blob Delegator. Получите ключ делегирования пользователя для использования при создании общей подписи доступа, подписанной с помощью учетных данных Microsoft Entra, для контейнера или двоичного объекта.

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

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

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

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

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

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

Задержки распространения назначения ролей для доступа к данным BLOB

При назначении ролей или удалении назначений ролей может потребоваться до 10 минут, чтобы изменения вступили в силу. Если вы назначаете роли на уровне группы управления, это может занять гораздо больше времени.

Встроенные роли можно назначать с действиями данных в области группы управления. Однако в редких сценариях может возникнуть значительная задержка (до 12 часов), прежде чем разрешения на действия данных эффективны для определенных типов ресурсов. В конце концов, разрешения применяются. Для встроенных ролей с операциями с данными, добавление или удаление назначений ролей в области управления группами не рекомендуется для сценариев, когда требуется своевременное введение в силу или отзыв разрешений, например, в системе управления привилегированными идентификаторами Microsoft Entra (PIM).

Если вы устанавливаете соответствующие разрешения на доступ к данным через Microsoft Entra ID и не можете получить доступ к данным, например, если вы получаете ошибку "AuthorizationPermissionMismatch", убедитесь, что прошло достаточно времени для того, чтобы изменения разрешений, внесенные в Microsoft Entra ID, были реплицированы. Кроме того, убедитесь, что у вас нет каких-либо запретных назначений, которые блокируют доступ. Дополнительные сведения см. в разделе Понимание отказов назначений Azure.

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

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

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

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

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

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

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

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

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

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

Поддержка функций

На поддержку данной функции может повлиять включение протокола Data Lake Storage 2-го поколения, протокола сетевой файловой системы (NFS) 3.0 или протокола SFTP. Если вы активировали любую из этих возможностей, см. Поддержка функций хранилища BLOB в учетных записях Azure, чтобы оценить её поддержку.

Авторизация операций с данными больших двоичных объектов с идентификатором Microsoft Entra поддерживается только для REST API версий 2017-11-09 и более поздних версий. Дополнительные сведения см. в разделе Управление версиями для служб хранилища Azure.

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

• Авторизация доступа к данным в службе хранилища Azure
• Назначение роли Azure для доступа к данным BLOB