Os aplicativos inteligentes que usam o Serviço OpenAI do Azure por meio de serviços nativos do Azure oferecem autenticação e autorização perfeitas do usuário. No entanto, alguns cenários são complexos e exigem designs de arquitetura diferentes. Esses cenários incluem topologias que têm aplicativos cliente que não são hospedados no Azure, que usam provedores de identidade externos e que implantam diversos clientes que acessam as mesmas instâncias do OpenAI do Azure. Nesses cenários, a introdução de um gateway na frente do OpenAI do Azure pode melhorar consideravelmente a segurança, adicionando uma camada que garante autenticação consistente para instâncias implantadas.
Este artigo descreve os principais cenários que fornecem autenticação para o Azure OpenAI:
Autenticar aplicativos cliente por meio de um provedor de identidade externo
Autenticar aplicativos cliente que acessam várias instâncias do OpenAI do Azure
Cada cenário descreve os desafios apresentados e os benefícios de incorporar um gateway.
Importante
Você pode usar a orientação a seguir para qualquer implementação de gateway, incluindo o Azure API Management. Para ilustrar essa flexibilidade, os diagramas de arquitetura usam representações genéricas de componentes na maioria dos cenários.
Autenticar aplicativos cliente por meio de um provedor de identidade externo
Baixe um Arquivo Visio dessa arquitetura.
Restrições do cenário
Esse cenário tem as seguintes restrições:
Os aplicativos cliente usam um provedor de identidade externo habilitado para OpenID Connect (OIDC), como Okta, Auth0 ou provedores de identidade social.
Os aplicativos cliente autenticam-se em um locatário que é diferente do Microsoft Entra do locatário do plano de dados do OpenAI do Azure.
Estas restrições aplicam-se aos seguintes exemplos:
Os aplicativos cliente existentes que já se autenticam em um provedor OIDC externo ou no Microsoft Entra ID e que se integram às instâncias do OpenAI do Azure.
Os aplicativos cliente que precisam constantemente autenticar usuários de vários provedores de identidade.
Conectar-se diretamente ao OpenAI do Azure
Se os aplicativos cliente nesses cenários se conectarem diretamente ao OpenAI do Azure sem usar um gateway, eles deverão usar a autenticação com base em chaves para autenticar no OpenAI do Azure. A autenticação baseada em chave introduz preocupações extras de segurança. É necessário armazenar e girar chaves com segurança, e você não pode fornecer configurações de RBAC (controle de acesso baseado em função) de clientes diferentes para implantações de modelos individuais.
Introduzir um gateway
Baixe um Arquivo Visio dessa arquitetura.
Um gateway resolve os desafios desse cenário das seguintes maneiras:
O gateway usa o Autorização Aberta (OAuth) para autenticar usuários por meio de seus provedores de identidade externos existentes. O gateway valida os tokens de acesso do usuário autenticados, como um JSON Web Token (JWT), que o provedor de identidade gera. Em seguida, o gateway concede autorização à instância de suporte do OpenAI do Azure.
Não é necessário gerenciar chaves de cliente. Essa abordagem elimina os riscos de segurança da autenticação baseada em chave.
O gateway conecta-se ao Azure OpenAI ao utilizar uma identidade gerida, o que melhora a segurança através do Azure RBAC com menos privilégios.
Recomendações para este cenário
Adicione mais escopos OAuth ao registro de aplicativo em seu provedor de identidade para habilitar a permissão granular aos consumidores. Esses escopos possibilitam que os aplicativos cliente solicitem permissão para executar operações específicas em seu gateway, incluindo acesso ao OpenAI do Azure.
Configure esse cenário para o Azure API Management ao usar políticas de entrada. Use a
validate-jwtpolítica para impor a existência, validade e valores de atributo de um JWT compatível.
Razões para evitar um gateway para esse cenário
Se uma única aplicação inteligente acessar ao OpenAI do Azure, será mais fácil configurar a autenticação e autorização do utilizador dentro do aplicativo em vez de por meio do gateway. Use esta abordagem para atribuir o RBAC do Azure necessário para autenticar com segurança o aplicativo inteligente com o OpenAI do Azure.
Autenticar aplicativos cliente por meio de certificados
Baixe um Arquivo Visio dessa arquitetura.
Restrições do cenário
Esse cenário tem as seguintes restrições:
Você deseja usar certificados para autenticar aplicativos cliente.
Os aplicativos cliente não podem ser usados ou você não deseja usar o Microsoft Entra ID nem outro provedor OIDC para autenticação.
Os clientes não podem usar, ou você não deseja usar, a identidade federada para autenticação.
Estas restrições aplicam-se aos seguintes exemplos:
Um cliente que autentica no OpenAI do Azure é uma máquina ou dispositivo e não ocorre nenhuma interação do usuário.
Sua organização exige que você use certificados para autenticação devido a padrões de segurança e regulamentos de conformidade.
Você deseja fornecer vários aplicativos cliente com opções para autenticação com base no ambiente, incluindo o uso de certificados de cliente.
Conectar-se diretamente ao OpenAI do Azure
O OpenAI do Azure não oferece suporte nativo à autenticação de certificação de cliente. Para dar suporte a esse cenário sem um gateway, o aplicativo inteligente precisa usar a autenticação de certificado para o usuário e usar uma chave de API ou identidade gerenciada para autenticar solicitações para a instância do OpenAI do Azure. Você deve implementar a lógica de autenticação de certificado em cada cliente. Neste cenário, a autenticação baseada em chaves introduz riscos e sobrecarga de gestão se ligar diretamente ao OpenAI do Azure a partir de clientes.
Introduzir um gateway
Baixe um Arquivo Visio dessa arquitetura.
Você pode introduzir um gateway nessa arquitetura que descarrega a validação de certificação do cliente dos clientes. O gateway tem a responsabilidade de validar o certificado digital do cliente que o aplicativo inteligente apresente e verifique o emissor, a data de validade, a impressão digital e as listas de revogação. O gateway deve usar uma identidade gerenciada para se autenticar com o OpenAI do Azure. O gateway também deve usar o Azure Key Vault para armazenar a AC (autoridade de certificação) raiz. Use essa abordagem para centralizar a validação do certificado do cliente, o que reduz a sobrecarga de manutenção.
Um gateway fornece várias vantagens neste cenário:
Você usa a identidade gerenciada do gateway em vez de chaves de acesso, o que elimina o risco de chaves roubadas e reduz a carga de manutenção da rotação de chaves.
Você pode centralizar a validação de certificados, o que garante o uso de políticas de segurança consistentes para avaliar certificados digitais de clientes para todos os aplicativos inteligentes.
Você pode descarregar a validação do certificado para o gateway, o que simplifica o código do cliente.
Recomendações para este cenário
Verifique toda a cadeia de certificados, incluindo a CA raiz e os certificados intermediários, ao validar os certificados. A verificação completa garante a autenticidade do certificado e evita o acesso não autorizado.
Alterne e renove certificados de cliente regularmente para minimizar o risco de comprometimento do certificado. Use o Key Vault para automatizar esse processo e manter os certificados atualizados. Defina alertas para expirações futuras de certificados para evitar interrupções de serviço no gateway.
Implemente o Transport Layer Security (mTLS) mútuo para garantir que o cliente e o servidor se autentiquem. Essa estratégia fornece uma camada adicional de segurança. Para configurar o gateway para impor o mTLS, defina as devidas políticas e restrições.
Use a
validate-client-certificatepolítica no API Management para validar os certificados de cliente referenciados por um cofre de chaves do Azure. Essa política valida o certificado do cliente que o aplicativo cliente apresenta e verifica as listas de emissores, expiração, impressão digital e revogação.
Razões para evitar um gateway para esse cenário
Em ambientes simples que têm poucos clientes, o custo de lidar com a segurança e o gerenciamento de certificados no cliente pode superar a complexidade adicional da introdução de um gateway. Além disso, os gateways podem se tornar pontos únicos de falha, aumentar a latência por causa de camadas adicionais e levar ao bloqueio do fornecedor se você escolher soluções comerciais em vez de implementações personalizadas.
Você deve avaliar cuidadosamente suas necessidades específicas, a disponibilidade de recursos e a criticidade de seus aplicativos antes de implementar um gateway para autenticação de certificado de cliente.
Autenticar vários aplicativos cliente por meio de chaves para acessar uma instância compartilhada do OpenAI do Azure
Baixe um Arquivo Visio dessa arquitetura.
Restrições do cenário
Esse cenário tem as seguintes restrições:
- Vários aplicativos cliente acessam uma instância compartilhada do OpenAI do Azure.
- Os clientes não podem usar ou você não deseja usar o Microsoft Entra ID para autenticação.
- Os clientes não podem usar, ou você não deseja usar, a identidade federada para autenticação.
- Você deseja usar a autenticação com base em chaves para aplicativos cliente.
Estas restrições aplicam-se aos seguintes exemplos:
Você implanta aplicativos em vários ambientes, incluindo o Azure, outros provedores de nuvem ou locais.
Uma organização precisa fornecer o OpenAI do Azure para equipes diferentes e define limites exclusivos de acesso e uso para cada equipe.
Conectar-se diretamente ao OpenAI do Azure
O OpenAI do Azure dá suporte à autenticação com base em chaves por meio de chaves compartilhadas. O OpenAI do Azure expõe uma chave primária e uma chave secundária. A finalidade da chave secundária é dar suporte à rotação de chaves. Ele não fornece isolamento de identidade do cliente. Quando você autentica vários clientes diretamente no OpenAI do Azure nesse cenário, cada cliente compartilha a mesma chave. Esta implementação tem as seguintes desafios:
Você não pode revogar permissões para clientes específicos porque todos os clientes compartilham a mesma chave.
Você não pode conceder a clientes direitos de acesso diferentes a modelos diferentes na mesma implantação de instância do OpenAI do Azure.
Não é possível diferenciar um cliente de outro de uma perspectiva de log.
Introduzir um gateway
Baixe um Arquivo Visio dessa arquitetura.
Você pode introduzir um gateway nessa arquitetura que emite uma chave dedicada para cada aplicativo cliente. O API Management usa o conceito de assinaturas para fornecer chaves de cliente dedicadas. O gateway deve usar uma identidade gerenciada para se autenticar com o OpenAI do Azure.
Um gateway fornece várias vantagens neste cenário:
Você pode revogar o acesso a um único aplicativo cliente sem afetar outros clientes.
Você não precisa atualizar todas as configurações de chave do cliente antes de girar as chaves, portanto, a rotação de chaves é logisticamente mais fácil. Pode ser feita a rotatividade das chaves dedicadas para cada cliente depois que a configuração do cliente for atualizada.
Você pode identificar exclusivamente cada cliente a partir de uma perspectiva de registro.
O gateway impõe limites de taxas e cotas para cada cliente de forma independente.
Recomendações para este cenário
Aprimore o monitoramento de métricas relacionadas a solicitações de API. Quando você usa uma identidade gerida a partir de um gateway, a rastreabilidade da aplicação do utilizador e do cliente nos registros do OpenAI do Azure não melhora. O gateway deve fornecer o log associado à solicitação, como os IDs de cliente e usuário solicitantes.
Certifique-se de que o gateway toma decisões de encaminhamento para implantações de modelo apropriadas com base na identidade do cliente quando encaminha vários pedidos de aplicação do cliente através de um gateway para uma instância compartilhada do OpenAI do Azure. Para mais informações, consulte Usar um gateway na frente de várias implantações ou instâncias do OpenAI do Azure.
Autenticar aplicativos cliente que acessam várias instâncias do OpenAI do Azure
Baixe um Arquivo Visio dessa arquitetura.
Restrições do cenário
Esse cenário tem as seguintes restrições:
- Os aplicativos cliente conectam-se a várias instâncias do OpenAI do Azure em uma ou mais regiões.
- Os clientes não podem ser usados ou você não deseja usar o Microsoft Entra ID nem outro provedor OIDC para autenticação.
- Você deseja usar a autenticação com base em chaves para aplicativos cliente.
Estas restrições aplicam-se aos seguintes exemplos:
Os aplicativos cliente devem distribuir suas cargas de trabalho geograficamente para reduzir a latência e melhorar o desempenho.
Os aplicativos cliente tentam otimizar suas cotas de tokens por minuto implantando instâncias em várias regiões.
Uma organização requer recursos contínuos de failover e recuperação de desastres para garantir a operação contínua. Portanto, eles gerenciam uma estratégia de implantação dupla, como uma estratégia que consiste em uma implantação de taxa de transferência provisionada e uma implantação paga conforme o uso.
Os aplicativos cliente devem usar recursos de modelo específicos que só estão disponíveis em determinadas regiões do Azure.
Conectar-se diretamente a várias instâncias do OpenAI do Azure
Quando os aplicativos cliente se conectam diretamente a várias instâncias do OpenAI do Azure, cada cliente deve armazenar a chave para cada instância. Juntamente com as considerações de segurança do uso de chaves, há uma carga de gerenciamento maior em relação à rotatividade de chaves.
Introduzir um gateway
Baixe um Arquivo Visio dessa arquitetura.
Ao usar um gateway para lidar com aplicativos clientes que acessam várias implantações do Azure OpenAI, você obtém os mesmos benefícios que um gateway que lida com vários aplicativos cliente usando chaves para acessar uma instância compartilhada do OpenAI do Azure. Você também simplifica o processo de autenticação porque usa uma única identidade gerenciada definida pelo usuário para autenticar solicitações do gateway para várias instâncias do OpenAI do Azure. Implemente essa abordagem para reduzir a sobrecarga operacional geral e minimizar os riscos de configuração incorreta do cliente ao trabalhar com diversas instâncias.
Um exemplo de como um gateway está sendo usado no Azure para descarregar a identidade para um intermediário é o recurso dos Serviços de IA do Azure. Nessa implementação, você se autentica no gateway e o gateway lida com a autenticação nos diferentes serviços de IA do Azure, como Visão Personalizada ou Fala. Embora essa implementação seja semelhante, ela não aborda esse cenário.
Recomendações para este cenário
Implemente técnicas de balanceamento de carga para distribuir as solicitações de API em várias instâncias do OpenAI do Azure para lidar com o alto tráfego e garantir alta disponibilidade. Para mais informações, consulte Usar um gateway na frente de várias implantações ou instâncias do OpenAI do Azure.
Correlacione o uso de token para cada locatário no gateway ao implementar cenários multilocatários com várias instâncias do OpenAI do Azure. Esta abordagem garante que rastreia a utilização total de tokens, independentemente da instância back-end do OpenAI do Azure para a qual o pedido é encaminhado.
Recomendações gerais
Quando integra o Azure OpenAI através de um gateway, existem várias recomendações transversais a considerar que se aplicam em todos os cenários.
Use o Gerenciamento de API do Azure em vez de criar sua própria solução para orquestração eficiente de API, integração perfeita com outros serviços do Azure e economia de custos, reduzindo os esforços de desenvolvimento e manutenção. O API Management garante o gerenciamento seguro de API, oferecendo suporte direto à autenticação e autorização. Ele se integra a provedores de identidade, como o Microsoft Entra ID, que habilita o OAuth 2.0 e fornece autorização baseada em políticas. Além disso, o API Management utiliza identidades geridas para acesso seguro e de baixa manutenção ao OpenAI do Azure.
Combinar cenários para uma solução de gateway abrangente
Em aplicações do mundo real, os seus casos de utilização podem abranger vários cenários deste artigo. Por exemplo, você pode ter aplicativos cliente que se autenticam por meio de um provedor de identidade externo e exigem acesso a várias instâncias do OpenAI do Azure.
Baixe um Arquivo Visio dessa arquitetura.
Para desenvolver um gateway que dê suporte aos seus requisitos específicos, combine as recomendações desses cenários para obter uma abordagem abrangente.
Impor políticas de gateway
Antes de um gateway enviar solicitações para instâncias do OpenAI do Azure, certifique-se de impor políticas de autenticação e autorização de entrada. Para garantir que o gateway apenas encaminhe pedidos autenticados e autorizados, utilize tokens de acesso do utilizador de um fornecedor de identidade ou validação de certificado para implementar esta abordagem.
Para ativar o controle granular, implemente mais escopo de autorização com funções e permissões para aplicativos cliente em seu gateway. Use esses escopos para permitir operações específicas com base nas necessidades do aplicativo cliente. Essa abordagem aumenta a segurança e a capacidade de gerenciamento.
Para validação de tokens de acesso, certifique-se de validar todas as principais declarações registradas, como iss, audexp e nbf e quaisquer declarações relevantes específicas da carga de trabalho, como associações a grupos ou funções de aplicativos.
Usar identidades gerenciadas pelo Azure
Para simplificar a autenticação em todos os cenários de aplicação do cliente, utilize identidades geridas pelo Azure para centralizar a gestão da autenticação. Essa abordagem reduz a complexidade e os riscos associados ao gerenciamento de diversas chaves ou credenciais de API em aplicativos clientes.
As identidades gerenciadas suportam inerentemente o RBAC do Azure, pelo que garantem que o gateway só tem o nível mais baixo de permissões necessárias para aceder às instâncias OpenAI do Azure. Para reduzir o risco de acesso não autorizado e simplificar a conformidade com as políticas de segurança, combine identidades gerenciadas com outros métodos que desabilitem a autenticação alternativa.
Implementar a observabilidade abrangente
Quando implementa um gateway com uma identidade gerida, reduz a rastreabilidade porque a identidade gerida representa o próprio gateway, não o utilizador ou a aplicação que faz o pedido. Portanto, é essencial melhorar a observabilidade das métricas relacionadas às solicitações de API. Para manter a visibilidade sobre os padrões de acesso e uso, os gateways devem fornecer mais metadados de rastreamento, como os IDs do cliente e do usuário solicitantes.
O registro centralizado de todas as solicitações que passam pelo gateway ajuda a manter uma trilha de auditoria. Uma trilha de auditoria centralizada é especialmente importante para solução de problemas, conformidade e detecção de tentativas de acesso não autorizado.
Endereçar o cache com segurança
Se o gateway de API for responsável por armazenar em cache conclusões ou outros resultados de inferência, verifique se a identidade do solicitante é considerada na lógica de cache. Não retorne resultados armazenados em cache para identidades que não estão autorizadas a receber esses dados.
Implementações de gateway
O Azure não fornece uma solução completa ou uma arquitetura de referência para criar o gateway neste artigo, portanto, você deve criar e operar o gateway. O gerenciamento de API do Azure pode ser usado para criar uma solução baseada em PaaS por meio de políticas internas e personalizadas. O Azure também fornece exemplos de implementações com suporte da comunidade que abrangem os casos de uso neste artigo. Consulte esses exemplos ao criar sua própria solução de gateway. Para mais informações, veja o vídeo Aprenda ao vivo: identidade e segurança do aplicativo OpenAI do Azure.
Colaboradores
Os colaboradores a seguir escreveram originalmente este artigo.
Principais autores:
- Lizet Pena De Sola | Brasil | Engenheira de cliente sênior, FastTrack for Azure
- Bappaditya Banerjee | Engenheiro Sênior do Cliente do FastTrack for Azure
- James Croft | Brasil | Engenheiro de clientes, ISV e Centro de Excelência Digital Native
Para ver perfis não públicos no LinkedIn, entre no LinkedIn.
Próximas etapas
- RBAC para o OpenAI do Azure
- Usar identidades gerenciadas no API Management
- Políticas no Gerenciamento de API
- Autenticação e autorização em APIs no Gerenciamento de API
- Proteger uma API no API Management ao usar o OAuth 2.0 e Microsoft Entra ID
- Proteger serviços de back-end usando a autenticação de certificado do cliente no API Management do Azure