Права доступа: RBAC, ABAC или велосипед

Мы приступаем ко второму блоку платформы Бипиум — правовой политике доступа. Это еще одна особенность, которая отличает Бипиум от других систем на рынке. В этой статье мы просим помощи и совета как создать идеальную систему с точки зрения реальных задач.

Для начала небольшой экскурс в тему:

Виды политик доступа

Ролевая политика (RBAC)

В большинстве систем, в которых есть регламентирование прав доступа, политика разграничения построена на базе ролей (групп). Например, настраивать систему могут администраторы, доступ к клиентам — у отдела продаж. Система на базе ролей называется RBAC (Role-based access control).

Эта система удобна и проста, но в больших компаниях превращается в настоящий ад. Допустим у нас есть роли Руководитель, Бухгалтер, Менеджер. Чтобы решить задачу «Менеджеры видят клиентов из своего города» придется создать множество фиктивных ролей: Менеджеры Москвы, Менеджеры Питера, Менеджеры Казани и так далее. Хуже того, число ролей растет многократно при добавлении еще одной характеристики. Управлять этим становится невозможно.

Ролевая политика с командами

Ребята в Сахаре реализовали политику доступа в 2-х измерениях: роли для разграничения прав действий (видеть, изменять), и «команды» (Teams) для разграничения доступа к объектам. Команды представлены в виде дерева. Члены команды видят объекты, доступные команде и объекты команд, которые входят в неё на всех уровнях дерева. Система сложнее ролевой, зато позволяет не раздувать число ролей, но команды при этом не дают гибкого разграничения доступа к данным.

Атрибутная политика (АВАС)

Например, что делать если задача сформулирована так: «Младшие менеджеры видят заказы своего филиала, если сумма заказа менее 100 000 руб»?

Существует альтернатива ролевой политике — политика на основе атрибутов ABAC (Attribute-based access control). Атрибутом может выступать любое свойство (поле) объекта данных или сотрудника. Например, «сумма заказа > 100 000 рублей» или «город клиента = городу сотрудника». Классно!

Именно эту модель политики доступа мы и планируем внедрить в Бипиум. Но у нас есть вопросы, и мы не готовы принять решение без вашего мнения.

Политика прав доступа Бипиум

Правила

Есть данные — объекты, сотрудники — субъекты, действия над данными — привилегии.
Данные описываются свойставами — атрибутами.
Правило связывает эти сущности между собой:
Кто (субъект) → Что может (привилегия) → С чем (объекты) → Какими именно (атрибуты).

Примеры:Михаил может видеть Клиентов со статусом Лид
Топ-менеджеры могут видеть Заказы на Сумму более 100 000 рублей

Объекты

В Бипиуме нет клиентов, заказов и обращений. Бипиум это конструктор, структура конфигурируемой системы произвольна. Платформа оперирует тремя основными типами объектов: разделы, каталоги и записи. Экземпляры эти типов и являются объектами правовой политики.

Примеры:
Право видеть Раздел 2 (например это «Продажи»)
Право видеть Каталог 5 (например это «Заказы»)
Право редактировать Запись 17 в Каталоге 5 (доступ до Заказа от «Газпрома»).

Эти объекты в Бипиуме подчинены иерархии вложенности: Раздел ← Каталоги ← Записи.

Атрибуты

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

Примеры:
Клиенты со статусом «Лид»
Обращения, созданные «В этом месяце»
Заказы, где ответственный сотрудник «Я»

Набор заданных фильтров каталога можно сохранить как шаблон — Вид. Вид это четвертый тип объектов правовой политики. Его особенность заключается в том, что Запись может попадать в несколько Видов одновременно.
Иерархия увеличивается: Раздел ← Каталоги ← (Виды) ← Записи.

Субъекты

Субъекты правовой политики — это сущности, на которых назначаются права. Самый очевидный субъект это Сотрудник компании. Когда сотрудников много, их удобно группировать. Во многих системах для этого есть Роли. Но ведь Бипиум это конструктор, в нем нет Ролей. Зато их можно создать, если нужны. А заодно и отделы, филиалы, команды, должности и все что угодно. Вы можете создать каталоги, которые описывают иерархию в вашей компании и включить соответсвующие поля в карточку сотрудника. Любой каталог, который связан с Сотрудниками становится субъектом правовой политики. То есть субъектом может быть Отдел, Роль, Должность, Филиал, Кабинет, Навык и так далее.

Привилегии

Привилегии — уровень доступа субъекта к объекту. Например: видеть, изменять, создавать, удалять или администрировать. Привилегии бывают атомарные (когда каждая привилегия не зависит от других) и включающие друг друга. Например, привилегия «редактировать» включает привилегию «видеть» и так далее. Для упрощения работы с правовой политикой Бипиума мы решили сделать включающие привилегии.

