Те, кто пробовал работать с Windows Server 2003, вероятно,  сталкивались с новой оснасткой менеджера авторизации Authorization Manager консоли Microsoft Management Console (MMC) для управления Active Directory (AD). Менеджер авторизации - это попытка Microsoft ввести управление доступом на основе ролей для приложений, запускающихся под Windows. Менеджер авторизации был включен в Release Candidate 1 (RC1) Windows Server 2003. Эта концепция получила название RBAC-модель (Role-Based Access Controls model). Сотрудники института National Institute of Standards and Technology (NIST) Дэвид Феррайоло и Ричард Кун впервые описали концепцию ролевого управления доступом (RBAC) в 1992 году в статье "Role-Based Access Controls", которую можно получить по адресу http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html. Далее я объясню основные концепции модели RBAC и покажу ее отличие от других моделей управления доступом. Мы рассмотрим, как Microsoft использует Authorization Manager для реализации принципов модели RBAC.

Модель RBAC

До 1992 года большинство платформ и поддерживаемых ими приложений использовали либо модель принудительного управления доступом (mandatory access control, MAC), либо модель с управлением доступом по усмотрению пользователя (discretionary access control, DAC). Две модели описаны в документе Trusted Computer Security Evaluation Criteria (TCSEC), который опубликовало для использования Министерство обороны США в 1985 году. Из этих двух моделей более общая - DAC -  используется во многих коммерческих операционных системах, включая Windows 2000 Server и Windows NT.

В модели DAC управление доступом к ресурсам остается на усмотрение пользователей. Такой децентрализованный подход позволяет предоставлять или отменять доступ к любому объекту и ресурсу, которые находятся под непосредственным управлением пользователя (т.е. пользователь является собственником объекта или ресурса). Таким образом, в этой модели пользователь управляет доступом к объектам и ресурсам без участия системного администратора.

Модель MAC представляет более централизованный подход к управлению доступом. В этой модели полномочия и разрешения доступа к ресурсам предоставляются и удаляются централизованно. Такое управление обеспечивает каждому объекту свой индивидуальный уровень разрешений и маркирует ресурсы в соответствии с уровнем доступа в соответствии с установленным для них уровнем авторизации. Структуры, в которых головному предприятию необходимо запретить неконтролируемый информационный поток от организаций высшего уровня к организациям низшего уровня, часто используют такой тип централизованного контроля доступа. Поскольку Microsoft пока не обеспечила какого-либо коммерческого варианта поддержки MAC -модели, мы ограничимся сравнением моделей RBAC и DAC. Отличия RBAC и DAC-моделей перечислены в Таблице 1.

Ключевой компонент модели RBAC - организационная роль пользователя, которая определяет его обязанности, возможности и ограничения. DAC-модель ориентирована в основном на ресурсы и объекты. С административной точки зрения, управление контролем доступа, основанное непосредственно на ролях, более естественно. Трансляция организационной модели (основанной на ролях пользователей) в объектно-центрическую (основанную на правах доступа к ресурсам) представляет для администраторов, работающих по модели DAC, более сложную задачу.

Модель RBAC - специальный тип группы управления доступом; она  связана с набором задач, которые пользователь или группа пользователей могут выполнять в рамках конкретной организации. Однако роль существенно отличается от группы. Группы, как мы их представляем в модели DAC, облегчают управление контролем доступа на уровне ресурса, позволяя задать и поддерживать управление доступом для групп, а не для отдельных пользователей. Роль, напротив, подразумевает набор разрешений на доступ к ресурсу, которые основаны на определениях роли (т.е. отношениях роли к поставленной задаче и отношениях роли к операции, которую нужно выполнить). Чтобы определить те задачи или операции, которые пользователь имеет право выполнить, достаточно знать только роль пользователя. Узнавать о наличии разрешения на доступ к различным ресурсам во время обращения к ним, как в модели DAC, не требуется.

Подтверждение и проверка присвоенных разрешений доступа и принудительное их применение - другая область, в которой модели DAC и RBAC имеют существенные различия. В модели RBAC приложение, поддерживающее роли, осуществляет запрос к базе данных политик RBAC или к связанной с ней службе управления доступом, выясняя, имеет ли пользователь права на выполнение данного действия. В модели DAC децентрализованное подтверждение доступа и проверка разрешений доступа к ресурсу происходит на уровне DAC-ориентированного приложения или самого ресурса. Например, в Windows NT сущность объекта "локальный компьютер", известная как монитор ссылок security reference monitor (SRM), сравнивает содержимое маркеров доступа пользователя со списком контроля доступа объекта (ACL), чтобы определить, имеет ли пользователь права доступа к выбранному объекту.

