Zalecenia dotyczące najlepszych praktyk zarządzania tożsamością

Tożsamości zarządzane na platformie Azure zapewniają bezpieczny i wygodny sposób zarządzania poświadczeniami aplikacji działających w zasobach platformy Azure. W tym artykule opisano zalecenia dotyczące najlepszych rozwiązań dotyczących wybierania tożsamości zarządzanych przypisanych przez użytkownika i przypisanych przez system, co pomaga zoptymalizować zarządzanie tożsamościami i zmniejszyć nakład pracy administracyjnej.

Wybieranie zarządzanych tożsamości przypisanych przez system lub użytkownika

Tożsamości zarządzane przypisane przez użytkownika są wydajniejsze w szerszym zakresie scenariuszy niż tożsamości zarządzane przypisane przez system. Zobacz poniższą tabelę, aby poznać niektóre scenariusze i zalecenia dotyczące przypisań przez użytkownika lub przez system.

Tożsamości przypisane przez użytkownika mogą być używane przez wiele zasobów, a ich cykle życia są oddzielone od cykli życia zasobów, z którymi są skojarzone. Przeczytaj, które zasoby wspierają tożsamości zarządzane.

Ten cykl życia umożliwia oddzielenie obowiązków związanych z tworzeniem zasobów oraz administrowaniem tożsamościami. Tożsamości przypisane przez użytkownika oraz przypisania ich ról można skonfigurować z wyprzedzeniem względem zasobów, które ich wymagają. Użytkownicy, którzy tworzą zasoby, wymagają dostępu tylko do przypisywania tożsamości przypisanej przez użytkownika bez konieczności tworzenia nowych tożsamości lub przypisań ról.

Ponieważ tożsamości przydzielane przez system są tworzone i usuwane wraz z zasobem, przypisań ról nie można tworzyć z wyprzedzeniem. Ta sekwencja może powodować błędy podczas wdrażania infrastruktury, jeśli użytkownik tworzący zasób nie ma również dostępu do tworzenia przypisań ról.

Jeśli infrastruktura wymaga, aby wiele zasobów wymagało dostępu do tych samych zasobów, można przypisać do nich jedną tożsamość przypisaną przez użytkownika. Obciążenie administracyjne jest zmniejszane, ponieważ istnieje mniej różnych tożsamości i przypisań ról do zarządzania.

Jeśli wymagasz, aby każdy zasób miał własną tożsamość lub zasoby, które wymagają unikatowego zestawu uprawnień i chcesz, aby tożsamość została usunięta w miarę usuwania zasobu, należy użyć tożsamości przypisanej przez system.

