Управление доступом на основе ролей в Exchange Server 2010

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

К примеру, рассмотрим случай с маленькой компанией, в которой есть трое служащих, занимающихся бухгалтерией. Кто-то из них имеет право подписывать чеки, кто-то — погашать векселя и осуществлять другие бухгалтерские функции. Со стороны администратора было бы целесообразно назначить разрешения этим пользователям в Active Directory (AD) или даже в Microsoft Exchange Server напрямую. Но возьмем компанию, в финансовом департаменте которой 3000 сотрудников. Назначать индивидуальные разрешения такому числу пользователей — как каждому, так и в группах — не столь рационально, можно потерять контроль над ситуацией.

Как и в случаях со многими другими проблемами в компьютерной отрасли, решение данного вопроса длится уже почти 40 лет. Оперативные системы разделения времени компьютера, такие как OpenVMS и Multics, привнесли идею наделить разрешениями роль, а не пользователя. Например, если назначить разрешения на определенные объекты роли для оплаты счетов и затем предоставить пользователям эту заданную роль, будет проще отслеживать и проверять, какие пользователи наделены какими ролями. .

Exchange и RBAC

Создатели Exchange 2000 Server ввели в обиход концепцию заданных ролей Exchange. Роли Exchange Administrator, Exchange Full Administrator и Exchange View Only Administrator могут использоваться для передачи прав отдельным пользователям или группам. Само по себе это было отличной идеей, но такие роли были ограничены в силу возможностей их реализации. По сути, основных ограничений было два. Во-первых, роли не были в должной степени детализированы, что создавало трудности в установлении точных разрешений или при наделении ими многих пользователей. Во-вторых, средства управления Exchange опирались на Windows для аутентификации. А Windows не обеспечивала всем необходимым для RBAC инструментарием. Соответственно, Exchange мог только выполнять несколько проверок доступа, чтобы определить, наделена ли учетная запись пользователя одной из административных ролей.

Exchange 2010 в корне изменил ситуацию. Так же, как и в Exchange Server 2007, каждое действие, которое пользователь или администратор может осуществить в оболочке Exchange Management Shell (EMS), консоли Exchange Management Console (EMC) или в панели Exchange Control Panel (ECP), фактически вызывает одну из многих команд PowerShell. Механизм Exchange Role Based Access Control, (RBAC), позволяет администраторам следить за тем, какую из заданных команд PowerShell — и даже какой из параметров команды — отдельный пользователь может выполнить. Это совершенный отход от старой модели, поэтому необходимо сделать некоторые пояснения.

Основы RBAC

RBAC зависит от трех составляющих: управляющая роль (management role), группа управляющих ролей (management role group) и область действия (scope).

Управляющая роль указывает, что может быть сделано. Например, Exchange 2010 определяет роли для управления системой объединенных коммуникаций (UM), управления обнаружением и других административных операций. Пользователь, имеющий одну из этих ролей, может выбрать действие, соответствующее определению данной роли. В Exchange роль складывается из записей роли, каждая из которых определяет команды EMS или набор параметров, которые пользователь, поддерживающий эту роль, может выполнить. Exchange 2010 SP1 содержит определения для приблизительно 70 ролей: для переноса почтовых ящиков, работы с электронной почтой, управления электронной базой данных и т. д. Некоторые из этих ролей предназначены для администраторов, другие — исключительно для пользователей. К примеру, роль MyBaseOptions обычно приписана пользователям, поэтому они могут редактировать свои личные координаты, используя ECP. Чтобы получить список ролей, вы можете выполнить команду Get-ManagementRole с сервера Exchange 2010.

Группа управляющих ролей уточняет, кто может сделать что-либо. Эта терминология немного сбивает с толку. Вы можете подумать, что членство определяет роль, но на самом деле группа ролей определяет членство. Ролевые группы — это фактически группы безопасности Windows, которые сохраняются в организационной единице, organizational unit (OU), группы безопасности Exchange в AD. Вы можете видеть членство в группе, используя инструментарий, такой как оснастка Active Directory Users and Computers консоли Microsoft Management Console (MMC). Тем не менее вы не можете редактировать членство в группе «вручную». Членам группы присваиваются пользовательские атрибуты, которые наверняка будут повреждены, если вы будете редактировать их, используя оснастку Active Directory Users and Computers.

