Role Based Access Control (RBAC) – новая модель управления доступом к Exchange 2010

До выхода Exchange 2010 наделение пользователей дополнительными возможностями осуществлялось при помощи функционала делегирования управления и списков управления доступом (ACL). В Exchange 2010 сердцем модели авторизации стала новая система разрешений Role Based Access Control(RBAC).

Role Based Access Control (RBAC) — это новая модель разрешений в Microsoft Exchange Server 2010. При использовании RBAC отпадает необходимость в изменении и поддержании списков управления доступом (ACL), использовавшихся в Exchange Server 2007.

Принципиальное отличие в данном случае состоит в том, что разрешения ассоциируются не с объектами AD, такими как серверы и почтовые ящики, а с задачами. Также необходимо знать, что в отличие от назначения разрешений безопасности (например в NTFS), где приоритетно ограничивающее разрешение, в RBAC пользователю присваивается объединение всех ролей и прав, которые для него назначены.

К сожалению, Exchange Management Console (EMC) не позволяет полноценно работать с RBAC, по этому, мы будем использовать командлеты Exchange Management Shell (EMS). Правда для просмотра набора ролей и редактирования их участников подойдет и веб-сайт с Exchange Control Panel (ECP).

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

Справка TechNet предлагает визуализировать схему работы RBAC следующим образом:

Рис.1: Визуальная схема работы RBAC.

Мне же больше нравится несколько модернизированный её вид:

Рис.2: Треугольник RBAC.

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

На практике, более правильным будет порядок вопросов Кто? –> Что? –> Где?, но для лучшего понимания теории давайте рассмотрим эти вопросы немного в другой последовательности.

1. Что?

Ответ на вопрос «Что?» должен подразумевать под собой те действия, которыми вы хотите наделить пользователя, т.е. Что он должен иметь право делать. Для ответа на этот вопрос существуют роли (Roles).

Роли управления (Management Roles) являются частью модели RBAC. Роли работают как логическая группировка командлетов, которые объединены для предоставления доступа к просмотру и изменению конфигурации компонентов Exchange 2010, например почтовых ящиков, правил транспорта и получателей. 

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

