Os aplicativos inteligentes que usam o Serviço OpenAI do Azure por meio de serviços nativos do Azure fornecem autenticação e autorização de usuário perfeitas. No entanto, alguns cenários são complexos e exigem projetos de arquitetura diferentes. Esses cenários incluem topologias que têm aplicativos cliente que não estão hospedados no Azure, usam provedores de identidade externos e implantam vários clientes que acessam as mesmas instâncias do Azure OpenAI. Nesses cenários, a introdução de um gateway na frente do Azure OpenAI pode melhorar significativamente a segurança adicionando uma camada que garante autenticação consistente às 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 Azure OpenAI
Cada cenário descreve os desafios que eles introduzem e os benefícios de incorporar um gateway.
Importante
Você pode usar as diretrizes a seguir para qualquer implementação de gateway, incluindo o Gerenciamento de API do Azure. 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
Transfira um ficheiro do Visio desta arquitetura.
Restrições de cenário
Este 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 são autenticados em um locatário do Microsoft Entra que é diferente do locatário do plano de dados OpenAI do Azure.
Essas restrições podem se aplicar aos seguintes exemplos:
Aplicativos cliente existentes que já se autenticam em um provedor OIDC externo ou Microsoft Entra ID e que se integram a instâncias do Azure OpenAI.
Aplicativos cliente que devem autenticar consistentemente usuários de vários provedores de identidade.
Conecte-se diretamente ao Azure OpenAI
Se os aplicativos cliente nesses cenários se conectarem diretamente ao Azure OpenAI sem usar um gateway, eles deverão usar a autenticação baseada em chave para autenticar no Azure OpenAI. A autenticação baseada em chave introduz preocupações adicionais de segurança. Você deve armazenar e girar chaves com segurança e não pode fornecer a diferentes clientes configurações de controle de acesso baseado em função (RBAC) para implantações de modelos individuais.
Introduzir um gateway
Transfira um ficheiro do Visio desta arquitetura.
Um gateway resolve os desafios desse cenário das seguintes maneiras:
O gateway usa Open Authorization (OAuth) para autenticar usuários por meio de seus provedores de identidade externos existentes. O gateway valida os tokens de acesso de usuário autenticados, como um JSON Web Token (JWT), que o provedor de identidade gera. Em seguida, o gateway concede autorização à instância OpenAI do Azure de suporte.
Você não precisa gerenciar chaves de cliente. Essa abordagem elimina os riscos de segurança da autenticação baseada em chave.
O gateway se conecta ao Azure OpenAI usando uma identidade gerenciada, que melhora a segurança por meio do RBAC do Azure com privilégios mínimos.
Recomendações para este cenário
Adicione mais escopos OAuth ao seu registro de aplicativo em seu provedor de identidade para habilitar a permissão granular aos consumidores. Esses escopos permitem que os aplicativos cliente solicitem permissão para executar operações específicas em seu gateway, incluindo o acesso ao Azure OpenAI.
Configure esse cenário para o Gerenciamento de API usando políticas de entrada. Use a
validate-jwtpolítica para impor a existência, validade e valores de atributo de um JWT suportado.
Razões para evitar um gateway para este cenário
Se um único aplicativo inteligente acessar o Azure OpenAI, será mais fácil configurar a autenticação e a autorização do usuário dentro do aplicativo do que por meio do gateway. Use essa abordagem para atribuir o RBAC do Azure necessário para autenticar com segurança o aplicativo inteligente com o Azure OpenAI.
Autenticar aplicativos cliente por meio de certificados
Transfira um ficheiro do Visio desta arquitetura.
Restrições de cenário
Este cenário tem as seguintes restrições:
Você deseja usar certificados para autenticar aplicativos cliente.
Os aplicativos cliente não podem usar, ou você não deseja usar, o Microsoft Entra ID ou outros provedores OIDC para autenticação.
Os clientes não podem usar, ou você não quer usar, identidade federada para autenticação.
Essas restrições podem se aplicar aos seguintes exemplos:
Um cliente que se autentica no Azure OpenAI é uma máquina ou dispositivo e nenhuma interação do usuário ocorre.
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 a vários aplicativos cliente opções para autenticação com base em seu ambiente, incluindo o uso de certificados de cliente.
Conecte-se diretamente ao Azure OpenAI
O Azure OpenAI não suporta nativamente a 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 uma chave de API ou identidade gerenciada para autenticar solicitações para a instância do Azure OpenAI. Você deve implementar a lógica de autenticação de certificado em cada cliente. Nesse cenário, a autenticação baseada em chave introduz riscos e sobrecarga de gerenciamento se você se conectar diretamente ao Azure OpenAI a partir de clientes.
Introduzir um gateway
Transfira um ficheiro do Visio desta arquitetura.
Você pode introduzir um gateway nessa arquitetura que descarrega a validação de certificação do cliente dos clientes. O gateway valida o certificado digital do cliente que o aplicativo inteligente apresenta e verifica o emissor, a data de validade, a impressão digital e as listas de revogação. O gateway deve usar uma identidade gerenciada para autenticar-se com o Azure OpenAI. O gateway também deve usar o Azure Key Vault para armazenar a autoridade de certificação (CA) raiz. Use essa abordagem para centralizar a validação do certificado do cliente, o que reduz a sobrecarga de manutenção.
Um gateway oferece várias vantagens nesse 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 cliente 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 autoridade de certificação raiz e os certificados intermediários, ao validar certificados. A verificação completa garante a autenticidade do certificado e impede o acesso não autorizado.
Alterne e renove certificados de cliente regularmente para minimizar o risco de comprometimento de certificados. Use o Key Vault para automatizar esse processo e manter os certificados atualizados. Defina alertas para futuras expirações de certificados para evitar interrupções de serviço no gateway.
Implemente mTLS (Transport Layer Security) mútuo para garantir que o cliente e o servidor se autentiquem. Esta estratégia fornece uma camada extra de segurança. Para configurar o gateway para impor mTLS, defina as políticas e restrições apropriadas.
Use a
validate-client-certificatepolítica no Gerenciamento de API para validar certificados de cliente aos quais um cofre de chaves do Azure faz referência. Esta política valida o certificado de cliente que o aplicativo cliente apresenta e verifica o emissor, a data de validade, a impressão digital e as listas de revogação.
Razões para evitar um gateway para este 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 devido às camadas adicionadas e levar à dependência 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.
Autentique vários aplicativos cliente por meio de chaves para acessar uma instância compartilhada do Azure OpenAI
Transfira um ficheiro do Visio desta arquitetura.
Restrições de cenário
Este cenário tem as seguintes restrições:
- Vários aplicativos cliente acessam uma instância compartilhada do Azure OpenAI.
- Os clientes não podem usar, ou você não quer usar, o Microsoft Entra ID para autenticação.
- Os clientes não podem usar, ou você não quer usar, identidade federada para autenticação.
- Você deseja usar a autenticação baseada em chave para aplicativos cliente.
Essas restrições podem se aplicar aos seguintes exemplos:
Você implanta aplicativos cliente em vários ambientes, incluindo Azure, local ou outros provedores de nuvem.
Uma organização precisa fornecer o Azure OpenAI para diferentes equipes e definir limites de acesso e uso exclusivos para cada equipe.
Conecte-se diretamente ao Azure OpenAI
O Azure OpenAI dá suporte à autenticação baseada em chaves por meio de chaves compartilhadas. O Azure OpenAI expõe uma chave primária e uma chave secundária. O objetivo da chave secundária é suportar a rotação de chaves. Ele não fornece isolamento de identidade do cliente. Quando você autentica vários clientes diretamente no Azure OpenAI nesse cenário, cada cliente compartilha a mesma chave. Esta implementação tem os seguintes desafios:
Não é possível revogar permissões para clientes específicos porque todos os clientes compartilham a mesma chave.
Não é possível conceder a clientes diferentes direitos de acesso a modelos diferentes na mesma implantação de instância do Azure OpenAI.
Não é possível diferenciar um cliente de outro do ponto de vista do registro.
Introduzir um gateway
Transfira um ficheiro do Visio desta arquitetura.
Você pode introduzir um gateway nessa arquitetura que emite uma chave dedicada para cada aplicativo cliente. O Gerenciamento de API usa o conceito de assinaturas para fornecer chaves de cliente dedicadas. O gateway deve usar uma identidade gerenciada para autenticar-se com o Azure OpenAI.
Um gateway oferece várias vantagens nesse 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. Você pode girar as chaves dedicadas para cada cliente depois de atualizar a configuração do cliente.
Você pode identificar exclusivamente cada cliente de uma perspetiva de registro.
O gateway impõe limites de taxa 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 gerenciada de um gateway, a rastreabilidade do usuário e do aplicativo cliente nos logs do Azure OpenAI não melhora. O gateway deve fornecer registro associado à solicitação, como os IDs de cliente e usuário solicitante.
Certifique-se de que o gateway tome decisões de roteamento para implantações de modelo apropriadas com base na identidade do cliente quando você rotear várias solicitações de aplicativo cliente por meio de um gateway para uma instância compartilhada do Azure OpenAI. Para obter mais informações, consulte Usar um gateway na frente de várias implantações do Azure OpenAI.
Autenticar aplicativos cliente que acessam várias instâncias do Azure OpenAI
Transfira um ficheiro do Visio desta arquitetura.
Restrições de cenário
Este cenário tem as seguintes restrições:
- Os aplicativos cliente se conectam a várias instâncias do Azure OpenAI em uma ou mais regiões.
- Os clientes não podem usar, ou você não quer usar, o Microsoft Entra ID ou outros provedores OIDC para autenticação.
- Você deseja usar a autenticação baseada em chave para aplicativos cliente.
Essas restrições podem se aplicar 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 uma operação contínua. Assim, 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.
Conecte-se diretamente a várias instâncias do Azure OpenAI
Quando os aplicativos cliente se conectam diretamente a várias instâncias do Azure OpenAI, cada cliente deve armazenar a chave para cada instância. Juntamente com as considerações de segurança do uso de chaves, há uma maior carga de gerenciamento em relação às chaves rotativas.
Introduzir um gateway
Transfira um ficheiro do Visio desta arquitetura.
Quando você usa um gateway para lidar com aplicativos cliente que acessam várias implantações do Azure OpenAI, obtém os mesmos benefícios que um gateway que lida com vários aplicativos cliente por meio de chaves para acessar uma instância compartilhada do Azure OpenAI. 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 Azure OpenAI. Implemente essa abordagem para reduzir a sobrecarga operacional geral e minimizar os riscos de configuração incorreta do cliente quando você trabalha com várias instâncias.
Um exemplo de como um gateway está sendo usado no Azure para descarregar a identidade para um intermediário é o recurso 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 Azure OpenAI para lidar com alto tráfego e garantir alta disponibilidade. Para obter mais informações, consulte Usar um gateway na frente de várias implantações ou instâncias do Azure OpenAI.
Correlacione o uso de token para cada locatário no gateway ao implementar cenários multilocatários com várias instâncias do Azure OpenAI. Essa abordagem garante que você acompanhe o uso total do token, independentemente da instância back-end do Azure OpenAI para a qual a solicitação é encaminhada.
Recomendações gerais
Quando você integra o Azure OpenAI por meio de um gateway, há várias recomendações transversais a serem consideradas que se aplicam a todos os cenários.
Use o Gerenciamento de API do Azure em vez de criar sua própria solução para orquestração de API eficiente, integração perfeita com outros serviços do Azure e economia de custos reduzindo os esforços de desenvolvimento e manutenção. O Gerenciamento de API garante o gerenciamento seguro de APIs, 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 Gerenciamento de API usa identidades gerenciadas para acesso seguro e de baixa manutenção ao Azure OpenAI.
Combine cenários para uma solução de gateway abrangente
Em aplicativos do mundo real, seus casos de uso 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 Azure OpenAI.
Transfira um ficheiro do Visio desta arquitetura.
Para criar um gateway que ofereça suporte aos seus requisitos específicos, combine as recomendações desses cenários para uma abordagem abrangente.
Impor políticas de gateway
Antes de um gateway enviar solicitações para instâncias do Azure OpenAI, certifique-se de aplicar políticas de autenticação e autorização de entrada. Para garantir que o gateway encaminhe apenas solicitações autenticadas e autorizadas, use tokens de acesso de usuário de um provedor de identidade ou validação de certificado para implementar essa abordagem.
Para habilitar 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 token de acesso, certifique-se de validar todas as principais declarações registradas, como iss, aud, expe nbf quaisquer declarações relevantes específicas da carga de trabalho, como associações de grupo ou funções de aplicativo.
Usar identidades gerenciadas do Azure
Para simplificar a autenticação em todos os cenários de aplicativo cliente, use as identidades gerenciadas do Azure para centralizar o gerenciamento de autenticação. Essa abordagem reduz a complexidade e os riscos associados ao gerenciamento de várias chaves de API ou credenciais em aplicativos cliente.
As identidades gerenciadas suportam inerentemente o RBAC do Azure, portanto, garantem que o gateway tenha apenas o nível mais baixo de permissões necessárias para acessar instâncias do Azure OpenAI. 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 desativem a autenticação alternativa.
Implementar observabilidade abrangente
Quando você implementa um gateway com uma identidade gerenciada, isso reduz a rastreabilidade porque a identidade gerenciada representa o gateway em si, não o usuário ou o aplicativo que faz a solicitação. Portanto, é essencial melhorar a observabilidade em métricas relacionadas a solicitações de API. Para manter a visibilidade sobre padrões de acesso e uso, os gateways devem fornecer mais metadados de rastreamento, como os IDs de cliente e usuário solicitante.
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 deteção de tentativas de acesso não autorizado.
Cache de endereços com segurança
Se o gateway de API for responsável por concluir o cache ou outros resultados de inferência, verifique se a identidade do solicitante é considerada na lógica do 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 turnkey ou 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 suportadas pela comunidade que abrangem os casos de uso neste artigo. Faça referência a esses exemplos ao criar sua própria solução de gateway. Para obter mais informações, consulte o vídeo Learn Live: Azure OpenAI application identity and security.
Contribuidores
Os seguintes colaboradores escreveram originalmente este artigo.
Principais autores:
- Lizet Pena De Sola - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
- Bappaditya Banerjee - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
- James Croft - Brasil | Engenheiro de Clientes, ISV & Digital Native Center of Excellence
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- RBAC para Azure OpenAI
- Usar identidades gerenciadas no Gerenciamento de API
- Políticas no Gerenciamento de API
- Autenticação e autorização para APIs no Gerenciamento de API
- Proteger uma API no Gerenciamento de API usando o OAuth 2.0 e o Microsoft Entra ID
- Proteja os serviços de back-end usando a autenticação de certificado de cliente no Gerenciamento de API