Аудит доступа к файлам и папкам в Windows Server 2008 R2

Для ведения аудита доступа к файлам и папкам в Windows Server 2008 R2, необходимо включить функцию аудита, а также указать папки и файлы, доступ к которым необходимо фиксировать. После настройки аудита, в журнале сервера будет содержаться информация о доступе и других событиях на выбранные файлы и папки. Стоит заметить, что аудит доступа к файлам и папкам может вестись только на томах с файловой системой NTFS.

Включаем аудит на объекты файловой системы в Windows Server 2008 R2

Аудит доступа на файлы и папки включается и отключается при помощи групповых политик: доменный политик для домена Active Directory либо локальных политик безопасности для отдельно стоящих серверов. Чтобы включить аудит на отдельном сервере, необходимо открыть консоль управления локальный политик Start -> All Programs -> Administrative Tools -> Local Security Policy. В консоли локальной политики нужно развернуть дерево локальный политик (Local Policies) и выбрать элемент Audit Policy.

В правой панели нужно выбрать элемент Audit Object Access и в появившемся окне указать какие типы событий доступа к файлам и папкам нужно фиксировать (успешный/ неудачный доступ):

После выбора необходимой настройки нужно нажать OK.

Выбор файлов и папок, доступ к которым будет фиксироваться

После того, как активирован аудит доступа к файлам и папкам, необходимо выбрать конкретные объекты файловой системы, аудит доступа к которым будет вестись. Так же как и разрешения NTFS, настройки аудита по-умолчанию наследуются на все дочерние объекты (если не настроено иначе). Точно так же, как при назначении прав доступа на файлы и папки, наследование настроек аудита может быть включено как для всех, так и только для выбранных объектов.

Чтобы настроить аудит для конкретной папки/файла, необходимо щелкнуть по нему правой кнопкой мыши и выбрать пункт Свойства (Properties). В окне свойств нужно перейти на вкладку Безопасность (Security) и нажать кнопку Advanced. В окне расширенных настроек безопасности (Advanced Security Settings) перейдем на вкладку Аудит (Auditing). Настройка аудита, естественно, требует прав администратора. На данном этапе в окне аудита будет отображен список пользователей и групп, для которых включен аудит на данный ресурс:

Чтобы добавить пользователей или группы, доступ которых к данному объекту будет фиксироваться, необходимо нажать кнопку Add… и указать имена этих пользователей/групп (либо указать Everyone – для аудита доступа всех пользователей):

Далее нужно указать конкретные настройки аудита (такие события, как доступ, запись, удаление, создание файлов и папок и т.д.). После чего нажимаем OK.

Сразу после применения данных настроек в системном журнале Security (найти его можно в оснастке Computer Management -> Events Viewer), при каждом доступе к объектам, для которых включен аудит, будут появляться соответствующие записи.

Альтернативно события можно просмотреть и отфильтровать с помощью командлета PowerShell — Get-EventLog Например, чтобы вывести все события с eventid 4660, выполним комманду:

UPD от 06.08.2012 (Благодарим комментатора Roman).

В Windows 2008/Windows 7 для управления аудитом появилась специальная утилита auditpol. Полный список типов объектов, на который можно включить аудит можно увидеть при помощи команды:

Как вы видите эти объекты разделены на 9 категорий:

• System
• Logon/Logoff
• Object Access
• Privilege Use
• Detailed Tracking
• Policy Change
• Account Management
• DS Access
• Account Logon

И каждая из них, соответственно, делиться на подкатегории. Например, категория аудита Object Access включает в себя подкатегорию File System и чтобы включить аудит для объектов файловой системы на компьютере выполним команду:

Отключается он соответственно командой:

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

После того, как активирован аудит доступа к файлам и папкам, нужно указать конкретные объекты которые будем контролировать (в свойствах файлов и папок). Имейте в виду, что по-умолчанию настройки аудита наследуются на все дочерние объекты (если не указано иное ).

Все собранные события можно сохранять во внешнюю БД для ведения истории. Пример реализации системы: Простая система аудита удаления файлов и папок для Windows Server.

Журналирование в Windows

С выходом Windows Vista в механизмах журналов Windows многое изменилось. В Windows 7 и Windows Server 2008 R2 эти механизмы получили дополнительное развитие. Теперь администраторы могут значительно упростить себе жизнь и сократить расходы на ИТ для небольшого предприятия, в разумных пределах, конечно. С некоторой натяжкой новые возможности можно назвать распределенным мониторингом «для бедных». Давайте рассмотрим эту тему несколько подробнее

. Сначала поговорим о системе журналирования в целом.

Компоненты системы журналирования

