Я давно не читал столь отборную ахинею, даже не поленился лог модерирования открыть...
Мне только одно не понятно, на каких пропагандистских курсах тебе преподали, что ACL - это "лютый антипаттерн программирования". Убери эту дурь из головы.ACL - это низкоуровневый механизм контроля доступа над объектами операционной системы. Речь идёт не только о файлах, но и о процессах, сокетах и других объектах. Все многопользовательские операционные системы общего назначения реализуют ACL, потому что нужно хоть как-то разграничивать права доступа. ACL - это вопрос авторизации, вопрос, который часто не понимают. Программирование и его паттерны тут совершенно не имеют никакого отношения к вопросу. ACL на уровне ОС решает задачу, есть у процесса доступ к объекту или либо нет.
В ОС Windows ACL развивались, чтобы решать бизнес задачи ПОВЕРХ них. Самих ACL для бизнес-задач никогда не достаточно. Да, они самые продвинутые из всех, но, нет, их никогда не хватит. В разных государствах в СНГ исторически существует порочная практика - пихать все корпоративные файлы на единый файловый сервер и решать вопросы авторизации средствами ACL файловой системы NTFS. То что это вообще работает на мелких и средних развертываниях - это лишний плюсик в карму авторов NT ACL, но на крупных развертываниях так делать нельзя, потому что это тяжело администрировать.
Исторически сложилось, что ACL легко интегрируются в службы каталогов, например, AD DACLs (Directory ACL), но и там это используется для низкоуровневых задач. Люди часто не понимают, что если речь идёт о корпоративной авторизации для доступа к данным вам нужен RBAC или даже ABAC, который, в общем случае, нельзя построить поверх ACL. Теоретически, минимальный можно построить поверх конкретно AD и его ACL, но это не пригодно к внедрению как RBAC. Но это я говорю про один портал, а если их много?
А если их много, вам нужны не ACL, Access Control Policy Sets. Например у вас есть набор фронтендов публикации вебсервисов и вам нужно вменять политики прав доступа относительно каких-нибудь токенов полученных из децентрализированной системы аутентификации. Это значит, что вы реализуете PEP (Policy Enforcement Point), сервер, который стоит между публикацией и запросом клиентского приложения. И вот если у вас таких политик много, написаны бизнес-процессы по их изменению на уровне организации, то обычно их принято оформлять как XACML: https://en.wikipedia.org/wiki/XACML
Это, кстати, к вопросу, почему "кровавый ынтерпрайз" так любит свой SAML2 и его расширения.
Начиная с 2014-го года активно (и важно понимать, что параллельно) развивается иная консьюмерская модель, которая применяется в рещениях B2C и работает поверх OpenID Connect и OAuth2. Разница в том, что у вас в корпоративной модели безопасники вменяют политики (клиенту можно, что безопасники разрешили), а в консьюмерской пользователь разрешает передачу данных, отправляя OAuth2 Consent (приложению можно, что клиенты разрешили). Обе эти модели имеют право на жизнь и прекрасно сосуществуют в корпоративном мире.
Казалось бы, причем тут ACL? ACL - это тот низкоуровневый механизм в каталоге, базе или на ФС, на который смотрят все эти системы. То что ACL на файловой системе не масштабируется - это стало понятно с появления функционала Public Folders в Microsoft Exchange. Они были предложены на замену файловым серверам. Когда оказалось, что Exchange не справляется и нужно еще больше функционала, этот кусок вытащили как Microsoft Office Server, а затем переименовали в Microsoft SharePoint. Причем старый урезанный функционал Public Folders с ACL-ками внутри Exchange до сих пор жив внутри в режиме какой-то там legacy-совместимости.
В самом крупном случае для организации вменяемое модели прав доступа в приложениях вам нужно:
Для B2B
1. Каталог пользователей с кучей стандартных атрибутов, для последующей конвертации в утверждения (claims)
2. База данных на стороне каждого приложения с расширенными атрибутами, специфичными для каждого конкретного приложения. Тоже для последующей конвертации в утверждения. В этих базах создаётся внутреннее понимание ролей, специфичных для приложения.
3. Secure Token Service - реализующий выдачу OAuth2 Token и SAML2 Assertion причём обоих одновременно. Он реализует выдачу подписанных сертификатами атрибутов в соответствующий формат и реализует федерации между партнерами (с другими организациями), когда нужно выдать доступы работникам одного предприятия в сервисах партнёра. Также STS должен уметь конвертировать утверждения в Kerberos-билеты.
4. Автоматизация кадрового учёта - формирует отражение ролей в смысле RBAC на НСИ в виде штатного расписания и должностных инструкций
5. Identity Management System - система управления ролями, реализующая модель "авторизация как бизнес-процесс", там у вас будут и политики и администрирование политик. Здесь определяются группы ролей.
6. ACL - на стороне операционных систем конечных устройств, файловых серверов, терминалов и всего остального.
Для B2C или взаимоотношениями с франч/ДЗО
7. Еще один федерированный (в смысле Kerberos) каталог с пользователями дочерних франч-организаций или пользователи-клиенты бизнеса
8. Облегченный STS реализующий исключительно OAuth2
9. CRM-система - формирует отражение ролей (в смысле RBAC) на НСИ в виде справочников контрагентов и услуги.
10. Еще одна IMS (опционально) - нужна, если существует множество разных клиентских порталов и личных кабинетов (у операторов связи так часто случается).
В случае применения парадигмы Bring yout own device или в случае внешнего контроля над конечным оборудованием дочерних предприятий
11. Инфраструктура интеграции с облачным провайдером-поставщиком Mobile Device Management и Endpoint Security. То что называется гибридным облаком.
12. Удаленное управление на стороне конечных мобильных устройств
Иными словами, если в вашей ОС ACL реализованы плохо, то она не придёт на Workstation и её не будет в терминале. Обратите внимание, что для мобильных телефонов ACL не особо-то и актуален, потому что они не шибко многопользовательские. Кроме того, мандатный контроль в ОС реализован c использованием ACL. То что входит в официальный стандарт POSIX является
Теперь что касается Linux:
Эта ОС исторически любит сопротивляться объективной реальности. Её пользователи часто напоминают адептов культа, бредящих о величии. Примеров много:
- ACL не нужен, нам хватит POSIX Permissions из 70-х.
- Ой нет, нас не хотят нигде использовать, давайте всунем недоделанные всеми выброшенные и никем кроме Linux не поддерживаемые POSIX ACLs, которые черновик.
- Ой, они не подходят большинству людей, давайте сделаем их опциональными
- Нам не нужен мандатный контроль.
... Пришло АНБ и написало SELinux...
- Из-за того что у нас нет нормальных ACL на уровне ядра система мандатного контроля обязана вменять ACL в своем собственном формате.
Когда до придурков, которые разрабатывают недо-каталоги вроде FreeIPA дойдёт, что контейнер OU (Organizational Unit) - это средство применяемое сервис провайдерами для синхронизации одних каталогов внутрь других и корпоративными пользователями в случае поглощения вновь купленных предприятий, то может кто-то догадается это куда-то ставить вместо AD в крупное развертывание. Придурки ведь умают, что пользователей нужно хранить в базах, как бы не понимая как медленно работает БД по сравнению с каталогом и как сложно в базе поменять схему.
Ну то есть такие необразованные фанатики как ты встречаются чаще чем хотелось бы и им там даже доверяют принимать решения:
https://en.wikipedia.org/wiki/TCP_offload_engine#Support_in_...
Это конечно оффтопик. Но да, разработчики-программисты ядра Linux решили, что TOE им не нужно, годами сопротивлялись внедрениям LRO и LSO и вот теперь мы имеем то что имеем: для работы с сетью тебе нужно взять драйверы сетевки разной степени проприетарности и работать с ними через DPDK, потому что ядро Linux и его адепты прибывают в состоянии вечного отрицания. Про подсистему хранения даже начинать не хочу. Про
И я уже не говорю про сеть и подсистему хранения. Ой всё...
Вот тебе пара тезисов попроще:
- То что в компаниях в которых ты работал точечно выдавали права на шаре каждому пользователю руками, даже не используя утверждения и не смотрели на атрибуты каталога - это не проблема ACL, это твои личные трудности, травмы детства и прочий бред.
- ACL - это низкоуровневый функционал, который лежит в основе много каких компонентов. От того что вы положили файлы в SharePoint Sites / Sharepoint Online, которые лежат в SQL, который кладут Blob Storage на SMB-шару (я сейчас не шучу, это так деплоится RBS и Azure Blob Storage) и вот там-то у вас что... вы не поверите...
Что ACL у него на файловой системе прямо совсем не нужны? "UNIX Permissions из 70-х хватит всем" или эти ископаемые права доступа тоже не нужны? А что нужно? Office 365? А ты знаешь как он работает? Про RBS и SMB-шары я сказал. Про то что outlook.com и Exchange Online хранят данные в Jet Blue (ESE) причем террабайтами рассказать? Или про то что AzureAD/Entra - это Active Directory работающее поверх того же Jet Blue. С теми самыми DACL, которые SharePoint Online так же как и On-Prem версия высасывает в базу чтобы присобачить к внутренним ролям портала.
