Что такое ReBAC? Управление доступом на основе связей (Relationship-Based Access Control) с примерами

Что такое ReBAC?

Управление доступом на основе связей (ReBAC) определяет доступ на основании связей между пользователями и ресурсами: alice — владелец документа, bob — его наблюдатель, документ находится в папке, папка принадлежит команде. Правила записываются один раз для каждого типа связи, например «владельцы могут редактировать, наблюдатели могут читать», и каждый пользователь получает доступ через записанные для него связи.

Типичные вопросы, на которые отвечает ReBAC:

Является ли пользователь владельцем ресурса?
Является ли пользователь участником проекта, которому принадлежит ресурс?
Относится ли ресурс к типу, к которому у пользователя есть доступ?

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

ReBAC и Google Zanzibar

ReBAC стал широко известен благодаря статье Google о системе Zanzibar (USENIX ATC 2019), лежащей в основе обмена данными в Google Drive, Calendar и других сервисах. Zanzibar хранит связи в виде кортежей объекта, отношения и пользователя, например doc:design.md#viewer@user:bob. Открытые сервисы, такие как OpenFGA и SpiceDB, следуют тому же дизайну. В Casbin тот же факт представлен одной строкой политики, g, bob, design.md, viewer, а матчер модели определяет, что разрешает каждое отношение.

ReBAC против RBAC и ABAC

	Доступ определяется	Пример правила
RBAC	Ролью пользователя, одинаковой для всех ресурсов	редакторы могут редактировать документы
ReBAC	Связью пользователя с конкретным ресурсом	владелец документа может его редактировать
ABAC	Атрибутами пользователя, ресурса и окружения	сотрудники отдела, к которому относится документ, могут читать его в рабочее время

RBAC с ролью для каждого ресурса («alice — редактор документа doc1») уже является простой формой ReBAC, именно так Casbin моделирует это ниже. Статья Выбор модели управления доступом рассматривает один пример в каждой модели и сравнивает их бок о бок.

ReBAC в Casbin

Casbin моделирует ReBAC с помощью:

Связей пользователь–ресурс–роль: «у пользователя U есть роль R на ресурсе O» (например, alice имеет роль collaborator на doc1).
Связей ресурс–тип: «ресурс O имеет тип T» (например, doc1 имеет тип doc).

Разрешения тогда формулируются как «роль R может выполнить действие A над типом T»; пользователь получает разрешение, если у него есть роль R на ресурсе, который имеет тип T. Пример модели:

[request_definition]
r = sub, obj, act

[policy_definition]
p = role, obj_type, act

[role_definition]
g = _, _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, r.obj, p.role) && g2(r.obj, p.obj_type) && r.act == p.act

# Permission definition: The "collaborator" role can read files of type "doc"
p, collaborator, doc, read

# User-Resource-Role Relationship: alice is a collaborator of doc1
g, alice, doc1, collaborator

# Resource-Type Relationship: doc1 is of type "doc"
g2, doc1, doc

Итак: у пользователя должна быть правильная роль на ресурсе, и ресурс должен соответствовать типу в правиле разрешения. Casbin комбинирует g (пользователь–ресурс–роль), g2 (ресурс–тип) и p (роль–тип–действие) для принятия решения о доступе.

FAQ

Нужен ли мне сервис в стиле Zanzibar для использования ReBAC? Нет. Если связи помещаются в базу данных вашего приложения и проверки происходят внутри вашего сервиса, достаточно библиотеки, такой как Casbin. Выделенный сервис имеет смысл, когда многие сервисы должны разделять одно хранилище связей; см. Casbin vs. OpenFGA.

Могу ли я попробовать эту модель без написания кода? Да. Выберите пример ReBAC в онлайн-редакторе.