Что такое списки dacl и sacl

Списки управления доступом

Список управления доступом на уровне пользователей (DACL) определяет доверенные лица, которым разрешен или запрещен доступ к защищаемому объекту. Когда процесс пытается получить доступ к защищаемому объекту, система проверяет ACE в списке DACL объекта, чтобы определить, следует ли предоставить доступ к нему. Если у объекта нет DACL, система предоставляет полный доступ для всех. Если DACL объекта не имеет записей ACE, система отклоняет все попытки доступа к объекту, так как список DACL не разрешает права доступа. Система проверяет ACE по порядку, пока не обнаружит один или несколько записей ACE, которые разрешают все запрошенные права доступа, или пока не будут отклонены все запрошенные права доступа. Дополнительные сведения см. в статье Управление доступом к объекту в DACL. Сведения о том, как правильно создать список DACL, см. в разделе Создание списка DACL.

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

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

Списки ACL также обеспечивают управление доступом к объектам службы Microsoft Active Directory Directory. Active Directory интерфейсов служб (ADSI) включают подпрограммы для создания и изменения содержимого этих списков ACL. Дополнительные сведения см. в разделе Управление доступом к Active Directory объектам.

Источник

Часть 16. Списки контроля доступа

— Желтые штаны — два раза «ку»… Ку, ку…
© «Кин-Дза-Дза»

Введение

После затяжного перерыва возобновляем работу нашего клуба. Как я и обещал, продолжим изучение подсистемы безопасности NT. На этот раз мы остановимся на одном из концептуальных понятий — списке контроля доступа, а также рассмотрим его применение касательно объектов реестра и файловой системы (с чем большинство пользователей и сталкивается на практике). Под файловой системой я, естественно, понимаю «родную» для NT NTFS. Поехали!

Теория

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

Итак, мы знаем, что у нас есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, значит, это «свой», впускаем, нет — «пшел вон!» Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя (здесь идет серьезное обобщение, впрочем, для нас это не важно), создающий рабочую среду (оболочку и т.д.). Этот процесс получает контекст защиты (так называемый маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы (т.е. открытые программы) запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.

Однако остается еще одна проблема: при обращении программы (процесса) к объекту ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы «остальные», которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (и NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту — уже упомянутый список контроля доступа. Что же это такое, и чем оно отличается (в положительную сторону) от других методов защиты?

Собственно, разительных отличий нет. И там, и там что-то с чем-то сверяется (этим озабочена та часть ядра, которая отвечает за безопасность — справочный монитор безопасности для NT), а потом выдается либо разрешение на доступ, либо запрет. Однако достоинство списков контроля (управления) доступа (Access Control List, ACL) в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности (научился использовать их для файлов, разберешься и для всего остального).

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

Теперь поясним, что каждый элемент означает. Итак, с номером защиты и с флагами, думаю, все понятно; нам они, собственно, и неинтересны. А что такое SID владельца? Дело в том, что все объекты, выполняющие в системе какие-нибудь действия (например, пользователи и группы), кроме имени, имеют свой идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект (вспомните содержимое папки RECYCLER, названия вложенных папок — идентификаторы защиты пользователя), что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины, формирующееся по правилам, нас здесь не касающимся:-). В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). С SID группы аналогично — это идентификатор основной группы владельца (используется только подсистемой POSIX).

А теперь самое вкусное: DACL и SACL. По сути дела, это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).

ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо листьями. Контейнеры могут содержать другие контейнеры и/или листья и так далее. ACE бывают двух общих видов (особенности Active Directory не рассматриваем): «доступ разрешен» и «доступ отклонен» (позже я это докажу вам на примере). Причем сначала идут запрещающие ACE, а потом разрешающие (это очень важно: в обратном случае редактор DACL файловой системы, например, сочтет это ошибкой и предложит вам унаследовать DACL родителя, хотя это случается архиредко и связано с использованием устаревших функций Win32).

SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как «успех», так и «отказ». В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.

Алгоритмы

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

Это общая схема, тем не менее, дающая нам возможность понять, как все это работает. Теперь подобьем наши знания и добавим новые:

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

