Jędrzej Boguszyński

Wyobraź sobie, że ktoś przy pomocy najprostszego phishingu zdobywa dostęp do konta jednego z administratorów globalnych w Twojej firmie. Na stałe przypisane, tak szerokie uprawnienia pozwalają atakującemu momentalnie przejąć kontrolę nad Twoim Microsoft Entra ID oraz subskrypcjami Azure, do których administrator ma dostęp. To najczarniejszy scenariusz, który może doprowadzić do całkowitego paraliżu firmy i pociągnąć za sobą poważne konsekwencje prawne, wizerunkowe oraz finansowe.

W świecie chmurowym, gdzie tożsamość stała się nową granicą bezpieczeństwa, a ludzie mogą pracować zdalnie z niemal każdego zakątka globu, tradycyjne podejście „raz nadane uprawnienia działają wiecznie” to proszenie się o katastrofę.

Odpowiednie zabezpieczenie kont o wysokich uprawnieniach (high-privileged accounts) w chmurze Microsoftu to absolutny fundament bezpieczeństwa operacyjnego IT. W tym artykule przejdziemy krok po kroku przez kompletną ścieżkę ochrony dostępów administracyjnych do środowisk Entra ID (a co za tym idzie, również Microsoft 365 i reszty aplikacji w tym ekosystemie) oraz Azure. Pokażę Wam, jak połączyć teorię architektury Zero Trust z praktyką, wykorzystując dostępne rozwiązania Microsoftu. Omówimy także, jak w codziennej pracy SysOps i SecOps weryfikować dostępy, analizować logowania i skutecznie monitorować bezpieczeństwo. Na koniec dorzucę od siebie skrypt, który pozwoli Wam w minutę zweryfikować pokrycie stałych ról administracyjnych modelem JIT (Just-In-Time access).

Zero trust (jak najmniejszy zakres uprawnień)

Model Zero Trust to obecnie absolutny fundament projektowania bezpieczeństwa w środowiskach chmurowych (zwłaszcza w ekosystemie Microsoftu). Cała ta filozofia opiera się na trzech głównych filarach:

1. Zawsze weryfikuj (Verify explicitly)

Każda próba dostępu do zasobów chmurowych musi być bezwzględnie uwierzytelniana (kim jesteś?) i autoryzowana (do czego masz prawo?) przy użyciu wszystkich dostępnych sygnałów. W praktyce oznacza to, że każde żądanie dostępu przechodzi przez rygorystyczne sito weryfikacji. System analizuje tożsamość użytkownika, jego lokalizację, stan zdrowia urządzenia (device compliance), typ usługi, protokół logowania oraz kontekst ryzyka. Nieważne, że użytkownik zalogował się poprawnie godzinę temu, jeśli zmieni się choćby jeden parametr (np. nagle połączy się z innej lokalizacji), system natychmiast wymusi ponowną weryfikację. Ten proces odbywa się w pętli, sprawiając, że zaufanie nigdy nie jest dane raz na zawsze.

2. Używaj najniższego poziomu uprawnień (Use least privileged access)

To klasyczna zasada minimalizmu: użytkownikom oraz usługom (service principals) przydzielamy wyłącznie taki zakres uprawnień, jaki jest im absolutnie niezbędny do wykonania konkretnego zadania (i ani odrobiny więcej). Przekładając to na realia Entra ID: jeśli Twój inżynier odpowiada wyłącznie za pocztę, nie nadajesz mu roli Globalnego Administratora, która pozwala na modyfikację każdego aspektu chmury. Zamiast tego otrzymuje on precyzyjnie skrojoną rolę Exchange Administratora, ograniczoną wyłącznie do zarządzania serwerem pocztowym.

3. Załóż, że do naruszenia bezpieczeństwa już doszło (Assume breach)

Projektując dostęp, infrastrukturę i mechanizmy obronne, zawsze wychodź z założenia, że haker już sforsował Twoje zabezpieczenia i aktywnie operuje wewnątrz sieci. Taki sposób myślenia zmusza do projektowania systemów w sposób, który maksymalnie ogranicza tzw. promień rażenia (blast radius) potencjalnego ataku. W praktyce oznacza to głęboką segmentację sieci i zasobów, rezygnację ze stałych uprawnień na rzecz ról aktywowanych czasowo (JIT), a także bezwzględne stosowanie osobnych kont administracyjnych dla działu IT. Chodzi o to, aby w momencie kompromitacji jednego konta, napastnik napotkał na swojej drodze mur, który uniemożliwi mu swobodne poruszanie się po środowisku, eskalację uprawnień i kradzież poufnych danych.

