Модель управления доступом на основе отношений

Термин ReBAC был предложен Кэрри И. Гейтс в 2006 году^[3].

В 2019 году компания Google опубликовала статью об архитектуре системы управления авторизацией «Zanzibar: Google’s Consistent, Global Authorization System»^[1]. В этой работе система описывается как состоящая из конфигураций пространства имён и данных отношений, представленных в виде триплетов.

После публикации этой статьи начался переход модели к активному промышленному внедрению. В период с 2024 по 2026 год вокруг идей Zanzibar сформировалась развитая экосистема, что сопровождалось активным ростом open-source проектов (таких как SpiceDB и OpenFGA) и появлением коммерческих решений^[4].^[5]

Ключевыми компонентами архитектуры ReBAC являются хранилище отношений, схема (или конфигурация пространства имён), ядро авторизации и API. Хранилище отношений содержит связи между сущностями в виде кортежей. Схема определяет типы объектов и возможные отношения между ними. Ядро авторизации отвечает за обработку запросов, а API предоставляет интерфейсы для управления связями и проверки прав доступа^[6].

Механизм проверки прав доступа базируется на обходе ориентированного графа связей от субъекта к объекту. При поступлении запроса система ищет в графе путь, который связывает пользователя с целевым ресурсом и подтверждает наличие необходимого разрешения согласно установленным политикам^[7].

В крупных системах с большим количеством пользователей и ресурсов обход сложных графов может приводить к значительным задержкам, что создаёт проблемы с масштабируемостью. Для оптимизации производительности применяются различные методы, включая использование специализированных баз данных, кэширование результатов проверок и материализацию разрешений (предварительное вычисление и сохранение прав доступа)^[8].

В отличие от модели ролевого управления доступом (англ. role-based access control, RBAC), в которой определяются роли с закреплёнными за ними наборами привилегий и к которым назначаются субъекты^[9], ReBAC, как и ABAC (англ. Attribute-based access control, ABAC)^[10], позволяет задавать более тонкие настройки разрешений^[9]. За счёт использования динамических связей вместо создания множества статичных ролей ReBAC решает присущую RBAC проблему «ролевого взрыва» (role explosion)^[11]. Например, если в системе ReBAC определён ресурс типа «документ», для которого возможна операция «редактор», и в системе содержится отношение «('alice', 'редактор', 'документ: budget')», то субъект «Alice» получает право редактировать конкретный ресурс «документ: budget». Недостатком ReBAC является то, что такая детализация требует большего числа проверок авторизации в приложениях.

Системы ReBAC по умолчанию реализуют запрет доступа, и на их основе возможно построение RBAC-систем^[1]. Современной тенденцией является создание гибридных систем, где RBAC задаёт базовый каркас прав, а ReBAC используется для тонкой настройки доступа к объектам^[2].

Преимущества:

• гибкость^[12];
• соответствие реальным организационным структурам^[13];
• высокая гранулярность управления доступом^[14].

Недостатки:

• сложность первоначального проектирования графа отношений^[15];
• высокие требования к вычислительным ресурсам при проверке прав (обход графа)^[15];
• сложность аудита доступа^[14].

Популярность модель управления доступом на основе отношений приобрела с ростом социальных сетей, где пользователям необходимо управлять доступом к личной информации в зависимости от своих отношений с получателем, а не от роли получателя^[3]. В таких системах ReBAC позволяет управлять видимостью контента на основе связей (например, предоставлять доступ только группе «друзья» или «семья»)^[12].

Благодаря ReBAC появилась возможность коллективно назначать разрешения группам и командам, что устраняет необходимость индивидуальной настройки доступа к каждому ресурсу. В системах управления документами (например, Google Drive) модель применяется для настройки прав на основе связей между пользователями и контентом^[1]. Права определяются отношениями «владелец», «редактор» или «читатель» для конкретного документа, при этом поддерживается наследование прав, когда доступ к папке автоматически распространяется на все вложенные в неё файлы.

Модель также активно внедряется в современные B2B SaaS-приложения и платформы. Например, сервис аренды жилья Airbnb использует систему авторизации Himeji, построенную на принципах ReBAC: гость получает доступ к точному адресу жилья только после подтверждения бронирования, а к паролю от Wi-Fi — исключительно на время своего пребывания^[16].

Наиболее значимые реализации, созданные под влиянием архитектуры Google Zanzibar, разделяются на проекты с открытым исходным кодом и коммерческие решения:^[4]

Open-source проекты:

• SpiceDB — база данных для хранения и вычисления прав доступа, поддерживаемая компанией Authzed^[17].
• OpenFGA — система авторизации, переданная в Cloud Native Computing Foundation (CNCF)^[18].
• Keto — часть экосистемы идентификации и управления доступом Ory^[4].
• Permify — решение, ориентированное на многопользовательские (multi-tenant) приложения^[4].

Коммерческие платформы и сервисы:

• Authzed — платформа, построенная на базе проекта SpiceDB и предлагающая управляемые облачные сервисы^[19].
• Aserto — облачный сервис авторизации, позволяющий комбинировать ReBAC с другими моделями (RBAC и ABAC)^[20].
• Permit.io — платформа, предлагающая ReBAC в сочетании с другими моделями контроля доступа^[21].