Fornecer autenticação alternativa aos serviços do Azure OpenAI por meio de um gateway

Os aplicativos inteligentes que usam os serviços OpenAI do Azure por meio de serviços do Azure nativos da plataforma oferecem uma abordagem de autenticação e autorização de usuário perfeita. No entanto, existem vários cenários que apresentam complexidades que exigem diferentes projetos de arquitetura. Esses cenários incluem topologias com aplicativos cliente hospedados que não são do Azure, o uso de provedores de identidade externos e a implantação de 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 fornecer melhorias significativas de segurança adicionando uma camada que garante consistência na autenticação para instâncias implantadas.

Este artigo explora os seguintes cenários-chave ao autenticar com os serviços OpenAI do Azure.

• Aplicativos cliente autenticados com um provedor de identidade externo
• Aplicativos cliente autenticados com certificados
• Vários aplicativos cliente acessando uma instância compartilhada do Azure OpenAI
• Aplicativos cliente acessando várias instâncias do Azure OpenAI

Cada cenário descreve os desafios que eles introduzem e os benefícios introduzidos pela inclusão de um gateway.

Aplicativos cliente autenticados com um provedor de identidade externo

Restrições de cenário

A seguir estão as restrições nesse cenário:

• Os aplicativos cliente estão usando 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 diferente do locatário do plano de dados OpenAI do Azure.

Estas restrições podem aplicar-se a cenários em que:

• Os aplicativos cliente existentes que já se autenticam em um provedor OIDC externo ou no Microsoft Entra ID estão se integrando às instâncias do Azure OpenAI.
• Os aplicativos cliente precisam autenticar usuários de vários provedores de identidade de maneira consistente.

Conectando-se diretamente ao Azure OpenAI

Se os aplicativos cliente nesses cenários estiverem se conectando diretamente ao Azure OpenAI (não usando um gateway), eles deverão usar a autenticação baseada em chave para autenticar no Azure OpenAI. A autenticação baseada em chaves introduz preocupações adicionais de segurança, como armazenar as chaves com segurança, girá-las e a incapacidade de fornecer a diferentes clientes suas próprias configurações de controle de acesso baseado em função (RBAC) para implantações de modelos individuais.

Apresentando um gateway

A introdução de um gateway aborda os desafios desse cenário de várias maneiras:

• O gateway pode usar o OAuth para autenticar usuários usando seus provedores de identidade externos existentes. O gateway valida os tokens de acesso de usuário autenticados, como um JSON Web Token (JWT), gerados pelo provedor de identidade antes de conceder autorização à instância OpenAI do Azure de suporte.
• O gerenciamento de chaves para clientes não é mais necessário e os riscos de segurança associados ao uso da autenticação baseada em chaves desapareceram.
• O gateway pode se conectar ao Azure OpenAI usando uma identidade gerenciada, melhorando a segurança usando o Azure RBAC menos privilegiado.

Recomendações e orientações para este cenário

• Mais escopos OAuth podem ser adicionados 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.
• Você pode configurar esse cenário para o Gerenciamento de API do Azure usando políticas de entrada. Use a política validate-jwt para impor os valores de existência, validade e atributo de um JWT suportado.

Razões para evitar um gateway para este cenário

Se você tiver um único aplicativo inteligente acessando o Azure OpenAI, pode ser mais fácil configurar a autenticação e a autorização do usuário dentro do aplicativo em comparação com o gateway. Você pode atribuir o RBAC do Azure necessário para autenticar com segurança o aplicativo inteligente com o Azure OpenAI usando essa abordagem.

Aplicativos cliente autenticados com certificados

Restrições de cenário

A seguir estão as restrições nesse cenário:

• 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 qualquer 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 podem aplicar-se a cenários em que:

• Um cliente que se autentica nos serviços do Azure OpenAI é uma máquina ou dispositivo onde não há interação do usuário.
• Sua organização exige o uso de 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.

