Сбор журналов аудита безопасности

от

«Формальное требование ФСТЭК превращается в основу для построения фактической безопасности. Журналы аудита — это не архив для регулятора, а детализированная запись всего, что происходит в системе. Когда они централизованы и доступны для анализа, вы перестаёте гадать и начинаете знать.»

Исходная ситуация: разрозненная реальность

Параметр Значение
Тип организации Кредитная организация с филиальной сетью
Обрабатываемые данные Финансовые транзакции, персональные данные клиентов
Текущее состояние логов Логи на отдельных серверах, отсутствие централизованного сбора, хранение 3 дня
Критическая проблема Расследовать инциденты невозможно, требования к хранению не выполняются

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

Нормативные требования: что на самом деле нужно

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

Ключевые документы и их скрытые акценты

  • 152-ФЗ «О персональных данных»: требует хранения журналов доступа к ПДн не менее 6 месяцев. Важный нюанс — регулятор вправе запросить эти журналы, и их отсутствие трактуется однозначно. Требование по обеспечению целостности делает бессмысленным хранение логов на том же сервере, который их генерирует.
  • Приказы ФСТЭК России (например, №17): для ГИС и систем критической информационной инфраструктуры (КИИ) устанавливают детальные требования к регистрируемым событиям. Здесь важен не просто сбор, а контроль за действиями привилегированных пользователей (администраторов).
  • Отраслевые стандарты (Банк России, PCI DSS): задают более длительные сроки хранения (до 5 лет) и специфичные события (например, все транзакции с платежными картами). Часто требуют физического разделения журналов операционной деятельности и журналов безопасности.

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

Техническая реализация: от источников к хранилищу

Первая ошибка — начать с выбора SIEM-системы. Правильный путь — определить, что собирать, откуда и как доставить данные без потерь.

Схема потоков данных от источников (серверы, сеть, СУБД, приложения) через агрегаторы и транспортные шины в центральное хранилище с выделенными каналами

1. Архитектурные модели сбора

Выбор зависит от масштаба и сетевой топологии.

Модель Принцип Плюсы Минусы Когда использовать
Централизованная Все источники отправляют логи напрямую в центральное хранилище Простота управления, единая точка анализа Единая точка отказа, высокие требования к каналу в ЦОД, риск потери данных при сетевых проблемах Компактная инфраструктура, все системы в одном ЦОД
Распределённая (децентрализованная) Локальные сборщики/буферы в каждом сегменте или филиале, затем ретрансляция Отказоустойчивость, снижение нагрузки на каналы связи, сохранность данных при обрывах Усложнённое управление, нужна корреляция между сегментами Распределённые сети, филиалы, сегментированная архитектура (например, АСУ ТП)
Гибридная Критичные источники дублируют логи и в локальный буфер, и в центр Баланс между надёжностью и управляемостью Удвоенный объём хранения, сложнее конфигурировать Для ключевых систем (домен, СУБД, шлюзы) в любой архитектуре

2. Конфигурация источников: практические детали

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

Тип системы Что включать Критичные настройки и предостережения
Windows Server Аудит входа/выхода, доступа к объектам, использования привилегий, изменений политик. Используйте подкатегории аудита для детализации. Без настройки SACL (списков управления доступом к системе) аудит доступа к файлам работать не будет. Высокий уровень детализации (например, аудит каждого обращения к файлу) мгновенно переполнит журналы.
Linux (auditd) Системные вызовы, файловый доступ, изменения прав, команды sudo. Правила auditd пишутся под конкретную задачу (например, отслеживание изменений в /etc/passwd). Сбор всех системных вызовов невозможен по производительности. Используйте ключ -k для тегирования событий.
СУБД (PostgreSQL) Все DDL и DML операции, неудачные попытки входа, действия привилегированных ролей. Параметр log_statement = 'all' даст полную картину, но может содержать сами данные (например, пароли в тексте запроса). Используйте log_destination = 'syslog' для отправки напрямую в систему сбора.
Сетевое оборудование Сессии управления (SSH, SNMP), изменения конфигурации, срабатывания ACL, события безопасности. Настройте отправку через secure syslog (например, на TCP/6514 с TLS). Убедитесь, что в логах достаточно контекста (исходный IP, имя пользователя). Для маршрутизаторов критически важен сбор NetFlow/IPFIX для анализа сетевых аномалий.
Веб-приложения Запросы к API, аутентификация, бизнес-транзакции, ошибки. Стандартные логи веб-сервера (access.log) недостаточны. Необходимо структурированное логирование из самого приложения (JSON-формат) с идентификатором пользовательской сессии (session_id) и важными параметрами запроса (без чувствительных данных).

