Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Microsoft załatał podatność w Microsoft Entra ID związaną z rolą administracyjną Agent ID Administrator. Błąd wynikał z niewłaściwego ograniczenia zakresu uprawnień tej roli, co w określonych scenariuszach umożliwiało przejęcie obiektów service principal, a następnie wykorzystanie ich uprawnień do dalszej eskalacji dostępu w środowisku.
To istotny problem z perspektywy bezpieczeństwa tożsamości, ponieważ service principal są szeroko wykorzystywane do automatyzacji, integracji aplikacyjnych i dostępu maszynowego w środowiskach chmurowych. Naruszenie kontroli nad taką tożsamością może oznaczać przejęcie zaufanego elementu infrastruktury.
W skrócie
- Luka dotyczyła wbudowanej roli Agent ID Administrator w Microsoft Entra ID.
- Użytkownik z tą rolą mógł przypisać sobie własność dowolnego service principal, także niezwiązanego z agentami AI.
- Następnie możliwe było dodanie własnych poświadczeń i uwierzytelnienie się jako przejęty obiekt.
- Skutkiem mogła być eskalacja uprawnień, jeśli przejęty service principal miał szeroki dostęp do katalogu, Microsoft Graph lub krytycznych zasobów.
- Microsoft wdrożył poprawkę 9 kwietnia 2026 roku.
Kontekst / historia
Rola Agent ID Administrator została wprowadzona w kontekście rozwoju mechanizmów zarządzania tożsamościami agentów AI w Entra ID. Jej celem było administrowanie cyklem życia takich tożsamości, jednak zastosowane mechanizmy autoryzacyjne okazały się zbyt szerokie.
Problem zgłoszono Microsoftowi 1 marca 2026 roku. Analiza wykazała, że architektura roli opierała się na współdzielonych prymitywach tożsamości, ale bez wystarczająco precyzyjnego ograniczenia ich wyłącznie do agentów AI. W efekcie uprawnienia rozszerzały się także na zwykłe service principal.
Analiza techniczna
Podatność miała charakter błędu autoryzacyjnego typu scope overreach. W praktyce rola, która miała działać wyłącznie w obszarze tożsamości agentów, pozwalała wykonywać operacje również na standardowych obiektach service principal.
Przykładowy scenariusz nadużycia wyglądał następująco:
- atakujący uzyskiwał konto z rolą Agent ID Administrator,
- nadawał sobie własność wybranego service principal,
- dodawał własne poświadczenia, takie jak sekret lub inny mechanizm uwierzytelnienia,
- logował się jako przejęty service principal,
- wykorzystywał istniejące uprawnienia tej tożsamości do dalszych działań w dzierżawie.
Nie oznaczało to automatycznie pełnej kompromitacji każdego środowiska. Skuteczność ataku zależała od rzeczywistych uprawnień przypisanych do przejętego service principal. Jeśli jednak taki obiekt posiadał role katalogowe, szerokie uprawnienia aplikacyjne lub dostęp do procesów administracyjnych, skutki mogły być bardzo poważne.
Szczególnie niebezpieczne były przypadki, w których service principal miał:
- uprzywilejowane role w katalogu,
- szerokie uprawnienia aplikacyjne do Microsoft Graph,
- dostęp do krytycznych zasobów chmurowych,
- możliwość modyfikacji konfiguracji bezpieczeństwa,
- udział w automatyzacji CI/CD lub procesach provisioningowych.
Po wdrożeniu poprawki próby nadania własności nieagentskim service principal z wykorzystaniem tej roli są blokowane i kończą się odmową dostępu.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją podatności była możliwość pełnego przejęcia service principal bez potrzeby łamania zabezpieczeń kryptograficznych czy przejmowania kont użytkowników. Atakujący mógł wykorzystać błędny model uprawnień, aby uzyskać kontrolę nad uprzywilejowaną tożsamością techniczną, która już cieszyła się zaufaniem w środowisku.
Ryzyko było szczególnie wysokie w organizacjach, które intensywnie wykorzystują service principal do automatyzacji administracyjnej, nie prowadzą regularnych przeglądów właścicieli i poświadczeń, utrzymują nadmiernie uprzywilejowane tożsamości aplikacyjne oraz nie monitorują zmian właścicielskich i rotacji sekretów.
Incydent pokazuje również rosnące znaczenie non-human identities jako wektora ataku w chmurze. Tożsamości techniczne często działają poza codzienną uwagą zespołów bezpieczeństwa, a jednocześnie posiadają rozległe i trwałe uprawnienia.
Rekomendacje
Organizacje korzystające z Entra ID powinny potraktować ten przypadek jako impuls do przeglądu całego obszaru zarządzania tożsamościami nieludzkimi.
- Przeprowadzić audyt przypisań ról uprzywilejowanych, szczególnie związanych z zarządzaniem agentami AI i service principal.
- Zweryfikować właścicieli wszystkich krytycznych service principal.
- Przejrzeć historię zmian właścicieli oraz tworzenia nowych poświadczeń.
- Ograniczyć uprawnienia aplikacyjne zgodnie z zasadą najmniejszych uprawnień.
- Zidentyfikować service principal posiadające role katalogowe lub szerokie uprawnienia do Graph API.
- Włączyć alertowanie dla operacji takich jak dodanie właściciela, utworzenie sekretu, dodanie certyfikatu i zmiany uprawnień aplikacyjnych.
- Skrócić czas życia poświadczeń i wdrożyć regularną rotację sekretów oraz certyfikatów.
- Objąć tożsamości techniczne pełnym monitoringiem IAM/PAM i okresową recertyfikacją.
- Ocenić, czy nowe funkcje związane z AI nie dziedziczą zbyt szerokich uprawnień z istniejących mechanizmów katalogowych.
- Sprawdzić, czy poprawki Microsoft zostały uwzględnione w procedurach operacyjnych i testach bezpieczeństwa.
W środowiskach o podwyższonym ryzyku warto dodatkowo przeprowadzić retrospektywną analizę logów pod kątem nietypowych zmian własności service principal oraz nieautoryzowanego dodawania poświadczeń przed wdrożeniem poprawki.
Podsumowanie
Luka w Microsoft Entra ID pokazała, jak groźne mogą być błędy zakresu uprawnień w nowych rolach administracyjnych, zwłaszcza tych związanych z tożsamościami AI i innymi non-human identities. Możliwość przejęcia dowolnego service principal przez użytkownika z rolą Agent ID Administrator stanowiła realną ścieżkę eskalacji uprawnień w środowiskach, gdzie istniały wysoko uprzywilejowane tożsamości aplikacyjne.
Choć poprawka Microsoft zamyka ten konkretny wektor ataku, incydent przypomina, że bezpieczeństwo chmury zależy nie tylko od ochrony kont użytkowników, ale również od ścisłej kontroli nad tożsamościami technicznymi, ich właścicielami oraz poświadczeniami.