Область действия определяет набор объектов, где роль может выполнить действие. К примеру, вы можете указать область для данной роли в виде индивидуальной базы данных почтовых ящиков, сервера Exchange или OU. Области могут предоставить доступ к набору объектов на запись или чтение.

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

Важно помнить, что назначения RBAC применяются с использованием его собственного механизма, но не с помощью механизма Windows ACL. Обычно, если вы определили несколько наборов разрешений на ресурс, применяется наиболее ограниченный набор разрешений. Но если вы применяете RBAC, пользователь получает объединение всех ролей RBAC, к которым имеет доступ. Например, если вы назначите пользователю А две различные роли RBAC, он сможет использовать команды, заданные в каждой из этих ролей, а не только те, что принадлежат самому ограниченному набору.

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

Рисунок. Треугольник влияния

Назначения области, роли и ролевой группы связываются назначением роли. Специалисты Microsoft рекомендуют сначала определить область, роль, затем ролевую группу и в самом конце — назначение роли. Это модель, которой я здесь следую.

Области RBAC

Области роли определяют, где роль может применяться. Exchange характеризуется большим диапазоном областей. Чтобы помочь вам охватить его весь, я сперва обрисую различие между областями действия на чтение и на запись. Разницу усвоить легко: если объект находится внутри области роли чтения, владельцы роли смогут «прочитать» объект. На такой же концепции основана и область действия записи.

Роль разделяет области на чтение и на запись для получателя и конфигурации. Таким образом, каждая роль имеет область действия чтения и область действия записи получателя, а также области чтения и записи конфигурации. Встроенные в Exchange управляющие роли имеют скрытые области. Например, управляющая роль Public Folders имеет скрытые области чтения и записи получателя для Organization и скрытые области чтения и записи конфигурации OrganizationConfig. Это говорит о том, что кто-то, обладающий данной ролью, может читать и изменять объекты как получателя, так и конфигурации везде в организации. Помните: сама роль может ограничивать, какие заданные команды и параметры могут использоваться.

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

Organization — глобально по организации;
Self — разрешает доступ только к текущему почтовому ящику пользователя;
MyDistributionGroups — разрешает доступ только к группам доставки, принадлежащим текущему пользователю.

Области пользователя гораздо интереснее. Exchange поддерживает три различных типа областей пользователя:

OU — позволяет изменять объекты получателя в данной OU;
Recipient filter — позволяет установить фильтр получателя для отбора объектов, которые владельцу роли разрешается посмотреть или изменить;
Configuration — предоставляет доступ на чтение или запись для подмножества объектов из контейнера конфигурации.

Области конфигурации — наиболее сложные из этих трех типов. Они позволят вам, например, установить область баз данных почтовых ящиков, которая предполагает доступ владельцев роли только к подмножеству баз данных почтовых ящиков организации. Области конфигурации могут быть основаны на фильтрах, динамически отбирающих объекты, которые будут включены, или на списках, в которых вы уточняете набор объектов. Возможно, пример поможет уловить разницу. Следующая команда устанавливает область действия конфигурации, основанную на фильтре баз данных.

New-ManagementScope -Name "HQ
   Databases» -DatabaseRestrictionFilter
   {Name -eq "HQ*"}

Эта область действия будет содержать все базы данных в организации, чьи имена начинаются с HQ.

Допустим, затем нам нужно установить область действия, которая будет поддерживать только три конкретных транспортных сервера в сайте HQ.

Чтобы это сделать, можно использовать область списка:

New-ManagementScope -Name "HQ Hub
   Servers" -ServerList HQ-HT01, HQ-
   HT02, HQ-HT-SPARE

