Модель контроля доступа выбирают не по тому, какая аббревиатура звучит современнее, а по тому, как реально устроены роли, ресурсы, контекст и связи в продукте.
Глава сравнивает ACL, RBAC, ABAC и ReBAC как разные способы принимать решение о доступе и показывает, как каждый подход влияет на выразительность правил, объяснимость, стоимость эксплуатации и рост системы.
Для ревью дизайна это хороший материал, чтобы обсуждать политику доступа как часть доменной модели, а не как техническую надстройку, которую можно безболезненно заменить потом.
Практическая польза главы
Практика проектирования
Выбирайте модель доступа по структуре домена: ролям, ресурсам, контексту запроса и связям между объектами.
Качество решений
Проверяйте не только выразительность политики, но и объяснимость решения, стоимость изменений и устойчивость к дрейфу прав.
Аргументация на интервью
Объясняйте выбор через сценарий: кто делает действие, над каким ресурсом, в каком контексте и почему именно эта модель подходит.
Формулировка компромиссов
Явно проговаривайте цену ACL, RBAC, ABAC и ReBAC: простоту, гибкость, задержку проверки, аудит и сложность эксплуатации.
Primary
Zanzibar: Google's Consistent, Global Authorization System
Канонический источник про ReBAC на глобальном масштабе и кортежную модель отношений.
Модель авторизации определяет, как именно система принимает решение доступа. На практике команды комбинируют несколько подходов: , , и на уровне объекта.
Каноническая визуализация моделей
Один и тот же запрос может читать локальный список, каталог ролей, контекстные атрибуты или граф отношений. Переключайте модель, чтобы увидеть, где система принимает решение доступа.
Список доступа рядом с ресурсом
ACL подходит, когда решение можно принять по локальной записи конкретного объекта: кто имеет право читать, менять или администрировать ресурс.
1. Кто запрашивает
Субъект
Пользователь, группа или сервис приходит с действием, например read или write.
2. Что защищаем
Ресурс
Документ, файл, объект хранилища или запись несёт собственный список доступа.
3. Проверка
Список доступа
Система ищет субъект или группу в локальных разрешениях ресурса.
4. Выход
Разрешить или запретить
Если подходящей записи нет, безопасная настройка - запретить действие.
Когда модель удобна
- Права легко объяснить для одного объекта.
- Хорошо работает в небольших изолированных доменах.
- Массовые изменения доступа быстро становятся дорогими.
Как читать схему
Читайте ACL как локальную проверку рядом с ресурсом: она проста и прозрачна, но плохо заменяет глобальную политику доступа.
Сравнение моделей
| Критерий | ACL | RBAC | ABAC | ReBAC |
|---|---|---|---|---|
| Единица политики | Запись рядом с ресурсом | Роль | Правило | Отношение в графе |
| Гранулярность | Очень точная, но локальная | Средняя | Высокая | Высокая на графе |
| Изменения доступа | Дорого на больших наборах | Через политики и атрибуты | ||
| Объяснимость | Высокая | Высокая | Средняя | Средняя, нужен |
| Сложность платформы | Низкая | Низкая-средняя | Средняя-высокая | Высокая |
| Типичный масштаб | Локальные системы | Корпоративные и B2B-системы | Регулируемые домены | Масштабная совместная работа |
ABAC
NIST SP 800-162
Практические рекомендации по модели политик и атрибутам для ABAC.
Границы применимости
ACL
Когда подходит: Объектные хранилища, файловые системы и небольшие изолированные домены с явным правилом владельца.
Где начинает болеть: Большие : массовые изменения прав становятся слишком дорогими.
Граница: Используйте как локальную модель рядом с ресурсом, но не как единую глобальную политику для всей компании.
RBAC
Когда подходит: Внутренние платформы, B2B SaaS и зрелые организационные структуры с понятными должностными функциями.
Где начинает болеть: Контекстные решения по географии, времени и риску, а также исключения на уровне отдельных объектов.
Граница: Базовая модель для большинства систем. Усиливайте её ABAC-предикатами или исключениями на уровне ресурса.
ABAC
Когда подходит: Домены с требованиями комплаенса: финансы, медицина, государственные сервисы, где важны контекст и классификация данных.
Где начинает болеть: Команды без управления атрибутами и без тестируемого .
Граница: Нужны строгий словарь атрибутов, аудит изменений политики и .
ReBAC (Zanzibar)
Когда подходит: Коллаборативные продукты: документы, репозитории, рабочие пространства и сложные общие графы отношений.
Где начинает болеть: Малые системы, где граф отношений не окупает инфраструктурную сложность.
Граница: Оправдан при большом числе и необходимости консистентного глобального .
В 2026 типичный промышленный подход: RBAC как каркас, ABAC как контекстные условия, ReBAC для общих объектов, ACL как локальное переопределение на ресурсе.
Контроли жизненного цикла политик доступа
| Этап | Обязательные контроли | Действие при провале |
|---|---|---|
| Проектирование политики | Единый словарь ресурсов и действий, владелец на каждую , с ревью кода. | Блокировать слияние политики без владельца и тестов, вернуть изменение в бэклог команды. |
| Доставка и версионирование | Версионирование , , подпись артефактов и проверка целостности в среде выполнения. | Остановить внедрение и автоматически откатить систему на последнюю стабильную . |
| Путь принятия решения | на критичных эндпоинтах, и проверки на уровне объекта для чувствительных операций. | Отключить рискованную операцию и поднять срочное оповещение для инженера. |
| Ревью и повторное подтверждение | Плановые , и контроль после организационных изменений. | Автоматически пометить доступ как временный и инициировать до подтверждения владельцем. |
| Экстренный отзыв доступа | Единый процесс , массовый отзыв токенов и связей, проверка последствий по . | Перевести систему в ограниченный режим и принудительно завершить активные сессии высокого риска. |
Операционные метрики авторизации
P95 задержки авторизационной проверки
Цель: <= 20 ms
Если проверки дорогие, команды начинают обходить слой политики и теряют консистентность .
Доля решений с трассой объяснения
Цель: >= 99%
Нужна для разборов инцидентов и понятного ответа, почему доступ был выдан или отклонен.
MTTR отката изменения политики
Цель: < 10 минут
Быстрый критичен, когда новая политика ломает промышленные потоки или легитимный доступ.
Просроченные доступы после отключения учётной записи
Цель: 0
Показывает зрелость и снижает риск несанкционированного доступа бывших пользователей.
Покрытие проверок на уровне объекта для API высокого риска
Цель: 100%
Без объектного контроля сохраняется риск BOLA/IDOR даже при формально корректной AuthN.
План внедрения модели доступа
Фаза 1 (0-30 дней)
Фокус: Инвентаризация прав и критичных ресурсов
Результат: Карта субъектов, ролей, ресурсов и текущих исключений с назначенными владельцами.
Фаза 2 (30-60 дней)
Фокус: RBAC-каркас и запрет по умолчанию
Результат: Единый , централизованный и базовые журналы аудита решений.
Фаза 3 (60-90 дней)
Фокус: Контекстные правила и граф отношений
Результат: ABAC-предикаты для риска и контекста, ReBAC для общих объектов, для отладки доступа.
Фаза 4 (90+ дней)
Фокус: Архитектурное управление и непрерывная верификация
Результат: Регулярные , контроль качества политик в CI/CD и измеримые SLO для платформы авторизации.
Типичные антипаттерны
Делать одну роль всесильного администратора и пытаться закрыть ей все сценарии доступа.
Смешивать бизнес-атрибуты и атрибуты безопасности без владельца и без .
Строить ReBAC без : пользователи не понимают, почему доступ есть или нет.
Оставлять права после организационных изменений, ухода сотрудника или смены роли без автоматического .
Источники
Связанные главы
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - Даёт IAM-основу: не работает отдельно от и контекста доверия.
- Zero Trust: современный подход к безопасности архитектуры - Показывает, как ACL/RBAC/ABAC/ReBAC встраиваются в непрерывное и проверку каждого запроса.
- API Security Patterns - Переносит модели доступа в прикладной контур API: проверки на уровне объекта, политики токенов и .
- Secrets Management Patterns - Связана с и безопасной доставкой секретов для и контролей во время выполнения.
- Data Governance & Compliance - Дополняет тему классификацией данных, аудируемостью и требованиями комплаенса к управлению доступом.