Metody uwierzytelniania obsługiwane przez usługę Azure OpenAI
Usługa Azure OpenAI obsługuje kilka metod uwierzytelniania w celu zapewnienia bezpiecznego i kontrolowanego dostępu do zasobów. Podstawowe metody to:
- Klucze interfejsu API: usługa Azure OpenAI obsługuje również uwierzytelnianie oparte na kluczach interfejsu API. Klucze interfejsu API są generowane w witrynie Azure Portal i mogą służyć do uwierzytelniania żądań w usłudze Azure OpenAI. Ta metoda uwierzytelniania nie jest zalecana z punktu widzenia zabezpieczeń i powinna być używana tylko w ostateczności. Jeśli musisz użyć tej metody uwierzytelniania, ważne jest, aby bezpiecznie obsługiwać klucze interfejsu API i okresowo obracać je w celu zmniejszenia ryzyka nieautoryzowanego dostępu.
- Microsoft Entra ID: Ta metoda wykorzystuje niezawodne funkcje zarządzania tożsamościami i dostępem firmy Microsoft Entra. Użytkownicy i aplikacje uwierzytelniają się przy użyciu tożsamości firmy Microsoft Entra, które mogą być tradycyjnymi kontami użytkowników lub tożsamościami zarządzanymi. Ta metoda zapewnia, że tylko uwierzytelnieni i autoryzowani użytkownicy mogą uzyskiwać dostęp do zasobów usługi Azure OpenAI.
- EntraManaged Identities: Tożsamości zarządzane dla zasobów platformy Azure zapewniają automatyczną tożsamość zarządzaną w usłudze Microsoft Entra dla aplikacji do użycia podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra. Te tożsamości mogą być przypisane przez system, co oznacza, że są one powiązane z określonym zasobem platformy Azure lub przypisanym przez użytkownika, co umożliwia współużytkowanie jednej tożsamości w wielu zasobach. Tożsamości zarządzane upraszczają zarządzanie poświadczeniami i zwiększają bezpieczeństwo, eliminując potrzebę zakodowanych poświadczeń w kodzie aplikacji.
Dlaczego tożsamości zarządzane są bezpieczniejsze niż klucze interfejsu API
Tożsamości zarządzane na platformie Microsoft Azure oferują bezpieczniejszą alternatywę dla kluczy interfejsu API z kilku powodów:
- Tożsamości zarządzane eliminują potrzebę bezpośredniego obsługi poświadczeń przez deweloperów, co zmniejsza ryzyko przypadkowego ujawnienia lub nieprawidłowego użycia.
- W przypadku korzystania z kluczy interfejsu API deweloperzy muszą osadzić te klucze w kodzie aplikacji lub plikach konfiguracji.
Klucze interfejsu API można przypadkowo uwidocznić za pośrednictwem repozytoriów kodu źródłowego, dzienników lub innych środków. Ta ekspozycja może prowadzić do nieautoryzowanego dostępu i potencjalnych naruszeń zabezpieczeń. Z kolei tożsamości zarządzane zapewniają automatycznie zarządzaną tożsamość dla aplikacji do użycia podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra (wcześniej Azure AD). Oznacza to, że poświadczenia nie są przechowywane w kodzie aplikacji, co zmniejsza ryzyko wycieków i nieautoryzowanego dostępu.
Ponadto tożsamości zarządzane usprawniają proces uwierzytelniania, umożliwiając usługom platformy Azure bezpieczne uwierzytelnianie w innych usługach platformy Azure bez konieczności używania jawnych poświadczeń. Jest to osiągane przy użyciu tokenów wystawionych przez firmę Microsoft Entra, które są automatycznie zarządzane i obracane, zapewniając, że poświadczenia są zawsze aktualne i zmniejszają ryzyko kradzieży poświadczeń. Z drugiej strony klucze interfejsu API są statyczne i wymagają ręcznego obracania, które mogą być podatne na błędy i często zaniedbywane, co prowadzi do potencjalnych luk w zabezpieczeniach. Korzystając z tożsamości zarządzanych, deweloperzy mogą korzystać z wbudowanych funkcji zabezpieczeń platformy Azure, takich jak kontrola dostępu oparta na rolach (RBAC), aby udzielić precyzyjnych uprawnień do zasobów, co dodatkowo zwiększa bezpieczeństwo.
Firma Microsoft zaleca używanie tożsamości zarządzanej za pośrednictwem kluczy interfejsu API podczas uwierzytelniania w usłudze Azure OpenAI lub dowolnej innej usługi platformy Azure obsługującej tożsamość zarządzaną.
Różnice między używaniem kluczy interfejsu API a tożsamościami zarządzanymi w usłudze Azure OpenAI
Oceńmy wpływ wycieku identyfikatora klienta w porównaniu z ujawnionym kluczem interfejsu API.
Klucz interfejsu API działa podobnie jak zwykłe hasło. W przypadku naruszenia zabezpieczeń każda osoba mająca klucz może uzyskać dostęp do zasobu. W przypadku usługi Azure OpenAI oznacza to nieograniczone użycie modeli sztucznej inteligencji, takich jak GPT-4. Jeśli sieć jest publicznie dostępna, wpływ na zabezpieczenia może być jeszcze większy.
Z drugiej strony, jeśli identyfikator klienta zostanie ujawniony, ryzyko jest minimalne. Dzieje się tak, ponieważ sam identyfikator klienta nie może nawiązać połączenia z usługą Azure OpenAI. Aby korzystać z tożsamości zarządzanej, usługa musi działać na platformie Azure, a nawet jeśli usługa Azure OpenAI jest publiczna, nie można nawiązać połączenia ze środowiska lokalnego ani z sieci przy użyciu aplikacji.
Podsumowując, w porównaniu z konsekwencjami wycieku klucza interfejsu API, wykorzystanie ujawnionego identyfikatora klienta obejmuje kilka kroków, co utrudnia złośliwym podmiotom wykorzystanie.
Z tych powodów tożsamości zarządzane oferują bezpieczniejszą metodę zarządzania operacjami w porównaniu z kluczami interfejsu API. Zaleca się używanie tożsamości zarządzanej za pośrednictwem kluczy interfejsu API w przypadku uwierzytelniania w usłudze Azure OpenAI lub dowolnej innej usługi platformy Azure obsługującej tożsamość zarządzaną.
Tożsamości przypisane przez system a użytkownika
Podczas tworzenia aplikacji Azure OpenAI zrozumienie różnic między tożsamościami przypisanymi przez system i przypisanymi przez użytkownika ma kluczowe znaczenie dla optymalnego zarządzania zabezpieczeniami i zasobami.
- Tożsamości przypisane przez system są tworzone i zarządzane przez platformę Azure dla określonego zasobu. Po usunięciu zasobu skojarzona z nim tożsamość przypisana przez system jest również usuwana, zapewniając, że cykl życia tożsamości jest ściśle powiązany z zasobem, do którego należy. Ten typ tożsamości jest idealny w scenariuszach, w których tożsamość musi być używana tylko przez jeden zasób, zapewniając prostotę i zmniejszenie obciążenia administracyjnego, ponieważ platforma Azure zarządza poświadczeniami tożsamości.
- Tożsamości przypisane przez użytkownika są tworzone niezależnie od dowolnego określonego zasobu i mogą być współużytkowane przez wiele zasobów. Dzięki temu są one wysoce uniwersalne w przypadku aplikacji wymagających spójnej tożsamości w różnych zasobach, co ułatwia zarządzanie uprawnieniami i kontrolami dostępu. Tożsamości przypisane przez użytkownika są utrwalane nawet po usunięciu zasobów, co zapewnia większą elastyczność ponownego wdrażania i ponownego używania tożsamości.
Wybór między tożsamościami przypisanymi przez system i przypisanymi przez użytkownika zależy od konkretnych potrzeb aplikacji. W przypadku aplikacji z jednym zasobem, w których prostota i minimalne zarządzanie są priorytetami, tożsamości przypisane przez system są zazwyczaj najlepszym wyborem. Z drugiej strony w przypadku aplikacji, które wymagają tożsamości udostępnionej w wielu zasobach, tożsamości przypisane przez użytkownika zapewniają większą elastyczność i możliwość ponownego użycia.