Bazując na tych trzech fundamentalnych zasadach, omówimy teraz konkretne mechanizmy bezpieczeństwa w Entra ID. To właśnie one, czerpiąc bezpośrednio z filozofii Zero Trust, pozwolą nam w pełni i w praktyce zabezpieczyć dostępy do naszych środowisk chmurowych oraz hybrydowych.

Microsoft PIM (Just-in-time access)

Role administracyjne przypisane na stałe to jeden z najcięższych grzechów bezpieczeństwa w chmurze. Rozwiązaniem tego problemu jest Microsoft Privileged Identity Management (PIM) oraz koncepcja Just-In-Time (JIT). Wyobraź sobie, że Twoi administratorzy na co dzień mają uprawnienia zwykłego użytkownika, a rolę Globalnego Administratora w Entra ID czy Ownera w subskrypcji Azure mogą aktywować tylko na kilka godzin i to wyłącznie po przejściu odpowiedniej weryfikacji. PIM pozwala drastycznie skrócić czas ekspozycji Twoich zasobów i sprawia, że potencjalnie skradzione konto administratora przez większość czasu jest dla hakera po prostu bezużyteczne.

Uwaga licencyjna: Funkcja ta nie jest dostępna out-of-the-box w darmowej wersji Entra ID. Wymaga posiadania licencji Microsoft Entra ID P2 lub pakietu, który ją zawiera – na przykład Microsoft Entra ID Governance lub Microsoft Entra Suite.

Konfiguracja PIM i flow przyznawania dostępu

Aby rozpocząć konfigurację PIM, musimy zalogować się do centrum administracyjnego, przejść do zakładki Identity Governance, a następnie wybrać Privileged Identity Management.

W głównym panelu PIM-a menu podzielone jest na dwie kluczowe sekcje, które precyzyjnie rozdzielają perspektywę zwykłego użytkownika od zadań administratora:

• Tasks (Zadania): To centrum operacyjne dla każdego, kto potrzebuje wyższych uprawnień. Z tego poziomu zarządzasz własnym dostępem: aktywujesz przypisane Ci role, przeglądasz status wysłanych próśb, zatwierdzasz żądania innych inżynierów (jeśli jesteś wskazany jako Approver) oraz przechodzisz procesy Access Review, czyli samoaudytu ról przypisanych do Twojego konta.
• Manage (Zarządzanie): To sekcja przeznaczona dla administratorów bezpieczeństwa. To tutaj konfigurujesz globalne reguły gry w PIM dla całej dzierżawy Entra ID, definiujesz polityki dla poszczególnych ról oraz decydujesz, kto, na jak długo i pod jakimi warunkami może wnioskować o dostęp.

Gdy klikniemy w sekcję Microsoft Entra roles, zostaniemy przeniesieni do widoku umożliwiającego precyzyjną konfigurację zasad, na jakich role mogą być przypisywane w naszym katalogu Entra ID. Wchodząc w zakładkę Roles, wybierając rolę, która nas interesuje (np. Billing Administrator lub Global Administrator), a następnie przechodząc do Role settings (Ustawienia roli), możemy dostosować parametry takie jak:

• Czas aktywacji roli: Określamy maksymalny czas (np. od 1 do 8 godzin), na jaki rola może zostać jednorazowo uruchomiona.
• Wymagania dotyczące samej aktywacji: Możemy wymusić ponowne przejście MFA podczas aktywacji lub zintegrować ten proces z zasadami dostępu warunkowego (Conditional Access Policies).
• Wymóg zatwierdzenia (Approval): Decydujemy, czy aktywacja roli wymaga zgody innej osoby i wskazujemy konkretnego zatwierdzającego (np. menedżera działu IT).
• Czas trwania kwalifikowalności (Assignment duration): Określamy, czy dany użytkownik ma mieć status „kwalifikowalnego” do roli na stałe, czy tylko na określony czas (np. w ramach projektu trwającego 3 miesiące).
• Powiadomienia (Notifications): Definiujemy, kto powinien zostać natychmiast poinformowany o aktywacji danej roli (np. wysyłając automatyczny e-mail do zespołu SOC lub na wspólną skrzynkę działu IT).

