Tożsamości zarządzane przypisane przez system a przypisane przez użytkownika w Azure: którą wybrać?

By Mirko Peters · 2026-10-26

Porównaj tożsamości zarządzane w Azure przypisane przez system i przypisane przez użytkownika. Dowiedz się, którego typu tożsamości użyć, aby ograniczyć obciążenie administracyjne i bezpiecznie skalować rozwiązanie.

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

Wybór między tożsamościami zarządzanymi przypisanymi przez system a przypisanymi przez użytkownika w Azure to jedna z najważniejszych decyzji architektonicznych dotyczących bezpieczeństwa chmury i obciążenia administracyjnego. Tożsamości przypisane przez system są bezpośrednio powiązane z cyklem życia pojedynczego zasobu Azure, natomiast tożsamości przypisane przez użytkownika działają jako samodzielne podmioty, które można współdzielić między wieloma zasobami. Znacząco ogranicza to nadmiarowe przypisania ról i zapobiega wąskim gardłom związanym z limitami tokenów w zautomatyzowanych środowiskach.

Najważniejsze wnioski

• Tożsamości przypisane przez system są tworzone, zarządzane i usuwane automatycznie wraz z zasobem Azure, do którego należą.
• Tożsamości przypisane przez użytkownika istnieją niezależnie jako samodzielne zasoby Azure, dzięki czemu można je współdzielić między wiele maszyn wirtualnych, aplikacji i funkcji.
• Microsoft zaleca tożsamości przypisane przez użytkownika w większości scenariuszy obejmujących wiele zasobów, aby zminimalizować prace ewidencyjne i złożone przypisania ról.
• Używanie tożsamości przypisanych przez system w szybko skalowanych lub krótkotrwałych środowiskach testowych może prowadzić do nagromadzenia się tożsamości i przekroczenia limitów żądań Azure.
• Pojedynczy zasób Azure może obsługiwać zarówno tożsamość przypisaną przez system do izolowanego logowania, jak i jedną lub więcej tożsamości przypisanych przez użytkownika dla obciążeń współdzielonych.

Zrozumienie zasadniczych różnic

Projektując bezpieczne aplikacje chmurowe bez zakodowanych na stałe sekretów i ciągów połączeń, musisz zdecydować, jak Twoje obciążenia będą uwierzytelniać się w usłudze Microsoft Entra ID. Azure oferuje dwa odrębne typy tożsamości zarządzanych: przypisane przez system i przypisane przez użytkownika. Zrozumienie ich działania „pod maską” pozwoli Twojemu zespołowi inżynierskiemu zaoszczędzić niezliczone godziny rozwiązywania problemów i utrzymania administracyjnego.

Jak działają tożsamości przypisane przez system

Tożsamość zarządzana przypisana przez system jest włączana bezpośrednio w konkretnym zasobie Azure, takim jak maszyna wirtualna Azure, App Service czy aplikacja funkcji. Można to porównać do narodzenia się razem z zasobem i zniknięcia wraz z nim. Gdy włączasz tożsamość przypisaną przez system na maszynie wirtualnej, Azure tworzy w usłudze Microsoft Entra ID tożsamość o dokładnie takiej nazwie jak ten zasób.

Główną zaletą tego podejścia są prostota i powiązanie z cyklem życia. Ponieważ tożsamość jest związana z zasobem, nie musisz martwić się osieroconymi tożsamościami pozostającymi w katalogu po wycofaniu maszyny wirtualnej. Gdy usuniesz zasób, Azure automatycznie usunie za Ciebie tożsamość. Ta ścisła zależność tworzy jednak ograniczenia architektoniczne, jeśli wiele zasobów potrzebuje identycznych uprawnień dostępu.

Jak działają tożsamości przypisane przez użytkownika

Tożsamość zarządzana przypisana przez użytkownika jest natomiast najpierw tworzona jako samodzielny zasób Azure. Nadajesz jej własną nazwę, zarządzasz nią niezależnie w grupach zasobów i jawnie podłączasz do jednej lub więcej usług Azure, które wymagają dostępu. Ponieważ nie jest związana z cyklem życia żadnej pojedynczej maszyny wirtualnej ani App Service, pozostaje nawet wtedy, gdy wszystkie podłączone do niej zasoby zostaną usunięte.

Ta samodzielność zmienia sposób, w jaki architekci chmury zarządzają dostępem na dużą skalę. Zamiast traktować uwierzytelnianie jako relację jeden do jednego między pojedynczym serwerem a bazą danych, tożsamości przypisane przez użytkownika pozwalają budować modele uwierzytelniania wiele do jednego, w których klastry mikrousług współdzielą jeden, dobrze zarządzany kontekst bezpieczeństwa.

Obciążenie administracyjne a przypisania ról

Praktyczne różnice między tymi dwoma typami tożsamości stają się bardzo wyraźne, gdy spojrzeć na zarządzanie kontrolą dostępu opartą na rolach (RBAC) w dużych środowiskach. Za każdym razem, gdy przyznajesz tożsamości dostęp do konta magazynu, magazynu kluczy lub bazy danych, musisz utworzyć przypisanie roli platformy Azure.