Conectando-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 seria limitado a 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 Azure OpenAI. A lógica de autenticação do certificado teria que ser implementada em cada cliente. Os riscos e a sobrecarga de gerenciamento do uso da autenticação baseada em chave se aplicariam se você se conectasse diretamente ao Azure OpenAI a partir de clientes nesse cenário.

Apresentando um gateway

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 apresentado pelo aplicativo inteligente e verificar as listas de emissor, expiração, impressão digital e revogação. O gateway deve usar a identidade gerenciada para autenticar-se com o Azure OpenAI. O gateway deve usar o Cofre da Chave do Azure para armazenar a autoridade de certificação (CA) raiz para garantir que a validação do certificado do cliente seja gerenciada em um local centralizado, o que reduz a sobrecarga de manutenção.

Há várias vantagens em introduzir um gateway para lidar com esse cenário, incluindo:

• Usar a identidade gerenciada do gateway versus chaves de acesso elimina o risco de roubo de chaves e reduz a carga de manutenção de chaves rotativas.
• A centralização da validação de certificados garante que você esteja usando políticas de segurança consistentes para avaliar certificados digitais de cliente para todos os aplicativos inteligentes.
• O descarregamento da validação do certificado para o gateway pode simplificar o código do cliente.

Recomendações e orientações para este cenário

• Ao validar certificados, verifique toda a cadeia de certificados, incluindo a autoridade de certificação raiz e os certificados intermediários. A verificação completa garante a autenticidade do certificado e impede o acesso não autorizado.
• Alterne e renove regularmente certificados de cliente para minimizar o risco de comprometimento de certificados. Automatize esse processo usando o Azure Key Vault para garantir que os certificados estejam sempre atualizados. A configuração de alertas para futuras expirações de certificados também evita a interrupção do serviço no gateway.
• Implemente TLS mútuo (mTLS) para garantir que cliente e servidor se autentiquem, fornecendo uma camada extra de segurança. Configure o gateway para impor mTLS definindo políticas e restrições apropriadas.
• Usando o Gerenciamento de API do Azure, você pode usar a política validate-client-certificate para validar certificados de cliente, referenciados em um cofre de chaves do Azure. Esta política valida o certificado de cliente apresentado pelo aplicativo cliente e verifica as listas de emissor, expiração, impressão digital e revogação.

Razões para evitar um gateway para este cenário

Em ambientes simples com 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ê optar por 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 decidir implementar um gateway para autenticação de certificado de cliente.

Vários aplicativos cliente usando chaves para acessar uma instância compartilhada do Azure OpenAI

Restrições de cenário

A seguir estão as restrições nesse cenário:

• Vários aplicativos cliente estão acessando uma instância compartilhada do Azure OpenAI.
• 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 baseada em chave para aplicativos cliente.

Estas restrições podem aplicar-se a cenários em que:

• Os aplicativos cliente são implantados em vários ambientes, incluindo o Azure, outros provedores de nuvem ou locais.
• As organizações precisam fornecer serviços do Azure OpenAI para equipes diferentes, cada uma com limites de acesso e uso exclusivos.

Conectando-se diretamente ao Azure OpenAI

O Azure OpenAI dá suporte à autenticação baseada em chaves usando chaves compartilhadas. Embora o Azure OpenAI exponha uma chave primária e uma chave secundária, o objetivo da chave secundária é dar suporte à rotação de chaves e não ao isolamento de identidade do cliente. Quando você autentica vários clientes diretamente no Azure OpenAI nesse cenário, cada cliente compartilha a mesma chave. Os seguintes são os desafios com esta implementação:

• Você não tem a capacidade de revogar permissões para clientes específicos porque todos os clientes estão compartilhando 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.

Apresentando um gateway

Você pode introduzir um gateway nessa arquitetura que emite uma chave dedicada para cada aplicativo cliente. O Gerenciamento de API do Azure usa o conceito de assinaturas para fornecer chaves de cliente dedicadas. O gateway deve usar a identidade gerenciada para autenticar-se com o Azure OpenAI.

Há várias vantagens em introduzir um gateway para lidar com esse cenário, incluindo:

• Você pode revogar o acesso a um único aplicativo cliente sem afetar outros clientes.
• Girar chaves torna-se menos desafiador logisticamente porque você não precisa atualizar todas as configurações de chave dos clientes antes de girá-las. As chaves dedicadas podem ser giradas para cada cliente após a atualização da configuração do cliente.
• Cada cliente pode ser identificado exclusivamente a partir de uma perspetiva de registro.
• O gateway torna-se responsável por impor limites de taxa e cotas para cada cliente de forma independente.

Recomendações e orientações para este cenário

• Como o uso de uma identidade gerenciada de um gateway não melhora a rastreabilidade do usuário final e do aplicativo cliente nos logs do Azure OpenAI, aprimore o monitoramento em métricas relacionadas a solicitações de API. O gateway deve fornecer registro associado à solicitação, como os IDs de cliente e usuário solicitante.
• Ao rotear várias solicitações de aplicativo cliente por meio de um gateway para um serviço compartilhado do Azure OpenAI, verifique se o gateway está tomando decisões de roteamento com base na identidade do cliente para implantações de modelo apropriadas. Para obter mais práticas recomendadas em implementações de gateway para várias implantações do Azure OpenAI, consulte Usando um gateway na frente de várias implantações do Azure OpenAI.

Aplicativos cliente acessando várias instâncias do Azure OpenAI

Restrições de cenário

A seguir estão as restrições nesse cenário:

• Os aplicativos cliente estão se conectando a várias instâncias do Azure OpenAI em uma ou mais regiões.
• Os clientes não podem usar ou você não deseja usar o Microsoft Entra ID ou qualquer provedor OIDC para autenticação.
• Você deseja usar a autenticação baseada em chave para aplicativos cliente.

Estas restrições podem aplicar-se a cenários em que:

• Os aplicativos cliente precisam 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 (TPM) implantando instâncias em várias regiões.
• As organizações precisam de recursos contínuos de failover e recuperação de desastres para garantir a operação contínua gerenciando uma estratégia de implantação dupla, potencialmente consistindo em uma implantação de taxa de transferência provisionada e uma implantação paga conforme o uso.
• Os aplicativos cliente precisam usar recursos de modelo específicos que só estão disponíveis em determinadas regiões do Azure.

Conectando-se diretamente a várias instâncias do Azure OpenAI

Quando os aplicativos cliente se conectam diretamente a várias instâncias do 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.

Apresentando um gateway

A introdução de um gateway para lidar com aplicativos cliente que acessam várias implantações do Azure OpenAI tem os mesmos benefícios cobertos pela introdução de um gateway para lidar com vários aplicativos cliente usando chaves para acessar uma instância compartilhada do Azure OpenAI. Além desses motivos, ao usar uma única identidade gerenciada definida pelo usuário para autenticar solicitações do gateway para várias instâncias do Azure OpenAI, o processo de autenticação é simplificado. A implementação dessa abordagem reduz a sobrecarga operacional geral e minimiza os riscos de configuração incorreta do cliente ao trabalhar com várias instâncias.

Recomendações e orientaçõ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 serviço Azure OpenAI para lidar com alto tráfego e garantir alta disponibilidade. Para obter mais informações sobre essa implementação, consulte Usando um gateway na frente de várias implantações ou instâncias do Azure OpenAI.
• Quando você estiver implementando cenários multilocatários usando várias instâncias do Azure OpenAI, o rastreamento do uso do token para um locatário específico deve ser correlacionado no gateway. A correlação do uso de token no gateway garante que você esteja rastreando o uso total do token, independentemente da instância de back-end do Azure OpenAI para a qual a solicitação é encaminhada.

Recomendações gerais

Quando você integra os serviços do Azure OpenAI por meio de um gateway, há várias recomendações transversais a serem consideradas que se aplicam a todos os cenários.

