Użytkownicy, grupy i przypisania ról

Azure Role-Based Access Control (RBAC) to system autoryzacji określający, kto może wykonywać jakie działania na zasobach platformy Azure. Zamiast przypisywać uprawnienia bezpośrednio pojedynczym osobom, przypisuje się role podmiotom zabezpieczeń (użytkownikom, grupom, jednostkom usługi lub tożsamościom zarządzanym) w określonym zakresie. Taki podział ułatwia zarządzanie uprawnieniami w miarę rozwoju organizacji.

Każde przypisanie RBAC obejmuje trzy elementy. Podmiot zabezpieczeń to odbiorca dostępu (użytkownik, grupa lub tożsamość zarządzana). Definicja roli określa dozwolone działania (np. odczytywanie maszyn wirtualnych lub zapisywanie danych w magazynie). Zakres określa miejsce obowiązywania dostępu — od najszerszego do najwęższego: grupa zarządzania, subskrypcja, grupa zasobów lub pojedynczy zasób. Dostęp jest dziedziczony w dół hierarchii zakresów.

Azure udostępnia setki ról wbudowanych. Cztery najczęściej używane we wszystkich typach zasobów to: Owner — pełny dostęp, w tym możliwość przypisywania ról innym osobom; Contributor — pełny dostęp do tworzenia zasobów i zarządzania nimi, ale bez możliwości udzielania dostępu innym; Reader — dostęp tylko do odczytu; oraz User Access Administrator — możliwość zarządzania przypisaniami ról bez samodzielnego zarządzania zasobami.

Przypisanie roli nadaje określonemu podmiotowi zabezpieczeń uprawnienia zdefiniowane w definicji roli w określonym zakresie. Przypisania ról są propagowane do wszystkich zakresów podrzędnych — przypisanie roli Contributor na poziomie grupy zasobów zapewnia dostęp Contributor do każdego zasobu w tej grupie. Przypisanie na poziomie subskrypcji zapewnia dostęp Contributor we wszystkich grupach zasobów tej subskrypcji.

Zasada najmniejszych uprawnień stanowi, że każda tożsamość powinna mieć wyłącznie minimalny zestaw uprawnień niezbędnych do wykonywania swoich zadań. W Azure RBAC oznacza to: preferowanie roli Reader zamiast Contributor, gdy zapis nie jest potrzebny, preferowanie zakresu grupy zasobów zamiast zakresu subskrypcji oraz używanie w miarę możliwości konkretnych ról na poziomie zasobu (np. Storage Blob Data Contributor) zamiast szerokiej roli Contributor.

Jeśli żadna rola wbudowana nie spełnia dokładnie wymagań, można utworzyć rolę niestandardową. Definicja roli niestandardowej określa zestaw elementów Actions (dozwolone operacje w płaszczyźnie sterowania), NotActions (wykluczone z dozwolonego zestawu), DataActions (operacje w płaszczyźnie danych na zasobach, takie jak odczytywanie zawartości obiektu blob) oraz AssignableScopes (subskrypcje lub grupy zarządzania, w których można przypisać rolę).

Przypisywanie ról grupom, a nie pojedynczym użytkownikom, jest najlepszą praktyką. Gdy nowy deweloper dołącza do zespołu DevTeam, należy dodać go do grupy zabezpieczeń DevTeam w Entra ID — automatycznie odziedziczy wszystkie przypisania ról posiadane przez grupę, bez wprowadzania zmian w Azure RBAC. Ten centralny punkt zarządzania zapobiega rozproszonym przypisaniom indywidualnym, które trudno później kontrolować lub odbierać podczas procesu odejścia pracownika.

Jednostka usługi to tożsamość używana przez aplikacje, skrypty i narzędzia automatyzacji do uwierzytelniania w platformie Azure i uzyskiwania dostępu do zasobów. W przeciwieństwie do tożsamości użytkownika jednostki usługi nie mogą logować się interaktywnie. Tworzy się je na podstawie rejestracji aplikacji w Entra ID, a następnie przypisuje im role RBAC w odpowiednim zakresie — na przykład przyznając potokowi CI/CD dostęp Contributor do pojedynczej grupy zasobów w celu wdrażania infrastruktury.

Przypisania odmowy blokują określone działania podmiotów zabezpieczeń, nawet jeśli przypisanie roli w innym przypadku by je umożliwiało. W przeciwieństwie do przypisań ról przypisań odmowy nie mogą tworzyć bezpośrednio administratorzy — są dołączane przez Azure Blueprints lub aplikacje zarządzane, aby uniemożliwić użytkownikom modyfikowanie chronionych zasobów. Przypisanie odmowy ma pierwszeństwo przed każdym pasującym przypisaniem roli.

Privileged Identity Management (PIM) to funkcja Entra ID P2 zapewniająca uprzywilejowany dostęp na żądanie. Zamiast przypisywać na stałe rolę Owner lub Global Administrator, oznacza się użytkowników jako kwalifikujących się do tej roli. Gdy jest ona potrzebna, użytkownik aktywuje przypisanie na czas określony (np. 1–8 godzin), opcjonalnie z wymaganiem zatwierdzenia i podania uzasadnienia. Znacząco ogranicza to stałą powierzchnię ataku wynikającą z kont posiadających nadmierne uprawnienia.

Przeglądy dostępu (Entra ID P2) to okresowe, zautomatyzowane przeglądy, w ramach których właściciele zasobów lub menedżerowie potwierdzają, czy członkowie ich zespołów nadal potrzebują bieżących przypisań ról. Osoby dokonujące przeglądu zatwierdzają lub odrzucają dalszy dostęp bezpośrednio w interfejsie przeglądu. Pozwala to wykrywać nieaktualne uprawnienia pozostałe po zmianie roli, zakończeniu projektu lub odejściu pracownika — jest to kluczowy wymóg programów zgodności z przepisami.

W tej lekcji poznali Państwo następujące informacje: Azure RBAC przypisuje role podmiotom zabezpieczeń w określonym zakresie, zasada najmniejszych uprawnień oznacza przyznawanie wyłącznie minimalnych wymaganych uprawnień, a PIM zapewnia aktywację ról o wysokich uprawnieniach na żądanie zamiast ich stałego przypisania. W następnej części omówimy uwierzytelnianie wieloskładnikowe i dostęp warunkowy w Entra ID.