Мониторинг и аудит доступа к хранилищу: настройка TrueNAS и ZFS в 2026

Аудит доступа к хранилищу отвечает на три вопроса: кто и когда работал с файлами, как менялись права и что происходило на дисках перед сбоем или утечкой. В TrueNAS SCALE 24.04 и новее базовый уровень собирается штатными средствами: свойством ZFS audit, аудитом SMB и пробросом syslog на отдельный хост. Внешний SIEM подключают на следующем шаге, когда нужны поиск по событиям, правила и алерты.

Дальше идут проверенные конфигурации: включение SMB- и NFS-аудита в TrueNAS SCALE, свойства ZFS audit и zpool history, правила auditd для контроля прав, приёмник логов на rsyslog, сравнение Graylog и ELK, готовые правила обнаружения аномалий и чек-лист запуска. Всё рассчитано на включение за один рабочий день и не требует платных компонентов.

Зачем нужен аудит доступа к хранилищу и какие задачи он решает

Логирование без хранения, разбора и уведомлений остаётся набором файлов на диске. Аудит это связка из четырёх элементов: сбор событий, централизованное хранение, правила разбора и оповещения. Уберите любой из них, и расследование инцидента превращается в догадки.

Практические сценарии, в которых аудит решает исход дела:

• Утечка через SMB-шару. Сотрудник скопировал клиентскую базу на личный ноутбук. Записи аудита дают учётную запись, IP клиента, время, имя файла и результат операции. Без них факт утечки недоказуем.
• Несанкционированное изменение прав. Команда вида chmod 777 или setfacl с записью everyone@:full_set:allow открывает датасет всем, у кого есть сетевой доступ. Аудит показывает автора команды и момент, когда доступ появился, значит можно оценить объём раскрытых файлов.
• Доступ бывшего сотрудника. Учётная запись в AD осталась активной, VPN-сертификат не отозван. Журнал фиксирует вход и список открытых файлов, это готовое доказательство для службы безопасности.
• Удаление снапшотов или датасетов. Операции zfs destroy и zpool destroy попадают в историю пула, что позволяет отличить ошибку администратора от сознательного вывода системы из строя.

Регуляторы требуют не сам факт логирования, а доказуемость контроля. GDPR в статьях 30, 32 и 33 требует реестр операций обработки, технические меры защиты и уведомление об утечке в течение 72 часов. PCI DSS 4.0 в требовании 10 обязывает отслеживать доступ к данным карт и хранить журналы 12 месяцев, из них последние 3 месяца должны быть доступны немедленно. ISO/IEC 27001:2022 в мерах A.8.15 и A.8.16 говорит о журналировании событий, мониторинге активности, защите журналов и синхронизации часов. Российские требования к операторам персональных данных опираются на 152-ФЗ и приказы ФСТЭК №21 и №17, где регистрация событий безопасности идёт отдельной мерой класса РСБ.

Есть и вторая сторона: аудит нужен на двух уровнях одновременно. Файловый уровень (SMB, NFS, POSIX ACL) показывает работу с содержимым, административный уровень (ZFS, zpool, zfs allow) показывает изменения правил целиком. Один уровень без второго оставляет слепую зону: смену ACL можно не заметить, а выданное делегированное право на уничтожение снапшотов вообще не отражается в файловых журналах.

Встроенные механизмы аудита в TrueNAS и ZFS

В TrueNAS SCALE журналирование живёт на трёх уровнях: файловые сервисы (SMB, NFS), пул ZFS и операционная система с её syslog и auditd. Уровни дополняют друг друга, и для полной картины нужны минимум два из трёх.

Настройка аудита SMB и NFS в TrueNAS SCALE

Через веб-интерфейс: Services → SMB → Edit, включите Enable Audit Logging и задайте путь журнала (по умолчанию /var/log/samba/audit.log). То же действие из командной строки:

midclt call smb.update '{"enable_audit": true, "audit_log_path": "/var/log/samba/audit.log"}'

Если нужен точный контроль над списком операций, добавьте в дополнительные параметры Samba модуль full_audit на уровне шары:

vfs objects = full_audit
full_audit:prefix = %u|%I|%S
full_audit:success = open close read write rename unlink mkdir rmdir chmod chown
full_audit:failure = open
full_audit:facility = LOCAL5
full_audit:priority = NOTICE