Scenariusz	Zalecenie	Uwagi
Szybkie tworzenie zasobów (na przykład przetwarzanie efemeryczne) przy użyciu tożsamości zarządzanych	Tożsamość przypisana przez użytkownika	Jeśli spróbujesz utworzyć wiele tożsamości zarządzanych w krótkim czasie — na przykład wdrożenie wielu maszyn wirtualnych z własną tożsamością przypisaną przez system — może przekroczyć limit szybkości tworzenia obiektów firmy Microsoft Entra, a żądanie zakończy się niepowodzeniem z powodu błędu HTTP 429. Jeśli zasoby są tworzone lub usuwane szybko, możesz również przekroczyć limit liczby zasobów w identyfikatorze Entra firmy Microsoft w przypadku korzystania z tożsamości przypisanych przez system. Chociaż usunięta tożsamość przypisana przez system nie jest już dostępna dla żadnego zasobu, wciąż liczy się do limitu aż do jej pełnego usunięcia po 30 dniach. Wdrożenie zasobów skojarzonych z jedną tożsamością przypisaną przez użytkownika wymaga utworzenia tylko jednego głównego klienta w Microsoft Entra ID, co pozwala na uniknięcie ograniczenia prędkości. Użycie jednej tożsamości utworzonej z wyprzedzeniem zmniejsza ryzyko opóźnień replikacji, które mogą wystąpić w przypadku utworzenia wielu zasobów z własną tożsamością. Przeczytaj więcej na temat limitów usługi subskrypcji platformy Azure.
Zreplikowane zasoby/aplikacje	Tożsamość przypisana przez użytkownika	Zasoby, które wykonują to samo zadanie — na przykład zduplikowane serwery internetowe lub identyczne funkcje uruchomione w usłudze aplikacji i aplikacji na maszynie wirtualnej — zwykle wymagają tych samych uprawnień. Korzystając z tej samej tożsamości przypisanej przez użytkownika, wymagana jest mniejsza liczba przypisań ról, co zmniejsza obciążenie związane z zarządzaniem. Zasoby nie muszą być tego samego typu.
Zgodność	Tożsamość przypisana przez użytkownika	Jeśli organizacja wymaga, aby wszystkie operacje tworzenia tożsamości musiały przejść przez proces zatwierdzania, użycie jednej tożsamości przypisanej przez użytkownika w wielu zasobach wymaga mniejszej liczby zatwierdzeń niż tożsamości przypisane przez system, które są tworzone jako nowe zasoby.
Wymagany dostęp przed wdrożeniem zasobu	Tożsamość przypisana przez użytkownika	Niektóre zasoby mogą wymagać dostępu do niektórych zasobów platformy Azure w ramach wdrożenia. W takim przypadku tożsamość przypisana przez system może nie zostać utworzona w czasie, więc należy użyć wcześniej istniejącej tożsamości przypisanej przez użytkownika.
Logowanie audytu	Tożsamość przypisana przez system	Jeśli musisz zarejestrować, który konkretny zasób wykonał daną akcję, a nie która tożsamość, użyj tożsamości przypisanej przez system.
Zarządzanie cyklem życia uprawnień	Tożsamość przypisana przez system	Jeśli wymagane jest usunięcie uprawnień dla zasobu wraz z zasobem, użyj tożsamości przypisanej przez system.

Używanie tożsamości przypisanych przez użytkownika w celu zmniejszenia administracji

Diagramy pokazują różnicę między tożsamościami przypisanymi przez system a tymi przypisanymi przez użytkownika, gdy są używane do umożliwienia dostępu kilku maszynom wirtualnym do dwóch kont magazynowych.

Na diagramie przedstawiono cztery maszyny wirtualne z tożsamościami przypisanymi przez system. Każda maszyna wirtualna ma te same przypisania ról, które zapewnia im dostęp do dwóch kont magazynowych.

Gdy tożsamość przypisana przez użytkownika jest skojarzona z czterema maszynami wirtualnymi, wymagane są tylko dwa przypisania ról w porównaniu z ośmioma tożsamościami przypisanymi przez system. Jeśli tożsamość maszyn wirtualnych wymaga większej liczby przypisań ról, zostaną one przyznane wszystkim zasobom skojarzonym z tą tożsamością.

Grupy zabezpieczeń mogą również służyć do zmniejszenia liczby wymaganych przypisań ról. Ten diagram przedstawia cztery maszyny wirtualne z tożsamościami przypisanymi przez system, które zostały dodane do grupy zabezpieczeń, z przypisaniami ról dodanymi do grupy zamiast tożsamości przypisanych przez system. Chociaż wynik jest podobny, ta konfiguracja nie oferuje tych samych możliwości szablonu Menedżera Zasobów co tożsamości przypisywane przez użytkownika.

Wiele tożsamości zarządzanych

Zasoby obsługujące tożsamości zarządzane mogą mieć zarówno tożsamość przypisaną przez system, jak i co najmniej jedną tożsamość przypisaną przez użytkownika.

Ten model zapewnia elastyczność zarówno w używaniu tożsamości przypisanej użytkownikowi, jak i stosowaniu szczegółowych uprawnień w razie potrzeby.

W poniższym przykładzie "Maszyna wirtualna 3" i "Maszyna wirtualna 4" mogą mieć dostęp do kont magazynowych i skarbców kluczy, w zależności od tożsamości przypisanej użytkownikowi podczas uwierzytelniania.

W poniższym przykładzie "Maszyna wirtualna 4" ma tożsamość przypisaną przez użytkownika, zapewniając jej dostęp zarówno do kont przechowywania, jak i skarbców kluczy, w zależności od tego, która tożsamość jest używana podczas uwierzytelniania. Przypisania ról dla tożsamości przypisanej przez system są specyficzne dla tej maszyny wirtualnej.

Limity

