RBAC i ABAC: Modele kontroli dostępu, które warto znać

Wprowadzenie#

Kontrola dostępu jest kluczowym aspektem bezpieczeństwa w każdym systemie. Zapewnia, że tylko autoryzowani użytkownicy mają dostęp do zasobów i mogą wykonywać określone działania. Kontrola dostępu na bazie roli (RBAC) i kontrola dostępu na bazie atrybutów (ABAC) to dwa z najpopularniejszych modeli kontroli dostępu stosowanych we współczesnych systemach. Oba modele są szeroko stosowane i mogą być używane do skutecznego egzekwowania polityk kontroli dostępu. Ale czym one są i czym się różnią?

Kontrola dostępu na bazie roli (RBAC)#

Kontrola dostępu na bazie roli (RBAC) została po raz pierwszy wprowadzona na początku lat 90. Uformalizowanie modelu przypisuje się Davidowi Ferraiolo i Rickowi Kuhnowi, którego artykuł został opublikowany w 1992 roku. Od tego czasu RBAC stał się jednym z najczęściej używanych modeli kontroli dostępu w branży.

W RBAC polityki kontroli dostępu opierają się na rolach, które są zbiorem uprawnień. Użytkownicy są przypisywani do ról (np. administrator, redaktor, widz), a ich prawa dostępu są określane przez uprawnienia (np. tworzenie, edycja, usuwanie) do określonych zasobów (np. pliki, bazy danych, aplikacje). Upraszcza to zarządzanie politykami kontroli dostępu poprzez grupowanie użytkowników na podstawie ich ról i przypisywanie uprawnień do ról. Łatwo jest dodać lub usunąć użytkowników z ról, a zmiany automatycznie zostaną odzwierciedlone w politykach kontroli dostępu.

Kluczowe komponenty RBAC#

• Zasób: Zasób to jednostka, do której użytkownik może mieć dostęp. Zasoby mogą obejmować wszystko, od plików, baz danych, API, po dowolne inne jednostki systemowe, które muszą być chronione.
• Uprawnienie: Uprawnienie to konkretna akcja, którą użytkownik może wykonać na zasobie. Na przykład tworzenie, edycja, usuwanie, przeglądanie. Definicja uprawnień może się różnić w zależności od systemu. W większości przypadków uprawnienia są definiowane na poziomie zasobu z minimalną szczegółowością.
• Rola: Rola to zbiór uprawnień, które definiują zestaw akcji, jakie użytkownik może wykonać. Na przykład rola administratora może mieć uprawnienia do tworzenia, edytowania i usuwania zasobów, podczas gdy rola widza może mieć uprawnienie do przeglądania zasobów.
• Użytkownik: Użytkownik to jednostka, która może być przypisana do jednej lub więcej ról. Użytkownicy otrzymują dostęp do zasobów na podstawie uprawnień związanych z przypisanymi im rolami.

Warianty RBAC#

Istnieje kilka wariantów RBAC, które rozszerzają podstawowy model, aby uwzględnić bardziej złożone wymagania dotyczące kontroli dostępu:

• RBAC0: Podstawowy model, w którym użytkownicy są przypisywani do ról, a role do uprawnień.
• RBAC1: Dodaje koncepcję hierarchii ról. Role mogą dziedziczyć uprawnienia od innych ról. Jest również znany jako hierarchiczny RBAC.
• RBAC2: Dodaje ograniczenia do ról. Ograniczenia mogą być używane do definiowania dodatkowych warunków, które muszą być spełnione, aby użytkownik mógł być przypisany do roli. Jest również znany jako RBAC oparty na ograniczeniach.
• RBAC3: Łączy cechy RBAC1 i RBAC2. Obsługuje zarówno hierarchie ról, jak i ograniczenia.

Więcej informacji na temat tych wariantów można znaleźć w modele RBAC i ich ewolucja.

Zalety RBAC#

• Prostota: RBAC jest łatwy do zrozumienia i wdrożenia. Przydzielanie uprawnień do ról i ról do użytkowników jest proste.
• Efektywność: Upraszcza zarządzanie politykami kontroli dostępu przez grupowanie użytkowników na podstawie ich ról. Łatwo jest dodać lub usunąć użytkowników z ról bez zmieniania polityk kontroli dostępu. Zwłaszcza w dużych organizacjach z dobrze zdefiniowanymi strukturami uprawnień, RBAC może być bardzo wydajny.
• Przejrzystość: RBAC zapewnia przejrzyste mapowanie ról, uprawnień i użytkowników. Łatwo jest przeprowadzić audyt i przegląd polityk kontroli dostępu.

