Аудит безопасности TrueNAS и ZFS: цели, направления и практические сценарии

Что такое аудит безопасности системы хранения и зачем он нужен

Аудит безопасности системы хранения на базе TrueNAS и ZFS отвечает на четыре вопроса: кто получает доступ к данным, какие операции с ними разрешены, защищены ли данные при хранении и передаче, и остаётся ли след этих операций в журналах. Результат проверки: список рисков с приоритетами, сроками устранения и ответственными. Формальный акт для отчётности задачу не решает.

Три риска, ради которых аудит проводят регулярно: утечка через открытую шару или аккаунт с лишними правами, потеря данных после ошибочного удаления или отказа пула, несоответствие требованиям при обработке персональных данных. С 2025 года штрафы за утечку персональных данных выросли до 3% годовой выручки компании (разбор Приказа ФСТЭК №21).

Внутренний аудит показывает, насколько эффективно работает система управления безопасностью, где остаются риски и что стоит улучшить (описание программы для внутренних аудиторов). Разовая проверка даёт срез на сегодняшний день. Устойчивый контур держится на цикле: фиксированный чек-лист, периодичность, запись результатов, повторная проверка найденных замечаний. Как формулировать измеримые цели для инфраструктуры, разобрано в статье про цели аудита безопасности для DevOps и системных администраторов.

Чем аудит NAS отличается от аудита обычного сервера

Сервер и сетевое хранилище проверяют по разным чек-листам, потому что у них разная модель угроз и разные точки отказа.

Доступ идёт по сети, а не через локальные учётные записи. К хранилищу подключаются сотни клиентов по SMB и NFS. В аудит входят экспорты NFS, список шар, версии протоколов, разрешён ли гостевой доступ и включено ли подписывание SMB.
Права живут на уровне файловой системы. В ZFS ACL наследуются от родительского датасета к дочерним, но наследование переопределяется на любом уровне. Проверять приходится фактическую матрицу доступа, а не только настройки в веб-интерфейсе.
Состояние данных важнее состояния служб. Цепочка снапшот, реплика, восстановление проверяется целиком. Аудит обычного сервера чаще ограничивается бэкапами и обновлениями ОС.
Конечные устройства вне контроля. Пользователь может скопировать файл на ноутбук. Журнал хранилища подтвердит факт чтения, но не дальнейшую судьбу копии. Отсюда повышенное внимание к минимально необходимым правам.
Шире поверхность администрирования. У TrueNAS есть веб-интерфейс с ролевым доступом, CLI и root-доступ к ZFS. Проверяется, кто и как получает эти права, заведена ли отдельная учётная запись для каждого инженера.

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

Ключевые цели аудита TrueNAS и ZFS

Защита данных от несанкционированного доступа. Риск: файлы читает тот, кому они не предназначены. Проверяют ACL на датасетах, гостевой доступ к шарам, список хостов в экспортах NFS.
Контроль доступа к датасетам и шарам. Риск: наследование прав рушит модель доступа, и права получают посторонние группы. Сверяют права с матрицей доступа, маски ACL и флаги наследования.
Проверка шифрования. Риск: диски или резервные копии покидают защищённый контур, а ключи лежат рядом с данными. Проверяют статус шифрования датасетов, порядок выдачи и ротации ключей.
Аудит SMB/NFS-шар. Риск: инцидент невозможно разобрать, потому что журналы доступа не ведутся. Проверяют список шар, версии протоколов, настройки аудита и срок хранения логов.
Проверка снапшотов и репликации. Риск: данные удалены или зашифрованы вымогателем, восстанавливать нечего. Проверяют расписание, срок хранения, целостность снимков и тестовое восстановление.
Соответствие требованиям регуляторов. Риск: предписания и штрафы. Проверяют, какие меры из чек-листа закрыты настройками хранилища, а какие остались только на бумаге.

Контроль доступа к датасетам и шарам

Разграничение прав - основа защиты данных в ZFS. Права наследуются от родительского датасета, но переопределяются на любом уровне, поэтому фактическая картина доступа часто расходится с проектной. В TrueNAS права задаются через ACL для SMB и NFS, плюс действуют POSIX-права и маски. Аудит проверяет три вещи: соответствие прав политике доступа, отсутствие избыточных разрешений и корректность наследования. Правила идентификации пользователей и разграничения их прав к данным входят в обязательные требования Приказа ФСТЭК №21. Практические конфигурации NFS, SMB и iSCSI с чек-листом собраны в руководстве по аудиту прав доступа и шифрования в TrueNAS.

Проверка прав доступа после миграции

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

До переноса выгрузите текущие права: для каждого датасета сохраните вывод getfacl с рекурсией и сохранением порядка, чтобы было с чем сравнивать. Список датасетов удобно получить через zfs list.
После переноса повторите выгрузку и сравните файлы. Расхождения покажут, где права потерялись или расширились.
Проверьте наследование: у дочерних датасетов и новых каталогов права должны совпадать с замыслом, а не с настройками по умолчанию.
Сверьте маски ACL. Маска урезает эффективные права, и при её переносе доступ может внезапно появиться у групп, которым он не нужен.
Убедитесь, что пользователи и группы сопоставлены корректно: одна и та же учётная запись на источнике и приёмнике должна иметь одинаковые UID и SID.
Проверьте доступ практически: зайдите под учётной записью обычного пользователя, попробуйте открыть файл из критичного датасета и записать новый.

