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

2025-05-06

Чтобы полностью защитить ресурсы с помощью управления доступом на основе атрибутов Azure (Azure ABAC), необходимо также защитить атрибуты , используемые в условиях назначения ролей Azure. Например, если условие основано на пути к файлу, следует постерегаться, что доступ может быть скомпрометирован, если у субъекта есть неограниченное разрешение на переименование пути к файлу.

В этой статье описываются вопросы безопасности, которые следует учитывать в условиях назначения ролей.

Это важно

Управление доступом на основе атрибутов Azure (Azure ABAC) общедоступно для управления доступом к хранилищу BLOB-объектов Azure, Azure Data Lake Storage 2-го поколения и очередям Azure с помощью request, resource, environment и principal атрибутов на стандартных и премиум уровнях производительности учетной записи хранилища. В настоящее время блоб списка включает атрибут запроса и атрибут запроса моментального снимка для иерархического пространства имен, которые находятся в предварительной версии. Полные сведения о состоянии функции ABAC для службы хранилища Azure см. в разделе «Состояние функций условий в хранилище Azure».

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

Использование других механизмов авторизации

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

Авторизация общего ключа
Маркер предоставления доступа к учетной записи (SAS)
Служба SAS.

Аналогичным образом условия не оцениваются при предоставлении доступа с помощью списков управления доступом (ACL) в учетных записях хранения с иерархическим пространством имен (HNS).

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

Защита атрибутов хранилища, используемых в условиях

Путь к Blob

При использовании пути блоба в качестве атрибута @Resource для условия, следует также запретить пользователям изменять имя блоба для получения доступа к файлу при использовании учетных записей с иерархическим пространством имен. Например, если вы хотите создать условие на основе пути blob, необходимо также ограничить доступ пользователя к следующим действиям:

Действие	Описание
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action`	Это действие позволяет клиентам переименовать файл с помощью API создания пути.
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action`	Это действие позволяет получить доступ к различным операциям файловой системы и пути.

Теги индекса для BLOB-объектов

Теги индекса BLOB-объектов используются в качестве атрибутов свободной формы для условий хранения. Если вы создаете условия доступа с помощью этих тегов, необходимо также защитить сами теги. В частности, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction позволяет пользователям изменять теги в объекте хранилища. Это действие можно ограничить, чтобы запретить пользователям управлять ключом тега или значением, чтобы получить доступ к несанкционированным объектам.

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

Теги для скопированных BLOB-объектов

По умолчанию теги индекса BLOB-объектов не копируются из исходного BLOB в место назначения при использовании API Copy Blob или любого из его вариантов. Чтобы сохранить доступ к блобу при копировании, необходимо также скопировать теги.

Теги моментальных снимков

Теги моментальных снимков BLOB-объектов не могут быть изменены. Поэтому перед созданием моментального снимка необходимо обновить теги на блобе. При изменении тегов в исходном BLOB, теги в его моментальном снимке продолжают иметь предыдущее значение.

Если тег базового большого двоичного объекта изменяется после создания моментального снимка, область доступа может отличаться для базового большого двоичного объекта и моментального снимка.

Теги в версиях BLOB-объектов

Теги индекса BLOB-объектов не копируются при создании версии большого двоичного объекта через Put Blob, Put Block List или Copy Blob APIs. Теги можно указать в заголовке для этих API.

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

Ограничения на запросы и фильтрацию для версий и моментальных снимков

При использовании тегов для запроса и фильтрации больших двоичных объектов в контейнере в ответ включаются только базовые BLOB-объекты. Версии BLOB-объектов или моментальные снимки с запрошенными ключами и значениями не включены.

Роли и разрешения

Если вы используете условия назначения встроенных ролей Azure, необходимо тщательно просмотреть все разрешения, предоставленные роли принципалу.

Наследуемые назначения ролей

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

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

Таким образом, необходимо последовательно применять условия для всех назначений ролей в иерархии ресурсов.

Другие вопросы

Операции условий, которые записывают большие двоичные объекты

Для многих операций записи больших двоичных объектов требуется разрешение Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write или Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Встроенные роли, такие как владелец данных BLOB-объектов хранилища и участник данных BLOB-объектов хранилища , предоставляют оба разрешения субъекту безопасности.

При определении условия назначения ролей для этих ролей следует использовать одинаковые условия для обоих разрешений, чтобы обеспечить согласованные ограничения доступа для операций записи.

Поведение для копирования BLOB-объектов и копирования BLOB-объектов из URL-адреса

Для операций копирования BLOB-объектов и копирования BLOB-объектов из URL-адреса условия, использующие путь к BLOB-объекту в качестве атрибута на @Request действии и ее подоперациях, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write оцениваются только для целевого BLOB-объекта.

Для условий исходного большого двоичного объекта @Resource вычисляются условия действия Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read .