Централизованное подтверждение и контроль разрешений доступа - существенное преимущество, потому что в большинстве организаций ресурсы и защищаемые информационные объекты поддерживают политику безопасности, которая обычно определяется на самом высоком уровне организации. Поддержка такой политики требует от информационной системы способности централизованно управлять и контролировать права доступа. Можно утверждать, что модель RBAC более полно соответствует административной модели, которую большинство компаний использует для управления доступом к ресурсам и управления контролем доступа к приложениям:

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

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

Архитектура Windows 2003 RBAC

Прежде чем начать разговор об архитектуре RBAC в Windows 2003, следовало бы упомянуть, что RBAC не является новинкой для операционных систем и приложений Microsoft. Так, например, понятия пользователя и групп ресурсов применялись еще в самых ранних версиях NT, обеспечивая похожую на роли функциональность. Кроме того, структура разработки модели COM использует концепцию специфической для приложения роли, подобно тому, как Windows 2003 задействует модель RBAC. Ключевое различие состоит в том, что вы можете использовать роли общей объектной модели только в приложениях, которые задействуют для записи общую объектную модель и ее продолжение COM+. В Windows 2003 модель RBAC не зависит от типа разработки общей объектной модели. Таким образом, вы можете применять различные варианты общей объектной модели: COM, COM+ или Windows.NET Framework.

Обратите внимание, что модель RBAC, представленная в Windows 2003, не будет заменять все модели DAC, существующие в настоящее время для приложений Windows. Модели RBAC и DAC могут легко сосуществовать. Однако в определенный момент Microsoft, возможно, интегрирует некоторые из моделей DAC в модель RBAC или даже полностью переместит приложения в модель RBAC

На Рисунке 1 показана текущая архитектура модели RBAC Windows 2003 и ее главные компоненты. Менеджер авторизации (Authorization Manager) является механизмом управления и принятия решений в RBAC-системе. Здесь показано, что вся RBAC информация должным образом сохранена в базе данных политик (policy database) и позволяет запросу из приложения и администраторам управлять политикой доступа к базе данных.

Приложения с поддержкой RBAC в процессе работы делают запросы менеджеру авторизации Authorization Manager, чтобы узнать, имеет ли определенный пользователь право исполнить некоторую операцию на уровне приложения. Authorization Manager дает разрешение продолжать операцию, основываясь на членстве пользователя в определенной роли. Для приложения разрешение дается на основе информации о связке операция-роль или задача-роль, хранящейся в базе данных политик. В модели DAC решения о возможности доступа принимает локальный менеджер ресурсов на хост-машине. RBAC-ориентированные приложения обращаются во время работы к менеджеру авторизации через набор интерфейсов, основанных на технологиях COM, показанных на Рисунке 1 как Authorization API (AuthzAPI).

Вы можете сохранить централизованную базу данных политики доступа менеджера авторизации в ActiveDirectry или в XML-файле. Чтобы использовать AD как хранилище базы политик управления доступом, необходимо перевести Windows 2003 на однородный функциональный уровень (Native). Лучше использовать AD, потому что AD позволяет делегировать администрирование политик управления доступом и их компонентов другим администраторам. Хранилище информации по авторизации, основанное на AD, по умолчанию размещается в контейнере Program Data в контексте именования домена AD. Следовательно, хранилище копируется на каждый контроллер домена.

Первичный интерфейс администрирования - оснастка MMC Authorization Manager, показанная на Рисунке 2. Консоль Authorization Manager поддерживает два режима: режим разработчика и режим администратора. В более ограниченном режиме администратора пользователи могут сделать все, что могут делать разработчики, кроме создания новых приложений Authorization Manager, операций, изменения операций, имен приложений или информации о версии. Для переключения между режимами нажмите Action, Options в консоли Authorization Manager.

