Група проти ролі (Є реальна різниця?)

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

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

Якби було більше користувачів з однаковою компетенцією, я використовував би групу для управління цим. Я б об'єднав таких користувачів в одну групу і призначив права доступу до модулів та їх функцій для групи. Усі користувачі однієї групи мали б однакові права доступу.

Чому це називають групою, а не роллю? Я не знаю, я просто так відчуваю. Мені здається, це просто не має значення:] Але я все ж хотів би дізнатися справжню різницю.

Будь-які пропозиції, чому це слід радше називати рольовим, ніж груповим чи навпаки?

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, полягає в тому, що елементи, створені для певної ролі, як правило, не можуть переходити транзитивно тим, хто не діє за цією роллю.

З іншого боку, за допомогою дискреційної моделі контролю доступу (ЦАП) (модель за замовчуванням в Unix) ви не можете отримати такий тип гарантії лише з групами. До речі, це не обмеження груп або Unix, а обмеження моделей ЦАП, заснованих на ідентичності (і транзитивно, з групами на основі ідентичності.)

Сподіваюся, це допомагає.

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

Додавши ще трохи, побачивши добре поставлену відповідь Саймона. Ролі допомагають керувати дозволами. Групи допомагають керувати об’єктами та предметами. Більше того, можна вважати ролі «контекстами». Роль 'X' може описати контекст безпеки, який визначає, як суб'єкт Y отримує доступ (або не має доступу) до об'єкта Z.

Ще одна важлива відмінність (або ідеал) полягає в тому, що є інженер-роль, людина, яка розробляє ролі, контексти, які необхідні та / або очевидні в додатку, системі чи ОС. Інженер ролей, як правило, є (але не повинен бути) також адміністратором ролей (або sysadmin). Більше того, справжня роль (не призначена для каламбура) інженера ролей полягає у царині інженерії безпеки, а не в адміністрації.

Це нова група, формалізована RBAC (навіть якщо вона рідко використовується), яка, як правило, не присутня в групових системах.

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

Це може бути корисно кількома способами. Наприклад, набір дозволів, згрупованих у роль, може бути призначений набору груп або набору користувачів незалежно від їх групи.

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

Тож, хоча в простій системі групи і ролі часто тісно узгоджуються, це не завжди так.

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

Таким чином, ми не можемо реально змінити ролі та групи. Обидва можна розглядати як групування користувачів І / АБО Дозволів. Таким чином, різниця є лише семантичною: - якщо вона семантично використовується для групування дозволів, то вона є роллю; - якщо він семантично використовується для групування Користувачів, то це Група. Технічно різниці немає.

"Група" - це сукупність користувачів. "Роль" - це сукупність дозволів. Це означає, що коли група альфа включає групову бета-версію , альфа отримує всіх користувачів від бета-версії, а бета-версія отримує всі дозволи від альфа. І навпаки, можна сказати, що бета-роль включає рольову альфа, і такі ж висновки будуть застосовані.

Приклад бетону робить речі більш ясно. Розгляньте "підтримку клієнтів" та "підтримку старшого клієнта". Якщо ви розглядаєте ці колекції як групи, то зрозуміло, що серед користувачів із обслуговування клієнтів "входять" старші користувачі служби підтримки. Однак якщо ви дивитесь на них як на ролі, то зрозуміло, що дозвіл на підтримку старшого клієнта "включає" дозволи на підтримку клієнтів.

Теоретично у вас може бути просто один тип колекції. Однак було б неоднозначно, якби ви сказали, що "колекційна альфа включає колекцію бета" . У такому випадку ви не можете визначити, чи користувачі альфа в бета-версії (на зразок ролі) чи користувачі в бета-версії в альфа (як група). Для того, щоб зробити термінологію на кшталт "включає" та візуальні елементи, такі як перегляди дерев, однозначно, більшість систем rbac вимагає вказати, чи є спірний збірник "групою" чи "роллю" хоча б заради обговорення.

Деякі аналогії можуть допомогти. Сформульована з точки зору теорії множин , коли група альфа є підмножиною групової бета-версії, то альфа-дозволи мають надмножину бета-версії дозволів. Якщо порівнювати з генеалогією , якщо групи схожі на дерево нащадків, то ролі - як дерево предків.

ПРИМІТКА. Наступні міркування мають сенс лише в тому випадку, якщо хтось намагається нав'язати безпеку в організації - тобто намагається обмежити доступ до інформації ...

