Авторизация доступа к blob-объектам с помощью идентификатора Microsoft Entra
служба хранилища Azure поддерживает использование идентификатора Microsoft Entra для авторизации запросов к данным BLOB-объектов. С помощью идентификатора Microsoft Entra можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем, группой или субъектом-службой приложений. Субъект безопасности проходит проверку подлинности с помощью идентификатора Microsoft Entra для возврата маркера OAuth 2.0. Затем маркер можно использовать для авторизации запроса к службе BLOB-объектов.
Авторизация с помощью идентификатора Microsoft Entra обеспечивает более высокую безопасность и простоту использования при авторизации общего ключа. Корпорация Майкрософт рекомендует использовать авторизацию Microsoft Entra с приложениями BLOB-объектов, если это возможно, чтобы обеспечить доступ с минимальными необходимыми привилегиями.
Авторизация с помощью идентификатора Microsoft Entra доступна для всех учетных записей хранения BLOB-объектов общего назначения и больших двоичных объектов во всех общедоступных регионах и национальных облаках. Только учетные записи хранения, созданные с помощью модели развертывания Azure Resource Manager, поддерживают авторизацию Microsoft Entra.
Хранилище BLOB-объектов также поддерживает создание подписанных URL-адресов с учетными данными Microsoft Entra. Дополнительные сведения см. в статье Предоставление ограниченного доступа к данным с помощью подписанных URL-адресов.
Общие сведения об идентификаторе Microsoft Entra для больших двоичных объектов
Если субъект безопасности (пользователь, группа или приложение) пытается получить доступ к ресурсу БОЛЬШОго двоичного объекта, запрос должен быть авторизован, если он не является большим двоичным объектом, доступным для анонимного доступа. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом:
Вначале удостоверение участника безопасности проходит аутентификацию, которая возвращает токен OAuth 2.0.
Для этапа аутентификации требуется, чтобы приложение запросило маркер доступа OAuth 2.0 во время выполнения. Если приложение работает в сущности Azure, такой как виртуальная машина Azure, масштабируемый набор виртуальных машин или приложение "Функции Azure", оно может использовать управляемое удостоверение для доступа к BLOB-объектам.
Затем маркер передается как часть запроса в службу 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, можно использовать одну из следующих клиентских библиотек для получения токена 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>.blob.core.windows.net |
| Azure для государственных организаций | https://<account-name>.blob.core.usgovcloudapi.net |
| Azure China 21Vianet | https://<account-name>.blob.core.chinacloudapi.cn |
Вы также можете указать идентификатор ресурса, который применяется к любой учетной записи хранения, как показано в следующей таблице. Этот идентификатор ресурса одинаков для всех общедоступных и национальных облаков и используется для получения маркера для авторизации запросов к любой учетной записи хранения.
| Облако | ИД ресурса |
|---|---|
| Глобальная служба Azure Azure для государственных организаций Azure China 21Vianet |
https://storage.azure.com/ |
Назначение ролей 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 (предварительная версия).
Примечание.
При создании учетной записи служба хранилища Azure разрешения на доступ к данным с помощью идентификатора Microsoft Entra не назначаются автоматически. Необходимо явно назначить роль Azure для доступа к служба хранилища BLOB-объектов. Вы можете назначить ее на уровне подписки, группы ресурсов, учетной записи хранения, контейнера.
Область ресурса
Прежде чем назначить роль RBAC Azure субъекту безопасности, определите для него область доступа. Рекомендуется всегда предоставлять максимально узкие области. Роли RBAC Azure, определенные в более широкой области, наследуются охватываемыми ресурсами.
Вы можете ограничить доступ к ресурсам BLOB-объектов Azure на следующих уровнях, начиная с самой узкой области:
- Отдельный контейнер. На этом область назначение роли применяется ко всем blob-объектам в контейнере, а также к свойствам и метаданным контейнера.
- Учетная запись хранения. В этой области назначение ролей применяется ко всем контейнерам и их BLOB-объектам.
- Группа ресурсов. В этой области назначение ролей применяется ко всем контейнерам, а также ко всем учетным записям хранения в группе ресурсов.
- Подписка. В этой области назначение ролей применяется ко всем контейнерам во всех учетных записях хранения во всех группах ресурсов в подписке.
- Группа управления. В этой области назначение ролей применяется ко всем контейнерам во всех учетных записях хранения во всех группах ресурсов во всех подписках в группе управления.
Дополнительные сведения об области для назначения ролей Azure RBAC см. в статье Сведения об области действия для Azure RBAC.
Встроенные роли Azure для BLOB-объектов
Azure RBAC предоставляет несколько встроенных ролей для авторизации доступа к данным BLOB-объектов с помощью идентификатора Microsoft Entra и OAuth. Некоторые примеры ролей, которые предоставляют разрешения для ресурсов данных в хранилище Azure, включают:
- Владелец данных BLOB-объектов хранилища. Предоставляет права владельца и позволяет управлять доступом POSIX для Azure Data Lake Storage 2-го поколения. Дополнительные сведения см. в статье Контроль доступа в Azure Data Lake Storage 2-го поколения.
- Участник для данных BLOB-объектов хранилища. Предоставляет разрешения (чтение, запись и удаление) к ресурсам хранилища BLOB-объектов.
- Модуль чтения данных BLOB-объектов хранилища. Предоставляет разрешения только для чтения к ресурсам хранилища BLOB-объектов.
- Представитель BLOB-объектов хранилища. Получение ключа делегирования пользователя, который можно использовать для создания подписи общего доступа, которую ставят при помощи учетных данных Microsoft Entra для контейнера или большого двоичного объекта.
Сведения о назначении встроенной роли Azure субъекту безопасности см. в статье Назначение роли Azure для доступа к данным BLOB-объектов. Чтобы узнать, как составить список ролей RBAC Azure и их разрешений, см. Список определений ролей Azure.
Дополнительные сведения о том, как встроенные роли определяются для службы хранилища Azure, см. в статье, посвященной обзору определений ролей. Дополнительные сведения о создании настраиваемых ролей Azure см. в разделе Настраиваемые роли Azure.
Только роли, явно определенные для доступа к данным, позволяют субъекту безопасности получать доступ к данным BLOB-объекта. Встроенные роли, такие как владелец, участник и участник служба хранилища учетной записи, позволяют субъекту безопасности управлять учетной записью хранения, но не предоставлять доступ к данным BLOB-объектов в этой учетной записи с помощью идентификатора Microsoft Entra. Однако, если роль включает Microsoft.Storage/storageAccounts/listKeys/action, то пользователь, которому назначена данная роль, может получить доступ к данным в учетной записи хранения с помощью авторизации общего ключа при помощи ключей доступа к учетной записи. Дополнительные сведения см. в разделе Выбор способа авторизации доступа к данным BLOB-объектов на портале Azure.
Подробные сведения о встроенных ролях Azure для службы хранилища Azure, как для служб данных, так и для службы управления, см. в разделе Хранилище статьи Встроенные роли Azure. Кроме того, сведения о различных типах ролей, которые предоставляют разрешения в Azure, см. в ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки.
Важно!
Назначение ролей Azure может занимать до 30 минут.
Разрешения доступа к операциям с данными
Дополнительные сведения о разрешениях, необходимых для вызова конкретных операций службы BLOB-объектов, см. в разделе Разрешения на вызов операций с данными BLOB-объектов.
Доступ к данным с помощью учетной записи Microsoft Entra
Доступ к данным больших двоичных объектов с помощью портал Azure, PowerShell или Azure CLI можно авторизовать с помощью учетной записи Microsoft Entra пользователя или с помощью ключей доступа к учетной записи (авторизация общего ключа).
Внимание
Авторизация с помощью общего ключа не рекомендуется, так как она может быть менее безопасной. Чтобы обеспечить оптимальную безопасность, отключите авторизацию через общий ключ для учетной записи хранения, как описано в разделе "Запрет авторизации общего ключа" для учетной записи служба хранилища Azure.
Использование ключей доступа и строка подключения должно быть ограничено первоначальным подтверждением концепции приложений или прототипов разработки, которые не обращаются к рабочим или конфиденциальным данным. В противном случае классы проверки подлинности на основе маркеров, доступные в пакете SDK Azure, всегда должны быть предпочтительнее при проверке подлинности в ресурсах Azure.
Корпорация Майкрософт рекомендует клиентам использовать идентификатор Microsoft Entra или подписанный URL-адрес (SAS), чтобы авторизовать доступ к данным в служба хранилища Azure. Дополнительные сведения см. в разделе "Авторизация операций для доступа к данным".
Доступ к данным с портала Azure
Портал Azure могут использовать учетную запись Microsoft Entra или ключи доступа к учетным записям для доступа к данным BLOB-объектов в учетной записи хранения Azure. Схема авторизации, используемая порталом Azure, зависит от назначенных вам ролей Azure.
При попытке доступа к данным BLOB-объектов портал Azure сначала проверка, назначена ли роль Azure с помощью Microsoft.служба хранилища/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.