Это как раз самое то. Потому иначе у тебя получается неуправляемая свалка, которую невозможно проаудировать, и заявки вида "скопируйте новому сотруднику X доступы уволившегося Y".

> По-хорошему, ресурсы, к которым выдаются доступы, тоже нужно группировать, и делать по схеме юзер->группа юзеров->группа ресурсов->ресурс

А вот с этим согласен.

Именно так работают коммерческие системы. Если вешать доступы "на сотрудника" - получаются "доступы-снежинки", единственные и неповторимые.

Я там выше скинул ссылку с костылями на эту тему :)

у меня успешно работает связка hbac/rbac на группу юзеров, дело в том что у юзера доступы могут быть не только на машины внутри домена, но и на внешние или впн адреса, и в этом случае это не работает

Значит нужно проектировать сетевой rbac с учетом этих требований и, например, с несколькими источниками данных.

А можно чуть конкретнее чем именно плохи доступы-снежинки? Я так-то в целом согласен, но неаргументированно-согласен.

так примерно и планировалось, если доступ для группы, но есть и уникальный доступ для сотрудника. Понятно что можно запилить монументальную поделку с отдельно стоящей субд, в которую надо будет ходить и дергать по логину юзера доступы, но это какой же крокодил получается. А так все компактно, 1 лдап запросом дергается

ну или 1-2 запроса к апи фрииипы...

Их невозможно аудировать, потому что у тебя нет самоописательной логики доступов, по которой можно было бы провести аудит, и, даже если ты требуешь в заявках на доступа описание, то не всегда оно будет (кто-то поленится заполнить, кто-то поленится потребовать корректное заполнение), и уж 100% будет вагон ситуаций, что ты смотришь на описание точечного доступа, но без уже утерянного контекста не можешь понять, зачем доступ был выдан.

Ну и 100% будут заявки "скопируйте доступы сотрудника Y сотруднику X", которые тоже последующий аудит доступов не облегчают.

а почему вот так сразу с ноги, если ds389, она какая-то особенная?

Посибо.

В общем, любые доступы нужно систематизировать и укладывать в какую-то логическую структуру, чтобы при взгляде на какой-то доступ вася может ходить на server1.foobar.xyz было понятно, что он может ходить не потому что он вася, а потому что он разработчик projectname, а server1.foobar.xyz — это тестовый стенд для бэкенда projectname.

И тогда сразу можно проверить, является ли до сих пор server1.foobar.xyz тестовым стендом projectname, а также является ли вася до сих пор разработчиком projectname.

это не работает IRL

У меня работает. IRL.

Но, конечно, нужна воля для претворения в жизнь. Потому что, если админ — это обслуга на побегушках разрабов, то, ясное дело, такую систему он сам не внедрит.

Не важно, сейчас вопрос не в стойкости админа или последствиях для Васи, сейчас вопрос в том правильно ли с точки зрения самой фриипы так делать, не сломается ли она от этого (мне кажется не сломается)

Просто прикол в том, что сейчас доступы пилятся в 3х разных системах и везде они разные, если все это сложить под крыло лдапа - будет удобно

Если говорить про hbac, то не сломается. Если же ты про сетевые доступы, которые ты хочешь в freeipa вкорячить, то freeipa, в целом, не очень подходящее место для их хранения. Но при этом может хороша в качестве одного из источников данных.