Управление доступом на основе ролей в Exchange 2010 (часть 1)

OSzone.net » Microsoft » Exchange Server » Exchange Server 2010/2013 » Управление доступом на основе ролей в Exchange 2010 (часть 1)
Автор: Нейл Хобсон
Иcточник: www.msexchange.ru
Опубликована: 29.09.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 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:

Заключение

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


Ссылка: http://www.oszone.net/13276/Exchange-2010