Прежде всего, как и в предыдущих версиях Windows, частью этой системы является служба журнала событий. Это, можно сказать, классический механизм журналирования, известный со времен Windows NT. Он обеспечивает поддержку нескольких стандартных журналов, в которые система и приложения могут писать различные сообщения при помощи специального API. Однако с появлением Windows Vista/Windows server 2008 этот механизм был значительно расширен. Наиболее значительным нововведением, на мой взгляд, является реализация поддержки технологии Event Tracing for Windows (ETW). Благодаря этой функциональности система журналирования научилась получать данные от провайдеров ETW, как системных, так и пользовательских. То есть появилась возможность расширять список отслеживаемых провайдеров за счет тех, которые могут предоставляться используемыми приложениями. Кроме того, теперь вы можете выполнять свой сценарий или приложение в ответ на определенное событие. Это может помочь в автоматизации работы системы.

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

• Source-initiated subscriptions — события отправляются источником. Этот тип позволяет создать подписку на компьютере, который будет собирать события с удаленных источников. При этом удаленные компьютеры должны быть настроены при помощи глобальной политики таким образом, чтобы они отправляли свои события в единую точку. Такие подписки могут использоваться для сбора данных как с доменных машин, так и с машин, не входящих в ваш домен. Для проверки подлинности последних можно использовать сертификаты.
• Collector-initiated subscriptions — события собираются приемником. Если вы знаете список систем, с которых хотите собирать события, то вы можете настроить компьютер для сбора данных с систем, входящих в домен. При этом приемник будет самостоятельно опрашивать нужные системы и собирать с них данные. Этот тип подписки применим только в рамках домена.

Для работы в сети служба использует еще одну технологию — WS-Management, что накладывает определенные требования на компьютеры, которые могут служить источниками событий.

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

Event Tracing for Windows

Сам по себе механизм Event Tracing for Windows имеет очень большие возможности. Основная его идея состоит в том, что многие компоненты как самой операционной системы, так и пользовательских приложений могут при помощи специального API отправлять сообщения о своем состоянии этому механизму по запросу. Компоненты, которые реализуют передачу событий, называются провайдерами событий. При этом нагрузка на систему во время сбора данных растет незначительно: на 20000 событий/с приходится примерно 5% процессорных ресурсов. Основным назначением данной системы является не очень длительная диагностика состояния системы, приложений и взаимодействия между ними. Сама по себе она не заменяет обычный журнал событий. Но другие внешние приложения, например служба журнала событий, могут подписываться на любые события, предоставляемые ETW через провайдеры событий. Для этого существуют так называемые каналы журнала событий, которые могут предоставляться провайдерами. То есть не все провайдеры предоставляют каналы для журнала событий. Именно эти каналы и провайдеры вы можете увидеть в журнале приложений и служб журнала событий (экран 1).

Экран 1. Каналы и провайдеры для журнала событий

Кроме того, список провайдеров можно получить при помощи двух утилит командной строки: xperf и wevtutil. Утилита xperf (экран 2) является частью пакета Microsoft Windows Performance Toolkit, и здесь мы не будем ее рассматривать, а утилитой wevtutil (экран 3) займемся немного позднее.

Экран 2. Утилита xperf

Экран 3. Утилита wevtutil

Следующей составляющей инфраструктуры событий можно считать планировщик заданий. Теперь эта служба используется системой очень активно, достаточно посмотреть на список заданий, существующих в системе по умолчанию. Теперь, например, можно привязать задание к определенному журналу или событию в журнале. А значит, реагировать на различные события в системе стало проще. Для этого требуется всего лишь выбрать нужное событие в журнале и, щелкнув правой кнопкой мыши, выбрать соответствующий пункт меню (экран 4).

Экран 4. Привязка задания к определенному журналу или событию в журнале

В результате появится окно мастера, в котором можно выбрать нужное действие, как на экране 5.

Экран 5. Мастер создания задачи

Свойства созданной задачи можно будет увидеть после ее создания, в самом конце процедуры, или в самом планировщике заданий. Как мы видим, задание запускается при появлении события с заданным EventID в журнале Application. Проверить это можно при помощи простой утилиты:

Данная команда создаст запись с необходимыми нам параметрами в нужном журнале, и мы сразу увидим сообщение, сгенерированное планировщиком заданий (экран 6).

Экран 6. Cообщение, сгенерированное планировщиком заданий

Кроме того, задание можно создать и из командной строки, следующим образом:

Эта функция планировщика заданий тоже основана на ETW.

Служба журнала событий

Теперь перейдем непосредственно к службе журнала событий и ее возможностям. Служба eventlog запускается в процессе svchost и принадлежит к группе служб LocalServiceNetworkRestricted. Права доступа к ней показаны на экране 7.

Экран 7. Права доступа к службе eventlog

Получить SDDL — строки, описывающие права доступа к службе, можно при помощи утилиты sc:

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

