Leggere in inglese Modifica

Condividi tramite


Fornire l'autenticazione personalizzata al Servizi OpenAI di Azure tramite un gateway

Servizi di intelligenza artificiale di Azure
Servizio OpenAI di Azure
Gestione API di Azure
Microsoft Entra ID

Le applicazioni intelligenti che usano il Servizio OpenAI di Azure tramite i servizi nativi di Azure offrono l'autenticazione e l'autorizzazione utente senza problemi. Tuttavia, alcuni scenari sono complessi e richiedono progettazioni di architettura diverse. Questi scenari includono topologie con applicazioni client che non sono ospitate in Azure, usano provider di identità esterni e distribuiscono più client che accedono alle stesse istanze di OpenAI di Azure. In questi scenari, l'introduzione di un gateway davanti a OpenAI di Azure può migliorare notevolmente la sicurezza aggiungendo un livello che garantisce l'autenticazione coerente alle istanze distribuite.

Questo articolo descrive gli scenari chiave che forniscono l'autenticazione a OpenAI di Azure:

Ogni scenario descrive le sfide introdotte e i vantaggi derivanti dall'incorporazione di un gateway.

Importante

È possibile usare le indicazioni seguenti per qualsiasi implementazione del gateway, incluso API Management di Azure. Per illustrare questa flessibilità, i diagrammi dell'architettura usano rappresentazioni generiche dei componenti nella maggior parte degli scenari.

Autenticare le applicazioni client tramite un provider di identità esterno

Diagramma che mostra le app client che autenticano gli utenti con un provider di identità esterno e OpenAI di Azure usando le chiavi API.

Scaricare un file di Visio di questa architettura.

Vincoli di scenario

Questo scenario presenta i vincoli seguenti:

  • Le applicazioni client usano un provider di identità abilitato per OpenID Connect (OIDC), ad esempio Okta, Auth0 o provider di identità di social networking.

  • Le applicazioni client eseguono l'autenticazione in base a un tenant di Microsoft Entra diverso dal tenant del piano dati OpenAI di Azure.

Questi vincoli possono essere applicati ai seguenti esempi:

  • Applicazioni client esistenti che già eseguono l'autenticazione con un provider OIDC esterno o Microsoft Entra ID e che si integrano con le istanze di OpenAI di Azure.

  • Applicazioni client che devono autenticare in modo coerente gli utenti da più provider di identità.

Connettersi direttamente a OpenAI di Azure

Se le applicazioni client in questi scenari si connettono direttamente a OpenAI di Azure senza usare un gateway, è necessario usare l'autenticazione basata su chiave per eseguire l'autenticazione a OpenAI di Azure. L'autenticazione basata su chiave introduce problemi di sicurezza aggiuntivi. È necessario archiviare e ruotare le chiavi in modo sicuro e non è possibile assegnare diverse configurazioni di controllo degli accessi in base al ruolo (RBAC) dei client per le singole distribuzioni modello.

Introdurre un gateway

Diagramma che mostra un gateway tra le app client e OpenAI di Azure, che abilita l'autenticazione con un provider di identità esterno.

Scaricare un file di Visio di questa architettura.

Un gateway risolve i problemi di questo scenario nei modi seguenti:

  • Il gateway usa Open Authorization (OAuth) per autenticare gli utenti tramite i provider di identità esterni esistenti. Il gateway convalida i token di accesso utente autenticati, ad esempio un token JSON Web (JWT), generato dal provider di identità. Il gateway concede quindi l'autorizzazione all'istanza OpenAI di Azure di backup.

  • Non è necessario gestire le chiavi client. Questo approccio elimina i rischi per la sicurezza dell'autenticazione basata su chiave.

  • Il gateway si connette a OpenAI di Azure usando un'identità gestita, migliorando la sicurezza tramite RBAC di Azure con privilegi minimi.

Raccomandazioni per questo scenario

  • Aggiungere altri ambiti OAuth alla registrazione dell'applicazione nel provider di identità per abilitare autorizzazioni granulari per i consumer. Questi ambiti consentono alle applicazioni client di richiedere l'autorizzazione per eseguire operazioni specifiche nel gateway, incluso l'accesso a OpenAI di Azure.

  • Configurare questo scenario per API Management usando i criteri in ingresso. Usare validate-jwt criteri per applicare i valori di esistenza, validità e attributo di un token JWT supportato.

