Управление доступом на основе ролей Azure

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

Общие сведения о рекомендуемых методиках RBAC как части стратегии идентификации и безопасности см. в разделе Рекомендации по безопасному управлению удостоверениями и доступом в Azure.

Общие сведения об управлении доступом на основе ролей в Azure

Используя управление доступом на основе ролей Azure, вы можете разделить обязанности в команде и предоставить только достаточный доступ для определенных пользователей Microsoft Entra, групп, субъектов-служб или управляемых удостоверений для выполнения своих заданий. Вместо того чтобы предоставить всем неограниченный доступ к подписке или ресурсам Azure, можно ограничить разрешения для каждого набора ресурсов.

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

Подробные инструкции по назначению конкретных ролей пользователям и группам и назначению ролей для областей см. в разделе Добавление или удаление назначенных ролей Azure на портале Microsoft Azure.

При планировании стратегии управления доступом используйте модель доступа с минимальными привилегиями, которая предоставляет пользователям только разрешения, необходимые для выполнения их работы. На схеме ниже показан рекомендуемый шаблон использования RBAC Azure в рамках этого подхода.

Примечание.

Чем более конкретные или подробные разрешения вы определяете, тем выше вероятность того, что элементы управления доступом станут сложными и ими будет труднее управлять. Это особенно актуально с ростом облачной инфраструктуры. Избегайте использования разрешений для конкретных ресурсов. Вместо этого используйте группы управления для управления доступом в масштабах предприятия и группы ресурсов для управления доступом в подписках. Следует также избегать использования разрешений для конкретных пользователей. Вместо этого назначьте доступ к группам в идентификаторе Microsoft Entra.

Использование встроенных ролей Azure

Azure предоставляет множество встроенных определений ролей с тремя основными ролями для обеспечения доступа:

• Владелец может управлять всем, в том числе доступом к ресурсам.
• Участник может управлять всем, кроме доступа к ресурсам.
• Читатель может просматривать все элементы, но не может вносить изменения.

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

• Администратор виртуальных машин. Пользователи, которым назначена эта роль, могут просматривать виртуальные машины и выполнять вход на портал в качестве administrator.
• Участник виртуальных машин. Пользователи, которым назначена эта роль, могут управлять виртуальными машинами, не имеют доступа к ним, а также к виртуальным сетям или учетным записям хранения, к которым эти машины подключены.
• Пользователь виртуальных машин. Пользователи, которым назначена эта роль, могут просматривать виртуальные машины на портале и выполнять вход в качестве обычного пользователя.

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

Полный список доступных встроенных ролей см. в статье Встроенные роли в Azure.

Применение пользовательских ролей

Хотя роли, встроенные в Azure, поддерживают разные сценарии управления доступом, они могут не соответствовать всем требованиям вашей организации или команды. Например, если у вас есть одна группа пользователей, отвечающая за управление виртуальными машинами и ресурсами Базы данных SQL Azure, вы можете создать настраиваемую роль для оптимизации управления необходимыми элементами управления доступом.

Документация по Azure RBAC содержит инструкции по созданию настраиваемых ролей, а также подробные сведения о том, как работают определения ролей.

Разделение обязанностей и ролей для крупных организаций

RBAC Azure позволяет организациям назначать разным командам различные задачи управления в больших облачных инфраструктурах. Он может позволить главным ИТ-командам контролировать основные функции доступа и безопасности, а также предоставляет разработчикам программного обеспечения и другим командам большой уровень контроля над конкретными рабочими нагрузками или группами ресурсов.

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

В приведенной ниже таблице показан общий шаблон для разделения ИТ-обязанностей на отдельные настраиваемые роли.

Групповой	Имя стандартной роли	Обязанности
Операции безопасности	SecOps	Обеспечивает общий контроль безопасности. Устанавливает и применяет политику безопасности, такую как шифрование при хранении. Управляет ключами шифрования. Управляет правилами брандмауэра.
Сетевые операции	NetOps	Управляет конфигурацией сети и операциями в виртуальных сетях, такими как маршруты и пиринги.
Системные операции	SysOps	Указывает параметры инфраструктуры вычислений и хранения, а также обеспечивает поддержку развернутых ресурсов.
Разработка, тестирование и эксплуатация	DevOps	Создает и развертывает функции рабочей нагрузки и приложений. Использует функции и приложения для соответствия соглашению об уровне обслуживания и другим стандартам качества.

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

Например, в звездообразной топологии сети с несколькими подписками у вас может быть общий набор определений ролей для центра и всех периферийных зон рабочей нагрузки. Роль NetOps подписки центра может быть назначена сотрудникам основного ИТ-отдела организации, которые отвечают за обслуживание сетей для общих служб, используемых всеми рабочими нагрузками. Роль NetOps подписки периферийной зоны рабочей нагрузки затем может быть назначена членам этой конкретной группы рабочей нагрузки, что позволяет им настраивать сети в рамках этой подписки для обеспечения лучшей поддержки их требований к рабочей нагрузке. Одно и то же определение роли используется для обеих ролей, но назначения на основе области гарантируют, что пользователи имеют только тот уровень доступа, который им необходим для выполнения своих заданий.