Практика

Как и говорилось, экспериментировать мы будем над ФС и реестром (в систему встроен графический редактор ACL и консольная версия редактора DACL — cacls.exe). В первую очередь, потому, что это актуально для пользователя, а во вторую — что здесь применяются все возможности ACL (включая наследование). В качестве ОС выбрана русская версия Windows XP Professional. Для начала в Windows XP необходимо отключить опцию Использовать простой общий доступ к файлам из закладки Вид окна Свойства папки Панели управления. Данный режим предназначен для неподготовленных пользователей и весьма ограничен в возможностях. В Windows XP Home Edition вам это сделать не удастся, поэтому нужно будет либо работать в Безопасном режиме (Safe Mode), либо воспользоваться консольной утилитой cacls.exe (или ее расширенным аналогом из Support Tools — xcacls.exe).

Итак, сначала откроем редактор ACL. Для файловой системы достаточно в Проводнике в контекстном меню выбрать пункт Свойства, а затем закладку Безопасность (для папок можно сразу выбрать пункт Общий доступ и безопасность…). Для реестра выбираем нужную ветвь (разграничение доступа идет только на ветви, а не отдельные ключи) и в контекстном меню выбираем пункт Разрешения… (для пользователей Windows NT и 2000 придется воспользоваться программой regedt32.exe, так как только она обладает нужной функциональностью). Так как в обоих случаях используется один и тот же редактор ACL и общие принципы, то продолжать я буду на примере свойств папки.

На нем перечислены пользователи и их права. Можно добавлять новых и удалять уже имеющихся (если позволяет наследование). Однако это лишь вершина айсберга — здесь перечислены только общие типы доступа, основанные на нескольких ACE с одинаковым SID. Проверим? Жмем кнопку Дополнительно и оказываемся в настоящем редакторе ACL.

Как видим, тут перечислены все ACE, причем сначала идут запрещающие. Мы можем добавить, удалить и изменить ACE. При добавлении нас спросят об имени пользователя, которое можно ввести вручную либо воспользоваться поиском, нажав в появившемся окне Дополнительно, Поиск. Кнопка Типы объектов позволяет указать, что мы ищем: пользователей, группы или встроенных пользователей/группы. Кстати, имя имеет вид Имя контейнера (компьютера в нашем случае)\Имя пользователя, хотя можно просто вводить имя пользователя. С удалением все понятно, а редактирование представляет некоторый интерес.

Мы вправе менять такие параметры, как имя пользователя (т.е. выбрали редактировать одно, а потом взяли да и сменили), параметры наследования (вложенные папки, объекты и т.д.), ограничение наследования (галочка внизу, становится доступна, когда выбрано наследование для подпапок и файлов) и собственно сами права. Кнопка Очистить выполняет быструю очистку всех галочек в ACE. Если мы поставим сразу запрещающие и разрешающие галочки, то будет создано два ACE: запрещающее и разрешающее (помните о примере). Причем этого можно добиться также и в самом первом окне (до нажатия кнопки Дополнительно) редактированием базовых типов доступа. Думаю, с этим разобрались.

В расширенный редакторе ACL внизу можно заметить две галочки, отвечающие за наследование. Первая указывает на то, что данный объект наследует права доступа от родительского. Если снять эту галочку, то нам предложат либо скопировать унаследованные права в качестве заданных явно (что в большинстве случаев удобно), либо просто очистить ACL, если нет других ACE, кроме унаследованных. Вторая галочка позволяет заменить разрешения всех объектов и контейнеров заданными здесь, то есть по сути дела заставляет их наследовать права.

Что касается аудита — все абсолютно аналогично рассмотренному DACL включая наследование.

Перейдем к владению (закладка Владелец). По умолчанию владельцем является его создатель, т.е. пользователь либо группа. Однако можно вступить во владение объектом, если вы обладаете таким правом (по умолчанию им обладают члены группы Администраторы) либо если в DACL явно указано, что вы можете изменить владельца. Мы просто выбираем доступного пользователя или группу для владения, если надо, ставим галочку Заменить владельца субконтейнеров и объектов и жмем Применить. Все, объект наш:-).

