Смешанный дизайн RBAC - хорошо или плохо?

Question

Введение

Я разрабатываю свою систему доступа на основе прав доступа на основе приложений. В моей системе я имею следующие роли:

• Корень
• Офис-менеджер
• Аудитор
• Заказчик
• работник

Например, позволяет просматривать пользователей отношения с ' задача ".

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

Root пользователь может делать все, он может создавать, обновлять, читать, удалять «задачи». Офис-менеджер может перечислить, обновить и создать «задачи». Аудитор может перечислять только задачи.

Root, Аудитор и Офис-менеджер будет иметь доступ к той же (полного) набора свойств сущностей «задач». Эти три пользовательских типа будут получать доступ к системе через один и тот же интерфейс управления (модуль веб-приложения).

Клиенты получат доступ к системе через отдельный ролевой модуль (модуль клиента), функциональность слишком специфична. Рабочие - тоже (рабочий модуль).

Таким образом, используя описанный пример, можно сказать, что мы можем создать следующие разрешения для Root, ревизором и офис-менеджера:

• LIST_TASKS
• CREATE_TASKS
• UPDATE_TASKS
• DELETE_TASKS

Это будет работать для них, но не для Клиент и Рабочий. Для работника мы могли бы сделать:

• LIST_WORKER_OWN_TASKS
• UPDATE_WORKER_TASK_STATUS

... и так далее.

Но это имеет довольно низкий смысл, как и для меня. Никто, кроме Работника, не будет использовать эти разрешения. Кроме того, условия, при которых Работник сможет редактировать определенные свойства объекта «Задача», не могут быть описаны с использованием разрешений.

Резюме

Таким образом, я делаю вывод о том, что мне нужна смешанная система контроля доступа. Клиенты и работники будут ролями без каких-либо разрешений. Менеджеры Root, Auditor и Office будут ролями с набором разрешений, привязанных к каждой роли.

Наконец, мы можем назвать такой механизм системы доступа с множественными разрешениями и функциями.

Вопрос

Является ли это нормальным иметь такую ​​конструкцию? Я думаю неправильно? Или лучше описать Клиент и Рабочая логика (насколько это возможно) с использованием очень подробного списка разрешений?

Answer 1

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

В рамках организации роли создаются для выполнения различных функций работы. Разрешения на выполнение определенных операций назначаются определенным ролям . Пользователям или сотрудникам (или другим пользователям системы) назначаются определенные роли, и через эти назначения назначаются разрешения компьютера для выполнения определенных функций компьютерной системы. Поскольку пользователям не назначены разрешения напрямую, но они приобретают только через их роль (или роли), управление правами отдельного пользователя становится простым назначением соответствующих ролей учетной записи пользователя ; это упрощает общие операции, такие как добавление пользователя или изменение отдела пользователя.

Ссылка: https://en.wikipedia.org/wiki/Role-based_access_control

Можно также реализовать ACL (списков контроля доступа)

список управления доступом (ACL), по отношению к файловой системе компьютера, список разрешений, прикрепленных к объекту. ACL указывает, каким пользователям или системным процессам предоставляется доступ к объектам, а также , какие операции разрешены для данных объектов. [1] Каждая запись в стандартном ACL указывает объект и операцию.Например, если в файловом объекте есть ACL, который содержит (Alice: read, write; Bob: read), , это даст Алисе разрешение читать и записывать файл, а Bob - , только читает его.

Обычно я предпочитаю ACL-реализации, потому что они дают более тонкое зерно контроля.

Ссылка: https://en.wikipedia.org/wiki/Access_control_list

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