Контроль доступа на основании ролей в Exchange 2010

Введение

В Exchange 2000 и Exchange 2003 разрешения выдавались через мастер делегирования Delegation Wizard, который располагался в консоли Exchange System Manager. Этот мастер позволял администратору присвоить одну из трех ролей пользователю, которому был нужен административный доступ. Вот эти три роли: Exchange View-Only Administrator, Exchange Administrator и Exchange Full Administrator. И хотя выдача пользователям этих ролей давала возможность разграничить уровни доступа, основная проблема при этом состояла в том, что для многих организаций такого разграничения было недостаточно. К примеру, хотя можно было дать разрешения на уровне корпоративной или административной групп, давать доступ к отдельным серверам было невозможно; если администратор получал доступ на уровне административной группы, он получал доступ ко всем серверам Exchange, относящимся к данной группе.

Ситуация с детализацией разрешений в Exchange 2007 улучшилась. Роль Exchange Full Administrator, которая была в Exchange 2000 и Exchange 2003, а теперь в Exchange 2007 называется Exchange Organization Administrator, по-прежнему дает администраторам полный доступ ко всем объектам Exchange во всей организации. Роль Exchange View-Only Administrators также осталась, обеспечивая администраторам разрешение на чтение во всей организации Exchange. В Exchange 2007 появились еще три эффективные роли:

• Exchange Recipient Administrator - Позволяла администраторам модифицировать настройки Exchange, касающиеся пользователей, групп, контактов и общих папок
• Exchange Public Folder Administrator - Была введена в Exchange 2007 Service Pack 1, и, согласно своему названию, позволяла администраторам контролировать общие папки
• Exchange Server Administrator - Позволяла администраторам полностью управлять определенным сервером Exchange 2007 в случае, если они также являлись членами локальной группы Administrators на этом сервере

Хотя модель разрешений в Exchange 2007 и представляла собой значительное улучшение по сравнению с моделями из предыдущих версий Exchange, она все еще не могла удовлетворить различным административным сценариям, возникающим в различных организациях. В сущности, роли в Exchange 2007 все еще давали слишком много власти администраторам в децентрализованной организации Exchange, что делало сложной задачу ограничения доступа для конкретных администраторов. И хотя существовала возможность реализации модели разделенных разрешений в Exchange 2007 при помощи списков контроля доступа (Access Control List - ACL), это было сложной процедурой, которая часто приводила к ошибкам и трудноразрешимым проблемам.

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

Модель RBAC

Модель разрешений, используемая в Exchange 2010, называется Role Based Access Control (RBAC – контроль доступа на основании ролей). Суть RBAC в том, что она позволяет очень точную настройку, вследствие чего вы легко сможете контролировать уровень доступа для пользователей и администраторов. Например, если у вас есть служба техподдержки, которой нужно управлять квотами почтовых ящиков, модель RBAC позволяет это реализовать.

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

Первый важный принцип в RBAC состоит в том, что есть три различных способа выдачи разрешений:

• Группы управляющих ролей
• Политики назначения управляющих ролей
• Прямое делегирование ролей пользователям

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

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

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

Группы управляющих ролей

В Exchange 2010 Microsoft значительно упростила задачу выдачи обычных наборов разрешений администраторам и специализированным пользователям, создав заранее 11 групп управляющих ролей по умолчанию. Поместив пользователя или группу в группу управляющих ролей, вы назначаете роли, связанные с данной группой управляющих ролей, выделив этому пользователю или группе необходимые разрешения. Microsoft использует термин role holder(носитель роли) для обозначения администратора или специализированного пользователя, добавленного в группу управляющих ролей. Эти 11 групп управляющих ролей по умолчанию создаются при установке Exchange 2010. Точнее, эти группы управляющих ролей создаются тогда, когда в процессе установки Exchange 2010 производятся действия по подготовке Active Directory, которые можно выполнить отдельно, запустив программу установки Exchange 2010 setup.com с ключом /PrepareAD. На группы управляющих ролей можно посмотреть в организационной единице Microsoft Exchange Security Groups Organizational Unit (OU), создаваемой в корневом домене в процессе установки Exchange. Эта OU и входящие в нее группы показана на Рисунке 1. Обратите внимание, что из 16 групп, показанных на Рисунке 1, только 11 являются группами управляющих ролей; они отмечены специально.

Рисунок 1: Группы управляющих ролей по умолчанию

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

