Jak zaprojektować kontrolę dostępu opartą na rolach?

15

Próbuję podążać za modelem kontroli dostępu opartym na rolach, aby ograniczyć to, co użytkownicy mogą lub nie mogą robić w moim systemie.

Do tej pory mam następujące podmioty:

users - Ludzie, którzy będą korzystać z systemu. Tutaj mam nazwy użytkownika i hasła. role - zbiór ról, które mogą mieć użytkownicy. Rzeczy takie jak zasoby menedżera, administratora itp. - Rzeczy, którymi użytkownicy mogą manipulować. Jak kontrakty, użytkowników, przeciągi kontraktowy itp operacje - rzeczy, które użytkownik może zrobić z zasobów. Jak tworzyć, czytać, aktualizować lub usuwać.

Teraz moje wątpliwości pojawiają się tutaj na schemacie, na którym mam taką relację:

operacje (0 .. *) są wykonywane na zasobach (0 .. *), które generują tabelę, którą nazwałem uprawnieniami, i która przechowuje operację i zasób .

Tabela uprawnień będzie wyglądać następująco (jeden wiersz): ID: 1, operacja: tworzenie, zasób: umowa.

Co oznacza uprawnienie do tworzenia się kontrakt .

Zrobiłem to w ten sposób, ponieważ uważam, że niektóre zasoby mogą nie mieć wszelkiego rodzaju operacji. Na przykład w celu zarejestrowania umów użytkownicy mogą przesyłać pliki , ale ta operacja nie jest dostępna w celu rejestracji dostawcy .

Dlatego teraz, gdy administrator będzie udzielał uprawnień do roli , nie będzie miał listy zasobów z każdą zarejestrowaną operacją w systemie.

Myślę, że każdy zasób ma własną kolekcję operacji, które można na nim wykonać.

Mogę wyjaśnić, czy coś nie jest zrozumiałe.

Czy to jest właściwy sposób na wdrożenie RBAC?

EDYTOWAĆ

Mam na myśli to, że mając tabelę uprawnień zawierającą operacje i zasoby , mam DWIE dodatkowe tabele, ponieważ chcę powiązać zasoby z operacjami . Mógłbym także zrobić zasoby, które mają uprawnienia, w których tabela uprawnień przechowywałaby uprawnienia.

Ale wtedy stałoby się tak, że niektóre uprawnienia, które nawet nie istnieją dla niektórych zasobów, pojawiałyby się, gdy administrator je przypisywał.

Więc chcę wiedzieć z punktu widzenia projektu bazy danych, czy to uprawnienie do tabeli, które ma operację na jednej kolumnie i inny zasób jest poprawne? Czy napotkam problemy, jeśli tak pozostanie?

imran.razak
źródło
2
Co rozumiesz przez „prawidłowe”? Uwaga: nie odpowiadaj tautologią typu „najlepsza praktyka”. Podaj swoje specyficzne wymagania.
Robert Harvey,
1
Moja definicja „poprawnej” to zazwyczaj „ta, która najskuteczniej spełnia funkcjonalne i niefunkcjonalne wymagania twojego oprogramowania”. Należy pamiętać, że NIST oferuje szczegółowe wytyczne i najlepsze praktyki dotyczące bezpieczeństwa opartego na rolach. Zobacz csrc.nist.gov/groups/SNS/rbac
Robert Harvey
Być może zainteresuje Cię, jak to się robi w projekcie Pundit .
Antarr Byrd
1
Powinieneś rozważyć użycie biblioteki do tego.
RibaldEddie
Istnieje wiele bibliotek, które wykonają dla ciebie RBAC lub ABAC
David Brossard

Odpowiedzi:

11

Twój projekt wydaje mi się bardzo bliski. Tylko kilka sugestii.

users - Ludzie, którzy będą korzystać z systemu. Tutaj mam nazwy użytkownika i hasła.

W porządku

role - zbiór ról, które mogą mieć użytkownicy. Rzeczy takie jak menedżer, administrator itp.

Też dobrze. Ale będziesz także potrzebował encji / tabeli „UserRoles”, która powie ci, którzy użytkownicy pełnią role. Prawdopodobnie dany użytkownik może mieć dwie lub więcej ról.

zasoby - rzeczy, którymi użytkownicy mogą manipulować. Podobnie jak umowy, użytkownicy, projekty umów itp.

Może to być tylko kwestia semantyki. Nie sądzę, aby użytkownicy bezpośrednio manipulowali zasobami; role robią. W ten sposób przechodzi użytkownik -> rola użytkownika -> rola -> operacja -> zasób

operacje - rzeczy, które użytkownicy mogą zrobić z zasobami. Jak tworzyć, czytać, aktualizować lub usuwać.

tak, z wyjątkiem „ról” zamiast „użytkowników”

Tabela uprawnień będzie wyglądać następująco (jeden wiersz): ID: 1, operacja: tworzenie, zasób: umowa. Co oznacza pozwolenie na utworzenie umowy.

Hmmm. Można to zrobić na dwa sposoby. Możesz mieć opisaną tabelę uprawnień, ale potrzebujesz także dodatkowej RolePermissionstabeli / encji, która powie ci, która rola ma uprawnienia. Ale nie jestem pewien, czy jest to konieczne.

Prostszym sposobem na to jest tabela uprawnień / jednostka z następującymi kolumnami / atrybutami: identyfikator roli, identyfikator operacji, identyfikator zasobu. W ten sposób operacje x kombinacje zasobów są przypisywane bezpośrednio do roli, a nie ładowane do uprawnienia przypisanego do roli. Eliminuje jeden byt. Naprawdę nie ma potrzeby oddzielnej tabeli uprawnień niezależnych od roli, chyba że chcesz wstępnie zdefiniować, które kombinacje uprawnień są dozwolone, a które nie.

John Wu
źródło
Przede wszystkim całkowicie zgadzam się z korektą „ról” zamiast „użytkowników”. To też miałem na myśli. Chodzi mi o to, że chcę również kojarzyć zasoby z operacjami. Na przykład: zasób kontraktu ma operację taką jak upload_file. Więc nie chcę, aby operacja upload_file pojawiała się również w innym zasobie, który nie ma operacji upload_file, takiej jak dostawcy (inny zasób), gdy administrator przypisuje uprawnienia do roli.
imran.razak
13

Nie używałbym ani nie implementował RBAC. Zamiast tego użyłbym ABAC. Pozwól mi wyjaśnić...

  • RBAC lub kontrola dostępu oparta na rolach dotyczy zarządzania użytkownikami i przypisywania ról. W RBAC możesz powiedzieć, że Alice jest menedżerem. Jednocześnie możesz zdefiniować uprawnienia statyczne. Na przykład kierownik może zatwierdzać pożyczki. Jest więc link od Alicji do menedżera, aby zatwierdzić Loan jako pozwolenie. Istnieje wiele systemów, które pozwolą ci to zrobić, więc nie musisz implementować własnych tabel. Nawet LDAP obsługuje ograniczone zestawy RBAC. Jest to w porządku, o ile masz stosunkowo niewielki zestaw ról i uprawnień. Ale co, jeśli chcesz wziąć pod uwagę określone uprawnienia, tak jak w twoim przypadku? Wyświetl, usuń, wstaw? Co jeśli chcesz wziąć pod uwagę relacje?
  • ABAC lub kontrola dostępu oparta na atrybutach dotyczy precyzyjnej autoryzacji opartej na zasadach. Za pomocą ABAC możesz używać ról zdefiniowanych w RBAC i zapisywać polityki np
    • Menedżerowie mogą przeglądać dokumenty w swoim dziale
    • Pracownicy mogą edytować posiadane dokumenty

W swoim pytaniu zasadniczo zdefiniowałeś model informacyjny. Twoje obiekty i ich atrybuty, np. Użytkownik (nazwa, hasło, dział ...); przedmiot (np. umowa) i tak dalej.

Model informacyjny

W ABAC całkowicie oddzielisz kod / logikę aplikacji od logiki autoryzacji, która jest następnie przechowywana jako zasady przy użyciu atrybutów. Same uprawnienia są przechowywane bezpośrednio w zasadach (patrz przykład powyżej). Architektura wdrażania ABAC wygląda następująco

Architektura kontroli dostępu oparta na atrybutach

Chodzi o to, że jeśli podejmiesz podejście ABAC, napiszesz zasady dla ABAC (w XACML lub ALFA - jest do tego mnóstwo narzędzi) i nigdy nie będziesz musiał ponownie tworzyć niestandardowego kodu RBAC ani kontroli dostępu.

David Brossard
źródło
1
W przykładzie zasad jest napisane, że menedżerowie mogą przeglądać dokumenty w swoich działach. Czy to oznacza, że ​​system będzie już miał predefiniowane uprawnienia, role i typy zasobów?
imran.razak
Nie. Oznacza to, że miałbyś coś (LDAP? Tabela?), Która łączy użytkownika (Alice) z jej rolami (menedżerem ...). Otrzymasz wtedy tabelę, która zawiera metadane dokumentu (zazwyczaj jest to tabela w chronionej aplikacji). Samo uprawnienie (przeglądaj, edytuj, usuwaj) jest przechowywane w polityce.
David Brossard,