Личность подтверждена. Доступ запрещён
Идентификация, аутентификация и авторизация звучат как три способа сказать «покажи паспорт». На деле это три разных вопроса.
Представь: ты пришёл в офис на собеседование.
- Здравствуйте, я Джейсон Стэйтем.
Это идентификация: ты назвал себя.
- Чем докажете? Паспорт есть?
Показываешь паспорт. Охранник сверяет имя и фотографию. Это аутентификация: ты подтвердил, что действительно Джейсон Стэйтем.
Охранник выдаёт пропуск и определяет, на какие этажи тебя можно пускать. Это авторизация: личность уже подтверждена, теперь система определяет, что тебе разрешено.
Можно быть Джейсоном Стэйтемом, успешно это доказать и всё равно не попасть в серверную.
Как доказать, что ты - это ты NIST выделяет три классических фактора аутентификации: Что ты знаешь: пароль, ПИН-код. Что у тебя есть: телефон, аппаратный ключ, генератор одноразовых кодов. Кто ты есть: лицо, палец, радужка глаза.
Пароль и ПИН вместе всё ещё один фактор: оба про то, что ты знаешь.
IP, геолокация, знакомое устройство и манера печатать тоже могут влиять на проверку. Но это контекстные сигналы риска, а не ещё два классических фактора. Система замечает что-то странное и просит подтвердить вход ещё раз или вовсе его блокирует.
Капча «Я не робот» стоит рядом, но решает другую задачу: пытается отличить человека от автоматизации. Кто именно этот человек, капча не знает.
Ты вошёл. Что тебе теперь можно? Здесь начинаются модели управления доступом.
ACL - Access Control List Права перечислены у конкретного объекта.
Например, у страницы в корпоративной вики: читать могут все; редактировать может аналитик; удалять может администратор, когда всё уже сгорело.
Гибко, но разросшимися списками сложно управлять. Выяснить, почему у Васи есть доступ, порой становится отдельным расследованием.
RBAC - Role-Based Access Control Права привязаны к ролям, а роли выдаются людям.
Например, в HR-системе: сотрудник создаёт и редактирует свои заявки; менеджер согласовывает заявки своей команды; HR видит всё. Почти бог, только с календарём отпусков.
Одних ролей часто мало. Нужна проверка связи с конкретным объектом: свою ли заявку редактирует сотрудник и своей ли команде менеджер согласует отпуск. Иначе Вася с ролью менеджера сможет управлять заявками Пети из соседнего отдела.
ABAC - Attribute-Based Access Control Решение зависит от атрибутов пользователя, ресурса и ситуации.
Например, менеджер может согласовать заявку на отпуск, если: сотрудник из его отдела; заявка ожидает согласования; запрос пришёл с офисного IP.
ABAC позволяет описывать тонкие правила. За это приходится платить сложностью: политику ещё надо понять, протестировать и отладить.
Почему с доступом нельзя на глазок В OWASP Top 10:2025 ошибки контроля доступа снова стоят на первом месте. Роль admin не заменяет нормальную проверку: кто обращается, к какому объекту и в каком контексте.
Короткий чеклист: не путать аутентификацию и авторизацию; не полагаться только на роли; учитывать владельца и связь пользователя с ресурсом; проверять права на сервере при каждом запросе; запрещать доступ, если разрешение явно не задано; выдавать только те права, которые нужны для работы.
А у вас что: ACL, RBAC, ABAC или Петя, который всё настраивает руками прямо на проде?
