Что такое RBAC и зачем он нужен в менеджере паролей
Представьте компанию из 80 человек. Есть IT-отдел, маркетинг, бухгалтерия, отдел продаж и DevOps-команда. У каждого отдела — свои сервисы, свои пароли, свои уровни конфиденциальности. Маркетолог не должен видеть пароли от production-серверов. Бухгалтер не должен иметь доступ к рекламным кабинетам. DevOps не нужны банковские реквизиты.
Как организовать всё это в корпоративном менеджере паролей так, чтобы каждый видел только то, что нужно для работы?
Ответ — RBAC.
Что такое RBAC
RBAC расшифровывается как Role-Based Access Control, ролевое управление доступом. Это модель, при которой права доступа назначаются не каждому пользователю отдельно, а ролям. Пользователь получает роль — и вместе с ней весь набор прав, которые этой роли соответствуют.
Простой пример. Есть роль «Менеджер по продажам». Этой роли доступны: CRM, корпоративная почта, мессенджер, сервис видеозвонков. Когда в компанию приходит новый менеджер по продажам, ему просто присваивают эту роль — и он автоматически получает доступ ко всему нужному. Не нужно вручную перебирать каждый сервис и думать, к чему открыть доступ.
Когда сотрудник переходит в другой отдел, роль меняется — меняются и все права. Когда увольняется, роль отзывается — все доступы закрываются одновременно.
Почему это важно именно для менеджера паролей
В корпоративном менеджере паролей хранятся учётные данные от всех систем компании. Без ролевой модели возможны два крайних сценария — оба плохие.
Сценарий 1: у всех доступ ко всему. Один общий сейф для всей компании. Удобно с точки зрения «не нужно настраивать», но катастрофично с точки зрения безопасности. Любой сотрудник видит пароли от серверов, банковских аккаунтов, учётных систем. При увольнении одного человека нужно менять все пароли, к которым он имел доступ — то есть потенциально все пароли в системе.
Сценарий 2: у каждого свой набор прав, настроенный вручную. 80 сотрудников, сотни сервисов. Администратор тратит часы на то, чтобы вручную выдать или отозвать доступ к каждому паролю. Это не масштабируется и неизбежно приводит к ошибкам: кто-то получает лишний доступ, у кого-то не хватает нужного.
RBAC решает обе проблемы. Доступ управляется через роли — это быстро, предсказуемо и аудируемо.
Как RBAC работает в BearPass
В BearPass ролевая модель реализована через сочетание ролей в системе и прав доступа к папкам.
Системные роли определяют, что пользователь вообще может делать в системе: видеть только свои папки, управлять доступами других, настраивать политики безопасности, просматривать журнал событий. Типичные роли: администратор, менеджер, пользователь.
Права на папки определяют, что конкретный пользователь или группа может делать с содержимым конкретной папки. Доступны три уровня:
«Только чтение» — сотрудник может использовать пароль через автозаполнение, но не видит его в явном виде и не может скопировать.
«Редактирование» — сотрудник видит пароль, может изменить его, добавить новые записи в папку.
«Администрирование» — полный контроль над папкой, включая управление правами других пользователей.
Группы пользователей позволяют присвоить права не одному человеку, а сразу всем членам группы. Создали группу «Маркетинг», добавили в неё всех маркетологов, открыли группе доступ к нужным папкам — готово. Новый маркетолог приходит в компанию, его добавляют в группу, и он автоматически получает все нужные доступы.
Практический пример настройки
Возьмём условную компанию с тремя отделами.
IT-отдел должен иметь доступ к папкам «Серверная инфраструктура», «Сетевое оборудование», «Облачные сервисы». Права на редактирование и администрирование — у старших инженеров, права на чтение — у всех остальных.
Маркетинг должен иметь доступ к папкам «Рекламные кабинеты», «Аналитика», «Социальные сети». Редактирование — у руководителя отдела, чтение — у исполнителей.
Бухгалтерия должна иметь доступ к папкам «Банковские сервисы», «Бухгалтерские программы», «Электронная отчётность». Доступ строго ограничен: только сотрудники бухгалтерии.
При этом каждый сотрудник также имеет личный сейф с отдельным ключом шифрования — для персональных паролей, которые не относятся к корпоративным системам.
Итого: 80 человек, три группы, несколько папок с разграниченными правами. Администратор тратит на первоначальную настройку несколько часов, после этого любые изменения в доступах занимают минуты.
Что происходит без RBAC при увольнении
Это один из самых наглядных аргументов в пользу ролевой модели.
Без RBAC: сотрудник увольняется, IT-отдел должен вручную перебрать все системы, к которым у него был доступ, и закрыть каждую. В среднем это занимает от трёх до пяти дней. За это время бывший сотрудник технически сохраняет доступ.
С RBAC и централизованным менеджером паролей: отзываем роль или удаляем пользователя из всех групп. Все доступы закрываются мгновенно. Можно сделать за минуту прямо во время финального разговора с сотрудником.
RBAC и принцип минимальных привилегий
RBAC хорошо сочетается с одним из базовых принципов информационной безопасности — принципом минимальных привилегий (least privilege). Суть проста: каждый пользователь должен иметь ровно столько прав, сколько необходимо для выполнения его работы, и ни одним разрешением больше.
На практике это означает: маркетолог не должен видеть пароли от серверов, даже если они хранятся в той же системе. Стажёр не должен иметь возможность удалять записи. Внешний подрядчик должен получить доступ только к конкретной папке на конкретный срок.
Реализовать принцип минимальных привилегий без ролевой модели крайне сложно. С RBAC это становится стандартным рабочим процессом.
Кому RBAC нужен в первую очередь
Ролевая модель актуальна для любой компании, где:
больше одного отдела с разными функциями и разными сервисами,
есть текучка кадров или работа с внешними подрядчиками,
есть чувствительные данные, доступ к которым должен быть ограничен,
компания проходит аудит безопасности или выполняет требования регуляторов — ФСТЭК, ЦБ, требования по 152‑ФЗ.
Для небольших команд до 10 человек RBAC тоже полезен, но там его можно реализовать проще — двух-трёх ролей обычно достаточно.
Итог
RBAC превращает управление доступами из ручной работы в управляемый процесс. Вместо того чтобы думать о каждом пользователе и каждом сервисе отдельно, вы один раз настраиваете роли и группы — дальше система управляет правами автоматически.
В контексте корпоративного менеджера паролей это означает: каждый сотрудник видит только те пароли, которые нужны ему для работы. Новый сотрудник получает нужные доступы в день выхода. Уволенный теряет все доступы мгновенно. А у ИБ-отдела есть полная картина того, кто к чему имел доступ.
Попробуйте BearPass бесплатно — настройте ролевую модель для своей команды за один день.
Рекомендуем к прочтению
[Управление секретами в DevOps и CI/CD: как не хранить пароли в коде
Как правильно встроить хранение секретов в конвейеры CI/CD и DevOps-процессы: практики, типичные ошибки, API и JWT-интеграция на примере BearPass.](/blog/upravlenie-sekretami-v-devops-i-cicd) [Принцип нулевого знания (zero-knowledge) в менеджерах паролей: как это работает
Разбираем, что стоит за архитектурой нулевого знания (zero-knowledge) в менеджерах паролей — технически и на практике. Что проверить перед выбором решения для бизнеса.](/blog/princip-nulevogo-znaniya-v-menedzherah-parolej) [ФСТЭК ужесточает требования: получить лицензии становится сложнее
Рост отказов в лицензировании, усиление проверок и что это значит для компаний и рынка информационной безопасности.](/blog/fstek-uzhestochaet-trebovaniya-licenziya-ib) [Блог BearPass
В блоге BearPass пишем о защите корпоративных доступов, управлении паролями и секретами, импортонезависимых решениях и построении безопасной ИТ-инфраструктуры.](https://bearpass.ru/blog)