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


Что такое управление доступом на основе ролей в Azure (RBAC)?

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

Azure RBAC — это система авторизации, основанная на Azure Resource Manager , которая обеспечивает точное управление доступом к ресурсам Azure.

В этом видео представлен краткий обзор Azure RBAC.

Какие возможности обеспечивает RBAC Azure?

Вот примеры того, что можно выполнять с помощью RBAC Azure:

  • предоставление одному пользователю разрешения на управление виртуальными машинами в подписке, а другому — на управление виртуальными сетями;
  • предоставление группе DBA разрешения на управление базами данных SQL в подписке;
  • предоставление пользователю разрешения на управление всеми ресурсами в группе ресурсов, включая виртуальные машины, веб-сайты и подсети;
  • представление приложению доступа ко всем ресурсам в группе ресурсов.

Принцип работы RBAC Azure

Для управления доступом к ресурсам с помощью Azure RBAC создаются назначения ролей. Это важнейшее понятие. Именно таким образом предоставляются разрешения. Назначение ролей состоит из трех элементов: субъект безопасности, определение роли и область действия.

Субъект безопасности

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

Diagram showing the security principal types for a role assignment.

Определение роли

Определение роли представляет собой коллекцию разрешений. Обычно это называется ролью. В определении роли перечисляются действия, которые можно выполнить, например чтение, запись и удаление. Роль может быть общей, например "Владелец", или более конкретной, например "Модуль чтения виртуальной машины".

Diagram showing role definition example for a role assignment

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

В этом видео представлен краткий обзор встроенных и настраиваемых ролей.

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

Дополнительные сведения о ролях Azure см. в этой статье.

Область

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

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

Diagram showing scope levels for a role assignment.

Дополнительные сведения об областях см. в статье Общие сведения об областях для Azure RBAC.

Назначения ролей

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

На приведенной ниже схеме показан пример назначения ролей. В этом примере группе "Маркетинг" назначена роль Участник для группы ресурсов "Продажи медицинских препаратов". Это означает, что пользователи из группы "Маркетинг" могут создавать ресурсы Azure в группе ресурсов "Продажи медицинских препаратов" или управлять любыми такими ресурсами. У маркетинговых пользователей нет доступа к ресурсам за пределами группы ресурсов pharma-sales, если только они не входят в другое назначение ролей.

Diagram showing how security principal, role definition, and scope create a role assignment.

Назначать роли можно с помощью портала Azure, Azure CLI, Azure PowerShell, пакетов SDK Azure или REST API.

Дополнительные сведения см. в статье Шаги по добавлению назначения роли.

Группы

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

Diagram showing how role assignments are transitive for groups.

Несколько назначений ролей

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

Diagram showing how multiple role assignments overlap.

Как RBAC Azure определяет право доступа пользователя к ресурсу

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

  1. Пользователь A (или директор службы) приобретает токен для Azure Resource Manager.

    Токен включает членство в группе пользователей (включая переходные членства в группах).

  2. Пользователь выполняет вызов REST API в Azure Resource Manager с помощью присоединенного токена.

  3. Azure Resource Manager извлекает все назначения ролей и запрет назначений, которые применяются к ресурсу, на котором выполняется действие.

  4. Если применяется запрет назначения, доступ блокируется. В противном случае вычисление продолжается.

  5. Azure Resource Manager сужает назначенные роли, которые применяются к этому пользователю или группе, и определяет, какие роли у пользователя есть для этого ресурса.

  6. Azure Resource Manager определяет, включено ли действие в вызове API в роли, которые пользователь имеет для этого ресурса. Если роли содержат Actions, где имеется подстановочный знак (*), действующие разрешения вычисляются путем вычитания NotActions из допустимой Actions. Аналогичным образом вычитание выполняется для любых действий с данными.

    Actions - NotActions = Effective management permissions

    DataActions - NotDataActions = Effective data permissions

  7. Если у пользователя нет роли с действием на запрошенном область, доступ не допускается. В противном случае оцениваются все условия.

  8. Если назначение роли включает условия, они оцениваются. В противном случае доступ разрешен.

  9. Если условия соблюдены, доступ разрешен. В противном случае доступ не разрешен.

На следующей схеме представлены сводные сведения о логике оценки.

Evaluation logic flowchart for determining access to a resource.

Где хранятся данные Azure RBAC?

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

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

Почему глобальные данные Azure RBAC?

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

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

Diagram showing Azure RBAC data in multiple regions.

Требования к лицензиям

Эта функция бесплатна и доступна в вашей подписке Azure.

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