Группа против роли (Есть ли реальная разница?)
Может кто-нибудь сказать мне, в чем реальная разница между группой и ролью? Я пытался понять это в течение некоторого времени, и чем больше информации я читаю, тем больше у меня возникает ощущение, что это поднимается только для того, чтобы сбить людей с толку, и в этом нет никакой разницы. Оба могут выполнять работу другого. Я всегда использовал группу для управления пользователями и их правами доступа.
Недавно я столкнулся с программным обеспечением для администрирования, где собралось множество пользователей. Каждому пользователю может быть назначен модуль (вся система разбита на несколько частей, называемых модулями, т. Е. Модуль администрирования, модуль опроса, модуль заказов, модуль клиента). Кроме того, у каждого модуля есть список функций, которые могут быть разрешены или запрещены для каждого пользователя. Допустим, пользователь Джон Смит может получить доступ к модулю Orders и редактировать любой заказ, но не дал права удалить любой из них.
Если бы было больше пользователей с такой же компетенцией, я бы использовал группу для управления этим. Я бы объединил таких пользователей в одну группу и назначил бы права доступа к модулям и их функциям. Все пользователи в одной группе будут иметь одинаковые права доступа.
Зачем называть это группой, а не ролью? Я не знаю, я просто так чувствую. Мне кажется, что это просто не имеет значения:] Но я все же хотел бы знать реальную разницу.
Любые предложения, почему это должно быть скорее названо ролью, чем группой или наоборот?
10 ответов
Гугл твой друг:)
В любом случае, разрыв между ролью и группой исходит из концепции компьютерной безопасности (в отличие от простого управления ресурсами). Профессор Рави Санду обеспечивает оригинальное освещение семантической разницы между ролями и группами.
http://profsandhu.com/workshop/role-group.pdf
Группа - это совокупность пользователей с заданным набором разрешений, назначенных группе (и транзитивно, пользователям). Роль - это набор разрешений, и пользователь эффективно наследует эти разрешения, когда действует под этой ролью.
Обычно членство в вашей группе сохраняется в течение всего времени входа в систему. С другой стороны, роль может быть активирована в соответствии с конкретными условиями. Если ваша текущая роль - "медицинский персонал", вы можете просмотреть некоторые медицинские записи для данного пациента. Если, однако, ваша роль также является "врачом", вы можете увидеть дополнительную медицинскую информацию за пределами того, что может видеть человек с ролью "медицинского персонала".
Роли могут быть активированы по времени суток, месту доступа. Роли также могут быть расширены / связаны с атрибутами. Вы можете действовать как "врач", но если у вас нет атрибута "основного врача" или отношения со мной (пользователь с ролью "пациента"), то вы не сможете увидеть всю мою историю болезни.
Вы можете сделать все это с группами, но опять же, группы, как правило, сосредоточены на идентичности, а не на роли или деятельности. И только что описанные аспекты безопасности имеют тенденцию лучше соответствовать последним, чем первым.
Во многих случаях при использовании классификации вещей (и не более того) группы и роли функционируют одинаково. Группы, однако, основаны на идентичности, тогда как роли предназначены для разграничения деятельности. К сожалению, операционные системы имеют тенденцию стирать различия, рассматривая роли как группы.
Вы видите гораздо более четкое различие с ролями на уровне приложения или системы - несущими семантику приложения или системы (как в ролях Oracle) - в отличие от "ролей", реализованных на уровне ОС (которые обычно синонимичны группам).
Могут быть ограничения для ролей и моделей контроля доступа на основе ролей (как, впрочем, и во всем):
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
Около десяти лет назад я наблюдал некоторые исследования по управлению доступом на основе атрибутов и отношений, которые обеспечивают гораздо более высокую степень детализации, чем контроль доступа на основе ролей. К сожалению, я не видел много активности в этой области в течение многих лет.
Наиболее важное различие между ролями и группами заключается в том, что роли обычно реализуют механизм обязательного управления доступом (MAC). Вы не можете назначить себя (или других) на роли. Это делает администратор ролей или инженер ролей.
Это внешне похоже на группы UNIX, где пользователь может / может быть в состоянии назначить себя группе (конечно, с помощью sudo). Когда группы назначаются в соответствии с процессом проектирования безопасности, это различие немного стирается.
Еще одной важной характеристикой является то, что настоящие модели RBAC могут обеспечить концепцию взаимоисключающих ролей. Напротив, основанные на идентичности группы аддитивны - идентичность принципала является суммой (или соединением) групп.
Другой характеристикой модели безопасности на основе реального RBAC является то, что элементы, созданные для конкретной роли, обычно не могут быть транзитивно доступны тем, кто не действует под этой ролью.
С другой стороны, в модели дискреционного управления доступом (DAC) (модель по умолчанию в Unix) вы не можете получить такой тип гарантии только с группами. Кстати, это не ограничение групп или Unix, а ограничение моделей DAC, основанных на идентичности (и транзитивно, с группами на основе идентичности).
Надеюсь, поможет.
=======================
Добавим еще немного, увидев хорошо поставленный ответ Саймона. Роли помогают вам управлять разрешениями. Группы помогают вам управлять объектами и предметами. Более того, можно считать роли "контекстами". Роль "X" может описывать контекст безопасности, который определяет, как субъект Y получает (или не получает) доступ к объекту Z.
Другое важное различие (или идеал) заключается в том, что существует ролевый инженер, человек, который разрабатывает роли, контексты, которые необходимы и / или очевидны в приложении, системе или ОС. Инженер роли обычно (но не обязательно) также администратор роли (или системный администратор). Более того, настоящая роль (не рассчитанная на каламбур) ролевого инженера находится в сфере безопасности, а не администрации.
Это новая группа, формализованная RBAC (даже если она редко используется), которая обычно отсутствует в системах с поддержкой групп.
Группа - это средство организации пользователей, а роль - это средство организации прав.
Это может быть полезно несколькими способами. Например, набор разрешений, сгруппированных в роли, может быть назначен набору групп или группе пользователей независимо от их группы.
Например, CMS может иметь некоторые разрешения, такие как чтение сообщения, создание сообщения, редактирование сообщения. Роль редактора может читать и редактировать, но не создавать (не знаю почему!). Сообщение может создавать и читать и т. Д. Группа менеджеров может иметь роль редактора, в то время как пользователь в ИТ, который не входит в группу менеджеров, может также иметь роль редактора, даже если остальная часть его или ее группа не.
Поэтому, хотя в простой системе группы и роли часто тесно связаны, это не всегда так.
"Группа" - это совокупность пользователей. "Роль" - это набор разрешений. Это означает, что когда группа альфа включает в себя группу бета, альфа получает всех пользователей от беты, а бета получает все разрешения от альфы. И наоборот, вы можете сказать, что бета-версия включает в себя альфа-роль, и к ней применимы те же выводы.
Конкретный пример проясняет ситуацию. Рассмотрим "службу поддержки" и "службу поддержки клиентов". Если вы рассматриваете эти коллекции как группы, то становится ясно, что пользователи службы поддержки клиентов "включают в себя" старших пользователей службы поддержки клиентов. Однако если вы посмотрите на них как на роли, то станет ясно, что разрешения для поддержки старших клиентов "включают" разрешения для поддержки клиентов.
Теоретически, вы можете просто иметь один тип коллекции. Однако было бы неоднозначно, если бы вы сказали, что "коллекция альфа включает коллекцию бета". В этом случае вы не можете определить, находятся ли пользователи в альфа-версии в бета-версии (например, роль) или пользователи в бета-версии находятся в альфа-версии (например, группа). Чтобы сделать терминологию, такую как "включает", и визуальные элементы, такие как представления дерева, однозначными, большинство систем rbac требуют, чтобы вы указали, является ли рассматриваемая коллекция "группой" или "ролью", по крайней мере, для обсуждения.
Некоторые аналогии могут помочь. С точки зрения теории множеств, когда группа альфа является подмножеством группы бета, тогда альфа разрешений - это расширенный набор бета разрешений. По сравнению с генеалогией, если группы похожи на дерево потомков, то роли похожи на дерево предков.
Хотя между ролями и группами существует семантическое различие (как описано выше в других ответах), технически роли и группы кажутся одинаковыми. Ничто не мешает вам назначать разрешения непосредственно пользователям и группам (это можно рассматривать как точную настройку контроля доступа). Эквивалентно, когда пользователю назначена роль, его можно считать участником роли в том же смысле, когда пользователь становится членом группы.
Таким образом, у нас не может быть никакой разницы между ролями и группами. Оба могут быть рассмотрены для группировки пользователей и / или разрешений. Таким образом, различие только семантическое: - если оно семантически используется для группировки разрешений, то оно является ролью; - если это семантически используется для группировки пользователей, то это группа. Технически нет никакой разницы.
ПРИМЕЧАНИЕ. - Следующие рассуждения имеют смысл, только если кто-то пытается навязать безопасность внутри организации, то есть пытается ограничить доступ к информации...
Группы эмпирически - они отвечают на вопрос "что". Они являются "есть" в том смысле, что они отражают существующую реальность доступа. IT-люди любят группы - они очень буквальны и их легко определить. В конце концов, все управление доступом в конечном итоге переходит (как мы все учились в средней школе...) к ответу на вопрос "К какой группе вы принадлежите?"
Роли, однако, являются более нормативными - они определяют, что "должно быть". Хорошие менеджеры и HR любят "роли" - они не отвечают - они задают вопрос "почему?" К сожалению, роли также могут быть расплывчатыми, и эта "нечеткость" может свести с ума (ИТ) людей.
Если использовать приведенный выше медицинский пример, если роль "врача первичной медицинской помощи" имеет больше прав (т.е. доступ к большему количеству групп), чем роль "рентгенолога", то это потому, что люди (руководители и отдел кадров) решили, почему это должно было случиться. В этом смысле они являются "коллективной мудростью" организации.
Допустим, врачу предоставляется доступ (членство в группе с доступом) к финансовым записям пациентов. Обычно это выходит за рамки "роли" врача и должно обсуждаться. Таким образом, никто (независимо от квалификации) не должен иметь полного доступа ко всем группам - это способствует злоупотреблениям властью. Вот почему "ролевая инженерия" так важна - без нее вам просто раздают групповой доступ, как много конфет. Люди будут собирать (а иногда и орду) групповой доступ без обсуждения опасностей чрезмерной власти.
В заключение, мудрость четко определенных ролей помогает смягчить опасность доступа беглых групп. Любой в организации может выступать за доступ к определенной группе. Но как только этот доступ предоставляется, от него редко отказываются. Ролевая инженерия (наряду с лучшими практиками, такими как четко определенные описания групп и уполномоченные менеджеры доступа к группам), может ограничить конфликт интересов в организации, децентрализовать процесс принятия решений и помочь сделать управление безопасностью более рациональным.
Предыдущие ответы все замечательные. Как было указано, концепция "Группа против роли" является скорее концептуальной, чем технической. Мы придерживаемся позиции, что группы используются для сдерживания пользователей (пользователь может входить в несколько групп, т. Е. Джо входит в группу менеджеров, а также в группу ИТ [он является менеджером в ИТ]) и назначать широкие привилегии. (т. е. наша система магнитных карт позволяет всем пользователям ИТ-группы получать доступ к серверной комнате). Роли теперь использовались для добавления привилегий определенным пользователям (т.е. люди в ИТ-группе могут RDP на серверы, но не могут назначать пользователей или изменять разрешения, люди в ИТ-группе с ролью администратора могут назначать пользователей и изменять разрешения). Roles can be made up of other roles as well (Joe has Admin role to add users/privileges and also has DBA role to do database changes to the DBMS on the server). Roles can be very specific as well in that we can make individual user Roles (ie JoesRole) that can be very specific for a user. So, to recap, we use Groups to manage users and assign general Roles and Roles to manage privileges. This is also cumulative. The Group the user is in may have Roles assigned (or a list of available Roles) that will give very general privileges (ie IT group users have the role ServerRDP that lets them log onto the servers) so that is assigned to the user. Then any Roles the user belongs in will be added in the order they are defined with the last Role having the final say (Roles can Allow, Deny or not apply privileges so that as each Role is applied it will either override previous settings for a privilege or not change it). Once all the Group level Roles and User level Roles have been applied, a distinct security model is created for the user that can be used throughout our systems to determine access and capabilities.
Назначение групп и ролей различается в приложениях, но в основном я понял следующее: группы (набор пользователей) статичны, а роли (набор разрешений) динамичны с политиками, например, основанными на времени от (9 до 6). группа или пользователь могут иметь эту роль, но не эту.
Пользователи назначаются на роли в зависимости от ответственности, которую они играют в любой системе. Например, пользователи в роли Sales Manager могут выполнять определенные действия, например предоставлять дополнительную скидку на продукт.
Группы используются для "группировки" пользователей или ролей в системе для простого управления безопасностью. Например, группа под названием "Лидерская группа" может иметь своих членов из ролей менеджеров, директоров и архитекторов, а также отдельных пользователей, которые также не входят в эти роли. Теперь вы должны быть в состоянии назначить определенные привилегии этой группе.
Вы можете назначить роль группе. Вы можете назначить пользователя для группы, и вы можете назначить роль отдельному пользователю в любой роли пользователя. Имея в виду. Жан Доу может быть в группе SalesDeptartment с ролью вне ReportWritter, которая позволяет печатать наши отчеты из SharePoint, но в группе SalesDepartment другие могут не иметь роли ReportWritter. - Другими словами, роли являются особыми привилегиями в рамках назначенных групп. Надеюсь, что это делает любые сцены.
Ура!!!
Это работает для нас:
- Управляйте пользовательскими политиками через группы (иногда добавляйте дополнительные политики вручную для отдельных пользователей)
- Управление политиками службы через роли (например, микрослужбе может потребоваться доступ к S3, и ему будут предоставлены разрешения через роль)