Grupa a rola (jakaś prawdziwa różnica?)

Czy ktoś może mi powiedzieć, jaka jest prawdziwa różnica między grupą a rolą? Od jakiegoś czasu próbuję to rozgryźć i im więcej informacji czytam, tym bardziej mam poczucie, że jest to poruszane tylko po to, aby zmylić ludzi i nie ma żadnej różnicy. Obaj mogą wykonywać swoją pracę. Zawsze używałem grupy do zarządzania użytkownikami i ich prawami dostępu.

Ostatnio natknąłem się na oprogramowanie administracyjne, w którym jest garstka użytkowników. Każdy użytkownik może mieć przypisany moduł (cały system jest podzielony na kilka części zwanych modułami tj. Moduł Administracja, Ankieta, Zamówienia, Klient). Oprócz tego każdy moduł ma listę funkcjonalności, które można zezwolić lub zabronić każdemu użytkownikowi. Powiedzmy, że użytkownik John Smith ma dostęp do modułu Zamówienia i może edytować dowolne zamówienie, ale nie ma prawa do usunięcia żadnego z nich.

Gdyby było więcej użytkowników z tą samą kompetencją, użyłbym grupy do zarządzania tym. Gromadziłbym takich użytkowników w tę samą grupę i przypisywałbym prawa dostępu do modułów i ich funkcji grupie. Wszyscy użytkownicy w tej samej grupie mieliby takie same prawa dostępu.

Po co nazywać to grupą, a nie rolą? Nie wiem, po prostu tak to czuję. Wydaje mi się, że to po prostu nie ma znaczenia:] Ale nadal chciałbym poznać prawdziwą różnicę.

Jakieś sugestie, dlaczego należałoby to raczej nazwać rolą niż grupą lub odwrotnie?

Google to twój przyjaciel :)

W każdym razie podział na rolę i grupę wynika z koncepcji bezpieczeństwa komputerowego (w przeciwieństwie do prostego zarządzania zasobami). Prof. Ravi Sandhu przedstawia przełomowe omówienie semantycznej różnicy między rolami a grupami.

http://profsandhu.com/workshop/role-group.pdf

Grupa to zbiór użytkowników z określonym zestawem uprawnień przypisanych do grupy (i przejściowo do użytkowników). Rola to zbiór uprawnień, a użytkownik skutecznie dziedziczy te uprawnienia, gdy działa w ramach tej roli.

Zazwyczaj członkostwo w grupie pozostaje w trakcie logowania. Z drugiej strony rolę można aktywować zgodnie z określonymi warunkami. Jeśli Twoja obecna rola to „personel medyczny”, możesz mieć możliwość wglądu do niektórych dokumentów medycznych danego pacjenta. Jeśli jednak Twoja rola jest również „lekarzem”, możesz zobaczyć dodatkowe informacje medyczne poza tym, co widzi osoba pełniąca tylko rolę „personelu medycznego”.

Role można aktywować według pory dnia, lokalizacji dostępu. Role można również ulepszyć / powiązać z atrybutami. Możesz działać jako „lekarz”, ale jeśli nie masz atrybutu „lekarza pierwszego kontaktu” lub relacji ze mną (użytkownik pełniący rolę „pacjenta”), nie możesz zobaczyć całej mojej historii medycznej.

Możesz to wszystko zrobić z grupami, ale znowu grupy mają tendencję do skupiania się na tożsamości, a nie na roli czy działaniu. A właśnie opisane aspekty bezpieczeństwa mają tendencję do lepszego dostosowywania się do późniejszych niż do poprzednich.

W wielu przypadkach, przy klasyfikowaniu rzeczy razem (i nic więcej), grupy i role funkcjonują tak samo. Jednak grupy opierają się na tożsamości, podczas gdy role mają na celu rozgraniczenie aktywności. Niestety systemy operacyjne mają tendencję do zacierania tej różnicy, traktując role jako grupy.

Widzisz znacznie wyraźniejsze rozróżnienie między rolami na poziomie aplikacji lub systemu - przenoszącymi semantykę specyficzną dla aplikacji lub systemu (jak w przypadku ról Oracle ) - w przeciwieństwie do `` ról '' realizowanych na poziomie systemu operacyjnego (które są zwykle synonimami grup).

Mogą istnieć ograniczenia dotyczące ról i modeli kontroli dostępu opartych na rolach (jak wszystko oczywiście):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

