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

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

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

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

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

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

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

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

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

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

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

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

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

Использование Microsoft Entra для управления привилегированными идентификациями

Чтобы защитить привилегированные учетные записи от вредоносных кибератак, вы можете использовать Microsoft Entra Privileged Identity Management (PIM) для снижения времени воздействия привилегий и повышения видимости их использования с помощью отчетов и оповещений. PIM помогает защитить привилегированные учетные записи, предоставляя доступ по принципу just-in-time к Microsoft Entra ID и ресурсам Azure. Доступ может быть ограничен временем, после чего привилегии отозваны автоматически.

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

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

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

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

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

• Вы используете собственную пользовательскую роль и решаете изменить имя.
• Вы используете роль, в названии которой указано (предварительный). Когда роль освобождается, её переименовывают.

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

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

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

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

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

• Устранение неполадок Azure RBAC