Выглядят они так:
Видеть < Изменять < Создавать новые < Администрировать < Запрет доступа
О «Запрете доступа» чуть позже.

Политики

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

Бывает так, что для одного пользователя подходит сразу несколько правил. Например для Михаила (который входит в отдел «Продажники») есть правило, разрешающее ему видеть Заказы, при этом есть другое правило для Продажников, разрешающее им изменять Заказы. Какое из правил должно действовать? Бывает, что нет ни одного подходящего правила. Что делать в этом случае?

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

— разрешить доступ
— запретить доступ
— не определено
— не применимо

Если подходящих правил нет, то результат комбинации будет «Не определено». Если правил несколько, то используется один из алгоритмов комбинации. Например, «Разрешено все, что разрешено» говорит, что если существует хоть одно правило, разрешающее доступ, то доступ будет дан, если правил нет (не определенное значение) — то доступ будет закрыт. Или «Разрешено все, что не запрещено». В этом случае по умолчанию все имеют доступ до всего, но если есть хоть одно правило ограничивающее доступ, то доступ будет закрыт.

В Бипиуме мы планируем сделать алгоритм «Разрешено все, что разрешено и не запрещено». Это предполагает, что по умолчанию никто не имеет доступа до данных, до тех пор пока им не разрешили. Но даже если разрешили, то могут быть правила, которые заблокируют им доступ до данных. Например, всем Продажникам можно видеть всех Клиентов, но Стажерам нельзя видеть клиентов со статусом «Вип». Сотрудник может быть и Продажником и Стажером, и в этом случае он не увидит вип-клиентов. Именно по этому привилегия «Запрет доступа» в нашей цепочке привилегий является самой высокой.

Вопросы к читателям

Вопрос №1

Введение привилегии «Запрет доступа» серьезно усложняет понимание работы системы прав. Мы не уверены, что эта возможность целесообразна в Бипиуме. Предлагаем обсудить это в комментариях.
Вопрос: Нужна ли привилегия «Запрет»?

Вопрос №2.1.

Следующие вопросы появляются при наличии привилегии «Запрета» и связан с иерархией объектов. Напомним иерархию: Раздел ← Каталоги ← (Виды) ← Записи.

Рассмотрим на примере: Михаил входит в группу «Продажники». Продажникам дали доступ до каталога Клиенты, но Михаилу поставили запрет на клиента «Газпром». Легенда: Каталоги (доступ есть) ← Запись (доступа нет).
Вопрос: У Михаила есть доступ до клиента «Газпром»?

Вопрос №2.2

А если наоборот: Продажникам можно видеть Клиентов, но Михаилу закрыли доступ на весь раздел «Продажи». Легенда: Раздел (доступа нет) ← Каталог (доступ есть).
Вопрос: У Михаила есть доступ к клиентам?

Вопрос №2.3.

Ситуация сложнее: Продажники могут видеть Клиентов, и Михаилу также как и в прошлом примере закрыли доступ на весь раздел «Продажи». Но при этом дали доступ на клиента «Газпром». Легенда: Раздел (доступа нет) ← Каталог (доступ есть) ← Запись (доступ есть).
Вопрос: У Михаила есть доступ к клиенту «Газпром»?

Вопрос №2.4

Ситуация с правами по атрибутам: Продажники могут видеть всех Клиентов, но Михаилу закрыли доступ на вид «Вип-клиенты». При этом дали доступ на вип-клиента «Газпром».
Легенда: Каталог (доступ есть) ← Вид (доступа нет) ← Запись (доступ есть).
Вопрос: У Михаила есть доступ к вип-клиенту «Газпром»?

Вопрос №3.

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

Мы выбрали 4 варианта алгоритмов, которые основаны на разном приоритете правил в зависимости от типа объектов и уровня доступа: разрешено/запрещено. Приведенные ниже схемы описывают правила. Правила бывают на раздел (Р), каталог (К), вид (В) и запись (З). Для каждого типа объектов правила бывают как разрешающие (зеленые) и запрещающие (красные). Знак меньше (<) означает, что левое правило слабее правого, а знак равно (=) говорит что правила равны по силе.

Алгоритмы:

1) Без запрещающих правил

2) Все запрещающие правила сильнее всех разрешающих

3) Разрешение более точечного объекта доминирует над запретом более общего объекта

4) Похож на 2-й. Запреты сильнее разрешений, с исключением. Разрешение на определенную Запись сильнее запрета на Вид.

Вопрос. Какой из алгоритмов комбинации правил лучше?

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

