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

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

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

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

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

В сценариях, где используются совместные ключи доступа (SAS), корпорация Майкрософт рекомендует использовать пользовательские делегированные SAS. SAS делегирования пользователей защищены учетными данными Microsoft Entra вместо ключа учетной записи. Дополнительные сведения о подписанных URL-адресах см. в статье Предоставление ограниченного доступа к данным с помощью подписанных URL-адресов. Для примера создания и использования SAS делегирования пользователей с .NET см. статью "Создание SAS делегирования пользователей для blob с помощью .NET".

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

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

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

• Авторизация: токен передается как часть запроса к службе хранилища BLOB-объектов и используется этой службой для авторизации доступа к указанному ресурсу на основе разрешений, предоставленных субъекту безопасности.

Использование учетной записи 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 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".

При использовании MSAL для получения токена OAuth для доступа к Azure Storage необходимо указать идентификатор ресурса 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 см. в статье "Авторизация доступа к BLOB-объектам" с помощью условий назначения ролей Azure (предварительная версия). Дополнительные сведения о поддерживаемых условиях для операций с данными BLOB-объектов см. в статье "Действия и атрибуты для условий назначения ролей Azure" в службе хранилища Azure (предварительная версия).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по безопасности:

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

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

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

При попытке доступа к данным BLOB-объектов портал 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. После входа сеанс запускается под этими учетными данными.

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

На поддержку данной функции может повлиять включение протокола Data Lake Storage 2-го поколения, протокола сетевой файловой системы (NFS) 3.0 или протокола SFTP.

Рекомендации по авторизации доступа к BLOB-объектам

При реализации авторизации Microsoft Entra ID для хранилища BLOB-объектов следуйте приведенным ниже рекомендациям по обеспечению безопасности.

• Используйте управляемые удостоверения: для приложений, работающих в Azure (виртуальных машинах, службе приложений, функциях, AKS), всегда используйте управляемые удостоверения вместо субъектов-служб с сохраненными учетными данными.
• Реализуйте наименьшие привилегии: назначьте самую ограничивающую роль, которая соответствует требованиям. Используйте средство чтения данных BLOB-объектов хранилища для сценариев, доступных только для чтения, а не для более допустимых ролей.
• Правильно назначайте области: применяйте назначения ролей, если возможно, на уровне контейнера, а не на уровне учетной записи хранения или подписки.
• Использование Azure ABAC. Используйте условия управления доступом на основе атрибутов (ABAC) для точного контроля доступа, если необходимо ограничить доступ на основе атрибутов ресурсов, таких как имя контейнера, путь к BLOB-объектам или теги.
• Отключение авторизации общего ключа. После миграции на проверку подлинности идентификатора Microsoft Entra ID отключите авторизацию общего ключа на уровне учетной записи хранения, чтобы предотвратить несанкционированный доступ через ключи учетных записей.
• Используйте SAS делегирования пользователей: если требуется предоставить временный доступ, предпочитайте SAS делегирования пользователей, вместо SAS делегирования учетной записи или SAS службы, так как он защищен учетными данными Microsoft Entra.
• Мониторинг доступа. Включите диагностику журналирования и регулярно просматривайте журналы Azure Monitor для отслеживания доступа к BLOB-данным и выявления подозрительных действий.
• Применение условного доступа. Используйте политики условного доступа Microsoft Entra для применения дополнительных требований безопасности, таких как многофакторная проверка подлинности, соответствие устройств или управление доступом на основе расположения.