Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Aplikacje mogą używać biblioteki Azure Identity do uwierzytelniania w Microsoft Entra ID, co umożliwia aplikacjom dostęp do usług i zasobów Azure. To wymaganie uwierzytelniania ma zastosowanie, niezależnie od tego, czy aplikacja jest wdrażana na Azure, hostowana na lokalnym serwerze, czy uruchamiana lokalnie na stacji roboczej dewelopera. W poniższych sekcjach opisano zalecane podejścia do uwierzytelniania aplikacji do Microsoft Entra ID w różnych środowiskach przy użyciu bibliotek klienckich Azure SDK.
Zalecane podejście do uwierzytelniania aplikacji
Uwierzytelnianie oparte na tokenach przez Microsoft Entra ID to zalecane podejście do uwierzytelniania aplikacji dla Azure, zamiast używania łańcuchów połączeniowych lub opcji kluczowych. Biblioteka tożsamości Azure udostępnia klasy, które obsługują uwierzytelnianie oparte na tokenach i umożliwiają aplikacjom uwierzytelnianie w zasobach Azure niezależnie od tego, czy aplikacja działa lokalnie, na Azure, czy na serwerze lokalnym.
Zalety uwierzytelniania opartego na tokenach
Uwierzytelnianie oparte na tokenach oferuje następujące zalety w porównaniu z ciągami połączenia.
- Uwierzytelnianie oparte na tokenach zapewnia, że tylko określone aplikacje przeznaczone do uzyskiwania dostępu do zasobu Azure mogą to zrobić, natomiast każda osoba lub dowolna aplikacja z connection string może łączyć się z zasobem Azure.
- Uwierzytelnianie oparte na tokenach umożliwia dalsze ograniczenie dostępu Azure zasobów tylko do określonych uprawnień wymaganych przez aplikację. Jest to zgodne z regułą najniższych uprawnień. Natomiast connection string przyznaje pełne prawa do zasobu Azure.
- W przypadku korzystania z managed identity do uwierzytelniania opartego na tokenach, Azure obsługuje funkcje administracyjne za Ciebie, więc nie musisz martwić się o takie zadania jak zabezpieczanie lub rotacja tajemnic. Dzięki temu aplikacja jest bezpieczniejsza, ponieważ nie ma łańcucha połączenia ani sekretu aplikacji, które mogłyby zostać naruszone.
- Biblioteka Azure Identity uzyskuje tokeny Microsoft Entra i zarządza nimi.
Użycie parametrów połączenia powinno być ograniczone do scenariuszy, w których uwierzytelnianie oparte na tokenach nie jest opcją, początkowymi aplikacjami weryfikacji koncepcji ani prototypami deweloperskimi, które nie uzyskują dostępu do danych produkcyjnych ani poufnych. Jeśli to możliwe, użyj klas uwierzytelniania opartych na tokenach dostępnych w bibliotece tożsamości Azure, aby uwierzytelnić się w zasobach Azure.
Uwierzytelnianie w różnych środowiskach
Określony typ uwierzytelniania opartego na tokenach, którego aplikacja powinna używać do uwierzytelniania się do zasobów Azure, zależy od tego, gdzie działa aplikacja. Poniższy diagram zawiera wskazówki dotyczące różnych scenariuszy i środowisk:
Gdy aplikacja jest:
- Hosted na Azure: aplikacja powinna uwierzytelniać się do zasobów Azure przy użyciu tożsamości zarządzanej. Ta opcja została omówiona bardziej szczegółowo w uwierzytelnianiu w środowiskach serwerowych.
- Uruchamianie lokalne podczas rozwoju: aplikacja może uwierzytelniać się w Azure przy użyciu konta programisty, brokera lub głównej usługi. Każda opcja została omówiona bardziej szczegółowo w sekcji uwierzytelniania podczas rozwoju lokalnego.
- Hosted lokalnie: aplikacja powinna uwierzytelniać się do zasobów Azure przy użyciu jednostki usługi aplikacji lub tożsamości zarządzanej w przypadku Azure Arc. Lokalne przepływy pracy zostały szczegółowo omówione w Uwierzytelnianie dla aplikacji hostowanych lokalnie.
Uwierzytelnianie dla aplikacji hostowanych Azure
Gdy aplikacja jest hostowana w Azure, może używać tożsamości zarządzanych do uwierzytelniania do zasobów Azure, bez konieczności zarządzania jakimikolwiek poświadczeniami. Istnieją dwa typy tożsamości zarządzanych: przypisane przez użytkownika i przypisane przez system.
Używanie tożsamości zarządzanej przypisanej przez użytkownika
Tożsamość zarządzana przypisana przez użytkownika jest tworzona jako autonomiczny zasób Azure. Można go przypisać do jednego lub więcej zasobów Azure, umożliwiając tym zasobom wspólne korzystanie z tej samej tożsamości i uprawnień. Aby uwierzytelnić się przy użyciu tożsamości zarządzanej przypisanej przez użytkownika, utwórz tożsamość, przypisz ją do zasobu Azure, a następnie skonfiguruj aplikację do użycia tej tożsamości na potrzeby uwierzytelniania, określając identyfikator klienta, identyfikator zasobu lub identyfikator obiektu.
Korzystanie z tożsamości zarządzanej przypisanej przez system
Systemowo przypisana tożsamość zarządzana jest włączana bezpośrednio w zasobie platformy Azure. Tożsamość jest powiązana z cyklem życia tego zasobu i jest automatycznie usuwana po usunięciu zasobu. Aby uwierzytelnić się przy użyciu tożsamości zarządzanej przypisanej przez system, włącz tożsamość w zasobie Azure, a następnie skonfiguruj aplikację tak, aby korzystała z tej tożsamości na potrzeby uwierzytelniania.
Uwierzytelnianie podczas programowania lokalnego
Podczas lokalnego tworzenia oprogramowania można uwierzytelnić się do zasobów Azure przy użyciu poświadczeń dewelopera lub głównego użytkownika usługi. Dzięki temu można przetestować logikę uwierzytelniania aplikacji bez wdrażania jej w Azure.
Używanie poświadczeń programisty
Możesz użyć własnych poświadczeń Azure do uwierzytelniania do zasobów Azure podczas lokalnego programowania. Zazwyczaj odbywa się to przy użyciu narzędzia programistycznego, takiego jak Azure CLI lub Visual Studio Code, które może zapewnić aplikacji tokeny niezbędne do uzyskiwania dostępu do usług Azure. Ta metoda jest wygodna, ale powinna być używana tylko do celów programistycznych.
Korzystanie z brokera
Uwierzytelnianie obsługiwane przez brokera zbiera poświadczenia użytkownika przy użyciu brokera uwierzytelniania systemu w celu uwierzytelnienia aplikacji. Broker uwierzytelniania systemu działa na komputerze użytkownika i zarządza procesami uwierzytelniania oraz utrzymaniem tokenów dla wszystkich połączonych kont.
Użycie głównego elementu usługi
Tworzy się service principal w dzierżawie Microsoft Entra, aby reprezentować aplikację i służyć do uwierzytelniania dostępu do zasobów Azure. Aplikację można skonfigurować tak, aby korzystała z poświadczeń jednostki usługi podczas programowania lokalnego. Ta metoda jest bezpieczniejsza niż używanie poświadczeń dewelopera i jest bliżej sposobu uwierzytelniania aplikacji w środowisku produkcyjnym. Jednak nadal jest to mniej idealne rozwiązanie niż używanie tożsamości zarządzanej ze względu na potrzebę obsługi tajemnic.
Uwierzytelnianie dla aplikacji hostowanych lokalnie
W przypadku aplikacji hostowanych lokalnie można użyć zasady usługi do uwierzytelniania do zasobów Azure. Obejmuje to utworzenie jednostki usługi w Microsoft Entra ID, przypisanie jej niezbędnych uprawnień i skonfigurowanie aplikacji do korzystania z jej poświadczeń. Ta metoda umożliwia aplikacji lokalnej bezpieczny dostęp do usług Azure.