Ну и напоследок бросим взгляд на закладку Действующие разрешения. Это полезное нововведение XP, позволяющее не просчитывать в уме права конкретного пользователя/группы. Достаточно выбрать имя, и мы получим список прав на основе имеющихся ACE.

Остается добавить, что внешний вид редактора ACL зависит от объекта, разрешения которого мы редактируем, т.е. могут быть недоступны какие-то опции. Если вам интересно, можете поэкспериментировать с консольными утилитами cacls.exe и xcacls.exe. Первая — аналог простого редактора базовых типов доступа, вторая позволяет работать с разрешениями более точно. Не забывайте, что, перетаскивая объект в другую папку в Проводнике, мы тем самым заставляем его унаследовать права этой папки. Чтобы этого не произошло, необходимо пользоваться консольными утилитами с соответствующими ключами либо файл-менеджерами, поддерживающими эту опцию (Total Commander, например).

Заключение

Надеюсь, приведенная мной информация оказалась вам полезной. Если это так, то я и дальше буду продолжать снабжать вас интересными фактами о системах семейства NT. В данной статье использовались материалы из книги Д. Соломона и М. Руссиновича «Внутреннее устройство Microsoft Windows 2000», а в предыдущей (забыл упомянуть) — книга Федора Зубанова «Microsoft Windows 2000. Планирование, развертывание, управление».

Источник

Sysadminium

База знаний системного администратора

Дескрипторы безопасности и управление доступом

Из этой статьи вы узнаете про ещё один компонент безопасности операционной системы Windows, а именно про дескрипторы безопасности.

Дескрипторы безопасности

Дескриптор безопасности — это информация, связанная с объектом, которая определяет, кто и какие действия с объектом может выполнять.

В дескриптор безопасности входят:

ACL состоит из субъектов доступа (кто может обращаться к объекту) и набора прав для каждого субъекта (писать, читать, исполнять). DACL — указывает какой доступ имеет определенный субъект к этому объекту. SACL — указывает какие события нужно заносить в журнал аудита безопасности.

Практика

Давайте посмотрим дескриптор безопасности какого-нибудь процесса. Заметьте, дескриптор безопасности процесса определяет кто может что-то сделать с этим процессом, а не то что может сделать сам процесс. Посмотреть на дескриптор безопасности можно из Process Explorer. Я выбираю любой процесс svhost (процесс какой-то службы), открываю его свойства. Затем перехожу на вкладку “Securuty” и внизу нажимаю кнопку “Permision“:

В примере выше к этому процессу имеют доступ только локальные администраторы. При этом читать и писать в процесс они не могут, но имеют “Особые разрешения“.

Если погрузиться дальше, нажимаем кнопку “Дополнительно“, далее два раза щелкаем по группе “Администраторы“, и в открывшемся окне нажимаем ссылку “Отображение дополнительных разрешений“. Вы увидите такую ACE запись (записи в ACL называются ACE):

То есть Администраторы могут запрашивать информацию о процессе.

Вот еще некоторые сведения о DACL:

Если открыть свойства файла или папки, перейти на вкладку “Безопасность“, а затем нажать кнопку “Дополнительно“. И перейти на вкладку “Действующие права доступа“, то можно выбрать пользователя и проверить его права доступа к этому файлу или каталогу:

Динамическое управление доступом (DAC)

В дополнение к перечисленному выше стоит упомянуть ещё одну технологию – динамическое управление доступом.

Механизм избирательного управления доступом, описанный выше был еще с первой версии Windows NT. Но начиная с Windows 8 и Server 2012 появилось динамическое управление доступом (DAC). Оно рассчитано на домен.

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

Дополнительно к этому на файлы и каталоги стало возможно навешивать различные теги.

Благодаря расширению маркера доступа и тегам, DAC позволяет настраивать гибкие правила. Например, можно настроить такое поведение, чтобы сотрудник из Москвы мог прочитать файлы только с определённым тегом.

