Дизайн базы данных: RBAC или ABAC?

У меня есть сервис SaaS, где несколько пользователей могут сотрудничать друг с другом. До сих пор пользователи с одной учетной записью подписки могли использовать одну и ту же базу данных и просматривать / редактировать / удалять все друг от друга.

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

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

  • просмотр клиентских карточек
  • обновление карты клиента
  • удаление карты клиента
  • добавление клиентских карт

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

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

Достаточно ли убедителен RBAC, чтобы кодировать такое требование? Или мне нужно перейти на ABAC?


user-permissions permissions rbac database-design abac
person Gianluca Ghettini    schedule 26.08.2019    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Практическое правило следующее:

  • Если у вас есть отношения в ваших требованиях к авторизации, перейдите в ABAC.

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

Но ... если вам нужно сказать что-то вроде:

  • вы можете просматривать клиентов только в вашем регионе
  • вы не можете просматривать клиента, с которым у вас есть личные (родительско-дочерние) отношения

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

Вот как будет выглядеть политика в alfa. :

policy clientAccess{
    target 
           clause action.name == "view"
           object.Type == "client record"
    apply firstApplicable
    rule managersCanViewAll{
        target clause user.role == "manager"
        permit
    }
    rule employeeCanViewSameState{
        target clause user.role == "employee"
        permit
        condition user.state == client.state
    }
}

Это заявление condition user.state == client.state - секретный соус ABAC.

Конечно, у ABAC есть и другие преимущества, такие как:

  • легче расти и развиваться
  • легче проверять
  • легче повторно использовать в приложениях и API ...

Ознакомьтесь с этими ресурсами для получения дополнительной информации:

person David Brossard    schedule 26.08.2019