Wady RBAC#

• Sztywność: RBAC może być sztywny, jeśli chodzi o definiowanie złożonych polityk kontroli dostępu. Może nie być odpowiedni dla systemów, w których polityki kontroli dostępu muszą być bardziej dynamiczne i świadome kontekstu.
• Szczegółowość: RBAC może nie mieć wymaganego poziomu szczegółowości dla kontroli dostępu o wysokiej granularności. Polityki kontroli dostępu są związane z dobrze zdefiniowanymi rolami i może wymagać dodatkowego wysiłku, aby zdefiniować uprawnienia na bardziej szczegółowym poziomie.
• Eksplozja ról: W dużych organizacjach z złożonymi strukturami uprawnień liczba ról może rosnąć wykładniczo, prowadząc do eksplozji ról. Zarządzanie dużą liczbą ról może być wyzwaniem.

Kontrola dostępu na bazie atrybutów (ABAC)#

Pod koniec lat 2000, gdy systemy stawały się coraz bardziej złożone i dynamiczne, coraz więcej organizacji zaczęło przyjmować kontrolę dostępu na bazie atrybutów (ABAC) jako alternatywę dla RBAC. Ważnym kamieniem milowym w formalizacji ABAC jest publikacja NIST Special Publication 800-162 z 2014 roku.

ABAC jest bardziej elastycznym modelem kontroli dostępu w porównaniu z RBAC. Jest to model autoryzacji, który definiuje polityki kontroli dostępu na podstawie atrybutów użytkownika, zasobu, akcji i środowiska. Pozwala organizacjom definiować szczegółowe polityki dostępu, które mogą dostosowaç się do różnych kontekstów i warunków.

Kluczowe komponenty ABAC#

• Podmiot: Podmiot to jednostka, która żąda dostępu do zasobu. Może to być użytkownik, urządzenie, aplikacja lub dowolna inna jednostka, która potrzebuje dostępu do zasobów.
• Zasób: Podobnie jak w RBAC, zasób to jednostka, do której podmiot może uzyskać dostęp. Zasoby mogą być plikami, bazami danych, API lub dowolnymi innymi jednostkami systemowymi.
• Akcja: Akcja to specyficzna operacja, którą podmiot może wykonać na zasobie. Może to być tworzenie, czytanie, aktualizacja, usuwanie lub jakakolwiek inna operacja, która wymaga kontroli.
• Środowisko: Środowisko to kontekst, w którym złożono żądanie dostępu. Może zawierać atrybuty takie jak pora dnia, lokalizacja, sieć, urządzenie itp.
• Atrybut: Atrybut to cecha podmiotu, zasobu, akcji lub środowiska. Atrybuty mogą być jakiekolwiek, np. rola użytkownika, dział, lokalizacja, adres IP, typ urządzenia itp.
• Polityka: Polityka to reguła, która definiuje warunki, na jakich dostęp jest przyznawany lub odmowywany. Polityki są definiowane na podstawie atrybutów.

Zalety ABAC#

• Elastyczność: ABAC może uwzględniać złożone polityki kontroli dostępu oparte na wielu atrybutach. Umożliwia organizacjom definiowanie szczegółowych polityk, które mogą dostosować się do różnych kontekstów i warunków.
• Dynamiczność: Polityki ABAC mogą być dynamiczne i świadome kontekstu. Decyzje o kontroli dostępu mogą być podejmowane na podstawie atrybutów w czasie rzeczywistym, takich jak lokalizacja, pora dnia, typ urządzenia itp.
• Szczegółowość: ABAC zapewnia szczegółową kontrolę dostępu, pozwalając organizacjom definiować polityki na podstawie wielu atrybutów. W przeciwieństwie do definiowania ról i uprawnień, polityki oparte na atrybutach mogą być bardziej szczegółowe.

Wady ABAC#