Dzięki takiemu podejściu jesteśmy w stanie bardzo szczegółowo i granularnie skonfigurować zasady aktywacji dla różnych uprawnień – dopasowując poziom restrykcji do stopnia ich krytyczności dla organizacji.

Wiele firm pozwala na automatyczną aktywację uprawnień (bez wymogu zgody drugiej osoby), ponieważ ręczne zatwierdzanie wniosków generuje dodatkowy nakład pracy dla i tak już przepracowanych administratorów. W takich scenariuszach PIM jest wykorzystywany głównie jako narzędzie audytowe, do sprawdzania, kto, kiedy i dlaczego uruchomił daną rolę. Jeżeli jednak priorytetem jest realne bezpieczeństwo, to najbardziej krytyczne role, z Global Administratorem na czele, powinny bezwzględnie wymagać manualnej aktywacji przez drugiego człowieka (tzw. zasada czterech oczu). W ten sposób minimalizujemy ryzyko, że przejęte przez hakera konto automatycznie uzyska najwyższe uprawnienia w organizacji.

Przyznawanie uprawnień

Uprawnienia przez PIM możemy nadawać na dwa sposoby: bezpośrednio z poziomu samego rozwiązania (Microsoft Entra ID roles -> Assignments -> Add assignments) lub prosto z widoku profilu konkretnego użytkownika (Assigned roles -> Add assignments).

W pierwszym przypadku proces zaczynamy od wskazania roli, którą chcemy przypisać, oraz zdefiniowania jej zakresu (ang. scope) – możemy przyznać uprawnienia na poziomie całego katalogu Entra ID lub ograniczyć je tylko do wybranej jednostki administracyjnej (Administrative Unit). W drugim widoku proces wygląda odwrotnie: wybieramy konkretnego pracownika, a następnie wskazujemy zestaw ról, do których chcemy dać mu dostęp. Oba podejścia prowadzą do tego samego celu, więc wybór zależy wyłącznie od tego, czy w danym momencie wygodniej zarządza Ci się uprawnieniami z perspektywy roli, czy użytkownika.

Podczas przypisywania roli użytkownikowi, zamiast opcji Active (przypisanie roli na stałe), wybieramy Eligible (użytkownik kwalifikuje się do aktywacji). W tym miejscu decydujemy również, czy dana osoba ma mieć możliwość uruchamiania uprawnień bezterminowo (Permanently eligible), czy tylko przez określony czas (np. na czas trwania projektu).

W przypadku etatowych pracowników działu IT standardem jest zazwyczaj przypisywanie statusu Eligible na stałe. Jeśli jednak ktoś potrzebuje dostępu na zastępstwo, dołącza do projektu na kilka miesięcy lub jest zewnętrznym kontraktorem zatrudnionym na określony czas, najlepszą praktyką jest sztywne zdefiniowanie ram czasowych tej kwalifikowalności. Dzięki temu nie musimy pamiętać o późniejszym odbieraniu uprawnień, gdy minie wyznaczona data, system automatycznie zrobi to za nas.

Po odpowiednim skonfigurowaniu i zweryfikowaniu wszystkich parametrów przypisania roli klikamy Assign i gotowe. Od tej chwili wybrany użytkownik ma bezpieczną, kontrolowaną ścieżkę do podnoszenia swoich uprawnień dokładnie wtedy, kiedy wymaga tego praca.

Zarządzanie dostępem w Azure

Microsoft Entra Privileged Identity Management pozwala na równie precyzyjne zarządzanie rolami na poziomie samych zasobów w Microsoft Azure. Przechodząc w głównym menu do sekcji Manage i wybierając Azure resources, możemy dokładnie wskazać zakres (ang. scope), na poziomie którego chcemy kontrolować uprawnienia. Do wyboru mamy pełną hierarchię chmury:

• Grupy zarządzania (Management Groups)
• Subskrypcje (Subscriptions)
• Grupy zasobów (Resource Groups)
• Poszczególne, konkretne zasoby (Resources)