Motivi per evitare un gateway per questo scenario

Se una singola applicazione intelligente accede a OpenAI di Azure, è più semplice configurare l'autenticazione e l'autorizzazione degli utenti all'interno dell'app anziché tramite il gateway. Usare questo approccio per assegnare il RBAC di Azure necessario per autenticare in modo sicuro l'applicazione intelligente con OpenAI di Azure.

Autenticare le applicazioni client tramite certificati

Diagramma che mostra un'architettura per autenticare gli utenti tramite certificati.

Scaricare un file di Visio di questa architettura.

Vincoli di scenario

Questo scenario presenta i vincoli seguenti:

  • Si desidera usare i certificati per autenticare le applicazioni client.

  • Le applicazioni client non possono usare o non si vuole usare, Microsoft Entra ID o altri provider OIDC per l'autenticazione.

  • I client non possono usare o non si vuole usare l'identità federata per l'autenticazione.

Questi vincoli possono essere applicati ai seguenti esempi:

  • Un client che esegue l'autenticazione a OpenAI di Azure è un computer o un dispositivo e non viene eseguita alcuna interazione dell'utente.

  • L'organizzazione richiede l'uso dei certificati per l'autenticazione a causa degli standard di sicurezza e delle normative di conformità.

  • Si vuole fornire a più applicazioni client opzioni per l'autenticazione in base al proprio ambiente, incluso l'uso dei certificati client.

Connettersi direttamente a OpenAI di Azure

OpenAI di Azure non supporta in modo nativo l'autenticazione della certificazione client. Per supportare questo scenario senza un gateway, l'applicazione intelligente deve usare l'autenticazione del certificato per l'utente e una chiave API o un'identità gestita per autenticare le richieste all'istanza di OpenAI di Azure. È necessario implementare la logica di autenticazione del certificato in ogni client. In questo scenario, l'autenticazione basata su chiave introduce rischi e sovraccarichi di gestione se ci si connette direttamente a OpenAI di Azure dai client.

Introdurre un gateway

Diagramma che mostra un gateway tra client e OpenAI di Azure che usa un'identità gestita con il controllo degli accessi in base al ruolo.

Scaricare un file di Visio di questa architettura.

È possibile introdurre un gateway in questa architettura che esegue l'offload della convalida della certificazione client dai client. Il gateway convalida il certificato digitale client presentato dall'applicazione intelligente e controlla l'autorità emittente, la data di scadenza, l'identificazione personale e gli elenchi di revoche. Il gateway deve usare un'identità gestita per autenticarsi con OpenAI di Azure. Il gateway deve anche usare Azure Key Vault per archiviare l'autorità di certificazione radice (CA). Usare questo approccio per centralizzare la convalida dei certificati client, riducendo così il sovraccarico di manutenzione.

Un gateway offre diversi vantaggi in questo scenario:

  • Si usa l'identità gestita del gateway anziché le chiavi di accesso, eliminando così il rischio di furto delle chiavi e riducendo il carico di manutenzione della rotazione delle chiavi.

  • È possibile centralizzare la convalida dei certificati, assicurandosi di usare criteri di sicurezza coerenti per valutare i certificati digitali client per tutte le applicazioni intelligenti.

  • È possibile eseguire l'offload della convalida del certificato nel gateway, semplificando il codice client.

Raccomandazioni per questo scenario

  • Verificare l'intera catena di certificati, inclusa CA radice e i certificati intermedi, quando si convalidano i certificati. La verifica completa garantisce l'autenticità del certificato e impedisce l'accesso non autorizzato.

  • Ruotare e rinnovare regolarmente i certificati client per ridurre al minimo il rischio di compromissione dei certificati. Usare Key Vault per automatizzare questo processo e mantenere aggiornati i certificati. Impostare avvisi per le scadenze imminenti dei certificati per evitare interruzioni del servizio nel gateway.

  • Implementare mTLS (Transport Layer Security) reciproco per assicurarsi che sia il client che il server si autenticano tra loro. Questa strategia offre un ulteriore livello di sicurezza. Per configurare il gateway per applicare mTLS, impostare i criteri e i vincoli appropriati.

  • Usare i validate-client-certificate criteri in API Management per convalidare i certificati client a cui fa riferimento un insieme di credenziali delle chiavi di Azure. Questo criterio convalida il certificato client presentato dall'applicazione client e controlla l'autorità emittente, la data di scadenza, l'identificazione personale e gli elenchi di revoche.

