Новый уровень управления доступом в NTFS

Вероятно, многие пользователи уже заметили, что программа Security Configuration Manager (SCM), реализованная в Windows NT 4.0 Service Pack 4, управляет доступом точно так же, как в Windows 2000. Действительно, новая модель доступа в NTFS унаследовала старую методику управления, но, вместе с тем, приобрела некоторые очень важные свойства. Изменения затрагивают контроль доступа в следующих трех аспектах. Во-первых, система разрешений (permission) стала более детально проработанной, что предполагает возможность более тонкой настройки доступа. Во-вторых, пользователям, привыкшим к принятой в NetWare системе динамического наследования прав, система разрешений Windows 2000, реализованная в SCM, покажется хорошо знакомой. И, наконец, специалисты Microsoft целиком переработали диалоговые окна при назначении разрешений доступа.

Модульность

Прежде чем воспользоваться новой моделью, необходимо уяснить, в чем же заключаются усовершенствования в системе управления доступом по сравнению с предыдущими моделями, реализованными в NT, и как ими воспользоваться. «Внутри себя» NT всегда обеспечивала более детализированную модель управления доступом, нежели через внешний интерфейс. До выхода четвертого пакета исправлений (SP4) доступ к файлам и каталогам контролировался с помощью семи разрешений высокого уровня: No Access (Нет доступа), Read (Чтение), Change (Изменение), Add (Добавление), List (Список), Add & Read (Добавление и Чтение) и, наконец, Full Control (Полный доступ). Разрешения высокого уровня являются удобной комбинацией шести низкоуровневых специальных разрешений: Read (Чтение), Execute (Исполнение), Write (Запись), Delete (Удаление), Change Permissions (Изменение разрешений) и Take Ownership (Право владения). Если заранее подготовленные разрешения пользователю не подходят, можно указать специальный доступ и выбрать индивидуальную комбинацию разрешений. Но хотя эти специальные разрешения появляются на самом низком уровне доступа, они содержат в себе еще более низкоуровневые разрешения. Например, совокупность разрешений List Folder/Read Data (Список каталога/Чтение данных), Read Attributes (Чтение атрибутов), Read Extended Attributes (Чтение расширенных атрибутов) и Read Permissions (Чтение разрешений) образуют специальное разрешение Read (R), так что с точки зрения внутренних механизмов NTFS разрешения, составляющие Read (R), рассматриваются по отдельности. Но до появления SP4 у пользователей не было возможности с помощью диалогового окна назначения разрешений устанавливать упомянутые выше специальные права доступа к NTFS. Теперь же этими низкоуровневыми разрешениями можно управлять, поскольку Windows 2000 и SCM отображают все 14 специальных разрешений, которые приведены в Таблице 1, а также формировать из них шесть более высокоуровневых групп разрешений, включая группу Special.

Обращаю внимание читателей на то, что разрешение No Access в группах Windows 2000 и SCM отсутствует. До появления SP4 элемент access control entry (ACE), элемент контроля доступа, с разрешением No Access аннулировал всякий доступ, который пользователь мог бы получить через другие элементы списка ACL. Операционные системы NT до установки SP4 не предоставляли никаких механизмов явного запрещения индивидуальных разрешений, поскольку No Access отвергал доступ в целом. Для Windows 2000 и SCM нет необходимости в разрешении No Access, поскольку разработчики Microsoft добавили новые механизмы «точечного» управления доступом. Windows 2000 и SCM предоставляют в распоряжение пользователя два типа ACE: Allow (разрешить) и Deny (отказать), как показано на Экране 1. Пользователь может выбрать в диалоговом окне флажок Allow или Deny в закладке Security в области Permissions и установить, какие разрешения следует предоставить, а какие - нет. Более того, можно даже ограничить доступ специальными разрешениями. Например, Джон выполняет некоторую работу вместе с сотрудниками инженерного отдела, и ему нужен такой же доступ, как и инженерной группе, за исключением права Write в каталог ProjectSchedule. Список контроля доступа, ACL, предоставляет группе Engineering доступ Change на каталог ProjectSchedule. Чтобы не переделывать полностью структуру группы для предотвращения нежелательного доступа Джона в указанный каталог, можно создать группу Interns, членом которой является Джон, и добавить для каталога элемент ACE, который «отнимет» у этой группы доступ Write. Джон по-прежнему сможет просматривать содержимое данного каталога, только без права записи.

