Role based access control что это

Обновлено: 28.06.2024

Role Based Access Control (RBAC) это новая модель разрешений, используемая в Microsoft Exchange Server 2013. При использовании RBAC отпадает необходимость в изменении и поддержании списков управления доступом (ACL), использовавшихся в Exchange Server 2007. Со списками ACL в версии Exchange 2007 было связано несколько проблем: было трудно изменять списки ACL без непредвиденных последствий, сохранять изменения ACL после обновлений и диагностировать проблемы, возникающие из-за нестандартного использования.

Модель RBAC позволяет контролировать как на широком, так и детальном уровне, какие действия могут совершать администраторы и конечные пользователи. RBAC также позволяет более точно сопоставлять роли, назначенные пользователям и администраторам, с их фактическими ролями в организации. В Exchange 2007 модель разрешений сервера применялась только к администраторам, которые управляли инфраструктурой Exchange 2007. В версии Exchange 2013 модель RBAC позволяет контролировать выполнение задач администрирования и полномочия, предоставляемые пользователям для управления своими почтовыми ящиками и группами рассылки.

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

В этом разделе рассматриваются расширенные возможности управления доступом на основе ролей (RBAC). Сведения об управлении базовыми разрешениями Exchange 2013, такими как использование Центра администрирования Exchange для добавления и удаления участников групп ролей, создания и изменения групп ролей, а также создания и изменения политик назначения ролей, см. в разделе Разрешения.

Сравнение ABAC и RBAC

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

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

P. S.: На сегодняшний день для ABAC существует стандарт XACML, который активно развивается и используется. Подробнее о нем можно узнать в следующей статье.

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

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

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

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

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

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

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

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

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

Actions - NotActions = Effective management permissions

DataActions - NotDataActions = Effective data permissions

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

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

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

Политики назначения ролей управления

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

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

Политика назначения ролей управления. Политика назначения ролей управления — это особый объект в Exchange 2013 г. Пользователям присваивается политика назначения ролей при создании почтовых ящиков или при изменении политики назначения ролей для почтового ящика. Она также назначается для ролей управления конечных пользователей. Сочетание всех ролей в политике назначения ролей определяет для пользователя все функции управления почтовым ящиком или группами рассылки.

Роль управления. Роль управления — это контейнер для группировки записей ролей управления. Роли позволяют указывать определенные задачи, которые пользователь может выполнять с почтовым ящиком или группами рассылки. Запись роли управления — это кодлет, скрипт или специальное разрешение, которое позволяет выполнять каждую конкретную задачу в роли управления. Вы можете использовать только роли конечных пользователей с политиками назначения ролей. Дополнительные сведения см. в руководстве Understanding roles.

Назначение ролей управления: назначение роли управления является связующим звеном между ролью и политикой назначения ролей. Назначение роли политике назначения ролей позволяет использовать командлеты и параметры, определенные в роли. При создании назначения ролей между политикой назначения ролей и ролью область действия назначения указать нельзя. Область, применяемая назначением, либо Self . MyGAL Все назначения ролей распространяются на почтовый ящик пользователя или его группы рассылки. Дополнительные сведения см. в дополнительных сведениях о назначенияхролей управления.

Если необходимо изменить распределение ролей в политиках назначения ролей, следует изменить назначения ролей, связывающие роли с политиками назначения ролей. Если назначения, встроенные в Exchange 2013, отвечают потребностям организации, изменять их не требуется. Дополнительные сведения см. в статье Общие сведения о назначениях ролей управления.

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

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

Подходы к контролю доступа: RBAC vs. ABAC

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.

Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.

Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:

каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к чужим;
каждый сотрудник должен видеть только связанную со своими бизнес-задачами информацию;
у каждой задачи должен быть ответственный за ее выполнение сотрудник.

неэффективного выполнения чужих задач в силу некомпетентности;
умышленных или неумышленных ошибок в чужих задачах;
раскрытия информации посторонним лицам.

Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).

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

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

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

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

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

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

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

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

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

Область

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

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

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

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

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

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

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

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

Attribute-based access control (ABAC)

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

Можно явно выделить несколько категорий атрибутов.

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

