BC/NW 2008, №2 (13): 13.2

РОЛЕВОЕ УПРАВЛЕНИЕ ДОСТУПОМ К РЕСУРСАМ В ОПЕРАЦИОННОЙ СИСТЕМЕ MICROSOFT WINDOWS SERVER 2003

Хорев П.Б.

(Москва, Московский энергетический институт (технический университет), Россия)

Ключевыми элементами информационной безопасности компьютерных систем и сетей являются идентификация и аутентификация (проверка регистрации субъекта доступа в системе и подтверждение подлинности его имени), авторизация (ограничение полномочий субъекта в системе и его прав доступа к ее ресурсам) и аудит (учет и регистрация действий субъекта при работе с системой). Среди существующих моделей управления доступом к ресурсам компьютерных систем наибольшей гибкостью обладает ролевое управление. Поддержка этого метода разграничения доступа впервые включена в операционные системы Microsoft, начиная с Windows Server 2003, но еще не получила достаточного распространения среди разработчиков программного обеспечения и администраторов компьютерных систем.

В докладе представлены основы методики использования системного компонента операционной системы Microsoft Windows Server 2003 «Диспетчер авторизации» для реализации ролевого разграничения доступа к ресурсам компьютерных сетей, функционирующих под управлением этой операционной системы. Ролевое разграничение доступа позволяет назначать пользователям права в соответствии с обязанностями, которые они выполняют в организации. Диспетчер авторизации позволяет детально определить задачи и роли и назначить их субъектам на основе учетных записей пользователей и групп Windows или их членства в специально определенных группах.

 

Разграничение доступа к объектам компьютерных систем базируется на различных моделях управления доступом и на криптографических методах защиты.

Дискреционная модель разграничения доступа предполагает назначение каждому объекту списка контроля доступа, элементы которого определяют права доступа к объекту конкретного пользователя или группы. Правом редактирования дискреционного списка контроля доступа обычно обладает владелец объекта. Эта модель отличается простотой реализации, но возможна утечка конфиденциальной информации даже в результате санкционированных действий пользователей. Например, владелец файла с конфиденциальной информацией может разрешить чтение этого файла своему коллеге на период совместной работы над каким-либо проектом. С помощью полученного разрешения другой сотрудник сможет скопировать конфиденциальный файл в свою папку и предоставить право его чтения произвольному кругу лиц.

Мандатная модель разграничения доступа предполагает назначение объекту метки секретности, а субъекту – уровня допуска. Доступ субъектов к объектам в этой модели определяется на основании правил «не читать выше» и «не записывать ниже», что предотвращает утечку конфиденциальной информации, но снижает производительность компьютерной системы, т.к. проверка прав доступа должна производиться при любой операции с объектом, а не только при его открытии, как в дискреционной модели. Необходимо также обеспечить достоверное подтверждение назначенного пользователю уровня допуска даже при отсутствии защищенного канала связи с сервером аутентификации.

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

В операционной системе Microsoft Windows Server 2003, наряду с поддерживаемым со времен Windows NT дискреционным разграничением доступа, включена возможность использования разработчиками и администраторами ролевого разграничения доступа к объектам с помощью оснастки «Диспетчер авторизации» (Authorization Manager). Методике применения этого системного программного средства и посвящен данный доклад.

Для запуска Диспетчера авторизации необходимо выполнить команду Пуск | Выполнить | azman.msc. Заметим, что при вызове Диспетчера авторизации не создается хранилище данных авторизации по умолчанию. Чтобы создать хранилище данных авторизации, необходимо переключить компонент «Диспетчер авторизации» в режим разработчика. Для этого в дереве консоли нужно в контекстном меню узла Диспетчер авторизации и выбрать команду Параметры. После чего в диалоговом окне Параметры выбрать Режим разработчика (или Режим администратора для возврата в этот режим).

В Диспетчере авторизации можно использовать следующие два режима:

·                     Режим разработчика. Используется для создания, разворачивания и поддержки приложений. В этом режиме открыт доступ ко всем возможностям компонента «Диспетчер авторизации».

·                     Режим администратора. Этот режим включен по умолчанию. Используется для разворачивания и поддержки приложений. Открыт доступ ко всем возможностям компонента «Диспетчер авторизации», за исключением создания новых хранилищ данных авторизации, создания новых приложений, определения или изменения операций, изменения имени приложения, изменения сведений о версии приложения. Чтобы работать в режиме администратора, необходимо сначала создать приложения, поддерживающие роли, включая все необходимые операции и задачи, а также хранилище данных авторизации. После установки приложения нет необходимости в использовании режима разработчика и можно переключиться в режим администратора.

 

Новое хранилище данных авторизации создается командой Создать | Новое хранилище данных авторизации контекстного меню узла Диспетчер авторизации (в режиме разработчика). Хранилища данных авторизации можно размещать в файлах XML или в Active Directory (рисунок 1).

Рисунок 1

Хранилище в Active Directory определяется с помощью