Wyświetlanie limitów tożsamości zarządzanych oraz ról niestandardowych i przypisań ról.

Przestrzegaj zasady najniższych uprawnień podczas udzielania dostępu

W przypadku udzielania dowolnej tożsamości, w tym tożsamości zarządzanej, uprawnień dostępu do usług, zawsze udzielaj najmniejszych uprawnień wymaganych do wykonania żądanych akcji. Jeśli na przykład tożsamość zarządzana jest używana do odczytywania danych z konta magazynu, nie ma potrzeby zezwalania na uprawnienia tożsamości do zapisywania danych na koncie magazynu. Na przykład przyznanie dodatkowych uprawnień, dzięki czemu tożsamość zarządzana jest współautorem w subskrypcji platformy Azure, gdy nie jest potrzebna, zwiększa promień wybuchu zabezpieczeń skojarzony z tożsamością. Zawsze należy minimalizować obszar oddziaływania zagrożenia bezpieczeństwa, aby kompromitacja tożsamości powodowała minimalne szkody.

Rozważ wpływ przypisywania tożsamości zarządzanych do zasobów Azure i/lub udzielania uprawnień do przypisywania użytkownikowi.

Należy pamiętać, że gdy zasób platformy Azure, taki jak aplikacja logiki platformy Azure lub maszyna wirtualna, ma przypisaną tożsamość zarządzaną, wszystkie uprawnienia przyznane tożsamości zarządzanej są teraz dostępne dla zasobu platformy Azure. Jest to ważne, ponieważ jeśli użytkownik ma dostęp do instalowania lub wykonywania kodu na tym zasobie, użytkownik ma dostęp do wszystkich tożsamości przypisanych/skojarzonych z zasobem platformy Azure. Celem tożsamości zarządzanej jest zapewnienie kodu uruchomionego na zasobie platformy Azure do innych zasobów bez konieczności obsługi lub umieszczania poświadczeń bezpośrednio w kodzie w celu uzyskania dostępu.

Jeśli na przykład tożsamość zarządzana (ClientId = 1234) otrzymuje dostęp do odczytu/zapisu do StorageAccount7755 i jest przypisana do LogicApp3388, a wtedy Alice, która nie ma bezpośredniego dostępu do konta magazynu, ale ma uprawnienia do wykonywania kodu w usłudze LogicApp3388, może również odczytywać/zapisywać dane do/z StorageAccount7755, wykonując kod korzystający z tożsamości zarządzanej.

Podobnie, jeśli Alicja ma uprawnienia do przypisywania tożsamości zarządzanej, może przypisać ją do innego zasobu platformy Azure i mieć dostęp do wszystkich uprawnień dostępnych dla tożsamości zarządzanej.

Ogólnie rzecz biorąc, w przypadku udzielania użytkownikowi dostępu administracyjnego do zasobu, który może wykonywać kod (taki jak aplikacja logiki) i ma tożsamość zarządzaną, należy rozważyć, czy rola przypisana użytkownikowi może zainstalować lub uruchomić kod w zasobie, a jeśli tak, przypisz ją tylko wtedy, gdy użytkownik naprawdę go potrzebuje.

Konserwacja

Tożsamości przypisane przez system są automatycznie usuwane po usunięciu zasobu, a cykl życia tożsamości przypisanej przez użytkownika jest niezależny od wszelkich zasobów, z którymi jest skojarzony.

Musisz ręcznie usunąć tożsamość przypisaną przez użytkownika, jeśli nie jest już wymagana, nawet jeśli nie są z nią skojarzone żadne zasoby.

Przypisania ról nie są usuwane automatycznie, gdy usuwane są tożsamości zarządzane, niezależnie od tego, czy są przypisane przez system, czy przez użytkownika. Te przypisania ról należy usunąć ręcznie, aby limit przypisań ról na subskrypcję nie został przekroczony.

Przypisania ról skojarzone z usuniętymi zarządzanymi tożsamościami są wyświetlane z komunikatem "Nie znaleziono tożsamości", gdy są wyświetlane w portalu. Dowiedz się więcej.