3. Транспорт и буферизация

Как доставить логи из точки А в точку Б надёжно и безопасно.

  • Syslog (RFC 5424): де-факто стандарт. Используйте TCP, а не UDP, чтобы не терять сообщения. Для защиты применяйте TLS (например, в rsyslog с модулем `gtls`). Для российских ГИС требуется поддержка отечественных криптоалгоритмов.
  • Агенты и сборщики: агенты (Wazuh, Ossec, Splunk UF) дают больше возможностей (чтение локальных журналов Windows, целостность файлов), но требуют управления. Без-агентный сбор (через WinRM, syslog) проще, но менее гибок.
  • Очереди сообщений (Kafka, RabbitMQ): обязательны для высоконагруженных систем. Они решают проблему пиковых нагрузок, когда скорость генерации логов превышает скорость их обработки хранилищем, и позволяют подписать несколько потребителей (например, SIEM и система долгосрочного архива) на один поток данных.
  • Локальная буферизация: каждый источник должен хранить свои логи локально (хотя бы 1-2 дня). Это спасает при сбое сети или центрального коллектора. Настройте ротацию логов не по времени, а по размеру.

Примеры конфигурации для российского контекста

Настройка rsyslog с шифрованием для Linux

# Загрузка необходимых модулей
module(load="imuxsock")    # локальный syslog
module(load="imtcp")       # прием по TCP
module(load="omfwd")       # пересылка

# Шаблон с RFC 3339 timestamp для корректного парсинга
template(name="SecureFormat" type="string"
         string="%timestamp:::date-rfc3339% %hostname% %programname% %msg%")

# Правило: все сообщения с тегом 'audit' отправляем на центральный коллектор с шифрованием
if $programname == 'audit' then {
    action(
        type="omfwd"
        target="audit-collector.company.local"
        port="6514"
        protocol="tcp"
        StreamDriver="gtls"
        StreamDriverMode="1"
        StreamDriverAuthMode="x509/certvalid"
        StreamDriverPermittedPeers="*.company.local"
        template="SecureFormat"
    )
    # Останавливаем обработку, чтобы не дублировать в локальный файл
    stop
}

# Резервное правило: если коллектор недоступен, пишем в локальный буфер
if $programname == 'audit' then {
    action(type="omfile" file="/var/log/local-audit-buffer.log")
    stop
}

Настройка подписки событий Windows для централизованного сбора

# PowerShell: Создание подписки на события Security с фильтром
$SourceArgs = @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    # ID 4624 (Успешный вход), 4625 (Неудачный вход), 4663 (Доступ к объекту), 4700 (Изменение прав)
    ID = 4624, 4625, 4663, 4700
}

$TargetMachine = 'collector.company.local'
$SubscriptionName = 'CentralSecurityAudit'

# Создание объекта-фильтра
$FilterXml = @"
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
        *[System[(EventID=4624 or EventID=4625 or EventID=4663 or EventID=4700)]]
    </Select>
  </Query>
</QueryList>
"@

# Создание подписки (требует прав администратора на целевом коллекторе)
New-WinEvent -SubscriptionName $SubscriptionName `
             -Credential (Get-Credential) `
             -SourceAddress $env:COMPUTERNAME `
             -FilterXPath $FilterXml `
             -RemoteComputer $TargetMachine `
             -MaxBatchSize 1000 `
             -MaxLatencyTime 5000

