Средний ~25 мин чтения

RBAC: роли, права доступа и модели авторизации

Урок 6 из 6 в курсе Аутентификация и авторизация

RBAC: роли, права доступа и модели авторизации

RBAC (Role-Based Access Control) — назначение прав через роли; ABAC добавляет атрибуты; Policy-based auth — декларативное описание прав

Почему это важно: без явной модели авторизации права расползаются по коду; добавление новой роли превращается в поиск по всей кодовой базе

Главная идея

RBAC: пользователь → роли → права. Вместо проверки user.admin? проверяем user.can?(:edit, post) — логика прав централизована

Как это выглядит на практике

  1. Определяем роли: admin, editor, viewer.
  2. Назначаем права: editor может create/update статьи, viewer — только read.
  3. Middleware/before_action проверяет: current_user.can?(:update, @post).
  4. Policy object (Pundit/CanCanCan): class PostPolicy — authorize :update, если user == post.author || user.admin?
  5. Аудит: логируем все авторизационные решения с user_id, resource, action, result.

Что происходит под капотом

  • RBAC: users → roles → permissions. Три таблицы + join tables.
  • ABAC: решение зависит от атрибутов (кто, что, где, когда). Гибче RBAC, но сложнее.
  • ACL (Access Control List): права на каждый объект. Файловые системы Unix — пример ACL.
  • Policy objects (Pundit): один класс на ресурс; все правила в одном месте; легко тестировать.
  • Principle of Least Privilege: выдавай минимально необходимые права.

Типичные ошибки и заблуждения

  • Ошибка: if current_user.role == 'admin' разбросан по коду — это тоже авторизация. Плохая авторизация, которую сложно изменить и проверить.
  • Ошибка: роли достаточно — не нужна проверка владения. Редактор не должен редактировать чужие статьи, даже если он 'editor'.
  • Ошибка: авторизация только в контроллере. Проверяй права и при отображении (не показывай кнопку Delete) и при действии (проверяй на сервере).
  • Ошибка: RBAC всегда лучше ABAC. RBAC прост для стандартных случаев; ABAC нужен для сложных условных правил.

Ключевые выводы

  • Централизуй авторизационную логику: policy objects или dedicated service.
  • Роли + проверка владения ресурсом: user.can?(:edit, post) && post.author == user.
  • Principle of Least Privilege: минимально необходимые права по умолчанию.
  • Логируй авторизационные решения для аудита.

Термины урока

RBAC: модель авторизации через роли (admin, editor, viewer).
ABAC: авторизация через атрибуты субъекта, объекта и окружения.
Policy object: класс, инкапсулирующий правила авторизации для одного ресурса.
Principle of Least Privilege: пользователь получает только необходимые минимальные права.
ACL: список прав доступа, привязанный к конкретному объекту.

Связь с работой backend-разработчика

Используй Pundit (Ruby), Casbin (Go/Python/Java) или аналог для своего фреймворка. Policy objects тестируемы, централизованы и документируют бизнес-логику доступа.

Мини-разбор реальной ситуации

Приложение с if current_user.admin? разбросанным в 40 файлах. Задача: добавить роль 'moderator' с правами admin, кроме финансового раздела. Итог: 2 дня поиска по коду, 3 пропущенных места, продакшен-инцидент. С Pundit это изменение в одном файле policy.

Что запомнить

  • Авторизация — централизована: policy objects, не if-условия по всему коду.
  • Проверяй и роль, и владение ресурсом.
  • Least Privilege: не давай лишних прав 'на всякий случай'.

Итог

RBAC с policy objects — баланс простоты и гибкости. Централизованная авторизация делает права прозрачными, тестируемыми и изменяемыми без страха.