Простые правила описываются простыми условиями.

Многомерные правила в этой модели не становятся более сложными.

При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».

Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC:

бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми;
не происходит взрывного роста числа условий, что упрощает их сопровождение.

Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных.

Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.

Администратор Ольга

Ольга является администратором в Contoso, компании среднего размера. Она отвечает за управление получателями компании в офисе, расположенном в Ванкувере. При создании модели разрешений Contoso Ольга вошла в группу "Управление получателями Ванкувер" настраиваемую группу ролей для Ванкувера. Роль "Управление получателями Ванкувер" наиболее точно отвечает ее рабочим обязанностям, к которым относятся создание и удаление получателей (например, почтовых ящиков и контактов), управление членством в группах рассылки и свойствами почтовых ящиков, а также другие аналогичные задачи.

Помимо настраиваемой группы ролей "Управление получателями Ванкувер", пользователю Jane также необходима политика назначения ролей для управления параметрами конфигурации собственного почтового ящика. Администраторы организации приняли решение о том, что все пользователи, кроме высшего руководства, получают одни и те же разрешения для управления своими почтовыми ящиками. Они могут настраивать свою голосовую почту, задавать политики хранения и вносить изменения в данные адреса. Политика назначения ролей по умолчанию, предоставляемая вместе с Exchange 2013, отвечает этим требованиям.

Так как пользователь Jane является членом настраиваемой группы ролей "Управление получателями Ванкувер", ей предоставляются разрешения на управление собственным почтовым ящиком. Несмотря на это, группа ролей не предоставляет ей все разрешения, необходимые для управления всеми аспектами работы почтового ящика. Разрешения, необходимые для управления параметрами голосовой почты и политик хранения, не входят в ее группу ролей. Они предоставляются только присвоенной ей политикой назначения ролей по умолчанию.

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

Создана настраиваемая группа ролей "Управление получателями Ванкувер". При ее создании произошло следующее:

Группе ролей были назначены все роли управления, также назначенные встроенной группе ролей Управление получателями. Это предоставляет пользователям, добавленным в настраиваемую группу ролей "Управление получателями Ванкувер", те же разрешения, которые предоставляются членам группы ролей Управление получателями. Тем не менее следующие этапы ограничивают пределы использования этих разрешений.

Создана настраиваемая область управления "Получатели Ванкувер", в которую входят только получатели из Ванкувера. Это было сделано путем создания области с фильтрацией по городу пользователя или другим уникальным данным.

Группа ролей была создана с использованием настраиваемой области управления "Получатели Ванкувер". Это значит, что администраторы, добавленные в группу ролей "Управление получателями Ванкувер", получают полные права на управление получателями, но могут применять их только к получателям из Ванкувера.

Дополнительные сведения о создании настраиваемой группы ролей см. в статье Управление группами ролей.

Ольга добавляется в качестве члена настраиваемой группы ролей "Управление получателями Ванкувер".

Дополнительные сведения о добавлении участников в группу ролей см. в статье Управление участниками группы ролей.

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

Дополнительные сведения о настройке политики назначения ролей по умолчанию см. в разделе Управление политиками назначения ролей.

Вице-президент Елена

Елена — вице-президент компании Contoso по маркетингу. Елена относится к высшему руководству Contoso и получает больше разрешений, чем обычный пользователь. Это относится к разрешениям на управление почтовым ящиком за одним исключением: Елене не разрешается управлять политиками сохранения по требованиям соответствия юридическим требованиям. Елена может настраивать свою голосовую почту, изменять контактные данные и данные профиля, создавать собственные группы рассылки и управлять ими, а также добавлять и удалять себя из существующих групп рассылки, принадлежащих другим пользователям.

Итак, Елене присвоены другие разрешения на управление собственным почтовым ящиком. Большинству пользователей в Contoso назначена политика назначения ролей по умолчанию. Высшему руководству, тем не менее, присвоена отдельная политика назначения ролей. Для создания настраиваемой политики назначения ролей были выполнены следующие действия:

Затем Елене была вручную присвоена политика назначения ролей для высшего руководства.

