Общие сведения об управлении доступом на основе ролей (RBAC)

командой Supertokens

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

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

В нашем примере мы создадим образец приложения для ведения блога.

Во-первых, у нас есть роль regular-user. Мы хотим разрешить обычным пользователям читать все сообщения в блогах, но только редактировать или удалять сообщения, созданные ими.

С другой стороны, мы создаем роль admin, которая позволяет admin создавать, редактировать и удалять все сообщения в блогах.

Таким образом, если пользователь только с ролью regular-user попытается отредактировать сообщение в блоге другого пользователя, наша система увидит, что роль regular-user не имеет разрешение редактировать эту запись в блоге и отклонить запрос.

RBAC или ABAC?

Управление доступом на основе атрибутов (ABAC) — это еще один подход, при котором разрешения назначаются на основе атрибутов пользователя, атрибутов ресурсов и атрибутов среды. Например, доступ к файлу дизайна может быть разрешен только пользователям, у которых в заголовке есть слово "дизайнер", и доступ к которым осуществляется в рабочие дни.

В то время как ABAC обеспечивает более точную детализацию доступа к различным ресурсам, RBAC выигрывает благодаря простоте реализации. Первоначальная стоимость установки RBAC намного ниже, чем у ABAC.

С помощью RBAC у компаний есть простой способ группировать пользователей с одинаковыми потребностями в доступе, а затем назначать разрешения этим группам.

При использовании ABAC компании должны сначала определить переменные и настроить различные правила на основе атрибутов, что может оказаться трудоемким процессом.

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

Простота понимания. Благодаря интуитивно понятной структуре базовая бизнес-логика RBAC проста в общении и понимании даже при использовании десятков различных ролей.

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

* Улучшение соответствия. Использование RBAC заставляет разработчиков думать и организовывать разрешения приложений и контроль доступа. Затем эта информация может быть использована ответственными за соблюдение нормативных требований во время проверок.

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

Недостатки RBAC

* Сложно делать исключения: может быть сложно сделать исключения в том, как работает роль. В нашем примере выше, если мы хотим добавить правило, согласно которому пользователи с ролью regular-user не могут редактировать свои собственные сообщения, если они уже внесли десять правок, его нужно будет добавить в логику API как исключение. Система ролей/разрешений не может легко выразить это. Это вызывает проблемы, так как мы должны кодировать это правило во всех местах, где мы проверяем разрешение edit:self.

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

* Может вызвать конфликты разрешений: могут возникнуть ситуации, когда пользователю назначены две роли с противоречивой информацией. В нашем примере выше, если пользователю назначена роль admin и роль regular-user, у него есть edit:self и редактировать: все права . Какой из них должен иметь приоритет? Логика приоритета может быть закодирована в API, но это открывает возможность для ошибок.

    // only allow editing if the blog post belongs to the current user 
} 
else if (permissions.contains("edit:all")) {
    // allow editing 
}  

Это может вызвать проблемы, если у пользователя есть роли admin и regular-user — несмотря на наличие роли admin, они не смогут редактировать все блоги, потому что оператор edit:self выполняется первым, а правила edit:all пропускаются в следующем операторе else-if.

Реализация RBAC

Мы в Supertokens много думали об аутентификации и авторизации пользователей. Собственно, это все, что мы делаем. Недавно мы запустили функцию пользовательских ролей, основанную на принципах RBAC. Нашу систему аутентификации пользователей с открытым исходным кодом можно настроить всего за 45 минут!

Вы можете узнать больше о том, как использовать роли пользователей и функции разрешений с помощью SuperToken, из руководств по рецептам.

Написано людьми на SuperTokens — надеюсь, вам понравилось! Мы всегда доступны на нашем сервере Discord. Присоединяйтесь к нам, если у вас есть вопросы или вам нужна помощь.

:::информация Также опубликовано здесь.

:::