Всем привет!
Про принципы работы Role Based Access Control (он же RBAC) слышали многие. Но реальное применение встречается довольно редко. Меня зовут Корняков Дмитрий, более 6 лет занимаюсь поддержкой инфраструктуры в команде Мир Plat.Form (НСПК). В статье расскажу про предпосылки создания, практическую реализацию и профит, который мы получили от ролевого доступа к ОС на инфраструктуре из 5000+ серверов в десятке доменов в разных ЦОД под управлением FreeIPA и Active Directory.
"Да что тут рассказывать – ещё на начальных курсах по админству про ролевую модель предоставления доступа рассказывают, и все всё знают" (с) Аноним
Когда-то мы использовали дискреционную модель выдачи прав (Discretionary Access Control, DAC). Она простая и эффективная при небольшом количестве серверов и администраторов, но имеет ряд недостатков, и самые существенные из них, напрямую влияющие на решение наших задач, ниже:
Накопление огромного количества правил;
Неочевидно, кто какие права имеет в моменте;
Администраторам систем приходится где-то хранить информацию, какие куда нужны права. Эта информация устаревает/теряется/etc;
Выход нового сотрудника/появление нового сервера может повлечь множество заявок на доступ, если с первого раза не заказали всё правильно;
Автоматизация выдачи прав при таком подходе выглядит утопией.
Например, на один сервер есть более 10 правил доступа, а серверов в информационной системе - 100. Приходит кто-то и просит выгрузить список администраторов. Проводим нехитрые подсчеты и получаем ужасающую цифру - вам придётся посмотреть 1000 правил. Да, можно что-то заскриптовать и что-то автоматизировать. Но автоматизация не решит таких вопросов, как выделение админов – ведь на сервер могут иметь права прикладные администраторы, ДБА, информационная безопасность. И у всех разные права вполне возможно, что разные они даже внутри одного подразделения.
А аудиторы могут попросить показать права из интерфейса системы, со скриншотами – представляете, если минимум сущностей, то уже выходит на 1000 скринов. Аудитору едва ли понятно, что делает скрипт, а объемы документации могут стать поводом посмотреть в сторону эффективности процессов в компании. Если вы не можете быстро и наглядно выяснить, у кого какие права — это уже звоночек.
Немного подробнее про DAC и сущности в правах
Active Directory - группа пользователей через доменную политику прилетает
на серверы в группы RDP доступа или LocalAdmin
FreeIPA – в линуксах добавляются:
Правила HBAC – каким сервисом можно войти на сервер - sshd/vsftpd/mysql/crond/etc;
Правила Sudo – какие команды под какими пользователями можно выполнять.
Дискреционная модель выдачи прав – это когда мы всегда выдаём ровно то, что просят. И выдаём, по большому счёту, не разбираясь, какие права уже есть.
Например, у нас есть команда из 3-х человек, у них есть 3 сервера. И набор правил, который описывает уровень доступа:
Появляется ещё один человек в команде, прилетает заявка на доступ, одному человеку на три сервера. Да кто разбираться будет, что там за правила есть, запилим новые!
Появляется 4-й сервер. Ну вы поняли:
А по пути можно заказать не все права, и какие-то из шагов выше могут повториться по нескольку раз. Сущности копятся лавинообразно.
Ролевая модель выдачи прав — это когда роли доступа к серверам предопределяются заранее.
Группа пользователей в таком случае выступает ролью и имеет чётко определённый набор прав. А предоставление прав — это всегда включение пользователя в предопределённую группу. И если подходящей группы нет, она создаётся совместно с функциональным администратором системы, а потом наполняется пользователями.
В таком случае каркас правил минимален и сущности не плодятся.
На примере правил FreeIPA:
Имя роли добавляется в поле “Описание” группы пользователей, для примера выше это CRM-WebDC-ПРОД_Администратор. “Человеческое” имя роли пригодится для последующего заказа в Service Desk, построения отчётов, понятного разграничения прав и т.д. Можно исходить из базового набора, например:
CRM-WebDC-ПРОД_Администратор
CRM-WebDC-ПРОД_Пользователь_БД
CRM-WebDC-ПРОД_Администратор_ИБ
И т.д.
Видно, что сущности для ролей переиспользуются, и по имени можно понять, что к чему относится:
Чтобы не скатиться обратно в дискреционную модель, нужно ввести ряд ограничений:
Одному пользователю можно назначить неограниченное количество ролей;
Один сервер может быть только в одной группе хостов, если нужно иное - оно вам не нужно, дробите группу серверов на две/три/etc;
В момент перехода на RBAC сервер удаляется из всех остальных групп доступа/правил.
Если в процессе эксплуатации системы вы понимаете, что появились люди, которым нужен доступ только на половину серверов из группы, значит вы пилите группу на две и увеличиваете гранулярность предоставления прав, создав новую роль. Также не должно возникать ситуации, когда вы даёте на сервер права и по RBAC, и дискретно.
А имея структурированные имена сущностей, их легко выгружать – раз в день любимым скриптовым языком парсите и отправляете в CMDB/WIKI/и т.д. Мы вот такую страничку сделали. Тут можно смотреть дифф с предыдущими состояниями, экспортировать и т.д.
Автоматизация с DevOPS
И вроде всё неплохо, но в процессе мы поняли, что такая история не работает со стендами разработки. Люди и серверы перемещаются между проектами, а права нужны вчера - по заявкам долго.
Да и состояние проектов у ребят описано в гите, и права назначаются через CI. Это отдельная история, подробнее можно почитать в статье тут.
Что мы сделали: примерно тот же формат именования, не всегда разделяем стенды на системы. А главное – мы дали права на предоставление ролей техучётке, которая вшита в CI.
Меняется описание проекта, добавляются пользователи – CI назначает им описанные роли.
Для этого во FreeIPA есть отличный механизм кастомных разрешений на права внутри каталога, о котором не все знают. Т.е. можно дать права ТУЗ управлять строго определённой группой пользователей. Вкладки RBAC -> Privileges, где даём нужные права на нужный DN.
Ниже пример Permission Settings “Разрешения”:
Это заняло порядочное количество времени, но мы не гнались. Для каждой системы нужно было рассказать что да как функциональным админам, выгрузить текущие права, определить на их основе роли. В итоге сейчас у нас на RBAC:
> 100 ИС, 3K серверов, 750 ролей;
Учёт всех ролей;
Особые права для команд разработки.
И всё чётко и структурировано. Теперь у нас есть набор кирпичиков, на основе которых можно развивать автоматизацию. От автоматического исполнения заявок на предоставление прав до триггерного изменения прав, например, при выходе/увольнении/переводе между подразделениями сотрудников, над чем мы сейчас и работаем.
Большая автоматизация начинается с маленьких кирпичиков, всем стабильной и прозрачной инфраструктуры!
