Zalecenia dotyczące najlepszych rozwiązań dotyczących tożsamości zarządzanych
Tożsamości zarządzane dla zasobów platformy Azure to funkcja identyfikatora Entra firmy Microsoft. Każda usługa platformy Azure obsługująca tożsamości zarządzane dla zasobów platformy Azure ma własną oś czasu. Pamiętaj, aby przed rozpoczęciem sprawdzić stan dostępności tożsamości zarządzanych dla swojego zasobu i znane problemy.
Wybieranie tożsamości zarządzanych przypisanych przez użytkownika lub systemu
Tożsamości zarządzane przypisane przez użytkownika są wydajniejsze w szerszym zakresie scenariuszy niż tożsamości zarządzane przypisane przez system. Zapoznaj się z poniższą tabelą, aby zapoznać się z niektórymi scenariuszami i zaleceniami dotyczącymi przypisanych przez użytkownika lub przypisanych 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 obsługują tożsamości zarządzane.
Ten cykl życia umożliwia oddzielenie obowiązków związanych z tworzeniem zasobów i administrowanie tożsamościami. Tożsamości przypisane przez użytkownika i ich przypisania ról można skonfigurować przed zasobami, 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.
W miarę tworzenia i usuwania tożsamości przypisanych przez system wraz z zasobem nie można wcześniej tworzyć przypisań ról. 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 zostanie zmniejszone, ponieważ istnieje mniej odrębnych 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. Mimo że usunięta tożsamość przypisana przez system nie jest już dostępna dla żadnego zasobu, będzie ona liczone do limitu do pełnego przeczyszczania po upływie 30 dni. Wdrożenie zasobów skojarzonych z jedną tożsamością przypisaną przez użytkownika będzie wymagało utworzenia tylko jednej jednostki usługi w identyfikatorze Entra firmy Microsoft, co pozwala uniknąć limitu szybkości. Użycie pojedynczej tożsamości utworzonej z wyprzedzeniem spowoduje również zmniejszenie ryzyka opóźnień replikacji, które mogą wystąpić, jeśli wiele zasobów zostanie utworzonych 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 będzie 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ć istniejącej tożsamości przypisanej przez użytkownika. |
| Rejestrowanie inspekcji | Tożsamość przypisana przez system | Jeśli musisz zarejestrować określony zasób wykonaną akcję, a nie 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 przedstawiają różnicę między tożsamościami przypisanymi przez system i przypisanymi przez użytkownika, gdy są używane do zezwalania kilku maszynom wirtualnym na dostęp do dwóch kont magazynu.
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 zapewniają im dostęp do dwóch kont magazynu.
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 funkcji szablonu usługi Resource Manager co tożsamości przypisane 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 używania tożsamości przypisanej przez współużytkowanego użytkownika, jak i stosowania szczegółowych uprawnień w razie potrzeby.
W poniższym przykładzie "Maszyna wirtualna 3" i "Maszyna wirtualna 4" mogą uzyskiwać dostęp do kont magazynu i magazynów kluczy, w zależności od tożsamości przypisanej przez użytkownika 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 magazynu, jak i magazynów kluczy, w zależności od tożsamości używanej 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ą. Należy zawsze zminimalizować promień wybuchu bezpieczeństwa, aby narażać tożsamość na minimalne uszkodzenia.
Rozważenie wpływu przypisywania tożsamości zarządzanych do zasobów platformy Azure i/lub udzielania uprawnień przypisywania do użytkownika
Należy pamiętać, że gdy zasób platformy Azure, taki jak aplikacja logiki platformy Azure, funkcja platformy Azure lub maszyna wirtualna itd. jest przypisana tożsamość zarządzana. 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) udzielono dostępu do odczytu/zapisu do usługi StorageAccount77555 i została przypisana do usługi LogicApp3388, 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 usługi 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.
Należy ręcznie usunąć tożsamość przypisaną przez użytkownika, jeśli nie jest już wymagana, nawet jeśli żadne zasoby nie są z nią skojarzone.
Przypisania ról nie są usuwane automatycznie po usunięciu tożsamości zarządzanych przypisanych przez system lub przypisanych 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 tożsamościami zarządzanymi będą wyświetlane z komunikatem "Nie znaleziono tożsamości" po wyświetleniu w portalu. Dowiedz się więcej.
Przypisania ról, które nie są już skojarzone z użytkownikiem lub jednostką usługi, będą wyświetlane z wartością ObjectType Unknown. 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ą ObjectType Unknown , 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 w przypadku tożsamości innych niż ludzkie, takich jak Microsoft Entra Applications i Tożsamości zarządzane, dokładny mechanizm przedstawiania tej informacji o autoryzacji aplikacji nie jest obecnie idealnie odpowiedni. 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. W przypadku użytkownika, który zwykle nie jest problemem, ponieważ użytkownik może uzyskać nowy token dostępu, wylogowając się i ponownie (lub czekając na wygaśnięcie okresu istnienia tokenu, czyli domyślnie 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 wprowadzenie zmian w grupie lub członkostwie roli tożsamości zarządzanej może potrwać kilka godzin. 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 odczekenie kilku godzin na zasób platformy Azure przy użyciu tożsamości w celu uzyskania poprawnego dostępu.
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że być używana jak grupa, ponieważ może być przypisana do co najmniej jednego zasobu platformy Azure do użycia. Operację przypisania można kontrolować przy użyciu roli Współautor tożsamości zarządzanej i Operator tożsamości zarządzanej.