Шаблон %u подставляет пользователя, %I адрес клиента, %S имя шары. Записи уходят в syslog с меткой LOCAL5, и rsyslog забирает их так же, как остальные сообщения. Список операций стоит сокращать: чтение полного каталога на шаре с архивами даёт десятки тысяч записей в час без пользы для расследования.

Объём считайте заранее. Одно событие SMB-аудита в текстовом виде занимает 300-600 байт. На шаре, где работает два десятка человек, легко набегает сотни тысяч операций в сутки, то есть 0,3-0,6 ГБ в сутки и 10-18 ГБ в месяц. Включение аудита чтения на всех датасетах без разбора превращает журнал в мусор, а иногда и в причину замедления операций с метаданными.

Для NFS картина иная: встроенный аудит SMB протокол NFS не покрывает. Доступны два рабочих приёма. Первый: включить отладочные сообщения NFS-сервера на короткое время.

rpcdebug -m nfsd -s all
rpcdebug -m nfsd -c all

Первая команда включает вывод, вторая отключает. Поток огромный, поэтому применяйте его только для разбора конкретного инцидента и не оставляйте включённым на ночь. Второй приём это аудит на уровне файловой системы через auditd, о нём ниже. В новых ветках TrueNAS SCALE появилась единая страница Audit с записями SMB- и NFS-аудита и настройкой срока хранения; наличие этой страницы зависит от версии, проверьте её в своей сборке.

Использование ZFS audit и zpool history

История пула доступна всегда, настройка не требуется. Команда zpool history хранит каждый вызов zfs и zpool: создание и удаление датасетов, снапшоты, изменение свойств, экспорт и импорт, запуск scrub.

zpool history -il tank | tail -50
zpool history tank | grep -E 'destroy|snapshot|set'

Ключ -i добавляет внутренние события пула, -l печатает подробный формат с временными метками и аргументами команд. Это самый быстрый способ выяснить, кто удалил снапшот перед шифровальщиком.

Свойство audit появилось в OpenZFS 2.2, его несут TrueNAS SCALE 24.04 и более новые сборки. Записи складываются в сам пул, поэтому переустановка операционной системы их не уничтожает:

zfs set audit=all tank
zfs get audit tank/data

Что попадает в журнал: административные операции с датасетами, снапшотами и клонами, изменение свойств (quota, compression, readonly, recordsize), выдача и отзыв делегированных прав через zfs allow. Чего там нет: чтения и записи файлов, изменений POSIX или NFSv4 ACL на отдельных файлах. Для файловых событий нужны SMB-аудит, auditd или серверные логи NFS.

Включайте audit точечно. Если на пуле каждые 15 минут создаются автоматические снапшоты и работают плагины с сотнями вызовов zfs, число записей растёт быстро. Начните с пула, где лежат критичные датасеты и где административные операции редки, значит любая из них заметна.

Готовые правила для аудита команд zfs и zpool через auditd, включая контроль удаления снапшотов и выдачи делегированных прав, разобраны в инструкции по аудиту безопасности ZFS на TrueNAS.

Логирование операций доступа: от syslog до специализированных решений

TrueNAS держит локальные журналы в /var/log. Обновление системы, переустановка, ошибка администратора или компромисс с правами root уничтожают их. Аудиторские записи нужно уводить на отдельный хост сразу, до того как они понадобятся для разбора.

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

В TrueNAS SCALE надёжнее идти через интерфейс: System Settings → Advanced → Syslog Server, там же выбирается транспорт UDP, TCP или TLS. Эти значения хранятся в конфигурации системы и переживают обновления, тогда как ручная правка /etc/rsyslog.conf может быть перезаписана.

Когда нужен полный контроль над форматом, правило добавляют в конец /etc/rsyslog.conf на самом NAS:

*.* @@logsrv.example.net:514
local5.* @@logsrv.example.net:514

Двойная собака означает TCP, одиночная UDP. Вторая строка отправляет отдельно всё, что помечено меткой LOCAL5, то есть записи full_audit. На приёмнике настраивают модуль imtcp, шаблон имени файла и правило записи:

module(load="imtcp")
input(type="imtcp" port="514" ruleset="remote")

