Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Права доступа и привилегии на основе групп — это хорошая практика. Работа с группами, а не отдельными пользователями упрощает обслуживание политик доступа, обеспечивает согласованное управление доступом в командах и снижает ошибки конфигурации. Назначение пользователей и удаление пользователей из соответствующих групп помогает сохранить текущие привилегии конкретного пользователя. Управление доступом на основе ролей Azure (Azure RBAC) обеспечивает точное управление доступом для ресурсов, организованных вокруг ролей пользователей.
Общие сведения о рекомендуемых методиках Azure RBAC в рамках стратегии идентификации и безопасности см. в рекомендациях по управлению удостоверениями Azure и управлению доступом.
Обзор управления доступом на основе ролей Azure
Используя управление доступом на основе ролей Azure, вы можете разделить обязанности в команде и предоставить только необходимый доступ для конкретных пользователей Microsoft Entra, групп, принципалов служб или управляемых удостоверений, чтобы они могли выполнять свои задачи. Вместо предоставления всем неограниченным доступом к подписке или ресурсам Azure можно ограничить разрешения для каждого набора ресурсов.
Определения ролей Azure описывают операции, которые разрешены или запрещены для пользователей или групп, назначенных этой ролью. Область роли указывает, к каким ресурсам применяются эти определенные разрешения. Области можно указать на нескольких уровнях: группу управления, подписку, группу ресурсов или ресурс. Области структурированы в родительско-дочерних отношениях.
Подробные инструкции по назначению пользователей и групп определенным ролям и назначению ролей областям см. в статье "Добавление или удаление назначений ролей Azure" с помощью портала Azure.
При планировании стратегии управления доступом используйте модель доступа с наименьшими привилегиями, которая предоставляет пользователям только разрешения, необходимые для выполнения своей работы. На следующей схеме показан рекомендуемый шаблон использования Azure RBAC с помощью этого подхода.
Примечание.
Чем более конкретные или подробные разрешения, тем более вероятно, что элементы управления доступом будут сложными и сложными для управления. Это особенно верно, так как ваши облачные ресурсы увеличиваются в объеме. Избегайте разрешений, относящихся к ресурсам. Вместо этого используйте группы управления для управления доступом на уровне предприятия и групп ресурсов для управления доступом в подписках. Не используйте персональные разрешения. Вместо этого назначьте доступ к группам в идентификаторе Microsoft Entra.
Использование встроенных ролей Azure
Azure предоставляет множество встроенных определений ролей с тремя основными ролями для предоставления доступа:
- Роль владельца может управлять всем, включая доступ к ресурсам.
- Роль участника может управлять всем, кроме доступа к ресурсам.
- Роль читателя может просматривать все, но не вносить никаких изменений.
Начиная с этих основных уровней доступа, дополнительные встроенные роли предоставляют более подробные элементы управления для доступа к определенным типам ресурсов или функциям Azure. Например, вы можете управлять доступом к виртуальным машинам с помощью следующих встроенных ролей:
-
Роль администратора виртуальных машин позволяет просматривать виртуальные машины на портале и входить в систему с правами
administrator. - Роль участника виртуальной машины может управлять виртуальными машинами, но не может получить к ним доступ или к виртуальной сети или учетной записи хранения, к которым они подключены.
- Роль входа пользователя виртуальной машины может просматривать виртуальные машины на портале и выполнять вход в качестве обычного пользователя.
Другой пример использования встроенных ролей для управления доступом к определенным функциям см. в обсуждении управления доступом к функциям отслеживания затрат в отслеживании затрат в бизнес-единицах, средах или проектах.
Полный список доступных встроенных ролей см. в статье о встроенных ролях Azure.
Использование пользовательских ролей
Хотя роли, встроенные в Azure, поддерживают широкий спектр сценариев управления доступом, они могут не соответствовать всем потребностям вашей организации или команды. Например, если у вас есть одна группа пользователей, ответственных за управление виртуальными машинами и ресурсами базы данных SQL Azure, может потребоваться создать пользовательскую роль для оптимизации управления необходимыми элементами управления доступом.
Документация по Azure RBAC содержит инструкции по созданию пользовательских ролей, а также сведения о работе определений ролей.
Разделение обязанностей и ролей для крупных организаций
Azure RBAC позволяет организациям назначать разные команды различным задачам управления в крупных облачных пространствах. Она позволяет центральным ИТ-командам управлять основными функциями доступа и безопасности, а также предоставлять разработчикам программного обеспечения и другим командам большие объемы контроля над конкретными рабочими нагрузками или группами ресурсов.
Большинство облачных сред также могут воспользоваться стратегией управления доступом, которая использует несколько ролей и подчеркивает разделение обязанностей между этими ролями. Этот подход требует, чтобы любое значительное изменение ресурсов или инфраструктуры предусматривало участие нескольких ролей, гарантируя, что более одного человека должны проверить и утвердить изменение. Это разделение обязанностей ограничивает способность одного человека получать доступ к конфиденциальным данным или вводить уязвимости без знаний других членов команды.
В следующей таблице показан общий шаблон разделения ИТ-обязанностей на отдельные пользовательские роли:
| Группа | Общее имя роли | Обязанности |
|---|---|---|
| Операции безопасности | SecOps | Обеспечивает общий надзор за безопасностью. Устанавливает и применяет политику безопасности, такую как шифрование данных в состоянии покоя. Управляет ключами шифрования. Управляет правилами брандмауэра. |
| Сетевые операции | NetOps | Управляет конфигурацией сети и операциями в виртуальных сетях, такими как маршруты и пиринги. |
| Операции с системами | SysOps | Задает параметры инфраструктуры вычислений и хранилища и поддерживает развернутые ресурсы. |
| Разработка, тестирование и операции | DevOps | Создает и развертывает функции и приложения рабочей нагрузки. Управляет функциями и приложениями для удовлетворения соглашений об уровне обслуживания и других стандартов качества. |
Разбивка действий и разрешений в этих стандартных ролях часто одинакова для приложений, подписок или всего облачного пространства, даже если эти роли выполняются разными людьми на разных уровнях. Соответственно, можно создать общий набор определений ролей Azure для применения в разных областях в вашей среде. Затем пользователям и группам можно назначить общую роль, но только для области ресурсов, групп ресурсов, подписок или групп управления, за управление которыми они отвечают.
Например, в топологии сети концентратора и периферийной сети с несколькими подписками может быть общий набор определений ролей для концентратора и всех периферийных рабочих нагрузок. Роль NetOps в рамках подписки-хаба можно назначить участникам центральной команды ИТ-организации, которые отвечают за поддержание сети для общих служб, используемых всеми нагрузками. Затем роль NetOps для подписки на рабочую нагрузку может быть назначена членам соответствующей команды, что позволяет им настраивать сети в этой подписке для лучшей поддержки их рабочих процессов. То же определение роли используется для обеих, но назначения по областям гарантируют, что пользователи имеют только доступ, который необходим для выполнения их работы.