Динамическое наследование

Для операционной системы NT в предшествовавшей появлению SP4 модели статического наследования каждый объект получал копию ACL от своего родителя в момент создания объекта. После этого объект становился полностью независимым от родителя, и те изменения, которые происходили с ACL родителя, не оказывали никакого воздействия на порожденный объект до тех пор, пока не устанавливался флажок Replace Permissions on Subdirectories (Заменить разрешения для подкаталогов) и Replace Permissions on Existing Files (Заменить разрешения для существующих файлов) в диалоговом окне определения разрешений каталогов NT. Установка этих флажков означала принудительное копирование родительских ACL на все дочерние объекты, поэтому удобно было использовать такие флажки, когда требовалось распространить разрешения по всей ветви дерева каталогов. Модель наследования ACL разработана именно в таком виде, для того чтобы ускорить процесс определения контроля доступа. Однако подобный подход усложнял администрирование объектов, поскольку процесс перезаписи родительских ACL ликвидировал все легитимные исключения, встречающиеся ниже по дереву от объекта-родителя. Поэтому, когда в NT создавалась новая группа, а SP4 установлен не был, администратор не имел никакой возможности назначить данной группе точный доступ для данного участка дерева каталогов и не повлиять при этом на существующие разрешения.

В Windows 2000 и SCM эти проблемы наследования успешно решены. Теперь разрешения автоматически распространяются от родительского объекта на все порожденные объекты и файлы. Когда происходит изменение ACL какого-либо каталога, все элементы ACE автоматически копируются для всех дочерних ACL. Вместе с тем, явным образом установленные ACE дочернего объекта не переписываются. Дело в том, что для каждого ACE имеется флажок, указывающий, каким образом сформирован элемент ACE - в результате наследования или же явным образом (без наследования). Когда система копирует ACE вниз по дереву дочерних объектов, замена существующих записей выполняется только для унаследованных элементов, а явно назначенные права остаются без изменений.

Описанная модель может вызвать вопрос - а как поведет себя система в том случае, когда, с одной стороны, унаследованные и неунаследованные разрешения конфликтуют между собой, а с другой стороны, администратор не заинтересован в распространении разрешений вниз по дереву? В модели определения контроля доступа Windows 2000 и SCM используется особый алгоритм, с помощью которого Security Reference Monitor (SRM) рассматривает элементы ACE для разрешения конфликтов между унаследованными и неунаследованными разрешениями. SRM-компонент Windows 2000 и SCM предоставляет или блокирует доступ к объекту, когда программа пытается его открыть. SRM в первую очередь обрабатывает неунаследованные разрешения и лишь потом унаследованные. Обработка записей ACE осуществляется по одной в данный момент времени, и каждый раз выполняется сравнение указанного SID группы или пользователя в записи ACE и набора SID маркера доступа (access token) программы.

Когда пользователь запускает какую-либо программу, то получает маркер доступа, включающий SID самого пользователя и набор SID тех групп, которым данный пользователь принадлежит. Когда SRM перебирает элементы ACE, соответствующие некоторому SID в маркере доступа, монитор SRM выполняет оценку ACE-разрешений. Если ACE явным образом отвергает затребованный программой тип доступа, SRM немедленно прекращает просмотр элементов ACE и отвергает доступ к объекту. В противном случае SRM аккумулирует разрешения, предоставляемые данным ACE. После этого SRM проверяет, накоплен ли необходимый программе уровень разрешений. Если SRM накопил все требуемые разрешения, доступ к объекту предоставляется; если же нет, монитор переходит к рассмотрению следующего ACE. Если список ACL исчерпан, а разрешений недостаточно, работа SRM завершается, и доступ к объекту отклоняется. Следовательно, в случае конфликта между унаследованными и неунаследованными разрешениями последние оказываются в выигрыше. Допустим, Фред, являющийся членом группы SalesReps, пытается открыть файл commission.doc для чтения и записи. Файл commission.doc имеет унаследованное разрешение ACE, которое отвергает доступ на чтение для группы SalesReps, а также неунаследованный ACE, предоставляющее лично Фреду права на чтение и запись. В результате Фред сможет открыть файл, поскольку монитор SRM удовлетворит запрос на доступ с правом чтения и записи еще до того, как будет рассмотрено унаследованное право на отказ в таком доступе.