DAC не заменяет DACL, а лишь дополняет его. Так что если DACL запрещало доступ к файлу, то с помощью DAC открыть доступ мы не сможем. Получится лишь ограничить доступ ещё сильнее, оставив доступ только у тех, кому он действительно нужен.

Вот ещё примеры действий, которые можно совершить используя DAC:

Конфигурация DAC определяется в Active Directory и распространяется через групповые политики. Для этого был расширен протокол Kerberos. Подробнее про DAC может посмотреть в этом видео.

Источник

Аудит доступа к объектам

Контроль использования файлов, принтеров, реестра и других объектов

Контроль на двух уровнях

Экран 1. Упрощенный вид DACL объекта.

Список DACL. В списке DACL перечислены пользователи, имеющие право доступа к объекту, и способы доступа. (Часто вместо DACL используется термин ACL.) Чтобы открыть DACL объекта из Windows Explorer (для папок и файлов) или в окне Printers (для принтеров), следует щелкнуть на объекте правой кнопкой мыши, выбрать пункт Properties и перейти к закладке Security (см Экран 1). На этой закладке дан упрощенный вид списка DACL, т. е. показаны разрешения только для одного пользователя или группы. Чтобы просмотреть полный список DACL, нужно щелкнуть на кнопке Advanced. Откроется диалоговое окно Access Control Settings объекта, показанное на Экране 2.

Экран 2. Полный список DACL-объекта.

Экран 3. SACL объекта.

Контроль попыток доступа к объекту

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

Предположим, что пользователь Гарольд работает с Microsoft Excel и пытается открыть файл payroll.xls. Excel запрашивает у Windows 2000 дескриптор для payroll.xls. Windows 2000 сравнивает DACL файла с учетной записью Гарольда и запросом на чтение, поступившим от Excel; согласно DACL, у Гарольда нет права на чтение payroll.xls. Как показано на Экране 2, доступ к payroll.xls имеют только Administrators и группа HR, а Гарольд не является членом ни одной из этих групп. Windows 2000 выясняет, что системной политикой аудита предусмотрена регистрация неудачных попыток обращения к объекту, поэтому она просматривает SACL файла payroll.xls и исследует каждый элемент ACE, контролирующий неудачные попытки доступа. Windows 2000 определяет, какие из этих элементов ACE указывают на учетную запись Гарольда или группу, к которой он принадлежит. Как показано на Экране 3, SACL объекта содержит ACE, который относит неудавшуюся операцию чтения к группе Everyone, поэтому Windows 2000 регистрирует событие с ID 560 (см. Экран 4).

Экран 4. Событие с ID 560 неудачной попытки доступа.

Предположим, что пользователь Салли также пытается открыть файл payroll.xls из Excel. Поскольку Салли является членом группы HR, она имеет право выполнять операции чтения и записи в файле payroll.xls. Системная политика аудита настроена на регистрацию успешных попыток доступа к объектам, и SACL файла содержит ACE, относящийся к успешным операциям записи и группе Everyone, поэтому Windows 2000 регистрирует событие с ID 560 (см. Экран 5).

Экран 5. Событие с ID 560 успешного доступа.

Экран 6. Событие с ID 560 непрямого доступа.

Поля Primary Logon ID и Client Logon ID содержат идентификатор logon ID, присваиваемый при регистрации с учетной записью пользователя, обратившегося к объекту. Чтобы определить, в каком сеансе был произведен доступ, следует посмотреть на событие с ID 540 (удаленная регистрация) или с ID 528 (все другие виды регистрации) с этим идентификатором (подробнее эти события описаны в статье «Контроль событий регистрации в Windows 2000».) Если пользователь напрямую открывает объект на своей локальной машине, то Primary Logon ID события с ID 560 соответствует Logon ID события с ID 528, зафиксированного Windows 2000 при регистрации пользователя в системе; поле Client Logon ID остается пустым. Если пользователь обращается к файлу на удаленной машине, то поле Primary Logon ID события с ID 560 идентифицирует сеанс, связанный с учетной записью локального компьютера, а поле Client Logon ID события с ID 528 соответствует Primary Logon ID.

