Scenariusze wdrożeniowe dla środowisk wielodostępnych
Inżynier MSP z dostępem Global Admin do 40 dzierżawców klientów. Jedno skompromitowane konto. Czterdzieści jednoczesnych incydentów. To nie było teoretyczne ryzyko w ramach starszego modelu Delegated Admin Privileges – było to standardową konfiguracją operacyjną przez lata. Własne zespoły reagowania na incydenty firmy Microsoft wskazywały ten wzorzec jako powtarzający się czynnik w atakach na łańcuch dostaw.
PIM w środowisku wielodostępowym jest architektoniczną odpowiedzią na ten problem. Wyzwanie polega na tym, że większość implementacji zatrzymuje się na podstawach jednodostępowych, a w momencie wprowadzenia dostępu między dzierżawcami, delegacji partnerskiej lub struktur holdingowych, decyzje szybko się kumulują. Ten artykuł omawia trzy odrębne scenariusze wielodostępowe, jak PIM zachowuje się inaczej w każdym z nich i gdzie implementacja załamuje się w praktyce.
Microsoft Entra Privileged Identity Management (PIM) to usługa Entra ID, która zastępuje stałe przypisania ról ograniczonymi czasowo, zatwierdzanymi i audytowanymi aktywacjami. Zamiast użytkownika posiadającego rolę Administratora Exchange na stałe, jest on do niej kwalifikowany. Gdy jej potrzebuje, aktywuje ją, podając uzasadnienie, przechodząc MFA i opcjonalnie czekając na zatwierdzenie. Rola aktywuje się na zdefiniowane okno, a następnie automatycznie wygasa.
W środowisku jednodostępowym PIM działa w ramach jednego katalogu. Każdy kwalifikowany użytkownik, każdy zatwierdzający, każda polityka i każdy dziennik audytu znajduje się w tym samym miejscu. Powierzchnia konfiguracji jest ograniczona.
Środowiska wielodostępowe rozbijają tę hermetyczność. Użytkownicy mogą znajdować się w jednym dzierżawcy i potrzebować ról w innym. Przepływy zatwierdzania mogą wymagać przekraczania granic organizacyjnych. MFA ukończone w jednym dzierżawcy może lub nie może być uznawane w innym. Licencje umożliwiające funkcje PIM mogą być wymagane w dzierżawcy, gdzie użytkownik się uwierzytelnia, w dzierżawcy gdzie rola istnieje, lub w obu – w zależności od modelu. Błędne wczesne decyzje w tych kwestiach powodują modele dostępu, które są albo niezabezpieczone (zbyt permisywne), uszkodzone (użytkownicy nie mogą w ogóle aktywować ról) lub kosztowne (licencje zakupione w niewłaściwych miejscach).
Większość dokumentacji traktuje wielodostępowy PIM jako jeden problem. Tak nie jest. Architektura, narzędzia i licencjonowanie różnią się znacząco w zależności od tego, dlaczego w ogóle masz wiele dzierżawców.
Enterprise multi-tenant obejmuje holdingi, środowiska po fuzjach i przejęciach oraz separacje produkcja/piaskownica. Użytkownicy znajdują się w dzierżawcy domowym (źródłowym), zasoby w jednym lub więcej dzierżawcach zasobów. Wzorzec dostępu to wewnętrzni pracownicy potrzebujący dostępu JIT do zasobów, których nie są właścicielami. Właściwym narzędziem jest synchronizacja między dzierżawcami w połączeniu z PIM dla Grup w dzierżawcy zasobów.
Partner/MSP multi-tenant obejmuje dostawcę usług zarządzającego N dzierżawcami klientów ze swojego własnego dzierżawcy zarządzającego. Użytkownicy są wewnętrzni wobec organizacji partnera; zasoby należą w całości do klientów. Wzorzec dostępu to zewnętrzni technicy potrzebujący ograniczonego, czasowego dostępu bez stawania się trwałymi obiektami w katalogach klientów. Właściwym narzędziem jest GDAP w połączeniu z PIM dla Grup w dzierżawcy partnera.
Azure Lighthouse obejmuje czyste zarządzanie zasobami Azure między dzierżawcami, typowo dla MSP lub zespołów platformowych enterprise zarządzających subskrypcjami należącymi do innych dzierżawców. Żadna administracja M365, żadne zarządzanie rolami Entra w zarządzanym dzierżawcy. Wzorzec dostępu to scentralizowane zespoły operacyjne potrzebujące podwyższonego dostępu Azure RBAC przez wiele subskrypcji bez tworzenia jakichkolwiek obiektów tożsamości w zarządzanych dzierżawcach. Właściwym narzędziem są autoryzacje kwalifikowane Lighthouse zdefiniowane w szablonach ARM, z PIM działającym w całości w dzierżawcy zarządzającym.
| Enterprise (synchronizacja między dzierżawcami) | Partner/MSP (GDAP) | Azure Lighthouse | |
|---|---|---|---|
| Obiekty użytkowników w zarządzanym dzierżawcy | Tak (goście B2B lub członkowie) | Nie | Nie |
| Gdzie znajduje się polityka PIM | Dzierżawca zasobów | Dzierżawca partnera (zarządzający) | Dzierżawca zarządzający |
| Licencja P2 wymagana w | Dzierżawca zasobów (na kwalifikowanego użytkownika) | Tylko dzierżawca partnera | Tylko dzierżawca zarządzający |
| Zasoby Azure | Tak | Tak (przez GDAP) | Tak |
| Role M365 / Entra | Tak | Tak | Nie |
| Maks. czas delegacji | Nieograniczony (regulowany przeglądami dostępu) | 2 lata na relację GDAP | Zdefiniowany w szablonie ARM |
| Dzienniki audytu widoczne dla zarządzanego dzierżawcy | Tak | Tak (logowania partnera widoczne) | Tak (dzienniki aktywności Azure) |
Właściwe sklasyfikowanie przed dotknięciem jakiejkolwiek konfiguracji oszczędza znaczącego przepisywania.
PIM dla Grup to funkcja umożliwiająca dostęp just-in-time do członkostwa lub własności grupy bezpieczeństwa Microsoft Entra lub grupy Microsoft 365. W przeciwieństwie do PIM dla Ról (który bezpośrednio przyznaje konkretną rolę Entra lub Azure), PIM dla Grup przyznaje członkostwo w grupie, a przez to członkostwo – dostęp do wszystkich zasobów, z którymi grupa jest powiązana.
Instynktem w większości implementacji JIT jest bezpośrednie użycie PIM dla Ról: sprawić, by użytkownik kwalifikował się do roli Contributor lub Exchange Administrator, wymagać aktywacji. To działa w scenariuszach jednodostępowych. W środowiskach wielodostępowych PIM dla Grup jest prawie zawsze lepszym prymitywem.
Jedno kwalifikowane członkostwo w grupie może jednocześnie przyznawać dostęp do wielu powiązanych zasobów: roli Entra, roli zasobu Azure, uprawnienia aplikacji i zakresu Intune. Dla technika obsługującego incydent w środowisku klienta, aktywacja jednego przypisania grupowego to różnica między użytecznym przepływem JIT a pięcioetapowym procesem podwyższania uprawnień, którego nikt nie przestrzega pod presją.
PIM dla Grup zapewnia też czystą separację między zarządzaniem tożsamością (kto kwalifikuje się do czego) a dostępem do zasobów (co ta kwalifikowalność przyznaje). Gdy środowisko klienta się zmienia, aktualizujesz przypisania zasobów grupy. Kwalifikowane przypisania dla członków Twojego zespołu się nie zmieniają.
Grup z dynamicznym członkostwem nie można dołączyć do PIM dla Grup.
Grupy synchronizowane z lokalnego Active Directory są wykluczone.
Jednostki usług mogą otrzymywać tylko czasowo ograniczone aktywne przypisania, nie kwalifikowane.
Zagnieżdżanie grupy w grupie z włączonym PIM dla Grup jest nieobsługiwane i powoduje nieprzewidywalne zachowanie audytu.
Limit wynosi 500 grup z możliwością przypisywania ról na dzierżawcę, choć grupy bez możliwości przypisywania ról można też dołączać do PIM dla Grup od stycznia 2023 roku.
To nie są przypadki brzegowe. Są to ograniczenia wpływające na każde środowisko z tożsamością hybrydową lub wzorcami dostępu z dużą ilością automatyzacji. Zaprojektuj taksonomię grup wokół tych ograniczeń przed budowaniem kwalifikowanych przypisań.
Granular Delegated Admin Privileges (GDAP) to zamiennik Microsoftu dla starszego modelu Delegated Admin Privileges (DAP). W ramach DAP, MSP posiadały stały dostęp Global Admin i Helpdesk Admin do każdego dzierżawcy klienta, bez limitu czasu i bez szczegółowości. W ramach GDAP, partner żąda konkretnych ról Microsoft Entra w dzierżawcy klienta za zgodą klienta i na zdefiniowany czas. Maksymalny czas trwania relacji GDAP wynosi dwa lata. Stałe relacje GDAP są celowo i jawnie nieobsługiwane.
Architektura łącząca GDAP z PIM dla Grup działa następująco: MSP tworzy grupy bezpieczeństwa w swoim dzierżawcy zarządzającym, każda reprezentująca poziom roli lub funkcji (wsparcie Tier 1, administracja Exchange, zarządzanie Intune). Te grupy są mapowane na przypisania ról GDAP w dzierżawcy klienta. PIM dla Grup w dzierżawcy zarządzającym kontroluje, którzy inżynierowie mogą aktywować członkostwo w tych grupach i na jak długo. Dzierżawca klienta nigdy nie przechowuje obiektów użytkowników partnera ani przypisań ról w IAM – dostęp pochodzi z dzierżawcy partnera.
Krytyczny punkt licencjonowania dla GDAP + PIM: licencje P2 są wymagane tylko w dzierżawcy partnera (zarządzającym), dla inżynierów posiadających kwalifikowane członkostwa w grupach i dla zatwierdzających. Dzierżawcy klientów nie wymagają licencji P2, by model dostępu partnerskiego działał. To najczęściej źle rozumiany aspekt licencjonowania GDAP + PIM, który często prowadzi do niepotrzebnych zakupów P2 per klient.
Udokumentowane, ale słabo nagłośnione ograniczenie: jeśli grupie partnera jest przypisana rola Security Reader lub Global Reader przez GDAP, a dzierżawca klienta ma włączone PIM, użytkownik partnera napotyka błąd „Brak dostępu” przechodząc do Ról i Administratorów Entra w dzierżawcy klienta. Obejście wymaga roli Global Administrator. To zachowanie wpływa na konfiguracje monitoringu tylko do odczytu i musi być uwzględnione przy projektowaniu modeli dostępu Tier 1 opartych na rolach GDAP tylko do odczytu.
Wygasanie relacji GDAP to ryzyko operacyjne powszechnie niedoceniane. Gdy relacja GDAP wygasa, wszystkie przypisania ról objęte tą relacją są natychmiast usuwane, bez okresu karencji. Partner traci możliwość aktywowania ról kwalifikowanych PIM dla tego klienta do momentu ponownego ustanowienia i ponownego zatwierdzenia relacji przez klienta. Ustawienie automatycznego przedłużania dodaje sześć miesięcy na cykl, ale wymaga aktywnego monitorowania by potwierdzić, że zastosowało się prawidłowo. Dla MSP zarządzających dziesiątkami relacji z klientami z rozłożonymi datami wygaśnięcia, odnowienie GDAP musi być traktowane jako formalny proces operacyjny z właścicielem i alertingiem, nie przypomnienie w kalendarzu.
Azure Lighthouse różni się architektonicznie od GDAP i B2B w jednym ważnym aspekcie: w zarządzanym dzierżawcy nie są tworzone żadne obiekty użytkowników ani przypisania ról. Z perspektywy klienta, dostęp partnera pojawia się jako projekcja z dzierżawcy zarządzającego. Klient może widzieć dzienniki audytu tego, co zostało zrobione, ale w jego katalogu nie ma kont gości i żadne przypisania ról nie są widoczne w blade IAM.
Integracja PIM z Lighthouse jest konfigurowana przez kwalifikowane autoryzacje w szablonie ARM dołączającym. Przy dołączaniu subskrypcji klienta, dzierżawca zarządzający definiuje które grupy bezpieczeństwa otrzymują jakie role Azure, czy te autoryzacje są stałe czy kwalifikowane, maksymalny czas aktywacji i kto jest zatwierdzającym. Cała polityka JIT znajduje się w dzierżawcy zarządzającym.
Ten model obejmuje zarządzanie zasobami Azure. Nie obejmuje administracji M365, zarządzania rolami Entra w dzierżawcy klienta ani Intune. Uruchamianie Lighthouse obok GDAP dla tego samego klienta to prawidłowa i powszechna konfiguracja: Lighthouse dla subskrypcji Azure, GDAP dla M365 i Entra.
Ograniczenie dataActions: role z jakimikolwiek uprawnieniami dataActions nie mogą być delegowane przez Lighthouse. Wyklucza to role przyznające dostęp do danych w storage, sekretów Key Vault lub baz danych SQL, niezależnie od tego jak rola jest zdefiniowana w szablonie ARM.
Stały reader wymagany: co najmniej jedno stałe (nie kwalifikowane) przypisanie reader jest wymagane by delegacja działała. Aktywacja kwalifikowanej roli wymaga najpierw odczytu zasobu. Jeśli rola reader jest też kwalifikowana, aktywacja się nie powiedzie.
Licencjonowanie P2 dla Lighthouse JIT jest wymagane tylko w dzierżawcy zarządzającym, dla użytkowników z kwalifikowanymi autoryzacjami i ich zatwierdzających. To najbardziej efektywny kosztowo model dla czystego zarządzania Azure na dużą skalę.
Gdy użytkownik gość B2B aktywuje rolę PIM w dzierżawcy zasobów, stosują się polityki dostępu warunkowego tego dzierżawcy, w tym wymagania MFA. Domyślnie, dzierżawcy zasobów nie ufają MFA ukończonemu w dzierżawcy domowym użytkownika. Gość musi zarejestrować MFA oddzielnie w dzierżawcy zasobów.
Dla inżyniera partnera z kwalifikowanym dostępem do 40 dzierżawców klientów oznacza to 40 oddzielnych rejestracji MFA, 40 wpisów w Authenticator, każdy wymagający indywidualnej ponownej rejestracji przy wymianie urządzenia. W praktyce, inżynierowie albo unikają używania dostępu kwalifikowanego, albo gromadzą niekontrolowane rejestracje MFA, które stają się problemem bezpieczeństwa gdy potrzebne jest odzyskanie konta.
Rozwiązaniem jest Zaufanie MFA w ustawieniach dostępu między dzierżawcami. Włączenie przychodzącego zaufania MFA dla konkretnej organizacji partnerskiej w dzierżawcy zasobów powoduje, że dzierżawca zasobów akceptuje poświadczenia MFA spełnione w dzierżawcy domowym użytkownika. Inżynier uwierzytelnia się raz w swoim dzierżawcy domowym i to uwierzytelnienie jest honorowane w dzierżawcach zasobów, które skonfigurowały zaufanie.
Niestandardowe Kontrole w Dostępie Warunkowym nie działają z zaufaniem między dzierżawcami. Jeśli polityki Dostępu Warunkowego w dzierżawcy zasobów używają niestandardowych kontroli do egzekwowania MFA, te polityki są niekompatybilne z zaufaniem MFA między dzierżawcami.
ID Protection + Zaufanie MFA tworzy ciche blokowanie dostępu. Jeśli dzierżawca zasobów ma aktywną politykę Microsoft Entra ID Protection wymagającą rejestracji MFA, a przychodzące zaufanie MFA jest też włączone, zewnętrzni użytkownicy nie mogą jednocześnie spełnić obu wymagań. ID Protection kieruje ich do lokalnej rejestracji, ale ustawienia zaufania honorowałyby poświadczenie z dzierżawcy domowego. Rezultatem jest zablokowane logowanie bez jasnego komunikatu błędu. Wyklucz zewnętrznych użytkowników z polityk rejestracji MFA ID Protection gdy włączasz zaufanie MFA.
Zaufanie MFA nie jest konfigurowalne na poziomie aplikacji ani roli. Jest konfigurowane dla całego dzierżawcy lub per organizacja w Ustawieniach Dostępu Między Dzierżawcami. Nie ma możliwości wymagania zaufania MFA z dzierżawcy domowego tylko dla konkretnych aplikacji, jednocześnie wymagając MFA z dzierżawcy zasobów dla innych, w ramach tej samej relacji z zewnętrzną organizacją.
| Scenariusz | P2 potrzebne w | Per co | Czy P2 wymagane w dzierżawcy klienta? |
|---|---|---|---|
| Enterprise synchronizacja między dzierżawcami + PIM dla Grup | Dzierżawca zasobów | Każdy kwalifikowany użytkownik + zatwierdzający | Nie dotyczy (ta sama organizacja) |
| Synchronizacja między dzierżawcami (dzierżawca źródłowy) | Dzierżawca źródłowy | Każdy synchronizowany użytkownik (minimum P1) | Nie dotyczy |
| GDAP + PIM dla Grup (model MSP) | Dzierżawca partnera | Każdy kwalifikowany inżynier + zatwierdzający | Nie |
| Azure Lighthouse + kwalifikowane autoryzacje | Dzierżawca zarządzający | Każdy kwalifikowany użytkownik + zatwierdzający | Nie |
| Własne kwalifikowane przypisania PIM klienta | Dzierżawca klienta | Własni kwalifikowani użytkownicy klienta | Tak (własni użytkownicy) |
Jeden przypadek brzegowy zaskakujący organizacje jednocześnie uruchamiające wszystkie trzy modele: jeśli inżynier w dzierżawcy zarządzającym posiada kwalifikowane przypisania zarówno przez Lighthouse jak i GDAP, licencja P2 jest zużywana raz w dzierżawcy zarządzającym. Nie ma sumowania P2 per dzierżawca klienta. MSP, które początkowo szacują licencjonowanie PIM jako koszt per klient, znacząco przeszacowują rzeczywiste wymagania licencyjne.
Zarówno Microsoft Entra ID P2, jak i licencja Entra ID Governance obejmują PIM. Entra Suite zawiera obie. Jeśli Twoja organizacja już kupuje Entra ID Governance dla przeglądów dostępu lub zarządzania uprawnieniami, PIM jest dołączony bez dodatkowych kosztów.
Koniec życia PIM API v2 (beta): 28 października 2026 roku. Wszelkie skrypty PowerShell, Logic Apps lub niestandardowe narzędzia wywołujące endpointy PIM Iteration 2 beta API dla zasobów Azure, ról Entra lub Grup przestaną działać w tym dniu, bez zwracanych danych i bez jasnego komunikatu błędu. Organizacje, które zbudowały automatyzację aktywacji ról, przepływy zatwierdzania lub skrypty przypisywania kwalifikowalności przed mniej więcej 2023 rokiem, muszą je zaudytować i zmigrować do endpointów Graph API Iteration 3 (GA). Migracja nie jest technicznie złożona, ale znalezienie każdego miejsca, gdzie stare wywołania PIM API są osadzone w wielodostępowych pipelineach automatyzacji, zajmuje czas. Przejrzyj to teraz, a nie w oknie incydentu pod koniec 2026 roku.
Opóźnienie propagacji tokenu po aktywacji roli. PIM aktywuje przypisanie roli w ciągu sekund, ale bieżąca sesja przeglądarki użytkownika nie odzwierciedla automatycznie nowego przypisania. Klasyczna awaria: inżynier aktywuje rolę w PIM, natychmiast przechodzi do zasobu lub próbuje zaprosić gościa B2B i otrzymuje błąd odmowy dostępu mimo że aktywacja pokazuje się jako udana. Rola jest aktywna. Token nie odświeżył się. Wylogowanie i ponowne zalogowanie rozwiązuje to. Powinno być to jawnie udokumentowane w operacyjnych runbookach.
Zagnieżdżanie grup w PIM dla Grup. Microsoft jawnie odradza zagnieżdżanie grupy w grupie z włączonym PIM dla Grup. Zagnieżdżeni członkowie grup dziedziczą dostęp gdy aktywowana jest grupa nadrzędna, co może przyznawać niezamierzone uprawnienia szerszemu zestawowi użytkowników niż zamierzono. Zachowanie aktywacji z zagnieżdżonymi grupami powoduje nieoczywiste wpisy w dziennikach audytu i utrudnia interpretację przeglądów dostępu. Używaj płaskich struktur grup z wyraźnie ograniczonymi kwalifikowanymi przypisaniami.
Odnowienie relacji GDAP jako formalny proces. Wygasła relacja GDAP natychmiast usuwa wszystkie przypisania ról objęte zakresem, bez okresu karencji. Ustawienie automatycznego przedłużania pomaga, ale samo musi być monitorowane. Dla MSP zarządzających dziesiątkami relacji z klientami z rozłożonymi datami wygaśnięcia, odnowienie GDAP potrzebuje właściciela, alertingu i zdefiniowanego czasu wyprzedzenia odnowienia, nie wpisu w kalendarzu.
Typ użytkownika gość B2B versus członek wpływa na zachowanie PIM. Użytkownicy zsynchronizowani do dzierżawcy zasobów przez synchronizację między dzierżawcami są domyślnie tworzeni jako goście B2B. Przeglądy dostępu, polityki zarządzania uprawnieniami i część zakresowania Dostępu Warunkowego zachowują się inaczej dla gości versus członków. Zmiana userType po stworzeniu wymaga wywołań Graph API lub rekonfiguracji mapowania atrybutów w zadaniu synchronizacji między dzierżawcami. Zdecyduj o strategii userType przed rozpoczęciem tworzenia.
Tak. Użytkownik gość B2B może mieć przypisane kwalifikowane role w dzierżawcy zasobów i może je aktywować przez portal PIM. Aktywacja podlega polityce Dostępu Warunkowego dzierżawcy zasobów, w tym wymaganiom MFA. Domyślnie, gość musi zarejestrować MFA w dzierżawcy zasobów oddzielnie od swojego dzierżawcy domowego, chyba że dzierżawca zasobów skonfigurował przychodzące zaufanie MFA w Ustawieniach Dostępu Między Dzierżawcami.
Nie. Azure Lighthouse zarządza wyłącznie rolami zasobów Azure (RBAC). Nie może delegować ról Entra ID ani zarządzać obciążeniami Microsoft 365 takimi jak Exchange, SharePoint lub Intune w dzierżawcy klienta. Do administracji M365 wymagane jest GDAP.
Nie. Jednostki usług nie mogą otrzymywać kwalifikowanych przypisań w PIM dla ról Entra, ról Azure ani PIM dla Grup. Mogą otrzymywać tylko czasowo ograniczone aktywne przypisania. Jeśli Twoja automatyzacja wymaga dostępu w stylu JIT dla tożsamości obciążeń, dostępnym mechanizmem jest czasowo ograniczone aktywne przypisanie, nie kwalifikowane przypisanie z aktywacją.
Kwalifikowane przypisania ról są usuwane. Stałe aktywne przypisania pozostają bez zmian. Usługa PIM i interfejsy Graph API do zarządzania uprzywilejowanym dostępem stają się niedostępne. Wszelkie trwające przeglądy dostępu ról Entra kończą się. Dotyczy to sytuacji gdy licencja P2 lub Entra ID Governance wygaśnie w dzierżawcy, gdzie istnieją kwalifikowane przypisania.
Nie. Dla modelu dostępu partnerskiego (GDAP + PIM dla Grup w dzierżawcy partnera), licencje P2 są wymagane tylko w dzierżawcy zarządzającym partnerem. Dzierżawcy klientów nie wymagają P2 by inżynierowie partnera mogli używać PIM przy dostępie do zasobów klientów przez GDAP.
Maksymalny czas aktywacji jest konfigurowalny per rola lub grupa, do maksymalnie 24 godzin na aktywację. Użytkownicy mogą żądać dowolnego czasu do skonfigurowanego maksimum w czasie aktywacji. Jest to oddzielne od czasu trwania kwalifikowanego przypisania, który może być ustawiony z konkretną datą końcową lub bez wygaśnięcia, z zastrzeżeniem przeglądów dostępu.
Tak. Uruchamianie Lighthouse obok GDAP dla tego samego klienta to powszechna i wspierana konfiguracja. Lighthouse obsługuje dostęp do subskrypcji Azure; GDAP obsługuje administrację M365 i rolami Entra. Wymaganie licencji P2 pozostaje w dzierżawcy zarządzającym/partnerskim dla obu.
Jeśli zarządzasz zasobami Azure dla klientów i nie używasz Azure Lighthouse z kwalifikowanymi autoryzacjami, używasz bardziej złożonego i mniej audytowalnego modelu niż to konieczne. Lighthouse utrzymuje katalogi dzierżawców klientów w czystości, centralizuje politykę PIM w jednym miejscu i wymaga licencji P2 tylko w Twoim dzierżawcy zarządzającym. Jedynym powodem nieużywania Lighthouse dla Azure jest potrzeba delegowania ról z uprawnieniami dataActions (storage, Key Vault, dostęp do danych SQL), czego Lighthouse jawnie nie obsługuje.
Jeśli zarządzasz obciążeniami M365 i Entra dla klientów, GDAP jest wymagane. Połącz to z PIM dla Grup w swoim dzierżawcy zarządzającym, mapuj kwalifikowane przypisania swojego zespołu na grupy bezpieczeństwa GDAP i skonfiguruj wychodzące zaufanie MFA by inżynierowie nie gromadzili rejestracji MFA per dzierżawca. Zdefiniuj taksonomię grup bezpieczeństwa według poziomu funkcji, używaj płaskich struktur grup i śledź daty wygaśnięcia GDAP jako formalny proces z właścicielem.
Jeśli jesteś przedsiębiorstwem z wieloma dzierżawcami po fuzjach i przejęciach, regulacyjnej separacji lub izolacji środowiska, synchronizacja między dzierżawcami ze źródłowego dzierżawcy w połączeniu z PIM dla Grup w każdym dzierżawcy zasobów to właściwa architektura. Skonfiguruj zaufanie MFA w przychodzących Ustawieniach Dostępu Między Dzierżawcami każdego dzierżawcy zasobów. Zdecyduj o typie użytkownika gość B2B versus członek przed rozpoczęciem tworzenia.
We wszystkich trzech scenariuszach, przeglądy dostępu nie są opcjonalne. Kwalifikowane przypisania gromadzą się z czasem gdy ludzie zmieniają role, odchodzą z organizacji lub przenoszą się między projektami. Kwalifikowane przypisanie, które jest technicznie poprawne ale operacyjnie nieaktualne, to nadal ryzyko. Zaplanuj kwartalne przeglądy dostępu dla wszystkich kwalifikowanych przypisań PIM we wszystkich dzierżawcach w zakresie.
Dostęp JIT przez PIM to nie jest funkcja, którą włączasz; to architektura, którą projektujesz. W środowiskach jednodostępowych przestrzeń projektowa jest wystarczająco mała by iterować ku działającej konfiguracji. W środowiskach wielodostępowych, wybory dotyczące modelu do użycia, gdzie potrzebne są licencje i jak skonfigurowane jest zaufanie MFA mają konsekwencje trudne do odwrócenia.
Trzy modele (enterprise synchronizacja między dzierżawcami, GDAP dla MSP i Azure Lighthouse) nie są zamienne. Każdy rozwiązuje konkretny wzorzec dostępu. Użycie niewłaściwego tworzy niepotrzebną złożoność i ryzyko operacyjne.
Wycofanie PIM API v2 (beta) w dniu 28 października 2026 roku to konkretny termin, którego wiele organizacji z przestarzałą automatyzacją nie śledzi. Przeprowadź audyt wszelką automatyzację PIM zbudowaną przed 2023 rokiem.
Licencjonowanie dla wielodostępowego PIM prawie zawsze kosztuje mniej niż organizacje początkowo szacują. P2 jest wymagane tam gdzie znajdują się kwalifikowane przypisania, nie tam gdzie znajdują się zasoby. Dla modeli MSP i Lighthouse oznacza to tylko dzierżawca zarządzający.
