TrueNAS не отдаёт файловый аудит в syslog и не помнит, что уже отдал. Собрали его в ELK поллером с курсором

Задача

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

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

Почему не получилось «просто включить отправку логов»

Три препятствия, каждое из которых меняет архитектуру:

1. Файловых операций нет в syslog. У TrueNAS два независимых потока: системный syslog (здоровье, служебное) и аудит (структурированный JSON во внутренней БД). Кто и что сделал с файлом — живёт только во втором, и достучаться до него можно только через API. Привычная схема «хранилище само шлёт логи в коллектор» здесь неприменима.

2. API — WebSocket, а не привычный HTTP-запрос. Поддерживаемый интерфейс — JSON-RPC поверх wss: соединение устанавливается один раз, вход по API-ключу, дальше запросы идут внутри него. Прежний REST-интерфейс объявлен устаревшим и удаляется в ближайших версиях, строить на нём новое нельзя.

3. Хранилище не помнит, что уже отдало. Оно отвечает на запрос «дай события» — и всё. Любой опрос без состояния тянет одно и то же окно снова и снова: лишний трафик, дубли в базе и при этом никакой гарантии, что ничего не потерялось между запросами. Позицию чтения обязан хранить тот, кто забирает.

Что сделали

• Поллер с курсором. Держит WebSocket-сессию, забирает только события новее сохранённой позиции, постранично — всплеск в десять тысяч событий выбирается целиком, за несколько страниц. Позиция пишется атомарно и переживает перезапуски.
• Не теряем при сбоях. Курсор сдвигается только после успешной передачи порции. Упал приёмник, оборвалась сеть, перезапустили разбор логов — сбор просто продолжится с той же точки.
• Не плодим дубли. Граничная секунда сознательно перечитывается — так не возникает дыр на стыке запросов, — а повторы гасятся дедупликацией по идентификатору события.
• Нормализация. События приводятся к общепринятой схеме полей, собирается полный сетевой путь (в исходном аудите путь относительный, а имя шары лежит отдельно), отсекается служебный шум — из ста с лишним тысяч сырых записей в сутки в базу попадает только то, что относится к файлам и данным.
• Сигнал «данные ушли». В SMB нет события «скопировал» — ни на уровне протокола, ни в аудите. Копирование определяем по закрытию файла с ненулевым объёмом чтения: это единственное место, где хранилище сообщает сколько байт реально прочитано. Пустые чтения и листинги каталогов отсекаются сами собой.
• Минимум прав. На хранилище заводится учётная запись только с правом читать аудит — без администраторских полномочий, без доступа к данным. Ключ хранится на стороне сбора.
• Срок хранения. На хранилище аудит держим коротким окном (неделя — этого достаточно, чтобы пережить любой простой сбора), в ELK — 180 дней с автоматическим управлением индексами.
• Масштабирование. Один процесс на одно хранилище, все шлют в общий приёмник и различаются меткой источника. Подключение следующего объекта — один конфигурационный файл, разбор и хранилище не трогаются.

Результат

События SMB в сутки с одного хранилища	~120 000
Шар под аудитом	22
Задержка «действие → поиск в Kibana»	~15 секунд
Потери при недоступности приёмника	нет — курсор не сдвигается
Дубли при повторной передаче	нет — дедупликация по идентификатору события
Права на хранилище	только чтение аудита
Хранение	180 дней в ELK (на самом хранилище — 7 дней)

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

Важное ограничение: подходит не любой TrueNAS

• TrueNAS SCALE 24.04 и новее — да. Аудит SMB-операций появился именно в этой линейке; решение проверено на 25.04.
• TrueNAS CORE (13.x и старше) — нет. Подсистемы аудита там нет в принципе: нужного API-метода не существует, и никакими правами или настройками он не появится. Пишется только журнал входов — файловых операций в нём нет.
• Что можно на CORE без обновления. Штатный модуль аудита Samba умеет писать файловые операции в syslog. Это рабочий путь, но другая система со слабее аналитикой: нет объёма прочитанных данных (то есть пропадает главный признак утечки), нет дедупликации, и доставка идёт «на выброс» — при обрыве канала события теряются. Годится как временная мера там, где обновление откладывается.
• Проверить пригодность можно за минуту, не имея паролей от хранилища, — по ответу API на служебный запрос сразу видно, какая это линейка.

Так что первый шаг на любом объекте — не установка, а проверка версии.

Чем можем помочь

Развернём сбор файлового аудита с ваших хранилищ TrueNAS в ELK: проверим пригодность версий, настроим права и аудит на шарах, поднимем сбор с гарантией «ничего не потеряно и ничего не задвоено», нормализуем события и соберём в Kibana панель с обнаружением массового копирования.

Если часть парка на CORE — скажем честно, что там возможно, а что нет, и предложим маршрут: обновление или временная схема.