Как современные приложения управляют ролями и правами доступа

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

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

Почему традиционный RBAC не справляется

Управление доступом на основе ролей (Role-Based Access Control) назначает права через роли. Пользователь получает роль «редактор», которая предоставляет предопределённый набор прав. Просто и понятно.

Проблема возникает по мере роста приложений. Рассмотрим инструмент управления проектами, где пользователям нужны разные уровни доступа для каждого проекта, рабочего пространства и типа документа. Вы начинаете создавать роли вроде «редактор-проекта-А» и «администратор-пространства-Б». Такое разрастание ролей делает систему неуправляемой.

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

Современные паттерны авторизации

Управление доступом на основе отношений (ReBAC)

ReBAC определяет доступ через отношения между сущностями. Вместо вопроса «есть ли у этого пользователя роль редактора?», вы спрашиваете «есть ли у этого пользователя отношение редактора к этому документу?»

Система Zanzibar от Google стала пионером этого подхода в масштабе. Когда вы делитесь Google Doc, вы создаёте отношение. Затем система проходит по этим отношениям, чтобы ответить на вопросы о правах доступа. Инструменты вроде OpenFGA, SpiceDB и Permify реализуют модели, вдохновлённые Zanzibar, для приложений любого размера.

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

Управление доступом на основе атрибутов (ABAC)

ABAC оценивает доступ на основе атрибутов пользователей, ресурсов и контекста. Политика может гласить: «пользователи могут получать доступ к документам, если их отдел совпадает с отделом документа, и запрос происходит в рабочее время».

Эта модель отлично справляется с правилами, зависящими от контекста. Медицинские приложения используют ABAC для обеспечения соответствия требованиям HIPAA — доступ зависит от отношений пациент-врач, конфиденциальности данных и контекста доступа.

RBAC против ReBAC: когда использовать каждый

RBAC остаётся подходящим для приложений с чёткими статическими границами прав доступа. Внутренние инструменты с чётко определёнными типами пользователей выигрывают от его простоты.

ReBAC лучше подходит, когда права доступа зависят от владения ресурсом, совместного использования или организационной структуры. Любое приложение с функцией «поделиться» или мультитенантностью должно рассмотреть ReBAC.

Большинство production-систем сочетают оба подхода. RBAC обрабатывает широкие категории (администратор против обычного пользователя), в то время как ReBAC управляет правами на уровне ресурсов.

Архитектурные паттерны для контроля доступа в веб-приложениях

Разделение аутентификации и авторизации

Аутентификация отвечает на вопрос «кто этот пользователь?» Авторизация отвечает на вопрос «что он может делать?» Современные архитектуры рассматривают их как отдельные задачи с выделенными сервисами для каждой.

Ваш провайдер идентификации обрабатывает аутентификацию. Отдельный сервис авторизации — будь то собственная разработка или управляемый сервис — обрабатывает решения о правах доступа. Это разделение позволяет каждой системе развиваться независимо.

Политики как код (Policy-as-Code)

Современные паттерны авторизации предпочитают выражать правила в виде кода, а не конфигураций в базе данных. Policy-as-code означает, что ваша логика авторизации находится в системе контроля версий, проверяется в pull request’ах и разворачивается через ваш стандартный pipeline.

Open Policy Agent (OPA) использует Rego для определения политик. Cedar, разработанный AWS, предоставляет другой язык политик. Эти инструменты делают логику авторизации тестируемой и аудируемой.

Централизованная политика, распределённое применение

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

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

Последствия для фронтенда

Backend остаётся источником истины для всех решений о правах доступа. Никогда не доверяйте фронтенду в вопросах безопасности.

Тем не менее, фронтенду нужна информация о правах доступа для хорошего UX. Feature gating — скрытие кнопок, которые пользователь не может нажать, отключение форм, которые он не может отправить — требует знания прав доступа на стороне клиента. Паттерн прост: используйте проверки прав доступа (например, «может ли этот пользователь выполнить это действие?») для решений в UI, но всегда валидируйте на сервере.

Библиотеки вроде CASL помогают управлять логикой прав доступа на стороне клиента, сохраняя при этом фактическое применение на стороне сервера.

Заключение

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

Начните с определения того, где ваш текущий RBAC испытывает трудности. Если вы создаёте роли для каждой комбинации прав доступа, или если совместное использование и коллаборация кажутся прикрученными сверху, современные паттерны авторизации упростят вашу систему, делая её более функциональной.

Переход от «какая роль у этого пользователя?» к «какое отношение имеет этот пользователь к этому ресурсу?» меняет ваше представление о правах доступа. Это лучшая ментальная модель того, как пользователи фактически взаимодействуют с современными приложениями.

Часто задаваемые вопросы

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.