Bereitstellen benutzerdefinierter Authentifizierung für Azure OpenAI Service über ein Gateway

Intelligente Anwendungen, die Azure OpenAI Service über für Azure-native Dienste verwenden, bieten ein nahtloses Konzept für Benutzerauthentifizierung und Autorisierung. Manche Szenarien sind jedoch komplex und erfordern unterschiedliche Architekturentwürfe. Zu diesen Szenarien gehören Topologien mit nicht auf Azure gehosteten Clientanwendungen, der Verwendung externer Identitätsanbieter und der Bereitstellung mehrerer Clients, die auf dieselben Azure OpenAI-Instanzen zugreifen. In solchen Szenarien kann die Einführung eines Gateways vor Azure OpenAI erhebliche Sicherheitsverbesserungen bieten, indem eine Ebene hinzugefügt wird, die die konsistente Authentifizierung für bereitgestellte Instanzen gewährleistet.

In diesem Artikel werden wichtige Szenarien beschrieben, die die Authentifizierung für Azure OpenAI bereitstellen:

• Authentifizieren von Clientanwendungen über einen externen Identitätsanbieter

• Authentifizieren von Clientanwendungen über Zertifikate

• Authentifizieren mehrerer Clientanwendungen mit Schlüsseln für den Zugriff auf eine freigegebene Azure OpenAI-Instanz

• Authentifizieren von Clientanwendungen, die auf mehrere Azure OpenAI-Instanzen zugreifen

Jedes Szenario beschreibt die Herausforderungen, die damit verbunden sind, und die Vorteile, die sich aus der Einbeziehung eines Gateways ergeben.

Authentifizieren von Clientanwendungen über einen externen Identitätsanbieter

Laden Sie eine Visio-Datei dieser Architektur herunter.

Szenarioeinschränkungen

Für dieses Szenario gelten die folgenden Einschränkungen:

• Clientanwendungen verwenden einen externen OpenID Connect-(OIDC-)aktivierten Identitätsanbieter, z. B. Okta, Auth0 oder Anbieter für soziale Identitäten.

• Clientanwendungen authentifizieren sich gegenüber einem Microsoft Entra-Mandanten, der sich von dem Mandanten der Azure OpenAI-Datenebene unterscheidet.

Diese Einschränkungen können für die folgenden Beispiele gelten:

• Vorhandene Clientanwendungen, die sich bereits bei einem externen OIDC-Anbieter oder Microsoft Entra ID authentifizieren und mit Azure OpenAI-Instanzen integriert sind.

• Clientanwendungen, die Benutzer von mehreren Identitätsanbietern in konsistenter Weise authentifizieren müssen.

Herstellen einer direkten Verbindung mit Azure OpenAI

Wenn die Clientanwendungen in diesen Szenarien eine direkte Verbindung mit Azure OpenAI herstellen, ohne ein Gateway zu verwenden, müssen sie die schlüsselbasierte Authentifizierung verwenden, um sich bei Azure OpenAI zu authentifizieren. Die schlüsselbasierte Authentifizierung bringt zusätzliche Sicherheitsbedenken mit sich. Sie müssen Schlüssel sicher speichern und rotieren, und Sie können nicht verschiedenen Clients rollenbasierte Zugriffssteuerungskonfigurationen (RBAC) für einzelne Modellimplementierungen zuweisen.

Einführung eines Gateways

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ein Gateway bewältigt die Herausforderungen dieses Szenarios auf folgende Weise:

• Das Gateway verwendet Open Authorization (OAuth), um Benutzer mithilfe ihrer vorhandenen externen Identitätsanbieter zu authentifizieren. Das Gateway validiert die authentifizierten Benutzerzugriffstokens, z. B. ein JSON Web Token (JWT), die der Identitätsanbieter generiert. Anschließend gewährt das Gateway die Autorisierung für die unterstützende Azure OpenAI-Instanz.

• Sie müssen keine Clientschlüssel verwalten. Dieses Konzept beseitigt die Sicherheitsrisiken der schlüsselbasierten Authentifizierung.

• Das Gateway stellt mithilfe einer verwalteten Identität eine Verbindung mit Azure OpenAI her, was die Sicherheit mit der am wenigsten privilegierten Azure RBAC verbessert.

Empfehlungen für dieses Szenario