Вероятно, сейчас уже ясно, что вы создаете области, используя команду New-ManagementScope. Вы можете получить список заданных областей с помощью команды Get-ManagementScope и можете удалить области, не назначенные никакой роли, командой Remove-ManagementScope.

Роли

Определив нужные области, переходим к указанию ролей для них. Каждая роль устанавливает набор команд и параметров, которые разрешается использовать владельцам роли. Давайте рассмотрим простую роль.

Роль MyDisplayName разрешает пользователям изменять их собственные отображаемые имена через ECP. С помощью команды Get-Management RoleEntry можно увидеть конкретные записи, назначенные этой роли, как показано на экране 1.

Экран 1. Записи, назначенные роли MyDisplayName

Эта роль содержит две записи: одну для Set-User и одну для Set-Mailbox. Почему их две? Потому что каждая из этих команд может использоваться для изменения отображаемого имени пользователя. В общем случае вы увидите несколько похожих записей роли для любой операции, которая может быть выполнена не только одним способом. Многие команды (например, это касается Set-OWAVirtualDirectory) связаны с одной функцией, поэтому обычно похожих записей для них не бывает.

Как насчет более сложной роли? Роль унифицированного обмена сообщениями Unified Messaging — подходящий пример. На экране 2 показана часть того, что выглядит как результат Get-ManagementRoleEntry «Unified Messaging\*». Стоит обратить внимание на некоторые важные моменты, касающиеся данной управляющей роли. Прежде всего, в наличии должны быть списки для каждой из команд, относящихся к UM. Владелец роли может выполнить любую команду, которая определена в записи внутри роли, поэтому понятно, что все команды, относящиеся к UM, будут иметь здесь записи, так что обладатели роли смогут использовать их. Кроме того, каждая запись роли детально определяет набор параметров, к которым пользователь будет иметь доступ.

$Часть вывода от команды Get-ManagementRoleEntry «Unified Messaging\*»$

Экран 2. Часть вывода от команды Get-ManagementRoleEntry «Unified Messaging\*»

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

Обратите внимание на вывод следующей команды:

Get-ManagementRoleEntry «Unified
   Messaging\Set-UMDialPlan» | select
   parameters | fl

На экране 3 показан результат. Заметим, что некоторые из этих параметров представляют собой аргументы команды, тогда как другие (такие, как Confirm, DomainController и Debug) являются общими переключателями PowerShell, которые не относятся к этой единичной команде. Одно из достоинств RBAC заключается в том, что вы можете контролировать доступ к отдельным параметрам, передаваемым команде. Вот как это будет выглядеть.

$Результат работы Get-ManagementRoleEntry «Unified Messaging\Set-UMDialPlan» | select parameters | fl$

Экран 3. Результат работы Get-ManagementRoleEntry «Unified Messaging\Set-UMDialPlan» | select parameters | fl

Оболочка EMS интерпретирует записи роли, когда вызывается на инициализацию для конкретного пользователя. Она загружает команды, определенные для записи роли одной из ролей, назначенных пользователю. Если данная команда не имеет соответствующей записи роли, она не загружается. EMC и ECP скрывают или отключают интерфейс пользователя для команд, которые признаны отсутствующими во время инициализации.

С таким разнообразием встроенных ролей у вас хорошие шансы найти роль, которая будет отвечать вашим требованиям. Если же нет, вы можете создать новую роль, основанную на одной из уже существующих, а затем «настроить» ее, добавляя или удаляя команды и параметры.

Вы можете создавать новые роли «на заказ» только посредством наследования, а не с нуля. Из-за этого ограничения у дочерней роли не будет больше прав, чем у ее родителя, так что вы свободно можете что-то удалять из родительской роли. К примеру, вы захотели создать особую роль, которая бы разрешала ее обладателям UM изменять только PIN для выбранных почтовых ящиков. Самый простой способ это сделать — создать новую роль, основанную на существующей роли UM Mailboxes, а затем удалить команды, которые вам не нужны.

Итак, в первую очередь создаем новую особую роль командой New-ManagementRole:

New-ManagementRole -name "UM PIN
   Reset» -parent "UM Mailboxes"

После создания новой роли, запустив Get-ManagementRoleEntry для новой роли, вы получаете доступ к нескольким командам, которые вам не нужны, включая Set-UMMailbox, Set-ADServer Settings и Set-MailboxJunkEmail Configuration. Это не обязательно плохо, потому что каждая запись роли ограничивает пользователей заданным набором элементов. Тем не менее, если вы захотите сократить их, вы можете это сделать, удалив почти все записи роли. Но вы не можете удалить их все! Если это сделать, роль станет бесполезной. Следующая команда дает нужный результат:

Get-ManagementRoleEntry "UM PIN
   Reset\*" | where {$_.Name -ne
   "Get-UMMailboxPIN"} | Remove-
   ManagementRoleEntry

Этот пример оставляет запись роли Get-UMMailboxPIN нетронутой. Важно понимать, что у вас не будет записи роли для команды Set без соответствующей команды Get. В данном случае это означает, что вам нужно восстановить запись роли Set-UMMailboxPIN:

Add-ManagementRoleEntry "UM PIN Reset\
   Set-UMMailboxPIN" -parameters
   LockedOut, NotifyEmail, Pin,
   SendEmail

Ролевая группа

Сами ролевые группы достаточно ясны. Команда Get-RoleGroup показывает 11 встроенных ролевых групп, описанных в таблице.

Таблица. Exchange Server 2010: встроенные ролевые группы

Если вы следуете рекомендациям Microsoft и соблюдаете последовательность действий, используя RBAC, следующий шаг — определить ролевую группу — выполнить просто, потому что вы уже определили «где» (область) и «что» (роль и ее записи), которые вам понадобятся. Определение группы позволит установить, кто готов к работе с заданной областью с определенными целевыми объектами.

Вы можете создать новую ролевую группу с помощью команды New-RoleGroup. Эта команда требует, чтобы было задано имя группы и одна или более ролей. Также по желанию вы можете определить область действия для группы. Это позволит определить роли и назначить область ролевой группе, у которой более ограниченная область, чем у оригинальной образующей роли. Однако помните, что пользователи в ролевой группе получат доступ ко всем командам и параметрам, которые разрешены в соответствии с любой ролью в группе. Если область не назначена, для роли используется область по умолчанию.

На примере с UM дальше можно показать, как создать ролевую группу для управления UM PIN:

New-RoleGroup "UM PIN Managers" -roles
   "UM PIN Reset"

Вы можете назначить участников ролевой группы, используя переключатель участников:

New-RoleGroup "UM PIN Managers"
   -roles "UM PIN Reset" -members
   paulr, brianh, davidw

Также можно использовать псевдоним или адреса SMTP для назначения членства.

Назначения ролей

Добавление переключателя member в команду New-RoleGroup выполняет назначения управляющей роли. А что если, следуя модели Microsoft, вам понадобится создать назначения управляющих ролей отдельно?

Выполняя назначение управляющих ролей, вы связываете роль с областью действия, а также с группой ролей или пользователем. Вы можете убедиться в этом, сделав следующее. Введите команду Get-ManagementRole Assignment, используйте команду New-Management Role Assignment, чтобы создать новое назначение, затем выполните Get-ManagementRole Assignment снова. Вы заметите, что новая запись добавлена. Exchange 2010 SP1 содержит 164 управляющие роли. Таким образом, когда вы создаете новые назначения, вы можете увидеть, что они добавлены в нижнюю часть списка.

Назначения встроенных ролей в названиях следуют простому образцу: Role — Role Group (Message Tracking — Records Management). Команда Get-ManagementRoleAssignment позволяет увидеть детали назначения, заданной роли, передавая ее имя. Вывод команды покажет, какие роли назначены, какие области действительны для назначения и даст другую полезную информацию для назначения роли.

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

Политики назначения ролей