Optar pelo Gerenciamento de API do Azure (APIM) em vez de criar sua própria solução tem vários benefícios. Ele fornece orquestração de API eficiente, integração fácil com outros serviços do Azure e economia de custos reduzindo os esforços de desenvolvimento e manutenção. O APIM fornece gerenciamento seguro de APIs, oferecendo suporte direto à autenticação e autorização. Ele se integra a provedores de identidade, como o Microsoft Entra ID, habilitando o OAuth 2.0 e oferece autorização baseada em políticas. Além disso, ele pode tirar proveito de identidades gerenciadas para acesso seguro e de baixa manutenção ao Azure OpenAI.

Combinando cenários para uma solução de gateway abrangente

Na prática, seus casos de uso podem abranger vários cenários descritos neste guia. Por exemplo, você pode ter aplicativos cliente que se autenticam com um provedor de identidade externo e exigem acesso a várias instâncias do Azure OpenAI.

A combinação das recomendações desses cenários fornece uma abordagem abrangente para criar um gateway que ofereça suporte aos seus requisitos específicos.

Aplicação da política de gateway

Antes que as solicitações para instâncias do Azure OpenAI sejam enviadas por meio de um gateway, as políticas de autenticação e autorização de entrada devem ser aplicadas. Seja por tokens de acesso de usuário de um provedor de identidade ou validação de certificado, a implementação dessa abordagem garante que apenas solicitações autenticadas e autorizadas sejam encaminhadas.

A implementação de mais escopo de autorização com funções e permissões para aplicativos cliente em seu gateway também permite um controle granular. Esses escopos permitem que operações específicas sejam permitidas com base nas necessidades do aplicativo cliente, aumentando 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 além de quaisquer declarações específicas de carga de trabalho relevantes, como associações de grupo ou funções de aplicativo.

Usar identidades gerenciadas do Azure

O uso de identidades gerenciadas do Azure simplifica a autenticação em todos os cenários de aplicativo cliente centralizando o gerenciamento de autenticação. Essa abordagem reduz a complexidade e os riscos associados ao gerenciamento de várias chaves ou credenciais de API em aplicativos cliente.

Como as identidades gerenciadas suportam inerentemente o controle de acesso baseado em função do Azure, elas garantem que o gateway tenha apenas o nível mais baixo de permissão necessário para acessar instâncias do Azure OpenAI. Combinadas com a desativação de métodos de autenticação alternativos, as identidades gerenciadas reduzem o risco de acesso não autorizado e simplificam a conformidade com as políticas de segurança.

Implementar observabilidade abrangente

Quando você implementa um gateway com identidade gerenciada, a rastreabilidade pode ser reduzida, pois uma identidade gerenciada representa o gateway, não o usuário final ou o aplicativo que fez a solicitação. Portanto, é essencial melhorar a observabilidade em métricas relacionadas a solicitações de API. Os gateways devem fornecer mais metadados de rastreamento, incluindo os IDs de cliente e usuário solicitantes, para manter a visibilidade sobre padrões de acesso e uso.

O registro centralizado de todas as solicitações que passam pelo gateway também ajuda na manutenção de uma trilha de auditoria. Uma trilha de auditoria centralizada é especialmente importante para solução de problemas, conformidade e garantia de que tentativas de acesso não autorizado possam ser detetadas.

Implementações de gateway

O Azure não oferece uma solução turn-key ou arquitetura de referência para criar esse gateway. Como mencionado no artigo de introdução, você deve criar e operar esse gateway. A seguir estão exemplos de implementações suportadas pela comunidade que abrangem os casos de uso mencionados anteriormente. Considere fazer referência a esses exemplos ao criar sua própria solução de gateway.

Próximos passos

A implementação de um gateway para sua carga de trabalho oferece benefícios além dos cenários para melhorar a autenticação e a autorização detalhados neste artigo. Saiba mais sobre os outros principais desafios que um gateway pode resolver.

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.

Recursos relacionados

• Controle de acesso baseado em função para o Azure OpenAI
• Usar identidades gerenciadas no Gerenciamento de API do Azure
• Políticas na Gestão de API do Azure
• Autenticação e autorização às APIs na Gestão de API do Azure
• Proteja uma API no Gerenciamento de API usando OAuth 2.0 e Microsoft Entra ID
• Back-end de gerenciamento de API segura usando autenticação de certificado de cliente