Podawanie poświadczeń tożsamości aplikacji, gdy nie ma użytkownika
Gdy jako deweloper tworzysz aplikacje inne niż użytkownicy, nie masz użytkownika, którego możesz wyświetlić monit o podanie nazwy użytkownika i hasła lub uwierzytelniania wieloskładnikowego (MFA). Musisz podać tożsamość aplikacji samodzielnie. W tym artykule wyjaśniono, dlaczego najlepszym rozwiązaniem Zero Trust poświadczeń klienta dla usług (aplikacji innych niż użytkownicy) na platformie Azure są tożsamości zarządzane dla zasobów platformy Azure.
Problemy z kontami usług
Użycie "konta usługi", w którym tworzysz konto użytkownika i używasz go dla usługi, nie jest dobrym rozwiązaniem, ponieważ usługa Azure Active Directory (Azure AD) nie ma pojęcia konta usługi. Gdy administratorzy tworzą konto użytkownika dla usługi, a następnie udostępniają hasło deweloperowi, jest ono niezabezpieczone, ponieważ nie może być bez hasła ani mieć uwierzytelniania wieloskładnikowego. Zamiast używać konta użytkownika jako konta usługi, najlepszym rozwiązaniem jest użycie jednej z opcji poświadczeń klienta opisanych poniżej.
Opcje poświadczeń klienta
Istnieją cztery typy poświadczeń klienta, które mogą identyfikować aplikację.
- Klucz tajny
- Certyfikat
- Tożsamość zarządzana dla platformy Azure
- Poświadczenia federacyjne
Klucz tajny lub certyfikat?
Klucze tajne są dopuszczalne, gdy masz zaawansowaną infrastrukturę zarządzania wpisami tajnymi w przedsiębiorstwie. Jednak klucze tajne w scenariuszach, w których specjalista IT generuje klucz tajny, a następnie wiadomości e-mail do dewelopera, który następnie może przechowywać go w niezabezpieczonej lokalizacji, takiej jak arkusz kalkulacyjny, powoduje, że klucze tajne nie będą prawidłowo chronione.
Poświadczenia klienta oparte na certyfikatach są bezpieczniejsze niż klucze tajne. Certyfikaty są lepiej zarządzane, ponieważ nie są same wpisów tajnych. Wpis tajny nie jest częścią transmisji. Gdy używasz klucza tajnego, klient wysyła rzeczywistą wartość klucza tajnego do Azure AD. W przypadku korzystania z certyfikatu klucz prywatny certyfikatu nigdy nie opuszcza urządzenia. Nawet jeśli ktoś przechwytuje, dekoduje i deszyfrowania transmisji, wpis tajny jest nadal bezpieczny, ponieważ strona przechwytujący nie ma klucza prywatnego.
Najlepsze rozwiązanie: używanie tożsamości zarządzanych dla zasobów platformy Azure
Podczas tworzenia usług (aplikacji innych niż użytkownicy) na platformie Azure tożsamości zarządzane dla zasobów platformy Azure zapewniają automatyczną tożsamość zarządzaną w Azure AD. Aplikacja może uwierzytelniać się w dowolnej usłudze obsługującej uwierzytelnianie Azure AD bez zarządzania poświadczeniami. Nie musisz zarządzać wpisami tajnymi; Nie musisz rozwiązywać problemów z możliwością ich utraty lub błędnej obsługi. Nie można przechwycić wpisów tajnych, ponieważ nie są przenoszone przez sieć. Tożsamości zarządzane dla zasobów platformy Azure to najlepsze rozwiązanie w przypadku tworzenia usług na platformie Azure.
Następne kroki
- Obsługa usług platformy Azure z tożsamościami zarządzanymi — Azure AD — Microsoft Entra | Microsoft Docs udostępnia linki do zawartości usług, które mogą używać tożsamości zarządzanych do uzyskiwania dostępu do innych zasobów platformy Azure. Każdy wpis w tabeli zawiera link do dokumentacji usługi omawiający tożsamości zarządzane.
- Dostawcy zasobów według usług platformy Azure — Azure Resource Manager | Microsoft Docs pokazuje sposób mapowania przestrzeni nazw dostawcy zasobów na usługi platformy Azure.
- Publiczne i poufne aplikacje klienckie (MSAL) — Microsoft Entra | Microsoft Docs opisuje, w jaki sposób dwa typy klientów mogą bezpiecznie uwierzytelniać się za pomocą serwera autoryzacji i zachować poufność poświadczeń klienta.
- Federacja tożsamości obciążenia — Microsoft Entra | Microsoft Docs zawiera omówienie federacji tożsamości obciążenia dla obciążeń oprogramowania w celu uzyskiwania dostępu do chronionych zasobów usługi Azure Active Directory (Azure AD) bez konieczności zarządzania wpisami tajnymi (w przypadku obsługiwanych scenariuszy).