Методы авторизации

Авторизация - это вызов, с которым приходится сталкиваться каждому разработчику. Она играет решающую роль в обеспечении необходимого уровня доступа для пользователей и служб к соответствующим ресурсам.

Важно различать идентификацию, авторизацию и аутентификацию.

  • Идентификация — процедура однозначно определяющая сущность в информационной системе.
  • Аутентификация — процедура проверки подлинности идентификации.
  • Авторизация — процедура проверки прав доступа идентифицированной сущности к ресурсу.

При разработке приложений аутентификация определяет, кто может пользоваться этим приложением, в то время как авторизация определяет, что эти пользователи могут делать, подтвердив аутентификацию.

Процесс авторизации очень быстро усложняется. Он может начинаться с чего-то столь же простого, как “Проверьте, является ли этот пользователь администратором или нет, а затем предоставьте ему доступ в соответствии с этим”, но по мере развития приложения меняются и требования к авторизации. Например, достаточно быстро может потребоваться предоставить доступ на основе нескольких типов ролей, атрибутов (таких как: время, географическое местоположение или статус платежа), связей с определенной группой, командой, иерархией и т.п. На этом этапе начинают свою работу модели авторизации. В этой статье реализована попытка разобрать и сравнить некоторые из наиболее распространенных моделей авторизации:

Контроль доступа на основе ролей (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 могут затруднить аудит.

RBACABACReBAC
ИспользованиеПозволяет создавать политики безопасности на основе ролей пользователейПозволяет создавать детализированные политики безопасности на основе атрибутов пользователей и ресурсовПозволяет создавать политики безопасности на основе иерархий и вложенных связей
ПроизводительностьВысокаяНормальнаяНормальная
ТрудоемкостьНизкаяСредняяВысокая
ДетализацияОграниченнаяЧрезвычайно высокаяСредняя
АудитПростойСреднийСложный

Резюме

Модели авторизации - это скорее образы мышления, чем конкретные рекомендации, и, в большинстве приложениях, в конечном итоге смешивают их, особенно, с течением времени и развитием этих приложений. Самое основное - спроектировать модель авторизации с учетом гибкости и масштабируемости. При этом, важно отметить, что модель авторизации не заканчивается на этапе внедрения, а продолжает развиваться вместе с потребностями приложения.

При разработке приложений зачастую начинают с четких правил RBAC, а затем постепенно превращают их в ABAC по мере необходимости в дополнительных атрибутах. Когда вступают в силу динамические данные, такие как время, местоположение, статус выставления счета и текущее поведение, ABAC становится обоснованной необходимостью. Если же с развитием приложения появляется необходимость контролировать доступ к иерархическим структурам - политики авторизации на основе ReBAC могут использоваться в совокупности с RBAC и ABAC.

Самым конструктивным подходом при разработке приложений будет внедрять комбинированную модель авторизации, используя политики безопасности на основе RBAC, ABAC или ReBAC и управляя ими с помощью службы авторизации, которая обеспечивает гибкий переход между моделями авторизации и предоставляет простой API и/или пользовательский интерфейс.

Ссылки и дополнительная информация



Коментарии

Остались вопросы, появились идеи для обсуждения или просто хотите оставить отзыв? Буду рад любой обратной связи!

Вместо авторизации в приложении giscus , вы также можете оставлять комментарии непосредственно на GitHub, с которым связанна данная ветка комментариев.

Похожие записи

Доступ к Docker Hub

Обход блокировки досутпа к Docker Hub с помощью прокси-сервера

Комментарии в блоге с Giscus

Система комментариев на основе GitHub Discussions.