Motivi per evitare un gateway per questo scenario

In ambienti semplici con pochi client, il costo di gestione della sicurezza e della gestione dei certificati nel client può superare la complessità aggiunta dell'introduzione di un gateway. Inoltre, i gateway possono diventare singoli punti di errore, aumentare la latenza a causa di livelli aggiunti e causare il blocco del fornitore se si scelgono soluzioni commerciali anziché implementazioni personalizzate.

È necessario valutare attentamente le esigenze specifiche, la disponibilità delle risorse e la criticità delle applicazioni prima di implementare un gateway per l'autenticazione del certificato client.

Autenticare più applicazioni client tramite chiavi per accedere a un'istanza di OpenAI di Azure condivisa

Diagramma di più app client che eseguono l'autenticazione con OpenAI di Azure tramite una chiave API condivisa.

Scaricare un file di Visio di questa architettura.

Vincoli di scenario

Questo scenario presenta i vincoli seguenti:

  • Più applicazioni client accedono a un'istanza di OpenAI di Azure condivisa.
  • I client non possono usare o non si vuole usare Microsoft Entra ID per l'autenticazione.
  • I client non possono usare o non si vuole usare l'identità federata per l'autenticazione.
  • Si vuole usare l'autenticazione basata su chiave per le applicazioni client.

Questi vincoli possono essere applicati ai seguenti esempi:

  • Le applicazioni client vengono distribuite in più ambienti, tra cui Azure, locale o altri provider di servizi cloud.

  • Un'organizzazione deve fornire OpenAI di Azure a team diversi e impostare limiti di accesso e utilizzo univoci per ogni team.

Connettersi direttamente a OpenAI di Azure

OpenAI di Azure supporta l'autenticazione basata su chiave tramite chiavi condivise. OpenAI di Azure espone una chiave primaria e una chiave secondaria. Lo scopo della chiave secondaria è supportare la rotazione delle chiavi. Non fornisce l'isolamento dell'identità client. Quando si autenticano più client direttamente in OpenAI di Azure in questo scenario, ogni client condivide la stessa chiave. Questa implementazione presenta le seguenti difficoltà:

  • Non è possibile revocare le autorizzazioni per client specifici perché ogni client condivide la stessa chiave.

  • Non è possibile concedere a client diversi diritti di accesso a modelli diversi nella stessa distribuzione dell'istanza OpenAI di Azure.

  • Non è possibile distinguere un client da un altro dal punto di vista della registrazione.

Introdurre un gateway

Diagramma che mostra un gateway tra più client e OpenAI di Azure che usa chiavi di sottoscrizione per client e autenticazione di identità gestite.

Scaricare un file di Visio di questa architettura.

È possibile introdurre un gateway in questa architettura che rilascia una chiave dedicata a ogni applicazione client. API Management usa il concetto di sottoscrizioni per fornire chiavi client dedicate. Il gateway deve usare un'identità gestita per autenticarsi con OpenAI di Azure.

Un gateway offre diversi vantaggi in questo scenario:

  • È possibile revocare l'accesso a una singola applicazione client senza influire sugli altri client.

  • Non è necessario aggiornare tutte le configurazioni chiave del client prima di ruotare le chiavi, quindi la rotazione delle chiavi è più semplice. È possibile ruotare le chiavi dedicate per ogni client dopo aver aggiornato la configurazione client.

  • È possibile identificare in modo univoco ogni client dal punto di vista della registrazione.

  • Il gateway applica i limiti di frequenza e le quote per ogni client in modo indipendente.

Raccomandazioni per questo scenario

  • Migliorare il monitoraggio sulle metriche correlate alle richieste API. Quando si usa un'identità gestita da un gateway, la tracciabilità dell'utente e dell'applicazione client nei log di OpenAI di Azure non migliora. Il gateway deve fornire la registrazione associata alla richiesta, ad esempio gli ID client e utente richiesti.

  • Assicurarsi che il gateway prende decisioni di routing per le distribuzioni di modelli appropriate in base all'identità client quando si instradano più richieste di applicazioni client tramite un gateway a un'istanza di OpenAI di Azure condivisa. Per maggiori informazioni, consultare la sezione Usare un gateway davanti a più distribuzioni OpenAI di Azure.

