Azure Role Based Access Control (RBAC) jest podstawowym mechanizmem kontroli dostępu w Azure. Jak sama nazwa wskazuje, kontrola dostępu w Azure bazuje na przypisanych użytkownikowi rolach – zdefiniowanych zestawach uprawnień niezbędnych do wykonywania określonych czynności czy pełnienia danej funkcji. Dzięki takiemu podejściu kwestia uprawnień jest znacznie uproszczona – łatwiej przypisać komuś rolę np. Network Administrator, niż nadawać uprawnienia do wszystkich niezbędnych do pracy zasobów czy tworzyć dużej ilości grup z konkretnymi uprawnieniami, do których później odpowiednio przypisywany jest dany użytkownik.
Przy okazji kwestii uprawnień nie można nie wspomnieć o niezwykle istotnej w kontekście bezpieczeństwa zasadzie najniższych możliwych uprawnień (Least Privilege). To podejście powinno być realizowane zawsze, gdy mamy do czynienia z uprawnieniami – system ról występujący w Azure absolutnie nie jest od tego wyjątkiem. Mówi ono o nadawaniu wyłącznie takich uprawnień, które są niezbędne do wykonywania bieżących obowiązków. Eliminuje to szereg potencjalnych zagrożeń, nie mając przy tym dużego wpływu na wykonywaną pracę – nie chodzi tutaj o ograniczanie możliwości wykonywania swoich zadań, gdyż nie miałoby to większego sensu. Nadmierne, niepotrzebne uprawnienia niosą z kolei potencjalne ryzyka wykonania akcji mających duży, negatywny wpływ np. na organizację – zarówno przypadkowo, jak i z premedytacją (np. usunięcie kluczowego zasobu czy danych). Co jeszcze istotniejsze, istotnie ograniczają (przynajmniej czasowo) wpływ przejęcia konta danego użytkownika przez atakującego. Z reguły zdecydowanie łatwiej jest przejąć konto zwykłego użytkownika z niskimi uprawnieniami niż konta z uprawnieniami administratora. W przypadku przejęcia konta z niskimi uprawnieniami, aby dostać się do kluczowych zasobów, atakujący musi jeszcze znaleźć sposób na eskalację uprawnień, a to już kolejna warstwa zabezpieczeń, która pomaga ograniczyć skutki takiego ataku.
Role w Azure Active Directory, zarówno te wbudowane jak i tworzone indywidualnie, wspierają takie podejście. Nie zmienia to faktu, że sam mechanizm do skutecznego działania wymaga odpowiedniego przypisania ról przez administratora systemu, tak aby to podejście było w praktyce efektywne.
Typy wbudowanych ról w Azure
Azure oferuje wiele wbudowanych ról, które możemy wykorzystać od samego początku korzystania z tej platformy. Możemy je podzielić na dwie główne grupy: Role w Azure Active Directory oraz Role wykorzystywane przez Azure Resource Manager.
W Azure AD role możemy znaleźć, znajdując w panelu po lewej stronie Roles and administrators:
Możemy tutaj znaleźć całą listę wbudowanych ról wraz z ich krótkimi opisami:
Klikając w dowolną interesującą nas rolę możemy sprawdzić do kogo została ona przypisana:
Jak również zapoznać się z dokładnym opisem danej roli oraz zestawem uprawnień z nią powiązanych (użytkownik do którego zostanie przypisana wybrana rola uzyska wszystkie uprawnienia wylistowane w sekcji Role premissions):
Uprawnienia powiązane z daną rolę w Azure AD można łatwo identyfikować, nawet na podstawie samych nazw. Znajdziemy tu zarówno role powiązane bezpośrednio z administracją konkretnymi produktami Microsoft (SharePoint, Skype for Business, Teams), jak również z różnymi aspektami naszego środowiska jak np. User Administrator (do zarządzania wszystkimi aspektami związanymi z kontami użytkowników, grupami itp.) czy Security Administrator. Nowo dodane role lub role, które zostały ostatnio zaktualizowane mają zaraz po nazwie charakterystyczny zielony kształt:
Zupełnie inne role znajdziemy przy okazji ról powiązanych z zasobami. Przechodząc do dowolnego zasobu lub grupy zasobów (ale także subskrypcji) w zakładce Access Control znajdziemy, jak sama nazwa wskazuje, informacje dotyczące kontroli dostępu do danego zasobu/grupy zasobów:
W zakładce Roles zobaczymy listę ról, które możemy przypisać do konkretnych zasobów lub grupy zasobów. Mimo dużej ilości dostępnych ról łatwo zauważyć, że oprócz tego, że dotyczą one konkretnych usług oferowanych na platformie Azure, kwestię uprawnień dla każdej z usług określają 3 główne poziomy (wymienione na samym początku listy):
- Owner – czyli właściciel zasobu. Przypisanie takiej roli oznacza nie tylko pełne uprawnienia w kontekście tego zasobu, ale również możliwość zarządzania uprawnieniami innych użytkowników do tego zasobu.
- Contributor – rola zawierająca pełne uprawnienia do danego zasobu, ale nie pozwalająca na zarządzanie uprawnieniami do niego
- Reader – rola pozwalająca na odczytanie zawartości zasobu, jego konfiguracji itp. ale nie pozwalająca na dokonywanie żadnych zmian. Często wykorzystywana w przypadku osób zajmujących się np. przygotowywaniem raportów
Przy okazji typów ról można jeszcze wyróżnić rolę User access administratora. Jest to rola pozwalająca wyłącznie na modyfikowanie uprawnień do danego zasobu. Ta rola znajduje swoje zastosowanie w szczególności w przypadku, gdy Globalny Administrator na skutek błędnej konfiguracji zablokuje sobie dostęp do jakiegoś zasobu. Może on nadać sobie to uprawnienie na poziomie root, co spowoduje „spłynięcie” tej roli na wszystkie obiekty znajdujące się w Azure AD (grupy, zasoby, subskrypcje itd.), która pozwoli na modyfikację uprawnień i odzyskanie dostępu do danego zasobu:
Opcje tą możemy włączyć przechodząc w Azure Active Directory do Properties i odnajdując opcję Access management for Azure resources:
Wracając do ról, konkretne uprawnienia jakie niesie ze sobą przypisanie danej roli możemy zobaczyć klikając w dowolną rolę, a następnie klikając w Permissions:
Możemy tutaj znaleźć różnego rodzaju „foldery” – uprawnienia są w ten sposób pogrupowane ze względu na usługę, której dotyczą:
Załóżmy, że interesuje nas jakie uprawnienia niesie za sobą ta rola w kontekście usługi Microsoft Key Vault:
Ten widok oferuje nam bardzo przejrzysty przegląd na konkretne uprawnienia, które są powiązane z wybraną przez nas rolą w kontekście wybranej usługi.
Azure Custom Roles
Pomimo szerokiej gamy wbudowanych ról oferowanych przez Azure może dojść do sytuacji, gdzie oferowany przez nie zestaw uprawnień nie będzie w pełni pasował do naszych potrzeb. W takich sytuacjach z pomocą przychodzi opcja Custom Roles, czyli możliwość zdefiniowania własnych ról – zarówno na bazie już istniejących, jak i określając uprawnienia zupełnie od 0.
W zależności od typu roli, którą chcemy stworzyć, będziemy to robili w innym miejscu. Dla ról w Azure AD w Azure AD Roles and administrators wykorzystujemy opcję New custom role:
W kreatorze musimy określić nazwę tworzonej roli oraz bazowe uprawnienia. Dla roli w Azure AD mamy dostępne 2 opcje:
- Start from scratch – która tworzy „pustą” rolę. Wszystkie uprawnienia, które będzie niosła ze sobą ta rola, musimy określić ręcznie
- Clone from a custom role – Dla nowo tworzonej roli bazowe uprawnienia będą takie same jak inna wybrana rola (wyłącznie stworzona przez nas, niewbudowana). Opcja ta jest przydatna, gdy chcemy doprecyzować uprawnienia bazując na innej roli lub wprowadzić kosmetyczne zmiany – zdefiniowanie uprawnień na podstawie innej roli przyśpiesza cały proces
Opcjonalnie możemy również uzupełnić opis danej roli, co w przypadku środowisk produkcyjnych jest raczej wskazane:
W zakładce Permissions możemy określić dokładne uprawnienia, jakie będą powiązane z tworzoną przez nas rolą (przy pomocy tego kreatora możemy wyłącznie wybrać zdefiniowane już uprawnienia, nie ma możliwości tworzenia „uprawnień niestandardowych”):
W ostatniej zakładce pozostaje jedynie zweryfikować poprawność i utworzyć tak zdefiniowaną rolę:
Utworzona przez nas rola jest od razu widoczna na liście. Wyróżnia się nieco innym kolorem ikony oraz wartością Custom w kolumnie Type:
W przypadku ról opartych o Azure Resource Manager sprawa wygląda nieco inaczej. Do kreatora tworzenia roli możemy przejść za pomocą opcji Add -> Add custom role, będąc w zakładce Access control dowolnego zasobu lub grupy zasobów:
W przypadku tych ról sam kreator jest nieco bardziej rozbudowany. W pierwszej zakładce już widać różnice względem omawianego przed chwilą kreatora. Po pierwsze, możemy wgrać bazowy zestaw uprawnień na podstawie utworzonego pliku w formacie JSON (Javascript Object Notation – w którym definiowane są również wszystkie zasoby w Azure). Po drugie, w przypadku opcji Clone a role mamy możliwość klonowania uprawnień przypisanych do wszystkich ról, także tych wbudowanych:
W zakładce Permissions znajdziemy opcje odpowiadające za możliwość określenia uprawnień, które zezwalają na daną czynność (Add premissions) oraz tych zabraniających określonych czynności (Exclude permissions):
Sam panel określania uprawnień również istotnie różni się od tego z omawianego przed chwilą kreatora:
W zakładce Assignable scopes za pomocą opcji Add assignable scopes mamy możliwość określenia zakresu działania danej roli – konkretne zasoby, grupy, subskrypcje:
Zakładka JSON pozwala na skonfigurowanie tworzonej roli za pomocą pliku o tym formacie:
Utworzona rola ponownie będzie wyróżniała się na liście wszystkich ról kolorem ikony oraz wartością w kolumnie Type:
Dziedziczenie ról
Niezwykle istotną kwestią, wymagającą krótkiego omówienia, w przypadku ról definiowanych dla zasobów jest ich dziedziczenie. Dla pokazania hierarchii występującej w Azure AD przygotowałem prosty schemat:
Tworzone role są dziedziczone z „warstw wyższych na niższe”. Oznacza to, że np. utworzona przez nas rola dla Resource Group będzie dostępna do wyboru w tej grupie oraz we wszystkich zasobach, które do niej należą. Gdy będziemy chcieli ustawić taką rolę dla np. naszej subskrypcji, nie będzie to możliwe – takiej roli nie będzie na liście dostępnych ról.
W drugą stronę, tworząc role na poziomie subskrypcji, będziemy mogli ją wybrać na poziomie wszystkich zasobów i grup zasobów dostępnych w obrębie tej subskrypcji. Co więcej, przypisanie danej roli na poziomie subskrypcji:
spowoduje przypisanie tej roli również w naszej grupie zasobów należącej do tej subskrypcji (oczywiście o ile określony na poziomie subskrypcji zakres to przewiduje):
Jak to zwykle bywa w przypadku dziedziczenia uprawnień, efektywne uprawnienia będą zgodne z zasadą Least Privileges. Oznacza to mniej więcej tyle, że uprawnienie Deny, niezależnie od tego, na jakim poziomie zostało ustawione, zawsze będzie ważniejsze od Allow.
W przypadku, gdy dane uprawnienie na poziomie subskrypcji będzie zabronione, a na poziomie grupy zasobów dozwolone – efektywnie będzie ono zabronione. W odwrotnej sytuacji efektywne uprawnienia będą identyczne.
Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!