Рисунок 1. Очередность при определении ACE.

Что же происходит, когда разрешающий элемент ACE конфликтует с запрещающим ACE и оба элемента унаследованы? Монитор SRM всегда в первую очередь обрабатывает запрещающую запись ACE для каждого наследования. Это означает, что, когда несколько ACE записаны на одного и того же пользователя, разрешения накапливаются; однако неунаследованные записи ACE превалируют над унаследованными ACE, а внутри каждого вида наследования запрещающие ACE превалируют над разрешающими ACE, что и показано на Рисунке 1. Администратор может указать наиболее общие разрешения на самом высоком уровне дерева каталогов и наращивать разрешения до необходимого уровня по мере продвижения вниз по дереву. Также он вправе воспользоваться запрещающими разрешениями для выборочных ограничений разрешений членов той или иной группы.

Управление наследованием

Экран 1. Просмотр ACE-элементов Windows 2000 и SCM.

Администратору может понадобиться блокировать распространение разрешений от родительского каталога к дочерним каталогам и файлам вниз по дереву. Для Windows 2000 и SCM такая возможность ему предоставляется - либо на дочернем, либо на родительском уровне. Например, администратор хочет заблокировать наследование на уровне дочернего каталога или файла, поскольку для данного каталога или файла должна действовать система разрешений, отличная от таковой на родительском уровне. Для этого на дочернем уровне в списке ACL достаточно просто снять флажок Allow inheritable permissions from parent to propagate to this object (Разрешается наследование разрешений от родительского объекта до данного) в диалоговом окне Properties закладки Security, как показано на Экране 1. Снятие этого флажка закрывает «дверь» к дочернему объекту и блокирует наследование любых разрешений. Когда для отмены наследования используется описанный выше метод, настройки диалогового окна предоставляют администратору возможность удалить наследуемые разрешения и начать формирование списка ACL объекта, что называется, «с чистого листа» или же создать копию уже имеющихся для дочернего объекта ненаследуемых разрешений и приспособить ее к новым требованиям.

На уровне родителя администратор может управлять наследованием двумя способами. Во-первых, каждый родительский ACE имеет специальный флажок, который определяет, будет ли система распространять данный элемент ACE ниже, чем непосредственные дочерние объекты рассматриваемого родителя. Когда администратор устанавливает флажок Apply these permissions to objects and/or containers within this container only (Применить разрешения к объектам и/или контейнерам внутри только данного контейнера) в диалоговом окне Permission Entry for Projects в закладке Object (см. Экран 2), система не распространяет рекурсивно данный ACE на «внучатые» объекты (т. е. порожденные дочерним объектом). Нужно иметь в виду, что рассматриваемый флажок ACE индивидуален и не распространяется на весь список ACL.

Экран 2. Просмотр элемента разрешений в диалоговом окне Projects.

Во-вторых, для управления наследованием на уровне родительского объекта администратор может воспользоваться индивидуальными настройками ACE, но уже в другом диалоговом окне, чтобы указать, будет ли данный ACE применяться к каталогу, файлам внутри каталога или подкаталогам внутри данного каталога. В выпадающем списке альтернативных значений Apply onto (Применить на) в диалоговом окне Permission Entry в закладке Object администратор может выбрать любое сочетание каталогов, подкаталогов и файлов, к которым будет применима данная запись ACE.

Можно воспользоваться выпадающим списком Apply onto для получения того же самого результата, который достигался с помощью разрешений Add и Add & Read в операционной системе NT до появления SP4 (напоминаю, что эти разрешения в Windows 2000 и SCM отсутствуют). Допустим, имеется некоторое устаревшее клиент-серверное приложение, в котором клиентская часть создает файлы в каталоге совместного доступа для дальнейшей их обработки серверным компонентом. В целях сохранения конфиденциальности информации администратору нужно, с одной стороны, обеспечить доступ пользователей к файлам, создание которых было инициировано самими пользователями, а с другой стороны, заблокировать доступ пользователей к чужим файлам. До выхода пакета исправлений SP4 требуемый список ACL выглядел так, как показано в Таблице 2. В среде Windows 2000 или SCM список ACL выглядит согласно Таблице 3.

