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

Корпоративный файловый сервис на 10 и более пользователей быстро упирается в пределы модели rwx: три категории (владелец, группа, остальные) не описывают случай, когда отделу продаж нужна запись в общую папку «Клиенты», а маркетингу на ту же папку только чтение. Рабочая схема получается составной: POSIX-права служат базой, ACL закрывает точечные разрешения и запреты, группы описывают структуру компании, роли работают как шаблоны прав, а default ACL раздаёт права новым файлам и подпапкам автоматически.

Порядок работ по этому материалу такой:

1. Разобрать, где rwx не хватает и зачем нужен ACL.
2. Построить группы и роли по модели AGDLP.
3. Настроить наследование через default ACL.
4. Убрать типичные ошибки: 777, права на пользователей напрямую, кривые маски.
5. Поставить регулярный аудит ACL и перейти к минимальным привилегиям.

Оговорка по источникам. В подборке материалов к этой статье нет публикаций, которые описывают ACL, наследование и группы именно в корпоративном файловом сервисе. Проверяемые внешние ссылки ниже относятся к смежным темам: управление правами через Active Directory и модель Zero Trust в корпоративном удалённом доступе. Синтаксис setfacl, getfacl и icacls приведён по документированному поведению утилит, и каждую команду стоит проверять на тестовой папке до применения на продакшене.

Почему стандартных POSIX-прав недостаточно для корпоративного файлового сервиса

POSIX-модель описывает объект тремя наборами: владелец (u), группа (g), остальные (o). В каждом наборе три бита: чтение (r), запись (w), выполнение (x). chmod меняет наборы, chown меняет владельца и группу, umask срезает лишние биты у новых файлов. Субъектов в этой схеме ровно три, и один из них всегда «остальные».

Ограничения модели rwx: владелец, группа, остальные

Три рабочих ситуации, в которых rwx упирается в стену:

• Две группы с разными правами на одну папку. У объекта один групповой слот. Дать отделу продаж rwx, а маркетингу r-x на /data/clients в чистом POSIX нельзя: вторая группа получит права либо как «остальные» (то есть те же права достанутся всем), либо никак. Обходные пути: дублировать дерево папок, объединить оба отдела в одну группу с равными правами или открыть чтение для всех.
• Запрет конкретному пользователю. Сотрудник входит в группу, у которой есть доступ. Отозвать доступ только ему внутри группы POSIX не позволяет: вариант один, исключить его из группы, а это заодно отрежет все остальные ресурсы группы. Запрещающих записей в rwx не существует.
• Файл, созданный другим пользователем. Владелец нового файла - тот, кто его создал, и он волен снять права группы. Частичное решение даёт бит SGID на папке (chmod g+s): новые объекты получают группу родительского каталога, но не его права. Права по-прежнему зависят от umask и от действий автора файла.

Сетевые файловые сервисы, совместимые с SMB, сопоставляют POSIX ACL с Windows ACL и при этом наследуют ограничения POSIX ACL: там, где возможностей POSIX ACL не хватает по сравнению с Windows NT/200X ACL, на Windows ACL накладывается семантика и ограничения POSIX. Взаимно однозначного сопоставления не существует, поэтому Samba применяет логическое сопоставление, а права UNIX user/group/other в общем случае имеют приоритет над созданием POSIX ACL. Практический вывод: не рассчитывайте, что расширенные записи, настроенные на стороне Windows, будут вести себя на POSIX-сервере ровно так же, как задумано в графическом интерфейсе. Базовые команды для локальных прав разобраны в руководстве по правам доступа в Linux.

Что такое ACL и как он расширяет POSIX

ACL (Access Control List) - список записей о доступе. Каждая запись указывает субъект и набор разрешений: user:ivan:rwx, group:sales:r-x, mask::rwx, other::---. Объект получает столько записей, сколько нужно, и ограничение «одна группа на папку» исчезает. ACL даёт три вещи, которых нет в rwx:

1. Права нескольким пользователям и группам на один объект, с разными наборами разрешений.
2. Default-записи для новых файлов и подпапок внутри каталога.
3. Маску как верхнюю границу прав для всех записей, кроме владельца и «остальных».

