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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользователям присваиваются роли в зависимости от ответственности, которую они играют в любой системе. Например, пользователи с ролью «Менеджер по продажам» могут выполнять определенные действия, например предоставлять дополнительную скидку на продукт.

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

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

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

Ура !!!