В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.
Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.
Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.
Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:
- каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к чужим;
- каждый сотрудник должен видеть только связанную со своими бизнес-задачами информацию;
- у каждой задачи должен быть ответственный за ее выполнение сотрудник.
Если не решить эти проблемы, фирма может понести финансовые потери из-за:
- неэффективного выполнения чужих задач в силу некомпетентности;
- умышленных или неумышленных ошибок в чужих задачах;
- раскрытия информации посторонним лицам.
Чтобы решить эти проблемы и правильно разграничить доступ, нужно понимать, кто из сотрудников хочет выполнить действие (аутентификация) и может ли он это сделать (авторизация).
Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).
Role-based access control (RBAC)
Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.
Если бизнес-правила одномерны и все действия можно разбить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.
Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит и т. п.).
Чтобы справиться с этой сложностью, необходимо создавать дополнительные роли, число которых равно числу различных комбинаций всех атрибутов.
После каждого добавления нового значения атрибута придется добавлять новые роли. То есть если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.
Кроме этого, появляются и другие проблемы:
- одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку;
- начинается взрывной рост числа ролей, что значительно усложняет управление ими.
А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели.
Существуют также бизнес-правила, которые ограничивают доступ не к действиям, а к данным. Такие бизнес-правила также невозможно выразить с помощью ролевой модели.
Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа.
Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые.
Attribute-based access control (ABAC)
Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах.
Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся.
Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.
Можно явно выделить несколько категорий атрибутов.
Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.
Простые правила описываются простыми условиями.
Многомерные правила в этой модели не становятся более сложными.
При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».
Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC:
- бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми;
- не происходит взрывного роста числа условий, что упрощает их сопровождение.
Но самое главное, ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил.
Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.
Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных.
Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.
Сравнение ABAC и RBAC
Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата.
ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным.
P.S.: На сегодняшний день для ABAC существует стандарт XACML, который активно развивается и используется. Мы постараемся поподробнее разобрать его в следующей публикации.
Интересные и полезные ссылки про ABAC, XACML и их использование:
ABAC
Стандарт XACML
Guide to ABAC от NIST
Реализация XACML от Axiomatics
WSO2 и XACML
Oracle WebLogic и XACML
IBM Tivoli Security Policy Manager и XACML
Cisco Enterprise Policy Manager и XACML
Boeing и XACML
PayPal и Axiomatics
Информационный ресурс
Автор: ApInvent
