Рекомендации по обеспечению безопасности условий назначения ролей Azure в Хранилище BLOB-объектов Azure
Чтобы полностью защитить ресурсы с помощью управления доступом на основе атрибутов Azure (Azure ABAC), необходимо также защитить атрибуты, используемые в условиях назначения ролей Azure. Например, если условие основано на пути к файлу, следует помнить, что доступ может быть скомпрометирован, если у субъекта есть неограниченное разрешение на изменение путей к файлам.
В этой статье рассматриваются вопросы безопасности, которые следует учитывать при определении условий назначения ролей.
Внимание
Управление доступом на основе атрибутов Azure (Azure ABAC) общедоступен для управления доступом к Хранилище BLOB-объектов Azure, Azure Data Lake Storage 2-го поколения и очередям Azure с помощью request, resourceenvironmentа principal также атрибутов в уровнях производительности учетной записи хранения уровня "Стандартный" и "Премиум". В настоящее время атрибут ресурса метаданных контейнера и большой двоичный объект списка включают атрибут запроса в предварительной версии. Полные сведения о состоянии функции ABAC для служба хранилища Azure см. в разделе "Состояние функций условий" в служба хранилища Azure.
Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Использование других механизмов авторизации
Условия назначения ролей оцениваются только при использовании Azure RBAC для авторизации. Эти условия можно обойти, если вы разрешите доступ с помощью альтернативных методов авторизации:
- авторизация на основе общих ключей;
- подписанный URL-адрес учетной записи (SAS);
- SAS службы.
Аналогичным образом условия не оцениваются при предоставлении доступа с помощью списков управления доступом (ACL) в учетных записях хранения с иерархическим пространством имен (HNS).
Вы можете запретить авторизацию на основе общих ключей, SAS уровня учетной записи и SAS уровня службы, отключив авторизацию на основе общих ключей для своей учетной записи хранения. Так как SAS делегирования пользователя зависит от Azure RBAC, при использовании этого метода авторизации оцениваются условия назначения ролей.
Защита атрибутов службы хранилища, используемых в условиях
Путь к большому двоичному объекту
Если вы используете путь к большому двоичному объекту в качестве значения атрибута @Resource для условия, то следует также запретить пользователям переименование этого большого двоичного объекта для получения доступа к файлу при использовании учетных записей с иерархическим пространством имен. Например, если вы хотите создать условие на основе пути к большому двоичному объекту, необходимо также ограничить доступ пользователя к следующим действиям.
| Действие | Description |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
Это действие позволяет клиентам переименовывать файлы с помощью API создания пути. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Это действие разрешает доступ к различным операциям с файловой системы и путями. |
Теги индекса BLOB-объектов
Теги индекса BLOB-объектов используются в качестве атрибутов со свободной формой записи для условий в службе хранилища. Если вы разрабатываете какие-либо условия доступа на основе этих тегов, необходимо также защитить сами теги. В частности, действие DataAction Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write позволяет пользователям изменять теги в объекте хранилища. Это действие можно ограничить, чтобы запретить пользователям оперировать ключом или значением тега для получения несанкционированного доступа к объектам.
Кроме того, если теги индекса BLOB-объектов используются в условиях, данные могут быть уязвимы, если данные и связанные теги индекса обновляются в отдельных операциях. Можно использовать условия @Request для операций записи больших двоичных объектов, чтобы в операции обновления также были заданы и теги индекса. Такой подход поможет защитить данные от мгновенной записи в службу хранилища.
Теги в скопированных больших двоичных объектах
По умолчанию теги индекса BLOB-объектов не копируются из исходного большого двоичного объекта в место назначения при использовании API копирования BLOB-объектов или любого из его вариантов. Чтобы сохранить область доступа для большого двоичного объекта после копирования, необходимо также скопировать его теги.
Теги в моментальных снимках
Теги моментальных снимков BLOB-объектов не могут быть изменены. Поэтому перед созданием моментального снимка необходимо обновить теги в большом двоичном объекте. При изменении тегов в базовом большом двоичном объекте теги на моментальном снимке продолжают иметь предыдущее значение.
Если тег базового большого двоичного объекта изменится после создания моментального снимка, то области доступа для базового большого двоичного объекта и моментального снимка могут отличаться.
Теги в версиях больших двоичных объектов
Теги индексов больших двоичных объектов не копируются при создании версии большого двоичного объекта с помощью API добавления BLOB-объектов, добавления списка блоков или копирования BLOB-объектов. Можно указать теги в заголовке для этих API.
Теги можно задать отдельно для текущего базового большого двоичного объекта и для каждой его версии. При изменении тегов в базовом большом двоичном объекте теги предыдущих версий не обновляются. Если вы хотите изменить область доступа для большого двоичного объекта и всех его версий с помощью тегов, необходимо обновить теги в каждой версии.
Ограничения запросов и фильтрации для версий и моментальных снимков
При использовании тегов для запроса и фильтрации больших двоичных объектов в контейнере в ответ включаются только базовые BLOB-объекты. Версии или моментальные снимки больших двоичных объектов с запрошенными ключами и значениями в ответ не добавляются.
Роли и разрешения
Если вы используете условия назначения ролей для встроенных ролей Azure, следует внимательно изучить все разрешения, предоставляемые ролью субъекту.
Наследуемые назначения ролей
Назначения ролей можно настроить для группы управления, подписки, группы ресурсов, учетной записи хранения или контейнера. Настроенные назначения наследуются на каждом уровне в указанном порядке. Azure RBAC — это аддитивная модель, поэтому действующие разрешения являются сочетанием назначений ролей на каждом уровне. Если субъекту предоставлено одно и то же разрешение несколькими назначениями ролей, то доступ к операции, использующей это разрешение, оценивается и предоставляется отдельно для каждого назначения на каждом уровне.
Так как условия реализуются как условия для назначений ролей, любое безусловное назначение ролей позволяет пользователям обойти условие. Предположим, вы назначаете пользователю роль участника данных BLOB-объектов хранилища для учетной записи хранения и подписки, но добавляете условие назначения только для учетной записи хранения. Результатом является то, что пользователь имеет неограниченный доступ к учетной записи хранения через назначение роли на уровне подписки.
Таким образом, необходимо последовательно применять условия для всех назначений ролей в иерархии ресурсов.
Другие вопросы
Операции с условием, записывающие данные в большие двоичные объекты
Многие операции, которые записывают большие двоичные объекты, должны иметь разрешение Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write или Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Встроенные роли, такие как владелец данных BLOB-объектов хранилища и участник данных BLOB-объектов хранилища, предоставляют оба разрешения субъекту безопасности.
При определении условия назначения ролей для этих ролей следует использовать одинаковые условия для обоих разрешений, чтобы обеспечить согласованные ограничения доступа для операций записи.
Поведение при копировании большого двоичного объекта и копировании большого двоичного объекта из URL-адреса
При операциях копирования большого двоичного объекта и копирования большого двоичного объекта из URL-адресов условия @Request, использующие путь к большому двоичному объекту как атрибут в действии Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write и его подоперациях, оцениваются только для целевого большого двоичного объекта.
Для исходного большого двоичного объекта оцениваются условия @Resource в действии Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read.