Группа против роли (Есть ли реальная разница?)

Question

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

Недавно я столкнулся с программным обеспечением для администрирования, где собрались пользователи. Каждому пользователю может быть назначен модуль (вся система разбита на несколько частей, называемых модулями, т. Е. Модуль администрирования, модуль опроса, модуль заказов, модуль клиента). Кроме того, у каждого модуля есть список функций, которые могут быть разрешены или запрещены для каждого пользователя. Допустим, пользователь Джон Смит может получить доступ к модулю Orders и редактировать любой заказ, но не дал права удалить любой из них.

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

Зачем называть это группой, а не ролью? Я не знаю, я просто так чувствую. Мне кажется, что это просто не имеет значения:] Но я все же хотел бы знать реальную разницу.

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

Answer 1

Google твой друг:)

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

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 (даже если она редко используется), которая обычно отсутствует в системах с поддержкой групп.

Answer 2

Группа - это средство организации пользователей, а роль - это средство организации прав.

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

Например, CMS может иметь некоторые разрешения, такие как чтение сообщения, создание сообщения, редактирование сообщения. Роль редактора может быть в состоянии читать и редактировать, но не создавать (не знаю почему!). Сообщение может создавать и читать и т. Д. Группа менеджеров может иметь роль редактора, в то время как пользователь в ИТ, который не входит в группу менеджеров, может также иметь роль редактора, даже если остальная часть его или ее группа не.

Так что, хотя в простой системе группы и роли часто тесно связаны, это не всегда так.

Answer 3

Хотя между ролями и группами существует семантическая разница (как описано выше в других ответах), технически роли и группы кажутся одинаковыми. Ничто не мешает вам назначать разрешения непосредственно пользователям и группам (это можно рассматривать как точную настройку контроля доступа). Эквивалентно, когда пользователю назначена роль, его можно считать участником роли в том же смысле, когда пользователь становится членом группы.

Таким образом, мы можем не получить никакой реальной разницы между ролями и группами. Оба могут быть рассмотрены для группировки пользователей И / ИЛИ Разрешения. Таким образом, разница только семантическая: - если это семантически используется для группировки разрешений, то это будет роль; - если это семантически используется для группировки пользователей, то это группа. Технически разницы нет.

Answer 4

«Группа» - это совокупность пользователей. «Роль» - это набор разрешений. Это означает, что , когда группа альфа включает в себя группу бета , альфа получает всех пользователей от беты, а бета получает все разрешения от альфы. И наоборот, можно сказать, что роль бета включает в себя роль альфа , и к нему применимы те же выводы.

A конкретный пример проясняет ситуацию. Рассмотрим «службу поддержки» и «службу поддержки клиентов». Если вы рассматриваете эти коллекции как группы, то становится ясно, что пользователи службы поддержки клиентов «включают в себя» старших пользователей службы поддержки клиентов. Однако, если вы посмотрите на них как на роли, то станет ясно, что разрешения для поддержки старших клиентов «включают» разрешения для поддержки клиентов.

Теоретически, вы могли бы просто иметь один тип коллекции. Однако было бы неоднозначно, если бы вы сказали, что «коллекция альфа включает коллекцию бета» . В этом случае вы не можете определить, находятся ли пользователи в альфа-версии в бета-версии (например, в роли) или пользователи в бета-версии находятся в бета-версии (например, в группе). Для того чтобы сделать терминологию, такую ​​как «включает», и визуальные элементы, такие как древовидные представления, однозначными, большинство систем rbac требуют, чтобы вы указали, является ли рассматриваемая коллекция «группой» или «ролью», по крайней мере, для обсуждения.

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

Answer 5