Autenticare le applicazioni client che accedono a più istanze di OpenAI di Azure

Diagramma che mostra le applicazioni client che eseguono l'autenticazione con più istanze di OpenAI di Azure tramite chiavi API condivise per ogni istanza.

Scaricare un file di Visio di questa architettura.

Vincoli di scenario

Questo scenario presenta i vincoli seguenti:

  • Le applicazioni client si connettono a più istanze di OpenAI di Azure in una o più aree.
  • I client non possono usare o non si vuole usare, Microsoft Entra ID o altri provider OIDC per l'autenticazione.
  • Si vuole usare l'autenticazione basata su chiave per le applicazioni client.

Questi vincoli possono essere applicati ai seguenti esempi:

  • Le applicazioni client devono distribuire i carichi di lavoro geograficamente per ridurre la latenza e migliorare le prestazioni.

  • Le applicazioni client tentano di ottimizzare le quote di token al minuto distribuendo istanze in più aree.

  • Un'organizzazione richiede funzionalità di failover e ripristino di emergenza senza problemi per garantire un'operazione continua. Quindi gestiscono una strategia di distribuzione duale, ad esempio una strategia costituita da una distribuzione della velocità effettiva con provisioning e da una distribuzione con pagamento in base al consumo.

  • Le applicazioni client devono usare funzionalità di modello specifiche disponibili solo in determinate aree di Azure.

Connettersi direttamente a più istanze di OpenAI di Azure

Quando le applicazioni client si connettono direttamente a più istanze di OpenAI di Azure, ogni client deve archiviare la chiave per ogni istanza. Oltre alle considerazioni sulla sicurezza relative all'uso delle chiavi, esiste un aumento del carico di gestione relativo alla rotazione delle chiavi.

Introdurre un gateway

Diagramma di un gateway con una singola chiave per un'applicazione client e l'autenticazione identità gestite in OpenAI di Azure con RBAC.

Scaricare un file di Visio di questa architettura.

Quando si usa un gateway per gestire le applicazioni client che accedono a più distribuzioni OpenAI di Azure, si ottengono gli stessi vantaggi di un gateway che gestisce applicazioni client multiple tramite chiavi per accedere a un'istanza di OpenAI di Azure condivisa. È anche possibile semplificare il processo di autenticazione perché si usa una singola identità gestita definita dall'utente per autenticare le richieste dal gateway a più istanze di OpenAI di Azure. Implementare questo approccio per ridurre il sovraccarico operativo complessivo e ridurre al minimo i rischi di errori di configurazione del client quando si usano più istanze.

Un esempio di come viene usato un gateway in Azure per eseguire l'offload dell'identità in un intermediario è la risorsa di Servizi di intelligenza artificiale di Azure. In tale implementazione si esegue l'autenticazione al gateway e il gateway gestisce l'autenticazione per i diversi servizi di intelligenza artificiale di Azure, ad esempio Visione personalizzata o Riconoscimento vocale. Anche se l'implementazione è simile, non risolve questo scenario.

Raccomandazioni per questo scenario

  • Implementare tecniche di bilanciamento del carico per distribuire le richieste API tra più istanze di OpenAI di Azure per gestire il traffico elevato e garantire la disponibilità elevata. Per maggiori informazioni, consultare la sezione Usare un gateway davanti a distribuzioni o istanze OpenAI di Azure multiple.

  • Correlare l'utilizzo dei token per ogni tenant nel gateway quando si implementano scenari multi-tenant con istanze di OpenAI di Azure multiple. Questo approccio garantisce di tenere traccia dell'utilizzo totale dei token, indipendentemente dall'istanza OpenAI di Azure back-end a cui viene inoltrata la richiesta.

Raccomandazioni generali

Integrando OpenAI di Azure tramite un gateway, esistono diverse raccomandazioni trasversali da considerare applicabili in tutti gli scenari.

Usare Gestione API di Azure invece di creare una soluzione personalizzata per un'orchestrazione efficiente delle API, un'integrazione senza problemi con altri servizi di Azure e risparmi sui costi riducendo le attività di sviluppo e manutenzione. API Management garantisce la sicurezza di API Management supportando direttamente l'autenticazione e l'autorizzazione. Si integra con provider di identità, ad esempio Microsoft Entra ID, che abilita OAuth 2.0 e fornisce l'autorizzazione basata su criteri. Inoltre, API Management usa le identità gestite per l'accesso sicuro e a bassa manutenzione ad OpenAI di Azure.

