03.07.2010

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

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

До выхода 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, но лично я рекомендую использовать английскую, т.к. в русской очень легко запутаться и не правильно понять суть написанного.

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

CAPTCHA
автор сообщения
04-07-2010 15:53:51
поправьте падежное окончания в заголовки статью
0 |
E. Cartman
05-07-2010 07:08:44
Ахренеть. Не прошло и 20-и лет как в MS осолили RBAC.
0 |
фетиш-мастер [Малиновые штаны]
05-07-2010 10:03:34
Я считаю, что модель RBAC более правильно будет ассоциировать именно с треугольнокомтогда уж с пирамидой З.Ы. администрация. вам не стыдно постить картинки консоли? неужели трудно потратить 10 минут и насобачить цсс-ку для подобной ботвы? во-первых, выглядеть будет так же, во-вторых, будет более читабельно. или ждете готового решения от микрософта?
0 |
tecklord
05-07-2010 10:24:23
А причем тут админы то? Если автор пришлет не картинку, а текст, то мы его опубликуем. Стили не проблема сделать.
0 |
фетиш-мастер [Малиновые штаны]
07-07-2010 09:50:20
Стили не проблема сделать.предположим, я собираюсь застатеится на секлабе где можно посмотреть правила оформления консольного кода?
0 |