Персональные инструменты
 

Подходы к контролю доступа: RBAC vs. ABAC

Материал из CustisWiki

Перейти к: навигация, поиск
Евгений Мяченков, наш ведущий разработчик, опубликовал в корпоративном блоге на «Хабрахабре» статью, посвященную вопросу контроля доступа в компании. Какие существуют подходы к контролю доступа? В чем заключаются достоинства и недостатки ролевого подхода? Какие преимущества по сравнению с ним предоставляет подход, основанный на атрибутах? Ответы на эти вопросы — в материале «Подходы к контролю доступа: RBAC vs. ABAC» на сайте.

Введение

Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.

RBAC Схема 1.jpg

Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.

RBAC Схема 2.jpg

Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:

  • каждый сотрудник должен выполнять только свои бизнес-задачи и не иметь доступа к чужим;
  • каждый сотрудник должен видеть только связанную со своими бизнес-задачами информацию;
  • у каждой задачи должен быть ответственный за ее выполнение сотрудник.

Если не решить эти проблемы, фирма может понести финансовые потери из-за:

  • неэффективного выполнения чужих задач в силу некомпетентности;
  • умышленных или неумышленных ошибок в чужих задачах;
  • раскрытия информации посторонним лицам.

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

RBAC Схема 3.jpg

Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).

Role-based access control (RBAC)

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

Если бизнес-правила одномерны и все действия можно разбить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.

RBAC Схема 4.jpg
RBAC Схема 5.jpg

Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит).

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

RBAC Схема 6.jpg
RBAC Схема 7.jpg

После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», придется добавить новые роли, такие как "Администратор филиала «Г», "Менеджер филиала «Г», "Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.

Кроме этого, появляются и другие проблемы:

  • одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку;
  • начинается взрывной рост числа ролей, что значительно усложняет управление ими.

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

RBAC Схема 8.jpg

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

RBAC Схема 9.jpg

Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа.

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

Attribute-based access control (ABAC)

Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах.

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

Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.

Можно явно выделить несколько категорий атрибутов.

RBAC Схема 10.jpg

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

Простые правила описываются простыми условиями.

RBAC Схема 11.jpg

Многомерные правила в этой модели не становятся более сложными.

RBAC Схема 12.jpg

При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».

Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC:

  • бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми;
  • не происходит взрывного роста числа условий, что упрощает их сопровождение.

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

Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.

RBAC Схема 13.jpg

Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных.

RBAC Схема 14.jpg

Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.

Сравнение ABAC и RBAC

RBAC Схема 15.jpg

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

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

Полезные ссылки



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