Co to jest RBAC i kiedy należy go stosować?

Kontrola dostępu oparta na rolach (RBAC) opisuje podejście do bezpieczeństwa systemu, w którym użytkownikom przypisuje się jedną lub więcej odrębnych ról. Przypisane role określają funkcje aplikacji, które są dostępne dla użytkownika.

RBAC to popularny sposób wymuszania ograniczeń dostępu użytkowników, ponieważ umożliwia przyznawanie szczegółowych uprawnień odpowiadających obowiązkom każdej osoby. Wiele systemów wymaga, aby niektórzy użytkownicy mogli tworzyć dane, inni mogli je przeglądać, a administratorzy mieli nieograniczony dostęp. RBAC może spełnić wszystkie te wymagania.

Czym są role RBAC?

Rola RABC to zestaw uprawnień. Uprawnienia to unikalne działania, które użytkownicy mogą wykonywać w systemie. Mogą być tak konkretne, jak potrzebujesz. Twoja baza kodu powinna blokować bezpieczne punkty końcowe z kontrolą uprawnień.

Role łączą uprawnienia, aby ułatwić przypisywanie ich użytkownikom. Oto krótki przykład różnicy między rolą a uprawnieniem:

Uprawnienia

1. Utwórz nowy artykuł.
2. Opublikuj artykuł.
3. Usuń artykuł.

Role

• Autor: Rezolucja 1.
• Redaktor: Rozdzielczość 1 i Rozdzielczość 2.
• Administrator: Wszystkie prawa.

Użytkownicy

• Użytkownik A: Rola autora.
• Użytkownik B: rola redaktora.

Ten model oznacza, że ​​użytkownik A może tylko tworzyć artykuły, podczas gdy użytkownik B może tworzyć i publikować.

W prawdziwej aplikacji możesz mieć znacznie więcej uprawnień. Przypisywanie ich bezpośrednio użytkownikom byłoby żmudne. Koncepcja ról zgrabnie łączy precyzyjną kontrolę uprawnień z jasną definicją odpowiedzialności użytkownika.

Większość implementacji RBAC umożliwia użytkownikom przypisanie dowolnej liczby ról. W razie potrzeby role mogą się nakładać. Jeśli to samo uprawnienie istnieje w dwóch rolach użytkownika, ich konto nadal będzie spełniało kryteria kontroli dostępu w kodzie.

Implementacja RBAC

RBAC może być stosunkowo złożony do wdrożenia w systemie. Musisz ocenić, ile uprawnień potrzebujesz, w jaki sposób zostaną zastosowane oraz w jaki sposób będą tworzone i rozdzielane role wśród użytkowników. Na początek możesz sobie poradzić ze stałą liczbą ról, ale wiele większych aplikacji pozwoli użytkownikom tworzyć własne role dla określonych przypadków użycia.

Przed rozpoczęciem integracji RBAC najlepiej dokładnie zaplanować swoje wymagania. Zawężenie zakresu implementacji tak bardzo, jak to możliwe, może pomóc w zmniejszeniu złożoności. Zacznij od minimum, bez którego Twoja aplikacja nie może działać, a następnie stopniowo dodawaj więcej ról i kontrolek.

Drugą stroną RBAC jest zastosowanie ról do określonego zasobu. Na przykład użytkownik może mieć możliwość przesyłania nowych artykułów do kategorii Blog, ale nie do kategorii Sprawy. Twoja kontrola uprawnień będzie teraz musiała uwzględniać kategorię, z którą użytkownik wchodzi w interakcję. Możesz kontrolować ten przepływ, dynamicznie tworząc nowe uprawnienia dla każdej kategorii i przypisując im przewidywalny identyfikator.

Możesz uprościć sprawdzanie uprawnień, używając zewnętrznego systemu do zarządzania tożsamością i autoryzacją. Oparte na zasadach systemy kontroli dostępu, które obsługują RBAC, takie jak Auth0 i Cerbos , mogą pomóc w skonfigurowaniu złożonej logiki autoryzacji bez wprowadzania zmian w niestandardowym kodzie. Platformy te mogą również oferować łatwiejszy sposób sprawdzania uprawnień związanych z zasobami.

System zewnętrzny jest często przesadą w przypadku małych projektów, które działają z ograniczoną liczbą ról i uprawnień. W takich przypadkach można utworzyć implementację RBAC z wielu tabel bazy danych: jedna kojarzy uprawnienia z rolami, a druga kojarzy role z użytkownikami. Aby sprawdzić, czy użytkownik może wykonać akcję, wyświetl jego role i sprawdź, czy którakolwiek z ról zawiera wymagane uprawnienia.

Wady RBAC

RBAC zapewnia ulepszone zabezpieczenia i bardziej elastyczne uprawnienia, gdy są prawidłowo zaimplementowane. Ma jednak również pewne wady, które należy rozpoznać przed użyciem go do ochrony systemu.

Być może najważniejszą z nich jest łatwość, z jaką aplikacje oparte na RBAC mogą być zaśmiecone nieużywanymi rolami i zduplikowanymi uprawnieniami. Role należy tworzyć tylko wtedy, gdy spełniają nowe wymagania lub odzwierciedlają określone obowiązki użytkownika. Posiadanie zbyt wielu ról utrudni utrzymanie systemu i zmniejszy widoczność przydziałów wymaganych przez każdego użytkownika.

Ważne jest również regularne sprawdzanie dystrybucji ról między użytkownikami. Role powinny być precyzyjne, aby użytkownicy mogli otrzymać minimalny zestaw ról, których potrzebują do pracy. Przydzielenie zbyt wielu ról lub przypisanie zbyt wielu uprawnień w ramach każdej roli może spowodować, że konta staną się nadmiernie uprzywilejowane. Zwiększa to ryzyko dla Twojej aplikacji, jeśli konto zostanie naruszone.

RBAC wymaga również wcześniejszej wiedzy o tym, jak będzie działać Twój system i gdzie są granice między obowiązkami. Próba wdrożenia RBAC bez tego zrozumienia będzie zwykle nieoptymalna, ponieważ Twoje uprawnienia i role będą albo zbyt szerokie, albo żmudnie precyzyjne. Rozmiar i kształt rozwiązania RBAC powinien ogólnie odzwierciedlać sposób działania operacji wewnętrznych.

Streszczenie

Kontrola dostępu oparta na rolach jest jedną z najczęstszych form ograniczania dostępu użytkowników w aplikacjach. Umożliwia skonfigurowanie szczegółowych uprawnień, które są następnie agregowane w role, które można przypisać użytkownikom. Takie podejście zapewnia wysoki stopień elastyczności i dostosowywania, ale może również prowadzić do rozdęcia, jeśli nie będziesz aktywnie sprawdzać, które role są używane.

Alternatywy dla RBAC obejmują listy kontroli dostępu , które działają jako reguły przyznawania lub odmawiania dostępu na podstawie warunków, oraz kontrola dostępu oparta na atrybutach (ABAC) , która zabezpiecza dostęp na podstawie atrybutów żądającego użytkownika. ABAC może zapewnić jeszcze większą elastyczność, gdy użytkownicy mają wiele ról, ale RBAC jest najlepszym wyborem, jeśli chcesz, aby system kontroli dostępu dokładnie reprezentował strukturę Twojej organizacji.