Active Directory Permissions Role	Роль разрешений Active Directory
Address Lists Role	Роль списков адресов
ApplicationImpersonation Role	Роль ApplicationImpersonation
Audit Logs Role	Роль журналов аудита
Cmdlet Extension Agents Role	Роль агентов расширения командлетов
Database Availability Groups Role	Роль групп доступности базы данных
Database Copies Role	Роль копий баз данных
Databases Role	Роль баз данных
Disaster Recovery Role	Роль аварийного восстановления
Distribution Groups Role	Роль групп рассылки
Edge Subscriptions Role	Роль пограничных подписок
E-Mail Address Policies Role	Роль политик адресов электронной почты
Exchange Connectors Role	Роль соединителей Exchange
Exchange Server Certificates Role	Роль сертификатов сервера Exchange Server
Exchange Servers Role	Роль серверов Exchange
Exchange Virtual Directories Role	Роль виртуальных каталогов Exchange
Federated Sharing Role	Роль федеративного общего доступа
Information Rights Management Role	Роль управления правами на доступ к данным
Journaling Role	Роль ведения журнала
Legal Hold Role	Роль юридического удержания
Mail Enabled Public Folders Role	Роль общих папок с включенной поддержкой почты
Mail Recipient Creation Role	Роль создания получателя электронной почты
Mail Recipients Role	Роль получателей почты
Mail Tips Role	Роль советов по использованию электронной почты
Mailbox Import Export Role	Роль экспорта и импорта почтового ящика
Mailbox Search Role	Роль поиска в почтовом ящике
Message Tracking Role	Роль отслеживания сообщений
Migration Role	Роль миграции
Monitoring Role	Отслеживание роли
Move Mailboxes Role	Перемещение роли почтовых ящиков
MyBaseOptions Role	Роль Мои_базовые_параметры
MyContactInformation Role	Роль Моя_контактная_информация
MyDiagnostics Role	Роль MyDiagnostics
MyDistributionGroupMembership Role	Роль Членство_в_моей_группе_рассылки
MyDistributionGroups Role	Роль Мои_группы_рассылки
MyProfileInformation Role	Роль Информация_о_моем_профиле
MyRetentionPolicies Role	Роль Мои_политики_хранения
MyVoiceMail Role	Роль Моя_голосовая_почта
Organization Client Access Role	Роль клиентского доступа организации
Organization Configuration Role	Роль конфигурации организации
Organization Transport Settings Role	Роль параметров транспорта организации
POP3 and IMAP4 Protocols Role	Роль протоколов POP3 и IMAP4
Public Folder Replication Role	Роль репликации общих папок
Public Folders Role	Роль общих папок
Receive Connectors Role	Роль соединителей получения
Recipient Policies Role	Роль политик получателя
Remote and Accepted Domains Role	Роль удаленных и обслуживаемых доменов
Retention Management Rolet	Роль управления хранением
Role Management Role	Роль управления ролями
Security Group Creation and Membership Role	Роль создания и членства в группе безопасности
Send Connectors Role	Роль соединителей отправки
Support Diagnostics Role	Поддержка роли диагностики
Transport Agents Role	Роль агентов транспорта
Transport Hygiene Role	Роль санации транспорта
Transport Queues Role	Роль очередей транспорта
Transport Rules Role	Роль правил транспорта
UM Mailboxes Role	Роль почтовых ящиков единой системы обмена сообщениями
UM Prompts Role	Роль запросов единой системы обмена сообщениями
Unified Messaging Role	Роль единой системы обмена сообщениями
Unscoped Role Management Role	Роль управления с незаданной областью
User Options Role	Роль параметров пользователя
View-Only Configuration Role	Роль конфигурации с правами только на просмотр
View-Only Recipients Role	Роль получателей с правами только на просмотр

Совет: Если вы хотите применять настраиваемые сценарии или командлеты, не относящихся к Exchange, то вам необходимо использовать Роль управления с незаданной областью (Unscoped Role Management Role).

Список всех ролей можно получить командлетом:

Get-ManagementRole

Рис.3: Вывод списка ролей.

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

Вы можете проконтролировать какие именно командлеты может выполнять роль, выполнив команду:

Get-ManagementRoleEntry "Mail Recipients\*"

Рис.4: Вывод списка командлетов роли Mail Recipients.

Данная команда показывает нам все командлеты, которые применимы внутри роли Mail Recipients.

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

Пример	Описание
*\*	Возвращает список всех записей роли для всех ролей.
*\Set-Mailbox	Возвращает список всех записей роли, которые содержат командлет Set-Mailbox.
Mail Recipients\*	Возвращает список всех записей роли в роли получателей почты.
Mail Recipients\*Mailbox	Возвращает список всех записей роли в роли получателей почты, оканчивающихся на Mailbox.
My*\*Group*	Возвращает список всех записей роли, которые содержат строку Group в имени командлета, для всех ролей, начинающихся с My.

Встроенные роли, выполняя определенный список задач, не покрывают все сценарии использования Exchange 2010. Для более гибкой настройки политики распределения полномочий, у нас есть возможность создавать дочерние роли (Child Roles).

Рис.5: Иерархия ролей.

Создать дочернюю роль можно командлетом New-ManagementRole, указав при этом её родителя при помощи параметра –Parent.
New-ManagementRole –Name “New Databases” – Parent “Databases”

Есть несколько вещей, которые должен знать администратор при создании дочерних ролей:

1. Вы можете создавать дочерние роли для уже дочерних ролей.
2. Дочерняя роль НЕ может обладать большими полномочиями, чем родительская, даже если родительская роль сама является дочерней.
3. У каждой роли должно быть минимум одно разрешение.
4. Перед удалением роли необходимо вручную удалить все её разрешения.
5. У вас должно быть право выполнять Get-командлеты для этой роли.

