W ciągu ostatnich kilku lat kontrola dostępu oparta na rolach (RBAC) była uważana za synonim autoryzacji na poziomie aplikacji. Jest to tak powszechne, że programiści od niechcenia opisują swoją usługę autoryzacji jako “usługę RBAC”, a CTO opisują ją jako “rzecz, którą w pewnym momencie wdrożymy”.

Z drugiej strony, aplikacje stają się coraz bardziej złożone, a w większości przypadków prosta implementacja RBAC po prostu nie wystarcza. Czy to oznacza, że RBAC odchodzi do lamusa? Czy powinni Państwo rozpocząć poszukiwania nowszych modeli? Na tym blogu omówimy wszystko, co powinni Państwo wiedzieć o korzystaniu z RBAC w 2024 roku.

Czym jest RBAC?

Zanim zagłębimy się w temat, zróbmy krótkie podsumowanie. RBAC to model autoryzacji używany do określania dostępu na podstawie predefiniowanych ról. Uprawnienia są przypisane do ról (takich jak “Administrator” lub “Użytkownik”), a role są przypisane do użytkowników. Ta struktura pozwala łatwo zrozumieć, kto ma dostęp do czego. Połączenie tego, kto (jaka tożsamość i jaka rola są przypisane?) może robić co (jakie działania mogą wykonywać?) z zasobem (w jakich aspektach oprogramowania?) nazywane jest polityką.

Jakie są zalety RBAC?

Główną zaletą RBAC jest jego prostoty. Kategoryzując użytkowników na role i przypisując uprawnienia do tych ról, RBAC tworzy system, który jest łatwy i zrozumiały zarówno dla programistów, jak i użytkowników.

Dla deweloperaRBAC oddziela relację między użytkownikami a potrzebnymi im uprawnieniami. Zamiast jawnie przypisywać uprawnienia do użytkownika i stosować je do różnych zasobów w systemie, przypisujemy uprawnienia do ról i role do użytkowników. Oznacza to, że gdy chcemy dodać więcej uprawnień, możemy dodać je do roli zamiast ręcznie dodawać je do poszczególnych użytkowników. Oznacza to łatwe zarządzanie i audyt.

Dla użytkownikaRBAC sprawia, że uprawnienia aplikacji są łatwe do zrozumienia, a użytkownicy nie muszą skupiać się na tym, jak aplikacja jest zbudowana, ale raczej na własnych rolach. Wiedza o tym, czy jest się standardowym użytkownikiem, czy administratorem, jest znacznie prostszym sposobem na zrozumienie uprawnień posiadanych w aplikacji (w przeciwieństwie do ACL i innych, starszych modeli, które były powszechne przed popularnością RBAC).

Kiedy RBAC to za mało?

Choć RBAC może być prosty, ta prostota ma swoją cenę, a RBAC nie działa, gdy potrzebne jest bardziej szczegółowe podejście. Podejście RBAC skoncentrowane na użytkowniku sprawia, że użytkownik jest jedynym dynamicznym elementem polityki. Oznacza to, że jeśli chcemy uzyskać bardziej dynamiczne i szczegółowe polityki, takie jak na przykład, gdzie atrybuty zasobów stale się zmieniają, RBAC okazuje się niewystarczający. Problem ten dotyczy większości nowoczesnych aplikacji, biorąc pod uwagę ich złożoność i ilość danych, na których polegają.

To, co przyniosło RBAC sławę, jest tą samą rzeczą, która obecnie promuje stosowanie innych modeli. wymagania użytkownika. Użytkownicy zarówno lepiej rozumieją oprogramowanie, jak i oczekują większej kontroli nad swoimi uprawnieniami niż kiedykolwiek wcześniej. Rzeczy takie jak prywatność, dane i własność stają się bardzo podstawowymi wymaganiami, których RBAC nie może już spełniać. To sprawia, że zadajemy sobie pytanie, czy RABC może być w ogóle istotne.

Jak RBAC może być przydatny dzisiaj?

W ciągu ostatnich kilku lat pojawiły się dwa znaczące modele, które zagrażają dominacji RBAC w przestrzeni autoryzacji: Kontrola dostępu oparta na relacjach (ReBAC) i Kontrola dostępu oparta na atrybutach (ABAC).

ReBAC rozszerza podstawowy RBAC poprzez uwzględnienie relacji między obiektami, użytkownikami i rolami w aplikacji. Jeśli spojrzą Państwo na coś takiego jak system autoryzacji w stylu “Dysku Google”, szybko zauważą Państwo, że wykorzystuje on podstawy ról, akcji i zasobów, które znają już Państwo z RBAC i rozszerza je o relacje. To samo dotyczy ABAC-wykorzystuje RBAC jako strukturę bazową i rozszerza ją poprzez dodanie atrybutów do istniejących elementów RBAC.

Prostota RBAC sprawia, że jest to świetna podstawa do modelowania systemu autoryzacji, podczas gdy inne modele, takie jak ABAC i ReBAC, są nakładane na wierzch, aby zaspokoić bardziej szczegółowe wymagania.

Klucz: Polityka jako kod

Tak długo, jak wdrażają Państwo RBAC zgodnie z najlepszymi praktykami, w szczególności pisząc politykę jako kod, pomoże to pokryć podstawowe wymagania dotyczące autoryzacji i pozwoli na rozszerzenie jej przy użyciu innych modeli, jeśli zajdzie taka potrzeba.

Definiowanie polityki jako kodu pozwala nam tworzyć polityki autoryzacji, które są nie tylko czytelne, ale także zapewniają nam możliwość zapewnienia, że są one konsekwentnie egzekwowane w różnych systemach i środowiskach, pomagając zapobiegać naruszeniom zasad i zmniejszając ryzyko nieautoryzowanego dostępu. Pozwala na łatwe zarządzanie i aktualizowanie polityk, ponieważ robią to Państwo za pomocą tych samych narzędzi i procesów, które służą do zarządzania i wdrażania oprogramowania. Ułatwia to śledzenie zmian w politykach w czasie, wycofywanie zmian w razie potrzeby i ogólnie korzystanie z przemyślanych najlepszych praktyk świata kodu (np. GitOps).

Jeśli osadzą Państwo swoją autoryzację za pomocą polityki jako kodu lub polityki jako wykresu, oddzielając konfigurację od danych, skalowanie z RBAC do bardziej złożonych modeli staje się dość łatwe.

RBAC doskonale nadaje się również do usprawnienia drobnoziarnistej autoryzacji za pomocą przełączania funkcji – zarządzania widocznością zasobów w aplikacjach frontendowych, przy czym warstwa autoryzacji frontendowej korzysta z uproszczonej abstrakcji i prostoty RBAC.

Czy RBAC jest wciąż aktualny? Oczywiście, że tak, może nawet bardziej niż kiedykolwiek, ponieważ każda złożona architektura powinna mieć prostą podstawę. Ale to nie koniec wyzwań. . .

RBAC Enhanced: Aktualizacje danych i zasad na żywo

Jak wspomnieliśmy wcześniej, rozszerzenie RBAC na inne modele jest jeszcze łatwiejsze, jeśli zastosujemy się do najlepszych praktyk autoryzacji i oprzemy nasz system autoryzacji na polityce jako kodzie. Ponieważ natura systemów policy-as-code lub policy-as-graph oddziela troskę między konfiguracją (samym kodem) a danymi, łatwiej jest pisać polityki, które wymagają mniej danych, co pozwala nam korzystać z prostoty RBAC przy jednoczesnym wykorzystaniu wszelkich wymaganych danych w modelach drobnoziarnistych.

Jednak do podejmowania większości decyzji w nowoczesnych aplikacjach nadal wymagane są duże ilości danych i chociaż korzystanie z silników polityk, takich jak OPA i Cedar, zapewnia nam doskonałą podstawę do stworzenia oddzielnej mikrousługi do autoryzacji (pozwalającej na konfigurację polityki jako kodu), nadal istnieje kwestia utrzymywania tych silników na bieżąco z najbardziej odpowiednimi politykami i danymi. Proszę spojrzeć na krótki przykład.

Załóżmy, że nasza polityka wymaga, aby użytkownik był subskrybentem, aby zobaczyć część naszej witryny. Aby podjąć decyzję dotyczącą polityki, musimy znać status subskrypcji użytkownika z naszej usługi rozliczeniowej (np. PayPal lub Stripe) i być natychmiast świadomi wszelkich zmian w tym zakresie. Nowy subskrybent oczekuje natychmiastowego dostępu do naszej witryny, a użytkownik, który zrezygnował z subskrypcji, powinien natychmiast utracić do niej dostęp.

Oznacza to, że nasz silnik zasad musi być aktualizowany w czasie rzeczywistym z zewnętrznych źródeł danych, podczas gdy wszystkie nasze silniki zasad są ze sobą zsynchronizowane.

Open Policy Administration Layer (OPAL) to projekt OSS stworzony, aby pomóc w zarządzaniu silnikami polityk, dzięki czemu są one aktualizowane w czasie rzeczywistym o dane i aktualizacje polityk. Obsługując wiele silników polityki, OPAL oferuje dwie ważne funkcje:

• OPAL umożliwia śledzenie określonego repozytorium polityk (takiego jak GitHub, GitLab lub Bitbucket) pod kątem aktualizacji. Odbywa się to za pomocą webhooka lub sprawdzania zmian co kilka sekund. Dzięki temu system działa jako punkt administrowania polityką (PAP), który wysyła zmiany polityki do silnika polityki, zapewniając, że jest ona zawsze aktualna.
• Możliwość śledzenia dowolnego odpowiedniego źródła danych (API, bazy danych, usługi zewnętrznej) w celu aktualizacji za pośrednictwem interfejsu API REST i pobierania aktualnych danych z powrotem do silnika polityki.

Korzystanie z tych możliwości pozwala w pełni wykorzystać zalety RBAC i bardziej złożonych modeli polityk poprzez aktualizowanie silników polityk o wszystkie istotne polityki i dane w czasie rzeczywistym.