вторник, 17 мая 2011 г.

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

До выхода 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.
Возвращает список всех записей роли, которые содержат строку 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
image
Рис.6: Добавление дочерней роли.
Все роли управления, образованные от родительской встроенной роли управления, относятся к одному типу роли. Типы ролей управления также представляют собой максимальный набор командлетов и их параметров, который можно добавить в роль, связанную со определенным типом.
Типы ролей управления делятся на следующие категории.
  • Администратор или специалист (Administrative or specialist)   Роли, связанные с типом ролей администратора или специалиста, имеют более широкую область влияния в организации Exchange. Роли этого типа позволяют выполнять такие задачи, как управление сервером или получателями, настройка организации, администрирование в соответствии с требованиями, аудит и другие.
  • Ориентированные на пользователя (User-focused)   Роли, связанные с типом ролей, ориентированных на пользователя, имеют область влияния, привязанную к одному пользователю. Роли этого типа позволяют выполнять такие задачи, как настройка профиля пользователя и самоуправление, управление пользовательскими группами рассылки и другие.
    Имена ролей, связанных с типами ролей, ориентированных на пользователя, и имена типов ролей, ориентированных на пользователя, начинаются с My.
  • Специальность (Specialty)   Роли, связанные с типом ролей специальности, позволяют выполнять задачи, не относящиеся к типам административных или ориентированных на пользователя ролей. Роли этого типа позволяют выполнять такие задачи, как олицетворение приложения (application impersonation) и использование сценариев и командлетов, не относящихся к Exchange.
Теперь, когда мы знаем что именно сможет делать пользователь, можно переходить к следующему вопросу и указать на самого пользователя.
Часть 2

3 комментария:

Анонимный комментирует...

Алексей,
Новые роли, можно создавать только как дочерние? Или есть способ, создать "корневую" роль?

"Для начала, нужно удалить все разрешения, кроме одного:
Get-ManagementRoleEntry “New Databases\*” | where {$_.name –ne “Get-Recipient”} | Remove-ManagementRoleEntry" - зачем нужно оставлять это разрешение?

Анонимный комментирует...

Кажется понял :), задача "очистить" роль от "лишних" командлетов, но роль не может быть пустой и поэтому нужно оставить ЛЮБОЕ разрешение.

Ход моих мыслей верный?

Алексей Богомолов (Alexx) комментирует...

Да, т.к. в пункте 3 я указал, что "3. У каждой роли должно быть минимум одно разрешение."

Отправить комментарий