Роли и права пользователей: как построить модель RBAC на практике

Что такое RBAC и какую задачу он решает

RBAC (Role-Based Access Control) - модель управления доступом, в которой права собраны в роли, а пользователь получает их через членство в роли или группе. Вместо персонального набора разрешений для каждого сотрудника вы один раз описываете роль «дежурный администратор», а затем подключаете к ней нужных людей.

Модель закрывает три задачи. Первая: масштабирование. Пять пользователей с восемью правами дают 40 ручных связок, которые нужно помнить и поддерживать; та же логика через одну роль сводится к одной роли и пяти членствам. Вторая: аудит. Проверяющему достаточно посмотреть, в каких группах состоит учётная запись, чтобы оценить объём доступа. Третья: соблюдение принципа наименьших привилегий, когда каждый специалист получает только нужные для работы разрешения.

Одна и та же идея работает на разных уровнях инфраструктуры: в Active Directory роль существует как группа безопасности, в Kubernetes - как объекты Role и ClusterRole, в веб-приложении - как таблица ролей и проверка разрешений в middleware. RBAC остаётся базовой моделью для большинства корпоративных систем, хотя существуют и другие подходы (ABAC, MAC, DAC), о которых речь в конце статьи.

Ключевые понятия: роль, разрешение, пользователь, группа

Каркас модели образуют четыре сущности.

• Пользователь - субъект доступа: человек, сервисная учётная запись или под в Kubernetes. Права напрямую у пользователя не хранят.
• Разрешение - право выполнить конкретную операцию над конкретным ресурсом: «сбросить пароль учётной записи в подразделении Users», «прочитать логи пода в namespace prod», «удалить комментарий». Формулировка «полный доступ к серверам» слишком широкая, чтобы считаться разрешением: по ней нельзя ни проверить, ни отозвать доступ точечно.
• Роль - именованный набор разрешений под типовую задачу: «дежурный администратор», «разработчик», «аудитор». Роль не равна должности: два инженера с одинаковым названием позиции могут иметь разные роли, а один человек совмещать несколько ролей.
• Группа - способ собрать пользователей, чтобы назначать роли не персонально, а пачкой. В Active Directory это группы безопасности, в Kubernetes - subjects с kind: Group, в веб-приложении - связка user_roles или отдельная сущность teams.

Связь выстраивается в цепочку: пользователь → группа → роль → разрешение. Читается она справа налево: разрешение входит в роль, роль назначается группе, группа включает пользователей. Такая структура позволяет менять доступ в одной точке: добавили разрешение в роль, и его получили все, кто в неё входит.

Чем RBAC отличается от прямого назначения прав

При прямом назначении у каждого пользователя свой список прав, и число связок растёт как произведение пользователей на ресурсы. Для 50 сотрудников и 30 ресурсов это до 1500 потенциальных комбинаций. В ролевой модели число связок складывается из членств и разрешений внутри ролей, то есть растёт линейно: типовой набор из 10-15 ролей покрывает те же задачи.

Практическая разница видна на трёх сценариях. При увольнении сотрудника в RBAC достаточно убрать его из групп, тогда как при прямом назначении приходится искать все выданные права по разным системам. При переводе в другой отдел старые привилегии остаются в учётной записи и никем не замечаются. При проверке регулятору или внутреннему аудиту приходится объяснять, почему у бухгалтера есть право менять настройки кластера, если это право выдавали когда-то под разовую задачу.

Ролевая модель проигрывает только в одном: её нужно спроектировать до массовой выдачи доступов. Разовое назначение одного права быстрее, чем создание роли, поэтому в спешке роли часто обходят, и модель разрушается изнутри.

Принцип наименьших привилегий как основа проектирования ролей

Принцип наименьших привилегий (least privilege) означает: пользователь получает ровно те права, которые нужны для текущих задач, и не больше. Проектирование разворачивается в пять шагов.

1. Инвентаризация: выписать задачи, которые люди реально выполняют, и ресурсы, к которым обращаются.
2. Группировка задач по ролям: объединить похожие наборы действий.
3. Назначение минимальных разрешений: для каждой роли прописать конкретные операции.
4. Проверка на избыточность: сверить выданное с фактическим использованием.
5. Регулярный пересмотр: раз в квартал или полгода в зависимости от критичности.

Типичная ошибка на этом этапе - роль «на всякий случай» с широкими правами. Она появляется, когда администратор не хочет разбираться с заявками и выдаёт один большой набор. Через год никто не помнит, какие из этих прав используются, а отозвать их страшно, потому что «что-то сломается».

