Главная Exchange/UC, Без рубрики, Новое Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010
  • Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010

    loo

    До выхода 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 следующим образом:

    image

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

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

    image

    Рис.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

    image

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

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

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

    Get-ManagementRoleEntry "Mail Recipients\*"

    image

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

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

     

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

    Пример

    Описание

    *\*

    Возвращает список всех записей роли для всех ролей.

    *\Set-Mailbox

    Возвращает список всех записей роли, которые содержат командлет Set-Mailbox.

    Mail Recipients\*

    Возвращает список всех записей роли в роли получателей почты.

    Mail Recipients\*Mailbox

    Возвращает список всех записей роли в роли получателей почты, оканчивающихся на Mailbox.

    My*\*Group*

    Возвращает список всех записей роли, которые содержат строку Group в имени командлета, для всех ролей, начинающихся с My.

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

    image

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

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

    New-ManagementRole –Name “New Databases” – Parent “Databases”

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

    1. Вы можете создавать дочерние роли для уже дочерних ролей.

    2. Дочерняя роль НЕ может обладать большими полномочиями, чем родительская, даже если родительская роль сама является дочерней.

    3. У каждой роли должно быть минимум одно разрешение.

    4. Перед удалением роли необходимо вручную удалить все её разрешения.

    5. У вас должно быть право выполнять Get-командлеты для этой роли.

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

    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 КТО?

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

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

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

    image

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

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

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

    12 3

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

    Чтобы создать новую группу ролей нужно воспользоваться командлетом New-RoleGroup:

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

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

    Add-RoleGroupMember “Group new databases” -Member user1

    image

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

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

    image

    Рис.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*

    image

    Рис.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), с дополнительными атрибутами.

    clip_image001

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

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

     

    Алексей Богомолов

Комментарии

  1. Спасибо за статью. В Избранное.

  2. 5+… Вот так надо писать… Образец просто…

  3. Рад, что понравилось, надеюсь пригодится.

  4. Алексей, спасибо за хорошую статью на интересную тему!

  5. Обещанное продолжение тут – http://itband.ru/2010/04/rbac-2/

  6. Алексей, благодарю вас данную статью и вообще за все труды.
    Благодаря вам многое для меня становится понятней:)