Tożsamości zarządzane a rejestracje aplikacji w Azure: kluczowe różnice i najlepsze praktyki

By Mirko Peters · 2026-04-28

Jeśli w dzisiejszych czasach budujesz lub zabezpieczasz w Azure coś poważnego, ogarnięcie tożsamości zarządzanych i rejestracji aplikacji nie jest opcjonalne…

Automatically translated with AI from the original post. Read the English original

Jeśli w dzisiejszych czasach budujesz lub zabezpieczasz w Azure coś poważnego, zrozumienie tożsamości zarządzanych i rejestracji aplikacji to podstawa, a nie opcja. Oba mechanizmy odgrywają kluczową rolę w zarządzaniu tożsamością i dostępem dla Twoich aplikacji, automatyzacji i usług. Ale jeśli pomylisz, który model pasuje do jakiego zastosowania, skończysz z niepotrzebnymi problemami, lukami w zabezpieczeniach albo zbyt dużym nakładem pracy przy zarządzaniu sekretami.

Ten przewodnik wyjaśnia, czym są tożsamości zarządzane i rejestracje aplikacji, jak współpracują z Entra ID (dawniej Azure AD) oraz dlaczego wybór właściwego podejścia ma znaczenie dla bezpieczeństwa i codziennej pracy. Znajdziesz tu konkretne definicje, praktyczne scenariusze, wskazówki dotyczące migracji z sekretów oraz praktyczne porady dotyczące rozwiązywania problemów i zarządzania. Celem jest pomoc w prowadzeniu bardziej szczelnej, bezpiecznej i wydajnej chmury Microsoft, zwłaszcza że ataki się nasilają, a najlepsze praktyki Entra ID ewoluują.

Omówienie tożsamości zarządzanych i rejestracji aplikacji

Zacznijmy od jasnego określenia, co faktycznie robią tożsamości zarządzane i rejestracje aplikacji w Azure i Entra ID. Oba mechanizmy umożliwiają podmiotom nieludzkim, takim jak aplikacje, skrypty czy automatyzacje, uwierzytelnianie się i dostęp do zasobów w chmurze Microsoft. Różnią się jednak sposobem działania oraz codziennymi problemami, które rozwiązują (lub powodują).

Tożsamości zarządzane to odpowiedź Azure na uwierzytelnianie bez sekretów. Zamiast zajmować się hasłami aplikacji i certyfikatami, możesz przypisać zasobowi Azure (np. maszynie wirtualnej, usłudze App Service czy aplikacji logiki) własną tożsamość w Entra ID. Tą tożsamością automatycznie zarządza Azure: powstaje wraz z utworzeniem zasobu, zostaje usunięta po jego skasowaniu i, co najważniejsze, nigdy nie wymaga przekazywania zwykłych sekretów. Tożsamości zarządzane występują w dwóch odmianach: przypisane systemowo (jedna na zasób, ściśle zamknięta) oraz przypisane przez użytkownika (można je wielokrotnie wykorzystywać w wielu zasobach).

Rejestracje aplikacji to klasyczne podejście. Zarejestrowanie aplikacji w Entra ID tworzy obiekt aplikacji i przydziela identyfikator klienta, a opcjonalnie sekrety lub certyfikaty do uwierzytelniania. Jeśli Twoja aplikacja musi logować się do usług Microsoft, uzyskiwać dostęp do Graph API albo działać poza Azure (lub jako więcej niż jeden zasób), najprawdopodobniej użyjesz rejestracji aplikacji. Ale to Ty odpowiadasz za zarządzanie jej sekretami, bezpieczeństwem i cyklem życia, a wiąże się to z pewnymi kompromisami.

Wybór odpowiedniego narzędzia to nie tylko decyzja techniczna. To kalkulacja ryzyka dla bezpieczeństwa: sekrety są łakomym celem dla atakujących, podczas gdy tożsamości zarządzane bez sekretów eliminują całe klasy podatności. Jeśli chcesz zobaczyć, dlaczego ma to takie znaczenie, zajrzyj do szczegółowego omówienia nadużyć zgody OAuth w Entra ID. Atakujący wiedzą, jak utrzymać dostęp w środowiskach, w których podstawy są zaniedbane, dlatego właściwe ustawienie tożsamości to pierwszy krok.

