RBAC vs ABAC на собеседовании системного аналитика

Зачем спрашивают

В любой системе с пользователями нужно ответить на вопрос «кто что может». В ТЗ SA описывает права. На собесе спрашивают: «как реализовать авторизацию доступа», «когда RBAC, когда ABAC». Без понимания моделей кандидат начинает изобретать велосипед.

Главная боль без понимания темы — система с десятком ролей становится неуправляемой через год: «менеджер VIP-клиентов из филиала Москва имеет частичный доступ к договорам только своих клиентов и только если статус активный». Через 50 таких правил RBAC ломается, нужна ABAC.

ACL

Access Control List — для каждого объекта список (subject, permission).

file: /reports/2026.pdf
  - Anna: read, write
  - Boris: read
  - Catherine: read, delete

Плюсы: простота, локальность правил.

Минусы: при росте числа объектов — комбинаторный взрыв. Изменение прав группы пользователей — обновление ACL на всех объектах.

Когда уместно: Unix-файлы, корзины S3, Google Docs (sharing по ссылке).

RBAC

Role-Based Access Control — права назначаются ролям, пользователи получают роли.

Roles:
  admin     — full access
  manager   — read, write own department
  user      — read own profile

Users:
  Anna   → admin
  Boris  → manager

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

admin > manager > user

Admin наследует всё от manager, manager — от user.

Плюсы:

• Управляемость на средних системах (10-100 ролей)
• Удобно для аудита: «кто имеет доступ к X» = «у кого есть роль Y»

Минусы:

• При росте бизнес-логики количество ролей взрывается («manager_moscow_active_premium_payments_readonly»)
• Контекст-зависимая логика плохо ложится в роли

В ТЗ: список ролей с описанием permission, mapping ролей к функциям системы, кто и как назначает роли.

Стандарт: NIST RBAC (2004) — формальная модель.

ABAC

Attribute-Based Access Control — решение принимается на основе атрибутов subject, object, action, environment.

Policy: "Менеджер может читать договор, если"
  - subject.department == object.department
  - object.status == "active"
  - action == "read"
  - environment.time in working_hours

Атрибуты:

• Subject: role, department, location, clearance level
• Object: owner, sensitivity, status, type
• Action: read, write, delete, approve
• Environment: time, IP, device type, MFA enabled

Реализация: policy engine (OPA, Cedar, AWS IAM policies).

# OPA Rego
allow {
  input.subject.department == input.object.department
  input.object.status == "active"
  input.action == "read"
}

Плюсы:

• Гибкость — любая бизнес-логика выражается
• Не плодятся роли
• Декларативно: правила в одном месте

Минусы:

• Сложность отладки: «почему я не могу прочитать?» — неясно
• Дорогая авторизация (вычисление policy на каждый запрос)
• Тестирование политик — отдельная задача

Стандарт: XACML (XML-based, тяжеловесно), современные — Rego (OPA), Cedar (AWS).

Гибридные модели

Чистые RBAC или ABAC встречаются редко. Чаще:

RBAC + ABAC. Роль определяет крупные разрешения, ABAC — fine-grained. «Менеджер (роль) может видеть договоры (action) своего отдела (атрибут)».

ReBAC (Relationship-Based). Авторизация на основе связей в графе (кто кого знает, кто чего владеет). Используется в Google Drive (sharing), социальных сетях.

Anna -[owner]-> document_X
Anna -[shared]-> Boris
Boris -[can_read]-> document_X (через transitive)

Open-source: SpiceDB (как Google Zanzibar).

PBAC (Policy-Based). Близко к ABAC, фокус на бизнес-правилах.

Когда что выбирать

Эвристика: начинать с RBAC. Когда ролей становится >50 и они «слишком специфичны» — добавлять ABAC-слой.

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

Десятки специфичных ролей. «manager_moscow_premium_active». Признак, что нужен ABAC.

Хардкод правил в коде. Меняется бизнес-правило → деплой. Лучше — policy engine, конфигурация.

Не описывать в ТЗ. «Авторизация по ролям» — недостаточно. Нужен список ролей, permissions, кто назначает.

Игнорировать audit. Без логов «кто что делал и под какой ролью» — невозможно расследовать инциденты.

Один root для всего. Если admin может всё — компрометация одного аккаунта = катастрофа. Принцип least privilege + 4-eyes для критичных операций.

Time-bound permissions без истечения. Подрядчик получил доступ на 3 месяца — через год всё ещё имеет. Roles/permissions с TTL и periodic review.

Не различать authz и authn. Authentication = «кто ты», Authorization = «что тебе можно». На собесе классическая ловушка — путать понятия.

Связанные темы

• OWASP Top 10 на собесе SA
• JWT на собесе SA
• OAuth на собесе SA
• Подготовка к собесу системного аналитика
• REST API на собесе SA

FAQ

Что используется в Active Directory?

RBAC с группами. Группы могут быть вложенными (наследование). На enterprise-уровне — частая модель.

Можно ли RBAC и ABAC одновременно?

Да, это нормальный паттерн. Роли как «крупные разрешения», ABAC как «дополнительный фильтр». На уровне реализации — два слоя в policy engine.

Что такое scope в OAuth — это RBAC?

Близко. Scope = разрешение. Не привязан жёстко к ролям, ближе к ABAC по гибкости. Часто scopes = «coarse-grained permissions», RBAC у API — поверх scopes.

IAM в AWS — это RBAC или ABAC?

ABAC, реализован через JSON-policies с conditions на атрибуты (region, tag, time, MFA). Roles в IAM — это набор policies, ассоциированных с identity, не RBAC в классическом смысле.

Как тестировать ABAC-политики?

Unit-тесты на policy engine с mock-входами (subject, object, action, environment) → ожидаемое решение. Так же — fuzzing с corner cases.

Это официальная информация?

Нет. Статья основана на NIST RBAC (2004), NIST ABAC Guide (2014), документации OPA, Cedar и общей практике авторизации.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.