Методы авторизации
Авторизация - это вызов, с которым приходится сталкиваться каждому разработчику. Она играет решающую роль в обеспечении необходимого уровня доступа для пользователей и служб к соответствующим ресурсам.
Важно различать идентификацию, авторизацию и аутентификацию.
- Идентификация — процедура однозначно определяющая сущность в информационной системе.
- Аутентификация — процедура проверки подлинности идентификации.
- Авторизация — процедура проверки прав доступа идентифицированной сущности к ресурсу.
При разработке приложений аутентификация определяет, кто может пользоваться этим приложением, в то время как авторизация определяет, что эти пользователи могут делать, подтвердив аутентификацию.
Процесс авторизации очень быстро усложняется. Он может начинаться с чего-то столь же простого, как “Проверьте, является ли этот пользователь администратором или нет, а затем предоставьте ему доступ в соответствии с этим”, но по мере развития приложения меняются и требования к авторизации. Например, достаточно быстро может потребоваться предоставить доступ на основе нескольких типов ролей, атрибутов (таких как: время, географическое местоположение или статус платежа), связей с определенной группой, командой, иерархией и т.п. На этом этапе начинают свою работу модели авторизации. В этой статье реализована попытка разобрать и сравнить некоторые из наиболее распространенных моделей авторизации:
- Контроль доступа на основе ролей (Role Based Access Control, RBAC)
- Контроль доступа на основе атрибутов (Attribute-Based Access Control, ABAC)
- Контроль доступа на основе связей (ReBAC)
Контроль доступа на основе ролей (RBAC)
Авторизация методом “контроля доступа на основе ролей” (RBAC
) использует предопределенные роли, назначенные пользователям, для определения их прав доступа. Простой и элегантный, RBAC
уже много лет является наиболее предпочтительным решением для многих разработчиков приложений.
В RBAC
пользователям назначаются роли, такие как “Администратор” или “Редактор”, причем каждая роль связана с определенными разрешениями.
Метод RBAC
на простом языке выглядит следующим образом:
Сотрудники могут просматривать и редактировать документы, в то время как администраторы могут просматривать, редактировать, создавать и удалять их.
Плюсы:
Доступность: RBAC
предоставляет решение, которое является простым и знакомым как разработчикам, так и конечным пользователям.
Использование: Предопределенные роли, установленные RBAC
, могут коррелировать с такими аспектами, как должностные функции или обязанности человека. Это позволяет администраторам управлять разрешениями на высоком уровне, а не для каждого отдельного пользователя.
Масштабируемость: RBAC
позволяет довольно легко масштабировать процедуру авторизации по мере развития приложения.
Производительность: RBAC
, как правило, обладает более высокими производительными возможностями по сравнению с другими методами авторизации, благодаря своей простоте.
Минусы:
Детализация: RBAC
подвержен "ролевому взрыву" в более сложных приложениях - ситуации, в которой для обеспечения детализации создается множество ролей, что чрезвычайно затрудняет их управление и аудит.
Гибкость: Поскольку доступ пользователей определяется исключительно ролями, а не конкретными атрибутами, RBAC
может быстро стать недостаточной при появлении новых, более детализированных требований к контролю доступа.
Контроль доступа на основе атрибутов (ABAC)
Авторизация методом “контроля доступа на на основе атрибутов” (ABAC
) использует атрибуты – аспекты пользователей, ресурсов, действий и условий среды выполнения – для определения доступа. Бесконечно универсальный, самый детализированный и надежный метод контроля доступа из рассматриваемых.
ABAC
расширяет базовые роли RBAC
, добавляя в набор атрибуты, что позволяет создавать гораздо более детализированные политики авторизации.
Метод ABAC
на простом языке выглядит следующим образом:
Сотрудники, находящиеся в России, могут редактировать документы, с грифом “Особая важность”.
В этом примере:
- Сотрудник - это роль
- Местоположение сотрудника в России - это атрибут пользователя
- Редактировать - это действие
- Документ - это ресурс
- Гриф “Особая важность” - это атрибут ресурса
Использование атрибутов ABAC
позволяет создавать детализированные политики авторизации. Обычно атрибуты включают (но не ограничиваются ими): время, местоположение, статус и многое другое - все зависит от конкретных потребностей приложения.
Плюсы:
Детализация: ABAC
предоставляет возможность создавать чрезвычайно детализированные политики авторизации с использованием атрибутов.
Динамичность: Очень часто приложения управляют ресурсами в режиме реального времени. При реализации с использованием методов ABAC
можно обеспечить динамический контроль доступа, основанный на изменениях атрибутов пользователя и/или ресурса в режиме реального времени.
Минусы:
Трудоемкость: Внедрение, управление и поддержка ABAC
может оказаться огромной проблемой. Это может быть очень сложным и трудозатратным процессом не только на этапе проектирования, но и на этапе постоянной эксплуатации.
Производительность: Поскольку ABAC
потенциально требует учета очень большого количества атрибутов, он может быть очень ресурсоемким, требуя больше вычислительной мощности и времени.
Контроль доступа на основе связей (ReBAC)
Авторизация методом “контроля доступа на основе связей” (ReBAC
) опирается на связи (отношения) между объектами для принятия решений о доступе, что делает его наиболее подходящим для работы с иерархическими структурами.
ReBAC
позволяет создавать политики авторизации на основе существующих взаимосвязей на уровне приложения.
Простыми словами метод ReBAC
выглядит следующим образом:
Пользователь, являющийся владельцем папки, также получит доступ владельца ко всем файлам в этой папке.
Авторизация методом ReBAC
избавляет нас от необходимости создавать политики авторизации для каждого экземпляра.
Плюсы:
Обработка сложных иерархий: ReBAC предназначен для контроля доступа для иерархических структур и вложенных связей.
Обратные индексы: графовая структура ReBAC допускает обратные запросы на авторизацию.
Комплексность: Использование ReBAC позволяет массово определять разрешения вместо того, чтобы делать это индивидуально для каждого отдельного ресурса с помощью ролей или атрибутов.
Минусы:
Трудоемкость: Внедрение, управление и сопровождение ReBAC может быть сложным и отнимать много времени.
Производительность: при рекурсивном характере связей может быть ресурсоемким
Аудит: Сложность и рекурсивный характер политик ReBAC могут затруднить аудит.
RBAC | ABAC | ReBAC | |
---|---|---|---|
Использование | Позволяет создавать политики безопасности на основе ролей пользователей | Позволяет создавать детализированные политики безопасности на основе атрибутов пользователей и ресурсов | Позволяет создавать политики безопасности на основе иерархий и вложенных связей |
Производительность | Высокая | Нормальная | Нормальная |
Трудоемкость | Низкая | Средняя | Высокая |
Детализация | Ограниченная | Чрезвычайно высокая | Средняя |
Аудит | Простой | Средний | Сложный |
Резюме
Модели авторизации - это скорее образы мышления, чем конкретные рекомендации, и, в большинстве приложениях, в конечном итоге смешивают их, особенно, с течением времени и развитием этих приложений. Самое основное - спроектировать модель авторизации с учетом гибкости и масштабируемости. При этом, важно отметить, что модель авторизации не заканчивается на этапе внедрения, а продолжает развиваться вместе с потребностями приложения.
При разработке приложений зачастую начинают с четких правил RBAC
, а затем постепенно превращают их в ABAC
по мере необходимости в дополнительных атрибутах. Когда вступают в силу динамические данные, такие как время, местоположение, статус выставления счета и текущее поведение, ABAC
становится обоснованной необходимостью. Если же с развитием приложения появляется необходимость контролировать доступ к иерархическим структурам - политики авторизации на основе ReBAC
могут использоваться в совокупности с RBAC
и ABAC
.
Самым конструктивным подходом при разработке приложений будет внедрять комбинированную модель авторизации, используя политики безопасности на основе RBAC
, ABAC
или ReBAC
и управляя ими с помощью службы авторизации, которая обеспечивает гибкий переход между моделями авторизации и предоставляет простой API и/или пользовательский интерфейс.
Ссылки и дополнительная информация
Коментарии
Остались вопросы, появились идеи для обсуждения или просто хотите оставить отзыв? Буду рад любой обратной связи!
Вместо авторизации в приложении giscus , вы также можете оставлять комментарии непосредственно на GitHub, с которым связанна данная ветка комментариев.
Похожие записи
Доступ к Docker Hub
Обход блокировки досутпа к Docker Hub с помощью прокси-сервера
Комментарии в блоге с Giscus
Система комментариев на основе GitHub Discussions.