После создания роли необходимо отредактировать её разрешения при помощи командлета Get-ManagementRoleEntry. Для начала, нужно удалить все разрешения, кроме одного:

Get-ManagementRoleEntry “New Databases\*” | where {$_.name –ne “Get-Recipient”} | Remove-ManagementRoleEntry

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

Add-ManagementRoleEntry “New Databases\Mount-Database” –Parameters Confirm,Debug

Рис.6: Добавление дочерней роли.

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

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

• Администратор или специалист (Administrative or specialist)   Роли, связанные с типом ролей администратора или специалиста, имеют более широкую область влияния в организации Exchange. Роли этого типа позволяют выполнять такие задачи, как управление сервером или получателями, настройка организации, администрирование в соответствии с требованиями, аудит и другие.
• Ориентированные на пользователя (User-focused)   Роли, связанные с типом ролей, ориентированных на пользователя, имеют область влияния, привязанную к одному пользователю. Роли этого типа позволяют выполнять такие задачи, как настройка профиля пользователя и самоуправление, управление пользовательскими группами рассылки и другие.
  Имена ролей, связанных с типами ролей, ориентированных на пользователя, и имена типов ролей, ориентированных на пользователя, начинаются с My.
• Специальность (Specialty)   Роли, связанные с типом ролей специальности, позволяют выполнять задачи, не относящиеся к типам административных или ориентированных на пользователя ролей. Роли этого типа позволяют выполнять такие задачи, как олицетворение приложения (application impersonation) и использование сценариев и командлетов, не относящихся к Exchange.

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

2. КТО?

Данный угол треугольника RBAC подразумевает под собой ответ на вопрос Кто?. Т.е. кто именно может выполнять обозначенные в вопросе «Что?» действия.

В качестве ответа на вопрос «Кто?» мы можем использовать конкретного пользователя (в RBAC пользователи представлены в виде почтовых ящиков), или группу. Чтобы выдать полномочия пользователю, необходимо добавить его в группу ролей управления (Role Groups), а затем группу связать с определенной ролью (Role).

Группа ролей управления(Management Role Group) — это универсальная группа безопасности, используемая в модели RBAC в Microsoft Exchange Server 2010. В Active Directory, группы ролей (Role Groups) располагаются в отдельной OU – Microsoft Exchange Security Groups. Там же можно посмотреть, кто входит в группу. Для всех участников группы ролей назначается идентичный набор ролей.

Рис.7: Расположение групп ролей в AD.

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

В следующей таблице перечислены встроенные группы ролей в составе Exchange 2010.

Группа ролей		Описание
Organization Management	Управление организацией	Администраторы, являющиеся участниками группы ролей Управление организацией, имеют административный доступ ко всей организации Exchange 2010 и могут выполнять практически все задачи с любым объектом Exchange 2010.
View-Only Organization Management	Управление организацией с правами только на просмотр	Администраторы, являющиеся участниками группы ролей Управление организацией с правами только на просмотр, могут просматривать свойства любого объекта в организации Exchange.
Recipient Management	Управление получателями	Администраторы, являющиеся участниками группы ролей Управление получателями, имеют административный доступ для создания или изменения получателей Exchange 2010 в организации Exchange 2010.
UM Management	Управление единой системой обмена сообщениями	Администраторы, являющиеся участниками группы ролей управления единой системы обмена сообщениями, могут управлять компонентами единой системы обмена сообщениями в организации Exchange, например конфигурацией сервера единой системы обмена сообщениями, свойствами этой системы для почтовых ящиков, запросами системы и конфигурацией автосекретаря единой системы обмена сообщениями.
Discovery Management	Управление обнаружением	Администраторы или пользователи, которые являются участниками группы ролей Управление обнаружением, могут выполнять поиск данных, которые соответствуют определенным критериям, в почтовых ящиках организации Exchange.
Records Management	Управление записями	Пользователи, которые являются участниками группы ролей Управление записями, могут настраивать такие соответствия требованиям, как теги политики хранения, классификации сообщений, правила транспорта и другие.
Server Management	Управление сервером	Администраторы, являющиеся участниками группы ролей управления сервером, имеют административный доступ к конфигурации сервера Exchange 2010. Они не имеют административного доступа к конфигурации получателя Exchange 2010.
Help Desk	Служба поддержки	Пользователи, являющиеся участниками группы ролей службы поддержки, могут выполнять ограниченное число задач управления получателями Exchange 2010.
Hygiene Management	Управление санацией	Администраторы, которые являются участниками группы ролей «Управление санацией», могут настраивать эти функции защиты от нежелательной почты и вирусов в Exchange 2010. Сторонние программы, интегрированные с Exchange 2010, могут добавлять в эту группу ролей учетные записи служб, чтобы предоставить этим программам доступ к командлетам, необходимым для извлечения и настройки конфигурации Exchange.
Public Folder Management	Управление общими папками	Администраторы, являющиеся участниками группы ролей управления общими папками, могут управлять общими папками и базами данных на серверах Exchange 2010.
Delegated Setup	Делегированная установка	Администраторы, являющиеся участниками группы ролей делегированной установки, могут развертывать предварительно подготовленные серверы Exchange 2010.