Предыдущие ответы все замечательные. Как было указано, концепция «Группа против роли» является скорее концептуальной, чем технической. Мы придерживаемся позиции, что группы используются для сдерживания пользователей (пользователь может входить в несколько групп: т. Е. Джо входит в группу менеджеров, а также в группу ИТ [он является менеджером в ИТ]) и назначать широкие привилегии. (т. е. наша система магнитных карт позволяет всем пользователям ИТ-группы получить доступ к серверной комнате). Роли теперь использовались для добавления привилегий определенным пользователям (то есть люди в ИТ-группе могут RDP на серверы, но не могут назначать пользователей или изменять разрешения, люди в ИТ-группе с ролью администратора могут назначать пользователей и изменять разрешения). Роли также могут состоять из других ролей (Джо имеет роль администратора для добавления пользователей / привилегий, а также роль администратора базы данных для внесения изменений в базу данных в СУБД на сервере). Роли также могут быть очень специфичными, поскольку мы можем создавать индивидуальные пользовательские роли (то есть JoesRole), которые могут быть очень специфичными для пользователя. Итак, подведем итог: мы используем группы для управления пользователями и назначаем общие роли и роли для управления привилегиями. Это также накопительно. Группе, в которой находится пользователь, могут быть назначены роли (или список доступных ролей), которые дадут очень общие привилегии (т. Е. Пользователи ИТ-группы имеют роль ServerRDP, которая позволяет им входить на серверы), так что она назначается пользователю. Затем любые роли, к которым принадлежит пользователь, будут добавлены в том порядке, в котором они определены с последней ролью, имеющей последнее слово (роли могут разрешать, запрещать или не применять привилегии, так что при применении каждой роли она либо отменяет предыдущие настройки привилегии или не меняй это). После применения всех ролей на уровне группы и на уровне пользователя создается отдельная модель безопасности для пользователя, которую можно использовать во всех наших системах для определения доступа и возможностей.

Answer 6

ПРИМЕЧАНИЕ. Следующие рассуждения имеют смысл только в том случае, если кто-то пытается навязать безопасность внутри организации, то есть пытается ограничить доступ к информации ...

Группы эмпирически - они отвечают на вопрос «что». Они являются «есть» в том смысле, что они отражают существующую реальность доступа. IT-люди любят группы - они очень буквальны и их легко определить. В конце концов, все управление доступом в конечном итоге переходит (как мы все учились в средней школе ...) к ответу на вопрос «К какой группе вы принадлежите?»

Роли, однако, более нормативны - они определяют, что «должно быть». Хорошие менеджеры и HR любят «роли» - они не отвечают - они задают вопрос «Почему?» К сожалению, роли также могут быть расплывчатыми, и эта «нечеткость» может свести с ума (ИТ) людей.

Чтобы использовать приведенный выше медицинский пример, если роль «врача первичной помощи» имеет больше прав (т. Е. Доступ к большему количеству групп), чем роль «рентгена» техник ", это потому, что люди (менеджеры и HR) решили , почему это должно было произойти. В этом смысле они являются «коллективной мудростью» организации.

Допустим, врачу предоставляется доступ (членство в группе с доступом) к финансовым записям пациентов. Обычно это выходит за рамки «роли» врача, и следует обсудить . Таким образом, никто (независимо от уровня квалификации) не должен иметь полного доступа ко всем группам - это способствует злоупотреблениям властью. Вот почему «ролевая инженерия» так важна - без нее вам просто раздают групповой доступ, как много конфет. Люди будут собирать (а иногда и орду) групповой доступ без обсуждения опасностей, связанных с чрезмерной властью.

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

Answer 7

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

Answer 8

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

Группы используются для «группировки» пользователей или ролей в системе для легкого управления безопасностью. Например, группа «Лидерская группа» может иметь своих членов из ролей менеджеров, директоров и архитекторов, а также отдельных пользователей, которые также не входят в эти роли. Теперь у вас должна быть возможность назначать определенные привилегии этой группе.

Answer 9

Вы можете назначить роль группе. Вы можете назначить пользователя для группы, и вы можете назначить роль отдельному пользователю в любой роли пользователя. Имея в виду. Жан Доу может находиться в группе SalesDeptartment с ролью вне ReportWritter, которая позволяет печатать наши отчеты из SharePoint, но в группе SalesDepartment другие могут не иметь роли ReportWritter. - Другими словами, роли являются особыми привилегиями в рамках назначенных групп. Надеюсь, что это делает любые сцены.

Ура !!!