В этой теме я хотел бы познакомить читателей с относительно новым подходом к контролю доступа, который называется Управление доступом на основе атрибутов .
Знакомство будет проходить на примере сравнения с популярным на данный момент. Управление доступом на основе ролей .
Когда компания состоит из одного человека, внутренних тайн нет. Единственный сотрудник имеет доступ к любым действиям и любой информации.
Если компания успешна и объёмы работ растут, то наступает момент, когда один человек уже не справляется.
И тогда в компанию нанимаются новые сотрудники.
Но когда количество сотрудников в компании увеличивается, появляются другие проблемы, например:
- каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к другим;
- каждый сотрудник должен видеть только информацию, связанную с его бизнес-задачами;
- У каждой задачи должен быть сотрудник, ответственный за ее выполнение.
- неэффективное выполнение чужих задач из-за некомпетентности;
- намеренные или непреднамеренные ошибки в чужих задачах;
- раскрытие информации третьим лицам.
Самая сложная проблема – авторизация.
Существует несколько подходов к ее решению, но наиболее распространённым на сегодняшний день является управление доступом на основе ролей (RBAC).
Управление доступом на основе ролей (RBAC)
Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и назначении их пользователям.На основе этих ролей проверяется возможность пользователя выполнить то или иное действие.
Если бизнес-правила одномерны и все действия можно разделить на роли (бухгалтер, менеджер, администратор и т. д.), такого подхода будет достаточно.
Тогда одной роли будет соответствовать одно бизнес-правило.
Но бизнес-правила неизбежно становятся более сложными и многомерными.
Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит и т. д.).
Чтобы справиться с этой сложностью, необходимо создать дополнительные роли, количество которых равно количеству различных комбинаций всех атрибутов.
Каждый раз, когда вы добавляете новое значение атрибута, вам придется добавлять новые роли.
То есть, если появится филиал «Г», то вам придется добавлять новые роли, такие как «Администратор филиала «Г», «Руководитель филиала «Г», «Бухгалтер филиала «Г» и т. д., а затем назначать новых сотрудников на все необходимые роли.
Все это создает много рутинного ручного труда.
Кроме того, возникают и другие проблемы:
- одно бизнес-правило «размазывается» по многим ролям и становится неочевидным, что усложняет понимание такого правила и его поддержку;
- Число ролей начинает стремительно расти, что значительно усложняет управление ими.
Также существуют бизнес-правила, ограничивающие доступ не к действиям, а к данным.
Такие бизнес-правила также нельзя выразить с помощью ролевой модели.
Для реализации поддержки таких бизнес-правил придется использовать другие инструменты, что только увеличивает стоимость и сложность внедрения и обслуживания системы контроля доступа.
Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые.
Управление доступом на основе атрибутов (ABAC)
Для решения проблем, которые не может решить RBAC, был создан другой подход, основанный на атрибутах.Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет выполнить, а с точки зрения атрибутов, которые к ним относятся.
Бизнес-правило — это, по сути, набор условий, при которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.
Можно явно выделить несколько категорий атрибутов.
Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями.
Выполнение всех условий обеспечивает доступ к ресурсу.
Простые правила описываются простыми условиями.
Многомерные правила в этой модели не становятся более сложными.
При добавлении новых значений атрибута условия бизнес-правила не изменятся.
То есть, если появится ветка «Г», ничего менять в условиях бизнес-правила не придется.
Все, что требуется – это добавить к необходимым сотрудникам значение атрибута «Филиал» – «Филиал «Г».
Таким образом, ABAC позволяет избежать проблем, возникающих в RBAC:
- бизнес-правило не «размазано» по всей системе, что делает его понимание и поддержку достаточно простыми;
- отсутствует взрывной рост числа состояний, что упрощает их обслуживание.
Бизнес-правила любой сложности, в том числе использующие ранее неизвестные атрибуты, не создают новых проблем и просты в сопровождении.
Представление бизнес-правила в виде набора условий удобно для фильтрации данных.
Некоторые условия можно рассчитать до обращения к ресурсу, а остальные условия становятся фильтром отбора данных.
Первые три условия можно проверить перед доступом к данным.
И последнее условие можно использовать как предикат для получения только разрешенных данных.
Сравнение ABAC и RBAC
Как видно из сравнения, RBAC хорош только для реализации простых бизнес-правил.
По мере увеличения сложности правил обоснованность использования RBAC уменьшается из-за увеличения стоимости обслуживания системы контроля доступа, а за пределами определенного уровня сложности правил этот подход вообще не работает. ABAC, в свою очередь, не ограничивает сложность бизнес-правил.
Благодаря более понятному бизнесу и компактному языку такой подход позволяет избежать увеличения затрат на поддержку при реализации более сложных правил, а также позволяет обеспечить контроль доступа не только к действиям, но и к данным.
P.S.: На сегодняшний день существует стандарт XACML для ABAC, который активно развивается и используется.
Более подробную информацию о нем можно найти в следующий статья.
Интересные и полезные ссылки про ABAC, XACML и их использование:
- Представляем XACML, стандарт управления доступом на основе атрибутов
- АБАК;
- стандарт XACML;
- Руководство по ABAC от NIST;
- реализация XACML от Axiomatics;
- WSO2 и XACML;
- Oracle WebLogic и XACML;
- IBM Tivoli Security Policy Manager и XACML;
- Cisco Enterprise Policy Manager и XACML;
- Боинг и XACML;
- PayPal и Аксиоматика;
- Информационный ресурс;
- От грустный пузырь : JSON-профиль XACML 3.0.
-
Введение В Интернет
19 Oct, 24 -
Новый Российский Ноутбук. А Вдруг…
19 Oct, 24 -
3 Простых Способа Увеличить Продажи B2B
19 Oct, 24