Идеальный комментарий выглядит так:
1. Да/нет. Потому что...
2.1. Да/нет. Потому что...
2.2. Да/нет. Потому что...
2.3. Да/нет. Потому что...
2.4. Да/нет. Потому что...
3. 1/2/3/4. Потому что...

Поделиться
Отправить
2015  
9 комментариев
SerjScobov

Не стыдно такое сырое чудо презентовать? Ребят посмотрите на рынок СРМ и дайте себе ответ.

Виктор Никитин

Вы правы, рынок СРМ завален различными решениями. Каждый продукт навязывает свое видение мира. Но за 10 лет работы на рынке мы не нашли решение, способное подстроиться под компанию в полной мере. Бипиум строиться на идеологии гибкости. Публикация продукта на текущем этапе развития поможет сделать его ближе к потребностям реального бизнеса.

Подскажите, в каком продукте вы встречали модель прав доступа столь гибкую как в Бипиуму?

Сергей

Podio

Виктор Никитин

Podio отличный продукт для небольших компаний. За основу информационной системы мы взяли их идею. Но Бипиум рассчитан и на более взрослые компании. В Подио слабое разграничение доступа к данным — только на уровне разделов, в Бипиуме права можно задавать на любые данные. Отдельная фишка — правовые виды, мы их выпускаем в понедельник и им будет посвящена отдельная статья. Помимо этого Бипиум получит графические сценарии, конструктор отчетов, интеграцию с любыми системами телефонии и многое другое. Роадмап уже расписан на ближайшие 2 года.

Сергей
  1. Да. Потому что часто будет требоваться запретить что-то конкретному человеку или группе не разбираясь в хитросплетениях вышестоящих разрешений.
    2.1. Нет. Потому что запрет на элемент сильнее доступа к каталогу.
    2.2. Нет. Потому что запрет на раздел сильнее разрешения на каталог. Если есть желание, чтобы сотрудник видел только один каталог в разделе, надо запретить ему просмотр других каталогов.
    2.3. Да. Здесь нужно сделать, как в Podio. Разрешение на просмотр конкретного элемента сильнее, чем все запреты. По сути я публикую конкретную запись для пользователя. Вообще, мне кажется, это ещё одна привилегия «Делиться записью» (т. е. давать права на её просмотр любому пользователю), которая располагается между «Создавать новые» и «Администрировать»
    2.4. Да. По тем же причинам, что и в п.2.3.
  2. 3. Потому что это удобно. Настроив общие разрешающие правила для большой группы сотрудников, можно в подгруппах или у конкретных специалистов запрещать точечно доступ к подразделам или конкретным элементам при этом не меняя общих прав.
Виктор Никитин

Сергей, спасибо за вдумчивое участие и ответы!

Мы активно обсуждали эти вопросы с партнерами вне этого блога и готовы в понедельник выпустить права в свет. При проектировании решения, мы придерживались следующих ответов на наши вопросы:

  1. Да
    2.1. Нет
    2.2. Нет
    2.3. Нет
    2.4. Нет
  2. 2-й алгоритм

Поясню позицию:
Мы побоялись путаницы с иерархией объектов и пошли по пути «любой запрет сильнее разрешения». При этом на каждый объект могут быть 3 состояния:
1) не определено — доступ будет дан до индивидуально разрешенных вложенных объектов
2) разрешен — доступ будет дан с указанной привилегий до объекта и вложенных в него
3) доступ закрыт — доступ будет закрыт

Таким образом можно дать права на конкретные записи каталога, не давая прав на весь каталог — сотрудник будет видеть только разрешенные записи. Если требуется быстро скрыть все разрешенные записи, то достаточно повесить «Доступ закрыт» на весь каталог, не снимая права с каждой записи. Особенно удобно, если решение временное.

Запрет доступа по видам дает еще более интересные возможности. О видах расскажем через неделю.

Сергей М

В Podio вообще с правами проблема. Их там практически нет. Отсутствие сложных прав стало причиной отказа от системы Podio

Сергей

Мы решили эту проблему, путем использования рабочего пространства с коммерческими реквизитами. Но шли к этому решению полтора года.
Если этот недостаток будет устранен в bpium, при этом все плюшки подио будут хотя бы не хуже (а к ним я отношу скорость и стабильность работы, супер коммуникации, различные виды по работе с данными приложений, настройка рабочих процессов и возможность их запуска по e-mail, отчеты и виджеты, задания связанные со всем чем угодно, поиск по любому словечку даже в названии файла), я поклонюсь в ноги разработчикам и перейду на отечественный продукт =)

Сергей

У всех подходов есть плюсы и минусы. Выбранный вами — устроит большинство и меня в том числе. Удачи в реализации!

Популярное