Поддержка ACL есть в ext4, XFS и ZFS, в NTFS, в Samba и NFSv4. Просмотр и правка выполняются утилитами getfacl и setfacl. Пример: setfacl -m u:ivan:rwx /data/project выдаёт пользователю Ивану полные права на папку, не меняя права группы и остальных. Обратная операция - setfacl -x u:ivan /data/project убирает запись целиком.

Читать вывод getfacl нужно построчно: строки user:, group:, other: и отдельная строка mask:. Если маска меньше, чем права в записи, эффективные права окажутся урезанными. Об этом ниже, в разделе про ошибки.

Проектирование групп и ролей под реальную оргструктуру

Назначать права напрямую пользователям - самый быстрый путь к разрастанию исключений: через год никто не помнит, почему у Ивана есть запись на папке бухгалтерии. Рабочий принцип: права получают группы, пользователи попадают в группы по своим функциям. Роли в этой схеме - наборы прав для типовых задач (чтение, редактирование, администрирование), которые крепятся к группам, а не к людям.

Модель AGDLP: от пользователя к ресурсу

1. Учётные записи (Account) - пользователи в AD или локальной базе файлового сервиса.
2. Глобальные группы (Global) - по отделам и функциям: GG_Marketing, GG_Sales.
3. Доменные локальные группы (Domain Local) - по ресурсам: DL_FS_Marketing_RW, DL_FS_Clients_RO.
4. Глобальные группы добавляются в доменные локальные.
5. Права на папку выдаются доменной локальной группе через ACL.

Выгода видна на переводе сотрудника: меняется одна строка членства в GG_Marketing, а ACL на сотнях папок остаются нетронутыми. Для Linux-файловых сервисов с Samba схема повторяется: группы AD после настройки SSSD или Winbind видны в системе, и ACL назначается прямо на них.

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

Роли: шаблоны прав для типовых задач

Ключевая деталь: право изменять ACL файла есть у владельца файла и у процессов, обладающих возможностью CAP_FOWNER; это аналогично правам, необходимым для доступа к режиму файла. В текущих Linux-системах root - единственный пользователь с возможностью CAP_FOWNER, а сама возможность эквивалентна применению прав, которые обычно принадлежат только владельцу объекта, включая управление ACL. Поэтому роль «Администратор» на практике означает, что каталог принадлежит служебной группе администраторов или правки идут через sudo. Пользователь с rwx на файле, но без владения, ACL изменить не сможет.

Роли комбинируются: сотрудник может быть читателем в /data/clients и редактором в /data/projects. Конфликтов не возникает, потому что записи ACL привязаны к конкретным объектам, а членство в группах определяет, какие записи сработают.

Наследование прав на вложенных папках: настройка и примеры

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

Default ACL: автоматические права для новых объектов

Default ACL задаётся только для каталога и действует на всё, что внутри него появится:

setfacl -d -m u::rwx,g::rx,o::---,g:DL_Sales:rwx /data/sales
getfacl /data/sales

После этого каждый новый файл и подпапка в /data/sales получат запись для группы DL_Sales, а маска default ACL ограничит максимум прав, которые способна унаследовать любая запись. Если маску не задать явно, setfacl вычислит её автоматически; проверить результат можно строкой default:mask:: в выводе getfacl.

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

Рекурсивное применение и сброс ACL

setfacl -R -m g:DL_Sales:r-x /data/sales
setfacl -b -R /data/legacy

Рекурсивный проход по большому дереву читает и правит атрибуты у каждого объекта, поэтому на миллионах файлов операция занимает часы и нагружает диски. Планируйте её на окно обслуживания, а не на рабочий день. Сброс через setfacl -b -R снимает все расширенные записи и оставляет только POSIX-права владельца, группы и остальных; после этого доступ может пропасть у тех, кто держался именно на ACL. Перед сбросом сохраните вывод getfacl -R в файл: он же пригодится как точка отката.

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

Типичные ошибки при разграничении доступа и их последствия

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

Права 777 и другие избыточные разрешения

chmod 777 открывает чтение, запись и выполнение всем: коллегам из других отделов, гостевым учётным записям, сервисным аккаунтам, любому, кто получил доступ к сети. Правильная замена - групповая запись в ACL плюс закрытая база:

chmod 770 /data/finance
setfacl -m g:DL_Finance_RW:rwx /data/finance
setfacl -m g:DL_Audit_RO:r-x /data/finance

Папка бухгалтерии остаётся доступной бухгалтерии и аудиту, остальные не получают ничего. В Windows-совместимых файловых сервисах аналог 777 - полный доступ для группы «Все» (Everyone).

Ошибки в наследовании и масках ACL

Маска ACL работает как потолок для всех записей, кроме владельца и «остальных». Классический промах: администратор выдаёт пользователю rwx, а маска стоит в r-x, и фактический доступ урезан до чтения.

setfacl -m u:ivan:rwx /data/project
getfacl /data/project
setfacl -m m::rwx /data/project

Строка effective: в getfacl показывает реальные права с учётом маски. Второй промах - отсутствие default ACL: новые файлы создаются с правами по umask (обычно 644 у файлов и 755 у папок), и коллеги из группы чтения не могут открыть документ. Третий - потеря наследования при копировании: после копирования без сохранения атрибутов расширенные записи могут не перенестись. После каждой настройки наследования выполняйте getfacl на новых объектах, а не полагайтесь на предположения.

Аудит доступа и принцип минимальных привилегий

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

Скрипт для аудита ACL

Быстрый срез по Linux-файловому серверу даёт одна строка:

find /data -type d -exec getfacl {} \; | grep -E 'user:.*:rwx|group:.*:rwx|other::rwx' | tee /var/log/acl-audit.txt

Команда рекурсивно собирает ACL всех каталогов и оставляет строки, где выдана запись или открыт полный доступ для «остальных». Результат удобно хранить: файл отчёта показывает динамику между проверками. Скрипт адаптируется под свои требования, например добавляет группу других каталогов или исключает служебные пути через ключ -prune. На NTFS аналогичный срез даёт icacls с ключом /save или PowerShell (Get-Acl по списку каталогов), на стороне Samba - smbcacls по каждому ресурсу. Больше о журналах, избыточных правах и связи с SIEM - в руководстве по аудиту доступа и разграничению прав в системах хранения.

Переход к принципу минимальных привилегий

1. Инвентаризация: список каталогов, текущие ACL, ответственные за данные.
2. Определение минимально нужных прав для каждой роли по каждому ресурсу.
3. Пересборка групп по AGDLP и выдача прав группам, а не людям.
4. Перевод папок порциями: одна группа каталогов, неделя наблюдения, следующая порция.
5. Аудит не реже раза в квартал, плюс внеплановые проверки при увольнении и переводе.

Принцип минимальных привилегий означает простое правило: сотрудник получает доступ только к тем папкам, которые нужны для его задач. Продавец работает в /data/sales и не имеет записей на /data/finance. Это та же логика, что и в модели Zero Trust, где доступ выдаётся к конкретным приложениям с постоянной проверкой параметров подключения: устройства, местоположения и времени (Контур.Эгида). По данным того же обзора, около 70% новых проектов удалённого доступа в 2025-2026 годах строятся на модели Zero Trust Network Access. Для файлового сервиса это переводится в два действия: сужение прав до рабочего минимума и логирование того, кто и когда открывал ресурс.

Практические команды и примеры для Linux и Windows

Опции setfacl стоит держать под рукой: -m добавляет или меняет записи, -x удаляет конкретную запись, -b снимает все расширенные ACL, -R включает рекурсию, -d задаёт default ACL для каталога. Файловая система должна быть смонтирована с поддержкой ACL. Для ext4 поддержка POSIX ACL включается в конфигурации ядра (CONFIG_EXT4_FS_POSIX_ACL) и по умолчанию активна при монтировании; опция acl указана как опция монтирования по умолчанию при создании файловой системы ext2/3/4 и настраивается в /etc/mke2fs.conf. Для Btrfs и XFS поведение поддержки ACL жёстко задано. Проверить опции монтирования по умолчанию для разделов ext2/3/4 можно командой tune2fs -l /dev/sd | grep "Default mount options:". Разбор монтирования и сетевых протоколов SMB и NFS есть в руководстве по доступу к файловой системе.

Команды setfacl и getfacl: синтаксис и примеры

getfacl /data/marketing
setfacl -m g:DL_Marketing:rwx /data/marketing
setfacl -x u:ivan /data/project
setfacl -d -m g:DL_Sales:rwx /data/sales
setfacl -R -m g:DL_Sales:r-x /data/sales
setfacl -b -R /data/legacy

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

Работа с ACL в Windows и Samba

icacls C:\Data\Marketing /grant DL_Marketing:(OI)(CI)F
icacls C:\Data\Marketing /save C:\audit\marketing.acl /t
smbcacls //fs01/marketing --add 'ACL:DL_Marketing:ALLOWED/0x0/FULL'

Флаги (OI) и (CI) в icacls задают наследование: (OI) - наследование объекта, объекты в этом контейнере наследуют эту запись, применяется только к каталогам; (CI) - наследование контейнера. Буква F даёт полный доступ. Пример icacls с (OI)(CI)F предоставляет пользователю полный доступ к папке с наследованием объектами и контейнерами. Значение буквы M (modify) в документации Microsoft Learn, доступной в подборке, не подтверждено, поэтому используйте F для полного доступа и проверяйте точное значение M по актуальной справке icacls перед выдачей прав. Настройка через проводник Windows нагляднее, но проверять результат стоит командой icacls: графический интерфейс показывает эффективные права с учётом наследования, а не сами записи. Тонкости групп безопасности и эффективных прав разобраны в статье о правах NTFS и SMB.

Интеграция с Active Directory и корпоративными сервисами

В компаниях с доменом учётные записи и группы живут в Active Directory, и файловый сервис должен работать с ними напрямую. Для Linux-серверов это делается через SSSD или Winbind: после подключения к домену группы AD видны в системе, и ACL назначается на них так же, как на локальные группы. Если файловый сервис построен на TrueNAS, связка «пользователи, группы, ACL для SMB/NFS» настраивается через веб-интерфейс, порядок шагов разобран в материале о делегировании прав в TrueNAS.

Настройка SSSD для интеграции с AD

Минимальный набор пакетов - sssd, sssd-ad, adcli, realmd. Базовая конфигурация в /etc/sssd/sssd.conf:

[sssd]
domains = example.com
services = nss, pam
config_file_version = 2

[domain/example.com]
id_provider = ad
access_provider = ad

После запуска службы проверьте, что группы видны: id user@example.com и getent group DL_Marketing. Если команда возвращает числовой идентификатор без имени группы, ACL на неё не назначится, и стоит проверить сопоставление идентификаторов и кэш SSSD.

Использование групп AD в ACL

setfacl -m g:DL_FS_Marketing_RW:rwx /data/marketing
getfacl /data/marketing

Права на ресурсы выдаются доменным локальным группам, а пользователи попадают в глобальные группы по отделам. Изменение состава группы в AD сразу меняет доступ участников: отдельные ACL править не нужно. Рекомендация простая: глобальные группы для членства, доменные локальные для прав, персональные записи только как временное исключение с датой снятия.

В корпоративных сетях доступ к внутренним файловым серверам нередко выдаётся через защищённый удалённый доступ, а права управляются в Active Directory с логированием подключений для аудита. Такой набор функций описан, например, для корпоративных VPN (Контур.Эгида). Логи подключений дополняют аудит ACL: они показывают, кто и когда заходил в сеть, тогда как права фиксируют, что именно ему доступно.

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

Как выбрать модель прав под свой сценарий

Начните с одной папки: соберите текущий getfacl, опишите роли, выдайте права доменным локальным группам, включите default ACL и через неделю проверьте вывод заново. Работающая схема на одном каталоге переносится на остальные без пересмотра принципов.