• Fügen Sie weitere OAuth-Bereiche Ihrer Anwendungsregistrierung in Ihrem Identitätsanbieter hinzu, um granulare Berechtigungen für Nutzer zu ermöglichen. Mit diesen Bereichen können Clientanwendungen die Berechtigung zum Ausführen bestimmter Vorgänge in Ihrem Gateway anfordern, einschließlich des Zugriffs auf Azure OpenAI.

• Konfigurieren Sie dieses Szenario für Azure API Management mithilfe von Richtlinien für eingehenden Datenverkehr. Verwenden Sie die validate-jwt-Richtlinie, um das Vorhandensein, die Gültigkeit und die Attributwerte eines unterstützten JWT zu erzwingen.

Gründe für die Vermeidung eines Gateways für dieses Szenario

Wenn eine einzelne intelligente Anwendung auf Azure OpenAI zugreift, kann es einfacher sein, die Benutzerauthentifizierung und -autorisierung innerhalb der Anwendung zu konfigurieren als über das Gateway. Verwenden Sie dieses Konzept, um die erforderliche Azure RBAC zuzuweisen, um die intelligente Anwendung mit Azure OpenAI sicher zu authentifizieren.

Authentifizieren von Clientanwendungen über Zertifikate

Laden Sie eine Visio-Datei dieser Architektur herunter.

Szenarioeinschränkungen

Für dieses Szenario gelten die folgenden Einschränkungen:

• Sie möchten Zertifikate zum Authentifizieren von Clientanwendungen verwenden.

• Clientanwendungen können Microsoft Entra ID oder andere OIDC-Anbieter nicht für die Authentifizierung verwenden (oder Sie möchten dies nicht).

• Clients können keine Verbundidentität für die Authentifizierung verwenden (oder Sie möchten dies nicht).

Diese Einschränkungen können für die folgenden Beispiele gelten:

• Ein Client, der für Azure OpenAI authentifiziert wird, ist ein Computer oder Gerät, auf dem keine Benutzerinteraktionen erfolgen.

• Ihre Organisation erfordert die Verwendung von Zertifikaten für die Authentifizierung aufgrund von Sicherheitsstandards und Compliance-Vorschriften.

• Sie möchten mehreren Clientanwendungen Optionen für die Authentifizierung basierend auf ihrer Umgebung bereitstellen, einschließlich der Verwendung von Clientzertifikaten.

Herstellen einer direkten Verbindung mit Azure OpenAI

Azure OpenAI unterstützt die Clientzertifizierungsauthentifizierung nicht nativ. Um dieses Szenario ohne Gateway zu unterstützen, benötigt die intelligente Anwendung eine Zertifikatauthentifizierung für den Benutzer und einen API-Schlüssel oder eine verwaltete Identität zur Authentifizierung von Anfragen an die Azure OpenAI-Instanz. Sie müssen die Zertifikatauthentifizierungslogik in jedem Client implementieren. In diesem Szenario führt die schlüsselbasierte Authentifizierung zu Risiken und Verwaltungsaufwand, wenn Sie eine direkte Verbindung mit Azure OpenAI von Clients aus herstellen.

Einführung eines Gateways

Laden Sie eine Visio-Datei dieser Architektur herunter.

Sie können ein Gateway in diese Architektur einbinden, das die Validierung der Client-Zertifizierung von den Clients übernimmt. Das Gateway validiert das digitale Clientzertifikat, das die intelligente Anwendung präsentiert, und prüft den Aussteller, das Ablaufdatum, den Fingerabdruck sowie die Sperrlisten. Das Gateway sollte für die Authentifizierung mit Azure OpenAI eine verwaltete Identität verwenden. Das Gateway sollte auch Azure Key Vault verwenden, um die Stammzertifizierungsstelle (Root Certificate Authority, CA) zu speichern. Verwenden Sie dieses Konzept, um die Clientzertifikatüberprüfung zu zentralisieren, wodurch der Wartungsaufwand reduziert wird.

Ein Gateway bietet in diesem Szenario mehrere Vorteile:

• Sie können die verwaltete Identität des Gateways anstelle von Zugriffsschlüsseln verwenden und so das Risiko ausschalten, dass Schlüssel gestohlen werden, und den Wartungsaufwand für rotierende Schlüssel reduzieren.

