Группа против роли (есть ли реальная разница?)
может кто-нибудь сказать мне, в чем реальная разница между группой и роль? Я пытался понять это в течение некоторого времени, и чем больше информации я читаю, тем больше я понимаю, что это воспитывается только для того, чтобы запутать людей, и нет никакой реальной разницы. Оба могут делать работу другого. Я всегда использовал группу для управления пользователями и их правами доступа.
недавно я столкнулся с программным обеспечением для администрирования, где есть куча пользователей. Каждый пользователь может назначить модуль (вся система разделена на несколько частей, называемых модулями ie. Модуль администрирования, модуль опроса, модуль заказов, модуль клиента). Кроме того, каждый модуль имеет список функциональных возможностей, которые могут быть разрешены или запрещены для каждого пользователя. Итак, скажем, пользователь John Smith может получить доступ к заказам модуля и может редактировать любой заказ, но не имеет права удалять любой из них.
Если бы было больше пользователей с той же компетенцией, я бы использовал группу для управления этим. Я бы агрегировал такие пользователей в одну группу и назначить права доступа к модулям и их функции в группе. Все пользователи в одной группе будут иметь одинаковые права доступа.
Почему это называется группой, а не ролью? Я не знаю, я просто чувствую это. Мне кажется, что просто это не имеет большого значения:] но я все равно хотел бы знать реальную разницу.
любые предложения, почему это должно называться скорее ролью, чем группой или наоборот?
9 ответов:
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 могут обеспечить принципиальную схему взаимоисключающие роли. Напротив, группы, основанные на идентичности, являются аддитивными-идентичность принципала является суммой (или конъюнкцией) групп.
еще одной характеристикой модели безопасности на основе true-RBAC является то, что элементы, созданные для определенной роли, как правило, не могут быть транзитивно доступны тем, кто не действует в этой роли.
с другой стороны, в модели дискреционного управления доступом (DAC) (модель по умолчанию в Unix) вы не можете получить этот тип гарантия с группами самостоятельно. Кстати, это не ограничение групп или Unix, а ограничение моделей DAC, основанных на идентичности (и транзитивно, с группами на основе идентичности.)
надеюсь, что это помогает.
=======================
добавив еще немного, увидев хорошо поставленный ответ Саймона. Роли помогают управлять разрешениями. Группы помогают управлять объектами и субъектами. Более того, можно было бы думать о ролях как о "контекстах". Роль ' X ' может описывать контекст безопасности то правило, как субъект Y обращается (или не обращается) к объекту Z.
еще одно важное различие (или идеал) заключается в том, что есть инженер роли, Человек, который проектирует роли, контексты, которые необходимы и/или очевидны в приложении, системе или ОС. Инженер роли обычно является (но не обязательно должен быть) также администратором роли (или системным администратором). Кроме того, истинная роль (без каламбура) инженера роли находится в области техники безопасности, а не администрация.
Это новая группа, формализованная RBAC (даже если она редко используется), которая обычно не присутствовала в системах с поддержкой групп.
группа-это средство организации пользователей, в то время как роль обычно является средством организации прав.
Это может быть полезно в нескольких отношениях. Например, набор разрешений, сгруппированных в роли, может быть назначен набору групп или набору пользователей независимо от их группы.
например, CMS может иметь некоторые разрешения, такие как чтение сообщения, создание сообщения, редактирование сообщения. Роль редактора может быть в состоянии читать и редактировать, но не создавать (не знаю, почему!). Пост возможно, вы сможете создавать и читать и т. д. Группа менеджеров может иметь роль редактора, в то время как пользователь в ней, который не входит в группу менеджеров, также может иметь роль редактора, даже если остальная часть его или ее группы этого не делает.
таким образом, хотя в простой системе группы и роли часто тесно связаны, это не всегда так.
Хотя существует семантическая разница между ролями и группами (как описано выше в других ответах), технически роли и группы кажутся одинаковыми. Ничто не мешает вам назначать разрешения непосредственно пользователям и группам (это можно рассматривать как тонкую настройку управления доступом). Аналогично, когда пользователю назначается роль, он может считаться членом роли, в том же смысле, когда пользователь становится членом группы.
таким образом, мы можем в конечном итоге без реальной разницы между Роли и группы. Оба варианта могут быть рассмотрены для группировки пользователей и / или разрешений. Таким образом, различие является только семантическим: - если он семантически используется для группирования разрешений, то это роль; - если он семантически используется для группировки пользователей, то это группа. Технически, нет никакой разницы.
"группа" - это набор пользователей. "Роль" - это набор разрешений. Это значит, что когда группа Альфа включает группу бета, Альфа получает всех пользователей от бета и бета получает все разрешения от Альфа. И наоборот, можно сказать роль бета включает в себя роль альфа и те же выводы будут применимы.
A конкретный пример делает вещи более ясно. Рассмотрим "поддержка клиентов"и" старшая поддержка клиентов". Если вы думаете об этих коллекциях как о группах, тогда ясно, что пользователи поддержки клиентов "включают" старших пользователей поддержки клиентов. Однако, если вы посмотрите на них как на роли, то ясно, что старшие разрешения поддержки клиентов "включают" разрешения поддержки клиентов.
теоретически, вы могли бы просто иметь один тип коллекции. Однако,было бы неоднозначно, если бы вы сказали ,что"коллекция Альфа включает в себя коллекцию бета". В этом случае, вы не можете сказать, если пользователи в альфа-версии находятся в бета-версии (например, роль) или пользователи в бета-версии находятся в альфа-версии (например, группа). Чтобы сделать терминологию, такую как "включает", и визуальные элементы, такие как представления дерева, однозначными, большинство систем rbac требуют, чтобы вы указали, является ли рассматриваемая коллекция "группой" или "ролью", по крайней мере, для обсуждения.
некоторые аналогии может помочь. Оформлена в терминах теория множеств, когда группа "Альфа" является подмножеством группы бета-версии, то разрешения Альфа являются набор бета разрешения. По сравнению с родословная, Если группы подобны дереву потомков, то роли подобны дереву предков.
Примечание-следующие бредни имеют смысл только в том случае, если кто - то пытается навязать безопасность внутри организации-то есть пытается ограничить доступ к информации...
группы являются эмпирическими - они отвечают на вопрос "что". Они "это" в том смысле, что они отражают существующую реальность доступом. Это люди любят группы-они очень буквальны и легко определяются. В конце концов, весь контроль доступа в конечном итоге переходит (как мы все узнали еще в средней школе...) к отвечая на вопрос "к какой группе вы принадлежите?"
роли, однако, более нормативны - они направляют то, что"должно быть". Хорошие менеджеры и HR любят "роли" - они не отвечают-они задать вопрос "почему?"К сожалению, роли также могут быть расплывчатыми и что "нечеткость" может сводить людей с ума.
использовать медицинский пример выше, если роль "врач первичной медико-санитарной помощи" имеет больше прав (т. е. доступ к большему количеству групп), чем роль из "рентгеновского техника", это потому, что люди (менеджеры и HR) решили почему это должно было произойти. В этом смысле они являются "коллективной мудростью" организации.
допустим, врачу предоставляется доступ (членство в группе с доступом) к финансовым записям пациентов. Это, как правило, вне "роли" врача и должны дискуссионный. Таким образом, никто (независимо от того, насколько квалифицирован) не должен иметь полный доступ ко всем группам-это призывает к злоупотреблениям властью. Вот почему "ролевая инженерия" так важна - без нее у вас просто есть групповой доступ, раздаваемый как много конфет. Люди будут собирать (а иногда и Орды) групповой доступ, не обсуждая опасности слишком большой власти.
В заключение, мудрость четко определенных ролей помогает умерить опасности беглого доступа к группе. Любой человек в организации может оспорить доступ к определенной группе. Но как только этот доступ предоставляется, он редко сдается. Ролевая инженерия (наряду с лучшими практиками, такими как четко определенные описания групп и уполномоченные менеджеры доступа к группам) может ограничить конфликты интересов в организации, децентрализовать принятие решений и помочь сделать управление безопасностью более рациональным.
пользователи назначаются на роли в зависимости от ответственности, которую они играют в любой системе. Например, пользователи в роли менеджер по продажам могут выполнять определенные действия, такие как предоставление дополнительной скидки для продукта.
группы используются для "группирования" пользователей или ролей в системе для упрощения управления безопасностью. Например, группа с именем "группа лидерства" может иметь своих членов из менеджеров ролей, директоров и архитекторов и отдельных пользователей, которые также не входят в эти роли. Теперь вы должны иметь возможность назначать определенные привилегии этой группе.
назначение групп и ролей различается в приложениях, но в основном я понял следующее, Группы(набор пользователей) являются статическими, в то время как роли (набор разрешений) являются динамическими с политиками, например, на основе времени от (9 до 6) группа или пользователь могут иметь эту роль, но не это.
предыдущие ответы, все замечательно. Как было заявлено, концепция группы против роли является скорее концептуальной, чем технической. Мы заняли позицию, что группы используются для содержания пользователей (пользователь может быть в более чем одной группе: т. е. Джо находится в группе менеджеров, а также в ИТ-группе [он является менеджером в ней]) и для назначения широких привилегий (т. е. наша система mag card позволяет всем пользователям в ИТ-группе получить доступ к серверной комнате). Роли использовались для добавления привилегий определенным пользователям (т. е. люди в ИТ-группе могут RDP на серверы, но не могут назначать пользователей или изменять разрешения, люди в ИТ-группе с ролью администратора могут назначать пользователей и изменять разрешения). Роли также могут состоять из других ролей (у Джо есть роль администратора для добавления пользователей/привилегий, а также роль DBA для внесения изменений в базу данных СУБД на сервере). Роли могут быть очень конкретными, а также в том, что мы можем сделать отдельные роли пользователей (т. е. JoesRole), которые могут быть очень конкретными для пользователя. Итак, чтобы резюмировать, мы используем Группы для управления пользователями и назначения общих ролей и ролей для управления привилегиями. Это также кумулятивно. Группа, в которой находится пользователь, может иметь назначенные роли (или список доступных ролей), которые дадут очень общие привилегии (т. е. пользователи ИТ-группы имеют роль ServerRDP, которая позволяет им входить на серверы), так что назначается пользователю. Затем любые роли, к которым принадлежит пользователь, будут добавлены в том порядке, в котором они определены с последней ролью, имеющей последнее слово (роли могут разрешать, запрещать или не применять привилегии, чтобы при применении каждой роли она либо переопределяла предыдущие настройки для привилегии, либо не изменяла ее). После применения всех ролей группового и пользовательского уровней для пользователя создается отдельная модель безопасности, которая может использоваться в наших системах для определения доступа и возможностей.
вы можете назначить роль группе. Вы можете назначить пользователя группе, и вы можете назначить роль отдельному пользователю в любой роли пользователя. Значение. Jean Doe может быть в группе SalesDeptartment с ролью off ReportWritter, которая позволяет печатать наши отчеты из SharePoint, но в группе SalesDepartment другие могут не иметь роли Reportwriter. - Другими словами, роли-это особые привилегии внутри назначенных групп. Надеюсь, что это делает любые сцены.
Ура!!!