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

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

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

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

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

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

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

Diagram showing thousands for role assignments.

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

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

Diagram showing one role assignment and a condition.

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

  @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]
 )
)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги