Wyobraźmy sobie, że administrator loguje się do Microsoft Entra ID, ma aktywną odpowiednią rolę i może zwyczajnie korzystać z centrum administracyjnego. Kiedy jednak próbuje zmodyfikować politykę Conditional Access, okazuje się, że samo posiadanie wymaganych uprawnień nie wystarcza. Entra żąda spełnienia dodatkowych warunków, na przykład ponownego uwierzytelnienia metodą odporną na phishing. Administrator nie utracił roli, a jego uprawnienia są nadal przypisane prawidłowo. To wykonanie konkretnej operacji zostało objęte dodatkową warstwą ochrony.

Autor: 6 min czytania

Za taki scenariusz odpowiadają Protected Actions w Microsoft Entra ID. Microsoft definiuje je jako uprawnienia Microsoft Entra, do których przypisano wymagania Conditional Access. Mechanizm nie zmienia więc tego, kto posiada dane uprawnienie – o tym nadal decydują role. Pozwala natomiast określić dodatkowe warunki, które użytkownik musi spełnić w chwili wykorzystania wybranego uprawnienia.

Conditional Access w momencie wykonania operacji

Conditional Access kojarzymy przede wszystkim z kontrolą dostępu do aplikacji i usług. Protected Actions wykorzystują ten sam mechanizm bardziej szczegółowo. Za pomocą Authentication Context politykę Conditional Access można powiązać z wybranym uprawnieniem administracyjnym. Kontrola zostanie wtedy wyegzekwowana nie podczas zwykłego logowania administratora, ale w chwili próby wykonania chronionej operacji.

Można na przykład wymagać silniejszej metody uwierzytelnienia określonej przez Authentication Strength, w tym phishing-resistant MFA, albo odpowiedniego urządzenia. Administrator może więc normalnie pracować w Entra admin center, natomiast dodatkowa kontrola pojawi się dopiero podczas szczególnie wrażliwej operacji.

Przecież od tego mamy PIM…

Protected Actions mogą na pierwszy rzut oka przypominać Privileged Identity Management, ale oba mechanizmy działają na innych etapach procesu. PIM pozwala przyznawać role jako eligible, ograniczać czas aktywacji, wymagać uzasadnienia, akceptacji czy dodatkowego uwierzytelnienia. Kontroluje więc przede wszystkim sposób uzyskania aktywnej roli.

Protected Actions działają później – w chwili użycia konkretnego uprawnienia. Administrator może poprawnie aktywować rolę w PIM, a następnie, przy próbie wykonania szczególnie wrażliwej operacji, zostać zobowiązany do spełnienia dodatkowych wymagań Conditional Access.

Istotne jest również to, że Protected Action jest powiązane z permission, a nie z nazwą roli. PIM i Protected Actions nie są więc mechanizmami konkurencyjnymi. Pierwszy ogranicza dostępność uprzywilejowanej roli, drugi pozwala kontrolować wykorzystanie wybranych uprawnień.

Co właściwie można chronić?

Protected Actions mają istotne ograniczenie: administrator nie może wybrać dowolnej operacji w Entra ID. Microsoft udostępnia określony zestaw permissions obsługujących ten mechanizm. Obejmuje on między innymi uprawnienia związane z zarządzaniem politykami Conditional Access, wybranymi ustawieniami cross-tenant access, Named Locations czy trwałym usuwaniem określonych obiektów katalogowych.

Dobrym przykładem jest microsoft.directory/deletedItems/delete, czyli uprawnienie związane z trwałym usuwaniem obiektów znajdujących się w deleted items. Protected Action pozwala wprowadzić dodatkowy punkt kontrolny przed operacją, której skutki mogą być nieodwracalne. Administrator nadal posiada wymagane uprawnienie, ale przed jego wykorzystaniem musi spełnić dodatkowe wymagania bezpieczeństwa.

Jak to działa?

Podstawą rozwiązania jest Conditional Access Authentication Context. Najpierw definiujemy Authentication Context i tworzymy politykę Conditional Access skierowaną na ten kontekst. Może ona wymagać na przykład phishing-resistant MFA lub odpowiedniego urządzenia. Następnie Authentication Context przypisujemy do jednego z permissions obsługiwanych przez Protected Actions.

Kiedy administrator próbuje wykonać chronioną operację, Entra sprawdza, czy spełnia on wymagania przypisanej polityki. Jeżeli potrzebne jest dodatkowe uwierzytelnienie, użytkownik może zostać poproszony o jego wykonanie. Nie oznacza to jednak, że prompt pojawi się przy każdej operacji – zależy to również od aktualnego stanu sesji oraz konfiguracji Conditional Access.

Portal działa. Skrypt – niekoniecznie

Protected Actions trzeba uwzględnić także w automatyzacji. Odpowiednie scenariusze step-up authentication są obsługiwane między innymi przez Entra admin center, Microsoft Graph PowerShell i Graph Explorer. Własna aplikacja korzystająca z Microsoft Graph musi jednak poprawnie obsługiwać claims challenge i umożliwić użytkownikowi spełnienie wymagań Authentication Context.

Microsoft wskazuje również ograniczenia dotyczące niektórych klientów. Dlatego przed objęciem permission mechanizmem Protected Actions warto przetestować nie tylko operację wykonywaną w portalu, ale również skrypty i aplikacje wykorzystujące to samo uprawnienie.

RBAC, PIM i Protected Actions

Protected Actions nie powinny zastępować RBAC. To RBAC określa, kto posiada uprawnienie. PIM może ograniczyć, kiedy i na jak długo administrator uzyskuje aktywną rolę. Protected Actions odpowiadają natomiast na jeszcze inne pytanie – jakie dodatkowe wymagania musi spełnić administrator w chwili wykorzystania szczególnie wrażliwego uprawnienia.

W praktyce mechanizmy te mogą tworzyć kilka uzupełniających się warstw ochrony. Administrator może posiadać właściwą rolę, aktywować ją zgodnie z zasadami PIM i mieć aktywną sesję, a mimo to Microsoft Entra może wymagać dodatkowego uwierzytelnienia przed wykonaniem konkretnej operacji.

Przy wdrażaniu Protected Actions trzeba również pamiętać o emergency access account wyłączonym z odpowiedniej polityki Conditional Access oraz o dokładnym przetestowaniu konfiguracji. Błąd jest tutaj szczególnie niebezpieczny, ponieważ Protected Actions mogą chronić również operacje związane z samym Conditional Access.

I właśnie na tym polega najważniejsza różnica: posiadanie uprawnienia nie zawsze musi oznaczać możliwość jego natychmiastowego wykorzystania. Protected Actions dodają kontrolę dokładnie tam, gdzie jest ona najbardziej potrzebna – w chwili wykonywania szczególnie wrażliwej operacji.