Przypisania ról, które nie są już skojarzone z użytkownikiem lub jednostką usługi, są wyświetlane z wartością ObjectTypeUnknown. Aby je usunąć, można połączyć kilka poleceń programu Azure PowerShell, aby najpierw uzyskać wszystkie przypisania ról, filtrować tylko te z wartością ObjectTypeUnknown , a następnie usuwać te przypisania ról z platformy Azure.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

Ograniczenie używania tożsamości zarządzanych do autoryzacji

Używanie grup identyfikatorów Entra firmy Microsoft do udzielania dostępu do usług to doskonały sposób na uproszczenie procesu autoryzacji. Pomysł jest prosty — udzielanie uprawnień grupie i dodawanie tożsamości do grupy, aby dziedziczyły te same uprawnienia. Jest to dobrze ugruntowany wzorzec z różnych systemów lokalnych i działa dobrze, gdy tożsamości reprezentują użytkowników. Inną opcją kontrolowania autoryzacji w identyfikatorze Entra firmy Microsoft jest użycie ról aplikacji, które umożliwiają deklarowanie ról specyficznych dla aplikacji (a nie grup, które są koncepcją globalną w katalogu). Następnie można przypisać role aplikacji do tożsamości zarządzanych (a także użytkowników lub grup).

W obu przypadkach dla tożsamości innych niż ludzkie, takich jak aplikacje Microsoft Entra i tożsamości zarządzane, dokładny mechanizm przekazywania tych informacji autoryzacyjnych aplikacji nie jest obecnie optymalnie dostosowany. Dzisiejsza implementacja z identyfikatorem Entra firmy Microsoft i kontrolą dostępu na podstawie ról platformy Azure (Azure RBAC) używa tokenów dostępu wystawionych przez identyfikator Entra firmy Microsoft do uwierzytelniania każdej tożsamości. Jeśli tożsamość zostanie dodana do grupy lub roli, zostanie ona wyrażona jako oświadczenia w tokenie dostępu wystawionym przez identyfikator Entra firmy Microsoft. Kontrola dostępu oparta na rolach platformy Azure używa tych oświadczeń do dalszej oceny reguł autoryzacji w celu zezwolenia na dostęp lub odmowy dostępu.

Biorąc pod uwagę, że grupy i role tożsamości są oświadczeniami w tokenie dostępu, wszelkie zmiany autoryzacji nie zostaną zastosowane do momentu odświeżenia tokenu. Dla użytkownika zazwyczaj nie stanowi to problemu, ponieważ może on uzyskać nowy token dostępu, wylogowując się i ponownie logując (lub czekając na wygaśnięcie okresu istnienia tokenu, który domyślnie wynosi 1 godzinę). Z drugiej strony tokeny tożsamości zarządzanej są buforowane przez podstawową infrastrukturę platformy Azure na potrzeby wydajności i odporności: usługi zaplecza dla tożsamości zarządzanych utrzymują pamięć podręczną na identyfikator URI zasobu przez około 24 godziny. Oznacza to, że zmiany dotyczące grupy lub członkostwa roli tożsamości zarządzanej mogą zacząć obowiązywać dopiero po kilku godzinach. Obecnie nie można wymusić odświeżenia tokenu tożsamości zarządzanej przed jego wygaśnięciem. Jeśli zmienisz grupę lub członkostwo w roli tożsamości zarządzanej w celu dodania lub usunięcia uprawnień, może być konieczne odczekanie kilku godzin, zanim zasób platformy Azure używający tej tożsamości otrzyma poprawny dostęp.

Jeśli to opóźnienie nie jest akceptowalne dla Twoich wymagań, rozważ alternatywy używania grup lub ról w tokenie. Aby upewnić się, że zmiany w uprawnieniach tożsamości zarządzanych zostaną zastosowane szybko, zalecamy grupowanie zasobów platformy Azure przy użyciu tożsamości zarządzanej przypisanej przez użytkownika z uprawnieniami zastosowanymi bezpośrednio do tożsamości, zamiast dodawania lub usuwania tożsamości zarządzanych z grupy Firmy Microsoft Entra, która ma uprawnienia. Tożsamość zarządzana przypisana przez użytkownika można traktować jak grupę, ponieważ może być przypisana do co najmniej jednego zasobu platformy Azure do użytku. Operację przypisania można kontrolować przy użyciu roli Współautora zarządzanej tożsamości i roli Operatora zarządzanej tożsamości.