·       URL-адреса, начинающегося с префикса протокола MSLDAP://,

·       составного имени протокола LDAP (например, CN=myStore, CN=ProgramData, DN=nwtraders, DN=com).

Хранилища данных в Active Directory и содержащиеся в них приложения поддерживают делегирование.

Хранилище данных авторизации в файле XML задается

·       URL-адресом, начинающимся с префикса протокола MSXML://,

·       путем к файлу (например, C:\Temp\MyStore.xml или \\ServerName\ShareName\MyStore.xml).

 

К хранилищу данных авторизации в Active Directory, а также к связанным с ним приложениям и областям, возможно делегирование прав доступа. Для хранилищ данных авторизации в файлах XML делегирование не поддерживается, а доступ к ним может быть разграничен с помощью списков (таблиц) дискреционного управления доступом, поддерживаемых файловой системой NTFS.

Приложение относится к конкретному хранилищу данных авторизации и всегда расположено непосредственно под родительским хранилищем данных авторизации в компоненте «Диспетчер авторизации». Чтобы создать приложение, необходимо использовать команду Создать | Новое приложение в контекстном меню выбранного хранилища данных авторизации в дереве консоли Диспетчера авторизации. При этом потребуется ввести имя приложения, которое должно совпадать с именем, используемым управляемым приложением при инициализации в нем Диспетчера авторизации. При создании приложения также указываются его описание и необязательная информация о версии.

К основным понятиям, используемым в Диспетчере авторизации, относятся роли, задачи и операции. Ролью называется набор разрешений (прав доступа к некоторому объекту), необходимых пользователю для работы. Хорошо спроектированные роли соответствуют категории работы или уровню ответственности сотрудника организации (например, секретарь, сотрудник отдела кадров или архивариус) и имеют соответствующие имена. В службе «Диспетчер авторизации» можно добавлять роли пользователям, чтобы обеспечить выполнение ими своих должностных обязанностей.

В реализованном Microsoft ролевом разграничении доступа введены две категории ролей – роли авторизации и роли конфигурации компьютера. Роли авторизации основаны на функциях работы пользователя. Роли авторизации можно использовать для разрешения доступа, делегирования привилегий администратора или управления взаимодействием с ресурсами компьютерной системы. Например, можно определить роль «Кассир», которая включает в себя права для авторизации расходов и аудита транзакций учетных записей в базе данных бухгалтерии. Компонент «Диспетчер авторизации» позволяет администраторам реализовать этот тип администрирования на основе ролей в приложениях.

Роли конфигурации компьютера основаны на функциях компьютера. Эти роли можно использовать для выбора возможностей, которые требуется установить, включения служб и выбора параметров. Например, для web-серверов, контроллеров домена, файловых серверов, а также для особых конфигураций серверов в организации можно определить роли сервера.

Операция − набор разрешений, которые связаны с процедурами безопасности системного уровня или уровня интерфейса Windows API, такими как WriteAttributes или ReadAttributes (запись или чтение атрибутов объекта). Операции являются составными блоками задач. Определения операций создаются только в режиме разработчика на уровне приложений, но не на уровне хранилища данных авторизации. Определение операции содержит имя, описание и номер операции. Номер операции должен быть целым числом в диапазоне от нуля до 2147483647 (то есть 2³¹ - 1). Номер операции используется приложением для идентификации операции, поэтому ввод неверного номера операции приведет к ошибке приложения.

Для создания определения операции нужно в дереве консоли Диспетчера авторизации выбрать узел Authorization Manager | Имя хранилища данных авторизации | Имя приложения | Определения | Определения операций и выполнить команду контекстного меню Создать | Определение новой операции.

Задачей называется набор операций и в некоторых случаях других задач. Хорошо спроектированная задача содержит интуитивно понятные элементы работы в системе (например, «сменить пароль» или «отправить заказ»). Для создания определения задачи нужно в дереве консоли Диспетчера авторизации выбрать узел Authorization Manager | Имя хранилища данных авторизации | Имя приложения | Определения | Определения задач и выполнить команду контекстного меню Создать | Постановка новой задачи.

Определения задач используются для определений ролей и других задач. В службе «Диспетчер авторизации» связь задач и ролей очевидна. Например, роль «Сотрудник по подбору кадров» может содержать задачу «Собеседование». Способ определения задач, также как и ролей, выбирается в соответствии со структурой организации. Для определения задачи необходимо указать имя, понятное описание, а также задачи и операции более низкого уровня, входящие в данную задачу. В определении задачи можно указать правило (сценарий) авторизации − сценарий VBScript или Jscript (рис. 2).

Опциональным элементом Диспетчера авторизации являются области, позволяющие предотвратить нежелательное разделение ресурсов, которые используются приложением, и обеспечить возможность аудита и делегирования. При создании области указываются ее имя и описание. Имя области не является произвольным, а соответствующим управляемому приложению. Например, если одним из ресурсов приложения является файл, то имя области должно основываться на пути к файлу. Для создания области необходимо выбрать узел консоли Диспетчера авторизации Authorization Manager | Имя хранилища данных авторизации | Имя приложения и выполнить команду контекстного меню Создать | Область.

