Chmura i kontrola dostępu – jak wdrożyć i zarządzać uprawnieniami

W nowym odcinku z cyklu “Jak bezpiecznie przenieść się do chmury” omówimy modele kontroli dostępu, czyli jak możemy zarządzać uprawnieniami w chmurze. Dobre zrozumienie tego tematu pozwala na uniknięcie wielu problemów.

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce.

W poprzednich artykułach i webinarze opisałem:

• architekturę modelu cloud computingu wg NIST SP 800-145,
• ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
• standardy bezpieczeństwa jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia,
• zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth.

W tym odcinku przedstawię jakie rozwiązania są wykorzystywane do kontroli dostępu w modelu chmury.

Kontrola dostępu

W poprzednim odcinku z cyklu Jak bezpiecznie przenieść się do chmury przedstawione zostały podstawowe pojęcia i modele związane z zarządzanie tożsamością w modelu cloud computing. W tym artykule obszar ten zostanie uzupełniony o charakterystykę modeli kontroli dostępu wykorzystywanych w systemach informatycznych oraz opis ich zalet i ograniczeń w kontekście usług chmurowych.

Kontrola dostępu rozumiana jest jako proces, który określa czy dany podmiot ma uprawnienia do dostępu, korzystania czy modyfikacji zasobu. Obejmuje sprawowanie nadzoru nad tym, którzy uczestnicy (osoby, procesy, maszyny, itd.) i na jakich zasadach mają dostęp do poszczególnych zasobów systemu komputerowego, na czym ten dostęp polega, w jaki sposób korzystają ze wspólnych danych itp. Kontrola dostępu działa na kilku poziomach: aplikacji, warstwy pośredniej (ang. middleware), systemu operacyjnego i sprzętu. Generalnie modele wykorzystują następujące pojęcia:

• Obiekt – pasywny zasób, który może być dostępny przez podmiot np. dane, pliki, zasoby.
• Podmiot – aktywny zasób, który chce wykonać operację na obiekcie.
• Polityka kontroli dostępu – zbiór reguł określających uprawnienia podmiotu do wykonania operacji na obiekcie. Jednym z najbardziej powszechnym sposobów na zdefiniowanie i zaprezentowanie polityki kontroli dostępu jest model Access Control Matrix. Zakłada on stworzenie macierzy, w której kolumnami są obiekty (np. dane, aplikacje), natomiast wiersze odpowiadają podmiotom (np. użytkownikom) operującym na tych zasobach. W przecięciu kolumny i wiersza umieszczone są wszystkie przypisane danej parze uprawnienia (np. odczyt, modyfikacja, usunięcie, uruchomienie, itp.).

Przykład matrycy kontroli dostępu

Z modelu tego wynikają dwa widoki: każdy wiersz tworzy profil dostępu (ang. Access profile) podmiotu, natomiast każda kolumna tworzy listę kontrolną dostępu do danego obiektu (ang. Access control list). To właśnie Access-control List (ACL) jest najczęściej wykorzystywaną strukturą do implementacji polityki kontroli dostępu.

Modele kontroli dostępu

Każdy z modeli kontroli dostępu ma swoje zalety, przeznaczenie i ograniczenia. Tradycyjnymi modelami kontroli dostępu w systemach informatycznych są MAC, DAC i RBAC.

DAC – (Discretionary Access Control – Uznaniowa kontrola dostępu) w tym modelu kontrola dostępu do obiektu oparta jest na założeniu własności obiektu. ACL (Access Control List) opiera się na polityce dostępu określanej przez prawa własności obiektu. W większości systemów wykorzystujących model DAC, prawo własności przysługuje twórcy obiektu. To on określa kto i na jakich zasadach ma dostęp do obiektu. Wadą tego modelu jest to, że użytkownik, który jest uprawniony do podjęcia działań na konkretnym obiekcie, może to uprawnienie przekazać bez wiedzy właściciela obiektu innemu użytkownikowi, który nie powinien mieć do niego uprawnień. Przykładem są tu systemy plików wykorzystywane w systemach operacyjnych, np. Windows, Linux lub innych.

MAC (Mandatory Access Control – Obowiązkowa kontrola dostępu) – podstawowym założeniem modelu jest jednokierunkowy przepływ informacji tzn. od obiektów o niższej klasyfikacji tajności do obiektów o wyższym stopniu tajności. Administrator systemu podejmuje decyzje odnośnie przyznawania i odbierania uprawnień do obiektu. Wskazany użytkownik ma dostęp tylko do obiektów sklasyfikowanych na tym samym poziomie, bądź niższych. W systemach wykorzystujących model MAC, wszystkie podmioty i obiekty muszą mieć przypisane etykiety wrażliwości (sensitive labels), które dla podmiotów określają jego poziom zaufania, a dla obiektów poziom zaufania wymagany do uzyskania dostępu. Etykiety mogą być określone poziomami tajności np. ściśle tajne, tajne, poufne, publiczne. Gdy podmiot chce otrzymać dostęp do obiektu, jego etykieta wrażliwości musi być równa lub wyższa niż etykieta wrażliwości żądanego obiektu. Najważniejszą różnicą wobec modelu uznaniowego jest to, że użytkownik nie ma pełnej kontroli nad stworzonymi przez siebie zasobami.

RBAC – (Role based access control) – kontrola dostępu oparta na rolach zakłada przypisanie podmiotom odpowiednich ról, które przekładają się na poszczególne uprawnienia do wykonywania operacji w systemie. Podmiot może pełnić wiele ról, ale może wykorzystać uprawnienia jedynie w ramach roli, którą pełni aktualnie. Są one przydzielane ze względu na jego przynależność do roli, a nie tożsamość. Główną przyczyną powstania modelu RBAC jest fakt powiązania uprawnień pracownika do funkcji, jaką pełnią. Rzadko są one nadawane konkretnej osobie. Podstawowy model RBAC opiera się o przyporządkowanie dotyczące użytkowników oraz ich ról, powiązanie uprawnień z rolami oraz powiązania uprawnień i operacji. Model jest bardziej elastyczny niż poprzednio opisane modele. Pozwala na wygodne budowanie szerokiej gamy ról, umożliwia hierarchiczne ich zagnieżdżanie, co przekłada się również na wygodę administrowania. Model RBAC jest neutralny pod względem polityk bezpieczeństwa – umożliwia zamodelowanie zarówno polityki MAC jak i DAC. O zmianie uprawnień użytkownika decyduje administrator systemu. Jeden z najpowszechniej stosowanych modeli, który obejmuje trzy znane zasady bezpieczeństwa: ukrywania informacji (information hiding),najmniejszego uprzywilejowania (least privilige) i separacji obowiązków (segregation of duties).

RBAC model –źródło „ Guide to Attribute Based Access Control (ABAC) Definition and Considerations”

Powyżej wymienione modele opierają się na założeniu, kto do jakich obiektów i na jakich uprawnieniach powinien mieć dostęp. Modelem, który dodatkowo określa kiedy, gdzie, dlaczego i jak dostęp powinien być nadany jest model attribute-based access control (ABAC). Polega on na nadaniu użytkownikowi zestawu atrybutów, które są cechami dla :

• podmiotu, którym może być użytkownik, funkcja, rola czy posiadany certyfikat
• obiektu np. urządzenie, plik, rekord, tablica, proces, program, sieć czy domena
• warunków środowiskowych (environment conditions) stanowiących operacyjny lub sytuacyjny kontekst, w którym następuje żądanie dostępu. Mogą obejmować atrybuty związane z czasem (godziny, dni tygodnia) , geolokalizacją lub przynależnością do sieci lub domeny.

Obiekt określa, jakie atrybuty musi posiadać podmiot łącznie z warunkami środowiskowymi, aby uzyskać do niego dostęp.

ABAC Basic Mechanism – źródło „ Guide to Attribute Based Access Control (ABAC) Definition and Considerations”

1. Podmiot chce uzyskać dostęp do obiektu
2. Mechanizm kontroli dostępu analizuje:
   1. Reguły – ograniczenia dostępu. W wyniku analizy zwracana jest wartość true lub false
   2. Atrybuty podmiotu
   3. Atrybuty obiektu
   4. Warunki środowiskowe (opcjonalnie)
3. W przypadku pozytywnej autoryzacji podmiot uzyskuje dostęp do obiektu.

Przykład: Pielęgniarka (1) z oddziału ortopedii (2b) może uzyskać dostęp w trybie do odczytu (2a) do danych aktualnych pacjentów z oddziału ortopedii (2c) w szpitalu warszawskim w trakcie swojej zmiany (2d)

ABAC jest logicznym modelem umożliwiającym zdefiniowanie szerokiej gamy polityk kontroli dostępu w zależności od ilości dostępnych atrybutów i relacji pomiędzy nimi.

Podejście oparte na ryzyku

Kolejnym modelem uwzględniającym dodatkowe czynniki przy podejmowaniu decyzji o przyznaniu dostępu do obiektu jest RAdAC (Risk-Adaptive Access Control). RAdAC (zwany też RBAC – Risk Based Access Control) jest modelem opartym o dynamiczne szacowanie ryzyka i będącym kombinacją Attribute-Based Access Control, Policy-Based Access Control oraz podejścia opartego na uczeniu maszynowym i heurystyce.

RAdAC model– źródło „ Guide to Attribute Based Access Control (ABAC) Definition and Considerations”

Do podejmowania decyzji uwzględniane są następujące czynniki:

Uzasadnienie operacyjne (operational need) – zapożyczony z tradycyjnych modeli kontroli dostępu oparty na zasadzie wiedzy koniecznej („need to know”) oznaczający, że podmiot powinien posiadać relację z obiektem uzasadniającą żądanie dostępu.

Ryzyko związane z bezpieczeństwem (Security risk) – fundament modelu. Czynnik wymagający wsparcia uczenia maszynowego do określenia ryzyka w czasie rzeczywistym w sposób probabilistyczny. Do szacowania ryzyka brane są pod uwagę komponenty związane z:

• Z wiarygodnością i autorytetem podmiotów chcących uzyskać dostęp do obiektów (rola, funkcja, poziom dostępu, świadomość bezpieczeństwa, historia incydentów).
• Z cechami komponentów IT (typy urządzeń, rodzaj sieci, siła szyfrowania, typ aplikacji, rodzaj uwierzytelnienia itp.).
• Z czynnikami związanymi z bieżącą sytuacją w jakiej realizowana jest operacja (situation factors) np. powiązanie uzasadnienia operacyjnego, polityk i procedur oraz wyników podobnych decyzji podejmowanych w przeszłości.
• Z cechami środowiska w jakich dokonywana jest operacja (environment factors) uwzględniając związane z nim podatności i zagrożenia.
• Z cechami obiektu uwzględniającymi np. klasyfikację danych, wymagany poziom szyfrowania, poziom uprawnień itp.
• Heurystyką czyli wiedzą na temat decyzji podejmowanych w przeszłości i ich konsekwencji.
  

Który z w/w modeli jest bardziej odpowiedni do zastosowania w usłudze chmurowej, z której chcemy skorzystać? W celu uzyskania odpowiedzi należy rozważyć i porównać kilka elementów. Do porównania uwzględnione zostały najczęściej stosowane w chmurze modele – RBAC, ABAC i RAdAC.

Podmiot

W przypadku modelu RBAC granice podmiotu określane są przez użytkownika w powiązaniu z rolą do, której jest przypisany. W ABAC granice podmiotu zdeterminowane są przez podmiot wraz z jego atrybutami. Granice podmiot w modelu RAdAC są najbardziej rozległe i obejmują podmiot wraz z atrybutami, czynnikami sytuacyjnymi, heurystyką i autorytetem.

Polityka kontroli dostępu

RBAC – polityka kontroli dostępu do obiektu realizowana jest na podstawie przynależności do roli posiadającej zestaw uprawnień do wykonania akcji. Administrowanie dostępem koncentruje się na odpowiednim przypisaniu uprawnień w rolach (uprawnienie może istnieć w wielu rolach, rola może się składać z wielu uprawnień) oraz przypisaniu użytkowników/grup do odpowiednich ról.

Polityka w modelu ABAC opiera się na regułach i przy podejmowaniu decyzji o przyznaniu dostępu bierze pod uwagę atrybuty podmiotu i obiektu. Wykorzystując kombinację słów kluczowych można w sposób elastyczny konstruować reguły polityki.

Kluczowa koncepcja modelu RAdAC oparta jest na założeniu dynamicznego zarządzania politykami poprzez zmianę poziomu ryzyka bezpieczeństwa i uzasadnienia operacyjnego. Polityki mogą być oparte na prostych regułach IF, THEN.

Obiekt

W modelu RBAC granice obiektu są określone wraz z operacjami jakie mogą być na nim realizowane. W modelach ABAC i RAdAC granice te są wyznaczone wraz z atrybutami obiektu.

Podsumowanie

Istnieje wiele modeli kontroli dostępu możliwych do wykorzystania w technologii chmury. Przy wyborze odpowiedniego dla używanych przez siebie rozwiązań należy wziąć pod uwagę wiele czynników m.in.:

• Uwzględnienie niejednorodnej specyfiki chmury i wsparcie interoperacyjności – usługi w modelu cloud computing wykorzystują różne technologie w zakresie oprogramowania i sprzętu. Przy projektowaniu systemu kontroli dostępu należy wziąć pod uwagę jego integrację i kompatybilność z wieloma rozwiązaniami i standardami.
• Złożoność rozwiązania i czas reakcji – jedna z cech chmury polega na szerokim, zdalnym dostępie do usług mogących znajdować się w dowolnym obszarze geograficznym. Część obecnie stosowanych modeli kontroli dostępu zapewnia wysoki poziom bezpieczeństwa okupiony jednak użyciem skomplikowanych algorytmów powodujących spowolnienie usługi.
• Skalowalność – kolejna z cech usług chmurowych, która powinna być również uwzględniona w kontekście kontroli dostępu. Rozwiązanie powinno w elastyczny sposób dostosowywać się do wzrostu liczby użytkowników i polityk i umożliwiać proste zarządzanie.

Do porównania wybrałem powszechnie wykorzystywane (RBAC i ABAC) oraz pionierski model RAdAC. Użyłem kilka podstawowych kryteriów, które mogą ułatwić ich zrozumienie. Jest to moja subiektywna ocena podparta wynikami publicznie dostępnych badań.

*Powstało wiele odmian RBAC dostosowanych do specyfiki chmury i eliminujących niektóre słabości tradycyjnego modelu.

Dla organizacji, które korzystają z usług chmurowych, w których liczba spodziewanych ról jest niewielka odpowiednim wyborem będzie model RBAC. Powstało wiele jego odmian eliminujących słabości modelu w w kontekście usług chmurowych m.in. coRBAC (Cloud optimized RBAC model), Task Role Based Access Control (TRBAC), Ontology Role Based Access Control Model (O-RBAC), Attribute Role Based Access Control (ARBAC) – połączenie modeli RBAC i ABAC. W przypadku rozległych, rozproszonych i dynamicznie zmieniających się środowiskach lepszym rozwiązaniem będzie ABAC. Zastosowanie atrybutów pozwala na bardziej precyzyjne zaprojektowanie polityki kontroli dostępu obejmujące takie czynniki jak czas, geolokalizację, przynależność do domeny itd. W przypadku zmian w podmiocie (rola, lokalizacja, oddział, stanowisko itd.) nie jest konieczny przegląd i aktualizacja przypisania podmiotu do roli. Zmiana dostępu dokona się wraz ze zmianą atrybutów podmiotu. W przypadku centralnego przechowywania atrybutów można uzyskać interoperacyjność przy korzystaniu z rozwiązań wielu dostawców. Dla rozwiązań wymagających bardzo szczegółowej, dynamicznie zmieniającej się i opartej na ryzyku polityce kontroli dostępu najbardziej odpowiednim modelem będzie Risk-adaptive access control. Wykorzystuje on elementy wszystkich wymienionych modeli kontroli dostępu umożliwiając podejmowanie decyzji o przyznaniu dostępu w częściowo zautomatyzowany sposób, w oparciu o uzasadnienie operacyjne, kontekst sytuacyjny, atrybuty podmiotu i obiektu przy wsparciu maszynowego uczeniu i heurystyki. Zapewnia wysoki poziom bezpieczeństwa, elastyczność i skalowalność w zarządzaniu politykami, ale wymaga dokładnego zaprojektowania wstępnych założeń. Jego złożoność powoduje wiele wyzwań do implementacji i integracji w rozproszonych środowiskach.

Jednym ze sposobów na implementację i zastosowanie w/w modeli jest zatwierdzony przez OASIS standard XACML – eXtensible Access Control Markup Language (obecnie w wersji 3.0). Oparty o model ABAC, ale z powodzeniem może być zastosowany dla modelu RBAC wykorzystującego atrybuty (m.in. ARBAC). Podstawowym językiem definiowania reguł polityki dostępu jest XML, ale wspiera też JSON. Składa się z podstawowych elementów:

• PAP – Policy Administration Point – definiowanie I zarządzanie politykami.
• PDP – Policy Decision Point – ocena żądań dostępu I przyznawanie decyzji o dostępie.
• PEP – Policy Enforcement Point – przesyłanie żądań od podmiotu do oceny w celu otrzymania decyzji o dostępie.
• PIP – Policy Information Point – repozytorium atrybutów (podmiotu, obiektu, środowiska).
• PRP – Policy Retrieval Point – punkt przechowywania polityk XACML.

XACML flow – źródło: Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

Standard XACML 3.0 Jest odpowiedni dla złożonych, rozproszonych, dynamicznie zmieniających się środowisk, w których wymagana jest szczegółowa kontrola dostępu np. sektor zdrowia w chmurze.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.