После этого для почтового ящика Елены действуют разрешения, задаваемые политикой назначения ролей для высшего руководства. Изменения этой политики назначения ролей автоматически применяются к ее почтовому ящику и всем другим почтовым ящикам, также связанным с этой политикой назначения ролей.

Прямое назначение ролей пользователей

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

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

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

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

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

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

RBAC и ABAC

Управление доступом на основе ролей и управление доступом на основе атрибутов (ABAC) – это два типа методов управления доступом, однако их подходы различны.

В то время как RBAC предоставляет права доступа в зависимости от ролей пользователей, ABAC управляет доступом на основе комбинации атрибутов: атрибутов пользователя, атрибутов ресурса, атрибутов, связанных с системой или приложением, к которым осуществляется доступ, и атрибутов среды.

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

Помимо упрощения процесса управления доступом, ABAC позволяет компаниям снизить риски, связанные с несанкционированным доступом, и помогает централизовать аудит.

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

Role-based access control (RBAC)

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

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

Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит и т. п.).

После каждого добавления нового значения атрибута придется добавлять новые роли. То есть если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.

Кроме этого, появляются и другие проблемы:

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

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

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

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

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

Группы

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

Преимущества RBAC

Использование RBAC для ограничения ненужного доступа к сети на основе ролей пользователей в организации имеет ряд преимуществ, в том числе:

Повышение операционной эффективности. Благодаря RBAC компании могут снизить потребность в смене документов и паролей, когда нанимают новых сотрудников или меняют роли существующих сотрудников. RBAC позволяет организациям быстро добавлять и изменять роли, а также реализовывать их на разных платформах, в операционных системах и приложениях. Это также сокращает вероятность ошибки при назначении прав пользователя. Кроме того, с помощью RBAC компании могут легче интегрировать сторонних пользователей в свои сети, предоставляя им предопределенные роли.
Повышение соответствия. Каждая организация должна соответствовать местным, государственным и федеральным нормам. Компании обычно предпочитают внедрять системы RBAC для удовлетворения нормативных и законодательных требований в отношении конфиденциальности, поскольку руководители и ИТ-отделы могут более эффективно управлять доступом и использованием данных. Это особенно важно для финансовых учреждений и медицинских организаций.
Прозрачность и контроль. RBAC предоставляет системным администраторам больше прозрачности и контроля, а также гарантирует, что авторизованным пользователям и гостям в системе предоставляется доступ только к тому, что им нужно для выполнения своей работы.
Сокращение затрат. Запретив пользователю доступ к определенным процессам и приложениям, компании могут экономить или более эффективно использовать ресурсы, такие как пропускная способность сети, память и хранилище.
Снижение риска нарушений и утечки данных. Внедрение RBAC означает ограничение доступа к конфиденциальной информации, что снижает вероятность взлома или утечки данных.

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

Необходимо определить ресурсы, доступом к которым требуется управлять, если они еще не перечислены, например, базы данных клиентов, системы электронной почты и т.д.
Требуется произвести анализ рабочей силы и определение ролей с одинаковыми потребностями в доступе. Однако не стоит создавать слишком много ролей, поскольку это противоречит целям RBAC и создает систему контроля доступа на основе конкретного пользователя, а вовсе не его роли. Например, может существовать базовая роль пользователя, которая включает доступ, необходимый каждому сотруднику, например, к электронной почте и корпоративной интрасети. Другая роль может быть ролью представителя службы поддержки клиентов, которая будет иметь права на чтение / запись в базе данных клиентов, и еще одной ролью может быть роль администратора базы данных клиентов с полным контролем над ней.
После создания списка ролей и их прав доступа требуется настроить эти права и выдать их пользователям сети.
Определите процесс изменения роли, блокировки учетной записи сотрудника, покидающего компанию, и процесс регистрации новых сотрудников.
Убедитесь, что RBAC интегрирован во все системы компании.
Проводите обучение, чтобы сотрудники понимали принципы RBAC.
Периодически проводите аудит ролей, корректности их назначения сотрудникам и параметров доступа, разрешенного для каждой роли. Если выясняется, что роль имеет ненужный доступ к определенной системе, измените роль и измените уровень доступа для тех лиц, которые находятся в этой роли.