• Sie können die Zertifikatüberprüfung zentralisieren und damit sicherstellen, dass Sie konsistente Sicherheitsrichtlinien verwenden, um digitale Clientzertifikate für alle intelligenten Anwendungen zu validieren.

• Sie können die Zertifikatüberprüfung auf das Gateway verlagern und damit den Client-Code vereinfachen.

Empfehlungen für dieses Szenario

• Überprüfen Sie bei der Validierung von Zertifikaten die gesamte Zertifikatkette, einschließlich der Stammzertifizierungsstelle und der Zwischenzertifikate. Die vollständige Überprüfung stellt die Echtheit des Zertifikats sicher und verhindert nicht autorisierten Zugriff.

• Rotieren und erneuern Sie Clientzertifikate regelmäßig, um das Risiko einer Zertifikatkompromittierung zu minimieren. Verwenden Sie Key Vault, um diesen Prozess zu automatisieren und Zertifikate auf dem neuesten Stand zu halten. Richten Sie Warnungen für bevorstehende Zertifikatablaufdaten ein, um so Dienstunterbrechungen am Gateway zu verhindern.

• Implementieren Sie wechselseitiges TLS (mutual Transport Layer Security, mTLS), um sicherzustellen, dass sich Client und Server gegenseitig authentifizieren. Diese Strategie bietet eine zusätzliche Sicherheitsebene. Konfigurieren Sie das Gateway so, dass mTLS erzwungen wird, indem Sie geeignete Richtlinien und Einschränkungen festlegen.

• Verwenden Sie die validate-client-certificate-Richtlinie in API Management, um Clientzertifikate zu validieren, auf die ein Azure Key Vault verweist. Diese Richtlinie validiert das von der Clientanwendung präsentierte Clientzertifikat sowie den Aussteller, das Ablaufdatum, den Fingerabdruck und die Sperrlisten.

Gründe für die Vermeidung eines Gateways für dieses Szenario

In einfachen Umgebungen mit wenigen Clients kann können Kosten für die Handhabung von Sicherheit und Zertifikatverwaltung im Client die zusätzliche Komplexität der Einführung eines Gateways überwiegen. Außerdem können Gateways zu Single Points of Failure werden, die Latenzzeit aufgrund zusätzlicher Ebenen erhöhen und zu einer Anbietersperre führen, wenn Sie sich für kommerzielle Lösungen anstatt für individuelle Implementierungen entscheiden.

Sie müssen Ihre spezifischen Anforderungen, die Ressourcenverfügbarkeit und die Kritikalität Ihrer Anwendungen sorgfältig bewerten, bevor Sie sich für die Implementierung eines Gateways zur Clientzertifikatauthentifizierung entscheiden.

Authentifizieren mehrerer Clientanwendungen mit Schlüsseln für den Zugriff auf eine freigegebene Azure OpenAI-Instanz

Laden Sie eine Visio-Datei dieser Architektur herunter.

Szenarioeinschränkungen

Für dieses Szenario gelten die folgenden Einschränkungen:

• Mehrere Clientanwendungen greifen auf eine freigegebene Azure OpenAI-Instanz zu.
• Clients können Microsoft Entra ID nicht für die Authentifizierung verwenden (oder Sie möchten dies nicht).
• Clients können keine Verbundidentität für die Authentifizierung verwenden (oder Sie möchten dies nicht).
• Sie möchten die schlüsselbasierte Authentifizierung für Clientanwendungen verwenden.

Diese Einschränkungen können für die folgenden Beispiele gelten:

• Sie stellen Clientanwendungen in mehreren Umgebungen bereit, einschließlich Azure, lokal oder bei anderen Cloudanbietern.

• Eine Organisation muss Azure OpenAI Services für verschiedene Teams bereitstellen, jeweils mit eindeutigen Zugriffs- und Nutzungsgrenzwerten.

Herstellen einer direkten Verbindung mit Azure OpenAI

Azure OpenAI unterstützt die schlüsselbasierte Authentifizierung mithilfe von gemeinsam genutzten Schlüsseln. Azure OpenAI macht einen Primärschlüssel und einen sekundären Schlüssel verfügbar. Der Zweck des Sekundärschlüssels besteht darin, die Schlüsselrotation zu unterstützen. Er stellt keine Clientidentitätsisolation bereit. Wenn Sie in diesem Szenario mehrere Clients direkt bei Azure OpenAI authentifizieren, teilt jeder Client denselben Schlüssel. Diese Implementierung ist mit den folgenden Herausforderungen verbunden:

