Pentest Microsoft Entra ID: techniczna metodyka

Pentest Microsoft Entra ID ocenia, czy przejęty użytkownik, administrator o ograniczonej roli, aplikacja albo workload identity może uzyskać dostęp szerszy niż przewidział właściciel tenanta. Zakres obejmuje uwierzytelnianie, Conditional Access, role katalogowe, Azure RBAC, aplikacje enterprise, consent, Microsoft Graph, service principals, sekrety i certyfikaty, PIM, gości B2B, synchronizację hybrydową oraz logowanie i reakcję.

Najważniejsza odpowiedź: Entra ID nie testuje się jak pojedynczego portalu WWW. To graf tożsamości, poświadczeń, grantów OAuth, scope’ów administracyjnych i zaufania pomiędzy chmurą a Active Directory. Skuteczna ocena łączy konfigurację z kontrolowanymi scenariuszami negatywnymi i nie atakuje infrastruktury Microsoft, innych tenantów ani kont osób trzecich.

Dobry raport rozróżnia możliwość uzyskania tokenu od efektywnych praw do konkretnego zasobu. Rozróżnia także role Microsoft Entra, role Azure Resource Manager i uprawnienia Microsoft Graph — nazwy mogą brzmieć podobnie, ale działają w innych płaszczyznach.

Najpierw zakres i reguły Microsoft

Właściciel tenanta może autoryzować test swojej konfiguracji, aplikacji i zasobów, ale nie daje to prawa do testowania współdzielonej infrastruktury dostawcy. Reguły zaangażowania wymieniają tenant ID, subskrypcje, aplikacje, konta testowe, dozwolone źródła, okno, limity API, działania zabronione i kontakt awaryjny. Zapisujemy aktualne Microsoft Cloud Penetration Testing Rules of Engagement.

Nie wykonujemy DoS, masowego password spray, phishingu pracowników Microsoft, prób wejścia do innych tenantów ani destrukcyjnych zmian. Test logowania, consentu i ról korzysta z kontrolowanych użytkowników oraz aplikacji. Jeśli w trakcie odczytu pojawią się dane innej organizacji, zatrzymujemy scenariusz i uruchamiamy procedurę incydentową.

Metodyka jest zbliżona do zasad opisanych w pentestach AWS, Azure i GCP, ale warstwa Entra zasługuje na osobny model: jedna tożsamość może wpływać na Microsoft 365, Azure, aplikacje SaaS i synchronizowane AD.

Model techniczny: tenant, aplikacja i service principal

Application object reprezentuje globalną definicję rejestracji aplikacji w jej home tenant. Service principal jest lokalną instancją aplikacji w konkretnym tenancie i to do niego wiążą się granty, assignmenty oraz część właściwości. Dla aplikacji wielodostępnej jeden application object może mieć service principal w wielu tenantach po consent lub provisioning.

W ocenie trzeba rozróżnić:

delegated permissions — aplikacja działa w kontekście zalogowanego użytkownika, zwykle w przecięciu praw użytkownika i przyznanych scope’ów;
application permissions — aplikacja działa bez użytkownika jako workload i może mieć szeroki dostęp organizacyjny;
Microsoft Entra roles — zarządzają obiektami i funkcjami katalogu;
Azure RBAC roles — autoryzują operacje na zasobach ARM w management group, subskrypcji, resource group lub zasobie;
app roles i grupy — mogą sterować autoryzacją w konkretnej aplikacji;
ownership — właściciel aplikacji/service principal może mieć możliwości administracyjne, które trzeba ocenić niezależnie od nazwy roli.

Wiele istotnych ścieżek wynika z kontroli poświadczenia aplikacji, prawa dodania credential, szerokiego Graph application permission albo możliwości nadania roli. Sama lista Global Administrator nie pokazuje pełnego blast radius.

Tokeny OAuth i OpenID Connect

Pentest aplikacji zintegrowanych z Entra weryfikuje walidację podpisu, issuer, audience, czasu, nonce/state/PKCE, redirect URI oraz właściwe użycie access tokenu i ID tokenu. API nie powinno przyjmować ID tokenu jako biletu do danych. Aplikacja multi-tenant musi walidować dozwolonych issuerów i powiązać tenant z klientem biznesowym, zamiast akceptować dowolny poprawnie podpisany token Entra.

Token nie jest dokumentem „dla każdego Microsoft API”. Audience określa zasób. Claim roles zwykle niesie application roles, scp — delegated scopes, a grupy mogą podlegać overage i wymagać dodatkowego odczytu. Kod autoryzacyjny nie może zakładać, że brak claimu oznacza brak grup w katalogu; musi obsłużyć udokumentowany mechanizm.

Testujemy wylogowanie, odebranie roli, unieważnienie sesji, refresh token i Continuous Access Evaluation dla obsługiwanych zasobów. „Użytkownik został wyłączony” nie zawsze unieważnia każdy już wydany token natychmiast w dowolnej aplikacji. Aplikacja musi poprawnie obsługiwać claims challenge i odmowę zasobu.

Pełny model aktualnych zaleceń OAuth przedstawiamy w artykule OAuth 2.0 i RFC 9700. W pentestach nie kradniemy tokenów prawdziwych użytkowników; używamy własnych sesji i zatwierdzonych scenariuszy.

Consent phishing wykorzystuje legalny ekran zgody do uzyskania dostępu przez aplikację. Obrona zaczyna się przed phishingiem: polityka user consent powinna ograniczać, jakie aplikacje i scope’y użytkownik może zatwierdzić. Microsoft zaleca w typowych środowiskach zezwalanie na zgodę tylko dla aplikacji zweryfikowanych wydawców i wybranych uprawnień niskiego wpływu, uzupełnione workflow admin consent.

Audyt obejmuje:

polityki user/admin consent i uprawnionych reviewerów;
wszystkie enterprise applications, publisher verification i datę pierwszego consentu;
delegated permission grants oraz app role assignments;
application permissions do Microsoft Graph i innych API;
właścicieli, certyfikaty, sekrety, federated identity credentials i reply URLs;
aplikacje nieaktywne, nieużywane granty i osierocone service principals.

Uprawnienie oceniamy według operacji, nie nazwy. Przykładowo prawo odczytu całego zbioru plików lub poczty przez aplikację działającą bez użytkownika ma inny wpływ niż delegowany dostęp jednego użytkownika. Microsoft zaleca least privilege, okresowy przegląd i usuwanie reducible permissions. Raport wskazuje konkretną minimalną alternatywę, jeśli API ją publikuje.

W kontrolowanej walidacji tworzymy testową aplikację albo używamy aplikacji klienta w sandboxie. Nie prosimy administratora o grant krytycznego uprawnienia tylko dla demonstracji. Gdy konfiguracja pokazuje, że właściciel może dodać credential do już uprzywilejowanego service principal, wystarcza dowód prawa i nieszkodliwa zmiana w dedykowanej aplikacji.

Workload identities, sekrety i federacja

Workload identity reprezentuje aplikację, skrypt, kontener lub usługę. W przeciwieństwie do użytkownika nie wykona MFA, często ma kilka credentiali i bywa pozbawiona właściciela lifecycle. Dlatego ocena service principals i managed identities jest równie ważna jak kont ludzi.

Preferowany model usuwa statyczne sekrety tam, gdzie można użyć managed identity lub workload identity federation. Federacja ufa tokenom z zewnętrznego IdP, np. pipeline’u, na podstawie issuer/subject/audience. Zbyt szeroki wzorzec subject albo kontrola nad repozytorium/pipeline’em może rozszerzyć, kto uzyska token Entra. Audytujemy więc zarówno credential federacyjny, jak i uprawnienia w systemie źródłowym.

Dla pozostałych sekretów sprawdzamy miejsce przechowywania, termin ważności, rotację, ekspozycję w kodzie/CI, właściciela i użycie. Certyfikat aplikacji zwykle jest lepszy od shared secret, ale skradziony klucz prywatny nadal jest poświadczeniem. Wymagamy HSM/Key Vault adekwatnie do ryzyka i blokujemy eksport, jeśli nie jest potrzebny.

Conditional Access dla workload identities ma zakres i wymagania licencyjne inne niż polityki użytkowników. Microsoft dokumentuje, że polityki muszą kierować się bezpośrednio do service principal; przypisanie do grupy zawierającej service principal nie egzekwuje policy. Managed identities i część aplikacji wielodostępnych także mają inne pokrycie. Raport nie powinien deklarować „wszystkie aplikacje są chronione CA” bez sprawdzenia tych wyjątków.

Role katalogowe, Azure RBAC i ścieżki eskalacji

Najpierw katalogujemy aktywne, eligible i grupowe przypisania ról. Dla każdej roli sprawdzamy scope, czas, źródło, możliwość zarządzania credentialami, grupami role-assignable, aplikacjami i innymi rolami. Role pozornie wsparciowe mogą resetować metody uwierzytelniania określonych użytkowników; ograniczenia administracyjne i protected actions trzeba ocenić na aktualnej dokumentacji.

Azure RBAC analizujemy oddzielnie. Owner lub User Access Administrator na subskrypcji może nadawać dostęp do zasobów Azure, ale nie jest tym samym co Global Administrator. Global Administrator może w określonym procesie podnieść dostęp do zarządzania subskrypcjami; to zdarzenie powinno być monitorowane. Ścieżki między płaszczyznami są ważniejsze niż etykiety pojedynczych ról.

PIM zmniejsza standing access przez eligible assignment, czasową aktywację, approval, MFA, justification i alerty. Nie poprawia jednak automatycznie źle zaprojektowanego scope’u. Jeśli wszyscy administratorzy mogą aktywować Global Admin bez approval na wiele godzin, ryzyko nadal jest duże. Recurring access reviews powinny usuwać niepotrzebne role, gości i właścicieli aplikacji.

Model operacyjny rozwijamy w artykule PAM — zarządzanie dostępem uprzywilejowanym.

Conditional Access: test decyzji, nie liczby polityk

Conditional Access jest silnikiem polityk opartym na sygnałach użytkownika/workloadu, zasobu, urządzenia, lokalizacji, ryzyka i metody uwierzytelnienia. Duża liczba policy nie gwarantuje dobrego pokrycia. Szukamy luk w scope, wykluczeń, polityk report-only, nieobjętych typów logowania, zaufanych lokalizacji i konfliktów między grant controls.

Macierz testowa powinna obejmować:

zwykłego użytkownika i administratora;
gościa, konto synchronizowane i cloud-only;
urządzenie compliant, registered i unmanaged;
logowanie interaktywne, legacy authentication oraz wybrane przepływy noninteractive;
aplikacje krytyczne i zasoby spoza Microsoft 365;
service principal tam, gdzie CA for workload identities ma zastosowanie;
ryzyko użytkownika/logowania, Authentication Strength i phishing-resistant MFA.

Nową politykę testujemy narzędziem What If, w report-only i na grupie pilotażowej. Wykluczenia awaryjne są konieczne, ale powinny obejmować co najmniej dwa cloud-only emergency access accounts, monitorowane przy każdym użyciu. Nie logujemy się nimi podczas zwykłego pentestu bez wyraźnej zgody; testujemy alarm i procedurę poprzez zatwierdzony scenariusz.

MFA opisane jako „enabled” nie wystarcza. Liczy się metoda i odporność na phishing. SMS lub push bez kontekstu mają inny profil niż FIDO2/passkey lub certificate-based authentication. Plan migracji opisujemy w przewodniku wdrożenia MFA w firmie.

Emergency access bez fałszywego poczucia bezpieczeństwa

Microsoft zaleca co najmniej dwa cloud-only konta awaryjne z trwałą rolą Global Administrator, przeznaczone wyłącznie do odzyskania dostępu. Ich metody uwierzytelniania powinny być niezależne od zwykłej infrastruktury, poświadczenia przechowywane bezpiecznie, a każde użycie alarmowane.

Pentest sprawdza istnienie, niezależność domeny/federacji, wykluczenia CA, monitoring, procedurę dostępu dwuosobowego i ćwiczenia. Nie ujawniamy sekretu ani nie wymuszamy realnego lockoutu. Test tabletop może potwierdzić, czy zespół odnajdzie poświadczenia, skontaktuje właściwe osoby i odtworzy dostęp w założonym czasie.

Konto break-glass jest kontrolą odzyskania, nie wygodnym wyjątkiem dla automatyzacji. Każde regularne logowanie powinno być traktowane jako incydent albo błąd procesu.

Goście B2B, cross-tenant access i aplikacje multi-tenant

Gość zachowuje powiązanie z zewnętrznym home tenantem. Polityki cross-tenant access określają, czy organizacja ufa MFA i device claims partnera oraz jakie połączenia inbound/outbound dopuszcza. Domyślna otwartość, wyjątki organizacyjne i direct connect powinny mieć właściciela.

Audytujemy zaproszenia, sponsorów, wygasanie, access reviews, grupy dynamiczne i aplikacje dostępne dla guests. Usunięcie projektu powinno odebrać rolę, grupę, entitlement package i sesje. Gość w role-assignable group albo jako właściciel aplikacji może mieć wpływ niewidoczny w prostym raporcie „Guest users”.

W aplikacjach multi-tenant poprawny token z innej organizacji nie wystarcza do utworzenia lokalnego klienta. Potrzebna jest jawna relacja onboardingowa, walidacja issuer/tenant i przypisanie uprawnień. Temat izolacji rozwijamy w pentestach tenant isolation SaaS.

Tożsamość hybrydowa: ścieżki z AD do chmury

Microsoft zaleca unikanie synchronizowanych kont w rolach chmurowych tam, gdzie można użyć cloud-native admin identities. Kompromitacja on-prem może inaczej przejść do Entra. Audytujemy model Password Hash Sync, Pass-through Authentication lub federacji, serwer Microsoft Entra Connect/Cloud Sync, konta connectorów, uprawnienia zapisu zwrotnego i staging mode.

Serwer synchronizacji jest zasobem krytycznym. Sprawdzamy administratorów lokalnych, konta usług, bazę, patching, EDR, backup, ruch sieciowy i monitorowanie. W AD oceniamy prawa do obiektów synchronizowanych oraz możliwość zmiany atrybutów, które wpływają na chmurową tożsamość. Szczegóły domenowej części znajdują się w technicznej analizie Active Directory.

Nie wykonujemy destrukcyjnej zmiany synchronizacji. Bezpieczny test używa dedykowanego OU i użytkownika, mierzy oczekiwany przepływ oraz potwierdza, że niedozwolony atrybut lub rola nie jest przenoszona.

Bezpieczna metodologia pentestu Entra ID

1. Discovery tylko z zatwierdzonego konta

Zbieramy tenant properties, domains, role assignments, CA, named locations, authentication methods, applications, service principals, grants, credential metadata, guests, devices, PIM, access reviews, logs i konfigurację hybrid identity. Nie pobieramy treści skrzynek ani plików, jeśli nie jest to osobno potrzebne do dowodu.

2. Graf uprawnień i scenariusze

Łączymy principal → credential/control → role/grant → resource → business impact. Oznaczamy, czy ścieżka jest aktywna, eligible, wymaga consentu/approval, działa tylko z urządzenia albo zależy od AD. Każdy krytyczny krok potwierdzamy w dokumentacji API i konfiguracji klienta.

3. Kontrolowana walidacja

Używamy dedykowanych użytkowników, aplikacji, grup i zasobów. Testujemy negatywny dostęp, PIM activation, report-only CA, odebranie consentu, rotację credential i alarm. Nie nadajemy testowej aplikacji szerokiego Graph application permission w produkcji tylko dla demonstracji.

4. Cleanup i dowód odwracalności

Usuwamy testowe granty, role, credentiale, aplikacje i sesje; potwierdzamy logi audytowe. Retest sprawdza brak tokenu/dostępu po zmianie i zachowanie legalnych przepływów.

Logi i detekcja w Microsoft Entra

Minimum to przechowywanie i eksport Sign-in logs, Audit logs, Provisioning logs oraz danych z PIM/Identity Protection do odseparowanego workspace/SIEM zgodnie z wymaganym okresem. Osobno analizujemy interactive user, non-interactive user, service principal i managed identity sign-ins. Jeden dashboard „user sign-ins” nie pokazuje workloadów.

Wysokowartościowe alerty obejmują:

dodanie credential do uprzywilejowanej aplikacji lub service principal;
nowy admin consent albo application permission wysokiego wpływu;
dodanie właściciela aplikacji, roli lub członka role-assignable group;
zmiana Conditional Access, trusted location, authentication method albo federation;
PIM activation wysokiej roli z nietypowego urządzenia/lokalizacji;
użycie emergency account;
logowanie workload identity z nowego ASN/IP i dostęp do Microsoft Graph;
wyłączenie eksportu logów albo skrócenie retencji.

Microsoft Identity Secure Score pomaga priorytetyzować rekomendacje, ale Microsoft wyraźnie zaznacza, że score nie jest miarą prawdopodobieństwa włamania. Nie „testujemy pod wynik procentowy”. Oceniamy kontrolę, wpływ i wykrywalność.

Checklista pentestu Entra ID

Co otrzymuje firma po teście?

Raport powinien zawierać diagram płaszczyzn, graf ścieżek eskalacji, macierz CA, inventory aplikacji i grantów, wpływ biznesowy, bezpieczny dowód oraz plan naprawczy. Priorytet nadajemy ścieżkom łączącym trwałe credentiale, application permissions, role i brak detekcji — nie pojedynczym „brakom best practice”.

Szerszą ochronę danych, Exchange, SharePoint i Defender opisuje przewodnik bezpieczeństwa Microsoft 365. Pentest Entra jest rdzeniem tożsamości, lecz nie zastępuje testu aplikacji, chmury ani endpointów.

Jeśli potrzebujesz kontrolowanej oceny tenanta, aplikacji i hybrydowych ścieżek uprawnień, skontaktuj się z Breachroad. Test zaplanujemy tak, aby dostarczyć techniczny dowód bez naruszania infrastruktury Microsoft i bez rozszerzania dostępu poza uzgodniony tenant.