Аудит доступа и разграничение прав в системах хранения: практическое руководство 2026

Аудит доступа в системе хранения отвечает на четыре вопроса: кто обратился к данным, к какому объекту, что именно сделал и когда. Пока эти поля не попадают в журнал, любое утверждение о безопасности хранения держится на предположениях. Рабочий минимум 2026 года выглядит так: права раздаются через POSIX-биты, ACL и ролевые модели, а события собираются в SIEM и проверяются на аномалии.

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

Содержание статьи: механизмы разграничения прав, пошаговые сценарии для TrueNAS, Windows Server и S3-совместимых хранилищ, настройка журналов аудита и их отправка в SIEM, методика поиска и снятия избыточных разрешений.

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

Аудит доступа фиксирует фактические обращения к данным и изменения политики. Это часть системы качества хранения наравне с проверкой целостности, контролем свободного места и тестами восстановления из снапшотов. Метрики производительности показывают, что хранилище работает. Журнал аудита показывает, кто им пользовался и не вышел ли кто-то за границы своих полномочий.

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

Ключевые компоненты аудита: субъект, объект, действие, время

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

Пример записи, по которой можно провести разбор: субъект john@example.local с адреса 10.20.4.18 прочитал объект /mnt/pool/finance/report.pdf, результат success, время 2026-01-15T10:23:45+03:00. Такая строка отвечает на вопрос «кто забрал файл» за секунды вместо часов переписки.

Метка времени работает только при синхронизированных часах. Расхождение в 10 секунд между NAS, контроллером домена и SIEM уже ломает корреляцию событий, а без часового пояса в записи невозможно понять, в какой момент суток произошёл доступ. NTP на всех узлах хранения и на коллекторе журналов это не формальность, а условие корректного аудита.

Почему избыточные права опаснее, чем кажется

Лишние разрешения появляются по трём типовым причинам. Наследование: права, выданные на корень шары, автоматически расходятся по тысячам вложенных объектов. Вложенность групп: пользователь попадает в доменную группу, та вложена в другую, и через три уровня он получает доступ к финансовому каталогу. Временные разрешения: доступ «на две недели» для миграции остаётся в ACL спустя год, потому что никто не завёл задачу на отзыв.

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

Последствия делятся на три группы. Утечка: чтение данных, к которым пользователь не должен иметь доступа. Порча: изменение или удаление файлов, включая поражение шар шифровальщиком, который работает под учётной записью с полными правами. Несоответствие требованиям: GDPR (статья 32, технические меры защиты и уведомление об утечке в течение 72 часов), HIPAA (контроль аудита в Security Rule), PCI DSS 4.0 (требование 7 об ограничении доступа по необходимости и требование 10 о журналировании с хранением записей 12 месяцев, из них 3 месяца в оперативном доступе), ISO/IEC 27001:2022 (контроли 5.15, 8.2, 8.15). Комплаенс-проверка начинается с вопроса «покажите, кому разрешён доступ и на каком основании», и избыточные права в ответе выглядят плохо.

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

Разграничение прав доступа: ACL, POSIX permissions и ролевые модели

Механизмов три, и в реальных хранилищах они комбинируются: POSIX-биты задают базу, ACL уточняет исключения, ролевые модели управляют доступом на уровне сервисов и учётных записей.

POSIX permissions: базовая модель и её ограничения

Три категории (владелец, группа, остальные) и три бита (чтение, запись, выполнение) дают девять битов на объект. Числовая запись строится просто: r=4, w=2, x=1, поэтому 755 означает полный доступ владельцу и чтение с выполнением остальным, а 644 это запись для владельца и чтение для всех остальных.

Пример: файл /srv/report.pdf с правами 644 читают все, включая сервисные учётные записи веб-приложений и учётку гостевого доступа SMB. Для общего каталога обмена это нормально, для каталога с договорами уже нет.

Ограничения модели заметны на практике: расширенное право можно выдать только владельцу, у файла одна владеющая группа, запрещающих записей нет, а наследование сводится к umask и биту setgid на каталоге (chmod 2775 передаёт группу каталога новым файлам). Запретить конкретному сотруднику чтение файла, если он входит в группу, тоже не получится. Как только появляется требование «дать доступ двум сотрудникам из разных отделов и не дать остальным», POSIX-битов не хватает.

ACL: гранулярное управление доступом

ACL позволяет перечислить произвольное число пользователей и групп с индивидуальными правами. В Linux это POSIX ACL: команда setfacl -m u:john:rw- /mnt/pool/data добавляет запись для john, а getfacl /mnt/pool/data показывает итоговый список, маску и вычисленные эффективные права. Наличие ACL заметно в выводе ls по символу + в конце строки прав.

Ключевые понятия: access ACL действует на сам объект, default ACL (задаётся как setfacl -m d:u:john:rwx /mnt/pool/data) применяется к объектам, созданным внутри каталога позже. Маска ограничивает максимальные права именованных записей и группы, поэтому новая запись может не дать ожидаемого эффекта, если маска её обрезает. Это самая частая причина фразы «я выдал права, а доступа нет».

В ZFS и Windows Server используется более богатая модель NFSv4 и NTFS. Вместо трёх битов доступны отдельные права: read_data, write_data, append_data, execute, delete_child, delete, take_ownership, а также запрещающие записи с явным приоритетом запрета. Флаги наследования позволяют передавать право на файлы, на каталоги или на оба типа, с распространением или без распространения вглубь. Именно эта модель нужна там, где требуется выдать запись без права удаления или разрешить создание файлов, но запретить смену владельца.

Ролевые модели: RBAC и ABAC в хранилищах

RBAC управляет доступом через роли: роль Developer даёт чтение и запись в бакет dev, роль Auditor только чтение всех бакетов и доступ к журналам, роль BackupOperator читает снапшоты. В Windows Server ролью выступает группа безопасности, в S3 её играет IAM-роль или политика, привязанная к группе пользователей.

ABAC добавляет атрибуты: адрес источника, наличие второго фактора, тег проекта, шифрование в запросе. В S3 это условия политики, например aws:SourceIp, aws:MultiFactorAuthPresent, aws:PrincipalTag/project, s3:x-amz-server-side-encryption. Правило работает так: доступ разрешён, если у учётной записи есть роль и выполняются условия.

Преимущество ролевой модели в масштабе. Смена требования для 300 сотрудников это правка одной политики вместо 3000 записей ACL. В AWS и MinIO действует важное правило: явный запрет (Deny) перекрывает любое разрешение, поэтому запреты удобно использовать как страховку от случайной выдачи.

Настройка ACL в TrueNAS: пошаговый сценарий

TrueNAS опирается на ZFS, поэтому ACL задаются свойствами датасета, а не только командами файловой системы. Порядок действий ниже актуален для TrueNAS SCALE версий 24.10 и новее.

Создание датасета с поддержкой ACL

1. В веб-интерфейсе откройте раздел Datasets и выберите пул.
2. Нажмите Add Dataset, задайте имя, например data.
3. В блоке Advanced Options укажите ACL Type: POSIX или NFSv4. Для совместной работы через SMB и для тонких прав выбирайте NFSv4.
4. Задайте ACL Mode: passthrough сохраняет права, которые присылает клиент, restricted приводит их к режиму, описанному в ACL датасета.
5. Сохраните датасет и проверьте свойства.

Эквивалент из командной строки и проверка:

zfs create -o acltype=nfsv4 -o aclmode=passthrough -o aclinherit=passthrough pool/data
zfs get acltype,aclmode,aclinherit pool/data

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

Настройка прав через веб-интерфейс и командную строку

Через интерфейс: Datasets, выберите датасет, откройте Edit Permissions (или Edit ACL), добавьте запись, укажите получателя (пользователь или группа), выберите права (Read, Modify, Full Control), задайте флаги наследования и сохраните с рекурсивным применением, если требуется.

Через консоль для POSIX ACL:

setfacl -m u:john:rw- /mnt/pool/data
getfacl /mnt/pool/data

Логика сценария: пользователь john получает чтение и запись в датасет, но не получает право удалять чужие объекты. В NFSv4 ACL это делается выдачей write_data и append_data без delete_child, а также включением права synchronize, если данные используются через SMB с блокировками. Право rwx в POSIX-модели такой тонкости не даёт: запись в каталоге автоматически означает возможность удалять файлы.

Типичные ловушки TrueNAS: у существующего датасета acltype=off, поэтому setfacl молча не влияет на наследование; для NFS включён maproot=root и клиент под root получает доступ ко всему; для доменных пользователей SMB не настроены idmap и winbind, из-за чего записи ACL ссылаются на неизвестные SID. Пошаговая схема раздачи прав для команды с группами и наследованием разобрана в руководстве по контролю доступа и делегированию прав в TrueNAS.

Разграничение прав в Windows Server: NTFS permissions и аудит

В Windows Server эффективные права определяются пересечением двух наборов: разрешения на общем ресурсе (share permissions) и разрешения NTFS. На практике share permissions выставляют как Full Control для группы Authenticated Users, а реальное ограничение задают на NTFS, потому что только NTFS умеет наследование, аудит и тонкие права.

Настройка NTFS permissions через PowerShell

Проверка текущего состояния и добавление правила для группы:

$acl = Get-Acl C:\Data
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("DOMAIN\DevTeam","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path C:\Data -AclObject $acl

Параметры читаются так: первые два задают получателя и уровень доступа, третий отвечает за наследование на контейнеры и объекты, четвёртый задаёт тип распространения, последний указывает Allow или Deny. Для простых случаев короче утилита icacls:

icacls C:\Data /grant "DOMAIN\DevTeam:(OI)(CI)(M)" /T
icacls C:\Data /inheritance:d
icacls C:\Data /remove:g "BUILTIN\Users" /T

Ключевые правила, которые экономят время на разборе инцидентов. Права выдавайте группам, а не отдельным пользователям: иначе при увольнении вы чистите ACL по десяткам папок. Уровень Modify включает удаление, поэтому для каталогов, где нужно писать без права стирать, используйте Write и отдельные расширенные права (Create files, Append data) без Delete. На корне папки с данными отключайте наследование (/inheritance:d) и превращайте унаследованные записи в явные, чтобы видеть реальную матрицу доступа.

Включение аудита доступа к объектам

Аудит в Windows включается на двух уровнях: политика аудита и системный список контроля доступа (SACL) на конкретном объекте.

1. Политика: Group Policy Management, Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy, включите Audit object access для Success и Failure. Локальный эквивалент: auditpol /set /subcategory:"File System" /success:enable /failure:enable.
2. Убедитесь, что включён параметр Audit: Force audit policy subcategory settings, иначе старые настройки категорий перекроют новые.
3. SACL: свойства папки, Security, Advanced, вкладка Auditing, Add, выберите группу или пользователя, тип Success и Failure, затем конкретные права: Write, Delete, Change Permissions.
4. Просмотр: Event Viewer, журнал Security, с фильтром по нужным идентификаторам событий.

Что искать в журнале: 4656 (запрошен дескриптор объекта), 4663 (попытка доступа к объекту), 4660 (объект удалён), 4670 (изменены права), 4907 (изменена политика аудита), 4624 и 4625 (успешный и неуспешный вход). Событие 4663 это рабочая лошадка аудита файлов, но именно оно создаёт объём: одна активно используемая папка на 200 сотрудников даёт сотни тысяч записей в сутки. Поэтому включайте аудит на папках с чувствительными данными, а не на всём томе. Пошаговая настройка SMB, NTFS и аудита доступа с диагностикой ошибок Access Denied собрана в материале по настройке и управлению SMB-ресурсами в Windows Server 2026.

Ролевая модель доступа в S3-совместимых хранилищах

В S3 доступ управляется тремя инструментами: identity policies (что разрешено учётной записи), bucket policies (что разрешено на уровне бакета) и ACL объектов. С апреля 2023 года новые бакеты в AWS создаются с отключёнными ACL и режимом bucket owner enforced, поэтому основной инструмент это политики. MinIO и Ceph RGW в S3-совместимом режиме поддерживают тот же синтаксис политик JSON.

Создание IAM-политики для доступа к бакету

Последовательность в консоли: IAM, Policies, Create policy, выбор сервиса S3, действия GetObject и PutObject, ресурс в виде ARN объектов, затем сохранение и прикрепление политики к группе или роли. Пример политики, дающей чтение и запись только в префиксе dev и при этом не открывающей остальные данные:

{"Version":"2012-10-17","Statement":[
{"Sid":"RWDevPrefix","Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],"Resource":"arn:aws:s3:::mybucket/dev/*"},
{"Sid":"ListOwnPrefix","Effect":"Allow","Action":["s3:ListBucket"],"Resource":"arn:aws:s3:::mybucket","Condition":{"StringLike":{"s3:prefix":["dev/*"]}}}
]}

Две детали, на которых чаще всего ошибаются. Действия над объектами применяются к ARN вида arn:aws:s3:::mybucket/dev/*, а ListBucket применяется к ARN бакета без пути, иначе список объектов не отобразится. Условие s3:prefix ограничивает листинг одним префиксом, иначе пользователь увидит имена всех объектов в бакете, даже тех, которые не может прочитать. Полезно добавить запрет на незашифрованный доступ: условие с aws:SecureTransport равным false и эффектом Deny блокирует обращения по HTTP. Проверить результат можно командой aws sts get-caller-identity и пробным aws s3 ls под тестовой учётной записью. Развёрнутый разбор протокола, ключевых операций API и клиентов есть в руководстве по S3-протоколу и настройке клиентов.

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

Долгосрочные ключи доступа это главный источник утечек в объектных хранилищах: ключ попадает в конфиг CI, в репозиторий или на ноутбук подрядчика и живёт годами. Роли решают задачу иначе. Учётная запись вызывает AssumeRole, получает временные credentials на срок от 15 минут до 12 часов (по умолчанию один час) и не хранит постоянных секретов.

Схемы, которые работают: роль для EC2 через instance profile, роль для пода в Kubernetes через сервисный аккаунт, роль для CI через OIDC-провайдер, роль для внешнего подрядчика с условием ExternalId и ограничением по IP. В MinIO то же самое делается командами mc admin user add и mc admin policy attach, плюс отдельные сервисные аккаунты. Признак грубой ошибки в политике: Action со звёздочкой на s3:* и Resource "*" в одном правиле. Это S3-аналог раздачи Full Control группе Everyone, только применяется он мгновенно ко всем бакетам.

Журналы аудита и интеграция с SIEM

Логировать нужно пять групп событий: доступ к данным (чтение, запись, удаление), изменение прав и владельцев, аутентификацию (успешную и неуспешную), административные действия (снапшоты, репликация, смена политик хранения), изменения конфигурации самого аудита. Форматы различаются: syslog по RFC 5424, Windows Event Log в XML или JSON, журналы доступа S3 в виде строк, события управления в JSON.

Три требования к конвейеру журналов. Синхронизация времени на всех узлах. Передача в SIEM по TCP или TLS, потому что UDP под нагрузкой теряет пакеты молча. Защита от подделки: журналы пишутся только на запись, архив хранится в неизменяемом виде, например в S3 с включённым Object Lock в режиме Compliance и сроком хранения 12 месяцев. Практический график хранения: 90 дней в оперативном индексе SIEM, 12 месяцев в архиве, что закрывает требование PCI DSS о 12 месяцах хранения и 3 месяцах быстрого доступа.

Настройка syslog forwarding в TrueNAS

Порядок: System, Advanced, раздел Syslog, укажите Syslog Server (адрес коллектора), Syslog Transport (TCP или TLS), уровень логирования и порт 514 для TCP либо 6514 для TLS. Для TLS заранее разместите сертификат коллектора. Проверка отправки: выполните в шелле TrueNAS тестовое сообщение через logger и убедитесь, что оно дошло до SIEM.

Уровень Debug не выбирайте без необходимости: он многократно увеличивает поток событий. Если коллектор временно недоступен, сообщения теряются, поэтому на стороне приёмника настройте очередь rsyslog на диске, а на стороне источника оставьте локальные журналы не менее чем на 30 дней. Пример строки пересылки всего потока на коллектор по TCP:

*.* @@siem.internal:6514

Сбор событий безопасности Windows Server

Два рабочих подхода: агент (Winlogbeat, Elastic Agent, агент производителя SIEM) или Windows Event Forwarding, когда контроллер-коллектор подписывается на источники. Второй вариант удобен тем, что не требует установки агентов на каждый сервер, но требует настройки подписок и прав.

Фрагмент конфигурации Winlogbeat с фильтром по нужным идентификаторам событий:

winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4663, 4670, 4907
    ignore_older: 72h
output.elasticsearch:
  hosts: ["siem.internal:9200"]

Фильтр по идентификаторам обязателен: без него в индекс попадут десятки миллионов событий в сутки, а стоимость хранения вырастет быстрее, чем польза. Для событий 4663 дополнительно фильтруйте по имени объекта и маске доступа, оставляя только чувствительные каталоги. Проверьте также, что время на серверах синхронизировано с тем же источником, что и на SIEM, иначе события доступа будут выпадать из корреляции со входом пользователя.

Логирование доступа в S3 и отправка в SIEM

В S3 включаются два вида журналов. Server Access Logging пишет каждое обращение к объекту в отдельный бакет и включается командой aws s3api put-bucket-logging с указанием целевого бакета и префикса. CloudTrail фиксирует события управления (создание бакета, изменение политики) по умолчанию, а события данных вида GetObject и PutObject требуют отдельного включения и стоят дополнительно. Серверные логи доставляются с задержкой в несколько минут и не гарантируют полноту, поэтому для критичных бакетов включают оба источника.

Дальше строят конвейер: журнальный бакет, уведомление о появлении объекта, функция обработки, отправка в SIEM по HTTP Event Collector или через агент вроде Vector и Fluent Bit. Та же схема применима к S3-сервису на базе MinIO в TrueNAS, где события доступны через вебхук аудита: настройка сервиса, бакетов и политик описана в руководстве по включению и настройке S3-сервиса в TrueNAS. Для архивных копий журналов и тестового SIEM-стенда удобно держать отдельный контур, который не пересекается с продуктивом: облачные VPS, объектное хранилище и управляемый Kubernetes с изменяемыми ресурсами предоставляет Timeweb Cloud, и на таком стенде безопасно отрабатывать фильтры и правила корреляции до переноса в рабочий SIEM.

Выявление и устранение избыточных прав

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

Инструменты для аудита прав

Windows: оснастка Effective Permissions на вкладке Advanced, утилита AccessEnum для обхода дерева каталогов, AccessChk из Sysinternals для проверки служб и разделов реестра, выгрузка через Get-Acl с рекурсией в CSV и icacls /save для резервной копии ACL перед правкой.

Linux и ZFS: команда find /data -type f -perm /o+w находит файлы, доступные на запись всем, getfacl -R выгружает все ACL, zfs get acltype,aclinherit показывает настройки датасета. Полезно искать файлы без владельца (find /data -nouser) и каталоги с правами 777.

TrueNAS: отчёты по датасетам в интерфейсе и периодическая выгрузка getfacl в контрольную сумму, чтобы видеть изменения ACL между проверками. S3: IAM Access Analyzer находит бакеты и роли с публичным или кросс-аккаунтным доступом, AWS Config отслеживает отклонения от эталонной конфигурации, а команды get-bucket-acl и get-bucket-policy показывают текущие разрешения. Скрипты для массовой проверки политик доступа в Linux, Windows, Active Directory и облачных IAM собраны в руководстве по аудиту политик и прав доступа.

Пример разбора: выгрузка показывает 42 учётные записи с правом записи в каталог финансов. По матрице доступа право должны иметь 9 человек. 33 лишние записи распределяются так: 20 пришли по наследованию с корня шары, 8 добавлены вручную для разовой задачи полтора года назад, 5 попали через вложенность групп Active Directory. Устранять нужно не записи, а источник: отключить наследование на корне, отозвать ручные разрешения, пересобрать вложенность групп.

Принцип наименьших привилегий на практике

1. Назначьте владельца данных: без ответственного человека пересмотр прав превращается в формальность.
2. Опишите роли по функциям (чтение, запись, администратор) и закрепите их группами, а не отдельными пользователями.
3. Отключите наследование на корне каталогов с чувствительными данными и раздавайте права группам явно.
4. Выдавайте временный доступ с автоматическим сроком жизни: задача на отзыв создаётся вместе с разрешением, а не после инцидента.
5. Проводите пересмотр прав раз в квартал с подписью владельца данных и храните результат как доказательство для аудита.
6. Встройте проверку в конвейер: если getfacl или icacls показывают запись для всех или полный доступ для сервисной учётки, сборка или приёмка изменений останавливается.

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

Выгрузка прав на крупном файловом хранилище легко даёт десятки тысяч записей ACE, и глазами такой CSV не разобрать. Разбор ускоряет модель: AiTunnel даёт единый API к GPT, Gemini и Claude с оплатой в рублях и управлением бюджетами ключей, поэтому скрипт проверки может отправлять выгрузку на анализ и получать список аномальных комбинаций, например «полный доступ для подрядчика на каталоге с персональными данными».

Начните с одного датасета. Включите ACL нужного типа, снимите текущую матрицу прав, включите аудит доступа и отправку событий в SIEM, а через неделю сравните, кто реально читал данные, с теми, кому это разрешено. Расхождение и будет перечнем скрытых дефектов, которые предстоит закрыть.