Типичная ошибка: при переносе между разными ОС или между CORE и SCALE числовые идентификаторы пользователей не совпадают. Права формально сохранены, но применяются к другим людям. Решение: централизованная аутентификация через LDAP или Active Directory до начала миграции, а не после. Тогда идентификаторы не зависят от локальной базы хранилища.

Аудит журналов доступа к критичным данным

Журналы нужны для одного: ответить на вопрос, кто читал этот файл перед инцидентом. Без них расследование упирается в догадки. В TrueNAS события файлового доступа собираются через аудит SMB и NFS и системные журналы; настройка и отправка логов во внешнее хранилище описаны в руководстве по настройке аудита доступа к хранилищу.

Неудачные попытки входа и подключения к шаре. При доменной аутентификации такие события удобно забирать с контроллера домена: неудачному входу в Windows Security log соответствует код 4625.
Обращения к каталогам с критичными данными: кто читал, когда и с какого адреса.
Изменения прав и владельцев. Смена ACL на критичном датасете почти всегда требует разбора.
Массовое чтение. Резкий рост числа открытий файлов под одной учётной записью за короткое время похож на копирование базы перед уходом сотрудника.

Что даёт журнал на практике: можно подтвердить или опровергнуть факт доступа, оценить объём скопированного и передать данные в службу безопасности. Что журнал не даёт: он не покажет, куда именно ушла копия, если за пределами хранилища нет своих средств контроля. Регистрация событий безопасности входит в чек-лист Приказа ФСТЭК №21, поэтому для систем с персональными данными журнал хранилища становится ещё и доказательством соответствия.

Шифрование данных в TrueNAS и ZFS

ZFS шифрует данные на уровне датасета: ключ привязан к конкретному датасету, а не ко всему пулу. Цели аудита здесь простые: критичные данные должны быть зашифрованы, ключи должны храниться вне самого хранилища, шифрование не должно быть отключено «временно» и забыто.

Статус шифрования: для критичных датасетов проверяют, что шифрование включено и что при создании дочерних датасетов оно не снято.
Хранение ключей: парольная фраза или файл ключа не должны лежать на том же сервере рядом с данными. Практичный вариант: ключ в защищённом внешнем хранилище, доступ к нему у ограниченного круга инженеров.
Ротация: при увольнении администратора с доступом к ключам ключи меняют. Проверяют, что процедура описана и выполняется.
Шифрование при передаче: трафик SMB и репликации защищается отдельно от шифрования на диске.
Резервные копии: копия расшифрованного датасета на другом носителе обнуляет защиту. Проверяют, что репликация и выгрузки сохраняют шифрование или идут в защищённый контур.

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

Приказ ФСТЭК №21 не регулирует тонкости криптографической защиты: для криптографии действуют отдельные требования. Шифрование датасета не заменяет применение сертифицированных средств, если этого требует модель угроз.

Аудит SMB/NFS-шар: что проверять в первую очередь

Шары - самая открытая часть хранилища: именно через них данные покидают NAS. Базовый набор проверок:

Инвентаризация: список всех шар и экспортов с назначением и владельцем данных. Шара без владельца почти всегда оказывается лишней.
Права: ACL на уровне шары и на уровне файловой системы должны совпадать. Расхождение даёт либо отказ в доступе, либо лишние разрешения.
Гостевой и анонимный доступ: отключён для всех шар, кроме осознанных исключений с некритичными данными.
Версии протоколов: устаревшие версии SMB и NFS без шифрования и подписывания отключают.
Настройки аудита: включены для критичных шар и отправляются во внешнее хранилище логов.

Проверка прав на SMB-шары

Настройки шар в TrueNAS смотрят в разделе Sharing, затем SMB: там видны путь, список разрешённых пользователей и групп, параметры аутентификации и доступ для гостей. Кроме веб-интерфейса полезны проверки со стороны клиента. Утилита smbclient выводит список шар командой smbclient -L с указанием сервера и пользователя, а также позволяет зайти в шару и увидеть фактические права. В PowerShell для тех же целей есть Get-SmbShare и Get-SmbShareAccess. Взгляд извне показывает то, что реально доступно клиенту, а не только конфигурацию сервера.

Проверка прав на NFS-шары

NFS отдаёт доступ по UID и GID и доверяет клиенту больше, чем SMB. Проверяют список экспортов, хосты и сети в правилах доступа, параметры монтирования. Список экспортов на сервере выводится командой showmount с ключом -e, в TrueNAS настройки видны в разделе Sharing, затем NFS. Отдельно убеждаются, что экспорт не открыт для всей сети и что для клиентов не включён режим с отключённой проверкой прав. Если NFS используется для критичных данных, для него включают аудит, иначе в журналах не будет следов чтения.

Проверка снапшотов и репликации

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