Служба поддерживает несколько основных каналов: «Система», «Приложение», «Установка» и «Безо­пасность». Каждому из этих каналов соответствует один журнал, который можно просматривать при помощи Event Viewer. Каналы «Система» и «Приложение» предназначены для журналирования различных событий. Канал «Установка» предназначен для сообщений, связанных с установкой и настройкой, а «Безопасность» — для сообщений, связанных с безопасностью.

Расширенные функции и дополнительные журналы находятся в разделе журналов приложений и служб. Представленные в нем журналы разделены на несколько типов: административный, журнал операций, аналитический и отладочный журналы. События, содержащиеся в административном журнале, предназначены в первую очередь для конечных пользователей, администраторов и служб технической поддержки. Кроме самого описания проблемы, такой журнал предоставляет администратору всеобъемлющую информацию о способах ее решения. Такие события либо подробно описаны в документации, либо с ними связаны сообщения с четкими инструкциями по устранению проблемы. Записи в журнале операций служат для анализа и диагностики проблем или событий. Они могут использоваться для запуска средств или задач при возникновении соответствующих проблем или событий. Примером события в журнале операций является добавление или удаление устройства из системы. Аналитический и отладочный журналы не предназначены для повседневного использования. Мало того, для событий, которые регистрируются в отладочных журналах на конечной системе, может не быть метаданных для их интерпретации. Эти журналы предназначены для анализа производителями приложений и службы поддержки Microsoft. Там же можно создать собственные журналы событий при помощи powershell:

Каналы провайдеров ETW можно найти в папке Microsoft в этом разделе. Тут же вы найдете и примеры описанных выше типов журналов. Чтобы увидеть отладочные и аналитические журналы, нужно выбрать соответствующую настройку (экран 8).

Экран 8. Включение просмотра отладочных и аналитических журналов

После этого можно включить эти журналы для сбора событий своего провайдера, щелкнув правой кнопкой мыши по журналу и выбрав пункт «Включить журнал». Для того чтобы включить аналитический журнал из командной строки, можно сделать следующее:

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

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

Основной утилитой командной строки при работе с журналами является wevtutil. Некоторые примеры ее применения мы уже рассмотрели выше. Хочу обратить ваше внимание еще на некоторые ключи и результаты, позволяющие лучше понять нововведения в механизмах журналирования.

Как можно узнать, с каким поставщиком событий связан тот или иной журнал? Посмотрите на экран 9 и обратите внимание на выделенные строки. Параметр owningPublisher указывает на поставщика событий для этого журнала. Характерно, что для классического журнала «Приложение» этот параметр пуст. Кроме того, обратите внимание на тип файла журнала. В случае расширенного журнала это файл с расширением etl — event trace. В таких файлах сохраняются события ETW при их сборе утилитой xperf.

Экран 9. Работа с wevtutil

Следующая интересная функция — возможность делать выборки из журналов прямо из командной строки при помощи упрощенного запроса xpath. Например, используя стандартную утилиту wevtutil, можно выбрать все события с EventID=1000 из журнала «Приложение»:

Можно сделать то же самое, используя другой подход — сценарий на Powershell. В Powershell 2.0 появились команды, предназначенные для работы с расширенными возможностями службы журналирования. Одна из них — get-winevent. С ней запрос будет выглядеть вот так:

Если вы хотите получить все ошибки и предупреждения, можно поступить так:

Для того чтобы упростить себе задачу при написании таких запросов, можно пойти на хитрость. Графический интерфейс встроенного просмотровщика событий позволяет фильтровать представления журнала по определенным параметрам. В том же окне фильтра есть вкладка XML, на которой заданный вами фильтр будет представлен в виде XML. В таком виде его можно использовать для команды get-winevent с параметром -FilterXml или, взяв только запрос в квадратных скобках, можно применять его как в параметре -FilterXPath команды, так и в wevtutil.

Подписка на события

Перейдем, наконец, к самой интересной части — к подписке на события. За эту функцию отвечает служба Windows Event Collector. Запускается она со следующей командной строкой: C:\Windows\system32\svchost.exe -k NetworkService.

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

WS-Management. Для сбора данных используется инфраструктура Windows remote management. Отсюда и вытекают все требования. Инфраструктура построена на протоколе ws-management, который в свою очередь использует HTTP, SOAP over HTTP (WS-I profile), SOAP 1.2, WS-Addressing, WS-Transfer, WS-Enumeration и WS-Eventing. Таким образом, для того чтобы можно было собирать события с удаленных источников, необходимо, чтобы на клиентах и сервере работала эта инфраструктура. Что для этого нужно? Необходим WinRM http://support.microsoft.com/kb/968929 — компонент, реализующий Windows remote management для Windows. Отсюда вытекают следующие требования.