• Sie können Berechtigungen für bestimmte Clients nicht widerrufen, da jeder Client denselben Schlüssel verwendet.

• Sie können verschiedenen Clients in derselben Azure OpenAI-Instanzbereitstellung keine unterschiedlichen Zugriffsrechte für unterschiedliche Modelle gewähren.

• Aus Sicht der Protokollierung können Sie einen Client nicht von einem anderen unterscheiden.

Einführung eines Gateways

Laden Sie eine Visio-Datei dieser Architektur herunter.

Sie können ein Gateway in diese Architektur einführen, das einen dedizierten Schlüssel für jede Clientanwendung ausgibt. API Management verwendet zum Bereitstellen von dedizierten Clientschlüsseln das Konzept von Abonnements. Das Gateway sollte für die Authentifizierung mit Azure OpenAI eine verwaltete Identität verwenden.

Ein Gateway bietet in diesem Szenario mehrere Vorteile:

• Sie können den Zugriff auf eine einzelne Clientanwendung widerrufen, ohne dass sich dies auf andere Clients auswirkt.

• Bevor Sie Schlüssel rotieren, müssen Sie nicht alle Schlüsselkonfigurationen des Clients aktualisieren – dies vereinfacht die Schlüsselrotation in logischer Weise. Sie können die dedizierten Schlüssel für jeden Client rotieren, nachdem Sie die Clientkonfiguration aktualisiert haben.

• Sie können jeden Client aus Protokollierungsperspektive eindeutig identifizieren.

• Das Gateway erzwingt Ratenlimits und Kontingente für jeden Client unabhängig.

Empfehlungen für dieses Szenario

• Verbessern Sie die Überwachung von Metriken, die sich auf API-Anforderungen beziehen. Wenn Sie eine verwaltete Identität über ein Gateway verwenden, wird die Nachverfolgbarkeit der Benutzer- und Clientanwendung in Azure OpenAI-Protokollen nicht verbessert. Das Gateway sollte die Protokollierung bereitstellen, die der Anforderung zugeordnet ist, z. B. die anfordernden Client- und Benutzer-IDs.

• Stellen Sie sicher, dass das Gateway Weiterleitungsentscheidungen für geeignete Modellimplementierungen auf der Grundlage der Client-Identität trifft, wenn Sie mehrere Client-Anwendungsanforderungen über ein Gateway zu einer gemeinsam genutzten Azure OpenAI-Instanz leiten. Weitere Informationen finden Sie unter Verwenden eines vor mehreren Azure OpenAI-Bereitstellungen hinzugefügten Gateways

Authentifizieren von Clientanwendungen, die auf mehrere Azure OpenAI-Instanzen zugreifen

Laden Sie eine Visio-Datei dieser Architektur herunter.

Szenarioeinschränkungen

Für dieses Szenario gelten die folgenden Einschränkungen:

• Clientanwendungen stellen eine Verbindung mit mehreren Azure OpenAI-Instanzen in einer oder mehreren Regionen her.
• Clients können Microsoft Entra ID oder andere OIDC-Anbieter nicht für die Authentifizierung verwenden (oder Sie möchten dies nicht).
• Sie möchten die schlüsselbasierte Authentifizierung für Clientanwendungen verwenden.

Diese Einschränkungen können für die folgenden Beispiele gelten:

• Clientanwendungen müssen ihre Workloads geographisch verteilen, um die Latenz zu reduzieren und die Leistung zu verbessern.

• Clientanwendungen versuchen, ihr Kontingent an Tokens pro Minute (TPM) zu optimieren, indem sie Instanzen über mehrere Regionen hinweg bereitstellen.

• Eine Organisation erfordert nahtlose Failover- und Notfallwiederherstellungsfunktionen, um einen kontinuierlichen Betrieb sicherzustellen. Daher verwenden sie eine Strategie für die duale Bereitstellung, z. B. eine, die aus einer bereitgestellten Durchsatzbereitstellung und einer Pay-as-you-go-Bereitstellung besteht.