Возможно, самый важный аспект в использовании модели RBAC в реализации Microsoft состоит в том, что она позволяет реализовать гибкие решения управления доступом. Администраторы могут применить политику управления доступом к специфическому объекту-приложению или операции (например, отправка почтового сообщения, подтверждение расходов). В модели DAC вы используете заданные разрешения управления доступом и применяете политику управления доступом к заранее определенным объектам, например к объектам файловой системы, объектам системного реестра и объектам баз данных.

Далее рассмотрим особенности Authorization Manager, позволяющие легко изменять поведение политики управления доступом во время ее применения к определенным объектам:

  • менеджер авторизации поддерживает динамические группы, членство в которых может изменяться в зависимости от результатов запросов к каталогу Lightweight Directory Access Protocol (LDAP), которые генерирует приложение во время работы. Например, приложение взаимодействия с партнерами CRM, поддерживающее роли, может автоматически посылать почтовые сообщения членам динамической группы Customer. Можно определять членство в группе Customers по результатам выполнения запроса LDAP, который приложение создает для базы данных каталога, содержащего данные клиентов.
  • менеджер авторизации поддерживает сценарии авторизации, которые выполняются во время работы приложения и предоставляют разрешения на доступ к данным, например, в зависимости от времени дня, валюты и типа значений. В случае приложений электронной коммерции, например, можно блокировать заказы определенных изделий в течение некоторых периодов дня или года. В качестве примера, приложение могло бы разрешить доступ к разделу Рождественских елок в каталоге продуктов только в декабре.
  • менеджер авторизации поддерживает детализированный аудит во время работы приложений. Менеджер авторизации проводит аудит удачной или неудачной инициализации приложений, инициализации клиентского контекста и попыток удаления и все попытки доступа. Администраторы могут использовать аудит на уровне базы данных политик в AD или базы политик в виде файла XML.

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

Концепции менеджера авторизации

База данных политик авторизации менеджера авторизации включает в себя один или более наборов следующих типов объектов: приложения, группы, роли, задачи, области и Bizrules. База данных политик может содержать политики управления доступом для множества приложений. Например, на Рисунке 3 показана база политик, содержащая Web-приложение управления расходами (Expense Web App) и Web-клиент этого приложения (Customers Leads Web App).

Можно назначить пользователям и группам Windows или специальным группам менеджера авторизации необходимые роли. Пользователи и группы Windows имеют SID и существуют в базе данных безопасности Windows (SAM или AD). Специальные группы менеджера авторизации, известные также как группы приложений (application groups) не имеют SID и существуют только в пределах контекста базы данных менеджера авторизации, приложения или области приложения. Так, на Рисунке 3 показан контейнер Groups в базе данных на уровне политик AD_AuthPolicyStore, контейнера приложения и наборов. Набор - это список объектов в пределах политики управления доступом к приложению.

Существует два типа групп приложения: основной и на LDAP-запросе. Основные группы приложения имеют атрибут членства и нечленства в группе. Атрибут нечленства позволяет запрещать доступ, подобно праву Deny access, которое используется при разграничении доступа к объектам AD или файловым ресурсам. Атрибуты членства и нечленства могут быть присвоены как пользователям и группам Windows, так и другим группам приложений. Группы приложений, базирующиеся на запросах к LDAP, могут обеспечить динамическое членство в группах, зависящее от результатов запроса к LDAP, который посылает приложение во время работы.

Мы определили роли менеджера авторизации в терминах операций и задач. Операция - это низкоуровневая процедура, которая обычно имеет значение для менеджера ресурса. В качестве примеров операций можно привести следующие: "Прочитать квоту расхода пользователя" или "Записать пользовательский пароль". Операции описываются на уровне приложения и идентифицируются номером операции, который должен быть целым числом.

Задача - это набор операций, значение которых важно для администратора приложения (например, "одобрить расход", "подтвердить расход"). Вы можете определить задачи как на уровне приложения, так и на уровнях набора.

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

Чтобы сделать процесс авторизации более динамическим, менеджер авторизации позволяет связывать сценарии авторизации (или как их называют в Microsoft, Bizrules) и задачи. Менеджер авторизации анализирует Bizrules во время их выполнения, чтобы изменять предоставляемую информацию в реальном времени в зависимости от времени дня, валюты или заданных пороговых значений параметров. Вы можете создавать Bizrules в VBScript или в Jscript, и сохранять их в базе данных политик, наряду с другой информацией из политики.

