«Регистрация событий — это не просто лог-файлы. Это создание иммунной системы для вашей ИСПДн, где каждый лог — это клетка памяти, способная в любой момент восстановить картину инцидента и доказать, что вы всё сделали правильно.»
Полная матрица мер РСБ
Согласно требованиям к защите персональных данных, регистрация событий безопасности (РСБ) реализуется через семь обязательных мер. Их применение зависит от уровня защищённости (УЗ) информационной системы.
| Мера защиты | УЗ-4 | УЗ-3 | УЗ-2 | УЗ-1 | Применение |
|---|---|---|---|---|---|
| РСБ.1: Определение событий безопасности, подлежащих регистрации, и сроков их хранения | ✓ | ✓ | ✓ | ✓ | Все уровни |
| РСБ.2: Определение состава и содержания информации о событиях безопасности | ✓ | ✓ | ✓ | ✓ | Все уровни |
| РСБ.3: Сбор, запись и хранение информации о событиях безопасности | ✓ | ✓ | ✓ | ✓ | Все уровни |
| РСБ.4: Реагирование на сбои при регистрации событий безопасности | ✗ | ✗ | ✓ | ✓ | УЗ-2, УЗ-1 |
| РСБ.5: Мониторинг результатов регистрации событий безопасности | ✗ | ✗ | ✓ | ✓ | УЗ-2, УЗ-1 |
| РСБ.6: Генерирование временных меток и синхронизация времени | ✓ | ✓ | ✓ | ✓ | Все уровни |
| РСБ.7: Защита информации о событиях безопасности | ✓ | ✓ | ✓ | ✓ | Все уровни |
Ключевое различие между базовыми (УЗ-3,4) и повышенными (УЗ-1,2) уровнями — в обязательности активного мониторинга и отказоустойчивости. На высоких уровнях недостаточно просто собирать логи, нужно гарантировать их непрерывность и постоянно анализировать.
Технические требования к регистрации событий
Каждая мера РСБ подразумевает конкретные технические и организационные действия. Формальное выполнение без понимания сути приводит к «мёртвым» журналам, бесполезным при проверке или расследовании.
РСБ.1 — Определение событий
Требуется не просто список, а формализованный перечень, привязанный к рискам конкретной системы. Для УЗ-3 и УЗ-4 минимальный срок хранения — 1 год, для УЗ-1 и УЗ-2 — 3 года. На практике этот срок часто определяют, исходя из сроков давности возможных проверок или внутренних расследований.
РСБ.2 — Состав информации
Каждая запись в журнале должна быть самодостаточной для анализа. Обязательный минимум включает:
- Временную метку (с точностью не хуже 1 секунды).
- Идентификатор субъекта доступа (учётная запись).
- Тип и результат события (успех/неудача).
- Идентификатор объекта доступа (файл, запись в БД, система).
Отсутствие любого из этих полей затрудняет или делает невозможным восстановление цепочки событий.
РСБ.3 — Сбор и хранение
Сбор должен быть автоматическим и централизованным. Хранение — гарантированным на весь установленный срок. Главная техническая проблема здесь — обеспечить неизменяемость (immutability) журналов в момент записи. Попытка злоумышленника стереть свои следы не должна быть тривиальной задачей.
РСБ.4 — Реагирование на сбои
Для УЗ-1 и УЗ-2 система должна уметь не просто фиксировать сбой журналирования, но и реагировать на него. Типовые сценарии: отправка уведомления администратору, переключение на резервный канал записи или, в критичных случаях, остановка обслуживания запроса с записью об ошибке. Это мера отказоустойчивости, которая часто упускается из виду при проектировании.
РСБ.5 — Мониторинг событий
Самая ресурсоёмкая мера. Регулярный анализ журналов — это не просмотр логов вручную. Речь идёт о настройке корреляционных правил в SIEM-системе для автоматического выявления аномалий: множественные неудачные попытки входа, доступ в нерабочее время, подозрительная активность привилегированных учётных записей. Для УЗ-1 такой мониторинг должен быть ежедневным.
РСБ.6 — Синхронизация времени
Без точных и синхронизированных временных меток журналы с разных узлов системы невозможно сопоставить. Требуемая точность — ±1 секунда. Для этого в инфраструктуре должен быть выделен надёжный источник эталонного времени (например, сервер NTP), с которым синхронизируются все компоненты ИСПДн.
РСБ.7 — Защита информации
Журналы сами по себе — ценный объект атаки. Их защита включает контроль целостности (например, с помощью электронной подписи или хэш-сумм), разграничение доступа (только для чтения уполномоченным лицам) и, при необходимости, шифрование конфиденциальных данных, которые могут попасть в логи (например, фрагменты SQL-запросов или передаваемых данных).
Требования к срокам хранения и типам событий
Минимальные обязательные параметры задают нижнюю планку. Реальный перечень событий должен быть шире и учитывать специфику бизнес-процессов.
Сроки хранения журналов
- УЗ-1: Не менее 3 лет
- УЗ-2: Не менее 3 лет
- УЗ-3: Не менее 1 года
- УЗ-4: Не менее 1 года
Срок в 3 года для УЗ-1/2 выбран не случайно — он перекрывает стандартные сроки проведения плановых проверок контролирующими органами.
Обязательные типы событий
- Вход (успешный и неудачный) и выход пользователей из системы.
- Попытки неудачной аутентификации (ключевой индикатор брут-форса).
- Изменение привилегий и прав доступа пользователей и групп.
- Обращение к конфиденциальным данным (персональным записям).
- Изменение критичных настроек безопасности системы.
- Запуск, остановка и перезагрузка системных служб и приложений.
Технические параметры реализации
- Формат времени: UTC с указанием временной зоны.
- Минимальный объём хранилища: рассчитывается индивидуально, но редко бывает менее 10 ГБ для средней системы.
- Резервное копирование журналов: должно выполняться отдельно от основных данных.
- Контроль целостности: обязательное использование криптографических хэш-функций.
- Режим доступа к журналам: только для чтения уполномоченным администраторам и системам мониторинга.
Рекомендуемые инструменты и СЗИ
Выбор зависит от инфраструктуры. Часто используется комбинация:
- SIEM-системы: Для централизованного сбора, хранения, корреляции и анализа (российские аналоги распространённых решений).
- Встроенные средства ОС: Windows Event Log, подсистема auditd в Linux.
- Средства защиты информации (СЗИ): Многие российские UTM- и DLP-системы имеют модули регистрации и аудита событий.
- Специализированные агенты: Для сбора логов с конкретных приложений и баз данных.
Регистрация событий безопасности — это фундамент, на котором строятся расследование инцидентов, внутренний аудит и доказательство соответствия требованиям 152-ФЗ. Её эффективность определяется не наличием лог-файлов, а готовностью и возможностью извлечь из них осмысленную информацию в любой необходимый момент.