• Clientanwendungen müssen bestimmte Modellfunktionen verwenden, die nur in bestimmten Azure-Regionen verfügbar sind.

Herstellen einer direkten Verbindung mit mehreren Azure OpenAI-Instanzen

Wenn Clientanwendungen eine direkte Verbindung mit mehreren Azure OpenAI-Instanzen herstellen, muss jeder Client den Schlüssel für jede Instanz speichern. Neben den Sicherheitsaspekten bei der Verwendung von Schlüsseln gibt es einen erhöhten Verwaltungsaufwand beim Rotieren von Schlüsseln.

Einführung eines Gateways

Laden Sie eine Visio-Datei dieser Architektur herunter.

Wenn Sie ein Gateways zum Verarbeiten von Clientanwendungen verwenden, die auf mehrere Azure OpenAI-Bereitstellungen zugreifen, erhalten Sie die gleichen Vorteile, die durch die Einführung eines Gateways zur Behandlung mehrerer Clientanwendungen mit Schlüsseln für den Zugriff auf eine gemeinsam genutzte Azure OpenAI-Instanz geboten werden. Außerdem optimieren Sie damit den Authentifizierungsprozess, da Sie eine einzelne benutzerdefinierte verwaltete Identität zum Authentifizieren von Anforderungen vom Gateway zu mehreren Azure OpenAI-Instanzen verwenden. Implementieren Sie dieses Konzept, um den gesamtbetrieblichen Aufwand zu reduzieren und die Risiken von Fehlkonfigurationen des Clients beim Arbeiten mit mehreren Instanzen zu minimieren.

Empfehlungen für dieses Szenario

• Implementieren Sie Lastverteilungstechniken zur Verteilung von API-Anfragen auf mehrere Instanzen des Azure OpenAI-Diensts, um hohen Datenverkehr zu bewältigen und Hochverfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Verwenden eines vor mehreren Azure OpenAI-Bereitstellungen oder -Instanzen hinzugefügten Gateways.

• Korrelieren Sie die Tokennutzung für jeden Mandanten am Gateway, wenn Sie Mehrmandanten-Szenarien mit mehreren Azure OpenAI-Instanzen implementieren. Dieses Konzept stellt sicher, dass Sie die gesamte Tokennutzung nachverfolgen, unabhängig von der Back-End-Instanz von Azure OpenAI, an die die Anforderung weitergeleitet wird.

Allgemeine Empfehlungen

Wenn Sie Azure OpenAI über ein Gateway integrieren, sollten mehrere übergreifende Empfehlungen in allen Szenarien berücksichtigt werden.

Verwenden Sie API Management, anstatt Ihre eigene Lösung für eine effiziente API-Orchestrierung, eine nahtlose Integration mit anderen Azure-Diensten und für Kosteneinsparungen zu erstellen, und reduzieren Sie so den Entwicklungs- und Wartungsaufwand. API Management sorgt für eine sichere API-Verwaltung, indem Authentifizierung und Autorisierung direkt unterstützt werden. Es lässt sich mit Identitätsanbietern wie Microsoft Entra ID integrieren, was OAuth 2.0 ermöglicht und eine richtlinienbasierte Autorisierung bereitstellt. Außerdem verwendet API Management verwaltete Identitäten für einen sicheren und wartungsarmen Zugang zu Azure OpenAI.

Kombinieren von Szenarien für eine umfassende Gatewaylösung

In realen Anwendungen können Ihre Anwendungsfälle mehrere Szenarien aus diesem Artikel beinhalten. Beispielsweise verfügen Sie möglicherweise über Clientanwendungen, die sich über einen externen Identitätsanbieter authentifizieren und Zugriff auf mehrere Azure OpenAI-Instanzen erfordern.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Kombinieren Sie zur Erstellung eines Gateways, das Ihre spezifischen Anforderungen unterstützt, die Empfehlungen aus diesen Szenarien für ein umfassendes Konzept.

Erzwingen von Gatewayrichtlinien

Bevor ein Gateway Anforderungen an Azure OpenAI-Instanzen sendet, stellen Sie sicher, dass eingehende Authentifizierungs- und Autorisierungsrichtlinien erzwungen werden. Um sicherzustellen, dass das Gateway nur authentifizierte und autorisierte Anforderungen weiterleitet, verwenden Sie Benutzerzugriffstokens von einem Identitätsanbieter oder Zertifikatvalidierung, um dieses Konzept zu implementieren.

