Модель контроля доступа выбирают не по тому, какая аббревиатура звучит современнее, а по тому, как реально устроены роли, ресурсы, контекст и связи в продукте.
Глава сравнивает 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
Когда подходит: Домены с требованиями комплаенса — финансы, медицина, госсервисы, — где решение зависит от контекста и классификации данных.
Где начинает болеть: Команды без управления атрибутами и без тестируемого : атрибуты протухают тихо, а доступ ломается громко.
Граница: Цена входа — строгий словарь атрибутов, аудит изменений политики и , иначе «почему дали доступ» останется без ответа.
ReBAC (Zanzibar)
Когда подходит: Коллаборативные продукты — документы, репозитории, рабочие пространства — где доступ естественно описывается графом связей.
Где начинает болеть: Малые системы, где граф отношений не окупает инфраструктурную сложность отдельного сервиса.
Граница: Оправдан, когда много и нужен консистентный глобальный , — иначе вы платите за инфраструктуру больше, чем экономите.
В 2026 типичный промышленный подход: как каркас, как контекстные условия, для общих объектов, как локальное переопределение на ресурсе.
Контроли жизненного цикла политик доступа
| Этап | Обязательные контроли | Действие при провале |
|---|---|---|
| Проектирование политики | Единый словарь ресурсов и действий, владелец на каждую , с ревью кода. | Блокировать слияние политики без владельца и тестов, вернуть изменение в бэклог команды. |
| Доставка и версионирование | Версионирование , , подпись артефактов и проверка целостности в среде выполнения. | Остановить внедрение и автоматически откатить систему на последнюю стабильную . |
| Путь принятия решения | на критичных эндпоинтах, и проверки на уровне объекта для чувствительных операций. | Отключить рискованную операцию и поднять срочное оповещение для инженера. |
| Ревью и повторное подтверждение | Плановые , и контроль после организационных изменений. | Автоматически пометить доступ как временный и инициировать до подтверждения владельцем. |
| Экстренный отзыв доступа | Единый процесс , массовый отзыв токенов и связей, проверка последствий по . | Перевести систему в ограниченный режим и принудительно завершить активные сессии высокого риска. |
Операционные метрики авторизации
95-й перцентиль (P95) задержки авторизационной проверки
Цель: <= 20 ms
Если проверки дорогие, команды начинают обходить слой политики и теряют консистентность .
Доля решений с трассой объяснения
Цель: >= 99%
Без неё разбор инцидента упирается в догадки: на вопрос «почему доступ выдан или отклонён» нечем ответить.
Среднее время восстановления (MTTR) при откате изменения политики
Цель: < 10 минут
Быстрый критичен, когда новая политика ломает промышленные потоки или легитимный доступ.
Просроченные доступы после отключения учётной записи
Цель: 0
Показывает зрелость и снижает риск несанкционированного доступа бывших пользователей.
Покрытие проверок на уровне объекта для API высокого риска
Цель: 100%
Без проверки «а этот объект вообще твой» остаётся брешь BOLA/IDOR — пользователь входит как надо, аутентификация (AuthN) корректна, а читает чужие данные по подменённому идентификатору.
План внедрения модели доступа
Фаза 1 (0-30 дней)
Фокус: Инвентаризация прав и критичных ресурсов
Результат: Карта субъектов, ролей, ресурсов и текущих исключений с назначенными владельцами.
Фаза 2 (30-60 дней)
Фокус: Каркас ролевой модели доступа (RBAC) и запрет по умолчанию
Результат: Единый , централизованный и базовые журналы аудита решений.
Фаза 3 (60-90 дней)
Фокус: Контекстные правила и граф отношений
Результат: -предикаты для риска и контекста, для общих объектов, для отладки доступа.
Фаза 4 (90+ дней)
Фокус: Архитектурное управление и непрерывная верификация
Результат: Регулярные , контроль качества политик в CI/CD и измеримые для платформы авторизации.
Типичные антипаттерны
Свести всё к одной всесильной роли администратора — она закрывает любой сценарий, но вместе с этим становится единой точкой компрометации.
Смешивать бизнес-атрибуты и атрибуты безопасности без владельца и : правка в одной системе тихо меняет права в другой.
Строить без — когда ни пользователь, ни поддержка не могут сказать, почему доступ есть или нет.
Оставлять права после реорганизации, ухода сотрудника или смены роли без автоматического — так копятся осиротевшие доступы, которыми пользуются уже бывшие люди.
Источники
Связанные главы
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - Даёт IAM-основу: не работает отдельно от и контекста доверия.
- Zero Trust: современный подход к архитектуре нулевого доверия - Показывает, как /// встраиваются в непрерывное и проверку каждого запроса.
- API Security Patterns - Переносит модели доступа в прикладной контур API: проверки на уровне объекта, политики токенов и .
- Secrets Management Patterns - Связана с и безопасной доставкой секретов для и контролей во время выполнения.
- Data Governance & Compliance - Показывает, откуда берётся классификация данных и требования комплаенса, на которые опираются предикаты доступа и аудит решений.