Методы авторизации
Авторизация - это вызов, с которым приходится сталкиваться каждому разработчику. Она играет решающую роль в обеспечении необходимого уровня доступа для пользователей и служб к соответствующим ресурсам.
Важно различать идентификацию, авторизацию и аутентификацию.
- Идентификация — процедура однозначно определяющая сущность в информационной системе.
- Аутентификация — процедура проверки подлинности идентификации.
- Авторизация — процедура проверки прав доступа идентифицированной сущности к ресурсу.
При разработке приложений аутентификация определяет, кто может пользоваться этим приложением, в то время как авторизация определяет, что эти пользователи могут делать, подтвердив аутентификацию.
Процесс авторизации очень быстро усложняется. Он может начинаться с чего-то столь же простого, как “Проверьте, является ли этот пользователь администратором или нет, а затем предоставьте ему доступ в соответствии с этим”, но по мере развития приложения меняются и требования к авторизации. Например, достаточно быстро может потребоваться предоставить доступ на основе нескольких типов ролей, атрибутов (таких как: время, географическое местоположение или статус платежа), связей с определенной группой, командой, иерархией и т.п. На этом этапе начинают свою работу модели авторизации. В этой статье реализована попытка разобрать и сравнить некоторые из наиболее распространенных моделей авторизации:
- Контроль доступа на основе ролей (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.