Обсуждение системы управления доступом в Exchange на основе ролей Role-Based Access Control (RBAC) неизбежно погружает в сон даже самых преданных поклонников Exchange. Возможно, это вызвано моим стилем описания данной технологии, возможно, механизмы управления сами по себе не особенно увлекательная тема, а возможно, скучен способ реализации технологии RBAC корпорацией Microsoft. В любом случае инструмент под названием RBACManager на сайте CodePlex — это ключ к пониманию RBAC.

До выхода Exchange 2010 управление объектами Exchange осуществлялось на основе списков управления доступом системы Windows Access Control Lists (ACL) и записей управления доступом Access Control Entries (ACE). Достоинство этого подхода заключалось в том, что он использовался и в самой системе Windows, так что, если вы хорошо понимали, как списки ACL работают в Windows, вам было проще разобраться, как это устроено в Exchange. Недостаток же состоял в том, что списки ACL были довольно грубым механизмом управления, который подходит для настройки доступа пользователей к таким объектам, как файлы, но менее эффективен для Exchange.

Разработчики Microsoft решили коренным образом все изменить в Exchange 2010 и заменили списки ACL управлением доступом на основе ролей (RBAC). История RBAC восходит к 1992 году (http://csrc.nist.gov/groups/SNS/rbac/) и повторялась во многих других компьютерных системах. Идея, по сути, проста: необходимо определить в системе роли (например, пользователь или администратор), а затем задать набор действий, которые может выполнять каждая из них (например, создание почтовых ящиков или настройка транспортных параметров). Каждое действие очень детализировано, оно управляет тем, что может делать держатель роли, поэтому вы организуете «группы роли», представляющие полный набор действий, доступных для выполнения держателем роли, такие как «Отслеживание сообщений» или «Перемещение почтовых ящиков».

Это как раз то, что предусмотрено в RBAC для Exchange. Группы ролей управления содержат наборы задач, которые можно назначить отдельным пользователям. Задачи представлены в виде команд PowerShell. При этом могут быть разрешены или запрещены какие-то отдельные параметры команд. Аналогичный подход используется для предоставления пользователям возможности работать с Exchange, то есть для предоставления доступа к почтовым ящикам или обновления пользовательских параметров (настроек).

RBAC поддерживается в Exchange 2010, Exchange 2013 и Exchange Online. В Exchange 2013 работать с RBAC проще, чем в Exchange 2010, благодаря наличию в разделе управления разрешениями центра администрирования Exchange Administration Center (EAC) удобного графического интерфейса. Exchange Online поддерживает такой же интерфейс, однако природа Office 365 такова, что группы ролей управления и доступные администраторам команды совершенно различны.

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

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

Все это в итоге привело меня к проекту CodePlex под названием «RBAC Manager R2 для Exchange 2010 SP2, Exchange 2013 Preview и Office 365» (https://rbac.codeplex.com/). Текущая версия продукта — 1.5.5.1, а его код не обновлялся с сентября 2012 года (поэтому для Exchange 2013 и указан его предварительный выпуск, Preview).

. Она легко устанавливается (всего один исполняемый файл и один файл настроек) и работает при условии, что на сервере или рабочей станции установлен компонент. NET Framework 3.5. Утилита отлично работает с Exchange 2013 CU8, однако чуть хуже с Office 365, возможно, из-за привлечения дополнительных ресурсов, необходимых для извлечения данных для RBAC от служб Office 365.

RBAC Manager особенно полезен, когда дело касается навигации по группам ролей, назначениям и соответствующим командам. Приведенный в статье экран демонстрирует полный набор групп ролей из развернутой мной корпоративной версии организации Exchange 2013, включая добавленные и специально настроенные группы ролей (например, выделенная курсором в левой части окна группа ролей Help Desk Level 2). На экране видны назначенные данной группе роли, включая управление списками рассылки, адресатами и экспортом/импортом почтовых ящиков (роль, которая должна быть назначена до разрешения экспорта или импорта из PST-файлов). Также здесь видны учетные записи пользователей, являющиеся членами данной группы. Словом, вы видите, что данный инструмент обеспечивает в целом очень удобную навигацию.

 

Окно RBAC Manager
Экран. Окно RBAC Manager

Кроме того, RBAC Manager позволяет создавать новые группы ролей и работать с другими компонентами RBAC, например обеспечивает удаление из команды какого-либо параметра или задание новой области для роли RBAC. Как и в случае с любым другим инструментом, вам потребуется определенное время, чтобы оценить возможности RBAC Manager, однако оно будет потрачено не впустую, если вам нужен удобный инструмент для облегчения процесса управления ролями RBAC.

Очень жаль, что эта утилита пребывает без изменений с сентября 2012 года. Codeplex предоставляет доступ к исходному коду на C# (https://rbac.codeplex.com/SourceControl/latest) для всех, кто уверен в своих силах, чтобы влиться в незнакомый ранее проект, однако было бы лучше обновить первоначальный код, особенно в той части, которая относится к работе с Exchange Online.