В поле Accesses указаны типы доступа, запрошенные приложением. Одни типы доступа специфичны для определенного класса объектов, другие применимы к любому объекту. В Таблице 1 перечислены и описаны самые распространенные типы доступа.

Когда пользователь открывает файл или папку, в поле Accesses отмечаются предоставленные пользователю типы доступа, специфичные для данной папки или файла. Эти типы доступа соответствуют специальным разрешениям, приведенным в DACL файла. Параметры ReadAttributes и WriteAttributes указывают, что пользователь открыл файл с возможностью изменения его свойств (только чтение, архивный, скрытый, системный). ReadEA и WriteEA применяются к расширенным атрибутам файла, определяемым конкретными приложениями. Чтобы увидеть расширенные атрибуты файла, нужно открыть Windows Explorer и щелкнуть на файле правой кнопкой мыши. Выбрав Properties, следует перейти к закладке Custom, а затем к закладке Summary.

Тип AppendData означает, что пользователь имеет право добавить данные в открытый файл. ReadData и WriteData означают, что пользователь, открывший файл, имеет возможность прочитать или изменить его данные. Если задан режим аудита запуска исполняемых файлов, то Windows 2000 регистрирует доступ типа Execute при каждом запуске программы.

Завершение работы с объектом

Когда пользователь открывает объект из приложения, Windows 2000 регистрирует событие с ID 560, а при закрытии объекта операционная система регистрирует событие с ID 562 (дескриптор закрыт). Поля события с ID 562 частично совпадают с полями события с ID 560.

Экран 7. Событие с ID 562.

Не только файлы

Категория Audit object class используется не только для контроля доступа к файлам. Например, с помощью программы regedt32 можно запустить аудит разделов реестра и затем контролировать доступ к разделам и элементам реестра. Элементы реестра не имеют собственных списков DACL и SACL; как и операции управления доступом, операции аудита проводятся через родительский раздел реестра. Windows 2000 регистрирует типы доступа, соответствующие разрешениям в списке DACL раздела, и описывает разрешения, указанные в событии с ID 560. Если обращение к разделу реестра вызывает событие с ID 560, то Windows 2000 указывает в поле Object Type значение Key. Значение в поле Object Name начинается с REGISTRY, за которым следует ветвь и остальной путь к разделу. Например, подраздел HKEY_LOCAL_MACHI-NESOFTWAREAcme отображается как REGISTRYMACHINESOFT-WAREAcme.

Из меню Settings, Printers можно получить доступ к спискам SACL принтеров и реестра. Для этого достаточно выполнить те же операции, что и при доступе к SACL файла или папки, но отправной точкой будет служить не Windows Explorer, а меню Settings, Printers.

