Всем привет!

Про принципы работы 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 ролей;
Учёт всех ролей;
Особые права для команд разработки.

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

Большая автоматизация начинается с маленьких кирпичиков, всем стабильной и прозрачной инфраструктуры!

Управление доступом к операционным системам на серверах. Как и какие проблемы решает RBAC