Вы можете назначить группе несколько ролей, если желаете, чтобы её члены имели больше возможностей. Также, при создании группы можно указать область (Scope), если вы не хотите, чтобы была присвоена область по умолчанию (но об этом чуть позже).
Чтобы создать новую группу ролей нужно воспользоваться командлетом New-RoleGroup:

New-RoleGroup “Group new databases” –Roles “New Databases”

Добавить пользователя или группу пользователей в группу ролей можно при помощи команды:

Add-RoleGroupMember “Group new databases” -Member user1

Рис.8: Добавление группы ролей и связывание её с пользователем.

Добавить пользователя в группу и просмотреть её параметры вы можете и при помощи Exchange Control Panel - ECP -> Users & Groups -> Administrator Roles.

Рис.9: Просмотр информации о группе через веб-страницу Exchange Control Panel.

Увидеть список всех групп мы можем, выполнив команду:

Get-RoleGroup

3. ГДЕ?

Следующим вопросов, на который вы должны ответить – это вопрос «Где?». Т.е. на какие объекты вы планируете давать разрешения? Ответ на данный вопрос вы должны задать в параметре Role Scope (область действия роли).

Область действия роли (Role Scope) – это объект, на который направлено действие конкретной роли, это может быть целая организация, отдельная OU в AD, либо группа пользователей.

У всех ролей RBAC есть свои области действия (Management role scope).

Когда вы создаете новую роль RBAC, по умолчанию, она будет наследовать область действия своего родителя. Но вы можете указать область действия роли также непосредственно во время её создания. Хорошей практикой является предварительное создание области действия (Role Scope) и последующее назначение её определенной роли с той целью, чтобы эту область потом можно было использовать ещё раз.

Создание новой области действия происходит при помощи командлета New-ManagementScope, к которому должны быть применены параметры фильрации:

• RecipientRestrictionFilter
• ServerRestrictionFilter
• ServerList

Например так:

New-ManagementScope -name "Managers" -RecipientRestrictionFilter {memberofgroup -eq "cn=Managers,ou=Managers,dc=domain,dc=local"}

Эта команда создает новую область действия с названием Managers из всех пользователей, группы Managers, находящейся в OU Managers.

Таким образом, мы видим, что области могут быть двух видов:

• Неявные области (implicit scopes) - наследуемые;
• Явные области (explicit scopes) - предварительно определенные и настраиваемые:
• Предварительно определенные относительные области (Predefined Relative Scopes)
• Настраиваемые области (Custom Scopes)

Посмотреть область действия конкретной роли можно командой:

Get-ManagementRole “Databases” | fl *scope*

Рис.10: Область действия конкретной роли

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