Około dekady temu widziałem badania dotyczące kontroli dostępu opartej na atrybutach i relacjach, które zapewniają znacznie lepszą szczegółowość niż kontrola dostępu oparta na rolach. Niestety od lat nie widziałem dużej aktywności w tym królestwie.

Najważniejsza różnica między rolami a grupami polega na tym, że role zazwyczaj implementują mechanizm obowiązkowej kontroli dostępu (MAC). Nie możesz przypisywać sobie (ani innym) ról. Robi to administrator roli lub inżynier roli.

Jest to powierzchownie podobne do grup UNIX, w których użytkownik może / mógłby być w stanie przypisać się do grupy (oczywiście przez sudo). Kiedy grupy są przypisywane zgodnie z procesem inżynierii bezpieczeństwa, różnica ta jednak nieco się zaciera.

Inną ważną cechą jest to, że prawdziwe modele RBAC mogą zapewnić koncepcję wzajemnie wykluczających się ról. Natomiast grupy oparte na tożsamości są addytywne - tożsamość pryncypała jest sumą (lub koniunkcją) grup.

Inną cechą charakterystyczną modelu zabezpieczeń opartego na prawdziwym RBAC jest to, że do elementów utworzonych dla określonej roli zazwyczaj nie ma dostępu przechodniego osoba, która nie działa w tej roli.

Z drugiej strony w modelu dyskrecjonalnej kontroli dostępu (DAC) (model domyślny w systemie Unix) nie można uzyskać tego typu gwarancji w przypadku samych grup. BTW, to nie jest ograniczenie grup lub Unix, ale ograniczenie modeli DAC opartych na tożsamości (i przejściowo, z grupami opartymi na tożsamości).

Mam nadzieję, że to pomoże.

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

Dodanie więcej po obejrzeniu dobrze ułożonej odpowiedzi Simona. Role pomagają w zarządzaniu uprawnieniami. Grupy pomagają zarządzać obiektami i tematami. Co więcej, można by pomyśleć o rolach jako o „kontekstach”. Rola „X” może opisywać kontekst bezpieczeństwa, który reguluje sposób, w jaki podmiot Y uzyskuje dostęp (lub nie ma dostępu) do obiektu Z.

Innym ważnym rozróżnieniem (lub ideałem) jest to, że istnieje inżynier roli, osoba, która projektuje role, konteksty, które są niezbędne i / lub widoczne w aplikacji, systemie lub systemie operacyjnym. Inżynier roli zazwyczaj jest (ale nie musi) także administratorem roli (lub sysadminem). Co więcej, prawdziwa rola inżyniera roli (gra słów nie jest zamierzona) dotyczy inżynierii bezpieczeństwa, a nie administracji.

Jest to nowa grupa sformalizowana przez RBAC (nawet jeśli rzadko jest używana), która zwykle nie była obecna w systemach obsługujących grupy.

Grupa jest sposobem organizowania użytkowników, podczas gdy rola jest zwykle sposobem organizowania praw.

Może to być przydatne na wiele sposobów. Na przykład zestaw uprawnień zgrupowanych według roli można przypisać do zestawu grup lub zestawu użytkowników niezależnie od ich grupy.

Na przykład CMS może mieć pewne uprawnienia, takie jak Czytaj post, Utwórz post, Edytuj post. Rola redaktora może mieć możliwość odczytu i edycji, ale nie może tworzyć (nie wiem dlaczego!). Post może być w stanie tworzyć i czytać itp. Grupa menedżerów może mieć rolę redaktora, podczas gdy użytkownik w IT, który nie należy do grupy menedżerów, może również pełnić rolę redaktora, nawet jeśli reszta jego lub jej grupa nie.

Tak więc, chociaż w prostym systemie grupy i role są często ściśle dopasowane, nie zawsze tak jest.

Chociaż istnieje różnica semantyczna między rolami a grupami (jak opisano powyżej w innych odpowiedziach), pod względem technicznym role i grupy wydają się być takie same. Nic nie stoi na przeszkodzie, aby przypisać uprawnienia bezpośrednio do użytkowników i grup (można to uznać za precyzyjną kontrolę dostępu). Równocześnie, gdy użytkownikowi przypisano rolę, można ją uznać za członka roli, w tym samym sensie, gdy użytkownik staje się członkiem grupy.