Kluczowe różnice: cykl życia, bezpieczeństwo i integracja z Azure

Tu teoria spotyka się z rzeczywistością. Tożsamości zarządzane i rejestracje aplikacji dają aplikacjom lub skryptom swego rodzaju cyfrowe „plakietki z imieniem”, dzięki którym mogą uzyskiwać dostęp do zasobów. Ale sposób ich uzyskiwania, dbania o nie i sprzątania po nich różni się, i to znacznie.

Tożsamości zarządzane są tak bliskie zasady „ustaw i zapomnij”, jak to tylko możliwe w chmurze. Utwórz zasób Azure, zażądaj dla niego tożsamości zarządzanej i gotowe. Azure sam utworzy tożsamość, podłączy ją do Entra ID i utrzyma synchronizację po stronie zaplecza. Usuń zasób, a tożsamość również zniknie. Nie ma żadnego zarządzania sekretami ani rotacji haseł, a zespoły bezpieczeństwa śpią spokojniej.

Rejestracje aplikacji wymagają znacznie większego nakładu pracy. Ręcznie tworzysz rejestrację aplikacji w Entra ID, pilnujesz jej identyfikatora klienta i generujesz sekrety lub certyfikaty do uwierzytelniania. Z czasem sekrety wygasają (albo mogą wyciec), a to Ty musisz kontrolować, które aplikacje z nich korzystają. Rotacja sekretów, śledzenie wygasających poświadczeń i usuwanie osieroconych rejestracji to zadanie samo w sobie, dlatego zespoły bezpieczeństwa zawsze pytają o automatyzację zarządzania cyklem życia.

Pod względem bezpieczeństwa różnica jest wyraźna: tożsamości zarządzane korzystają z uwierzytelniania bez sekretów, powiązanego z zasobami platformy Azure, natomiast rejestracje aplikacji opierają się na statycznych sekretach lub certyfikatach. Dlatego tożsamości zarządzane są preferowane wszędzie tam, gdzie sekrety stanowią ryzyko, oraz gdy kluczowa jest automatyzacja.

Te różnice w cyklu życia i bezpieczeństwie mają duże znaczenie dla automatyzacji, zgodności i utrzymania szczelności środowisk chmurowych. Jeśli chcesz zobaczyć, jak zasady zarządzania i mechanizmy kontroli wpływają na rozrost tożsamości i odchylenia w zabezpieczeniach, zajrzyj do tego przewodnika o strategii zarządzania Azure — to lektura obowiązkowa dla każdego, kto odpowiada za duże, rozrastające się zasoby Azure.

Jednostki usługi, role RBAC i uprawnienia Microsoft Graph

Teraz zajrzyjmy nieco pod maskę. Pod spodem zarówno tożsamości zarządzane, jak i rejestracje aplikacji korzystają z jednostek usługi (service principal) w Entra ID. Jednostkę usługi warto traktować jako rzeczywistą, działającą tożsamość, o której wie Entra ID. Niezależnie od tego, czy pochodzi ona z tożsamości zarządzanej, czy z rejestracji aplikacji, to właśnie ten obiekt otrzymuje uprawnienia i dostęp w Twojej dzierżawie.

W przypadku rejestracji aplikacji, gdy dodajesz nową aplikację, Entra tworzy odpowiadającą jej jednostkę usługi dla każdej dzierżawy, do której ją przypiszesz. To na tej tożsamości przydzielasz role RBAC platformy Azure, takie jak Contributor czy Reader, oraz nadajesz uprawnienia interfejsu API Graph, zarówno delegowane, jak i na poziomie aplikacji.

Tożsamości zarządzane są nieco inne, ale zbudowane na tych samych podstawach. Włączenie tożsamości zarządzanej dla zasobu platformy Azure powoduje, że Entra tworzy jednostkę usługi o specjalnym przeznaczeniu, która istnieje i znika razem z zasobem. Następnie przypisujesz role RBAC (np. Key Vault Reader) bezpośrednio do tej tożsamości, a zasób otrzymuje w tle dostęp oparty na tokenach. Bez zmian w kodzie i bez krążących sekretów.