Рисунок 2

Создание ролей происходит в соответствии со структурой и целями организации. Роли поддерживают наследование. Для определения роли необходимо указать соответствующее имя, понятное описание, а также задачи, роли и операции более низкого уровня, входящие в данную роль. Это позволяет использовать механизм наследования ролей. Например, роль «Справочная служба» может включать в себя роль «Поддержка продукта». В определении роли также можно указать правило авторизации − сценарий на языках VBScript или JScript. Правило авторизации позволяет определить условия, при которых возможна авторизация (ограничить время использования роли или возможность совмещения или одновременного использования роли).

Если определение роли содержит несколько правил авторизации (например, несколько субролей и задач), правила авторизации выполняются синхронно. Порядок выполнения правил в компоненте «Диспетчер авторизации» не имеет значения для авторизации.

Для создания роли требуется выбрать узел консоли Диспетчера авторизации Authorization Manager | Имя хранилища данных авторизации | Имя приложения | Определения | Определения ролей и выполнить команду контекстного меню Создать | Определение новой роли.

В компоненте «Диспетчер авторизации» получатели политики авторизации представлены следующими различными видами групп.

·        Группы и пользователи Windows. В эти группы входят пользователи, компьютеры и встроенные группы, которые используются не только в компоненте «Диспетчер авторизации», но и в других компонентах Windows.

·        Группы запросов LDAP. Принадлежность к этим группам при необходимости динамически вычисляется из запросов LDAP. Группы запросов LDAP являются одним из типов группы пользователей приложения.

·        Основные группы пользователей приложения. Сюда входят группы запросов LDAP, пользователи и группы Windows и другие основные группы пользователей приложения. Основные группы пользователей приложения являются одним из типов группы пользователей приложения

·        Группы пользователей приложения. Включают в себя основные группы пользователей приложения и группы запросов LDAP как частный случай. Группы пользователей приложения используются при ролевом разграничении доступа в компоненте «Диспетчер авторизации». Группой пользователей приложения называется группа пользователей, компьютеров и других участников безопасности.

 

При создании новой группы пользователей приложения необходимо определить, будет она группой запросов LDAP или основной группой пользователей приложения. Любая авторизация пользователей и групп Windows в приложениях на основе ролей в компоненте «Диспетчер авторизации» доступна также для групп пользователей приложения. Причем группы пользователей приложения более гибкие и динамичные.

Для создания группы пользователей приложения нужно выбрать узел Authorization Manager | Имя хранилища данных авторизации | Имя приложения и выполнить команду контекстного меню Создать | Новая группа пользователей приложения. При этом указываются ее имя, описание и тип. После создания группы пользователей приложения в нее могут быть добавлены пользователи и группы Windows, а также другие группы пользователей приложения.

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

Чтобы назначить роль группе пользователей приложения, нужно выбрать узел Authorization Manager | Имя хранилища данных авторизации | Имя приложения | Назначения ролей и выполнить команду контекстного меню Назначить роль. Далее в диалоговом окне Добавление определения роли выбирается ранее созданное определение роли. Затем следует выбрать узел Authorization Manager | Имя хранилища данных авторизации | Имя приложения | Назначения ролей | Имя роли и выполнить команду контекстного меню Назначить группы пользователей приложения. В диалоговом окне Выбор: пользователи, компьютеры или группы вводится имя субъекта, которому требуется назначить роль. Назначаемая роль может находиться не только на уровне приложения, но и на уровне области. С помощью команды того же контекстного меню Назначить пользователей и группы Windows можно назначить роль этим категориям субъектов разграничения доступа.

Чтобы приложение-сервер могло использовать возможности ролевого разграничения доступа оно во время своего выполнения должно инициализировать Диспетчер авторизации для установки соединения с хранилищем объектов авторизации и тем разделом хранилища, которое соответствует этому приложению. Когда клиент затем соединяется с сервером, создается контекст клиента авторизации. Сервер может определить полномочия клиента с помощью функции AccessCheck из набора Windows API. При установке в системе приложения-сервера возможно создание хранилища объектов авторизации и добавление в него необходимых серверу операций, задач и первоначальных ролей.

 

В докладе представлены основы методики использования системного компонента операционной системы Microsoft Windows Server 2003 «Диспетчер авторизации» для реализации ролевого разграничения доступа к ресурсам, используемых приложениями, которые поддерживают авторизацию на основе ролей

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

ЛИТЕРАТУРА

1.     MSDN Library.  Knowledge Base. HOW TO: Install and Administer the Authorization Manager in Windows Server 2003.

2.     MSDN Library.  Windows Server 2003 Technical Articles. Using Dynamic Business Rules in Windows Server 2003 Authorization Manager.