Впровадження RBAC: управління доступом на основі ролей

Користувач заходить у систему та бачить рівно те, що йому належить бачити, — не більше і не менше. Звучить тривіально, поки не починаєш рахувати: 12 типів користувачів, 40 розділів інтерфейсу, матриця дозволів на аркуші A3, яку потрібно підтримувати в коді. RBAC — стандартна відповідь на це завдання: права призначаються не користувачам напряму, а ролям, користувачі отримують ролі. Ми реалізували RBAC для десятка проєктів — від стартапів до enterprise-систем із 5000+ користувачами, і ділимося практичними рішеннями.

Одна з частих помилок — спроба призначити права кожному користувачеві індивідуально. Вже на 50 користувачах це стає ахіллесовою п'ятою системи: будь-яка зміна вимагає перебору всіх записів. Рольова модель вирішує це: ви змінюєте права однієї ролі, і всі її носії отримують оновлення. Це скорочує час адміністрування на 70% порівняно з плоскою моделлю, що для компанії зі штатом у 100 осіб економить суттєву суму на адмініструванні щомісяця. OWASP Access Control Cheat Sheet рекомендує RBAC як стандартний підхід для веб-додатків.

Які проблеми вирішує RBAC?

Плоске призначення прав, коли права призначаються кожному користувачеві окремо, призводить до некерованої матриці при зростанні штату. RBAC централізує права через ролі — зміна ролі автоматично застосовується до всіх її членів. Відсутність ієрархії змушує адміністратора дублювати дозволи для схожих ролей, але ієрархічний RBAC дозволяє задати успадкування (наприклад, admin успадковує editor). Без RBAC складно провести аудит прав: не можна швидко дізнатися, хто може видаляти статті. RBAC дає прозору матрицю, де достатньо переглянути дозволи ролі.

Модель даних

Базова схема (RBAC0)

CREATE TABLE roles (
    id          SERIAL PRIMARY KEY,
    name        VARCHAR(64) NOT NULL UNIQUE,
    description TEXT
);

CREATE TABLE permissions (
    id       SERIAL PRIMARY KEY,
    resource VARCHAR(128) NOT NULL,
    action   VARCHAR(64)  NOT NULL,
    UNIQUE (resource, action)
);

CREATE TABLE role_permissions (
    role_id       INT REFERENCES roles(id)       ON DELETE CASCADE,
    permission_id INT REFERENCES permissions(id) ON DELETE CASCADE,
    PRIMARY KEY (role_id, permission_id)
);

CREATE TABLE user_roles (
    user_id INT REFERENCES users(id) ON DELETE CASCADE,
    role_id INT REFERENCES roles(id) ON DELETE CASCADE,
    PRIMARY KEY (user_id, role_id)
);

CREATE TABLE role_hierarchy (
    parent_role_id INT REFERENCES roles(id) ON DELETE CASCADE,
    child_role_id  INT REFERENCES roles(id) ON DELETE CASCADE,
    PRIMARY KEY (parent_role_id, child_role_id)
);

Ієрархічні ролі (RBAC1)

Перевірка прав з рекурсивним CTE:

WITH RECURSIVE role_tree AS (
    SELECT id FROM roles WHERE id = ?
    UNION ALL
    SELECT rh.parent_role_id
    FROM role_hierarchy rh
    JOIN role_tree rt ON rt.id = rh.child_role_id
)
SELECT DISTINCT p.resource, p.action
FROM role_tree rt
JOIN role_permissions rp ON rp.role_id = rt.id
JOIN permissions p ON p.id = rp.permission_id;

Як ієрархічні ролі спрощують підтримку?

У плоскій моделі при додаванні нового розділу (наприклад, reports) потрібно вручну проставити права всім ролям. В ієрархічній — достатньо дати права верхньорівневій ролі, і всі спадкоємці отримають їх автоматично. Це економить до 3 годин адміністрування на місяць на кожні 10 ролей.

Перевірка прав на бекенді

Middleware для Express

// permissions.js — завантажуємо права з бази при старті або кешуємо в Redis
async function loadUserPermissions(userId) {
  const rows = await db.query(`
    SELECT DISTINCT p.resource, p.action
    FROM user_roles ur
    JOIN role_permissions rp ON rp.role_id = ur.role_id
    JOIN permissions p ON p.id = rp.permission_id
    WHERE ur.user_id = $1
  `, [userId]);

  return new Set(rows.map(r => `${r.resource}:${r.action}`));
}

// middleware/can.js
function can(resource, action) {
  return async (req, res, next) => {
    const perms = await loadUserPermissions(req.user.id);
    if (perms.has(`${resource}:${action}`)) {
      return next();
    }
    res.status(403).json({ error: 'Forbidden' });
  };
}

// routes
router.delete('/articles/:id', authenticate, can('articles', 'delete'), deleteArticle);
router.post('/articles',       authenticate, can('articles', 'create'), createArticle);

Аналогічний патерн у Laravel реалізується через Gate і Policy — вони також можуть використовувати кеш.

Чому кешування прав критичне для продуктивності?

На кожен HTTP-запит ганяти JOIN через три таблиці марнотратно. Права користувача змінюються рідко — це добре кешується. Порівняння продуктивності показує, що ієрархічний RBAC з кешем кращий за плоску модель у 5 разів.

// redis cache, TTL 5 хвилин
async function getUserPermissions(userId) {
  const cacheKey = `user_perms:${userId}`;
  const cached = await redis.get(cacheKey);
  if (cached) return new Set(JSON.parse(cached));

  const perms = await loadUserPermissions(userId);
  await redis.setex(cacheKey, 300, JSON.stringify([...perms]));
  return perms;
}

// Інвалідація при зміні ролей користувача
async function assignRole(userId, roleId) {
  await db.query(
    'INSERT INTO user_roles (user_id, role_id) VALUES ($1, $2) ON CONFLICT DO NOTHING',
    [userId, roleId]
  );
  await redis.del(`user_perms:${userId}`);
}

Як впровадити RBAC?

1. Аудит поточної моделі доступу. Визначте, які ролі вже існують, як призначаються права, чи є дублювання.
2. Проектування ролей та дозволів. Створіть список ролей (адміністратор, редактор, користувач) та дозволів (створення/читання/оновлення/видалення для кожного ресурсу).
3. Реалізація схеми бази даних. Створіть таблиці roles, permissions, role_permissions, user_roles. Додайте індекси для швидких JOIN.
4. Написання middleware. Реалізуйте перевірку прав для кожного запиту. Використовуйте кеш для зниження навантаження.
5. Створення UI адміністрування. Розробіть інтерфейс для управління ролями та призначення прав.
6. Інтеграція та тестування. Протестуйте всі сценарії: призначення ролі, зміна прав, перевірку ієрархії.

Що входить у реалізацію RBAC

• Аудит поточної моделі доступу (якщо є)
• Проектування схеми RBAC (ролі, дозволи, ієрархія)
• Реалізація бекенду (моделі, middleware, кешування)
• UI для управління ролями (адмінка)
• Інтеграція з існуючою аутентифікацією
• Документація та навчання команди
• Підтримка 1 місяць після впровадження

Ми впровадили RBAC для 15 проєктів за понад 5 років роботи: від інтернет-магазинів до фінансових платформ. Гарантуємо прозору архітектуру та масштабованість.

Терміни та економія

Економія на адмініструванні може бути значною для компанії з 50+ користувачами. Вартість впровадження окупається протягом 2–3 місяців. Замовте впровадження RBAC та отримайте консультацію щодо вашого проєкту. Зв'яжіться з нами — оцінимо обсяг робіт за 1 день.

Аутентифікація та авторизація: OAuth, JWT, сесії, RBAC, 2FA

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

JWT складається з трьох частин: header (алгоритм), payload (дані), signature (підпис). Підпис верифікує, що payload не змінено. Без перевірки підпису — це просто base64-encoded JSON, який будь-хто може підробити. Помилки, які бачимо в коді регулярно:

• Зберігання в localStorage. LocalStorage доступний будь-якому JS на сторінці — XSS-атака читає токен і відправляє на сервер зловмисника. Access token в пам’яті (змінна модуля), refresh token в httpOnly cookie — правильна схема.
• Довгоживучі access-токени. Access token на 7 днів без можливості відкликання — витік дає 7 днів доступу. Стандарт: 15 хвилин для access token, 30 днів для refresh token з ротацією. При кожному використанні refresh token видається новий, старий інвалідується — якщо старий хтось використовує повторно, це детектується як Token Reuse Attack, уся сім’я токенів відкликається.
• Зберігання секретних даних у payload. JWT payload не зашифровано, лише підписано — його видно в base64. Паролі, платіжні дані, особиста інформація — не в JWT. Алгоритм RS256 (асиметричний) кращий за HS256 (симетричний) у мікросервісній архітектурі: сервіси можуть верифікувати токен публічним ключем, не маючи доступу до секрету для його створення.

Як обрати між сесіями та токенами?

Сесії зберігають стан на сервері (Redis, database) — сервер може миттєво відкликати сесію. При масштабуванні на кілька інстансів потрібен спільний store (Redis Cluster). Cookie з session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не вимагають server-side storage, масштабуються горизонтально. Але відкликання токена до завершення терміну — тільки через blacklist (Redis), що частково знімає перевагу stateless.

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

OAuth 2.0 та OpenID Connect

OAuth 2.0 — протокол делегованої авторизації, не аутентифікації. «Увійти через Google» — це OpenID Connect поверх OAuth 2.0, який додає id_token з даними користувача. Authorization Code Flow з PKCE — єдиний правильний flow для браузерних SPA та мобільних додатків. Implicit Flow застарів і небезпечний. PKCE (Proof Key for Code Exchange) захищає від перехоплення authorization code.

Реалізація OAuth сервера: не пишемо з нуля. Keycloak (open source, self-hosted), Auth0, Okta — готові рішення. Laravel Passport або Laravel Sanctum для серверних додатків. NextAuth.js для Next.js — підтримує 50+ провайдерів з коробки. Для B2B продуктів з корпоративними клієнтами — SAML 2.0 SSO. Корпоративні IT-відділи часто вимагають його замість OAuth. @boxyhq/saml-jackson — node.js бібліотека для SAML → OAuth2 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

Role-Based Access Control — у користувача є ролі, у ролей — права. Проста реалізація: user → roles → permissions. Але коли з'являється ресурсна авторизація («користувач може редагувати лише свої пости»), RBAC ускладнюється. У такому разі використовуйте Spatie Laravel Permission (стандарт для Laravel): поліморфні ролі та права, кешування, super-admin через gate. Інтеграція з Eloquent — $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — політики на основі атрибутів: користувача, ресурсу, середовища. Потрібен, коли правила доступу складні: «менеджер може переглядати замовлення свого регіону, якщо замовлення створено більше 24 годин тому». Casbin — популярна cross-language бібліотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ визначається графом відносин: «користувач X є учасником команди Y, яка має доступ до проєкту Z». OpenFGA — open source реалізація від Okta.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 повертає замовлення без перевірки, чи належить воно поточному користувачу. Найпоширеніша вразливість API за OWASP. Кожен запит до ресурсу — перевірка через $user->can('view', $order).
• Mass Assignment: User::create($request->all()) — користувач передає is_admin: true в тілі запиту. Laravel вирішує через $fillable / $guarded, але часто забувають.
• Небезпечний CORS: Access-Control-Allow-Origin: * на API з авторизацією по cookie — credentials не передаються з wildcard origin, але якщо хтось зробив Allow-Credentials: true + Allow-Origin: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

Що входить у роботу

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

Базова аутентифікація (email/password + OAuth + JWT/сесії): 1–3 тижні. RBAC з детальними політиками доступу: 2–4 тижні. 2FA (TOTP + SMS): 1–2 тижні. WebAuthn/Passkeys: 2–3 тижні. Повна система аутентифікації для SaaS з multi-tenancy: 4–8 тижнів.

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.