В статье Microsoft «Monitoring and Auditing for End Systems» (http://www.microsoft.com/technet/ security/monito.asp) говорится, что можно выполнять аудит системных служб, но в действительности это не так. Даже если в SACL службы режим аудита включен (с помощью политик Group Policy через ComputerConfiguration, Windows Settings, Security Settings, System Services), Windows 2000 не заносит в журнал безопасности сведений о запуске, остановке и отключении службы. Идентификаторы событий документированы для некоторых других операций (например, удаления объекта), но этот механизм пока не функционирует.

Наследование SACL

В Windows 2000 схема наследования SACL повторяет схему DACL. По умолчанию, элементы SACL автоматически переходят от родительских папок и разделов реестра к дочерним объектам. Например, если разрешить аудит неудачных операций записи в папку, то все файлы и подпапки наследуют этот элемент SACL. Существует несколько уровней настройки наследования SACL.

Дочерний уровень. Чтобы блокировать передачу элементов родительского SACL дочернему объекту, следует открыть окно Access Control Settings (параметры управления доступом) дочернего объекта, перейти к закладке Auditing и снять флажок Allow inheritable auditing entries from parent to propagate to this object. Затем нужно щелкнуть OK или Apply. Если к моменту сброса флажка какие-то наследуемые элементы SACL уже были переданы объекту-потомку, Windows 2000 потребует подтвердить необходимость их удаления или создать их копии без наследования.

Экран 8. Отмена блокировки наследования в дочерних объектах.

Родительский уровень. Чтобы разблокировать наследование в дочерних объектах, следует открыть диалоговое окно Access Control Settings родительского объекта, показанное на Экране 8, перейти к закладке Auditing и установить флажок Reset auditing on all child objects and enable propagation of inheritable auditing entries. После щелчка на кнопке OK или Apply операционная система отменяет аудит на всех дочерних объектах и сбрасывает флажок, чтобы администратор мог выборочно блокировать наследование на дочерних объектах. Данная функция сброса полезна, если администратор не знает, какой режим наследования установлен в системе, и хочет начать все сначала.

Можно также контролировать глубину наследования и указать последний дочерний объект, на который распространяется действие каждого элемента SACL. Чтобы отредактировать отдельный элемент SACL, нужно открыть диалоговое окно Access Control Settings родительского объекта, перейти к закладке Auditing, выбрать элемент и открыть окно Auditing Entry щелчком на кнопке View/Edit, как показано на Экране 9. В данном диалоговом окне предусмотрено два способа реализации наследования дочерними объектами. Раскрывающийся список Apply onto определяет типы объектов, которым передается запись об аудите. По умолчанию из списка выбирается значение This folder, subfolders and files (данная папка, подпапки и файлы), но пользователь может выбрать любое сочетание этих объектов. (На Экране 9 выбран режим аудита неудачных операций чтения только файлов, но не папок.) С помощью флажка Apply these auditing entries to objects and/or containers within this container можно определить, передаст ли Windows 2000 запись объектам, расположенным непосредственно в папке, или рекурсивно распространит эту запись на все дочерние уровни ниже данной точки.

Экран 9. Редактирование отдельных элементов SACL.

Как лучше провести аудит

Какую стратегию избрать для аудита объектов? Во-первых, если требуется проверить определенный каталог или раздел реестра на нескольких машинах, нужно использовать групповые политики. Например, чтобы исследовать неудачные попытки записи в каталоге \%systemroot% на всех компьютерах домена, следует открыть оснастку MMC Active Directory Users and Computers и щелкнуть правой кнопкой мыши на корневом домене. Затем, выбрав Properties, необходимо перейти к закладке Group Policy. Отметив пункт Default Domain Policy Group Object (GPO), следует щелкнуть на кнопке Edit и пройти по Computer Configuration, Windows Settings, Security Settings, File System. Щелкнув правой кнопкой мыши на File System, нужно выбрать пункт Add File. Затем введите с клавиатуры

и щелкните OK. На экране появится диалоговое окно разрешений, похожее на то, которое показано на Экране 1. Чтобы запустить процесс аудит объекта, следует повторить описанную ранее последовательность действий. При этом нужно внимательно отнестись к определению области аудита. Не рекомендуется ограничивать круг проверяемых лиц, так как взломщики часто используют чужие пароли. Поэтому в списке управления следует указать аудитом группу Everyone, чтобы охватить всех пользователей. Однако желательно ограничить подлежащие аудиту типы доступа и объекты. В процессе аудита объектов генерируется большой объем данных. Чтобы журнал безопасности не наполнялся бесполезными сведениями, лучше остановиться на небольшом числе типов доступа к немногим объектам.

Неопытным администраторам может показаться, что на самом деле активность системы не столь велика, как можно предположить исходя из событий Audit object access. Следует помнить, что Windows 2000 не выполняет аудит собственно операций (например, чтения и записи) над объектами; вместо этого проверяются запросы на доступ к объектам, поступающие из приложений. Поэтому в поле Accesses события с ID 560 указывается только тип доступа, который мог получить пользователь, но не сам факт выполнения пользователем каких-либо операций. Проблема усугубляется прикладными программами, которые автоматически запрашивают все типы доступа, независимо от того, нужны ли они пользователю. Представители Microsoft заявляют, что в конечном итоге в Windows 2000 может быть реализован аудит действительных операций, а не возможностей доступа.

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

Поделитесь материалом с коллегами и друзьями

Источник