Więc możemy skończyć bez rzeczywistej różnicy między rolami a grupami. Oba można rozważać przy grupowaniu użytkowników ORAZ / LUB uprawnień. Zatem różnica jest tylko semantyczna: - jeśli jest semantycznie używana do grupowania uprawnień, to jest rolą; - jeśli jest semantycznie używany do grupowania użytkowników, jest to grupa. Technicznie nie ma różnicy.

„Grupa” to zbiór użytkowników. „Rola” to zbiór uprawnień. Oznacza to, że gdy grupa alfa obejmuje grupę beta , alfa otrzymuje wszystkich użytkowników z wersji beta, a beta otrzymuje wszystkie uprawnienia od wersji alfa. I odwrotnie, można powiedzieć, że rola beta obejmuje rolę alfa i miałyby zastosowanie te same wnioski.

Przykład betonu sprawia, że rzeczy bardziej jasne. Rozważ „obsługę klienta” i „obsługę klienta wyższego szczebla”. Jeśli myślisz o tych kolekcjach jako o grupach, to jasne jest, że użytkownicy obsługi klienta „obejmują” starszych użytkowników obsługi klienta. Jeśli jednak spojrzysz na te role jako na role, jasne jest, że uprawnienia starszego działu obsługi klienta „obejmują” uprawnienia obsługi klienta.

Teoretycznie możesz po prostu mieć jeden typ kolekcji. Jednak byłoby niejednoznaczne, gdybyś powiedział, że „kolekcja alfa obejmuje kolekcję beta” . W takim przypadku nie można stwierdzić, czy użytkownicy w wersji alfa są w wersji beta (jak rola), czy też użytkownicy w wersji beta (jak grupa). Aby terminologia taka jak „zawiera” i elementy wizualne, takie jak widoki drzewa, były jednoznaczne, większość systemów RBAC wymaga określenia, czy dana kolekcja jest „grupą” czy „rolą”, przynajmniej na potrzeby dyskusji.

Pomóc mogą pewne analogie . Ujęte w ramach teorii zbiorów , kiedy grupa alfa jest podzbiorem grupy beta, wtedy uprawnienia alfa są nadzbiorem uprawnień beta. W porównaniu z genealogią , jeśli grupy są jak drzewo potomków, wtedy role są jak drzewo przodków.

UWAGA - poniższe błądzenia mają sens tylko wtedy, gdy próbuje się narzucić bezpieczeństwo w organizacji - to znaczy próbując ograniczyć dostęp do informacji ...

Grupy mają charakter empiryczny - odpowiadają na pytanie „co”. Są „jest” w tym sensie, że odzwierciedlają istniejącą rzeczywistość dostępu. Informatycy uwielbiają grupy - są bardzo dosłowne i łatwe do zdefiniowania. Ostatecznie cała kontrola dostępu ostatecznie sprowadza się (jak wszyscy nauczyliśmy się w gimnazjum ...) do odpowiedzi na pytanie „Do jakiej grupy należysz?”

Role są jednak bardziej normatywne - kierują tym, co „powinno być”. Dobrzy menedżerowie i HR uwielbiają „role” - nie odpowiadają - zadają pytanie „Dlaczego?” Niestety role mogą być również niejasne, a „niejasność” może doprowadzić ludzi (IT) do szału.

Aby skorzystać z powyższego przykładu medycznego, jeśli rola od „lekarza pierwszego kontaktu” ma więcej praw (czyli dostęp do większej ilości grup) niż rola wystąpienia „technika rentgenowskiej”, to dlatego, że ludzie (menedżerów i HR) postanowił dlatego , że musiało się wydarzyć. W tym sensie są „zbiorową mądrością” organizacji.

Powiedzmy, że lekarz ma dostęp (członkostwo w grupie z dostępem) do dokumentacji finansowej pacjentów. Zwykle wykracza to poza „rolę” lekarza i powinno być przedmiotem dyskusji. Tak więc nikt (bez względu na kwalifikacje) nie powinien mieć pełnego dostępu do wszystkich grup - zaprasza to nadużycia do władzy. Dlatego tak ważna jest „inżynieria ról” - bez niej dostęp grupowy jest wręczany jak wiele cukierków. Ludzie będą gromadzić (a czasem hordy) dostęp do grupy bez dyskusji na temat niebezpieczeństw związanych z nadmierną władzą.

