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

Что такое управление доступом на основе ролей в 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. Это ключевое понятие для понимания — именно так осуществляется контроль за разрешениями. Назначение ролей состоит из трех элементов: субъект безопасности, определение роли и область действия.

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

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

Схема: типы субъектов безопасности для назначения ролей

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

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

Схема: пример определения роли для назначения ролей

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

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

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

Для получения дополнительной информации см. Понимание определений ролей Azure.

Область

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации см. раздел Шаги по назначению роли Azure.

Группы

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

Схема, показывающая, как назначения ролей являются транзитивными для групп

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

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

Схема, показывающая, как пересекаются несколько назначений ролей.

Как 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 проверяет, учтено ли действие в вызове API в ролях, которые пользователь имеет для этого ресурса. Если роли содержат Actions, где имеется подстановочный знак (*), действующие разрешения вычисляются путем вычитания NotActions из допустимой Actions. Аналогичным образом вычитание выполняется для любых действий с данными.

    Actions - NotActions = Effective management permissions

    DataActions - NotDataActions = Effective data permissions

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

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

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

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

Блок-схема логики оценки для определения доступа к ресурсу.

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

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

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

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

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

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

Схема, на которой показаны данные Azure RBAC в нескольких регионах.

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

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

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