Модель контроля доступа выбирают не по тому, какая аббревиатура звучит современнее, а по тому, как реально устроены роли, ресурсы, контекст и связи в продукте.
Глава сравнивает ACL, RBAC, ABAC и ReBAC как разные способы принимать решение о доступе и показывает, как каждый из них влияет на выразительность правил, объяснимость, стоимость эксплуатации и рост системы.
Для design review это хороший материал, чтобы обсуждать политику доступа как часть доменной модели, а не как техническую надстройку, которую можно безболезненно заменить потом.
Практическая польза главы
Практика проектирования
Используйте материал по моделях контроля доступа ACL/RBAC/ABAC/ReBAC и их применимости, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по моделях контроля доступа ACL/RBAC/ABAC/ReBAC и их применимости: UX friction, latency overhead, стоимость сопровождения и требования compliance.
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 на ресурсе.
Контроли жизненного цикла политик доступа
| Этап | Обязательные контроли | Действие при провале |
|---|---|---|
| Policy design | Единый словарь ресурсов и действий, owner на каждую policy-зону, policy-as-code с code review. | Блокировать merge политики без владельца и без тестов, вернуть изменение в backlog команды. |
| Distribution and versioning | Версионирование policy bundles, canary rollout, подпись артефактов и проверка integrity на runtime. | Остановить rollout и автоматически откатить на последнюю стабильную policy-версию. |
| Decision path | Fail-closed на критичных эндпоинтах, deny-by-default, object-level checks для чувствительных операций. | Отключить рискованную операцию и поднять high-priority alert для on-call инженера. |
| Review and recertification | Плановые access review, recertification ролей, контроль orphan-доступов после орг-изменений. | Автоматически пометить доступ как временный и инициировать revoke до подтверждения владельцем. |
| Emergency revoke | Единый break-glass процесс, массовый revoke токенов/связей, проверка последствий по audit trail. | Перевести систему в ограниченный режим и принудительно завершить активные сессии высокого риска. |
Операционные метрики авторизации
P95 latency авторизационного check
Target: <= 20 ms
Если проверки дорогие, команды начинают обходить policy-layer и теряют консистентность доступа.
Доля решений с explain trace
Target: >= 99%
Нужна для разборов инцидентов и понятного ответа, почему доступ был выдан или отклонен.
MTTR отката policy-изменения
Target: < 10 минут
Быстрый rollback критичен, когда новая политика ломает production-потоки или легитимный доступ.
Просроченные доступы после offboarding
Target: 0
Показывает зрелость identity lifecycle и снижает риск несанкционированного доступа бывших пользователей.
Покрытие object-level checks на high-risk API
Target: 100%
Без object-level контроля сохраняется риск BOLA/IDOR даже при формально корректном AuthN.
Roadmap внедрения модели доступа
Фаза 1 (0-30 дней)
Фокус: Инвентаризация прав и критичных ресурсов
Результат: Карта субъектов, ролей, ресурсов и текущих исключений с назначенными владельцами.
Фаза 2 (30-60 дней)
Фокус: RBAC baseline и deny-by-default
Результат: Единый role catalog, централизованные policy-check middleware и базовые audit-логи решений.
Фаза 3 (60-90 дней)
Фокус: Контекстные правила и граф отношений
Результат: ABAC-предикаты для риска/контекста, ReBAC для shared-объектов, explain API для дебага доступа.
Фаза 4 (90+ дней)
Фокус: Governance и непрерывная верификация
Результат: Регулярные access review, policy quality gates в CI/CD и измеримые SLO для authorization-платформы.
Типичные антипаттерны
Делать один 'god-role admin' и пытаться закрыть им все сценарии доступа.
Смешивать бизнес-атрибуты и security-атрибуты без owner и без data contract.
Строить ReBAC без explainability: пользователи не понимают, почему доступ есть или нет.
Оставлять права после org-изменений (offboarding/role change) без автоматического revoke.
References
Связанные главы
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - Дает IAM-основу: access model не работает отдельно от identity lifecycle и trust контекста.
- Zero Trust: современный подход к безопасности архитектуры - Показывает, как ACL/RBAC/ABAC/ReBAC встраиваются в continuous policy enforcement и verify-every-request.
- API Security Patterns - Переносит модели доступа в прикладной контур API: object-level checks, token policies и deny-by-default.
- Secrets Management Patterns - Связана с сервисными идентичностями и безопасной доставкой секретов для policy engines и runtime-контролей.
- Data Governance & Compliance - Дополняет тему через data classification, auditability и требования комплаенса к управлению доступом.