Анализ: от сырых данных до инцидента

Собранные логи — это сырьё. Ценность появляется при анализе.

Уровни аналитики

  1. Автоматическая корреляция (SIEM): поиск известных паттернов атак (брутфорс, подбор учётных данных, горизонтальное перемещение). Здесь важна низкая ложноположительная rate.
  2. Поиск аномалий (UEBA): система учит нормальное поведение пользователя/хоста (время, ресурсы, объёмы) и флагует отклонения. Например, доступ к файловому серверу в 3 ночи или скачивание в 100 раз больше данных, чем обычно.
  3. Расследование инцидентов: ручной, но направленный поиск. При подозрении на компрометацию учётной записи аналитик строит временную линию всех действий этого пользователя: откуда логинился, к каким системам обращался, какие файлы открывал.
  4. Проактивный Threat Hunting: поиск скрытых угроз по гипотезам. Например, проверка всех процессов в сети на предмет подключения к известным C2-серверам из открытых списков угроз (Threat Intelligence).

Пример правила корреляции для Wazuh/Suricata

Обнаружение потенциальной попытки выполнения вредоносного PowerShell-скрипта (техника MITRE T1059.001).

<group name="windows,powershell,malware">
  <rule id="100100" level="10">
    <if_sid>61600</if_sid> <!-- Базовое событие PowerShell -->
    <field name="win.eventdata.scriptBlockText">IEX.*New-Object.*Net.WebClient</field>
    <description>PowerShell: Потенциально опасный скрипт с загрузкой из сети.</description>
    <mitre>
      <id>T1059.001</id>
      <tactic>execution, defense-evasion</tactic>
    </mitre>
  </rule>

  <rule id="100101" level="12">
    <if_sid>100100</if_sid>
    <match>DownloadString|Invoke-Expression</match>
    <description>PowerShell: Высоковероятная вредоносная активность - загрузка и выполнение кода.</description>
    <group>malware</group>
  </rule>
</group>
Скриншот дашборда Kibana или Grafana с визуализацией: топ источников угроз, карта сетевых соединений, график аномальной активности

Экономика и организация процесса

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

Статья расходов / экономии Описание и влияние
Капитальные затраты (CAPEX) Лицензии SIEM/SOAR, серверное оборудование для хранилища (расчёт от ~1 ТБ на 100 серверов в месяц), средства криптографической защиты информации (СКЗИ) для каналов передачи. Может быть значительной, но часто распределяется по годам.
Операционные затраты (OPEX) Поддержка инфраструктуры, облачное хранение логов (если используется), обучение и зарплата аналитиков SOC. Это постоянная статья. Автоматизация ответа (SOAR) снижает OPEX, сокращая время реакции на рутинные инциденты.
Избежание штрафов Штраф по 152-ФЗ для юрлиц — до 75 000 руб. За невыполнение предписаний регулятора КИИ — значительно выше. Наличие работоспособной системы аудита — ключевой аргумент при проверке.
Сокращение времени простоя (MTTR) При инциденте (например, падение критического сервиса) журналы позволяют найти первопричину не за дни, а за часы. Стоимость простоя бизнес-системы может исчисляться миллионами рублей в час.
Снижение репутационных потерь Утечка данных, обнаруженная не вами, а извне, подрывает доверие клиентов и партнёров. Возможность быстро обнаружить и локализовать утечку минимизирует ущерб.

Стартовать можно с малого: выделить критичные активы (домен, финансовые СУБД, шлюзы), настроить для них сбор ключевых событий в open-source стек (ELK, Wazuh, Graylog) и отработать процесс расследования на тестовых кейсах. Это даст понимание реальных объёмов данных и потребностей, на основе которых можно обоснованно планировать бюджет на полноценную коммерческую или масштабируемую open-source платформу.

Конечная цель — не гигабайты логов на диске, а ситуационная осведомлённость: способность в любой момент ответить на вопросы «Кто? Что? Когда? Откуда?» применительно к любой значимой операции в вашей инфраструктуре.

Загрузка…

Оставьте комментарий