Наименьшие привилегии не означают, что широкий доступ запрещён всегда: иногда он оправдан и компенсируется контролем. По данным публикации Unite.AI, Anthropic планирует пригласить встроенную внешнюю ревизионную команду и выдать ей рабочие места в офисах, пропуска, ноутбуки компании и доступ к рабочим пространствам, инструментам и правам, в основном сопоставимый с доступом внутренних команд по оценке рисков. Широту доступа там уравновешивает право ревизоров публиковать ключевые выводы о рисках, инцидентах и практиках без редакционного контроля со стороны компании, кроме ограниченного набора случаев. Логика переносится на любую инфраструктуру: чем шире права, тем важнее независимый контроль, журналирование и прозрачность.

Как составить матрицу доступа и не утонуть в деталях

Матрица доступа - таблица, где строки это роли, столбцы ресурсы, а в ячейках перечислены действия. Начинайте с 3-5 ролей и расширяйте список по мере появления новых задач, иначе согласование матрицы превратится в отдельный проект.

Пример для типовой инфраструктуры:

Матрица живёт в Git рядом с инфраструктурным кодом: так у неё есть история, ревью и возможность отката. Изменение доступа оформляют pull request, где в diff видно, кому и что добавили. Если матрица лежит в переписке или в голове администратора, через полгода восстановить её не получится.

Как проверить роли на избыточность

Работают три метода. Анализ журналов доступа показывает, какие операции реально выполнялись. Опрос владельцев ролей выявляет права, которые остались от прошлых задач. Автоматическое сравнение фактических прав с эталонной матрицей находит расхождения без ручного просмотра.

Пример: если роль содержит право удалять виртуальные машины, а за полгода ни один вызов не зафиксирован в журнале, право переносят в отдельную роль и выдают под конкретную задачу. Периодичность пересмотра: раз в квартал для ролей с административными правами, раз в полгода для прикладных ролей. Критерий один: право, которое не использовалось с прошлой проверки, требует обоснования от владельца роли.

Реализация RBAC в Active Directory

В AD роль существует как группа безопасности, а разрешение - как право, назначенное этой группе. Пользователю права напрямую не выдают: любые исключения потом невозможно отследить, потому что они не видны в структуре групп.

Группы безопасности и делегирование: практическая схема

Классическая схема раскладывает доступ на четыре уровня и известна как AGDLP: Accounts (учётные записи), Global groups (глобальные группы), Domain Local groups (локальные доменные группы), Permissions (разрешения). Сотрудников добавляют в глобальные группы по подразделению или функции, глобальные группы включают в локальные доменные, а права на ресурс назначают уже локальной доменной группе. В лесу с несколькими доменами между уровнями добавляют универсальные группы: A-G-U-DL-P.

Пример для типовой компании: глобальная группа GG-HelpDesk-Users содержит сотрудников первой линии, локальная доменная группа DL-Users-PasswordReset получает делегированное право Reset Password на OU Users, а GG-HelpDesk-Users включают в DL-Users-PasswordReset. Сброс пароля появляется у человека через членство, а не через персональное назначение.

Делегирование настраивают мастером Delegation of Control Wizard на нужном OU: право сбрасывать пароли, разблокировать учётные записи, изменять членство в группах. Права на уровне домена выдают реже: они распространяются на все объекты и плохо поддаются точечному отзыву. Каждое делегирование фиксируют с указанием группы, OU и набора прав, иначе через год разобраться в наследовании будет сложно.

GPO ограничивают доступ средствами операционной системы. Параметры User Rights Assignment управляют локальным входом и входом по RDP, Restricted Groups фиксируют состав локальной группы администраторов, отдельная политика запрещает кэширование учётных данных на недоверенных машинах. Эти настройки дополняют RBAC, потому что закрывают путь к эскалации на конкретном хосте. Как связать каталог с остальной инфраструктурой через SSO, OIDC и SCIM, разобрано в статье про IAM для DevOps.

Типичные ошибки в AD и как их избежать

• Использование встроенных групп (Domain Admins, Account Operators) для повседневных задач. Решение: отдельные узкие группы под конкретные операции.
• Вложенность групп без документации: через два-три уровня никто не скажет, откуда у учётной записи права. Решение: фиксировать структуру в реестре и проверять её скриптом.
• Отсутствие владельца группы: заявки на изменение доступа некому согласовывать. Решение: указывать владельца в атрибуте managedBy.
• Выдача прав на уровне домена вместо OU. Решение: делегировать минимально возможную область.
• Отсутствие аудита: без включённой политики изменения групп остаются незамеченными. Решение: включить аудит управления учётными записями и собирать события на SIEM.

Реализация RBAC в Kubernetes

В Kubernetes RBAC встроен в API-сервер: он проверяет, разрешена ли операция над ресурсом для конкретного субъекта. Роли делятся по области действия: Role работает внутри одного namespace, ClusterRole действует на весь кластер. Привязки тоже парные: RoleBinding и ClusterRoleBinding.

Role и RoleBinding: доступ в пределах namespace

Role описывает правила тремя полями: apiGroups (группа API), resources (ресурсы) и verbs (действия). Пример роли для чтения подов и логов в namespace dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: dev
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

RoleBinding связывает роль с субъектом: пользователем, группой или ServiceAccount. В поле subjects указывают kind: User, kind: Group или kind: ServiceAccount, в roleRef - имя роли и её вид. Привязка действует только в своём namespace, поэтому роль с одинаковым именем в другом namespace доступа за его пределами не даёт.

Для команды разработчиков обычно хватает двух ролей: чтение подов и логов в dev и deploy в dev. Прав на чтение Secret в этих ролях быть не должно: именно через них чаще всего утекают учётные данные.

ClusterRole и ClusterRoleBinding: кластерные права

ClusterRole нужна для ресурсов без namespace (узлы, PersistentVolume, эндпоинты API-сервера) либо когда одну и ту же роль выдают в нескольких namespace. Связывают её двумя способами: ClusterRoleBinding даёт права на весь кластер, RoleBinding - только в одном namespace.

Основной риск сосредоточен в wildcard. Запись verbs: ["*"] и resources: ["*"] в ClusterRole превращает роль в администратора кластера, включая доступ к секретам и возможность создавать поды с привилегированным режимом. Практика простая: начинать с namespace-ролей и расширять права только под конкретную задачу, а wildcard оставлять для временного диагностического доступа с автоматическим отзывом.

ServiceAccount и права подов

ServiceAccount - идентификатор для процессов внутри пода. В каждом namespace автоматически создаётся ServiceAccount default, и под без явного указания работает от его имени. Если приложению не нужен доступ к API, токен лучше не монтировать: параметр automountServiceAccountToken: false ставят и в ServiceAccount, и в описании пода.

Когда доступ нужен, создают отдельный ServiceAccount, например ci-deployer для конвейера, и привязывают к нему Role с минимальным набором verbs. Проверить выданные права можно командой kubectl auth can-i --list --as=system:serviceaccount:dev:ci-deployer: она покажет полный список разрешённых операций и сразу выявит лишнее. Готовые манифесты для разработчиков, Jenkins и Prometheus с аудитом через kubectl auth can-i собраны в руководстве RBAC в Kubernetes 2026.

Реализация RBAC в веб-приложениях

В приложении модель держится на двух частях: схема данных, где хранятся роли и разрешения, и проверка доступа в коде. Права не хранят в коде: изменение роли не должно требовать релиза и пересборки образа.

Модель данных для ролей и разрешений

Минимальная схема включает пять таблиц:

• users - учётные записи;
• roles - роли с человекочитаемым именем;
• permissions - атомарные разрешения вида articles.edit, comments.delete;
• user_roles - связь пользователя и роли;
• role_permissions - связь роли и разрешения.

Пример: роль «модератор» получает разрешения comments.delete и users.ban, роль «редактор» - articles.create и articles.edit без articles.delete. Разрешение описывает одно действие над одним типом объекта: составные формулировки вроде «управлять контентом» приводят к путанице при проверке и мешают выдавать права частично.

Проверка доступа в коде: middleware и декораторы

Проверку концентрируют в одном месте. Middleware обрабатывает группу маршрутов: все пути /admin/* требуют разрешения admin.access, поэтому дублировать проверку в каждом контроллере не нужно. Декораторы или guard-функции закрывают точечные операции: удаление статьи требует articles.delete, а не только articles.edit.

Проверять доступ нужно на каждом уровне. Интерфейс скрывает недоступные кнопки, API отклоняет запрос без разрешения, база ограничивает операции на уровне ролей СУБД. Скрытая кнопка защитой не считается: запрос можно отправить напрямую, минуя интерфейс. Практический пример с матрицей ролей и проверкой через интерфейс и API приведён в материале как настроить роли и права пользователей в административной панели сайта.

Как поддерживать RBAC: аудит, автоматизация и пересмотр

После внедрения модель расходится с реальностью: появляются новые сервисы, сотрудники меняют команды, роли обрастают разрешениями. Поддержка сводится к трём практикам: аудит фактических прав, автоматизация выдачи и регулярный пересмотр.

Автоматизация выдачи прав через IaC

Роли и привязки описывают кодом. В Kubernetes это ресурсы Terraform kubernetes_role, kubernetes_role_binding, kubernetes_cluster_role, в AD - плейбуки Ansible с модулями win_domain_group и win_domain_group_membership. Смысл один: изменения проходят ревью в pull request, попадают в историю Git и откатываются той же командой, которой применялись.

Отдельная задача - контроль расхождений. Если права меняли руками через консоль или kubectl, следующее планирование Terraform покажет drift и предложит вернуть эталонное состояние. Правки, сделанные в обход репозитория, стоит либо перенести в код, либо осознанно оставить с записью в реестре исключений.

Регулярный пересмотр ролей и прав

Календарь пересмотра: раз в квартал для ролей с административными правами (кластерные роли, доступ к продакшн-базам, доменные группы администраторов), раз в полгода для прикладных ролей. Процесс строится на двух ролях: владелец подтверждает, что доступ ещё нужен, аудитор сверяет фактическое состояние с матрицей и снимает лишние членства.

Пример: сотрудник перешёл из поддержки в разработку, но старые роли HelpDesk остались в учётной записи и сохранили право сбрасывать пароли. Такие членства снимают в момент перевода, а не на ближайшем пересмотре. Для кластеров точку входа даёт базовая проверка конфигурации и прав, набор шагов описан в статье про аудит безопасности Kubernetes-кластера.

Типичные ошибки при внедрении RBAC и как их избежать

• Роль-монстр. Одна роль с широкими правами «на всякий случай». Решение: разделить обязанности на несколько ролей и совмещать их через членство.
• Дублирование ролей. Роли «разработчик 1» и «разработчик-2» с почти одинаковым набором. Решение: свести к одной роли, а различия вынести в отдельные узкие разрешения.
• Прямые назначения в обход ролей. Право, выданное конкретному пользователю, теряется при аудите и остаётся после перевода. Решение: единственный путь выдачи прав - через роль.
• Отсутствие владельца роли. Без ответственного роль не пересматривают. Решение: владелец для каждой роли, зафиксированный в реестре.
• Игнорирование ServiceAccount. Под работает под default и получает токен, который ему не нужен. Решение: отдельный ServiceAccount с узкой Role и automountServiceAccountToken: false.
• Wildcard в правах. Запись verbs: ["*"] в ClusterRole. Решение: перечислить конкретные verbs и resources, wildcard оставить только для временного диагностического доступа.
• Права в коде приложения. Список администраторов зашит в конфигурации или в условии. Решение: хранить роли в базе, а код проверяет наличие разрешения.

Общий признак всех ошибок один: доступ шире, чем требует задача, и никто не может объяснить, откуда он взялся. Каждая из них закрывается набором инструментов из этой статьи: матрица доступа, владелец роли, автоматизация выдачи и регулярный пересмотр.

Когда RBAC недостаточно: другие модели доступа

RBAC отвечает на вопрос «какая у пользователя роль», но плохо работает с правилами, которые зависят от контекста. Для таких случаев применяют другие модели.

• ABAC (attribute-based access control): решение принимается по атрибутам - отдел сотрудника, метка конфиденциальности документа, время суток, IP-адрес. Пример: доступ к документу открыт только в рабочие часы и только из корпоративной сети. Правило зависит от времени и места, поэтому роли его не выражают.
• MAC (mandatory access control): уровни доступа заданы системой, пользователь не может передать свои права другим. Применяют там, где требования к секретности жёсткие.
• DAC (discretionary access control): владелец объекта сам назначает права, как в файловой системе POSIX. Гибко, но предсказуемость доступа ниже.

На практике модели комбинируют: RBAC выдаёт базовые права по роли, ABAC добавляет условия. В Kubernetes это делают внешние движки политик - OPA Gatekeeper и Kyverno проверяют атрибуты запроса и могут отклонить действие, даже если RoleBinding формально его разрешает. Как выбрать модель и настроить её в Keycloak, LDAP и Kubernetes, разобрано в статье про RBAC и ABAC в IAM-системах.

Начните с матрицы доступа на 3-5 ролей для одной системы, назначьте каждой роли владельца и зафиксируйте дату первого пересмотра. Этого минимума достаточно, чтобы модель выдержала первый квартал эксплуатации и не превратилась в набор персональных исключений.