Расписание: как часто снимаются снапшоты для критичных датасетов и покрывает ли интервал допустимую потерю данных.
Срок хранения: сколько снимков и на какой период сохраняется. Короткое окно не даёт восстановиться после атаки, которая развивалась неделями.
Целостность: снимки не повреждены и доступны для чтения. Список выводится командой zfs list с ключом -t snapshot.
Репликация: задачи выполняются по расписанию, последняя завершилась успешно, данные на приёмнике совпадают с источником.
Тестовое восстановление: раз в квартал файл из снапшота восстанавливают в отдельный датасет, результат фиксируют в отчёте.

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

Приказ ФСТЭК №21 требует процедуру регулярной проверки эффективности всех принятых мер защиты (страница о приказе на сайте Контур.Эгида). Проверка снапшотов и репликации входит в такой цикл напрямую: восстанавливаемость подтверждают практикой, а не галочкой в настройках.

Связь аудита TrueNAS с требованиями ФСТЭК и 152-ФЗ

Приказ ФСТЭК №21 детализирует, как именно выполняются требования безопасности из 152-ФЗ и Постановления №1119 на техническом и организационном уровне внутри информационной системы. Документ задаёт чек-лист защитных мер и содержит 15 групп обязательных мер, распределённых по четырём уровням защищённости (УЗ1-УЗ4) в таблице соответствия. Требования обязательны для всех, кто обрабатывает персональные данные с помощью информационных систем (разбор применимости приказа).

Если на TrueNAS лежат персональные данные, часть мер чек-листа закрывается настройками хранилища. Таблица показывает, как требования ложатся на конкретные механизмы.

Мера из Приказа ФСТЭК №21	Как выглядит в TrueNAS и ZFS	Что проверяет аудит
Идентификация пользователей и разграничение прав доступа	ACL на датасетах, права на SMB/NFS-шары, подключение LDAP или AD	Нет ли избыточных прав и анонимного доступа, совпадают ли учётные записи с кадровыми данными
Регистрация событий безопасности	Аудит SMB и NFS, системный журнал, отправка логов в SIEM	Пишутся ли события доступа к критичным файлам и хранятся ли логи дольше срока, нужного для разбора инцидента
Контроль ПО, включая виртуализацию и облака	Сканирование шар, ограничение списка плагинов и приложений	Проверяется ли содержимое файловых шар и запускаются ли сторонние плагины без согласования
Обнаружение вторжений и реагирование на инциденты	Правила в SIEM по неудачным входам и массовому чтению	Описан ли порядок действий при срабатывании правила и кто отвечает за реакцию
Регулярная проверка эффективности мер	Повторяющийся цикл аудита с записью результатов	Устранены ли замечания прошлого цикла и не повторяются ли они

Границы применимости: Приказ №21 не распространяется на сведения, составляющие государственную тайну, и не регулирует тонкости криптографической защиты. Для криптографии действуют отдельные требования регулятора, и настройка шифрования ZFS не заменяет аттестацию средств защиты.

Как выстроить проверяемый контур безопасности

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

Политика аудита: что проверяем, с какой периодичностью (критичные датасеты ежемесячно, остальные раз в квартал), кто отвечает, какие доказательства сохраняем.
Инвентаризация: список датасетов, шар, экспортов, задач репликации и расписаний снапшотов с пометкой уровня критичности.
Автоматизация сбора: скрипт выгружает ACL и список снимков, результат складывается в систему контроля версий или тикетов, чтобы отличать новые отклонения от уже известных.
Хранение доказательств: отчёты, выгрузки журналов, результаты тестовых восстановлений с датой и исполнителем.
Повторная проверка: каждое замечание получает срок и ответственного, следующий цикл начинается с проверки закрытия прошлых находок.

Пример скрипта для инвентаризации прав и снимков по всем датасетам пула:

#!/bin/bash
# Дамп ACL и списка снимков по всем датасетам пула
tank
out=/root/acl-audit
mkdir -p "$out"
zfs list -H -o name -r tank | while read -r ds; do
  mp=$(zfs get -H -o value mountpoint "$ds")
  [ "$mp" = "-" ] && continue
  safe=$(echo "$ds" | tr "/" "_")
  getfacl -R -p "$mp" > "$out/$safe.acl" 2>/dev/null
  zfs list -t snapshot -o name,creation,used -r "$ds" > "$out/$safe.snap"
done
# Сравнение с предыдущим циклом
diff -ru /root/acl-audit-prev "$out" > /root/acl-audit.diff

Скрипт не заменяет разбор результатов, он лишь убирает ручную работу. Внутренний аудит помогает увидеть эффективность системы управления безопасностью, риски и точки улучшения (описание программы внутреннего аудитора). Если проверка выходит за пределы хранилища и затрагивает серверы, сети и Kubernetes, порядок действий и оформление отчёта разобраны в руководстве по аудиту безопасности ИТ-инфраструктуры.

Практический ориентир на первый цикл: выгрузить ACL по всем датасетам с критичными данными, включить аудит на двух самых важных шарах, проверить наличие снапшотов за последние 30 дней и восстановить один файл из снимка. Четыре действия дают основу для плана, который дальше расширяется до полного чек-листа.