• Delegated Setup - Члены этой группы управляющих ролей получают возможность запускать программу установки Exchange 2010, и, следовательно, развертывать, но не устанавливать новый сервер Exchange 2010. Развертывание можно осуществлять только на тех серверах, которые уже получили разрешения от администратора с дополнительными полномочиями.
• Discovery Management - Участник группы Discovery Management имеет возможность выполнять поиски по всем почтовым ящикам в организации Exchange, а также включать функцию Legal Hold в Exchange 2010. Подробнее эту группу мы рассмотрим позднее в нашем цикле статей.
• Help Desk - Члены группы Help Desk получают полномочия, обычно нужные для службы техподдержки, например, модификация данных о пользователях, такие как: адрес и номер телефона.
• Hygiene Management - Эта группа управляющих ролей используется для обеспечения полномочиями, связанными с управлением и настройкой антивирусного и антиспамового элементов в Exchange 2010.
• Organization Management - Группа Organization Management аналогична административной роли Exchange Full Administrator в Exchange 2003 и роли Exchange Organization Administrator в Exchange 2007. По сути, членство в этой группе дает пользователю право почти любую задачу в Exchange 2010 за исключением некоторых, основной среди которых является возможность осуществлять поиск по почтовым ящикам; которую можно получить через группу Discovery Management.
• Public Folder Management - Эта группа управляющих ролей дает возможность своим членам управлять средой общих папок.
• Recipient Management - Участник этой группы может создавать и модифицировать получателей Exchange.
• Records Management - Группа Records Management дает возможность своим членам контролировать и настраивать функции соответствия в Exchange 2010. Примеры подобных функций включают транспортные правила, настроенные на сервере Hub Transport, а также классификации сообщений в Outlook.
• Server Management - Эта группа управляющих ролей предоставляет возможность управлять всеми серверами Exchange в организации. Полномочия, получаемые участниками этой группы работают, таким образом, на уровне конфигурации сервера, находящейся в консоли Exchange Management Console, и не работают, скажем, на организационном уровне, находящемся в консоли Exchange Management Console.
• UM Management - Согласно своему наименованию, данная группа управляющих ролей дает возможность управлять всеми аспектами среды Unified Messaging.
• View-Only Organization Management - Эта группа позволяет своим членам просматривать конфигурацию любого элемента в организации Exchange.

Участие в группе ролей управления

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

Давайте начнем с рассмотрения команд Exchange Management Shell, необходимых для управления принадлежностью к группам ролей управления, и того, как можно контролировать принадлежность к группе роли Discovery Management. По умолчанию эта группа не содержит участников.

Команда Add-RoleGroupMember используется для добавления участников в эту группу. Таким образом, чтобы добавить пользователя 'Neil' в группу роли Discovery Management, нужно использовать следующую команду:

Add-RoleGroupMember 'Discovery Management' 'Member Neil

Подобно этому, можно легко удалять участников из группы ролей управления с помощью команды Remove-RoleGroupMember. Чтобы удалить добавленного нами пользователя, воспользуемся следующей командой:

Remove-RoleGroupMember 'Discovery Management' 'Member Neil

Обратите внимание, что команда Remove-RoleGroupMember без 'Confirm параметра со значением $false приведет к тому, что Exchange Management Shell запросит у вас подтверждение на удаление, поэтому следует учитывать данный факт, используя эту команду в сценарии.

Если вы в какой-то момент захотели получить список членов группы Discovery Management, используйте команду Get-RoleGroupMember, как показано на рисунке 2.

Рисунок 2: Команда Get-RoleGroupMember

Наконец, также есть полезная команда Update-RoleGroupMember, которую можно использовать для изменения принадлежности к группам ролей управления. Допустим, пользователь Neil уже является участником группы роли Discovery Management, как видно из рисунка 2. Если нам потребуется добавить двух новых участников, Mark и Rob, в группу ролей управления, и в то же время удалить существующих в ней участников, команду Update-RoleGroupMember можно использовать следующим образом:

Update-RoleGroupMember 'Discovery Management' 'Members Mark,Rob 'Confirm:$false

Результаты команды показаны на рисунке 3, где показана принадлежность к группе ролей управления до и после выполнения команды Update-RoleGroupMember.

Рисунок 3: Обновление принадлежности к группе ролей управления

Роли управления

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

Для начала нужно понять, что группа ролей управления представляет собой группу, в которой имеется одна или несколько ролей управления. Для просмотра свойств этой группы ролей управления, которые будут включать информацию о том, какие роли назначены для этой группы, нужно воспользоваться Get-RoleGroup командой для соответствующего имени группы и обработать результаты в команде форматирования списка (сокращенно 'fl'). Например:

Get-RoleGroup 'Discovery Management' | fl

Результаты этой команды показаны на рисунке 4.

Рисунок 4: Результаты команды Get-RoleGroup

На рисунке 4 видно, что с группой роли Discovery Management связаны несколько интересных параметров, но на данный момент нас интересует параметр ролей (Roles) , который является четвертым параметром в списке на рисунке 4. Параметр Roles показывает, что группе роли Discovery Management назначены роли управления Legal Hold и Mailbox Search. Это две встроенные роли управления, которые идут с Exchange 2010. На момент написания этой статьи имелось 64 различных встроенных роли управления в Exchange 2010. Запустив команду Get-ManagementRole, можно получить весь список ролей, как показано на рисунке 5. Обратите внимание, что не все роли управления показаны на рисунке 5, поскольку результаты команды не влезли в снимок.

Рисунок 5: Стандартные роли управления

Любой пользователь, который добавлен в группу роли Discovery Management, получает роли управления Legal Hold и Mailbox Search. Вполне очевидно из названия этих ролей, что именно роль Mailbox Search дает пользователю возможность выполнять поиск в почтовых ящиках для юридических целей поиска информации. Сами роли управления содержат группу команд, которые позволено выполнять пользователю, являющемуся участником данной группы ролей управления. Эти команды называются записи ролей управления (management role entries) , и о них мы поговорим позже. А пока нам нужно рассмотреть то, что называется задания ролей управления (management role assignments) , которые показаны на рисунке 4 в результатах параметра RoleAssignments.

Задания ролей управления

Задания ролей управления представляют собой связи между группой ролей управления и ролями управления. Если вы взгляните на рисунок 4, вы увидите, что группа роли Discovery Management имеет два задания ролей управления:

• Legal Hold-Discovery Management
• Mailbox Search-Discovery Management

Поскольку мы рассматриваем элемент почтового поиска в группе управления, давайте вызовем свойства задания роли Mailbox Search-Discovery Management. Для этого используем команду Get-ManagementRoleAssignment:

Get-ManagementRoleAssignment 'Mailbox Search-Discovery Management' | fl

Результаты команды показаны на рисунке 6.

Рисунок 6: Свойства задания роли управления

Одним из ключевых моментов в задании роли управления является то, что оно может использовать границы управления. Более того, границу управления можно настроить по-разному для серверов и объектов получателей. В середине рисунка 6 видно, что атрибуты RecipientReadScope и RecipientWriteScope имеют значение Organization. Это означает, что границы этого задания роли управления для получателей составляют пределы всей организации Exchange, а не его подразделения (например). Конечно, этого и следовало ожидать, так как пользователям, принадлежащим к этой группе, потребуется возможность осуществлять поиск в почтовых ящиках всей организации.

На рисунке 6 также видно, что RoleAssignmentDelegationType атрибут имеет значение Regular, что означает, что задание роли Mailbox Search-Discovery Management является регулярным заданием. Регулярное задание роли управления означает, что (в данном случае) оно позволяет участникам группы роли Discovery Management получать доступ к записям роли управления, командам, связанным с ролью управления Mailbox Search. Другим типом задания роли управления является delegating задание роли управления, которое дает пользователям возможность назначать роли другим участникам группы. Для этих заданий роли управления атрибут RoleAssignmentDelegationType будет иметь значение DelegatingOrgWide.

Заключение

На этом завершаем вторую часть цикла статей, в которой мы рассмотрели связи между группами ролей управления, ролями управления и заданиями ролей управления. В третьей части мы завершим разговор рассмотрением записей ролей управления и конечного результата, посредством которого пользователь может выполнять поиск в почтовых ящиках, являясь участником группы Discovery Management.

 

Автор: Нейл Хобсон (Neil Hobson)

Нейл является основным консультантом в Silverslands (www.silversands.co.uk), Золотом партнере Microsoft в Великобритании и отвечает за разработку, применение и поддержку приложений для многих крупных клиентов по всей Европе. В IT отрасли он трудится с 1987 года и специализируется на отправке сообщений с 1995. Он начинал работать еще с Exchange 4.0. Он также обладает званием Exchange MVP и уделяет некоторую часть своего личного времени на помощь различным пользователям Exchange, ведет блоги, посвященные Exchange. Эти блоги вы можете найти по адресу www.msexchangeblog.com. С Нейлом можно связаться по адресу neil.hobson@silversands.co.uk.

Источник: https://www.Redline-Software.com

Возникли вопросы?

Обращайтесь на форум! Follow us