Um eine präzise Kontrolle zu ermöglichen, implementieren Sie weitere Autorisierungsbereiche mit Rollen und Berechtigungen für Clientanwendungen in Ihrem Gateway. Verwenden Sie diese Bereiche, um bestimmte Vorgänge basierend auf den Anforderungen der Clientanwendung zuzulassen. Dieses Konzept verbessert Sicherheit und Verwaltbarkeit.

Überprüfen Sie bei der Validierung von Zugriffstokens unbedingt alle wichtigen registrierten Ansprüche wie iss, aud, exp und nbf zusätzlich zu allen relevanten workload-spezifischen Ansprüchen wie Gruppenmitgliedschaften oder Anwendungsrollen.

Verwenden von verwalteten Azure-Identitäten

Verwenden Sie zur Vereinfachung der Authentifizierung über alle Client-Anwendungsszenarien hinweg von Azure verwaltete Identitäten zur Zentralisierung der Authentifizierungsverwaltung. Dieses Konzept reduziert die Komplexität und die Risiken im Zusammenhang mit der Verwaltung mehrerer API-Schlüssel oder Anmeldeinformationen in Clientanwendungen.

Verwaltete Identitäten unterstützen Azure RBAC inhärent und stellen so sicher, dass das Gateway nur über die niedrigste Berechtigungsstufe verfügt, die für den Zugriff auf Azure OpenAI-Instanzen erforderlich ist. Um das Risiko unautorisierter Zugriffe zu reduzieren und die Einhaltung von Sicherheitsrichtlinien sicherzustellen, kombinieren Sie verwaltete Identitäten mit anderen Methoden, die alternative Authentifizierungen deaktivieren.

Implementieren eines umfassenden Einblicks

Wenn Sie ein Gateway mit einer verwalteten Identität implementieren, reduziert dies die Rückverfolgbarkeit, da eine verwaltete Identität das Gateway selbst repräsentiert und nicht den Endbenutzer oder die Anwendung, der/die die Anfrage gestellt hat. Daher ist es wichtig, den Einblick in Metriken im Zusammenhang mit den API-Anforderungen zu verbessern. Um die Transparenz der Zugriffsmuster und der Nutzung zu wahren, sollten Gateways mehr Nachverfolgungsmetadaten bereitstellen, etwa den anfordernden Client und die Benutzer-IDs.

Die zentralisierte Protokollierung aller über das Gateway übergebenen Anforderungen hilft auch bei der Aufrechterhaltung eines Überwachungspfads. Ein zentraler Überwachungspfad ist besonders wichtig für die Fehlersuche, die Einhaltung von Vorschriften und die Erkennung unbefugter Zugriffsversuche.

Gatewayimplementierungen

Azure bietet keine direkt einsetzbare Lösung oder Referenzarchitektur, um das Gateway in diesem Artikel zu erstellen. Daher müssen Sie das Gateway selbst erstellen und betreiben. Azure bietet Beispiele für communitygestützte Implementierungen, die die Anwendungsfälle in diesem Artikel abdecken. Berücksichtigen Sie diese Beispiele, wenn Sie Ihre eigene Gatewaylösung entwickeln. Weitere Informationen finden Sie im Video Learn Live: Azure OpenAI-Anwendungsidentität und -sicherheit.

Beitragende

Dieser Artikel wurde ursprünglich von folgenden Mitwirkenden verfasst.

Hauptautoren:

• Lizet Pena De Sola | Senior Customer Engineer, FastTrack for Azure
• Bappaditya Banerjee | Senior Customer Engineer, FastTrack for Azure
• James Croft | Customer Engineer, ISV & Digital Native Center of Excellence

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• RBAC für Azure OpenAI
• Verwenden von verwalteten Identitäten in API Management
• Richtlinien in Azure API Management
• Authentifizierung und Autorisierung für APIs in API Management
• Schützen einer API in API Management mithilfe von OAuth 2.0 und Microsoft Entra ID
• Sichern von Back-End-Diensten über eine Clientzertifikatauthentifizierung in API Management

Zugehörige Ressourcen

• Zugriff auf Azure OpenAI und andere große Sprachmodelle über ein Gateway