Групи емпіричні - вони відповідають на питання "що". Вони є "є" в тому сенсі, що вони відображають існуючу реальність доступу. ІТ-люди люблять групи - їх дуже буквально і легко визначити. Зрештою, весь контроль доступу в кінцевому рахунку переходить (як ми всі дізналися ще в середній школі ...) на відповідь на запитання "До якої групи ви належите?"

Ролі, однак, є більш нормативними - вони керуються тим, що "повинно бути". Хороші менеджери та HR люблять "ролі" - вони не відповідають - вони задають питання "Чому?" На жаль, ролі також можуть бути невиразними, і що "нечіткість" може заганяти (ІТ) людей.

Використовувати вищезазначений медичний приклад, якщо роль "лікаря первинної медичної допомоги" має більше прав (тобто доступ до більшої кількості груп), ніж роль "рентгенівського лікаря ", це тому, що люди (керівники та кадровий персонал) вирішили, чому це потрібно було статися. У цьому сенсі вони є "колективною мудрістю" організації.

Скажімо, лікарем надається доступ (членство в групі з доступом) до фінансових записів пацієнтів. Це, як правило, поза "роллю" лікаря, і має бути обговорено. Отже, ніхто (незалежно від того, наскільки кваліфікований) не повинен мати повний доступ до всіх груп - це запрошує зловживання владою. Ось чому «інженерія ролей» настільки важлива - без цього вам просто надається груповий доступ, як стільки цукерок. Люди збиратимуть (а іноді й ординський) груповий доступ, не обговорюючи небезпеки занадто великої сили.

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

Попередні відповіді - чудові. Як було зазначено, концепція групи проти ролі є більш концептуальною, ніж технічною. Ми прийняли позицію, що Групи використовуються для утримання користувачів (користувач може бути в більш ніж одній групі: тобто Джо є в групі менеджерів, а також ІТ-групі (він менеджер в галузі ІТ)) і для призначення широких привілеїв (тобто наша система mag-карт дозволяє всім користувачам ІТ-групи доступ до серверної кімнати). Тепер ролі використовувались для додавання привілеїв певним користувачам (наприклад, люди в ІТ-групі можуть RDP на сервери, але не можуть призначити користувачів або змінити дозволи. Люди з ІТ-групи з роллю адміністратора можуть призначати користувачів та змінювати дозволи). Ролі можуть складатися з інших ролей (Джо має роль адміністратора для додавання користувачів / привілеїв, а також має роль DBA для зміни баз даних у СУБД на сервері). Ролі можуть бути дуже специфічними, оскільки ми можемо скласти індивідуальні ролі користувача (тобто JoesRole), які можуть бути дуже специфічними для користувача. Отже, для резюме, ми використовуємо Групи для управління користувачами та присвоюємо загальні ролі та ролі для управління привілеями. Це також є кумулятивним. Групі, в якій є користувач, можуть бути призначені ролі (або список доступних ролей), які даватимуть дуже загальні привілеї (тобто користувачі ІТ-групи мають роль ServerRDP, яка дозволяє їм входити на сервери), так що присвоюється користувачеві. Тоді будь-які Ролі, до яких належить користувач, будуть додані в порядку, визначеному з останньою Роллю, яка має остаточне слово (Ролі можуть дозволяти, забороняти чи не застосовувати привілеї, так що при застосуванні кожної ролі вона або перекриє попередні налаштування для привілею або не змінювати його). Після застосування всіх ролей на рівні групи та ролей на рівні користувача,

Користувачі присвоюються ролям на основі відповідальності, яку вони виконують у будь-якій системі. Наприклад, користувачі в ролі менеджера з продажу можуть виконувати певні дії, такі як надання додаткової знижки на продукт.

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

Призначення груп і ролей відрізняється у різних додатках, але, головним чином, я розумію, як це слідувати, Групи (набір користувачів) є статичними, тоді як Ролі (набір дозволів) динамічні з політикою, наприклад на основі часу від (9 до 6). група чи користувач можуть виконувати цю роль, але не таку.

Ви можете призначити роль групі. Ви можете призначити користувача групі, а ви можете призначити роль окремому користувачеві будь-якому користувачеві ролі. Значення. Жан До може бути в групі SalesDeptartment з роллю ReportWritter, що дозволяє друкувати наші звіти з SharePoint, але в групі SalesDepartment інші можуть не мати ролі ReportWritter. - Іншими словами, ролі - це спеціальні привілеї, призначені для призначених груп. Сподіваюся, що це робить будь-які сцени.

Ура !!!