Правильная модель в управление доступом

Какую модель управления доступом выбрать? Читайте в этой статье, я попробую "разложить по полочкам" параметры выбора и принципы использования.

Существуют разные принципы управления доступом. Я остановлюсь только не некоторых из них: RBAC, ABAC и PBAC. Давайте для начала дадим определение каждому из упомянутых типов.

Role-Based Access Control (RBAC)

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

RBAC является примером "грубой" (низкогранулярной) авторизации. Конкретные атрибуты запроса на авторизацию, такие как время и местоположение, не могут быть учтены в среде RBAC. Необходимо определить новую роль для сотрудника, если необходимо изменить хотя бы одно разрешение, предоставленное его предыдущей роли. Кроме того, RBAC создает проблемы масштабируемости по мере добавления в структуру компании новых ролей и должностей. При использовании RBAC очень велик риска "взрывному роста ролей".

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

Attribute-based access control (ABAC)

Управление доступом на основе атрибутов, как следует из названия, опирается на определенные атрибуты запроса авторизации, а не на заранее определенную роль. Эта возможность означает, что вы можете сопоставить любую центральную политику безопасности с набором атрибутов, которые определяют, предоставляется ли доступ к конкретному ресурсу.

Примеры параметров в ABAC:

• Идентификатор пользователя/роль/отдел
• Время, местоположение и информация об устройстве
• Название, создатель и тип файла ресурса, о котором идет речь

Отходя от RBAC, ABAC обеспечивает гораздо большую гибкость с точки зрения того, кто получает доступ к какому ресурсу на предприятии, независимо от их назначения. Это также позволяет учитывать время и место подачи запроса, что позволяет при необходимости обеспечить доступ с разбивкой по району и по времени.

Использование атрибутов вместо ролей обеспечивает большую детализацию с настраиваемым набором разрешений для каждого участника предприятия, что делает ABAC тонким методом управления доступом. ИТ-персонал также может устанавливать новые атрибуты для учета диверсификации рабочей силы по мере расширения предприятия. Благодаря централизованному хранению данных облачные вычисления требуют большей детализации в управлении доступом для обеспечения безопасности.

Policy-based access control (PBAC)

Как и ABAC, управление доступом на основе политик (PBAC) использует комбинацию атрибутов для определения того, следует ли авторизовать запрос на доступ. Включенные параметры столь же всеобъемлющи, как и в ABAC.

Управление доступом на основе политик — это уже промышленный стандарт (inductrial standart), на котором наблюдается быстрый рост. Политики позволяют системе оценивать запросы в различных контекстах и в соответствии со значениями атрибутов в режиме реального времени.

ABAC полагается на то, что политики компании сопоставляются с заранее определенным списком атрибутов, которые затем рассматриваются для авторизации. В отличие от этого, PBAC полагается на набор предопределенных политик компании, записанных в коде, для определения значений каждого атрибута в допустимом запросе.

PBAC использует логику для определения того, как конкретные политики должны взаимодействовать друг с другом. Кроме того, отделение логики политики от программного кода позволяет вносить изменения в политику, не влияя на бизнес-функции приложений или ресурсов.

ABAC vs RBAC vs PBAC: Какую модель вам следует выбрать?

Надеюсь, вы поняли основные отличия, принципы и правила работы ABAC, RBAC и PBAC и как функционируют эти модели авторизации. Теперь полезно объяснить, что означают различия в каждой инфраструктуре для предприятия, стремящегося улучшить свои механизмы контроля доступа.

В таблице ниже приведены основные различия в функциональности для каждой модели:

Заключение

И всё-таки, какой же выбрать тип? Всё просто! За нас (за разработчиков) уже выбор сделан. На всех (или почти на всех) современных системых используется

Policy-based access control (PBAC). Более того, в шаблоны проектов, которые используются для создания новых проектов на ASP.NET Core (и не только) уже встроена система PBAC на базе фреймворка Microsoft Identity Framework. 

Другими словами про выбор... Хотите другую систему - ищите другой фреймворк! А если вы хотите еще больше проблем, то тогда пишите свою систему! В таком случае, количество бессонных ночей и сумашедших дней будет увеличиваться с геометрической прогрессией. Почему? Потому что запросы "бизнеса" никогда не заканчиваются, поэтому требования всегда не только меняются но и добавляются!