Как спроектировать контроль доступа на основе ролей?


15

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

Пока у меня есть следующие объекты:

пользователи - люди, которые будут использовать систему. Здесь у меня есть имена пользователей и пароли. Роли - Коллекция ролей, которые могут иметь пользователи. Вещи, такие как ресурсы менеджера, администратора и т. Д. - вещи, которыми пользователи могут манипулировать. Подобно контрактам, пользователям, черновикам контрактов и т. П. Операциям - то, что пользователи могут делать с ресурсами. Как создать, прочитать, обновить или удалить.

Теперь мое сомнение возникает здесь на диаграмме, где у меня есть такое отношение:

Операции (0 .. *) выполняются над ресурсами (0 .. *), которые генерируют таблицу, которую я назвал permissions, и которая будет хранить операцию и ресурс .

Таблица разрешений будет выглядеть следующим образом (одна строка): ID: 1, операция: создание, ресурс: контракт.

Что означает разрешение на создание в контракте .

Я сделал это таким образом, потому что я чувствую, что некоторые ресурсы могут иметь не все виды операций. Например, для регистрации договоров пользователи могут загружать файлы , но эта операция недоступна для регистрации поставщика .

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

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

Я могу уточнить, если что-то не понятно.

Это правильный способ реализации rbac?

РЕДАКТИРОВАТЬ

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

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

Итак, я хочу знать с точки зрения дизайна базы данных, является ли это разрешение таблицы, которое имеет одну операцию столбца и другой ресурс, правильно? Буду ли я сталкиваться с проблемами, если так будет и дальше?


2
Что вы подразумеваете под "правильно"? Примечание: не отвечайте с тавтологией как "лучшая практика". Укажите ваши конкретные требования.
Роберт Харви

1
Мое определение «правильного» обычно является «тем, которое наиболее эффективно соответствует функциональным и нефункциональным требованиям вашего программного обеспечения». Обратите внимание, что NIST предлагает подробные рекомендации и рекомендации по безопасности на основе ролей. См. Csrc.nist.gov/groups/SNS/rbac
Роберт Харви

Возможно, вам будет интересно посмотреть, как это делается в проекте pundit .
Антарр Берд

1
Вы должны рассмотреть возможность использования библиотеки для этого.
Рибальд Эдди

Есть много библиотек, которые сделают для вас RBAC или ABAC
Дэвид Броссар

Ответы:


11

Ваш дизайн кажется мне очень близким. Просто пара предложений.

пользователи - люди, которые будут использовать систему. Здесь у меня есть имена пользователей и пароли.

хорошо

Роли - Коллекция ролей, которые могут иметь пользователи. Вещи, как менеджер, администратор и т. Д.

Тоже хорошо. Но вам также понадобится сущность / таблица UserRoles, которая скажет вам, у каких пользователей какие роли. Вполне вероятно, что данный пользователь может иметь две или более роли.

ресурсы - вещи, которыми пользователи могут манипулировать. Как контракты, пользователи, проекты контрактов и т. Д.

Может быть, это просто вопрос семантики. Я не думаю, что пользователи напрямую манипулируют ресурсами; роли делают. Таким образом, идет пользователь -> роль пользователя -> роль -> операция -> ресурс

операции - то, что пользователи могут делать с ресурсами. Как создать, прочитать, обновить или удалить.

да, кроме "ролей" вместо "пользователей"

Таблица разрешений будет выглядеть следующим образом (одна строка): ID: 1, операция: создание, ресурс: контракт. Что означает разрешение на создание контракта.

Хммм. Есть два способа пойти с этим. Вы можете иметь таблицу разрешений, которую вы описываете, но вам также понадобится дополнительная RolePermissionsтаблица / сущность, которая сообщает вам, какая роль имеет какое разрешение. Но я не уверен, что это необходимо.

Более простой способ сделать это - таблица / объект разрешений со следующими столбцами / атрибутами: идентификатор роли, идентификатор операции, идентификатор ресурса. Таким образом, комбинации операций x ресурсов назначаются непосредственно роли, а не загружаются в разрешение, назначенное роли. Это устраняет одну сущность. В действительности нет необходимости в отдельной таблице разрешений, не зависящей от роли, если только вы не хотите заранее определить, какие комбинации разрешений разрешены, а какие нет.


Прежде всего, я полностью согласен с коррекцией «роли» вместо «пользователей». Это то, что я имел в виду. Дело в том, что я хочу связать ресурсы и с операциями. Например: ресурс контракта имеет такую ​​операцию, как upload_file. Поэтому я не хочу, чтобы операция upload_file также появлялась в другом ресурсе, у которого нет операции upload_file, такой как провайдеры (другой ресурс), когда администратор назначает разрешения для роли.
imran.razak

13

Я бы не стал использовать или внедрять RBAC. Вместо этого я бы использовал ABAC. Позволь мне объяснить...

  • RBAC или управление доступом на основе ролей - это управление пользователями и назначение ролей. В RBAC вы можете сказать, что Алиса - менеджер. Вы можете определить статические разрешения вместе с этим. Например, менеджер может утверждать кредиты. Так что есть ссылка от Алисы на менеджера, чтобы утвердить кредит в качестве разрешения. Существует множество систем, которые позволят вам сделать это, поэтому вам не нужно реализовывать свои собственные таблицы. Даже LDAP поддерживает ограниченные наборы RBAC. Это нормально, если у вас относительно небольшой набор ролей и разрешений. Но что, если вы хотите принять во внимание конкретные разрешения, как в вашем случае? Посмотреть, удалить, вставить? Что если вы хотите принять во внимание отношения?
  • ABAC или управление доступом на основе атрибутов - это детализированная авторизация на основе политик. С ABAC вы можете использовать роли, определенные в RBAC, и писать политики, например:
    • Менеджеры могут просматривать документы в своем отделе
    • Сотрудники могут редактировать свои документы

В своем вопросе вы по сути определили информационную модель. Ваши объекты и их атрибуты, например, пользователь (имя, пароль, отдел ...); объект (например, контракт) и так далее.

Информационная модель

Таким образом, в ABAC вы полностью отделяете код / ​​логику приложения от логики авторизации, которая затем сохраняется в виде политик с использованием атрибутов. Сами разрешения хранятся прямо в политике (см. Пример выше). Архитектура развертывания ABAC выглядит следующим образом

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

Дело в том, что если вы используете подход ABAC, вы пишете политики для ABAC (либо в XACML, либо в ALFA - для этого есть множество инструментов), и вам больше никогда не придется заново настраивать или настраивать RBAC или контроль доступа.


1
В вашем примере политик сказано, что менеджеры могут просматривать документы в своем отделе. Означает ли это, что система уже будет иметь предварительно определенные разрешения, роли и типы ресурсов?
imran.razak

Нет. Это означает, что у вас есть что-то (LDAP? Таблица?), Которое связывает пользователя (Алису) с его ролями (менеджер ...). После этого у вас будет таблица, которая будет содержать метаданные документа (обычно это таблица в приложении, которое вы защищаете). Само разрешение (просмотр, редактирование, удаление) хранится в политике.
Дэвид Броссар
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.