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

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

Заключение

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