Мониторинг доступа к критичным данным: аудит файлов и баз, события защиты данных в Wazuh

Разграничение доступа отвечает на вопрос «кому можно», а мониторинг на другой: «кто на самом деле обращался». Без него нельзя заметить, что бухгалтер выгрузил всю клиентскую базу, что учётная запись уволенного читает кадровые файлы или что копирование началось ночью. При этом включать аудит «на всё» бессмысленно: журнал растёт гигабайтами, а в нём ничего не найти. Ниже как выбрать, что контролировать, как включить аудит файлов, баз данных и Linux-каталогов, как написать правила Wazuh на значимые сценарии, как подкрепить их файлами-ловушками и как регулярно проверять, что события действительно доходят.

Подключение журналов и общая настройка Wazuh: журналы сетевых средств в Wazuh, аномалии доступа. Журналы ИСПДн: регистрация событий и аудит. Что считать критичными данными: реестр защищаемой информации.

Что хотим получить

Начните с короткого списка: 5–10 каталогов и таблиц, где лежат самые ценные данные (клиентская база, кадровые файлы, финансовая отчётность). Для них включается подробный аудит, для остального обычный журналирование входов. Список берётся из реестра защищаемой информации, а не из головы администратора.

Шаг 1. Файловый сервер Windows

Включите аудит доступа к файловой системе и задайте, какие каталоги и какие действия записывать:

auditpol /set /subcategory:"File System" /success:enable /failure:enable
auditpol /get /subcategory:"File System"

$path = 'D:\Data\HR'
$acl  = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
          'Everyone', 'ReadData,WriteData,Delete,ChangePermissions',
          'ContainerInherit,ObjectInherit', 'None', 'Success')
$acl.AddAuditRule($rule)
Set-Acl $path $acl

Ожидаемо: вторая команда показывает аудит успехов и отказов, а при открытии файла в каталоге HR в журнале безопасности появляется событие 4663 с именем пользователя, файла и типом доступа. Удаление фиксируется событием 4660, изменение прав — 4670. Риск: аудит чтения на каталоге с тысячами пользователей создаёт огромный поток событий; ограничьтесь критичными папками и действиями. Политику можно распространять групповой политикой: GPO и Ansible.