Специалист Павел

Павел работает в Contoso той же компании, где работает Ольга. Он отвечает за выполнение представления, настройку политик хранения, правил транспорта и ведения журнала в масштабах всей организации. Как и в случае Ольги, при создании модели разрешений Contoso Павел был добавлен в группы ролей, отвечающие его рабочим обязанностям. Группа ролей Управление записями предоставляет Павлу разрешения на настройку политик хранения, ведения журнала и правил транспорта. Группа ролей Управление обнаружением предоставляет ему возможность вести поиск в почтовых ящиках.

Как и в случае с Ольгой, Павлу нужны разрешения для управления своим почтовым ящиком. Ему присваиваются те же разрешения, что и Ольге: он может настраивать свою голосовую почту и политики хранения, а также изменять данные адреса.

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

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

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

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

Управление доступом на основе ролей (role-based access control или RBAC) - это метод ограничения доступа к сети на основе ролей отдельных пользователей в рамках предприятия. RBAC позволяет сотрудникам иметь права доступа только к той информации, которая им необходима для работы, и не позволяет им получать доступ к информации, которая у ним не относится.

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

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

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

Обзор и примеры

На следующей иллюстрации приведены компоненты RBAC и описано их взаимодействие:

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

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

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

Политики назначения ролей:

С политикой назначения ролей может быть связан один пользователь или несколько.

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

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

Прямое назначение ролей (дополнительный метод):

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

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

Обзор RBAC

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

Группы ролей управления

Группы ролей управления связывают роли управления с группами администраторов или пользователей-специалистов. Администраторы управляют широкой Exchange или конфигурацией получателей. Специализированные пользователи управляют определенными функциями Exchange, такими как соответствие требованиям. Или они могут иметь ограниченные возможности управления, такие как члены службы поддержки, но не имеют широких административных прав. Группы ролей обычно связывают административные роли управления, позволяющие администраторам и пользователям-специалистам управлять конфигурацией организации и получателей. Например, можно ли администраторам управлять получателями или использовать функции обнаружения почтовых ящиков, управляется с помощью групп ролей.

Обычно разрешения назначаются администраторам и пользователям-специалистам путем добавления и удаления соответствующих пользователей в группах ролей. Дополнительные сведения см. в статье Общие сведения о группах ролей управления.

Группы ролей состоят из следующих компонентов, определяющих доступные администраторам и пользователям-специалистам возможности:

Группа ролей управления. Группа ролей управления — это специальная универсальная группа безопасности (USG), которая содержит почтовые ящики, пользователей, группы usGs и другие группы ролей, которые являются членами группы ролей. Здесь добавляются и удаляются члены, а также назначены роли управления. Сочетание всех ролей в группе ролей определяет все, что пользователи, добавленные в группу ролей, могут управлять в Exchange организации.

Роль управления. Роль управления — это контейнер для группировки записей ролей управления. Роли используются для определения определенных задач, которые могут выполняться членами группы ролей, за которую назначена роль. Запись роли управления — это командылет, скрипт или специальное разрешение, которое позволяет выполнять каждую конкретную задачу в роли. Дополнительные сведения см. в руководстве Understanding roles.

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

Область ролей управления. Область ролей управления — это область влияния или влияния на назначение ролей. При назначении роли с областью группе ролей область управления определяет, какими объектами может управлять это назначение. Затем назначение и область его выполнения даются членам группы ролей и ограничивают возможности, которые могут выполнять эти члены. Область может состоять из списка серверов или баз данных, организационных подразделений (OUs) или фильтров на объектах сервера, базы данных или получателей. Дополнительные сведения см. в разделе Общие сведения об областях ролей управления.

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

Если необходимо изменить распределение ролей в группах ролей, следует изменить назначения ролей, связывающие роли с группами ролей. Если назначения, встроенные в Exchange 2013, отвечают потребностям организации, изменять их не требуется. Дополнительные сведения см. в статье Общие сведения о назначениях ролей управления.

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

Запрет назначений

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

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

Читайте также: