Privileged Identity Management w Microsoft Entra ID — pułapki, opóźnienia i luki bezpieczeństwa, które mogą cię zaskoczyć

TL;DR: PIM w Entra ID to standard dla zarządzania dostępem uprzywilejowanym, ale wdrożenie "na domyślnych ustawieniach" zostawia otwarte dziury — od ominięcia MFA przez skradzione tokeny AITM, po ryzyko całkowitego lockouta tenanta. W tym artykule znajdziesz konkretne konfiguracje, skrypty PowerShell do audytu oraz listę edge case'ów, które mogą cię boleśnie zaskoczyć w produkcji.

---

Problem

Każdy admin, który wdrożył PIM i uznał temat za zamknięty, prędzej czy później dostaje zgłoszenie: "Aktywowałem rolę, ale nadal nie mam dostępu do SharePoint". Albo gorszy scenariusz — dział bezpieczeństwa pyta, dlaczego ktoś aktywował Global Administratora o 3 w nocy z adresu IP w Rumunii, mimo że MFA było wymagane. PIM nie jest srebrną kulą — to narzędzie, które działa dokładnie tak, jak je skonfigurowano, a domyślna konfiguracja ma poważne luki.

Codzienne życie z PIM wygląda tak: użytkownicy dzwonią, że aktywowali rolę, czekają pół godziny i dalej nie mogą wejść do centrum administracyjnego Exchange. Helpdesk otwiera ticket, ktoś sprawdza w portalu — rola aktywna, wszystko zielone. Reset sesji, nowe logowanie — działa. Dlaczego? Token cacheowanie po stronie Exchange i SharePoint powoduje opóźnienie od 15 do 40 minut dla bezpośrednich przypisań ról PIM. Użytkownicy o tym nie wiedzą, dokumentacja Microsoftu to wspomina małym drukiem, a w każdej organizacji trzeba się na to natknąć samemu.

Drugi problem, który pojawia się po kilku miesiącach: chaos w przypisaniach eligible. Ktoś dostał rolę na projekt, projekt się skończył, rola została. Ktoś inny dostał rolę "tymczasowo" jako permanent active, bo "tak było szybciej". Po roku masz kilkadziesiąt przypisań, z czego połowa jest nieaktualna, a kilka osób ma permanent active na rolach Tier-0, co zupełnie wypacza sens PIM. Bez regularnego audytu skryptami przypisania puchną i nikt nie ma pełnego obrazu stanu.

---

Dlaczego tak się dzieje

Opóźnienia tokenów i replikacji są efektem architektury rozproszonych usług Microsoft 365. Gdy PIM aktywuje przypisanie roli, informacja trafia do Entra ID w czasie rzeczywistym — ale Exchange Online i SharePoint Online utrzymują własne cache uprawnień. Token dostępowy użytkownika, który był wystawiony przed aktywacją, nadal nie zawiera nowego claim z rolą. Exchange respektuje ten stan przez 15–40 minut zanim wymusi odświeżenie. SharePoint i OneDrive działają podobnie dla bezpośrednich przypisań ról, ale gdy korzystasz z PIM dla Grup (a nie bezpośrednich ról Entra), opóźnienie replikacji członkostwa w grupie do SharePoint wynosi nawet 24 godziny — Microsoft potwierdził to w artykule KB. To fundamentalna różnica: przypisujesz przez PIM for Groups i liczysz na natychmiastowy efekt w SharePoint? Nie tym razem.

Luka MFA w PIM wynika z tego, jak Entra ID weryfikuje spełnienie wymagania wieloskładnikowego. Ustawienie "On activation, require MFA" w polityce roli PIM sprawdza wyłącznie, czy w bieżącej sesji istnieje claim MFA — nie wymaga nowej weryfikacji. Jeśli użytkownik zalogował się rano z MFA, jego token sesyjny zawiera ten claim przez cały dzień. Atakujący z tokenem skradzionym przez adversary-in-the-middle (AITM) — np. przez phishing z frameworkiem Evilginx — ma aktywną sesję z ważnym claimem MFA i może aktywować rolę uprzywilejowaną bez żadnej dodatkowej weryfikacji. To nie jest teoretyczny scenariusz: AiTM phishing targeting M365 jest obecnie jednym z najczęściej używanych wektorów przejęcia kont administracyjnych.

Refresh tokeny to osobny problem. Atakujący, który zdobył refresh token użytkownika z eligible assignment, może nie działać natychmiast. Refresh tokeny w M365 mogą być ważne nawet 90 dni. Wystarczy, że atakujący poczeka, aż ofiara sama aktywuje rolę w ramach normalnej pracy — w tym momencie może użyć skradzionego tokenu do uzyskania access tokenu z podwyższonymi uprawnieniami i działać równolegle ze swoją ofiarą. PIM nie wykryje podwójnego użycia tokenu samo z siebie.

---

Rozwiązanie krok po kroku

Krok 1: Audyt stanu obecnego — co masz w tenantcie

Zanim cokolwiek zmienisz, musisz wiedzieć co masz. Poniższy skrypt wyciąga wszystkie eligible assignments z instancji aktywnych i wyświetla je w tabeli:

# Lista wszystkich eligible assignments PIM
Connect-MgGraph -Scopes "RoleManagement.Read.Directory", "Directory.Read.All"
$eligibleAssignments = Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -All -ExpandProperty 'principal,roleDefinition'
$eligibleAssignments | Select-Object `
    @{N="Użytkownik";E={$_.Principal.AdditionalProperties.displayName}},
    @{N="Rola";E={$_.RoleDefinition.DisplayName}},
    @{N="Koniec";E={$_.EndDateTime}},
    @{N="Typ";E={$_.MemberType}} |
  Format-Table -AutoSize

Szukaj: przypisań bez daty wygaśnięcia (pole Koniec puste), duplikatów tej samej roli dla jednej osoby, ról Tier-0 (Global Administrator, Privileged Role Administrator, Security Administrator) z przypisaniem Permanent. Każde permanent active przypisanie na roli Tier-0, które nie należy do konta break glass, jest błędem konfiguracyjnym.

Drugi skrypt — kto aktywował co i z jakiego adresu IP w ostatnich 30 dniach:

# Audyt aktywacji ról PIM z ostatnich 30 dni
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddT00:00:00Z")
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to role completed (PIM activation)' and activityDateTime ge $startDate" |
  Select-Object ActivityDateTime,
    @{N="Użytkownik";E={$_.InitiatedBy.User.UserPrincipalName}},
    @{N="Rola";E={$_.TargetResources[0].DisplayName}},
    @{N="IP";E={$_.InitiatedBy.User.IpAddress}} |
  Export-Csv -Path "pim_aktywacje_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8

Eksportuj do CSV i przejrzyj pod kątem: aktywacji poza godzinami pracy, aktywacji z nieznanych adresów IP, aktywacji ról których dany użytkownik normalnie nie używa.

Żeby zobaczyć kto ma w tej chwili aktywną podwyższoną rolę:

# Sprawdź kto ma aktywne right now elevated role
Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -All -ExpandProperty 'principal,roleDefinition' |
  Where-Object { $_.AssignmentType -eq "Activated" } |
  Select-Object `
    @{N="Użytkownik";E={$_.Principal.AdditionalProperties.userPrincipalName}},
    @{N="Rola";E={$_.RoleDefinition.DisplayName}},
    @{N="Od";E={$_.StartDateTime}},
    @{N="Do";E={$_.EndDateTime}} |
  Format-Table -AutoSize

Krok 2: Zablokuj lukę MFA przez Authentication Context

Samo "require MFA on activation" nie wystarczy. Musisz wymusić re-autentykację niezależnie od tego, czy sesja już ma claim MFA. Realizujesz to przez Authentication Context w Conditional Access.

W portalu Entra ID przejdź do: Protection → Conditional Access → Authentication context i utwórz nowy kontekst, np. c1 z nazwą "PIM Privileged Role Activation". Następnie stwórz politykę Conditional Access:

• Assignments → Users: All users (lub dedykowana grupa adminów)
• Target resources → Authentication context: wybierz c1
• Access controls → Grant: Require MFA (lub Require authentication strength → Phishing-resistant MFA)
• Session → Sign-in frequency: Every time

Opcja "Every time" w Sign-in frequency to kluczowy element — wymusza pełne uwierzytelnienie przy każdej aktywacji roli, nie respektuje istniejącego tokenu sesyjnego. Atakujący ze skradzionym tokenem AITM nie przejdzie przez tę weryfikację, bo token nie zawiera świeżego claimu autentykacji.

Następnie w ustawieniach roli PIM (Role Settings → Activation) wybierz ten Authentication Context jako wymaganie zamiast standardowego "Require MFA".

Ważne ograniczenie: po aktywacji roli na jednym urządzeniu (np. zgodnym z Intune), ta sama aktywowana sesja jest dostępna z innego urządzenia — Entra ID nie wiąże sesji aktywowanej roli do konkretnego urządzenia. Żeby zamknąć tę lukę, potrzebujesz drugiej polityki CA targetującej bezpośrednio aplikacje zarządzane przez te role (Azure Portal, M365 Admin Center) z wymaganiem zgodności urządzenia.

Krok 3: Ustaw rozsądne limity czasu aktywacji

Dla ról Tier-0 — Global Administrator i Privileged Role Administrator — maksymalny czas aktywacji ustaw na 2–4 godziny. PIM pozwala na zakres 1–24 godzin, ale 8 czy 24 godziny dla Global Admina to proszenie się o kłopoty: skradziony token aktywowanej sesji jest użytkowalny przez cały ten czas.

Rekomendowane maksymalne czasy aktywacji:

• Global Administrator: 2 godziny
• Privileged Role Administrator: 2 godziny
• Security Administrator: 4 godziny
• Exchange Administrator: 4 godziny
• SharePoint Administrator: 4 godziny

Krok 4: Konfiguracja break glass i zabezpieczenie przed lockoutem

Scenariusz lockouta: wszystkie konta z rolą Privileged Role Administrator i Global Administrator mają assignment eligible (nie active), do aktywacji wymagane jest zatwierdzenie przez approverów, ale lista approverów jest pusta lub wszyscy approverzy są niedostępni. Wynik: nikt nie może aktywować roli, nikt nie może zatwierdzić wniosku, tenant zablokowany.

Zapobieganie:

1. Minimum dwa konta break glass z permanent active przypisaniem Global Administratora. Konta break glass powinny być cloud-only, bez MFA (dostęp przez fizycznie zabezpieczone hasło), monitorowane alertami na każde logowanie.
2. W politykach PIM ról Tier-0, jeśli wymagasz zatwierdzenia — zawsze wskaż konkretnych approverów, a konta break glass dodaj jako domyślnych approverów.
3. Regularnie testuj procedurę break glass — raz na kwartał zweryfikuj, że hasło działa i konto nie zostało zablokowane.
4. Konta break glass muszą być wykluczone ze wszystkich polityk Conditional Access, włącznie z tą nową dla Authentication Context.

Krok 5: Rozwiąż problem opóźnień SharePoint i Exchange

Dla Exchange: po aktywacji roli użytkownicy muszą odczekać 15–40 minut i otworzyć nową sesję przeglądarki. Skrócenie czasu oczekiwania jest możliwe przez odświeżenie tokenu sesji — użytkownik może otworzyć https://aka.ms/pim/tokenrefresh bezpośrednio po aktywacji, co wymusza wymianę tokenu sesyjnego i skraca oczekiwanie do kilku minut.

Dla SharePoint z PIM dla Grup: opóźnienie do 24 godzin to standard, nie wyjątek. Masz dwie ścieżki:

• Opcja A (zalecana): Nie używaj PIM dla Grup do zarządzania dostępem do SharePoint. Przypisuj uprawnienia bezpośrednio przez PIM for Microsoft Entra roles. Opóźnienie spada do 15–40 minut.
• Opcja B: Jeśli musisz używać grup — dodaj użytkownika do grupy jako stały członek, a następnie zrób grupę eligible przez PIM for Groups wyłącznie dla uprawnień directory role. SharePoint widzi statyczne członkostwo, PIM kontroluje uprawnienia katalogowe.

Krok 6: Monitoruj ciągle, nie jednorazowo

PIM bez alertowania to połowiczne rozwiązanie. Minimalne alerty, które musisz mieć w Microsoft Sentinel lub Defender XDR:

• Aktywacja roli Global Administrator lub Privileged Role Administrator — alert natychmiastowy, każdorazowo
• Aktywacja roli z adresu IP z innego kraju niż zwykła lokalizacja użytkownika
• Więcej niż dwie aktywacje ról przez jednego użytkownika w ciągu 30 minut
• Logowanie kontem break glass — alert krytyczny z eskalacją do osoby odpowiedzialnej za bezpieczeństwo

---

Typowe pułapki i edge cases

Pułapka 1: Okno 10-minutowe przy wielu aktywacjach

Jeśli użytkownik aktywuje pierwszą rolę przez Authentication Context (przechodząc pełną re-autentykację), a następnie w ciągu 10 minut aktywuje drugą eligible rolę — Entra ID nie wymaga ponownej weryfikacji dla drugiej aktywacji. System traktuje to jako tę samą sesję uwierzytelnienia. Okno 10 minut dotyczy wszystkich typów ról: Microsoft Entra roles, Azure resource roles i PIM for Groups. Atakujący z dostępem do sesji w tym oknie może aktywować kolejne role bez przeszkód. Mitygacja: skróć listę eligible assignments do absolutnego minimum i monitoruj aktywacje wielu ról w krótkim czasie.

Pułapka 2: PIM dla Grup i niezamierzone uprawnienia Global Admina

PIM dla Grup pozwala nadać eligible membership do grupy. Jeśli ta grupa — bezpośrednio lub przez zagnieżdżone grupy — jest przypisana do roli Global Administrator, aktywacja membershipu daje efektywnie Global Admina. Problem: łatwo przeoczyć, do czego przypisana jest dana grupa, szczególnie w tenantach z długą historią i setkami grup. Każda zmiana przypisania grupy do ról Entra ID powinna być procesem zatwierdzanym. Regularnie uruchamiaj skrypt audytowy z Kroku 1 i dla każdej grupy z eligible assignment sprawdzaj jej role w portalu Entra ID.

Pułapka 3: Refresh token jako wektor ataku czasowego

Użytkownik z eligible assignment aktywuje rolę w piątek. Atakujący ze skradzionym refresh tokenem (ważnym przez 90 dni) czeka właśnie na taki moment. W momencie aktywacji może użyć refresh tokenu, wymienić go na access token z uprawnieniami aktywnej roli i działać w ramach okna aktywacji — 2, 4 lub 8 godzin. PIM log aktywacji nie rozróżni dwóch urządzeń korzystających z tego samego tokenu. Mitygacja: wymuszaj Continuous Access Evaluation (CAE), monitoruj logowania z nowych urządzeń/lokalizacji dla kont z eligible assignments.

Pułapka 4: Permanent active "na chwilę"

"Dałem mu permanent active bo było pilne, potem cofniemy" — to zdanie padło w każdej organizacji. Bez procesu regularnego audytu te "tymczasowe" przypisania zostają miesiącami. Permanent active assignment omija cały mechanizm PIM: brak justyfikacji, brak zatwierdzenia, brak ograniczenia czasowego, brak wymogu re-auth. Dla ról Tier-0 ustaw w polityce PIM zakaz permanent active assignments (Role Settings → Assignment → Allow permanent active assignment → No). Konta break glass dodaj ręcznie jako wyjątek przed zmianą polityki.

Pułapka 5: Brak alertów = brak bezpieczeństwa

PIM bez zintegrowanego monitoringu daje fałszywe poczucie bezpieczeństwa. Dane o aktywacjach są dostępne przez 30 dni w logach Entra ID, ale nikt ich aktywnie nie przegląda. Zautomatyzuj eksport logów do CSV (skrypt z Kroku 1) jako zaplanowane zadanie, i zintegruj z SIEM jeśli masz. Bez alertowania w czasie rzeczywistym na aktywację Global Admina o 3 w nocy z nieznanego IP — nie masz bezpieczeństwa, tylko jego pozory.

---

Podsumowanie

• PIM "require MFA" to za mało — bez Authentication Context z "Sign-in frequency: Every time" atakujący z tokenem AITM aktywuje privileged role bez żadnej weryfikacji. To luka architektoniczna, nie błąd konfiguracyjny.
• Opóźnienia są dokumentowane: 15–40 minut dla bezpośrednich ról (token caching Exchange/SharePoint), do 24 godzin dla PIM for Groups → SharePoint/OneDrive. Wybór metody przypisania ma realny wpływ operacyjny. Użyj https://aka.ms/pim/tokenrefresh by przyspieszyć odświeżenie sesji.
• Lockout tenanta jest możliwy gdy wszystkie konta Tier-0 mają eligible assignments z wymaganym zatwierdzeniem bez skonfigurowanych approverów. Konta break glass z permanent active Global Admin to zabezpieczenie krytyczne, nie opcjonalne.
• Audyt PowerShell to podstawa higieny: lista eligible assignments, logi aktywacji z 30 dni, aktualnie aktywne elevated sessions — trzy skrypty do regularnego uruchamiania.
• PIM for Groups niesie ryzyko eskalacji uprawnień: każda zmiana przypisania grupy do ról Entra ID musi być auditowana — inadvertent Global Admin przez zagnieżdżone grupy to realny scenariusz w tenantach z długą historią.