Weźmy typowy scenariusz przedsiębiorstwa: masz cztery maszyny wirtualne, które muszą odczytywać dane z dwóch oddzielnych kont Azure Storage. Jeśli polegasz wyłącznie na tożsamościach przypisanych przez system, każda maszyna wirtualna wymaga własnej, dedykowanej tożsamości. Aby przyznać dostęp, musisz skonfigurować osiem oddzielnych przypisań ról – po jednym dla każdej maszyny na każdym koncie magazynu. Jeśli skalujesz środowisko do dwudziestu maszyn wirtualnych, liczba przypisań ról rośnie wykładniczo, co tworzy prawdziwy koszmar administracyjny.

Dla porównania: jeśli te same cztery maszyny wirtualne współdzielą jedną zarządzaną tożsamość przypisaną przez użytkownika, potrzebujesz łącznie tylko dwóch przypisań ról. Uzyskujesz dokładnie taką samą szczegółową kontrolę dostępu przy ułamku wysiłku administracyjnego. Gdy członkowie zespołu odchodzą lub infrastruktura jest odbudowywana, utrzymanie uporządkowanego katalogu staje się znacznie prostsze.

Pułapki architektoniczne i przypadki brzegowe

Choć tożsamości przypisane przez użytkownika są zazwyczaj bardziej efektywne, wybór niewłaściwego typu może wprowadzić ukryte problemy operacyjne. Jedno z głównych zagrożeń dotyczy krótkotrwałych zasobów obliczeniowych lub środowisk z automatycznym skalowaniem.

Jeśli w ciągu dnia szybko tworzysz i usuwasz środowiska deweloperskie, testowe lub kontenerowe, korzystając z tożsamości przypisanych przez system, tożsamości te będą się gromadzić w usłudze Microsoft Entra ID, zanim uruchomią się procedury czyszczenia. Z czasem organizacje mogą napotkać limity szybkości katalogu platformy Azure, przez co platforma odrzuci żądania utworzenia nowych zasobów. Współdzielenie tożsamości przypisanej przez użytkownika między tymi efemerycznymi obciążeniami całkowicie eliminuje tę pułapkę.

Z kolei tożsamości przypisane przez system sprawdzają się w dwóch konkretnych scenariuszach:

• Audyt i niezaprzeczalność: Jeśli logi bezpieczeństwa muszą jednoznacznie dowodzić, która konkretna maszyna wirtualna wykonała określoną operację, tożsamości przypisane przez system zapewniają atrybucję na poziomie pojedynczego zasobu, ponieważ każdy zasób posiada własny, unikalny obiekt w katalogu.
• Ścisłe czyszczenie cyklu życia: Jeśli wymogi zgodności nakazują, aby wszystkie uprawnienia dostępu zniknęły dokładnie w momencie zakończenia działania zasobu, tożsamości przypisane przez system obsługują to automatycznie, bez interwencji człowieka.

Pamiętaj, że nie jesteś zmuszony do wyboru absolutnie binarnego. Pojedynczy zasób platformy Azure może mieć zarówno tożsamość przypisaną przez system do prywatnych, wrażliwych operacji, jak i jedną lub więcej tożsamości przypisanych przez użytkownika do współdzielonych przepływów pracy w firmie.

Podsumowanie

Zarządzanie tożsamościami w chmurze Microsoft wymaga wyważenia efektywności operacyjnej i ścisłych granic bezpieczeństwa. Rozumiejąc odmienności operacyjne między tożsamościami przypisanymi przez system a tożsamościami przypisanymi przez użytkownika, możesz projektować solidne, skalowalne architektury, które eliminują zakodowane na stałe sekrety bez nadmiernego rozrostu administracyjnego.

Aby zgłębić, jak wystawiane są tokeny, jak Azure Key Vault integruje się bez haseł oraz jakich typowych pułapek bezpieczeństwa unikać, koniecznie posłuchaj całego odcinka podcastu, aby poznać opinie ekspertów i praktyczne strategie.

Często zadawane pytania

Czy pojedynczy zasób platformy Azure może korzystać jednocześnie z tożsamości zarządzanych przypisanych przez system i przez użytkownika?

Tak. Zasób platformy Azure, taki jak maszyna wirtualna lub App Service, może mieć jednocześnie włączoną jedną tożsamość przypisaną przez system i jedną lub więcej tożsamości przypisanych przez użytkownika, co pozwala łączyć dedykowane i współdzielone strategie uwierzytelniania.

Co dzieje się z tożsamością przypisaną przez użytkownika, gdy zasób platformy Azure, do którego jest dołączona, zostanie usunięty?

W przeciwieństwie do tożsamości przypisanych przez system, które są automatycznie usuwane wraz z zasobem nadrzędnym, tożsamości przypisane przez użytkownika istnieją w platformie Azure jako niezależne, samodzielne obiekty, dopóki administrator wyraźnie ich nie usunie.

Dlaczego firma Microsoft zaleca tożsamości przypisane przez użytkownika w większości scenariuszy z wieloma zasobami?

Firma Microsoft zaleca tożsamości przypisane przez użytkownika przede wszystkim po to, aby ograniczyć obciążenie administracyjne i nadmierny rozrost przypisań ról. Współdzielenie jednej tożsamości przez wiele zasobów obliczeniowych znacznie zmniejsza liczbę przypisań RBAC, które trzeba tworzyć i utrzymywać.

Czy zarządzane tożsamości generują koszty w platformie Azure?

Nie, zarówno tożsamości zarządzane przypisane przez system, jak i przypisane przez użytkownika są bezpłatnymi funkcjami dołączonymi do Microsoft Entra ID dla zasobów platformy Azure, jednak za usługi obliczeniowe lub magazynowania, do których uzyskujesz dostęp, mogą obowiązywać standardowe opłaty.