До выхода 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”
Есть несколько вещей, которые должен знать администратор при создании дочерних ролей:
- Вы можете создавать дочерние роли для уже дочерних ролей.
- Дочерняя роль НЕ может обладать большими полномочиями, чем родительская, даже если родительская роль сама является дочерней.
- У каждой роли должно быть минимум одно разрешение.
- Перед удалением роли необходимо вручную удалить все её разрешения.
- У вас должно быть право выполнять 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
-SecurityGroup < USG> -Role -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 набор ролей, групп, областей и назначений предоставляет необходимый и достаточный функционал делегирования, при этом позволяя гибко изменять его под свои нужды.