Также вы можете использовать менеджера авторизации набора, чтобы более точно настроить политику управления доступом к приложению. Указать набор так же просто, как  путь в файловой системе (для приложений, базирующихся на файловой системе), контейнер AD (для приложений, основывающихся на AD) или URL (для Web-приложений). На Рисунке 3 изображены два набора, определенные в контейнере приложения Expense Web App: один для обработки коммерческих расходов подразделения (Sales Dept Expenses) и  другой -  для обработки расходов на управление (Executive Expenses).

Сценарии развертывания

Менеджер авторизации открывает много новых интересных возможностей, связанных с созданием сценариев развертывания приложений. Посмотрим, как менеджер авторизации может усовершенствовать защиту многоуровневых приложений, которые используются  архитектурной моделью доверенных приложений (trusted application architectural model).

Существует две архитектурных модели для многоуровневых приложений - модель имитации/делегирования и модель доверенных приложений. Windows 2003 содержит расширения для обеих моделей. Наиболее значимы два расширения Kerberos для имитации/делегирования: ограниченное делегирование и смена протокола.

В модели имитации/делегирования приложение промежуточного слоя (обычно приложение Web-сервера) может выполнять одну из следующих операций.

  • Генерация маркера имитации (impersonation token), который отражает данные о разрешениях доступа пользователя и применение этого маркера для обращения пользователя к нужным ресурсам.
  • Отправление маркера доступа к требуемому ресурсу. Этот процесс называется делегированием и выполняется только в случае использования протокола Kerberos. Применение авторизационного протокола Kerberos также разрешает многоуровневое делегирование.

Концепция, стоящая за моделью имитации/делегирования, состоит в том, что имитатор объекта "пользователь" выходит за пределы промежуточного слоя и устанавливает параметры настройки управления доступом на конечных ресурсах, имитируя учетные данные пользователя. В модели доверенных приложений имитация пользователя не выходит за рамки промежуточного слоя. В этой модели для доступа к оконечным ресурсам используется служебная учетная запись Web-сервера или Web-приложения.

Интегрирование менеджера авторизации в модель доверенных приложений позволяет принудительно присваивать разрешения на основании ролей и предоставляет возможности детального аудита на уровне Web-приложений в реальном времени. Но интеграция не отменяет преимуществ модели доверенных приложений, таких как:

  • Более простое управление доступом на конечном ресурсе и серверах приложений. Вы можете использовать одну учетную запись (служебную учетную запись Web-сервера или Web-приложения) для настройки всех параметров управления доступом.
  • Поддержка пула подключений. Пул обеспечивает более высокий уровень масштабируемости, но это возможно только если все подключения с оконечной инфраструктурой работают в том же пользовательском контексте защиты. Пул подключений в модели имитации\делегирования не имеет большого значения, поскольку каждое соединение запускается в различных пользовательских контекстах защиты (в контексте имитированного или делегируемого пользователя).
  • Управляемая точка доступа. В модели доверенных приложений доступ ко всем оконечным ресурсам происходит через Web-интерфейс. Пользователи не могут задействовать другие каналы для доступа к оконечным ресурсам (при условии, что соответствующие списки доступа к ресурсам (ACL) находятся на самих этих ресурсах).

На Рисунке 4 показаны различия между моделью имитации\делегирования и моделью доверенных приложений с менеджером авторизации.

Перспективы развития менеджера авторизации и модели RBAC

Windows 2003 позволяет задействовать менеджер авторизации и модель RBAC для работы с бизнес-приложениями, в которых используются роли. Однако, за исключением Microsoft Internet Information Services (IIS) 6.0, имеющего возможность авторизации, основанной на URL, Microsoft не обеспечивает приложениям поддержку ролей без определенной доработки этих приложений. Менеджер авторизации более полезен разработчикам, чем администраторам. Однако положение дел со временем может измениться. А до тех пор вы можете использовать программное обеспечение типа ActiveRoles от FastLane для ролевого управления в AD и других задач. FastLane ActiveRoles обеспечивает поддержку модели RBAC на вершине модели DAC. Более подробную информацию об этом программном обеспечении можно найти в документации на http://www.quest.com/fastlane/activeroles.

Жан де Клерк (jan.declercq@hp.com) - член Security Office компании HP, специализирующийся на идентификационных параметрах и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press).