Прочитать на английском

Поделиться через

Рекомендации по Azure RBAC

  • Статья

В этой статье описываются некоторые рекомендации по использованию управления доступом на основе ролей в Azure (Azure RBAC). Эти рекомендации основаны на нашем опыте работы с Azure RBAC и подобном опыте других клиентов.

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

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

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

На следующей схеме представлен рекомендуемый шаблон для использования Azure RBAC.

Azure RBAC and least privilege

Сведения о назначении ролей см. в статье Назначение ролей Azure с помощью портала Azure.

Ограничение количества владельцев подписки

У вас должно быть не более 3 владельцев подписки, чтобы снизить вероятность бреши в системе безопасности из-за компрометации владельца. Эту рекомендацию можно отслеживать в Microsoft Defender для облака. Другие рекомендации по идентификации и доступу в Defender для облака см. в руководстве по безопасности.

Ограничение назначений привилегированных ролей администратора

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

  • Удалите ненужные назначения привилегированных ролей.
  • Избегайте назначения привилегированной роли администратора, если вместо нее можно использовать роль функции задания.
  • Если необходимо назначить привилегированную роль администратора, используйте узкие область, например группу ресурсов или ресурс, а не более широкую область, например группу управления или подписку.
  • Если вы назначаете роль с разрешением на создание назначений ролей, попробуйте добавить условие для ограничения назначения роли. Дополнительные сведения см. в статье "Делегирование управления назначениями ролей Azure другим пользователям с условиями".

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

Использование microsoft Entra управление привилегированными пользователями

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

Дополнительные сведения см. в разделе "Что такое Microsoft Entra управление привилегированными пользователями?".

Назначение ролей группам, а не пользователям

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

Назначение ролей с помощью уникального идентификатора роли вместо имени роли

В некоторых случаях имя роли может измениться, например в следующих:

  • вы используете собственную настраиваемую роль и решили переименовать ее;
  • вы используете роль предварительного просмотра с указанием (Preview) в имени. После выпуска роли она будет переименована.

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

Дополнительные сведения см. в статье "Назначение роли с помощью уникального идентификатора роли" и Azure PowerShell и назначение роли с помощью уникального идентификатора роли и Azure CLI.

Избегайте использования дикой природы карта при создании пользовательских ролей

При создании пользовательских ролей можно использовать дикий символ карта (*) для определения разрешений. Рекомендуется указать Actions и DataActions явно вместо использования дикого карта (*) символа. Дополнительный доступ и разрешения, предоставленные в будущем Actions или DataActions может быть нежелательным поведением с помощью дикой природы карта. Дополнительные сведения см. в статье Настраиваемые роли Azure.

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