Связаться →
01 WINDOWS SECURITY LOG

Сколько истории хранит журнал Security?

Рассчитайте реальную глубину журнала Windows Security и оцените, через сколько дней старые события могут быть перезаписаны.

Рассчитать глубину → Почему пропадает история
SECURITY EVENT LOG POWERSHELL FORENSICS
SECURITY EVENT LOG SIZE / EVENTS / HISTORY
01 События Записываются системой
02 Журнал Постепенно заполняется
03 Предел Достигается максимум
04 Перезапись Старые события исчезают

Размер журнала — это ещё не глубина истории.

Журнал Security в Windows Server хранит события входа в систему, изменения учётных записей, действия с правами доступа и другие события безопасности.

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

На одном сервере журнал объёмом 2 ГБ может хранить несколько месяцев событий, а на другом — полностью перезаписываться за несколько дней.

Почему это важно

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

02 SECURITY LOG CALCULATOR

Рассчитайте глубину журнала Security.

Инструмент WEB-LABS позволяет оценить, сколько времени журнал Windows Security способен хранить события до их перезаписи.

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

WEB-LABS TOOL / WINDOWS SECURITY LOG

Калькулятор глубины журнала Windows Security

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

POWERSHELL / DATA SOURCE Получить параметры журнала одной командой 
$logName = 'Security'
$logFile = Join-Path $env:SystemRoot 'System32\winevt\Logs\Security.evtx'

$meta   = Get-WinEvent -ListLog $logName -ErrorAction Stop
$file   = Get-Item $logFile -ErrorAction Stop
$oldest = Get-WinEvent -LogName $logName -Oldest -MaxEvents 1 -ErrorAction Stop
$newest = Get-WinEvent -LogName $logName -MaxEvents 1 -ErrorAction Stop

$currentMB   = [math]::Round($file.Length / 1MB, 2)
$maxMB       = [math]::Round($meta.MaximumSizeInBytes / 1MB, 2)
$historyDays = [math]::Round(($newest.TimeCreated - $oldest.TimeCreated).TotalDays, 2)
$fillPercent = if ($maxMB -gt 0) { [math]::Round(($currentMB / $maxMB) * 100, 1) } else { 0 }

[PSCustomObject]@{
    CurrentSizeMB = $currentMB
    MaxSizeMB     = $maxMB
    FillPercent   = $fillPercent
    RecordCount   = $meta.RecordCount
    OldestEvent   = $oldest.TimeCreated
    NewestEvent   = $newest.TimeCreated
    HistoryDays   = $historyDays
} | Format-List
Запустите PowerShell от имени администратора. Для быстрого расчёта понадобятся значения CurrentSizeMB, MaxSizeMB и HistoryDays.
01 Запустите команду 02 Перенесите 3 значения 03 Получите ориентир по глубине истории

Метод экстраполирует текущую плотность журнала до его максимального размера. Если журнал уже почти заполнен и работает с перезаписью, фактический HistoryDays обычно полезнее самого прогноза.

РАСЧЁТНАЯ ГЛУБИНА ИСТОРИИ ≈ 16 дней

При текущей плотности событий журнал объёмом 2 ГБ даст примерно 16 дней истории до перезаписи старых событий.

Заполнение сейчас 87.9%
< 7 днейочень короткая история
7–30 днейограниченный горизонт
30–90 днейрабочий горизонт
90+ днейбольшой запас истории

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

Техническое обследование Windows Server
03 PARAMETERS

Что показывает калькулятор.

MB
01

CurrentSizeMB

Текущий размер файла журнала Security.evtx.

MAX
02

MaxSizeMB

Максимальный объём журнала, установленный в настройках Windows.

EVT
03

RecordCount

Количество событий, которые сейчас находятся в журнале.

OLD
04

OldestEvent

Дата самого старого события, которое ещё доступно для просмотра.

NEW
05

NewestEvent

Дата наиболее нового события в журнале.

DAY
06

HistoryDays

Фактическая глубина доступной истории в днях.

04 LOG CAPACITY

Почему нельзя ориентироваться только на размер журнала.

Количество генерируемых событий сильно зависит от роли сервера и настроек аудита.

Контроллер домена, терминальный сервер, файловый сервер и небольшой сервер приложений могут создавать совершенно разный объём событий за одинаковый промежуток времени.

После включения расширенного аудита количество записей также может значительно увеличиться. Поэтому универсального значения вроде «2 ГБ достаточно для любого сервера» не существует.

01 Настройки аудита
02 Количество событий
03 Скорость заполнения
04 Глубина истории
05 Перезапись
05 RESULT

Как оценивать полученный результат.

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

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

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

Главное — фактическая глубина истории

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

WEB-LABS / EVENT RETENTION SECURITY LOG HISTORY WINDOW
NOW OLDEST AVAILABLE EVENT OVERWRITTEN
AVAILABLE HISTORY EVENT WINDOW
OLDER EVENTS OVERWRITTEN
RETENTION MONITORING ACTIVE
05 EVENT RETENTION

Журнал может хранить меньше истории, чем кажется.

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

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

Подробнее об этой проблеме: «Журнал Security: почему пропадает история событий» .

06 WHEN TO CHECK

Когда стоит проверить журналирование сервера.

Особенно важно контролировать глубину журналов после изменения конфигурации сервера или политик аудита.

01

После включения расширенного аудита Windows

02

После увеличения количества пользователей

03

После внедрения или расширения RDP-доступа

04

После изменения политики информационной безопасности

05

После обнаружения подозрительного входа или инцидента

06

После изменения размера или параметров журналов

01
WINDOWS SERVER

Что ещё стоит проверить

При техническом обследовании Windows Server важно смотреть не только размер журнала Security.

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

02
EVENT HISTORY

История должна быть пригодна для расследования

Цель журналирования — не просто записывать события, а сохранять достаточно информации для восстановления последовательности действий после инцидента.

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

03
LOG ARCHIVE

Важные события лучше хранить отдельно

Увеличение размера локального журнала решает только часть задачи. При высокой нагрузке история всё равно постепенно перезаписывается.

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

WEB-LABS WINDOWS SERVER SECURITY

Не знаете, достаточно ли журналов?

WEB-LABS выполняет техническое обследование Windows Server: проверяем журналирование, события входа, RDP, права пользователей, административные учётные записи и параметры аудита.

Обсудить задачу → Защита инфраструктуры
SECURITY LOG MONITORED EVENTS / RDP / ACCESS