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

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