Как настроить Security Auditing в Windows для отслеживания подозрительных действий

Security Auditing в Windows — это механизм, который пишет в журнал безопасности события вроде входов в систему, неудачных попыток авторизации, изменений прав, запуска процессов и доступа к файлам. Сам по себе он ничего не блокирует, но без него вы часто просто не увидите, что произошло на компьютере или сервере.

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

Что стоит отслеживать в первую очередь

Если вы настраиваете аудит впервые, не начинайте с глубокого аудита каждого файла. Для большинства рабочих станций и серверов полезнее начать с базового набора событий: входы в систему, ошибки входа, изменения учётных записей, изменения групп, запуск служб и процессов, а также подозрительная активность PowerShell.

Минимальный список, который обычно имеет смысл включить:

• неудачные входы в систему;
• успешные входы на серверы и критичные рабочие станции;
• изменения локальных групп, особенно Administrators;
• создание и удаление учётных записей;
• изменение политик безопасности;
• запуск служб;
• создание процессов;
• использование PowerShell и скриптов;
• доступ к важным папкам, если это действительно нужно.

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

Где настраивать: локальная политика, GPO или auditpol

В Windows есть несколько способов включить аудит. Выбор зависит от того, где вы работаете: один компьютер, группа компьютеров или домен Active Directory.

Если у вас домен, лучше настраивать через Group Policy. Если один сервер — через Local Security Policy или auditpol. Если вы тестируете настройку перед развёртыванием — начните с auditpol, а потом перенесите результат в GPO.

Базовая настройка через Local Security Policy

Для отдельного компьютера или сервера откройте Local Security Policy. На Windows это можно сделать через secpol.msc. Дальше идите по пути:

Security Settings → Advanced Audit Policy Configuration → Audit Policies

Лучше использовать именно Advanced Audit Policy Configuration, а не старые настройки в разделе Security Options. В Windows Server и современных редакциях Windows Advanced Audit Policy даёт более понятные категории событий.

Какие категории включить для старта

Включайте аудит не везде, а точечно. Для начала я бы настроил так:

• Account Logon — аудит входа по учётным данным, особенно на контроллерах домена.
• Logon/Logoff — успешные и неуспешные интерактивные, сетевые и удалённые входы.
• Account Management — создание, изменение и удаление пользователей и групп.
• Policy Change — изменения политик безопасности и доверенных отношений.
• Privilege Use — использование важных прав, например отладки или изменения системного времени.
• System — включение и выключение аудита, изменения безопасности системы.
• Process Creation — запуск процессов, особенно если нужно видеть команды запуска.
• PowerShell — если нужно отслеживать выполнение скриптов и команд.

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

Пошаговая настройка через Group Policy

Если компьютеры в домене, настройку лучше делать через GPO. Так вы не будете вручную ходить по каждому серверу и рабочей станции.

1. Откройте Group Policy Management.
2. Создайте отдельную политику, например Security Auditing Baseline. Не смешивайте её с политикой паролей или настройками брандмауэра.
3. Откройте её редактор и перейдите в Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration.
4. Включите нужные подкатегории аудита.
5. Для важных событий поставьте Success и Failure, для шумных — только Failure.
6. Привяжите GPO к нужным подразделениям: серверам, рабочим станциям, контроллерам домена или критичным системам.
7. На клиенте выполните gpupdate /force или дождитесь обычного обновления политик.
8. Проверьте результат командой auditpol /get /category:*.

Отдельная GPO для аудита удобна тем, что её проще сопровождать. Через месяц вы посмотрите журналы, поймёте, какие события шумят, и спокойно измените только этот раздел политики.

Настройка через auditpol

auditpol — удобный инструмент для проверки и быстрой настройки. Он особенно полезен, когда нужно понять, что реально применено на машине.

Посмотреть текущие параметры:

auditpol /get /category:*

Посмотреть все доступные подкатегории:

auditpol /list /subcategory:*

Включить аудит неудачных входов:

auditpol /set /subcategory:"Logon" /failure:enable

Включить успешный запуск процессов:

auditpol /set /subcategory:"Process Creation" /success:enable

Включить и успехи, и ошибки для изменения локальных групп:

auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable

Сбросить параметры подкатегории:

auditpol /clear

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

Экспорт текущих настроек:

auditpol /get /category:* > C:\Temp\audit-policy.txt

Какие события искать в журнале Security

После включения аудита события появятся в Event Viewer → Windows Logs → Security. Не все события одинаково полезны. Часть из них техническая, часть действительно помогает найти подозрительные действия.

Event ID 4624 сам по себе не означает проблему. На сервере успешных входов может быть сотни в день. Подозрительным его делает контекст: необычный пользователь, необычный IP, ночное время, новый тип входа или вход на сервер, куда этот человек обычно не заходит.

Как включить полезные параметры для запуска процессов

Аудит процесса Process Creation становится намного полезнее, если Windows пишет командную строку запуска. Без неё вы часто увидите только cmd.exe или powershell.exe, но не поймёте, что именно выполнялось.

Включить отображение командной строки можно через GPO:

Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events

Поставьте значение Enabled. После этого в событии 4688 будет больше деталей. Но учитывайте: командные строки могут содержать пароли, токены или чувствительные параметры. Поэтому доступ к журналу Security должен быть ограничен только администраторами.

PowerShell: что включить для расследований

Если в вашей среде используют PowerShell, обычный аудит событий Windows не всегда показывает достаточно. Для расследований полезно включить логирование PowerShell через GPO.

Основные настройки:

• Turn on PowerShell Script Block Logging — пишет содержимое выполняемых скриптов.
• Turn on PowerShell Module Logging — логирует использование модулей.
• Turn on PowerShell Transcription — сохраняет ввод и вывод PowerShell-сессий.

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

Аудит файлов и папок: когда он нужен

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

Правильнее делать так:

1. Определите конкретную папку или файловый ресурс.
2. Включите аудит только для нужных действий: чтение, изменение, удаление, изменение прав.
3. Настройте SACL на самой папке.
4. Включите соответствующую категорию аудита объектов.
5. Проверьте, какие события появляются в журнале Security.

Для файлового ресурса это обычно делается через свойства папки: Security → Advanced → Auditing. Там можно выбрать пользователей или группы, для которых нужно писать события, и действия: Read attributes, Write data, Delete, Change permissions и другие.

Если вам нужно знать, кто удалил файл, достаточно аудита удаления. Если нужно видеть каждое чтение конфиденциального отчёта — это уже другой уровень нагрузки и совсем другая политика хранения журналов.

Размер журнала и хранение событий

Даже правильно настроенный аудит бесполезен, если журнал переполняется и старые события затираются. Поэтому сразу проверьте размер журнала Security.

Откройте Event Viewer → Windows Logs → Security → Properties и настройте:

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

Практический ориентир: для рабочей станции может хватить меньшего размера журнала, для сервера — больше, для контроллера домена — ещё больше. Если у вас нет централизованного сбора событий, минимум стоит хранить события хотя бы несколько недель. Если есть SIEM или отдельный syslog-сервер, локальный журнал можно рассматривать как буфер, а основную историю держать централизованно.

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

Как понять, что события реально пишутся

После настройки не верьте настройкам на слово. Проверьте их на практике.

Мини-тесты:

• Введите неправильный пароль и проверьте событие 4625.
• Войдите под доменной учётной записью и найдите событие 4624.
• Создайте тестового пользователя и найдите событие 4720.
• Добавьте тестового пользователя в локальную группу и проверьте события добавления в группу.
• Запустите notepad.exe и проверьте событие 4688, если включён аудит процессов.
• Очистите тестовый журнал только на тестовой машине и убедитесь, что событие 1102 появляется.

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

Что выбрать в зависимости от ситуации

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

Частые ошибки при настройке Security Auditing

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

• Включили слишком много событий. В результате журнал быстро переполняется, а важные записи теряются среди шума.
• Не включили нужную подкатегорию. Например, ожидают события доступа к файлу, но включили только общую категорию без нужного действия.
• Не настроили SACL для файлов и папок. Включить политику недостаточно — для объектов тоже нужны правила аудита.
• Смотрят не тот журнал. События безопасности находятся в Security, PowerShell и системные события могут быть в других журналах.
• Не проверили применение GPO. На доменной машине политика могла не примениться, попасть под наследование или быть переопределена.
• Оставили маленький размер журнала. Через пару дней старые события перезаписались, и расследовать уже нечего.
• Не ограничили доступ к журналам. Security-журнал содержит чувствительные данные: имена пользователей, IP-адреса, командные строки.
• Включили аудит процессов без командной строки. Событие 4688 без командной строки часто мало что объясняет.
• Не ведут базовый уровень нормы. Если вы не знаете, как выглядит обычный вход администратора, сложнее заметить необычный.

Практические рекомендации

Если вы хотите настроить Security Auditing не «для галочки», а чтобы потом реально разбирать подозрительные действия, делайте так:

1. Начните с критичных событий: входы, ошибки входа, изменения групп, создание пользователей, изменения политик, запуск процессов и служб.
2. Для доменной среды используйте отдельную GPO для аудита.
3. Проверьте текущие настройки через auditpol /get /category:*.
4. Включите командную строку для событий запуска процессов, если это допустимо по требованиям безопасности.
5. Настройте размер журнала Security так, чтобы события не затирались слишком быстро.
6. Для контроллеров домена и важных серверов настройте централизованный сбор событий.
7. Не включайте аудит файлов на весь диск. Выбирайте конкретные папки и действия.
8. После настройки проведите тесты: неправильный пароль, создание пользователя, добавление в группу, запуск процесса.
9. Периодически пересматривайте список событий. Если что-то создаёт много шума и не помогает расследованиям — отключите или уменьшите уровень.
10. Зафиксируйте базовую конфигурацию. Через месяц будет проще понять, кто и что изменил.

Минимальный набор для быстрого старта

Если нужно быстро привести Windows-среду в рабочее состояние, я бы начал с такого набора:

• Audit Logon: Success и Failure.
• Audit Account Management: Success и Failure.
• Audit Policy Change: Success и Failure.
• Audit System: Success и Failure.
• Audit Process Creation: Success, с командной строкой.
• Audit Security Group Management: Success и Failure.
• PowerShell Script Block Logging: для административных машин и серверов.

Этого достаточно, чтобы увидеть большинство типовых подозрительных действий: подбор пароля, вход с необычного источника, создание учётной записи, добавление в администраторы, изменение политики, запуск подозрительного процесса или PowerShell-скрипта.

Итог

Security Auditing в Windows нужно настраивать не как «включить всё», а как систему наблюдения за конкретными рисками. Для начала включите аудит входов, ошибок входа, изменений учётных записей и групп, изменений политик, запуска процессов и служб. В домене делайте это через отдельную GPO, на отдельных машинах — через Local Security Policy или auditpol.

После настройки обязательно проверьте журнал Security тестовыми действиями, увеличьте размер журнала и решите, куда вы будете собирать события для хранения. Без проверки и хранения аудит превращается в формальность: события вроде бы пишутся, но в момент разбора их уже нет или они слишком шумные, чтобы найти нужное.

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