Po wybraniu odpowiedniego poziomu zyskujemy możliwość identycznego konfigurowania zasad dla ról Azure (takich jak np. Owner, Contributor czy Key Vault Administrator). Możemy dokładnie tak samo decydować o czasie aktywacji, wymogu MFA czy zatwierdzaniu wniosków przez drugą osobę oraz nadawać użytkownikom status Eligible (dokładnie tak, jak robiliśmy to w przypadku ról katalogu Entra ID).

Praca z PIM od strony użytkownika

Sam proces podnoszenia uprawnień z perspektywy użytkownika końcowego jest niezwykle prosty. Przed rozpoczęciem pracy inżynier musi wejść w usługę PIM w portalu Entra ID lub Azure i wybrać opcję My roles.

Tutaj, w dwóch osobnych zakładkach – Microsoft Entra roles oraz Azure resources – widzi listę wszystkich przypisanych mu funkcji. Wystarczy, że odszuka rolę, której w danym momencie potrzebuje, i kliknie przycisk Activate.

Podczas aktywacji użytkownik wskazuje, na jak długo chce uruchomić rolę, oraz podaje uzasadnienie, dlaczego jest mu ona w tym momencie potrzebna. Notatkę tę otrzyma osoba wyznaczona do zatwierdzenia wniosku.

System uruchomi wtedy zdefiniowany przez nas proces weryfikacji (np. poprosi o kod MFA). Po spełnieniu tych wymagań i zatwierdzeniu żądania przez Approvera (jeżeli dla danej roli konfiguracja tego wymaga), uprawnienia stają się aktywne, a nasz pracownik może bezpiecznie przystąpić do swoich zadań.

Osobne konta i stacje administracyjne

Dobrą praktyką bezpieczeństwa jest też rozdzielanie kont, których osoby techniczne używają do konfiguracji infrastruktury, od kont imiennych, służących im na co dzień do przeglądania poczty czy komunikacji. Dzięki temu, w razie gdy taka osoba da się np. złapać na phishing, haker po przejęciu codziennego konta nie ma ułatwionego zadania. Aby wyrządzić realne szkody, musiałby najpierw zdobyć dostęp do drugiego, specjalnie wydzielonego konta administracyjnego, co przy dobrej higienie zarządzania hasłami i dostępem często jest dla niego ścianą nie do przeskoczenia.

Jeżeli chcemy pójść w stronę jeszcze bardziej rygorystycznego zarządzania dostępem, jeden administrator może posiadać kilka dedykowanych kont technicznych w zależności od poziomu wpływu na kluczowe systemy organizacji. Możemy wdrożyć model warstwowy, w którym administrator posiada np. konto Level 1 (do codziennych, bazowych zmian w konfiguracji) oraz konto Level 2 (służące wyłącznie do ingerowania w krytyczne elementy infrastruktury, których modyfikacja mogłaby spowodować poważny downtime).

Co najważniejsze: nawet po zalogowaniu się na takie dedykowane konto administracyjne, inżynier wciąż nie ma żadnych stałych uprawnień. Aby wykonać pracę, nadal musi każdorazowo aktywować odpowiednią rolę przy pomocy PIM-a. Połączenie separacji kont z dostępem Just-In-Time tworzy potężną, wielowarstwową synergię obronną.

Niektóre firmy z branży infrastruktury krytycznej czy sektora finansowego (takie jak banki) idą jeszcze o krok dalej. Pozwalają one na logowanie się na konta techniczne wyłącznie z poziomu specjalnie wydzielonych, bezpiecznych stacji roboczych – tzw. PAW (ang. Privileged Access Workstations), które mogą mieć formę dedykowanych maszyn fizycznych lub ściśle odizolowanych maszyn wirtualnych. Urządzenia te są rygorystycznie zarządzane przez systemy MDM, pozbawione dostępu do otwartego internetu czy skrzynek pocztowych i nieustannie monitorowane pod kątem jakichkolwiek podejrzanych zachowań.

Tę wielowarstwowość obrony możemy porównać do próby dostania się do fizycznego centrum danych. Losowa osoba z ulicy nie jest przecież wpuszczana bezpośrednio do serwerowni, by swobodnie majstrować przy przełącznikach. Aby tam dotrzeć, musi najpierw wejść na teren obiektu, wylegitymować się przed ochroną fizyczną, uzyskać odpowiednią przepustkę gościa, a następnie (przechodząc przez kolejne śluzy bezpieczeństwa i weryfikacje biometryczne) kierować się w głąb budynku, będąc przez cały czas pod czujnym okiem kamer.

Dokładnie tak samo działa opisana wyżej cyfrowa bariera. Buduje ona wielopoziomowy mur, który na każdym etapie blokuje potencjalnego napastnika. Sprawia to, że haker musi się potężnie napocić, aby wykonać jakikolwiek ruch, a im dłużej próbuje sforsować kolejne przeszkody, tym większe prawdopodobieństwo, że systemy bezpieczeństwa wykryją jego obecność, zanim zdąży wyrządzić realne szkody.

Konta breakglass – dostępy awaryjne

Konfigurując zaawansowane, wielowarstwowe systemy obrony, bardzo łatwo można przedobrzyć i przez przypadek zablokować dostęp sobie lub (co gorsza) wszystkim innym administratorom do środowiska chmurowego. W przypadku takiego całkowitego odcięcia, nawet wsparcie techniczne Microsoftu może mieć ogromny problem z przywróceniem nam dostępu (każdy, kto kiedykolwiek gorączkowo szukał starego telefonu z jedyną skonfigurowaną aplikacją MFA, doskonale wie, o co chodzi).

Inny czarny scenariusz: podczas poważnej awarii paraliżującej całą firmę, w systemie może nie być akurat nikogo, kto mógłby fizycznie zatwierdzić nam wniosek o podniesienie uprawnień w PIM-ie, które są w tej sekundzie kluczowe do przywrócenia ciągłości działania biznesu.

Co należy zrobić w takiej sytuacji? Użyć konta typu break-glass.

Konto Break-Glass (nazywane też kontem awaryjnym) działa dokładnie na zasadzie: „W razie pożaru, zbij szybę”. Jest to dedykowane konto z najwyższymi uprawnieniami Global Administratora w naszej dzierżawie Entra ID, które jest celowo wyłączone ze standardowych polityk bezpieczeństwa (takich jak dostęp warunkowy czy klasyczne, zależne od urządzeń MFA). Trzymamy je w rezerwie i uruchamiamy wyłącznie w sytuacjach skrajnego kryzysu, gdy standardowe, imienne konta administracyjne są z jakichkolwiek przyczyn całkowicie niedostępne.

Jako że konto awaryjne jest wysoce uprzywilejowane i z założenia omija standardowe zabezpieczenia, jego przejęcie jest równoznaczne z oddaniem atakującemu pełnej kontroli nad całą infrastrukturą chmurową. Aby drastycznie zminimalizować to ryzyko, przy wdrażaniu konta break-glass należy bezwzględnie przestrzegać poniższych zasad:

• Pełna anonimizacja: Nazwa konta nie powinna zawierać słów kluczowych takich jak „admin”, „administrator”, „breakglass” czy „awaryjne”. Nazwij je w sposób neutralny, tak aby podczas ewentualnego rekonesansu atakującego wewnątrz infrastruktury nie rzucało się ono w oczy i wyglądało na zwykłe konto użytkownika.
• Ekstremalnie silne hasło i zasada podziału: Hasło powinno składać się z minimum 64 do 128 losowych znaków (alternatywnie można użyć dedykowanego klucza sprzętowego FIDO2 zamkniętego w sejfie). Musi być przechowywane w bezpiecznym, odizolowanym menedżerze haseł (lub fizycznej skrytce), do którego dostęp ma wyłącznie kluczowy personel IT. Dobrą praktyką jest podzielenie hasła na pół i przekazanie każdej części innej osobie, dzięki temu nikt nie jest w stanie użyć konta samodzielnie (tzw. zasada dualnej autoryzacji).
• Jednorazowy charakter: Każde zalogowanie na konto awaryjne powinno być traktowane jak incydent bezpieczeństwa. Po zakończeniu prac i zażegnaniu kryzysu, dotychczasowe konto (lub jego dane uwierzytelniające) należy natychmiast unieważnić, a następnie wygenerować zupełnie nowe hasło (lub nowe konto), które z powrotem trafi do bezpiecznej skrytki.

Konta usług, aplikacji i serwisów

Omówiliśmy już szczegółowo temat logowań pracowników, czyli tzw. kont ludzkich. Co jednak z szeroko pojętą tożsamością maszynową? Jak podejść do zabezpieczania kont usług, aplikacji czy wszelkiego rodzaju zewnętrznych skryptów, które muszą uwierzytelnić się przez API w naszej Entra ID, aby wykonać zautomatyzowane działania?

Większość omawianych wcześniej mechanizmów bezpieczeństwa (takich jak ręczna aktywacja roli w PIM-ie czy zatwierdzanie powiadomień push MFA) wymaga interakcji ze strony człowieka. Dla autonomicznej aplikacji jest to bariera nie do przejścia. Dlatego konfigurując konta serwisowe (rejestrowane w Entra ID jako App Registrations, a w kontekście uprawnień reprezentowane przez Service Principals), musimy bezwzględnie kierować się żelazną zasadą minimalnych uprawnień (Least Privilege).

Aplikacja powinna mieć dostęp tylko i wyłącznie do tych punktów końcowych API, które są jej niezbędne do funkcjonowania, i operować na absolutnie minimalnym zakresie danych. W przypadku integracji z API (np. Microsoft Graph) w Entra ID mamy do dyspozycji dwa typy uprawnień:

• Application permissions: Uprawnienia są przypisane bezpośrednio do samej aplikacji (konta serwisowego). Działa ona w tle jako usługa systemowa lub demon, bez udziału jakiegokolwiek użytkownika. Poziom jej uprawnień jest stały i niezależny od tego, kto akurat korzysta z systemu.

• Delegated permissions: Aplikacja potrzebuje do działania interakcji człowieka. Użytkownik musi zalogować się do niej (np. poprzez protokół SSO), a aplikacja wykonuje operacje w API w jego imieniu. W tym scenariuszu ostateczny zakres możliwości aplikacji jest wypadkową jej własnych uprawnień oraz uprawnień zalogowanego w danej chwili pracownika (aplikacja nigdy nie zrobi więcej, niż pozwala na to rola danego użytkownika).

Jak to wygląda w praktyce?
Jeśli wdrażamy w organizacji aplikację, do której pracownicy logują się przez SSO i która służy np. wyłącznie do odczytywania ich spotkań z kalendarza Outlook, powinniśmy przypisać jej kontu serwisowemu uprawnienia delegowane (Delegated). Dzięki temu aplikacja (działając w imieniu zalogowanego użytkownika) będzie mogła odczytać wyłącznie jego własny kalendarz. Gdybyśmy w tym samym scenariuszu popełnili błąd i użyli uprawnień aplikacyjnych (Application), nasza usługa zyskałaby uprawnienia do odczytu kalendarzy wszystkich osób w całej firmie (w tym zarządu), co w przypadku ewentualnego przejęcia kluczy do aplikacji skończyłoby się poważnym wyciekiem danych.

Dostęp warunkowy

Dostęp Warunkowy (Entra ID Conditional Access) to absolutne serce bezpieczeństwa w ekosystemie Microsoftu. Zgodnie z opisywaną wcześniej filozofią Zero Trust, polityki dostępu warunkowego nieustannie analizują setki napływających sygnałów (tzw. telemetrię), aby precyzyjnie zweryfikować każdą próbę logowania do naszych zasobów chmurowych (zarówno w przypadku kont użytkowników, jak i kont serwisowych). Co więcej, reguły te mogą być bezpośrednio powiązane z PIM-em, tworząc obowiązkowe ścieżki dodatkowej weryfikacji tożsamości przy każdej próbie aktywacji wysoko uprzywilejowanej roli.

Uwagi licencyjne: Aby korzystać z polityk dostępu warunkowego w Entra ID, potrzebujemy przynajmniej licencji Microsoft Entra ID P1.

Jak to wygląda w praktyce?

Możemy skonfigurować rygorystyczną politykę, która zezwoli na zalogowanie się na konto administratora wyłącznie wtedy, gdy zostaną spełnione wszystkie poniższe warunki:

• Zaufane urządzenie: Logowanie jest możliwe tylko z komputera wpiętego do domeny Entra ID i w pełni zgodnego z normami bezpieczeństwa (compliance policy) narzucanymi centralnie przez system Microsoft Intune.
• Bezpieczna lokalizacja: Ruch musi pochodzić wyłącznie ze zweryfikowanych adresów IP należących do fizycznych biur naszej firmy lub bezpiecznego tunelu VPN.
• Silne uwierzytelnianie: Tożsamość musi zostać potwierdzona przy użyciu metody MFA odpornej na phishing (ang. phishing-resistant MFA), np. za pomocą sprzętowego klucza FIDO2 lub biometrii Windows Hello for Business.

Dzięki takiemu podejściu, nawet jeśli cyberprzestępca wejdzie w posiadanie loginu i hasła administratora, jego próba logowania zostanie natychmiast zablokowana na samym wejściu, ponieważ nie będzie korzystał z firmowego laptopa i nie przejdzie sprzętowej autoryzacji.

Jeżeli chcesz dowiedzieć się więcej o konfiguracji dostępu warunkowego, zapraszam do mojego innego artykułu.

Okresowy przegląd uprawnień

Nawet jeśli bardzo dbamy o higienę nadawania i odbierania uprawnień, to czas oraz nawał bieżących obowiązków nieuchronnie działają na naszą niekorzyść. Prędzej czy później (nawet w mniejszych organizacjach) w przypisaniach ról zaczyna pojawiać się chaos.

Na ratunek przychodzi nam tutaj funkcja Microsoft Entra ID Access Reviews (część pakietu Entra ID Governance). Pozwala ona na konfigurowanie automatycznych, uruchamianych okresowo, a nawet wieloetapowych przeglądów (recenzji) uprawnień.

Uwagi licencyjne: Korzystanie z funkcji Access Reviews wymaga posiadania licencji Microsoft Entra ID P2

Jak to działa w praktyce?

Możemy skonfigurować automatyczny, kwartalny przegląd uprawnień dla wybranego zespołu projektowego, który będzie składał się z trzech prostych kroków:

1. Samoocena użytkownika: W pierwszym etapie pracownicy sami się weryfikują. Otrzymują powiadomienie mailowe i wypełniają krótką ankietę, deklarując, czy dany dostęp jest im wciąż niezbędny do wykonywania codziennych zadań.
2. Weryfikacja przełożonego: Ich odpowiedzi trafiają bezpośrednio do Project Managera (lub właściciela zasobu), który musi zatwierdzić deklaracje pracowników i podjąć ostateczną decyzję.
3. Automatyzacja lub decyzja IT: Na koniec system może automatycznie odebrać uprawnienia osobom, które ich już nie potrzebują (lub nie odpowiedziały na wezwanie), bądź też przesłać kompletny raport do działu IT, który ręcznie dokona niezbędnych modyfikacji.

Jeżeli interesuje Cię ten temat i chcesz dowiedzieć się więcej, odsyłam do mojego innego artykułu.

Monitoring bezpieczeństwa tożsamości

Jako że tożsamość jest granicą bezpieczeństwa w chmurze, warto ją na bieżąco monitorować w celu wykrywania nieprawidłowości, zanim przerodzą się one w incydenty.

Wszelkie próby logowania do Microsoft Entra ID (oraz powiązanych aplikacji i środowisk), weryfikacje polityk Dostępu Warunkowego (Conditional Access) czy aktywacje ról w PIM (Privileged Identity Management) są rejestrowane w dziennikach aktywności. Logi te możemy analizować z poziomu konkretnego użytkownika lub aplikacji w sekcjach Audit logs (logi audytowe) oraz Sign-in logs (logi logowania). Czas przechowywania (retencji) tych danych zależy od posiadanej licencji:

• w wersji bezpłatnej (Free) wynosi on 7 dni,
• w wersjach premium (P1 oraz P2) wynosi 30 dni.

Dodatkowo, posiadając licencję Microsoft Entra ID P2, zyskujemy dostęp do zaawansowanego modułu ID Protection. Pozwala on na automatyczne wykrywanie zagrożeń (zarówno na poziomie pojedynczego logowania, jak i całego konta użytkownika) oraz flagowanie podejrzanych kont, które wymagają weryfikacji przez administratorów. Dane telemetryczne z ID Protection mogą być również używane jako warunek w regułach Dostępu Warunkowego (np. do automatycznego wymuszenia MFA przy podwyższonym ryzyku). Logi z tego obszaru są przechowywane przez 90 dni.

Wiele firm działających w ekosystemie Microsoftu wdraża również rozwiązanie Microsoft Defender for Identity. Narzędzie to wykorzystuje globalną bazę wiedzy o zagrożeniach (Microsoft Threat Intelligence) do automatycznego wykrywania i blokowania zaawansowanych prób ataków na naszą tożsamość w czasie rzeczywistym.

MDI dostarcza również gotowe scenariusze i narzędzia do ciągłej oceny stanu bezpieczeństwa (Security Posture) naszej tożsamości, wraz z konkretnymi rekomendacjami, jak możemy skuteczniej uszczelnić cały system. Warto dodać, że uproszczona wersja takich zaleceń jest dostępna dla każdego również bezpośrednio w darmowej, bazowej wersji Entra ID w zakładce Secure Score.

Jeżeli Wasza firma posiada własne centrum operacji bezpieczeństwa (SOC) oraz system klasy SIEM (np. Wazuh czy Microsoft Sentinel), możecie pójść krok dalej. Logi zdarzeń z Entra ID oraz całą telemetrię o incydentach wykrytych przez Microsoft Defender można bez problemu przekazywać bezpośrednio do systemu SIEM.

Pozwala to zespołowi ds. bezpieczeństwa na zaawansowaną korelację zdarzeń z wielu różnych źródeł (np. łączenie podejrzanego logowania w chmurze z aktywnością na stacji roboczej) oraz sprawną analizę potencjalnych zagrożeń. Dodatkowo takie scentralizowane logowanie ułatwia spełnienie rygorystycznych wymagań dotyczących retencji danych (przechowywania logów), co jest kluczowe z punktu widzenia zgodności z przepisami i standardami bezpieczeństwa (compliance).

🎁 Bonus – skrypt do audytowania pokrycia PIM

Dodatkowo, jako bonus do artykułu, dorzucam swój autorski skrypt PowerShell służący do audytowania wdrożenia PIM-a. Kod oraz instrukcję uruchomienia znajdziecie bezpośrednio na moim GitHubie.

Ważna uwaga: Skrypt podczas działania kilkukrotnie poprosi o zalogowanie się do Entra ID oraz Azure. Aby audyt mógł zostać wykonany w pełni poprawnie, należy użyć konta posiadającego odpowiednie uprawnienia – najlepiej z przypisaną rolą Global Reader (Czytelnik globalny).

I jeszcze jedna, żelazna zasada: zawsze, gdy uruchamiacie jakiekolwiek skrypty z internetu (zwłaszcza te, które wymagają uwierzytelnienia w Waszym środowisku tożsamości), najpierw dokładnie przejrzyjcie ich kod i upewnijcie się, że są w stu procentach bezpieczne (w przypadku dużych skryptów, można wrzucić je do AI w celu weryfikacji)!

Co dokładnie robi ten skrypt?

• Skanuje całe środowisko: Weryfikuje wszystkie przypisane na stałe (aktywne) role wysokiego ryzyka w Microsoft Entra ID lub powiązanych subskrypcjach Azure.
• Analizuje konfigurację: Zestawia stałe uprawnienia z rolami kwalifikowanymi (dostępnymi na żądanie) przypisanymi przez PIM.
• Wskazuje słabe punkty: Wypisuje precyzyjnie, które przypisania są niezgodne z najlepszymi praktykami i wymagają natychmiastowej poprawy.
• Liczy wskaźnik pokrycia: Pokazuje, jaki jest realny procentowy wskaźnik pokrycia PIM dla całego Waszego środowiska.

Sam audyt odbywa się w pełni interaktywnie w konsoli PowerShell, ale po skończonej weryfikacji skrypt automatycznie generuje również estetyczny raport w formacie HTML, idealny do podesłania przełożonemu lub zarządowi jako podsumowanie stanu bezpieczeństwa infrastruktury (lub jako podkładka pod audyt).