Определения часто спрашивают на собесах, а я сегодня хочу рассказать про это чуть больше. Когда я работала в платформе, наша команда занималась как раз авторизацией.
Представьте, что вы пришли на собеседование в большой офис с входом по пропускам. Вы подходите к охране и говорите:
— Здравствуйте, я Маша Иванова.
Это была идентификация. Идентификация — это процесс определения, кто перед нами. Для нее может использоваться логин, email, номер телефона или другие уникальные идентификаторы.
Охранник смотрит на вас сурово и отвечает:
—
Вы протягиваете паспорт, охранник проверяет ФИО и фото, затем кивает.
Это была аутентификация. Аутентификация — это процесс проверки, что пользователь является тем, за кого себя выдает. Для этого он приводит доказательства, например, знание пароля.
Существует пять различных типов доказательств (факторов) что пользователь тот, за кого себя выдает. В веб-приложениях распространены первые три. Двухфакторная авторизация — когда используется комбинация двух факторов.
1️⃣ Что-то, что ты знаешь: пароль, пин-код, секретные вопросы
2️⃣ Что-то, что у тебя есть: SMS-код и звонок на телефон, код на email, OTP токен
3️⃣ Что-то, что ты есть (биометрия): отпечаток пальца, распознавание лица, радужная оболочка глаза
4️⃣ Где-то, где ты есть: IP-адрес, геолокация
5️⃣ Что-то, что ты делаешь: движения мыши, паттерн нажатия на клавиатуре, другие поведенческие факторы
Кстати, я только недавно узнала, что капча с галочкой "Я не робот" проверяет поведенческий паттерн: движение мыши, скорость клика, скролл.
Охранник записывает ваши данные, выдает карточку и говорит:
— На ваше имя выписан гостевой пропуск. С ним вы можете пройти на третий этаж в HR и в столовую на первом этаже. На другие этажи проход запрещен.
Это была авторизация. Авторизация — это процесс предоставления пользователю определённых прав доступа после успешной аутентификации.
Интересно, что согласно данным OWASP за 2021 год ошибки в авторизации занимают первое место среди рисков безопасности веб-приложений.
Существует куча подходов к управлению доступом, предлагаю посмотреть на самые основные.
📌 ACL (Access Control List) — это подход, в котором доступ определяется для каждого ресурса отдельно.
Например, у нас есть страница в корпоративной вики. Мы открываем настройки конкретно для этой страницы и указываем, что смотреть и оставлять комментарии могут только участники нашей команды, а редактировать может только аналитик.
ACL дает гибкий и детализированный контроль, но с ним трудно управлять правами для большого количества пользователей и объектов. Это ж для каждой страницы настраивать 😖
📌 RBAC (Role Based Access Control) — это подход, в котором доступ предоставляется на основании роли пользователя, а не настроек каждого объекта. Роль — это просто набор прав.
Например, у нас HR-система управления отпусками.
Роль "Сотрудник" содержит права: создание заявки, просмотр, редактирование, удаление.
Роль "Менеджер": просмотр, согласование заявок
Роль "HR": просмотр, утверждение заявок
Кажется, тут все просто. Но если мы реализуем только это, то сотрудники смогут редактировать чужие заявки, а менеджеры — согласовывать заявки чужих сотрудников.
‼️ Доступ должен зависеть не только от роли пользователя, но и от свойств объекта, к которому запрашивается доступ. Это называется Ownership.
В данном случае нужна дополнительная проверка, что сотрудник может управлять только своими заявками. А менеджер может согласовывать только заявки своих подчиненных.
📌 ABAC (Attribute Based Access Control) — это более гибкий подход, в котором доступ предоставляется на основе атрибутов (характеристик) самого пользователя, запрашиваемого ресурса и контекста.
Например, в HR-системе мы используем:
атрибут пользователя - его роль
атрибут заявки на отпуск - ее автор.
Добавим еще атрибут пользователя - IP-адрес и атрибут контекста - время дня. Теперь заявку на отпуск можно создать только из офиса и только в рабочее время 👍