Podsumowując, mądrość dobrze zdefiniowanych ról pomaga złagodzić niebezpieczeństwa związane z ucieczką grupową. Każdy w organizacji może argumentować o dostęp do określonej grupy. Ale gdy ten dostęp zostanie zapewniony, rzadko się go rezygnuje. Inżynieria ról (wraz z najlepszymi praktykami, takimi jak dobrze zdefiniowane opisy grup i upoważnieni menedżerowie dostępu do grup) może ograniczyć konflikty interesów w organizacji, zdecentralizować podejmowanie decyzji i pomóc uczynić zarządzanie bezpieczeństwem bardziej racjonalnym.

Wszystkie poprzednie odpowiedzi są wspaniałe. Jak już powiedziano, koncepcja Grupa vs rola jest bardziej koncepcyjna niż techniczna. Przyjęliśmy stanowisko, że Grupy są używane do przechowywania użytkowników (użytkownik może być w więcej niż jednej grupie, tj. Joe jest w grupie Menedżerów, jak również w grupie IT [jest menedżerem w IT]) i do przypisywania szerokich uprawnień (tj. nasz system kart mag pozwala wszystkim użytkownikom z grupy IT na dostęp do serwerowni). Role były teraz używane do dodawania uprawnień do określonych użytkowników (tj. Osoby z grupy IT mogą RDP do serwerów, ale nie mogą przypisywać użytkowników ani zmieniać uprawnień, osoby w grupie IT z rolą Admin mogą przypisywać użytkowników i zmieniać uprawnienia). Role mogą również składać się z innych ról (Joe ma rolę administratora, aby dodawać użytkowników / uprawnienia, a także ma rolę DBA, aby dokonywać zmian w bazie danych w DBMS na serwerze). Role mogą być również bardzo specyficzne, ponieważ możemy tworzyć indywidualne role użytkowników (np. JoesRole), które mogą być bardzo specyficzne dla użytkownika. Podsumowując, używamy grup do zarządzania użytkownikami i przypisywania ogólnych ról i ról do zarządzania uprawnieniami. To również się kumuluje. Grupa, w której znajduje się użytkownik, może mieć przypisane role (lub listę dostępnych ról), które dają bardzo ogólne uprawnienia (tj. Użytkownicy grupy IT mają rolę ServerRDP, która pozwala im logować się na serwery), więc jest ona przypisana do użytkownika. Następnie wszystkie role, do których należy użytkownik, zostaną dodane w kolejności, w jakiej zostały zdefiniowane, z ostatnią rolą mającą ostatnie słowo (Role mogą zezwalać, odmawiać lub nie stosować uprawnień, tak aby każda rola została zastosowana, nadpisuje poprzednie ustawienia uprawnienia lub nie zmieniać). Po zastosowaniu wszystkich ról na poziomie grupy i ról użytkownika,

Użytkownicy są przypisywani do Ról na podstawie odpowiedzialności, jaką odgrywają w dowolnym systemie. Na przykład użytkownicy pełniący rolę Sales Manager mogą wykonywać określone czynności, takie jak udzielanie dodatkowego rabatu na produkt.

Grupy służą do „grupowania” użytkowników lub ról w systemie w celu łatwego zarządzania bezpieczeństwem. Na przykład grupa o nazwie „Grupa przywódcza” może mieć swoich członków z ról menedżerów, dyrektorów i architektów oraz indywidualnych użytkowników, którzy również nie pełnią tych ról. Teraz powinieneś móc przypisać określone uprawnienia tej grupie.

Cel grup i ról różni się w aplikacjach, ale przede wszystkim rozumiem to następująco: grupy (zestaw użytkowników) są statyczne, podczas gdy role (zestaw uprawnień) są dynamiczne z politykami, na przykład na podstawie czasu od (9 do 6) a grupa lub użytkownik może mieć tę rolę, ale nie tę.

Możesz przypisać rolę do grupy. Możesz przypisać użytkownika do grupy i przypisać role poszczególnym użytkownikom w dowolnej roli użytkownika. Znaczenie. Jean Doe może być w Grupie Działu Sprzedaży z rolą poza ReportWritter, co pozwala na drukowanie naszych raportów z SharePoint, ale w grupie Dział Sprzedaży inni mogą nie pełnić roli ReportWrittera. - Innymi słowy, role to specjalne uprawnienia związane z przypisanymi grupami. Mam nadzieję, że to tworzy jakieś sceny.

Twoje zdrowie!!!