Nadawanie uprawnień to moment, w którym teoria spotyka się z praktyką. Oba modele korzystają z RBAC platformy Azure do kontroli dostępu na poziomie zasobów, ale sposób nadawania uprawnień Microsoft Graph się różni. Rejestracje aplikacji pozwalają zatwierdzać dostęp do interfejsu API Graph poprzez jawną zgodę lub zatwierdzenie przez administratora. Tożsamościom zarządzanym można natomiast przydzielić uprawnienia aplikacji do Microsoft Graph bez interaktywnego logowania, dzięki czemu idealnie nadają się do automatyzacji, która musi pobierać dane użytkowników, audytować zabezpieczenia lub uruchamiać przepływy pracy.

Przypisywanie dostępu i monitorowanie zgodności tych tożsamości nie jest jednak czymś, co można „ustawić i zapomnieć”. Ścisłe przypisywanie ról RBAC, regularne audyty oraz narzędzia takie jak Microsoft Defender for Cloud pomagają kontrolować, kto co robi, wykrywać błędne konfiguracje i ograniczać odchylenia do minimum. Chcesz zgłębić zarządzanie tożsamościami? Nie przegap przewodnika o zarządzaniu przedsiębiorstwem w Azure ani poradnika o monitorowaniu zgodności w Microsoft Defender for Cloud, który zawiera praktyczne wskazówki dotyczące ciągłego zabezpieczania.

Wybór właściwego modelu: scenariusze, migracja i zarządzanie

Całe to tło jest ważne, ale większość zespołów chce przede wszystkim wiedzieć: kiedy używać tożsamości zarządzanych, a kiedy rejestracji aplikacji? I jak migrować lub zarządzać tymi tożsamościami, żeby w miarę skalowania nic nie poszło nie tak?

Tożsamości zarządzane sprawdzają się najlepiej w obciążeniach działających bezpośrednio w Azure, które potrzebują dostępu tylko w ramach tej samej dzierżawy. Przykładem mogą być maszyny wirtualne uruchamiające skrypty, usługi App Service łączące się z Key Vault czy aplikacje Logic Apps wysyłające zapytania do Microsoft Graph. Bezpieczeństwo jest lepsze, konfiguracja szybsza, a zarządzanie sekretami mniej uciążliwe. Jeśli jednak działasz w modelu SaaS, tworzysz rozwiązania wielodzierżawcze lub konfiguracje hybrydowe (np. aplikacje lokalne łączące się z interfejsami API w chmurze), rejestracje aplikacji nadal są standardowym wyborem ze względu na elastyczność i szerszą zgodność.

Migracja z rejestracji aplikacji do tożsamości zarządzanych to gorący temat. Proces zaczyna się od oceny gotowości: które obciążenia faktycznie mogą przejść na nowy model i jakie zależności oraz ograniczenia istnieją? W przypadku aplikacji już opartych na rejestracjach aplikacji warto wdrażać zmiany etapami, dokładnie je testować i mieć plany awaryjne, aby uniknąć przestojów lub niespodzianek w uwierzytelnianiu.

Środowiska hybrydowe i wielochmurowe wymagają odrobiny kreatywności. Czasem trzeba połączyć oba modele—praktyka ta nazywa się tożsamością hybrydową. Sztuczka polega na minimalizowaniu sekretów, ograniczaniu uprawnień i jasnym dokumentowaniu, która tożsamość do czego służy. I tak, regularne audyty są koniecznością, bo pozwalają wykryć nieaktualne lub osierocone tożsamości, które stwarzają ukryte ryzyko.

Silne zasady zarządzania spinają całą strategię w całość. Korzystanie z Azure Policy, Privileged Identity Management oraz regularnych kontroli zgodności pozwala egzekwować zasadę najmniejszych uprawnień, wykrywać odchylenia i być zgodnym z modelem zero trust. Aby spojrzeć na rzeczywistość bez złudzeń, jeśli chodzi o konta usługowe a prawdziwe tożsamości obciążeń (i o tym, dlaczego podejścia z dawnych lat zawodzą), zapoznaj się z tą analizą: ryzyko tożsamości nieludzkich a Microsoft Entra Workload Identities. Szukasz kompleksowych podstaw zarządzania? Materiał strategia zarządzania w przedsiębiorstwie zawiera wiele sprawdzonych praktyk.