• Złożoność: ABAC może być bardziej złożone we wdrażaniu i zarządzaniu w porównaniu z RBAC. Definiowanie atrybutów i polityk może wymagać większego wysiłku i wiedzy specjalistycznej. W przeciwieństwie do RBAC, gdzie role i uprawnienia są dobrze zorganizowane, atrybuty mogą być bardziej dynamiczne, a polityki złożone. Zarządzanie dużą liczbą atrybutów i polityk w złożonym systemie może być wyzwaniem. Często wymagany jest scentralizowany mechanizm oceny polityk, aby je ocenić.
• Wydajność: Ocena atrybutów może wpływać na wydajność, zwłaszcza w środowiskach czasu rzeczywistego. Polityki oparte na wielu atrybutach i warunkach czasu rzeczywistego mogą wprowadzać opóźnienia w decyzjach dotyczących kontroli dostępu.

Tabela porównawcza#

Z tabeli porównawczej wynika, że RBAC najlepiej nadaje się do systemów z dobrze zdefiniowanymi strukturami uprawnień i tam, gdzie polityki kontroli dostępu są stosunkowo statyczne. Z kolei ABAC jest bardziej odpowiedni dla systemów, w których polityki kontroli dostępu muszą być dynamiczne, świadome kontekstu i drobnoziarniste.

Przykłady#

Scenariusz: System szpitalny, który musi zarządzać dostępem do danych pacjentów dla różnych członków personelu.

• Personel: Lekarze, Pielęgniarki, Administratorzy
• Zasoby: Dane pacjentów
• Uprawnienia: Czytaj, Pisz, Usuń

Przypadek 1#

Polityki kontroli dostępu są stosunkowo proste:

1. Lekarze mogą czytać i pisać dane pacjentów.
2. Pielęgniarki mogą czytać dane pacjentów.
3. Administratorzy mogą czytać, pisać i usuwać dane pacjentów.

Model RBAC#

W tym przypadku RBAC jest prosty i skuteczny. Możemy zdefiniować role dla lekarzy, pielęgniarek i administratorów, a następnie przypisać odpowiednie uprawnienia do każdej roli.

Ocena kontroli dostępu jest prosta:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

Model ABAC#

W tym przypadku, ABAC może być zbyt skomplikowany, ale można go nadal używać do definiowania szczegółowych polityk opartych na atrybutach, takich jak dział, rola, itp.

Atrybuty:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

Polityki:

• Polityka 1: Zezwól na dostęp do odczytu na podstawie user.role i resource.name
  • podmiot: Użytkownik z rolą doctor, nurse, admin
  • zasób: Zasób z nazwą patient-record
  • akcja: read
  • efekt: allow
  • uzasadnienie: "Zezwól na dostęp do odczytu do danych pacjentów dla wszystkich ról"
• Polityka 2: Edycja dostępu dla lekarzy i administratorów
  • podmiot: Użytkownik z rolą doctor, admin
  • zasób: Zasób z nazwą patient-record
  • akcja: write
  • efekt: allow
  • uzasadnienie: "Zezwól na dostęp do pisania do danych pacjentów dla lekarzy i administratorów"
• Polityka 3: Usunięcie dostępu dla administratorów
  • podmiot: Użytkownik z rolą admin
  • zasób: Zasób z nazwą patient-record
  • akcja: delete
  • efekt: allow
  • uzasadnienie: "Zezwól na dostęp do usunięcia danych pacjentów dla administratorów"

Dla każdego żądania odczytu/zapisu/usunięcia, silnik polityki ocenia wszystkie odpowiednie polityki na podstawie atrybutów i podejmuje decyzję dotyczącą kontroli dostępu.

Porównanie#

W tym przypadku polityki kontroli dostępu są proste i dobrze zorganizowane. Wymagany jest tylko jeden poziom kontroli uprawnień, aby określić, czy użytkownik ma dostęp do zasobu. Wyobraź sobie, że system szpitalny ma bardziej złożoną strukturę z wieloma działami, rolami i uprawnieniami:

• W modelu RBAC proces oceny kontroli dostępu do zasobu danych pacjenta pozostanie prosty i przejrzysty, czy użytkownik ma uprawnienie do read, write, czy delete;
• ABAC, z drugiej strony, będzie wymagał uwzględnienia dodatkowych atrybutów, takich jak department-id i doctor-id. Co w przypadku, gdy urządzenie IoT potrzebuje dostępu do danych pacjenta? Będzie wymagało nowego atrybutu device-id do wprowadzenia w ocenie polityki. Jak udzielić tymczasowego uprawnienia read stażystom?

Podsumowując, RBAC jest lepszym wyborem. RBAC jest prosty i wydajny dla systemów z dobrze zdefiniowanymi strukturami uprawnień i gdzie polityki kontroli dostępu są statyczne.

Przypadek 2#

Ten sam system szpitalny, teraz wprowadzimy nową rolę pacjent i nowy atrybut patient-id.

Polityki kontroli dostępu to:

1. Lekarze mogą czytać i pisać dane pacjentów.
2. Pielęgniarki mogą czytać dane pacjentów.
3. Administratorzy mogą czytać, pisać i usuwać dane pacjentów.
4. Pacjenci mogą czytać swoje własne dane.

Model RBAC#

W tym przypadku, oprócz starego uprawnienia read, musimy wprowadzić nowe uprawnienie read-own. Możemy zdefiniować role dla lekarzy, pielęgniarek, administratorów i pacjentów, a następnie przypisać odpowiednie uprawnienia do każdej roli.

Teraz ocena kontroli dostępu jest nieco bardziej złożona, szczególnie dla akcji read:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

Model ABAC#

Teraz zaktualizujmy atrybuty i polityki w modelu ABAC, aby uwzględnić nowe wymagania.

Atrybuty:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

Polityki:

• Polityka 1: Zezwól na dostęp do odczytu wszystkich danych pacjentów
  • podmiot: Użytkownik z rolą doctor, nurse, admin
  • zasób: Zasób z nazwą patient-record
  • akcja: read
  • efekt: allow
  • uzasadnienie: "Zezwól na dostęp do odczytu danych pacjentów dla całego personelu i pacjenta"
• Polityka 2: Zezwól na pisanie danych pacjentów dla lekarzy i administratorów
  • podmiot: Użytkownik z rolą doctor, admin
  • zasób: Zasób z nazwą patient-record
  • akcja: write
  • efekt: allow
  • uzasadnienie: "Zezwól na pisanie danych pacjentów dla lekarzy i administratorów"
• Polityka 3: Zezwól na usunięcie danych pacjentów dla administratorów
  • podmiot: Użytkownik z rolą admin
  • zasób: Zasób z nazwą patient-record
  • akcja: delete
  • efekt: allow
  • uzasadnienie: "Zezwól na usunięcie danych pacjentów dla administratorów"
• Polityka 4: Zezwól na dostęp do własnych danych pacjenta
  • podmiot: Użytkownik z rolą patient
  • zasób: Zasób z nazwą patient-record
  • akcja: read
  • warunek: user.id === resource.patient-id
  • efekt: allow
  • uzasadnienie: "Zezwól na dostęp do własnych danych pacjenta"

Porównanie#

W tym przypadku polityki kontroli dostępu są bardziej złożone i świadome kontekstu. Proces oceny kontroli dostępu do zasobów danych pacjenta będzie wymagał wielu poziomów kontroli uprawnień, aby określić, czy użytkownik ma dostęp do zasobu.

• W modelu RBAC proces oceny kontroli dostępu do zasobów danych pacjenta będzie wymagał wielu poziomów kontroli uprawnień, aby określić, czy użytkownik ma dostęp do zasobu. Na przykład, aby określić, czy pacjent ma dostęp do swoich własnych danych, system musi sprawdzić, czy użytkownik ma uprawnienie read-own i czy identyfikator użytkownika pasuje do identyfikatora pacjenta.
• W modelu ABAC proces oceny kontroli dostępu może być bardziej przejrzysty. Polityki mogą być definiowane na podstawie atrybutów użytkownika, zasobu i akcji. Na przykład, aby określić, czy pacjent ma dostęp do swoich własnych danych, silnik polityki może ocenić politykę na podstawie identyfikatora użytkownika i identyfikatora pacjenta.

W tym przypadku ABAC może być lepszym wyborem. ABAC jest bardziej odpowiedni dla systemów, w których polityki kontroli dostępu muszą być dynamiczne, świadome kontekstu i drobnoziarniste.

Podsumowanie#

Wybór między RBAC a ABAC zależy od specyficznych wymagań systemu. RBAC jest najlepszy dla systemów z dobrze zdefiniowanymi strukturami uprawnień i gdzie polityki kontroli dostępu są statyczne. ABAC jest bardziej odpowiedni dla systemów, w których polityki kontroli dostępu muszą być dynamiczne, świadome kontekstu i drobnoziarniste. W praktyce organizacje mogą zdecydować się na połączenie obu modeli, aby osiągnąć pożądany poziom kontroli dostępu.