Как стать автором
Обновить
60.63

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

Время на прочтение4 мин
Количество просмотров6.4K

Всем привет!

Про принципы работы 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 ролей;

  • Учёт всех ролей;

  • Особые права для команд разработки.

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

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

Теги:
Хабы:
Всего голосов 9: ↑9 и ↓0+9
Комментарии0

Публикации

Информация

Сайт
mir-platform.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
nspk