Посмотреть, кто чаще всего обращается к каталогу, можно прямо на сервере:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddHours(-24)} |
  ForEach-Object { $x=[xml]$_.ToXml(); ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Count, Name

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

Шаг 2. Каталоги Linux: auditd и FIM

# /etc/audit/rules.d/data.rules
-w /srv/data/hr -p rwxa -k hr_data
-w /srv/data/finance -p rwxa -k finance_data

sudo augenrules --load
sudo ausearch -k hr_data --start today -i | tail -n 20
sudo aureport -f -i --start today --summary | head

Ожидаемо: в выводе ausearch видны события чтения и записи с именем пользователя и программой; aureport показывает сводку по файлам. Правила аудита должны быть частью базовой настройки: правила auditd. Для изменений и удалений в каталогах с критичными файлами удобен и контроль целостности Wazuh с записью «кто сделал»:

<syscheck>
  <directories whodata="yes" check_all="yes">/srv/data/hr,/srv/data/finance</directories>
</syscheck>

Ожидаемо: после перезапуска агента создание, изменение и удаление файлов в этих каталогах порождают оповещения с именем пользователя и процессом. FIM не фиксирует простое чтение: для него нужен auditd.

Шаг 3. База данных: pgaudit

Журнал обращений к таблицам с персональными данными нужен не меньше, чем к файлам. Для PostgreSQL подходит расширение pgaudit: объектный аудит записывает обращения только к тем таблицам, на которые выдан доступ специальной роли.

# postgresql.conf
shared_preload_libraries = 'pgaudit'
pgaudit.role = 'auditor'
pgaudit.log_parameter = off

-- в базе
CREATE ROLE auditor NOLOGIN;
GRANT SELECT, UPDATE, DELETE ON customers TO auditor;     -- таблица с ПДн

sudo systemctl restart postgresql
sudo grep AUDIT /var/log/postgresql/postgresql-16-main.log | tail -n 5

Ожидаемо: после обращения к таблице customers в журнале появляется строка AUDIT: OBJECT,...,SELECT,... с именем пользователя и запросом. Параметр log_parameter = off не записывает значения запросов, чтобы журнал сам не стал хранилищем персональных данных. Общая настройка защиты СУБД: безопасная настройка PostgreSQL. Для других СУБД есть свои механизмы аудита, для облачных баз — журналы доступа сервиса.

Шаг 4. Правила Wazuh

События уже собираются, теперь нужно научить систему замечать важное. Ниже три правила (синтаксис и проверка: аномалии доступа).

<group name="local,windows,data,">

  <!-- обращение к критичному каталогу -->
  <rule id="100300" level="3">
    <if_group>windows</if_group>
    <field name="win.system.eventID">^4663$</field>
    <field name="win.eventdata.objectName">D:\\Data\\HR</field>
    <description>Доступ к каталогу HR: $(win.eventdata.subjectUserName) -> $(win.eventdata.objectName)</description>
  </rule>

  <!-- массовое чтение: 200 обращений одного пользователя за минуту -->
  <rule id="100301" level="12" frequency="200" timeframe="60">
    <if_matched_sid>100300</if_matched_sid>
    <same_field>win.eventdata.subjectUserName</same_field>
    <description>Массовое чтение каталога HR пользователем $(win.eventdata.subjectUserName)</description>
    <mitre><id>T1530</id></mitre>
  </rule>

  <!-- изменение прав доступа к файлам -->
  <rule id="100302" level="10">
    <if_group>windows</if_group>
    <field name="win.system.eventID">^4670$</field>
    <field name="win.eventdata.objectName">D:\\Data</field>
    <description>Изменены права на объект $(win.eventdata.objectName) пользователем $(win.eventdata.subjectUserName)</description>
  </rule>

</group>

Ожидаемо: единичные обращения дают событие низкого уровня, массовое чтение — оповещение уровня 12. Порог в 200 событий за минуту условный: нормальная работа с каталогом в вашей организации может быть и выше, и ниже, поэтому первые две недели смотрите на фактические значения. Имена каталогов в регулярных выражениях пишите свои, с двойным обратным слешем. Сценарии для Linux строятся так же на событиях auditd и FIM: типичный признак выгрузки — резкий рост числа чтений одним пользователем или копирование архива.

Шаг 5. Файлы-ловушки

Самое дешёвое средство обнаружения — файлы, которыми никто не должен пользоваться. В критичные каталоги кладутся несколько приманок с привлекательными именами («Зарплаты_2026.xlsx», «пароли.txt»). Легитимные пользователи их не открывают, поэтому любое обращение — повод проверить. Для Windows на такие файлы ставится аудит чтения, а правило Wazuh срабатывает на любой доступ с высоким уровнем:

<rule id="100303" level="12">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4663$</field>
  <field name="win.eventdata.objectName">Зарплаты_2026\.xlsx$</field>
  <description>Обращение к файлу-ловушке: $(win.eventdata.subjectUserName)</description>
</rule>

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

Шаг 6. События защитных средств в SIEM

Интеграция с SIEM нужна не только для событий доступа, но и для самих средств защиты данных: изменения политик, отказы резервного копирования, подключение съёмных носителей, срабатывания DLP. Это вторая часть задачи: если защита ломается молча, мониторинг доступа бесполезен.

Регулярная проверка доставки и оповещений

Мониторинг, который не проверяли, считается работающим до первого инцидента, когда выясняется обратное. Раз в месяц запускайте тест: искусственное событие, на которое должно прийти оповещение. Для Linux с FIM удобен скрипт:

#!/usr/bin/env bash
# canary_test.sh: проверка цепочки "изменение файла -> оповещение Wazuh"
FILE=/srv/data/hr/.canary_$(date +%s)
touch "$FILE" && echo test > "$FILE"
sleep 120
if sudo grep -q "$FILE" /var/ossec/logs/alerts/alerts.json; then
  logger -t canary-test "OK: событие $FILE дошло до Wazuh"
else
  logger -t canary-test "ПРОВАЛ: событие $FILE не найдено в оповещениях"; exit 1
fi
rm -f "$FILE"

Ожидаемо: в журнале запись «OK»; код выхода 1 при сбое. Скрипт запускается на сервере Wazuh (для файла на агенте проверьте через API или перенесите проверку на нужный узел). Результаты ежемесячных проверок сохраняйте: они подтверждают, что система мониторинга исправна. Общая проверка доставки: проверка доставки событий.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Безопасность данных» (хаб: безопасность данных, карта: карта зрелости), смежное направление — мониторинг. На втором уровне для мониторинга доступа к критичным данным используются автоматизированные решения (встроенные средства ОС, системы управления доступом); на четвёртом решения защиты данных интегрированы с SIEM, а корректность передачи событий и оповещений регулярно проверяется. Конфигурации, журналы, примеры нарушений и результаты проверок — подтверждения.

Как проверить

1. Открытие файла в критичном каталоге тестовой учётной записью порождает событие 4663 или запись auditd.
2. Искусственное массовое чтение вызывает оповещение о массовом доступе.
3. Обращение к файлу-ловушке вызывает оповещение высокого уровня.
4. Тест доставки за последний месяц выполнен, результат сохранён.
5. Для последнего оповещения есть запись о разборе: что было, что решили.

Источники

• Microsoft Learn, аудит доступа к объектам файловой системы: learn.microsoft.com.
• pgaudit, документация: github.com/pgaudit/pgaudit.
• Wazuh, контроль целостности файлов и whodata: documentation.wazuh.com.
• CIS Control 3, защита данных, и Control 8, журналы аудита: cisecurity.org/controls.