• Область чтения получателей (Recipient read scope)  Неявная область чтения получателей определяет объекты получателей, которые пользователь с назначенной ролью управления может читать из Active Directory.
• Область записи получателей (Recipient write scope)   Неявная область записи получателей определяет объекты получателей, которые пользователь с назначенной ролью управления может изменять в Active Directory.
• Область чтения конфигурации (Configuration read scope)   Неявная область чтения конфигурации определяет объекты конфигурации, которые пользователь с назначенной ролью управления может читать из Active Directory.
• Область записи конфигурации (Configuration write scope)   Область записи конфигурации определяет объекты сервера и организации, которые пользователь с назначенной ролью управления может изменять в Active Directory.

Области должны добавляться в один из этих типов областей.

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

Назначение области для определенной роли делается при помощи политики назначений (Role Assignment), командлетами New-ManagementRoleAssignment или Set-ManagementRoleAssignment.

4. Назначение ролей (Role Assignment)

Наконец мы добрались до центра треугольника.
Как вы уже заметили «Где», «Что» и «Кто» - это все элементы Active Directory. Таким образом, связующим, для этих трех элементов будет другой объект AD – назначение ролей (Role Assignment).

Политика назначения ролей управления (Role Assignment) — это набор из одной или нескольких ролей управления. Политики назначения ролей являются частью модели RBAC и позволяют определять, какие именно параметры может изменять конечный пользователь.

Командлет New-RoleGroup создает именно политику назначения (Role Assignment) между группой ролей (Role Groups) и ролью (Management Role), с дополнительными атрибутами.

Рис.11: Модель политики назначения ролей управления

Запустив команду

Get-ManagementRoleAssignment

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

Примечание: Как уже говорилось в самом начале, очень важно не путать RBAC с назначением разрешений безопасности (например NTFS), где приоритетно ограничивающее разрешение. В RBAC пользователю присваивается объединение всех ролей, которые для него назначены. Таким образом, нужно назначать пользователю только те роли, которые необходимы.

Назначения создаются при помощи командлета New-ManagementRoleAssignment с добавлением в виде параметров всех связываемых элементов: имени назначение (–Name), группы ролей (–SecurityGroup), роли (–Role) и области действия (-RecipientRelativeWriteScope), например так:

New-ManagementRoleAssignment -Name <assignment name> -SecurityGroup < USG> -Role <role name> -RecipientRelativeWriteScope < MyDistributionGroups | Organization | Self >

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

Заключение

В конце давайте подведем итог и закрепим основные понятия:

Роль (Role) – определяет набор командлетов и параметров, которые могут быть запущенны внутри неё. Это угол треугольника, который определяет Что именно пользователь можете сделать. В PowerShell – ManagementRole.

Запись роли (Role Entry) – индивидуальная запись для роли, которая определяет командлет и параметр этой роли. Это именно та часть, которую нужно редактировать, когда вы хотите тонко настроить права роли. В PowerShell – ManagementRoleEntry.

Группа ролей (Role Group) – это группа безопасности, которая определяет Кто принадлежи конкретной роли или области. Это угол треугольника, который обозначает кто именно может выполнять указанные выше действия. В PowerShell – RoleGroup.

Область (Scope) – область определяет объекты Где находятся объекты, на которые накладывает свое действие определенная роль. Область определяет Где роль может работать. В PowerShell – ManagementScope.

Назначение ролей (Role Assignment) – это объект AD, который связывает вместе все 3 угла треугольника, т.е. объекты Кто, Что и Где. В PowerShell – ManagementRoleAssignment.

RBAC это очень обширная и не простая тема. В этой статье я лишь хотел изложить её основы, чтобы вы начали смотреть на эту технологию с правильной точки зрения. Главное, когда планируете политику RBAC, не забывайте о том, что это треугольник, в центре которого Role Assignment.

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

На этом теоретическая часть закончена, более подробную информацию про RBAC вы можете получить в библиотеке TechNet по адресу - http://technet.microsoft.com/en-us/library/dd297943.aspx, также есть и русская справка вот тут - http://technet.microsoft.com/ru-ru/library/dd297943.aspx, но лично я рекомендую использовать английскую, т.к. в русской очень легко запутаться и не правильно понять суть написанного.

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