Ролевая модель контроля доступа (RBAC)

Ролевая модель контроля доступа (Role-Based Access Control, RBAC) — это мощная парадигма безопасности, где права доступа назначаются не отдельным пользователям, а ролям, которые затем присваиваются пользователям.

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

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

RBAC можно описать следующим математическим аппаратом:

• U — множество пользователей: U = {u₁, u₂, …, uₙ}
• R — множество ролей: R = {r₁, r₂, …, rₘ}
• P — множество привилегий: P = {p₁, p₂, …, pₖ}
• UA — назначение пользователей ролям: UA ⊆ U × R
• PA — назначение привилегий ролям: PA ⊆ P × R
• RH — иерархия ролей: RH ⊆ R × R (частичный порядок)

Тогда доступ пользователя u к привилегии p разрешен, если: ∃r ∈ R: (u, r) ∈ UA ∧ (p, r) ∈ PA

RBAC естественно представляется в виде ориентированного графа:

• Вершины: пользователи, роли, привилегии
• Рёбра: отношения между вершинами (назначения и иерархии)

NIST определил четыре уровня (референсные модели) RBAC:

1. Core RBAC — базовая модель с пользователями, ролями и привилегиями
2. Hierarchical RBAC — добавляет иерархию ролей и наследование
3. Constrained RBAC — вводит разделение обязанностей (SoD)
4. Symmetric RBAC — добавляет разрешения на основе привилегий

Архитектура RBAC включает:

1. Пользователи (Users) — субъекты, получающие доступ к системе
2. Роли (Roles) — наборы прав, соответствующие должностным функциям
3. Привилегии (Permissions) — права доступа к конкретным ресурсам
4. Сессии (Sessions) — активные подключения пользователей
5. Иерархия ролей (Role Hierarchy) — отношения наследования между ролями
6. Ограничения (Constraints) — правила, регулирующие назначение ролей

Иерархия ролей позволяет одним ролям наследовать привилегии других, что отражает организационную структуру:

Главный администратор
├── Администратор БД
│   └── Оператор резервного копирования
└── Сетевой администратор
    └── Мониторинг сети

1. Статическое разделение обязанностей (Static SoD)

   • Пользователь не может быть назначен на конфликтующие роли
   • Пример: Один пользователь не может быть одновременно “Инициатор платежа” и “Утверждающий платежа”

2. Динамическое разделение обязанностей (Dynamic SoD)

   • Пользователь не может активировать конфликтующие роли в одной сессии
   • Пример: Нельзя одновременно действовать как “Аудитор” и “Администратор”

3. Кардинальность (Cardinality)

   • Ограничение на количество пользователей в роли или ролей у пользователя
   • Пример: “Системный администратор” — максимум 3 пользователя

В AD роли реализуются через:

• Группы безопасности — для управления доступом
• Делегирование управления — для административных функций
• Групповые политики — для применения настроек

Пример структуры групп:

DOMAIN\IT
├── DOMAIN\IT-Administrators
├── DOMAIN\IT-Developers
└── DOMAIN\IT-Support
    ├── DOMAIN\IT-HelpDesk-L1
    └── DOMAIN\IT-HelpDesk-L2

AWS реализует RBAC через:

• IAM Roles — роли для сервисов и федерации
• IAM Groups — группы пользователей
• IAM Policies — политики доступа в формате JSON

Пример архитектуры:

AWS Account
├── AdminRole (полный доступ)
├── DeveloperRole (разработка и тестирование)
└── AuditorRole (только чтение)

Oracle использует сложную модель RBAC:

• Roles — роли с наборами привилегий
• System Privileges — системные привилегии
• Object Privileges — привилегии на объекты

Пример иерархии:

DBA
├── RESOURCE (создание объектов)
└── CONNECT (базовое подключение)

PostgreSQL реализует RBAC через:

• Roles (с атрибутом INHERIT для наследования)
• Grant/Revoke для управления привилегиями
• Row-level security для детального контроля

Kubernetes использует развитую модель RBAC:

1. Subjects — пользователи, группы, сервисные аккаунты
2. Resources — поды, сервисы, секреты и т.д.
3. Verbs — действия (get, list, create, update, delete)
4. Roles/ClusterRoles — наборы правил
5. RoleBindings/ClusterRoleBindings — связывание ролей с субъектами

Пример ролей Kubernetes:

• cluster-admin — полный контроль над кластером
• admin — полный доступ к ресурсам в namespace
• edit — изменение ресурсов в namespace
• view — только просмотр ресурсов

1. Упрощение администрирования

   • Централизованное управление доступом
   • Снижение количества индивидуальных настроек
   • Удобство при изменении организационной структуры

2. Масштабируемость

   • Легкое добавление новых пользователей
   • Стабильность модели при росте организации
   • Поддержка сложных иерархий и отношений

3. Безопасность

   • Принцип наименьших привилегий
   • Разделение обязанностей
   • Снижение риска избыточных привилегий

4. Соответствие требованиям регуляторов

   • Поддержка процессов аудита
   • Четкое распределение ответственности
   • Документированность политик доступа

5. Бизнес-ориентированность

   • Соответствие организационной структуре
   • Отражение бизнес-процессов в модели доступа
   • Понятность для нетехнических специалистов

1. Сложность первоначальной настройки

   • Требуется тщательный анализ ролей
   • Необходимость классификации ресурсов
   • Разработка политик для различных сценариев

2. Потенциальное разрастание ролей

   • “Взрыв ролей” при большом количестве исключений
   • Создание уникальных ролей для узких задач
   • Сложность поддержки при большом количестве ролей

3. Ограниченная гранулярность

   • Невозможность учета контекста доступа
   • Сложность реализации временных или условных привилегий
   • Недостаточная гибкость для некоторых сценариев

4. Проблемы с кросс-функциональными ролями

   • Сложность моделирования матричных организаций
   • Необходимость множественных назначений ролей
   • Возможные конфликты при наследовании

5. Задержка обновления при организационных изменениях

   • Необходимость переназначения ролей при переводах
   • Риск устаревания модели при быстрых изменениях
   • Административная нагрузка при реорганизациях

Сценарий: Физико-математическая школа внедряет единую информационную систему для управления учебным процессом, оценками, расписанием и учебными материалами.

Задача: Разработать модель RBAC для обеспечения правильного разграничения доступа.

Решение:

1. Определение ролей:

   • Администратор системы
   • Директор школы
   • Завуч
   • Учитель-предметник
   • Классный руководитель
   • Ученик
   • Родитель
   • Методист
   • Библиотекарь

2. Иерархия ролей:

   Директор школы
   ├── Завуч
   │   ├── Методист
   │   └── Классный руководитель
   │       └── Учитель-предметник
   └── Библиотекарь
   

3. Матрица доступа:

   Роль / Ресурс	Личные дела	Оценки	Расписание	Учебные материалы	Отчеты
   Директор	ЧЗИ	ЧЗИ	ЧЗИ	ЧЗИ	ЧЗИ
   Завуч	ЧЗ	ЧЗИ	ЧЗИ	ЧЗИ	ЧЗИ
   Классный руководитель	Ч (свой класс)	ЧЗ (свой класс)	Ч	ЧЗ (свой предмет)	Ч (свой класс)
   Учитель	Нет	ЧЗ (свои предметы)	Ч	ЧЗ (свой предмет)	Ч (свои предметы)
   Ученик	Ч (своё)	Ч (свои)	Ч	Ч	Нет
   Родитель	Ч (своего ребенка)	Ч (своего ребенка)	Ч	Нет	Нет

   Обозначения: Ч - чтение, З - запись, И - изменение структуры/удаление

4. Ограничения:

   • Статическое SoD: “Учитель” и “Ученик” несовместимы
   • Динамическое SoD: “Классный руководитель” и “Методист” не могут использоваться одновременно
   • Временное ограничение: Родители имеют доступ только в определенные часы

Сценарий: Лаборатория квантовой физики проводит эксперименты и обрабатывает результаты в распределенной вычислительной среде.

Задача: Разработать RBAC-модель для защиты экспериментальных данных и вычислительных ресурсов.

Решение:

1. Роли:

   • Руководитель лаборатории
   • Старший научный сотрудник
   • Научный сотрудник
   • Лаборант
   • Инженер оборудования
   • Системный администратор
   • Внешний рецензент

2. Привилегии для научных данных:

   • Руководитель: полный доступ ко всем данным
   • Старший научный сотрудник: чтение/запись данных своей группы, чтение данных других групп
   • Научный сотрудник: чтение/запись своих данных, чтение общих данных
   • Лаборант: запись сырых данных, ограниченный доступ к результатам
   • Внешний рецензент: временный доступ только к определенным наборам данных

3. Привилегии для вычислительных ресурсов:

   • Системный администратор: управление всей инфраструктурой
   • Инженер оборудования: настройка экспериментального оборудования
   • Научные сотрудники: запуск вычислительных задач с разными приоритетами в зависимости от роли

1970      1980      1990      2000      2010      2020
  |         |         |         |         |         |
  v         v         v         v         v         v
[DAC] --> [MAC] --> [RBAC] --> [RBAC+] --> [ABAC] --> [NGAC]
                      |           |
                      v           v
                   [LBAC]     [ReBAC]

DRBAC расширяет стандартный RBAC, добавляя:

• Временные ограничения (доступ в определенные часы)
• Контекстные условия (геолокация, устройство доступа)
• Динамическую активацию/деактивацию ролей

ARBAC объединяет преимущества RBAC и ABAC:

• Основа модели — роли (для масштабируемости)
• Дополнительные атрибуты (для гибкости)
• Правила, учитывающие контекст доступа

Модификация RBAC для облачных и распределенных сред:

• Роли в разных доменах безопасности
• Федеративные отношения между ролями
• Многоуровневое администрирование ролей

Сценарий: В научном центре сложилась следующая структура ролей и привилегий для информационной системы:

- Администраторы (5 пользователей, 35 привилегий)
- Руководители отделов (8 пользователей, 20 привилегий)
- Научные сотрудники (45 пользователей, 15 привилегий)
- Лаборанты (30 пользователей, 8 привилегий)
- Администраторы отдела физики (2 пользователя, 28 привилегий)
- Администраторы отдела химии (2 пользователя, 28 привилегий)
- Руководители проектов (12 пользователей, 18 привилегий)
- Сотрудники бухгалтерии (6 пользователей, 10 привилегий)
- Системные аналитики (4 пользователя, 12 привилегий)

Задание:

1. Проанализировать структуру на предмет избыточности и неэффективности
2. Спроектировать оптимизированную иерархию ролей
3. Определить, какие роли можно объединить или разделить
4. Предложить механизмы для управления исключениями

Сценарий: Физико-математическая школа организует международную научную конференцию с онлайн-системой для регистрации, подачи докладов, рецензирования и публикации материалов.

Задание:

1. Определить всех участников процесса и их функциональные обязанности
2. Спроектировать систему ролей и иерархию
3. Определить привилегии для каждой роли
4. Проработать временные аспекты (этапы конференции)
5. Предусмотреть механизмы для делегирования полномочий

Техническое задание:

1. Представить структуру RBAC как ориентированный граф
2. Разработать алгоритм для проверки наличия доступа с учетом иерархии ролей
3. Реализовать алгоритм обнаружения избыточных назначений ролей
4. Решить задачу оптимизации назначений для минимизации количества ролей при сохранении необходимых привилегий

• 1992: Первая формальная модель RBAC (Ferraiolo and Kuhn)
• 1996: Иерархическая модель RBAC (Sandhu)
• 2000: Временные ограничения в RBAC
• 2004: Стандарт ANSI INCITS 359-2004
• 2010: Интеграция с федеративными системами идентификации
• 2015: Адаптация для облачных сред и микросервисов
• 2020+: Гибридные модели (RBAC+ABAC, ReBAC)

1. Интеллектуальный RBAC

   • Применение машинного обучения для оптимизации ролей
   • Автоматическое обнаружение аномалий в назначениях
   • Рекомендательные системы для администраторов

2. Квантовые вычисления и RBAC

   • Квантовая криптография для защиты назначений ролей
   • Новые модели для квантовых информационных систем

3. Децентрализованные модели

   • RBAC на основе блокчейна
   • Смарт-контракты для управления ролями и привилегиями

4. Биоинспирированные подходы

   • Адаптивные RBAC системы по аналогии с иммунными системами
   • Самоорганизующиеся структуры ролей

• “Role-Based Access Control” - David F. Ferraiolo, D. Richard Kuhn, Ramaswamy Chandramouli
• “Security Engineering” - Ross Anderson
• “Enterprise Security Architecture” - Nicholas Sherwood
• “Identity and Access Management: Business Performance Through Connected Intelligence” - Ertem Osmanoglu

• Microsoft Identity Manager
• SailPoint IdentityIQ
• RSA Identity Governance & Lifecycle
• Apache Fortress
• OpenIAM

1. В чем фундаментальное отличие RBAC от DAC и MAC?
2. Какие проблемы решает иерархия ролей в RBAC?
3. Что такое “взрыв ролей” и как его избежать?
4. Как реализовать принцип наименьших привилегий с помощью RBAC?
5. Каковы преимущества RBAC при организационных изменениях?
6. Почему RBAC является предпочтительной моделью для корпоративных систем?
7. Какие ограничения RBAC могут привести к необходимости перехода на ABAC?
8. Как правильно спроектировать иерархию ролей, отражающую организационную структуру?