Масштабирование управления назначениями ролей Azure с помощью условий и настраиваемых атрибутов безопасности

Управление доступом на основе ролей Azure (Azure RBAC) имеет ограничение назначений ролей для каждой подписки. Если вам нужно создать сотни или даже тысячи назначений ролей Azure, вы можете столкнуться с этим ограничением. Управление сотнями или тысячами заданий ролей может быть непростой задачей. В зависимости от вашего сценария вы можете уменьшить количество назначений ролей и упростить управление доступом.

В этой статье описывается решение для масштабирования управления назначениями ролей с помощью условий управления доступом на основе атрибутов Azure (Azure ABAC) и настраиваемых атрибутов безопасности Microsoft Entra для субъектов.

Пример сценария

Рассмотрим компанию Contoso с тысячами клиентов, которые хотят настроить следующую конфигурацию:

  • Распределяйте данные клиентов между 128 учетными записями хранения по соображениям безопасности и производительности.
  • Добавьте 2000 контейнеров в каждую учетную запись хранения, где есть контейнер для каждого клиента.
  • Представьте каждого клиента в виде уникального идентификатора-службы Microsoft Entra.
  • Разрешить каждому клиенту получать доступ к объектам в контейнере, но не к другим контейнерам.

В данной конфигурации могут потребоваться 256 000 назначений роли владельца данных BLOB-объектов хранилища в подписке, что значительно превышает ограничение назначений ролей. Наличие этих многих назначений ролей было бы трудно, если не невозможно, поддерживать.

Диаграмма, показывающая тысячи назначений ролей.

Пример решения

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

Схема, показывающая одно назначение ролей и условие.

Вот выражение в условии, которое делает это решение работоспособным:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

Полное условие будет похоже на следующее. Список действий можно настроить только на необходимые действия .

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

Почему это решение используется?

Существует несколько механизмов управления доступом, которые можно использовать для предоставления доступа к ресурсам плоскости данных.

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

Как и ключи доступа, маркеры SAS не имеют связывания с удостоверением, но истекают регулярно. Отсутствие привязки удостоверений представляет те же риски безопасности, что и ключи доступа. Необходимо управлять сроком действия, чтобы клиенты не столкнулись с ошибками. Маркеры SAS требуют дополнительного кода для управления и ежедневной работы и могут значительно нагружать команду DevOps.

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

Ниже приведены некоторые преимущества этого решения:

  • Централизованное управление доступом
  • Проще поддерживать
  • Не зависит от ключей доступа или маркеров SAS
  • Не требуется управлять доступом к каждому объекту
  • Может потенциально улучшить состояние безопасности

Можно ли использовать это решение?

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

Шаг 1. Определение соответствия предварительным требованиям

Чтобы использовать это решение, необходимо:

Шаг 2. Определение атрибутов, которые можно использовать в условии

Существует несколько атрибутов, которые можно использовать в вашем условии, например следующие:

  • Имя контейнера
  • Путь к Blob
  • Теги индекса BLOB-объектов [ключи]
  • Теги индекса BLOB [значения в ключе]

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

Для получения дополнительной информации см. раздел "Формат и синтаксис условий назначения ролей Azure" и раздел "Что такое настраиваемые атрибуты безопасности в Microsoft Entra ID".

Шаг 3. Создание условия на более высоком уровне.

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

Дальнейшие действия

  • Last updated on