Группа против роли (Любая реальная разница?)

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

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

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

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

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

ОТВЕТЫ

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

Надеюсь, что это поможет.

=======================

Добавьте еще немного, увидев ответ Симона с хорошим ответом. Роли помогают управлять разрешениями. Группы помогают управлять объектами и предметами. Более того, можно было бы рассматривать роли как "контексты". Роль "Х" может описывать контекст безопасности, который управляет тем, как субъект Y получает доступ (или не получает доступ) к объекту Z.

Другим важным отличием (или идеалом) является то, что есть роль инженера, человека, который разрабатывает роли, контексты, которые необходимы и/или очевидны в приложении, системе или ОС. Роль инженера обычно (но не обязательно) также является администратором роли (или sysadmin). Более того, истинная роль (не предназначенная для каламбура) инженера-специалиста в области безопасности, а не администрирования.

Это новая группа, формализованная RBAC (даже если она редко используется), которая, как правило, не присутствует в системах с поддержкой групп.

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ура!!!