Вы можете не только явно разрешить пользователям назначать роли, но и дать им соответствующий уровень доступа, обусловленный функцией Exchange 2010, от которой зависят политики назначения роли. Политика назначения роли задает назначения ролей, которые вы хотели бы связать с группой пользователей. Exchange включает в себя политику назначения ролей по умолчанию, предоставляющую пользователям право изменять их личную информацию; политика по умолчанию применяет роли MyBaseOptions, MyContactInformation, MyProfile Information, MyVoiceMail, MyText Messaging, MyDistributionGroup-Membership и MyDistributionGroups ко всем пользователям.

Достоинство этой системы в том, что, добавляя или удаляя роли в данной политике, вы контролируете возможности пользователя в ECP. Вы также можете определить новые политики назначения ролей и изменить политики назначения ролей по умолчанию, применяемые к пользователям, чтобы они получили в точности такой доступ, который вы хотели бы им предоставить. Для этого нужно создать политику назначения ролей и воспользоваться командой Set-Role AssignmentPolicy вместе с переключателем IsDefault. Дополнительно вы присваиваете политики назначения управляющих ролей новым почтовым ящикам, когда создаете или разблокируете их с помощью команд New-Mailbox или Enable-Mailbox. Используя команду Set-Mailbox, вы присваиваете новую политику назначения ролей существующим почтовым ящикам.

RBAC и Exchange Control Panel

До сих пор я подробно рассказывал об использовании EMS, чтобы показать, как управлять объектами RBAC. В Exchange 2010 SP1 специалисты Microsoft добавили поддержку для некоторых операций RBAC в панель ECP. Это значительный шаг вперед, потому что он делает RBAC гораздо более легким в доступе и управлении для обычного администратора.

Когда вы открываете ECP с учетной записью, имеющей роль Organization Management, вы видите ссылку с именем Roles & Auditing в навигационной панели. Нажмите на эту ссылку, и вы увидите два незнакомых значка на всей панели деталей для Administrator Roles и User Roles, как показано на экране 4. Средства управления для Administrator Roles позволяют просматривать, изменять и определять ролевые группы для административного доступа. Соответствующие средства управления для User Roles дают те же возможности для политик назначения ролей для пользователей.

Экран 4. Интерфейс Exchange Control Panel для просмотра, управления и назначений ролей

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

Создавая новую ролевую группу, вы определяете имя, набор ролей, который она будет содержать, и участников, которых вы хотите включить в ролевую группу, как показано на экране 5. Вы не можете удалять команды или изменять назначенный набор параметров здесь, поскольку не в состоянии изменять содержание ролей, которые назначаете. Следовательно, при использовании данной функции вам необходимо продумать, какие возможности вы хотели бы видеть у участников ролевой группы.

Экран 5. Создание новой ролевой группы в Exchange Control Panel

Инструменты User Roles в ECP позволяют видоизменять политику назначения ролей по умолчанию или создавать новую. С другой стороны, когда вы изменяете или создаете политику назначения ролей, вы видите диалоговое окно, похожее на показанное на экране 6. Вы можете управлять доступом пользователей к каждой из встроенных ролей «My». Например, я создал политику, позволяющую пользователям управлять наибольшим количеством аспектов их учетных записей, но не собственностью их группы распределения или их членством. Дополнительно некоторые возможности, к которым, с моей точки зрения, нежелательно пользователям иметь доступ (такие, как право управлять установками пересылки текста), блокируются. Это похоже на политику по умолчанию, которую использует Microsoft для собственных операций Exchange.

Экран 6. Страница изменения политики назначения роли

Новый способ управления

RBAC — это устоявшаяся технология, которая, однако, будет совершенно новой для многих администраторов Exchange. Она несколько обескураживает при первом сравнении с другими технологиями Exchange, отчасти потому, что функции Exchange 2010, такие как группы доступности баз данных database availability groups (DAG), основаны на вещах, вполне нам понятных, включая базы данных почтовых ящиков. RBAC с этой точки зрения — новая технология.

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

Поль Робишо (getting-started@robichaux.net) — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT