Primary
Zanzibar: Google's Consistent, Global Authorization System
Канонический источник про ReBAC на глобальном масштабе и tuple-модель отношений.
Модель авторизации определяет, как именно система принимает решение доступа. На практике команды комбинируют несколько подходов: RBAC как базовый слой, ABAC для контекста и исключений, ReBAC для graph-shaped collaboration, ACL как локальный механизм на уровне объекта.
Каноническая визуализация моделей
ACL
Права хранятся рядом с ресурсом как список субъектов и разрешений.
Сравнение моделей
| Критерий | ACL | RBAC | ABAC | ReBAC |
|---|---|---|---|---|
| Единица политики | Запись per resource | Роль | Правило | Отношение в графе |
| Гранулярность | Очень точная, но локальная | Средняя | Высокая | Высокая на графе |
| Изменения доступа | Дорого на больших наборах | Дёшево через role mapping | Через политику/атрибуты | Через новые relation tuples |
| Объяснимость | Высокая | Высокая | Средняя | Средняя, нужен explain API |
| Сложность платформы | Низкая | Низкая-средняя | Средняя-высокая | Высокая |
| Типичный масштаб | Локальные системы | Enterprise/B2B | Regulated domains | Collaboration at scale |
ABAC
NIST SP 800-162
Практические рекомендации по policy model и атрибутам для ABAC.
Границы применимости
ACL
Когда подходит: Object storage, файловые системы, небольшие изолированные домены с явным owner-правилом.
Где начинает болеть: Большие multi-tenant системы: слишком дорогие массовые изменения прав.
Граница: Используйте как edge-модель рядом с ресурсом, но не как единую глобальную политику для всей компании.
RBAC
Когда подходит: Внутренние платформы, B2B SaaS, зрелые org-структуры с понятными job functions.
Где начинает болеть: Контекстные решения (гео/время/риск) и объектные исключения per item.
Граница: Базовая модель для большинства систем. Усиливайте ABAC-предикатами или ACL-exceptions.
ABAC
Когда подходит: Домены с комплаенсом: финансы, healthcare, govtech, где важны контекст и классификация данных.
Где начинает болеть: Команды без governance для атрибутов и без тестируемого policy lifecycle.
Граница: Нужны строгий словарь атрибутов, audit policy changes и инструменты explain/trace решений.
ReBAC (Zanzibar)
Когда подходит: Коллаборативные продукты: документы, репозитории, рабочие пространства, сложные shared-графы.
Где начинает болеть: Малые системы, где граф отношений не окупает инфраструктурную сложность.
Граница: Оправдан при большом числе relationship checks и необходимости консистентного глобального AuthZ-сервиса.
В 2026 типичный production-подход: RBAC как каркас, ABAC как контекстные условия, ReBAC для shared-объектов, ACL как локальный override на ресурсе.
Типичные антипаттерны
Делать один 'god-role admin' и пытаться закрыть им все сценарии доступа.
Смешивать бизнес-атрибуты и security-атрибуты без owner и без data contract.
Строить ReBAC без explainability: пользователи не понимают, почему доступ есть или нет.
Оставлять права после org-изменений (offboarding/role change) без автоматического revoke.