Роли RBAC и бизнес-функции

Уверен, что раньше этот вопрос задавали много раз. Я много дней искал в Интернете, но с каждым разом все больше и больше запутываюсь. Я читал стандарт 359-2012 и книги, но все же.

Какова на самом деле роль RBAC? Я видел много путаницы, когда люди склонны называть ролями бизнес-роль, которую может иметь пользователь, например Аналитик по безопасности или помощник по персоналу. Насколько я понимаю, это не роль. Роль - это то, что имеет смысл в системе. Например, я аналитик InfoSec, это моя бизнес-роль. Для RBAC мои роли будут назначены для каждого системного случая. Т.е. в базе данных у меня может быть роль Database_Admin, в другой системе я могу иметь роль System_User, в CRM я могу быть CRM_PowerUser, для доступа к файлам на FTP-сервере я могу выполнять роль FTP_ReadOnly. Итак, у меня есть несколько ролей, которые зависят от системы / приложения / ресурса.

Что касается бизнеса, мы можем сказать, что я аналитик InfoSec, который является сотрудником отдела безопасности, который также является обычным сотрудником. Каждый «наследует» предыдущий. Каждая из этих бизнес-ролей предоставляет доступ к системам / приложениям / ресурсам.

Подводя итог, у меня есть бизнес-функции InfoSec Analyst -> Сотрудник службы безопасности -> Обычный сотрудник, и каждая из этих бизнес-функций дает мне доступ к определенным ролям (как упоминалось выше).

Имеет ли это смысл? Я что-то не так понимаю?


roles rbac
person Lazaros Kyr    schedule 16.09.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Это приятно, потому что ...

Subject-Roles:

Peter +---- Company3000-Employee
      |
      +---- London-Department
      |
      +---- CoreSystem-Backend-Developer

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

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

Role-Roles:

London-Department +---- London-Visitor
                  |
                  +---- London-Permament +---- London-Temporary

Таким образом, вы можете группировать связанные группы разрешений. Здесь London-Permament получает все права от London-Temporary (например, использование главного входа для выхода И входа, в результате чего посетитель должен иметь возможность только выйти, но не только вход).

Наконец, у вас есть Role-Permissions:

Role-Permissions:

London-Visitor +---- [permitted to exit building]

London-Permanent +-- [permitted to use parking deck]
                 |
                 +-- Longon-Temporary -- [permitted to enter building]

Насколько глубоко вы хотите все это вложить - дело вкуса и требований. Например, вы также можете смоделировать его так, чтобы London-Temporary был производным от London-Visitor (хотя это затруднило бы ограничения при временном отмене входа-доступа только для посетителей, например, на химических заводах, когда вход только посетителям должен быть запрещен).

В этом примере Job отделен от Location, и они оба отделены от лестницы иерархии. Это имеет смысл:

- Peter should have access to his documents in his cloud-storage, never mind _where_ he is physically.
- Peter should not be able to just enter a Company3000 office in Germany without being handed a pass.

И так далее.

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

В основном это моя интерпретация / реализация RBAC. Он поддерживает только дополнительные права, например наследование всегда добавляет разрешения, но не удаляет их.

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

смотрите также

person Sebastian Mach    schedule 16.09.2015
comment
У меня аналогичный подход к моей реализации RBAC, хотя у нас нет ограничений по местоположению. Каждому сотруднику назначается бизнес-роль Сотрудник, которая переводится в определенные роли системы / приложения / и т. Д. (Например, Windows_user). Затем у нее есть роль отдела (сотрудник информационной безопасности), которая также дает доступ к другим ролям (System1_Admin, ResourceX_WriteOnly), а затем более конкретная роль (аналитик информационной безопасности или менеджер информационной безопасности), которая дает более конкретный доступ (System2_Admin для менеджера и System2_StandardUser для аналитика). - person Lazaros Kyr; 16.09.2015
comment
(продолжение) И так далее. Насколько я понял, мы делаем то же самое, и нет, у нас тоже нет SoD, что значительно упрощает работу. - person Lazaros Kyr; 16.09.2015
comment
@LazarosKyr: Я думаю, нам нужно различать реализацию и реализацию :) Когда я говорил о реализации, я имел в виду сам код, а не то, как компания реализует роли. Это были действительно просто примеры. В моей RBAC-библиотеке я попытался упростить. У меня есть три основных таблицы: субъекты, роли и разрешения. А еще у меня есть таблицы соединений: RoleSubjects, RolePermissions и RoleRoles. Я думаю, что это минимум, который вам нужен для реализации RBAC. Что в конечном итоге сделает пользователь, полностью зависит от него. Думаю, мы оба на правильном пути :) - person Sebastian Mach; 16.09.2015