Аудит событий доступа к объектам Active Directory
Оценка эффективности существующей политики безопасности системы должна базироваться на некотором аналитическом материале. В состав операционной системы Windows Server 2003 включены действенные механизмы протоколирования событий, связанных с попытками (как удачными, так и неудачными) получения доступа к ресурсам сети.
Согласно терминологии Microsoft, процесс протоколирования действий пользователей получил название аудита (audit). Сведения обо всех событиях, связанных с попыткой получения доступа к ресурсам, для которых активизирован режим аудита, фиксируются системой в специальном журнале безопасности (Security log).
Для объектов каталога реализация аудита осуществляется в два этапа:
- Активизация режима аудита. При этом администратор должен указать категории событий, которые подлежат аудиту.
- Определение объектов каталога, для которых будет осуществляться аудит событий.
Подсистема безопасности Windows Server 2003 оперирует девятью категориями событий, подлежащих аудиту. Применительно к аудиту событий, связанных с функционированием службы каталога, интерес представляют три категории событий:
- Audit object access (Аудит событий, связанных с доступом к объектам);
- Audit directory service access (Аудит событий, связанных с доступом к службе каталога);
- Audit account management (Аудит событий, связанных с управлением учетными записями).
Аудит доступа к службе каталога выполняется по отношению к операциям, выполняемым на контроллерах домена. Для активизации аудита можно использовать оснастку Domain Controllers Security Policy. Эта оснастка работает с объектом групповой политики Default Domain Controllers Policy, привязанного к подразделению Domain Controller. Откройте узел Computer Configuration › Windows Settings › Security Settings › Local Policies › Audit Policy (Конфигурация компьютера › Конфигурация Windows › Параметры безопасности › Локальные политики › Политика аудита) содержащий категории аудита.
По умолчанию для политик аудита задано одно значение – No auditing (Нет аудита). В окне оснастки выберите категорию событий, откройте его окно свойств, установите флажок Define these policy settings (Определить следующие параметры политики) и определите, какие именно попытки – успешные (Success) или неуспешные (Failure) – должны регистрироваться в системном журнале безопасности. Если флажок Define these policy settings (Определить следующие параметры политики) снят, считается, что для данной категории событий аудит не определен (Not Defined).
Следует заметить, что установки No auditing (Нет аудита) и Not defined (He определено) имеют разное значение. Если политика не определена, вы можете установить ее на другом уровне. Значение No auditing переопределяет все установки, которые могли быть заданы ранее. Групповые политики для контейнера Domain Controllers применяются последними и, следовательно, имеют самый высокий приоритет. Поэтому установки аудита, определяемые этими политиками по умолчанию, переопределяют любые параметры, заданные на предыдущих уровнях.
На следующем этапе администратор определяет объекты каталога, для которых будет осуществляться аудит событий. Для каждого объекта каталога аудит событий может производиться на двух уровнях:
- на первом уровне отслеживаются все события, связанные с доступом непосредственно к самому объекту (создание, удаление, чтение объекта и т. п.);
- на втором уровне система регистрирует в системном журнале все события, связанные с доступом к индивидуальным атрибутам объекта (чтение или изменение атрибута объекта).
Режим аудита позволяет отслеживать действия над объектами каталога и их атрибутами на любом уровне иерархии. При этом допускается наследование дочерними объектами параметров аудита от родительских объектов.
Для операций чтения рекомендуется задавать аудит неудачных обращений (отказов), поскольку при регистрации большого количества успешных обращений журнал безопасности (Security Log) будет быстро переполняться. Как следствие, снижается производительность контроллеров домена. Для операций записи, создания/удаления и других критичных операций (которые выполняются гораздо реже, чем чтение) можно устанавливать аудит всех событий, т. е. как успешных, так и неудачных обращений.
По умолчанию для группы Everyone (Все) выполняется аудит специальных обращений (успешных и неудачных) ко всем объектам в домене. Все объекты домена наследуют эти установки от корневого доменного контейнера. У некоторых контейнеров имеются дополнительные параметры аудита. Эти установки разрешают аудит критических операций, таких как запись, удаление, изменение и т. д. Все установки аудита можно просматривать в окне свойств объекта: откройте вкладку Security (Безопасность), нажмите кнопку Advanced (Дополнительно) и перейдите на вкладку Auditing (Аудит).
Нажмите кнопку Edit (Редактирование), и в открывшемся окне вы можете просматривать и изменять параметры. Если вы откроете вкладку Auditing для некоторого дочернего объекта каталога, то заметите, что все установленные флажки затенены. Их нельзя изменить непосредственно, для этого нужно открыть родительский или корневой объект. Если установить еще не отмеченный флажок, система создаст новый набор параметров аудита и добавит его в список.
Поскольку по умолчанию многие успешные обращения регистрируются, после включения аудита может возникнуть громадное количество записей в системных журналах. Поэтому при выполнении аудита в течение достаточно длительного времени следует изменить параметры, заданные по умолчанию.
Содержимое журнала безопасности может быть просмотрено при помощи оснастки Event Viewer. Для каждого события утилита отображает следующую информация:
- успешность попытки (была ли попытка доступа успешной или нет);
- дата и время попытки;
- имя учетной записи компьютера, с которого была произведена попытка;
- имя учетной записи пользователя, совершившего попытку.