На родительском уровне можно одновременно воспользоваться обоими методами для назначения точной глубины распространения родительских разрешений и конкретных объектов, к которым эти разрешения применимы. Хотя администратор может в этих двух методах запутаться. Флажок Apply these permissions to objects and/or containers within this container only (Применить разрешения к объектам и/или контейнерам внутри только данного контейнера) контролирует рекурсивное распространение, в то время как выпадающий список альтернативных значений Apply onto контролирует объекты, которые собственно и получают эти разрешения.

Существует еще третий метод управления наследованием разрешений, применяемый при необходимости жестко задать непротиворечивые разрешения для определенной ветви дерева каталогов. Например, несколько администраторов обслуживают один и тот же каталог проектов для инженерного отдела. Это приводит к тому, что в нескольких подкаталогах могут быть неправильно установлены разрешения, в связи с чем возникнет необходимость переустановить эти разрешения. Нужно отредактировать список ACL для каталога проектов и установить флажок Reset permissions on all child objects and enable propagation of inheritable permissions (Переустановить разрешения для всех дочерних объектов и активизировать наследование разрешений) в диалоговом окне Access Control Settings в закладке Permissions (см. Экран 3). В результате списки ACL для всех дочерних объектов очистятся и разрешения родительского каталога проектов распространятся вниз по всей ветви порожденных объектов.

Экран 3. Просмотр установок в диалоговом окне Access Control Settings for Projects.

Новый интерфейс

Для реализации новых возможностей управления доступом пришлось существенно изменить пользовательский интерфейс. Администраторам Windows 2000 необходимо тщательно изучить возможности нового интерфейса, поскольку и сами разработчики Microsoft признают, что на первый взгляд система управления ACL представляется весьма сложной. Закладка Security диалогового окна свойств объекта позволяет ознакомиться с имеющимися разрешениями объекта. В списке Name отображены пользователи или группы, составляющие список ACL. Список Permissions представляет разрешения высокого уровня, относящиеся к пользователю или группе, выбранному или выбранной в списке Name. К сожалению, за один раз администратор может увидеть разрешения лишь для одного пользователя или группы; в этом диалоговом окне не отображается, наделил ли администратор какого-либо пользователя или группу уникальным набором специальных разрешений. Вместе с тем, когда выбирается запись в списке Name, в диалоговом окне выводится сообщение о том, что для данного имени установлены дополнительные разрешения, но они не отображены. Кроме того, диалоговое окно Security не раскрывает факт наследования разрешений, поэтому нельзя определить индивидуальные установки ACE, с помощью которых и реализуется управление наследованием разрешений для дочерних объектов.

Если администратор намерен применять группы со стандартными разрешениями и избегать использования специальных разрешений, то возможностей данного диалогового окна вполне достаточно. Но для того чтобы упростить работу с диалоговым окном Security, специалистам Microsoft нужно было бы так скомбинировать списки Name и Permissions, чтобы, наряду с возможностью пользоваться предопределенным набором разрешений, администратор мог бы с одного взгляда оценить все имеющиеся разрешения, а не заниматься прокруткой всего списка из начала в конец. Также целесообразно снабдить это главное диалоговое окно системой оповещений (alert) о наличии для данного объекта индивидуальных разрешений в одном или нескольких элементах ACL так, чтобы не приходилось просматривать для этого весь список Name целиком.

Щелкнув мышью на кнопке Advanced в закладке Security в диалоговом окне Properties данного объекта, можно вызвать новое диалоговое окно - Access Control Settings. В нем практически во всех деталях отображается весь список ACL. Эллипсис в колонке Permissions сигнализирует о том, что более подробная информация будет доступна при растягивании диалогового окна. Однако в этом окне администратор не может поменять большинство настроек и увидеть, для каких именно записей ACE отключено рекурсивное распространение разрешений. Для обслуживания специальных разрешений и рекурсии следует выбрать соответствующую запись Permissions, а затем щелкнуть кнопкой View/Edit. Появится окно Permission Entry, которое позволяет обработать и каждое ACE-свойство, и выпадающий список альтернативных значений Apply onto нужных файлов и каталогов.

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

ОБ АВТОРЕ