WinRM 2.0 и PowerShell 2.0. Вы должны тем или иным способом установить и настроить WinRM на всех своих клиентских машинах, с которых будут собираться данные. Отрадно, что в Windows Server 2008 R2 и Windows 7 эти компоненты, как и необходимая для наших целей оболочка Powershell, уже есть.

После установки вам потребуется настроить WinRM. Для этого существует два способа. В первом случае можно использовать сценарий winrm.vbs, он же утилита winrm, во втором — Powershell. При первом способе настройка сводится к выполнению команды winrm quickconfig. Эта команда настроит сетевой экран, и, самое главное, создаст так называемый слушатель (Listener), который обеспечивает возможность подключения и сетевого взаимодействия с инфраструктурой. Слушатель по умолчанию создается для протокола HTTP по порту 5985. Для диагностических целей важно знать, как проверить наличие слушателя и его настроек. Для проверки настроек и наличия слушателя можно указать следующую команду:

Косвенно проверить, открыт ли и слушается ли нужный порт, можно командой netstat -an. С другой стороны, при помощи powershell эта задача выполняется следующим образом: настройка winrm — командой Set-WSManQuickConfig, а проверка слушателей протокола HTTP — вызовом get-wsmaninstance winrm/config/listener -selectorset @. Слушателей при необходимости можно создать вручную.

Для корректной работы сборщика событий на сервере и клиентах winrm должен быть настроен.

После этого для доменных конфигураций мы должны сделать следующее:

1. Настроить на сервере сбора службу сбора событий.
2. Создать политику пересылки данных для клиентов.
3. Создать подписку соответствующего типа на сервере.
4. Создать нужные правила для брандмауэра.

Для настройки службы выполним команду wecutil qc. В качестве примера создадим простейшую политику. Для этого во вновь созданном объекте групповой политики в разделе административных шаблонов выберите пункт Event Forwarders. В нем нужно указать сервер назначения в правильном формате. Формат настроек указан в пояснении к политике. В конечном виде настройка выглядит так, как показано на экране 10.

Экран 10. Настроенная политика пересылки событий

Следующий этап — создание подписки. Этот шаг делается на сборщике событий в оснастке просмотра журналов событий. На первом этапе выбирается тип подписки. Тут вы принимаете решение исходя из того, каким образом события будут собираться в конечной точке. Либо их будет собирать сам сервер, либо, как в нашем случае, клиенты будут присылать события сами. На втором шаге указываются группы компьютеров или отдельные компьютеры, которые будут иметь право отправлять сообщения. В данном окне речь идет только о правах, обратите на это внимание.

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

На последнем шаге нам предстоит выбрать параметры доставки сообщений.

• Обычная. Данный параметр обеспечивает надежную доставку событий без попыток экономии пропускной способности сети. Это правильный выбор, когда не требуется жестко контролировать использование полосы пропускания или обеспечить максимально возможную скорость доставки событий. Применяется режим доставки pull и передача пакетов по пять событий с периодом задержки 15 минут.
• Уменьшенная пропускная способность. Этот параметр обеспечивает строгий контроль использования полосы пропускания для доставки событий. Подходящий выбор, если требуется ограничить частоту сетевых подключений для доставки событий. Используется режим доставки push и передача пакетов с периодом задержки 6 часов. Кроме того, используется интервал подтверждения соединения в 6 часов.
• Уменьшенная задержка.Этот параметр обеспечивает доставку событий с минимальной задержкой. Подходящий вариант при сборе оповещений или критических событий. Используется режим доставки push и передача пакетов с периодом задержки 30 секунд.

Обращаю ваше внимание, что режимы доставки в данном случае — это не то, каким образом будут передаваться данные. Это параметры API, которые отвечают за методы реакции сервера на полученные сообщения:

• модель push проталкивает события асинхронно путем вызова функций обратного вызова;
• модель pull использует обработчик событий, созданный в специальном объекте событий для того, чтобы уведомить вас о том, что поступили события, соответствующие вашему фильтру. После этого список полученных событий вы обрабатываете вручную.

На данном этапе также можно выбрать протокол доставки. В нашем случае это HTTP. Для использования HTTPS нужно дополнительно создать слушателей этого протокола.

Для того чтобы использовать параметр custom, при указании настроек доставки сообщений придется задействовать утилиту wecutil. При этом можно использовать как параметры командной строки, так и специально подготовленный XML-файл с конфигураций подписки. В рамках такого рода подписок можно изменять количество событий в пакете, отправляемом серверу, время между отправками, heartbeat-интервал, который используется как индикатор доступности источника данных.

Если все сделано правильно, то в журнале ForwardedEvents начнут появляться выбранные вами события с удаленных компьютеров.