Combinare scenari per una soluzione gateway completa

Nelle applicazioni reali, i casi d'uso possono estendersi su più scenari di questo articolo. Ad esempio, si potrebbero avere applicazioni client che eseguono l'autenticazione tramite un provider di identità esterno e richiedono l'accesso a istanze di OpenAI di Azure multiple.

Diagramma che mostra le applicazioni client che eseguono l'autenticazione con un provider di identità esterno tramite un gateway, che ha accesso a istanze di OpenAI di Azure multiple.

Scaricare un file di Visio di questa architettura.

Per creare un gateway che supporti i requisiti specifici, combinare le raccomandazioni di questi scenari per un approccio completo.

Applicare i criteri del gateway

Prima che un gateway invii richieste alle istanze OpenAI di Azure, assicurarsi di applicare i criteri di autenticazione e autorizzazione in ingresso. Per garantire che il gateway inoltra solo le richieste autenticate e autorizzate, usare i token di accesso utente da un provider di identità o la convalida del certificato per implementare questo approccio.

Per abilitare il controllo granulare, implementare un maggior ambito di autorizzazione con ruoli e autorizzazioni per le applicazioni client nel gateway. Usare questi ambiti per consentire operazioni specifiche in base alle esigenze dell'applicazione client. Questo approccio migliora la sicurezza e la gestibilità.

Per la convalida del token di accesso, assicurarsi di convalidare tutte le attestazioni registrate con chiave, ad esempio iss, audexp, e nbf, qualsiasi attestazione specifica del carico di lavoro pertinente, ad esempio appartenenze a gruppi o ruoli applicazione.

Usare le identità gestite di Azure

Per semplificare l'autenticazione in tutti gli scenari di applicazioni client, usare le identità gestite di Azure per centralizzare la gestione dell'autenticazione. Questo approccio riduce la complessità e i rischi associati alla gestione di più chiavi API o credenziali nelle applicazioni client.

Le identità gestite supportano intrinsecamente il controllo degli accessi in base al ruolo di Azure, quindi assicurano che il gateway abbia solo il livello di autorizzazioni più basso necessario per accedere alle istanze OpenAI di Azure. Per ridurre il rischio di accesso non autorizzato e semplificare la conformità ai criteri di sicurezza, combinare le identità gestite con altri metodi che disabilitano l'autenticazione alternativa.

Implementare un'osservabilità completa

Quando si implementa un gateway con un'identità gestita, riduce la tracciabilità perché l'identità gestita rappresenta il gateway stesso, non l'utente o l'applicazione che effettua la richiesta. Di conseguenza, è essenziale migliorare l'osservabilità sulle metriche correlate alle richieste API. Per mantenere la visibilità sui modelli di accesso e sull'utilizzo, i gateway devono fornire più metadati di traccia, ad esempio gli ID client e utente richiesti.

La registrazione centralizzata di tutte le richieste che passano attraverso il gateway consente di gestire un audit trail. Un audit trail centralizzato è particolarmente importante per la risoluzione dei problemi, la conformità e il rilevamento di tentativi di accesso non autorizzati.

Memorizzazione nella cache degli indirizzi in modo sicuro

Se il gateway API è responsabile della memorizzazione nella cache dei completamenti o di altri risultati di inferenza, assicurarsi che l'identità del richiedente sia considerata nella logica della cache. Non restituire i risultati memorizzati nella cache per le identità che non sono autorizzate a ricevere tali dati.

Implementazioni del gateway

Azure non fornisce una soluzione chiavi in mano completa o un'architettura di riferimento per compilare il gateway in questo articolo, quindi è necessario compilare e gestire il gateway. È possibile usare Gestione API di Azure per creare una soluzione basata su PaaS tramite criteri predefiniti e personalizzati. Azure offre anche esempi di implementazioni supportate dalla community che riguardano i casi d'uso in questo articolo. Fare riferimento a questi esempi quando si compila una soluzione gateway personalizzata. Per maggiori informazioni, guardare il video Learn Live: Identità e sicurezza delle applicazioni OpenAI di Azure.

Collaboratori

Questo articolo è stato originariamente scritto dai seguenti collaboratori.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi