Что такое ролевая модель (Role-Permission model)?

Ролевая модель (Role-Based Access Control, RBAC)

Это система управления доступом, в которой права пользователей определяются не индивидуально, а через назначение ролей. Это один из самых распространённых и эффективных подходов в современных приложениях.

Основные концепции

Роль (Role) — набор разрешений, сгруппированных по смыслу. Например:

• Admin (администратор)
• Editor (редактор)
• Viewer (просмотрщик)
• Moderator (модератор)

Разрешение (Permission) — право выполнить конкретное действие:

• create_post
• edit_post
• delete_post
• moderate_comments
• manage_users

Пользователь (User) — объект, которому назначаются роли. Пользователь может иметь несколько ролей одновременно.

Архитектура модели

Отношение между сущностями:

Users → User_Roles → Roles → Role_Permissions → Permissions

Пример таблиц в БД:

CREATE TABLE users (
  id UUID PRIMARY KEY,
  username VARCHAR(255) NOT NULL,
  email VARCHAR(255) NOT NULL
);

CREATE TABLE roles (
  id UUID PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  description TEXT
);

CREATE TABLE permissions (
  id UUID PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  description TEXT
);

CREATE TABLE user_roles (
  user_id UUID REFERENCES users(id),
  role_id UUID REFERENCES roles(id),
  PRIMARY KEY (user_id, role_id)
);

CREATE TABLE role_permissions (
  role_id UUID REFERENCES roles(id),
  permission_id UUID REFERENCES permissions(id),
  PRIMARY KEY (role_id, permission_id)
);

Преимущества RBAC

1. Масштабируемость — при добавлении новых пользователей не нужно каждому индивидуально назначать права. Просто добавляете роль.

2. Управляемость — изменения в правах вносятся один раз для роли, влияя на всех её носителей. Если Editor'ам нужно добавить право на удаление, вы обновляете роль один раз.

3. Безопасность — легче отследить и аудировать, какие права имеет каждая роль. Снижает риск ошибок при выдаче доступа.

4. Гибкость — пользователь может иметь несколько ролей, комбинируя права из разных источников.

Практический пример: Система управления статьями

Роли:

• Author — может писать статьи (create_article)
• Editor — может редактировать статьи (edit_article), просматривать черновики
• Publisher — может публиковать статьи (publish_article)
• Admin — полный доступ

Сценарий: Пользователь Иван — одновременно Author и Editor. Его права = объединение прав обеих ролей.

Частые ошибки

1. Путаница между Role и Permission — не смешивайте их. Role — это набор Permission.
2. Слишком много ролей — если более 10 ролей, вы усложняете систему. Комбинируйте вместо этого.
3. Отсутствие аудита — всегда логируйте, кому и когда давали роли.
4. Прямое назначение Permission пользователю — всегда через Role. Иначе управление становится кошмаром.

RBAC vs ABAC

ABAC (Attribute-Based Access Control) — более гибкая модель, где доступ зависит от атрибутов (время, IP, контекст). RBAC проще в реализации, ABAC мощнее, но сложнее.

Вывод

RBAC — стандарт де факто для управления доступом. Используется в CMS, в системах управления проектами, в enterprise приложениях. Это надёжный, проверенный подход, который масштабируется с ростом системы.