Как избежать утечек данных через журнал событий Windows

Журнал событий Windows — это не просто техническая запись «что произошло на компьютере». В нём часто оказываются имена пользователей, адреса рабочих станций, следы входов в систему, команды PowerShell, ошибки приложений, сетевые подключения и иногда то, чего там быть не должно: пароли, токены, строки подключения и служебные ключи.

Проблема начинается не с самого Event Log, а с привычки считать его «безопасным системным мусором». На практике журналы читают администраторы, службы поддержки, SIEM, системы резервного копирования, подрядчики и иногда пользователи с лишними правами. Если в логах есть чувствительные данные, утечка происходит без взлома пароля: достаточно получить доступ к .evtx-файлу, выгрузке, скриншоту или тикету с фрагментом журнала.

Где журнал событий Windows чаще всего выдаёт лишнее

Самые рискованные места — не всегда очевидны. В Security могут быть учётные записи и IP-адреса, в PowerShell — команды с параметрами, в Application — ошибки с connection string, в Task Scheduler — действия задач, в ForwardedEvents — копии событий со множества машин.

С чего начать проверку

Сначала нужно понять не «есть ли события», а где они лежат и кто может их читать. Журнал событий Windows сам по себе не утекает. Утекают копии: экспортированные .evtx, выгрузки в SIEM, резервные копии, скриншоты, тикеты поддержки и дампы для разработчиков.

На отдельном сервере или рабочей станции можно быстро посмотреть размеры журналов:

Get-WinEvent -ListLog * | Where-Object { $_.RecordCount -gt 0 } | Sort-Object FileSize -Descending | Select-Object LogName, RecordCount, @{n='SizeMB';e={[math]::Round($_.FileSize/1MB,1)}}, LogMode, IsEnabled

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

$keywords = 'password|passwd|пароль|token|secret|api[_-]?key|connectionstring|bearer|private key'
Get-WinEvent -LogName Application -MaxEvents 5000 |
  Where-Object { $_.Message -match $keywords } |
  Select-Object TimeCreated, Id, ProviderName,
    @{n='Fragment';e={(($_.Message -split "`r?`n" | Select-String $keywords) -join ' | ')}}

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

Проверьте права на чтение журналов

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

Практичный минимум:

• Проверьте локальную группу Event Log Readers. Если туда добавлены обычные пользователи, доступ к части журналов у них уже есть.
• Не давайте доступ к Security.evtx «на всякий случай». Это журнал с самой чувствительной информацией о входах, привилегиях и изменениях.
• Разделите роли: администраторы серверов, администраторы безопасности и аналитики SIEM не должны автоматически получать одинаковые права на все журналы.
• Проверьте не только файловые ACL, но и доступ к коллекторам событий, SIEM, резервным копиям и папкам с экспортами.

На рабочей станции можно быстро посмотреть ACL файла Security.evtx:

icacls "$env:SystemRoot\System32\winevt\Logs\Security.evtx"
Get-LocalGroupMember "Event Log Readers" 2>$null

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

Не включайте лишнее логирование без защиты

Логирование команд PowerShell и запуска процессов полезно для расследований, но оно же может стать источником утечки. Например, событие 4688 с командной строкой покажет весь запуск процесса. Если команда содержит пароль, токен или путь к приватному ключу, журнал сохранит это как есть.

Перед включением таких настроек задайте себе три вопроса:

1. Зачем нам именно этот журнал?
2. Кто будет иметь к нему доступ?
3. Как долго эти данные будут храниться на конечных устройствах и в централизованной системе?

Если вы включаете логирование команд, проверьте политику:

auditpol /get /subcategory:"Process Creation"

Отдельно смотрят настройку Include command line in process creation events в групповых политиках. Включать её на всех рабочих станциях без защиты журналов — плохая идея. На критичных серверах и рабочих местах администраторов она часто оправдана, но доступ к Security.evtx должен быть строго ограничен.

Как настроить хранение, чтобы не копить утечку годами

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

Практичные ориентиры:

• Для рабочих станций без централизованного сбора часто хватает локального хранения на 30–90 дней, если нет требований регуляторов.
• Для контроллеров домена, серверов приложений и систем с персональными данными хранение лучше централизовать и держать дольше.
• Для продуктовых приложений не стоит писать подробные debug-логи месяцами, если в них могут быть пользовательские данные.
• Если события отправляются в SIEM, локально не обязательно хранить всё вечно. Иначе вы просто дублируете чувствительные данные.

Пример изменения максимального размера Security.evtx на 256 МБ:

wevtutil sl Security /ms:268435456

Не ставьте размер «побольше» без понимания, кто и как будет эти данные читать. Большой журнал — это не только больше истории, но и больше данных для потенциальной утечки.

Если события уходят в WEF или SIEM

Windows Event Forwarding и SIEM удобны, но они превращают Event Log в централизованное хранилище. Ошибка в фильтрах или правах доступа может сделать утечку масштабнее.

Хорошая схема выглядит так:

• Сборщик событий находится на отдельном сервере, не на обычной рабочей станции администратора.
• Передача идёт по защищённому каналу, без открытого доступа из всех сегментов сети.
• Подписки собирают только нужные журналы и события, а не весь Application.evtx со всех компьютеров.
• В SIEM включено разграничение доступа: аналитик, администратор и аудитор видят разный объём данных.
• Резервные копии SIEM и коллектора защищены так же строго, как сами журналы.
• Доступ к сырым событиям логируется и периодически проверяется.

Особенно внимательно относитесь к Application.evtx. В нём часто оказываются не только системные ошибки, но и сообщения бизнес-приложений. Если приложение пишет в Event Log токены, email-адреса, номера заказов или параметры запросов, SIEM получит всё это автоматически.

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