template(name="PerHost" type="string"
  string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

ruleset(name="remote") {
  action(type="omfile" dynaFile="PerHost")
}

Проверка занимает минуту: на NAS выполните logger -t audittest "test message", на приёмнике посмотрите tail -f /var/log/remote/имя-хоста/2026-09-13.log. Файлы по хостам упрощают поиск и ротацию.

Открытый syslog в сети это дыра в доказательной базе: любой, кто получил доступ к сегменту, может подделать записи. Для TLS используйте драйвер gtls с взаимной проверкой сертификатов:

module(load="imtcp" StreamDriver.Name="gtls"
  StreamDriver.Mode="1" StreamDriver.Authmode="x509/name")

Плюс настройте дисковую очередь на отправителе, иначе при недоступности приёмника сообщения молча теряются, а после перезагрузки пропадают совсем:

action(type="omfwd" target="logsrv.example.net" port="6514"
  protocol="tcp" queue.type="disk" queue.filename="fwdq"
  queue.saveonshutdown="on" action.resumeRetryCount="-1")

Сравнение Graylog и ELK для аудита хранилища

Оба стека принимают syslog и умеют искать по событиям, разница в стоимости входа и в требованиях к железу.

Сборщики логов тоже различаются: Fluent Bit заметно легче Logstash по памяти и подходит для отправки в несколько приёмников одновременно, Logstash даёт больше фильтров и разбор grok. Graylog удобен там, где администратор хочет видеть поток событий и настраивать правила мышкой. ELK и OpenSearch берут, когда нужны дашборды, связи между индексами и запросы к полям. Loki стоит брать под большие объёмы, если по логам нужно в основном считать частоты и фильтровать по меткам, а не искать по подстроке в старых данных.

Приёмник логов держите отдельно от NAS: смысл централизации в том, что журналы остаются доступны даже при потере сервера хранения. Для этого хватает облачного сервера с 4-8 ГБ памяти и диском под индексы, например Timeweb Cloud даёт VDS и объектное хранилище, куда удобно выносить архив индексов и снапшоты.

Отслеживание изменений прав доступа в ZFS и TrueNAS

Изменение прав это самый тихий способ получить доступ: одна команда chmod 777 или setfacl с записью everyone@:full_set:allow открывает датасет всем, у кого есть сетевой доступ. В ZFS права живут в метаданных, поэтому смотреть нужно на двух уровнях: файловом (POSIX ACL и NFSv4 ACL) и административном (делегирование через zfs allow).

Использование auditd для мониторинга прав в Linux

TrueNAS SCALE основан на Debian, поэтому auditd ставится через apt. Учитывайте риск: обновления системы возвращают часть пакетов и конфигураций к штатному состоянию, поэтому правила храните отдельным файлом и применяйте их после каждого апгрейда. Иначе аудит тихо отключится, а вы узнаете об этом только при разборе инцидента.

apt install auditd
augenrules --load

Набор правил для контроля прав выглядит так:

-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_change
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -k owner_change
-a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr -k acl_change
-w /mnt/tank/finance -p wa -k data_access
-w /usr/sbin/zfs -p x -k zfs_admin

Первые три правила ловят chmod, chown и работу с расширенными атрибутами, через которые действует setfacl. Фильтр auid>=1000 и auid!=4294967295 отсекает системные процессы без пользовательской сессии: без него журнал заполнят записи от systemd, cron и самого Samba. Правило с ключом data_access фиксирует запись и изменение атрибутов в каталоге, но не читает содержимое файлов. Последняя строка следит за запуском zfs, это связка файлового и административного уровней.

Загрузка и разбор событий:

augenrules --load
ausearch -k perm_change -ts today -i
aureport -k -i

Ограничение, о котором забывают: auditd работает на уровне системных вызовов. Он видит команды из shell и скриптов на самом NAS, но не разбирает протокольные операции SMB и NFS, потому что запрос клиента обрабатывает smbd или nfsd, и связь «пользователь - файл» на уровне syscall уже потеряна. Для файловых шар нужен аудит SMB. Расширенные наборы правил и их связка с SIEM разобраны в руководстве по auditd для аудита ZFS на TrueNAS.

Мониторинг изменений ACL в SMB через TrueNAS

После включения аудита SMB записи об изменении прав приходят отдельным типом события (в терминах Samba это set_sec). Обязательные поля: пользователь и домен, IP клиента, имя шары, путь, результат, время операции. Набор полей зависит от версии TrueNAS, но структура остаётся такой:

{"ts":"2026-09-13T09:41:12Z","event":"set_sec","user":"CORP\\ivanov",
 "client_ip":"10.10.4.23","share":"finance","path":"/mnt/tank/finance/reports",
 "result":"success"}

Практика подсказывает включать события ACL change отдельно от чтения и записи. Изменений прав на зрелой инфраструктуре немного: десятки в месяц на датасет. Такой поток легко читать глазами и легко превратить в правило алертинга, чего не скажешь о миллионе операций чтения. Дополнительно проверяйте права по расписанию, а не только по событиям: чек-лист регулярного аудита прав в NFS, SMB и iSCSI с командами проверки собран в отдельном материале по аудиту безопасности TrueNAS.

Второй канал изменений это делегирование ZFS. Проверить и изменить его можно так:

zfs allow tank/data
zfs allow -u backupuser snapshot,mount tank/data
zfs unallow -u backupuser tank/data

Выдача прав через zfs allow равносильна передаче административных возможностей: пользователь сможет уничтожать снапшоты или монтировать датасеты в обход файловых прав. Каждое такое изменение должно попадать в журнал ZFS и вызывать уведомление, потому что последствия шире, чем у обычного chmod.

Выявление аномальной активности на основе логов

Правило без базовой линии даёт шум. Сначала соберите статистику за две недели: сколько операций записи, удаления и переименования делает каждая учётная запись, из каких подсетей приходит, в какие часы работает. Дальше аномалия это отклонение от нормы, а не любое событие из списка.

Признаки, которые на практике дают настоящие инциденты:

• Удаление или переименование сотен файлов за минуту одной учётной записью (почерк шифровальщика).
• Обращения к датасету с персональными данными вне рабочих часов и из подсети, где нет рабочих станций отдела.
• Изменение ACL в корне шары, на каталогах бэкапов и на системных путях.
• Серия неудачных аутентификаций, после которой идёт успешный доступ к конфиденциальной шарe.
• Массовое чтение файлов учётной записью, которая раньше открывала единичные документы (выкачивание базы перед увольнением).
• Сервисные учётные записи (бэкап, антивирус, индексатор) обращаются к шарам, которых нет в их профиле.

Правила обнаружения в Graylog

Pipelines в Graylog разбирают сообщение и помечают его, а Event Definitions считают события и создают алерт. Пример правила, которое помечает изменение ACL на критичной шарe:

rule "ACL change on finance share"
when
  has_field("event") && to_string($message.event) == "set_sec" &&
  has_field("share") && to_string($message.share) == "finance"
then
  set_field("alert_severity", "high");
end

Второе правило проверяет подсеть, из которой пришёл запрос, и ловит доступ с адресов вне офисных диапазонов:

rule "Finance share from outside office subnet"
when
  has_field("client_ip") && has_field("share") &&
  to_string($message.share) == "finance" &&
  !cidr_match("10.10.0.0/16", to_ip(to_string($message.client_ip)))
then
  set_field("alert_severity", "high");
end

Пороговые сценарии удобнее выносить в Event Definitions с агрегацией, а не в пайплайны. Рабочие условия: count() больше 5 за 5 минут с группировкой по полю user при поисковом запросе event:auth_failure (подбор пароля), count() больше 200 уникальных путей за 5 минут по полю user (массовое чтение), count() больше 50 событий event:unlink за минуту по полю user (работа шифровальщика). Пайплайны держите дешёвыми: проверка через has_field перед обращением к полю экономит обработку на больших потоках.

Использование ElastAlert для ELK

В бесплатной версии Elasticsearch Watcher недоступен, поэтому для алертов в ELK ставят ElastAlert2. Правило описывается одним YAML-файлом:

name: Suspicious deletions in finance
type: frequency
index: filebeat-*
num_events: 10
timeframe:
  minutes: 1
filter:
- term:
    share: finance
- terms:
    event.action: ["delete", "rename"]
alert:
- "slack"
- "email"

Кроме типа frequency полезны два: cardinality (одна учётка коснулась более 200 уникальных путей за 5 минут) и new_term (первое появление нового IP клиента в шарe с персональными данными). Для алертов без шума добавьте список исключений: сервисные учётные записи бэкапа и антивируса, задачи репликации, окна обслуживания.

Разбор подозрительного интервала ускоряет модель: выгрузите записи за час и попросите LLM сгруппировать их по сессиям и выделить необычные. Доступ к GPT, Gemini, Claude и ещё более чем двумстам моделям через один API с оплатой в рублях и без VPN даёт AiTunnel, что удобно, если не хочется держать собственный инференс. Логи с персональными данными перед отправкой во внешний сервис обезличивайте.

Настройка уведомлений о подозрительных событиях

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

Встроенные уведомления TrueNAS

System → Email задаёт SMTP сервер, порт, отправителя и получателей. System → Alert Services добавляет каналы: Slack, Telegram, PagerDuty, Opsgenie, произвольный webhook. System → Alert Settings включает нужные категории и уровень (Warning или Critical), чтобы не получать письма о каждой неудачной проверке обновлений. Пошаговая настройка SMTP, webhook и Telegram разобрана в материале по алертингу в TrueNAS.

Важное ограничение: штатные алерты TrueNAS реагируют на состояние системы (деградация пула, ошибки SMART, сбои репликации, проблемы с сертификатами). Содержимое файловых журналов в эти триггеры не входит, поэтому события ACL и удаления файлов должны идти через внешний SIEM. Если у вас уже есть собственный парсер логов, разовое уведомление можно создать из скрипта через middleware, синтаксис аргументов сверяйте с версией:

midclt call alert.oneshot_create '{"klass": "AuditAlert", "args": {"path": "/mnt/tank/finance"}}'

Интеграция Graylog с Slack и Telegram

Slack: создайте Incoming Webhook в рабочем пространстве, затем в Graylog откройте Alerts → Notifications → Create notification → Slack, вставьте URL вебхука, укажите канал вида #sec-alerts и нажмите Execute Test. Уведомление привязывается к Event Definition, поэтому одно правило может рассылать сообщения в разные каналы с разной срочностью.

Telegram: получите у бота token и chat_id, после чего добавьте уведомление типа HTTP Notification с вызовом метода sendMessage Bot API Telegram и параметрами chat_id и text. Отдельного коннектора в Graylog Open нет, поэтому применяют HTTP-уведомление или сторонний плагин. То же самое делается в ElastAlert через тип оповещения telegram.

Два параметра экономят нервы. Первый это backlog у уведомления Graylog: он ограничивает число сообщений, отправляемых одним срабатыванием (по умолчанию порядка 30). При шторме событий он работает как защита чата, но часть сообщений теряется, поэтому критичные правила лучше вести отдельным каналом. Второй это эскалация: Slack для дежурного, Telegram для руководителя, звонок при повторном срабатывании правила в течение часа. Токены ботов и вебхуки храните с ограниченными правами на файлы конфигурации и отзывайте при смене состава команды.

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

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

Сроки хранения и ротация логов аудита

auditd ротируется сам, параметры задаются в /etc/audit/auditd.conf: max_log_file (например, 200 МБ), num_logs (например, 50), max_log_file_action = keep_logs. Опасны disk_full_action и disk_error_action: при значении HALT служба останавливает сервер, когда журнал некуда записать. Для продакшена выбирайте SUSPEND или SINGLE и следите за свободным местом алертом заранее.

Для файловых журналов настройте logrotate:

/var/log/samba/audit.log {
  daily
  rotate 90
  compress
  missingok
  notifempty
  create 0600 root root
}

В Graylog срок хранения задаётся в Index Set: ротация по размеру (20-30 ГБ) или по времени, retention policy удаляет индексы старше срока. Архивация в объектное хранилище относится к Enterprise-версии, в открытой данные живут в OpenSearch и удаляются по политике без выгрузки. В ELK то же самое делается через ILM-политику с фазами hot, warm и delete плюс snapshot repository для долгосрочного хранения.

Планируйте диски по потоку событий. 1 млн событий SMB-аудита в сутки это 0,3-0,6 ГБ в исходном виде и 10-18 ГБ в месяц; Elasticsearch или OpenSearch с индексами и одной репликой увеличат это в 1,5-2 раза. Для хранения за 12 месяцев при таком потоке нужен узел с 300-500 ГБ под индексы. Если включаете аудит чтения на архивных шарах, умножьте оценку на 5-10.

Защита целостности логов

• Отдельный приёмник с учётной записью, у которой есть права только на запись. Администратор NAS не должен иметь возможности удалять журналы на сервере логов.
• TLS с взаимной аутентификацией: rsyslog с драйвером gtls, режимом 1 и Authmode x509/name. Без шифрования записи можно подделать или выбросить из потока.
• Защита файлов от перезаписи: chattr +a на каталоге приёмника плюс ротация только через отдельную службу с повышенными правами.
• Хеш-цепочка: для каждого закрытого файла журнала считайте sha256sum и храните значение вне системы (в системе тикетов, в git-репозитории у ответственного). Проверка архива на подмену становится тривиальной.
• WORM или объектное хранилище с неизменяемостью (S3 Object Lock) для архива. Запись нельзя удалить до истечения срока даже с правами root.
• Снапшоты ZFS для локальной копии журналов: zfs snapshot tank/logs@$(date +%F) и zfs hold keep tank/logs@2026-09-13, чтобы случайный zfs destroy не унёс единственную копию.

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

Типичные ошибки и ограничения при настройке аудита

1. Включение всех событий сразу. Аудит чтения на всех шарах увеличивает объём журналов в десятки раз и заметно снижает скорость операций с метаданными. Начинайте с шар с персональными данными и отчётностью, логируйте удаление, переименование, изменение прав, чтение включайте точечно.
2. Локальное хранение логов. Компромисс с правами root на NAS уничтожает или подделывает записи. Удалённый приёмник это обязательный элемент схемы, а не улучшение.
3. Отсутствие ротации. Переполнение /var/log на TrueNAS SCALE ломает обновления и работу служб, потому что системный раздел небольшой. Настройте num_logs для auditd, logrotate для файловых журналов и retention в SIEM до включения аудита.
4. Опора только на auditd. Системные вызовы не содержат информации о том, какой пользователь через SMB открыл файл. Комбинируйте auditd с аудитом SMB.
5. Пороги без базовой линии. Репликация, индексатор и антивирус дают регулярные пики чтения и записи. Без белого списка сервисных учёток алерты приходят каждые несколько минут и перестают читаться.
6. Несовместимость версий. Свойство audit требует OpenZFS 2.2 и новее, то есть TrueNAS SCALE 24.04 и новее; на старых сборках zfs set audit вернёт ошибку о неверном свойстве. Проверяйте версии до настройки: zfs version и midclt call system.version.
7. Отсутствие синхронизации времени. Без NTP события на NAS и в SIEM сопоставляются с ошибкой в минуты, и хронология инцидента рассыпается. Один источник времени и один часовой пояс (UTC) на всех узлах.
8. Аудит без регламента. Если журналы никто не смотрит, аудит существует для галочки. Назначьте ответственного и частоту: критичные события ежедневно, статистика и пересмотр порогов еженедельно.

Чек-лист внедрения аудита доступа к хранилищу

1. Опишите критичные данные: датасеты с персональными данными, финансовой отчётностью, бэкапами и ключами. Для остальных оставьте минимальный набор событий.
2. Сверьте версии: zfs version и midclt call system.version. Убедитесь, что сборка поддерживает свойства audit и страницу Audit.
3. Включите аудит SMB: midclt call smb.update '{"enable_audit": true, "audit_log_path": "/var/log/samba/audit.log"}', затем проверьте запись тестовым действием.
4. Включите ZFS audit на пулах с критичными датасетами: zfs set audit=all tank, статус проверьте через zfs get audit tank.
5. Настройте auditd: правила на chmod, chown, setxattr, каталоги критичных данных и бинарник zfs. Загрузите через augenrules --load и проверьте ausearch -k perm_change -ts today.
6. Разверните приёмник логов: rsyslog с TLS и отдельным файлом на хост, затем Graylog, ELK, OpenSearch или Loki по масштабу и бюджету.
7. Создайте правила обнаружения: удаление и переименование пачками, доступ вне рабочих часов, изменение ACL в корне шар, серия неудачных аутентификаций, доступ с нового адреса к критичной шарe.
8. Настройте уведомления: email и мессенджер для критичных правил, отдельный канал для менее срочных, эскалация при повторе в течение часа.
9. Зафиксируйте хранение и защиту: retention под требования регулятора, TLS с взаимной аутентификацией, снапшоты и hold для локальных журналов, хеш-цепочка для архивов.
10. Проверьте аудит на практике: измените права на тестовом файле, удалите тестовый снапшот, зайдите под сервисной учёткой. Каждое действие должно дойти до SIEM и породить ожидаемое уведомление.

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