Inteligentne aplikacje korzystające z usługi Azure OpenAI Service za pośrednictwem usług natywnych dla platformy Azure zapewniają bezproblemowe uwierzytelnianie i autoryzację użytkownika. Jednak niektóre scenariusze są złożone i wymagają różnych projektów architektury. Te scenariusze obejmują topologie, które mają aplikacje klienckie, które nie są hostowane na platformie Azure, korzystają z zewnętrznych dostawców tożsamości i wdrażają wielu klientów, którzy uzyskują dostęp do tych samych wystąpień usługi Azure OpenAI. W tych scenariuszach wprowadzenie bramy przed usługą Azure OpenAI może znacznie zwiększyć bezpieczeństwo, dodając warstwę zapewniającą spójne uwierzytelnianie do wdrożonych wystąpień.
W tym artykule opisano kluczowe scenariusze, które zapewniają uwierzytelnianie w usłudze Azure OpenAI:
Uwierzytelnianie aplikacji klienckich za pośrednictwem zewnętrznego dostawcy tożsamości
Uwierzytelnianie aplikacji klienckich za pomocą certyfikatów
Uwierzytelnianie aplikacji klienckich, które uzyskują dostęp do wielu wystąpień usługi Azure OpenAI
W każdym scenariuszu opisano wyzwania, które wprowadzają, oraz korzyści wynikające z włączenia bramy.
Ważne
Możesz użyć poniższych wskazówek dotyczących dowolnej implementacji bramy, w tym usługi Azure API Management. Aby zilustrować tę elastyczność, diagramy architektury używają ogólnych reprezentacji składników w większości scenariuszy.
Uwierzytelnianie aplikacji klienckich za pośrednictwem zewnętrznego dostawcy tożsamości
Pobierz plik programu Visio z tą architekturą.
Ograniczenia scenariusza
Ten scenariusz ma następujące ograniczenia:
Aplikacje klienckie używają zewnętrznego dostawcy tożsamości z obsługą protokołu OpenID Connect (OIDC), takiego jak Okta, Auth0 lub dostawcy tożsamości społecznościowych.
Aplikacje klienckie uwierzytelniają się w dzierżawie firmy Microsoft Entra, która różni się od dzierżawy płaszczyzny danych usługi Azure OpenAI.
Te ograniczenia mogą mieć zastosowanie do następujących przykładów:
Istniejące aplikacje klienckie, które już uwierzytelniają się względem zewnętrznego dostawcy OIDC lub identyfikatora Entra firmy Microsoft i które integrują się z wystąpieniami usługi Azure OpenAI.
Aplikacje klienckie, które muszą spójnie uwierzytelniać użytkowników od wielu dostawców tożsamości.
Nawiązywanie połączenia bezpośrednio z usługą Azure OpenAI
Jeśli aplikacje klienckie w tych scenariuszach łączą się bezpośrednio z usługą Azure OpenAI bez korzystania z bramy, muszą używać uwierzytelniania opartego na kluczach do uwierzytelniania w usłudze Azure OpenAI. Uwierzytelnianie oparte na kluczach wprowadza dodatkowe obawy dotyczące zabezpieczeń. Należy bezpiecznie przechowywać i obracać klucze, a nie można nadawać różnym klientom konfiguracji kontroli dostępu opartej na rolach (RBAC) dla poszczególnych wdrożeń modelu.
Wprowadzenie do bramy
Pobierz plik programu Visio z tą architekturą.
Brama rozwiązuje problemy związane z tym scenariuszem w następujący sposób:
Brama używa protokołu OAuth (Open Authorization) do uwierzytelniania użytkowników za pośrednictwem istniejących zewnętrznych dostawców tożsamości. Brama weryfikuje uwierzytelnione tokeny dostępu użytkownika, takie jak token internetowy JSON (JWT), które generuje dostawca tożsamości. Następnie brama udziela autoryzacji dla wystąpienia usługi Azure OpenAI kopii zapasowej.
Nie musisz zarządzać kluczami klienta. Takie podejście eliminuje zagrożenia bezpieczeństwa związane z uwierzytelnianiem opartym na kluczach.
Brama łączy się z usługą Azure OpenAI przy użyciu tożsamości zarządzanej, co zwiększa bezpieczeństwo za pośrednictwem kontroli dostępu opartej na rolach platformy Azure z najniższymi uprawnieniami.
Zalecenia dotyczące tego scenariusza
Dodaj więcej zakresów OAuth do rejestracji aplikacji u dostawcy tożsamości, aby umożliwić użytkownikom szczegółowe uprawnienia. Te zakresy umożliwiają aplikacjom klienckim żądanie uprawnień do wykonywania określonych operacji w bramie, w tym dostępu do usługi Azure OpenAI.
Skonfiguruj ten scenariusz dla usługi API Management przy użyciu zasad ruchu przychodzącego. Użyj zasad
validate-jwtaby wymusić istnienie, ważność i wartości atrybutów obsługiwanego zestawu JWT.
Przyczyny uniknięcia bramy w tym scenariuszu
Jeśli jedna inteligentna aplikacja uzyskuje dostęp do usługi Azure OpenAI, łatwiej jest skonfigurować uwierzytelnianie i autoryzację użytkownika w aplikacji, a nie za pośrednictwem bramy. Użyj tego podejścia, aby przypisać niezbędną kontrolę dostępu opartą na rolach platformy Azure w celu bezpiecznego uwierzytelniania inteligentnej aplikacji za pomocą usługi Azure OpenAI.
Uwierzytelnianie aplikacji klienckich za pomocą certyfikatów
Pobierz plik programu Visio z tą architekturą.
Ograniczenia scenariusza
Ten scenariusz ma następujące ograniczenia:
Chcesz użyć certyfikatów do uwierzytelniania aplikacji klienckich.
Aplikacje klienckie nie mogą używać ani nie chcesz używać identyfikatora Entra firmy Microsoft ani innych dostawców OIDC na potrzeby uwierzytelniania.
Klienci nie mogą używać tożsamości federacyjnej do uwierzytelniania lub nie chcesz ich używać.
Te ograniczenia mogą mieć zastosowanie do następujących przykładów:
Klient, który uwierzytelnia się w usłudze Azure OpenAI, jest maszyną lub urządzeniem i nie ma interakcji z użytkownikiem.
Twoja organizacja wymaga używania certyfikatów do uwierzytelniania ze względu na standardy zabezpieczeń i przepisy dotyczące zgodności.
Chcesz udostępnić wiele aplikacji klienckich z opcjami uwierzytelniania na podstawie ich środowiska, w tym przy użyciu certyfikatów klienta.
Nawiązywanie połączenia bezpośrednio z usługą Azure OpenAI
Usługa Azure OpenAI nie obsługuje natywnie uwierzytelniania certyfikatu klienta. Aby obsługiwać ten scenariusz bez bramy, inteligentna aplikacja musi używać uwierzytelniania certyfikatu dla użytkownika i klucza interfejsu API lub tożsamości zarządzanej w celu uwierzytelniania żądań w wystąpieniu usługi Azure OpenAI. Należy zaimplementować logikę uwierzytelniania certyfikatu na każdym kliencie. W tym scenariuszu uwierzytelnianie oparte na kluczach wprowadza ryzyko i obciążenie związane z zarządzaniem, jeśli łączysz się bezpośrednio z usługą Azure OpenAI od klientów.
Wprowadzenie do bramy
Pobierz plik programu Visio z tą architekturą.
Bramę można wprowadzić do tej architektury, która odciąża walidację certyfikacji klienta od klientów. Brama weryfikuje certyfikat cyfrowy klienta, który przedstawia inteligentna aplikacja i sprawdza wystawcę, datę wygaśnięcia, odcisk palca i listy odwołania. Brama powinna używać tożsamości zarządzanej do uwierzytelniania się za pomocą usługi Azure OpenAI. Brama powinna również używać usługi Azure Key Vault do przechowywania głównego urzędu certyfikacji. Użyj tego podejścia, aby scentralizować weryfikację certyfikatu klienta, co zmniejsza nakład pracy związany z konserwacją.
Brama zapewnia kilka zalet w tym scenariuszu:
Używasz tożsamości zarządzanej bramy zamiast kluczy dostępu, co eliminuje ryzyko skradzione klucze i zmniejsza obciążenie konserwacją rotacji kluczy.
Weryfikację certyfikatów można centralizować, co gwarantuje, że używasz spójnych zasad zabezpieczeń do oceny certyfikatów cyfrowych klienta dla wszystkich inteligentnych aplikacji.
Walidację certyfikatu można odciążyć do bramy, co upraszcza kod klienta.
Zalecenia dotyczące tego scenariusza
Sprawdź cały łańcuch certyfikatów, w tym główny urząd certyfikacji i certyfikaty pośrednie, podczas weryfikowania certyfikatów. Pełna weryfikacja zapewnia autentyczność certyfikatu i uniemożliwia nieautoryzowany dostęp.
Regularnie wymieniaj i odnawiaj certyfikaty klienta, aby zminimalizować ryzyko naruszenia certyfikatu. Użyj usługi Key Vault, aby zautomatyzować ten proces i aktualizować certyfikaty. Ustaw alerty dotyczące nadchodzących wygasań certyfikatów, aby zapobiec przerwom w działaniu usługi w bramie.
Zaimplementuj wzajemne zabezpieczenia warstwy transportu (mTLS), aby upewnić się, że zarówno klient, jak i serwer uwierzytelniają się nawzajem. Ta strategia zapewnia dodatkową warstwę zabezpieczeń. Aby skonfigurować bramę w celu wymuszania biblioteki mTLS, ustaw odpowiednie zasady i ograniczenia.
Użyj zasad
validate-client-certificateAPI Management, aby zweryfikować certyfikaty klienta, do których odwołuje się magazyn kluczy platformy Azure. Te zasady weryfikują certyfikat klienta, który aplikacja kliencka przedstawia i sprawdza wystawcę, datę wygaśnięcia, odcisk palca i listy odwołania.
Przyczyny uniknięcia bramy w tym scenariuszu
W prostych środowiskach, które mają kilku klientów, koszt obsługi zabezpieczeń i zarządzania certyfikatami w kliencie może przewyższać dodatkową złożoność wprowadzania bramy. Ponadto bramy mogą stać się pojedynczymi punktami awarii, zwiększyć opóźnienie z powodu dodanych warstw i prowadzić do blokady dostawcy, jeśli wybierzesz rozwiązania komercyjne, a nie niestandardowe implementacje.
Przed wdrożeniem bramy na potrzeby uwierzytelniania certyfikatu klienta należy dokładnie ocenić określone potrzeby, dostępność zasobów i krytyczność aplikacji.
Uwierzytelnianie wielu aplikacji klienckich za pomocą kluczy w celu uzyskania dostępu do udostępnionego wystąpienia usługi Azure OpenAI
Pobierz plik programu Visio z tą architekturą.
Ograniczenia scenariusza
Ten scenariusz ma następujące ograniczenia:
- Wiele aplikacji klienckich uzyskuje dostęp do udostępnionego wystąpienia usługi Azure OpenAI.
- Klienci nie mogą używać ani nie chcesz używać identyfikatora Entra firmy Microsoft do uwierzytelniania.
- Klienci nie mogą używać tożsamości federacyjnej do uwierzytelniania lub nie chcesz ich używać.
- Chcesz użyć uwierzytelniania opartego na kluczach dla aplikacji klienckich.
Te ograniczenia mogą mieć zastosowanie do następujących przykładów:
Aplikacje klienckie są wdrażane w wielu środowiskach, w tym na platformie Azure, lokalnie lub u innych dostawców usług w chmurze.
Organizacja musi zapewnić usługę Azure OpenAI różnym zespołom i ustawić unikatowe limity dostępu i użycia dla każdego zespołu.
Nawiązywanie połączenia bezpośrednio z usługą Azure OpenAI
Usługa Azure OpenAI obsługuje uwierzytelnianie oparte na kluczach za pośrednictwem kluczy udostępnionych. Usługa Azure OpenAI uwidacznia klucz podstawowy i klucz pomocniczy. Celem klucza pomocniczego jest obsługa rotacji kluczy. Nie zapewnia izolacji tożsamości klienta. W przypadku uwierzytelniania wielu klientów bezpośrednio w usłudze Azure OpenAI w tym scenariuszu każdy klient ma ten sam klucz. Ta implementacja ma następujące wyzwania:
Nie można odwołać uprawnień dla określonych klientów, ponieważ każdy klient współudzieli ten sam klucz.
Nie można nadać różnym klientom różnych praw dostępu do różnych modeli w tym samym wdrożeniu wystąpienia usługi Azure OpenAI.
Nie można odróżnić jednego klienta od innego od perspektywy rejestrowania.
Wprowadzenie do bramy
Pobierz plik programu Visio z tą architekturą.
Bramę można wprowadzić do tej architektury, która wystawia dedykowany klucz dla każdej aplikacji klienckiej. Usługa API Management używa koncepcji subskrypcji do udostępniania dedykowanych kluczy klienta. Brama powinna używać tożsamości zarządzanej do uwierzytelniania się za pomocą usługi Azure OpenAI.
Brama zapewnia kilka zalet w tym scenariuszu:
Dostęp do pojedynczej aplikacji klienckiej można odwołać bez wpływu na innych klientów.
Nie musisz aktualizować wszystkich konfiguracji kluczy klienta przed wymianą kluczy, więc rotacja kluczy jest łatwiejsza logistycznie. Po zaktualizowaniu konfiguracji klienta można obrócić dedykowane klucze dla każdego klienta.
Można jednoznacznie zidentyfikować każdego klienta z perspektywy rejestrowania.
Brama wymusza limity szybkości i limity przydziału dla każdego klienta niezależnie.
Zalecenia dotyczące tego scenariusza
Ulepszanie monitorowania metryk związanych z żądaniami interfejsu API. W przypadku korzystania z tożsamości zarządzanej z bramy śledzenie użytkownika i aplikacji klienckiej w dziennikach usługi Azure OpenAI nie poprawia się. Brama powinna zapewnić rejestrowanie skojarzone z żądaniem, takie jak identyfikatory klienta żądającego i identyfikatory użytkownika.
Upewnij się, że brama podejmuje decyzje dotyczące routingu do odpowiednich wdrożeń modelu na podstawie tożsamości klienta podczas kierowania wielu żądań aplikacji klienckich za pośrednictwem bramy do udostępnionego wystąpienia usługi Azure OpenAI. Aby uzyskać więcej informacji, zobacz Używanie bramy przed wieloma wdrożeniami usługi Azure OpenAI.
Uwierzytelnianie aplikacji klienckich, które uzyskują dostęp do wielu wystąpień usługi Azure OpenAI
Pobierz plik programu Visio z tą architekturą.
Ograniczenia scenariusza
Ten scenariusz ma następujące ograniczenia:
- Aplikacje klienckie łączą się z wieloma wystąpieniami usługi Azure OpenAI w co najmniej jednym regionie.
- Klienci nie mogą używać ani nie chcesz używać identyfikatora Entra firmy Microsoft ani innych dostawców OIDC do uwierzytelniania.
- Chcesz użyć uwierzytelniania opartego na kluczach dla aplikacji klienckich.
Te ograniczenia mogą mieć zastosowanie do następujących przykładów:
Aplikacje klienckie muszą dystrybuować obciążenia geograficznie, aby zmniejszyć opóźnienia i zwiększyć wydajność.
Aplikacje klienckie próbują zoptymalizować przydziały tokenów na minutę, wdrażając wystąpienia w wielu regionach.
Aby zapewnić ciągłą pracę, organizacja wymaga bezproblemowego przejścia w tryb failover i odzyskiwania po awarii. W związku z tym zarządzają strategią podwójnego wdrażania, taką jak strategia składająca się z wdrożenia aprowizowanej przepływności i wdrożenia płatności zgodnie z rzeczywistym użyciem.
Aplikacje klienckie muszą używać określonych możliwości modelu, które są dostępne tylko w niektórych regionach świadczenia usługi Azure.
Łączenie się bezpośrednio z wieloma wystąpieniami usługi Azure OpenAI
Gdy aplikacje klienckie łączą się bezpośrednio z wieloma wystąpieniami usługi Azure OpenAI, każdy klient musi przechowywać klucz dla każdego wystąpienia. Oprócz zagadnień dotyczących zabezpieczeń związanych z używaniem kluczy zwiększa się obciążenie związane z zarządzaniem w zakresie rotacji kluczy.
Wprowadzenie do bramy
Pobierz plik programu Visio z tą architekturą.
Jeśli używasz bramy do obsługi aplikacji klienckich, które uzyskują dostęp do wielu wdrożeń usługi Azure OpenAI, uzyskasz te same korzyści co brama, która obsługuje wiele aplikacji klienckich za pośrednictwem kluczy w celu uzyskania dostępu do udostępnionego wystąpienia usługi Azure OpenAI. Usprawnisz również proces uwierzytelniania, ponieważ używasz jednej tożsamości zarządzanej zdefiniowanej przez użytkownika do uwierzytelniania żądań z bramy do wielu wystąpień usługi Azure OpenAI. Zaimplementuj to podejście, aby zmniejszyć ogólne nakłady pracy operacyjnej i zminimalizować ryzyko błędnej konfiguracji klienta podczas pracy z wieloma wystąpieniami.
Przykładem użycia bramy na platformie Azure do odciążania tożsamości do pośrednika jest zasób usług Azure AI Services. W tej implementacji uwierzytelniasz się w bramie, a brama obsługuje uwierzytelnianie w różnych usługach sztucznej inteligencji platformy Azure, takich jak Custom Vision lub Speech. Chociaż ta implementacja jest podobna, nie dotyczy tego scenariusza.
Zalecenia dotyczące tego scenariusza
Zaimplementuj techniki równoważenia obciążenia, aby dystrybuować żądania interfejsu API między wiele wystąpień usługi Azure OpenAI w celu obsługi dużego ruchu i zapewnienia wysokiej dostępności. Aby uzyskać więcej informacji, zobacz Używanie bramy przed wieloma wdrożeniami lub wystąpieniami usługi Azure OpenAI.
Korelowanie użycia tokenu dla każdej dzierżawy w bramie podczas implementowania scenariuszy wielodostępnych z wieloma wystąpieniami usługi Azure OpenAI. Takie podejście zapewnia śledzenie całkowitego użycia tokenu, niezależnie od wystąpienia zaplecza usługi Azure OpenAI, do którego jest przekazywane żądanie.
Zalecenia ogólne
Podczas integrowania usługi Azure OpenAI za pośrednictwem bramy istnieje kilka rekomendacji obejmujących krzyżowe, które należy wziąć pod uwagę we wszystkich scenariuszach.
Użyj usługi Azure API Management zamiast tworzyć własne rozwiązanie w celu wydajnej aranżacji interfejsu API, bezproblemowej integracji z innymi usługami platformy Azure i oszczędności kosztów dzięki zmniejszeniu nakładu pracy związanych z programowaniem i konserwacją. Usługa API Management zapewnia bezpieczne zarządzanie interfejsem API, bezpośrednio obsługując uwierzytelnianie i autoryzację. Integruje się z dostawcami tożsamości, takimi jak Microsoft Entra ID, który umożliwia uwierzytelnianie OAuth 2.0 i zapewnia autoryzację opartą na zasadach. Ponadto usługa API Management używa tożsamości zarządzanych do bezpiecznego i niskiego poziomu dostępu do usługi Azure OpenAI.
Łączenie scenariuszy dla kompleksowego rozwiązania bramy
W rzeczywistych aplikacjach przypadki użycia mogą obejmować wiele scenariuszy z tego artykułu. Na przykład mogą istnieć aplikacje klienckie, które uwierzytelniają się za pośrednictwem zewnętrznego dostawcy tożsamości i wymagają dostępu do wielu wystąpień usługi Azure OpenAI.
Pobierz plik programu Visio z tą architekturą.
Aby utworzyć bramę, która spełnia określone wymagania, połącz zalecenia z tych scenariuszy w celu uzyskania kompleksowego podejścia.
Wymuszanie zasad bramy
Zanim brama wysyła żądania do wystąpień usługi Azure OpenAI, upewnij się, że wymuszasz zasady uwierzytelniania przychodzącego i autoryzacji. Aby upewnić się, że brama przekazuje tylko uwierzytelnione i autoryzowane żądania, użyj tokenów dostępu użytkowników od dostawcy tożsamości lub weryfikacji certyfikatu, aby zaimplementować to podejście.
Aby włączyć szczegółową kontrolę, zaimplementuj więcej zakresu autoryzacji z rolami i uprawnieniami dla aplikacji klienckich w bramie. Użyj tych zakresów, aby zezwolić na określone operacje na podstawie potrzeb aplikacji klienckiej. Takie podejście zwiększa bezpieczeństwo i możliwości zarządzania.
Aby sprawdzić poprawność tokenu dostępu, upewnij się, że wszystkie zarejestrowane oświadczenia klucza, takie jak , iss, audi exp wszelkie odpowiednie oświadczenia specyficzne dla obciążenia, takie jak nbfczłonkostwo w grupach lub role aplikacji.
Korzystanie z tożsamości zarządzanych platformy Azure
Aby uprościć uwierzytelnianie we wszystkich scenariuszach aplikacji klienckich, użyj tożsamości zarządzanych platformy Azure do scentralizowanego zarządzania uwierzytelnianiem. Takie podejście zmniejsza złożoność i ryzyko związane z zarządzaniem wieloma kluczami interfejsu API lub poświadczeniami w aplikacjach klienckich.
Tożsamości zarządzane z natury obsługują kontrolę dostępu opartą na rolach platformy Azure, dlatego zapewniają, że brama ma tylko najniższy poziom uprawnień niezbędnych do uzyskiwania dostępu do wystąpień usługi Azure OpenAI. Aby zmniejszyć ryzyko nieautoryzowanego dostępu i uprościć zgodność z zasadami zabezpieczeń, połącz tożsamości zarządzane z innymi metodami, które wyłączają uwierzytelnianie alternatywne.
Implementowanie kompleksowej obserwacji
Podczas implementowania bramy z tożsamością zarządzaną zmniejsza możliwość śledzenia, ponieważ tożsamość zarządzana reprezentuje samą bramę, a nie użytkownika lub aplikację, która wysyła żądanie. W związku z tym ważne jest, aby zwiększyć wgląd w metryki związane z żądaniami interfejsu API. Aby zachować widoczność wzorców dostępu i użycia, bramy powinny zapewnić więcej metadanych śledzenia, takich jak identyfikatory klienta i użytkownika żądającego.
Scentralizowane rejestrowanie wszystkich żądań przekazywanych przez bramę pomaga zachować dziennik inspekcji. Scentralizowany dziennik inspekcji jest szczególnie ważny w przypadku rozwiązywania problemów, zgodności i wykrywania nieautoryzowanych prób dostępu.
Bezpieczne buforowanie adresów
Jeśli brama interfejsu API jest odpowiedzialna za uzupełnianie buforowania lub inne wyniki wnioskowania, upewnij się, że tożsamość obiektu żądającego jest uwzględniana w logice pamięci podręcznej. Nie zwracaj buforowanych wyników dla tożsamości, które nie są autoryzowane do odbierania tych danych.
Implementacje bramy
Platforma Azure nie udostępnia kompletnego rozwiązania gotowego do użycia ani architektury referencyjnej w celu utworzenia bramy w tym artykule, więc musisz skompilować i uruchomić bramę. Usługa Azure API Management może służyć do tworzenia rozwiązania opartego na usłudze PaaS za pomocą wbudowanych i niestandardowych zasad. Platforma Azure zawiera również przykłady implementacji obsługiwanych przez społeczność, które obejmują przypadki użycia w tym artykule. Odwołaj się do tych przykładów podczas tworzenia własnego rozwiązania bramy. Aby uzyskać więcej informacji, zobacz wideo Learn Live: Tożsamość i zabezpieczenia aplikacji Azure OpenAI.
Współautorzy
Następujący współautorzy pierwotnie napisali ten artykuł.
Autorzy zabezpieczeń:
- Lizet Pena De Sola | Starszy inżynier klienta, fasttrack dla platformy Azure
- Bappaditya Banerjee | Starszy inżynier klienta, fasttrack dla platformy Azure
- James Croft | Inżynier klienta, niezależnego dostawcy oprogramowania i cyfrowego centrum doskonałości
Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Kontrola dostępu oparta na rolach dla usługi Azure OpenAI
- Używanie tożsamości zarządzanych w usłudze API Management
- Zasady w usłudze API Management
- Uwierzytelnianie i autoryzacja interfejsów API w usłudze API Management
- Ochrona interfejsu API w usłudze API Management przy użyciu protokołu OAuth 2.0 i identyfikatora entra firmy Microsoft
- Zabezpieczanie usług zaplecza przy użyciu uwierzytelniania certyfikatu klienta w usłudze API Management