Forneça autenticação alternativa aos serviços OpenAI do Azure por um gateway

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

Este artigo explora os seguintes cenários principais 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 OpenAI do Azure
• Aplicativos cliente acessando diversas instâncias do OpenAI do Azure

Cada cenário descreve os desafios apresentados, e os benefícios apresentados pela inclusão de um gateway.

Aplicativos cliente autenticados com um provedor de identidade externo

Restrições do cenário

A seguir, veja as restrições deste 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 estão se autenticando em um locatário diferente do Microsoft Entra do locatário do plano de dados do OpenAI do Azure.

Essas restrições podem ser aplicadas a cenários nos quais:

• 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 OpenAI do Azure.
• Os aplicativos cliente precisam autenticar usuários de vários provedores de identidade de maneira consistente.

Conectando-se diretamente ao OpenAI do Azure

Se os aplicativos cliente nesses cenários estiverem se conectando diretamente ao OpenAI do Azure (não usando um gateway), eles deverão usar a autenticação com base em chaves para autenticar no OpenAI do Azure. A autenticação com base em chaves introduz preocupações de segurança adicionais, como o armazenamento seguro das chaves, a rotatividade das chaves e a incapacidade de fornecer a diversos clientes suas próprias configurações de controle de acesso com base em função (RBAC) para implantações de modelo individuais.

Introdução a 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ários autenticados, como um Token Web JSON (JWT), gerados pelo provedor de identidade antes de conceder autorização para a instância de suporte do OpenAI do Azure.
• O gerenciamento de chaves para clientes não é mais necessário, e os riscos de segurança associados ao uso da autenticação com base em chaves desapareceram.
• O gateway pode se conectar ao OpenAI do Azure usando uma identidade gerenciada, melhorando a segurança usando o RBAC do Azure com privilégios mínimos.

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

• Mais escopos OAuth podem ser adicionados ao 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 acesso ao OpenAI do Azure.
• Você pode configurar esse cenário para o Azure API Management usando políticas de entrada. Use a política validate-jwt 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 você tiver um único aplicativo inteligente acessando o OpenAI do Azure, poderá ser mais fácil configurar a autenticação e a autorização do usuário no aplicativo em vez do gateway. Você pode atribuir o RBAC do Azure necessário para autenticar com segurança o aplicativo inteligente com o OpenAI do Azure usando essa abordagem.

Aplicativos cliente autenticados com certificados

Restrições do cenário

A seguir, veja as restrições deste cenário:

• 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 qualquer provedor OIDC para autenticação.
• Os clientes não podem usar ou você não deseja usar a identidade federada para autenticação.

Essas restrições podem ser aplicadas a cenários nos quais:

• Um cliente que se autentica nos serviços do OpenAI do Azure é uma máquina ou um dispositivo em que 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 vários aplicativos cliente com opções para autenticação com base no ambiente, incluindo o uso de certificados de cliente.

Conectando-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 se limitaria 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 OpenAI do Azure. 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 com base em chave seriam aplicáveis se você se conectasse diretamente ao OpenAI do Azure de clientes nesse cenário.

Introdução a 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 emissores, expiração, impressão digital e revogação. O gateway deve usar a identidade gerenciada para se autenticar com o OpenAI do Azure. O gateway deve usar o Cofre de Chaves 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, reduzindo a sobrecarga de manutenção.

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

• O uso da 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.
• Transferir a 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 CA raiz e os certificados intermediários. A verificação completa garante a autenticidade do certificado e evita o acesso não autorizado.
• Faça uma rotatividade e renove regularmente os certificados do cliente para minimizar o risco de comprometimento do certificado. Automatize esse processo usando o Cofre de Chaves do Azure para garantir que os certificados estejam sempre atualizados. A configuração de alertas para expirações futuras de certificados também evita a interrupção do serviço no gateway.
• Implemente um TLS mútuo (mTLS) para garantir que o cliente e o servidor se autentiquem, fornecendo uma camada adicional de segurança. Configure o gateway para impor o mTLS definindo as devidas políticas e restrições.
• Usando o Azure API Management, você pode usar a política validate-client-certificate para validar certificados de cliente mencionados em um cofre de chaves do Azure. Essa política valida o certificado do cliente apresentado pelo aplicativo cliente 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 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 a camadas adicionais e levar ao bloqueio 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 OpenAI do Azure

Restrições do cenário

A seguir, veja as restrições deste cenário:

• Vários aplicativos cliente estão acessando 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.

Essas restrições podem ser aplicadas a cenários nos quais:

• 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 OpenAI do Azure para equipes diferentes, cada uma com limites exclusivos de acesso e uso.

Conectando-se diretamente ao OpenAI do Azure

O OpenAI do Azure dá suporte à autenticação com base em chaves usando chaves compartilhadas. Embora o OpenAI do Azure exponha uma chave primária e uma chave secundária, o objetivo da chave secundária é dar suporte à rotatividade de chaves, não ao 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. Veja a seguir os desafios dessa implementação:

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

Introdução a um gateway

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

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.
• A rotatividade de chaves torna-se menos desafiadora logisticamente porque você não precisa atualizar todas as configurações de chave do cliente antes de fazer a rotatividade delas. Pode ser feita a rotatividade das chaves dedicadas para cada cliente depois que a configuração do cliente é atualizada.
• Cada cliente pode ser identificado exclusivamente a partir de uma perspectiva de log.
• 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 OpenAI do Azure, aprimore o monitoramento de métricas relacionadas a solicitações de API. O gateway deve fornecer o log associado à solicitação, como os IDs de cliente e usuário solicitantes.
• Ao rotear várias solicitações de aplicativo cliente por meio de um gateway para um serviço OpenAI do Azure compartilhado, 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 OpenAI do Azure, consulte Usar um gateway na frente de várias implantações do OpenAI do Azure.

Aplicativos cliente acessando diversas instâncias do OpenAI do Azure

Restrições do cenário

A seguir, veja as restrições deste cenário:

• Os aplicativos cliente estão se conectando 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 qualquer provedor OIDC para autenticação.
• Você deseja usar a autenticação com base em chaves para aplicativos cliente.

Essas restrições podem ser aplicadas a cenários nos quais:

• 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, consistindo potencialmente em uma implantação de taxa de transferência provisionada e uma implantação de pagamento 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.

Como se conectar diretamente a várias instâncias do OpenAI do Azure

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 carga de gerenciamento maior em relação à rotatividade de chaves.

Introdução a um gateway

A introdução de um gateway para manipular aplicativos cliente que acessam várias implantações do OpenAI do Azure tem os mesmos benefícios abordados pela introdução de um gateway para manipular vários aplicativos cliente usando chaves para acessar uma instância compartilhada do OpenAI do Azure. Além desses motivos, usando uma única identidade gerenciada definida pelo usuário para autenticar solicitações do gateway para várias instâncias do OpenAI do Azure, 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 OpenAI do Azure para lidar com o alto tráfego e garantir alta disponibilidade. Para obter mais informações sobre essa implementação, consulte Usar um gateway na frente de várias implantações ou instâncias do OpenAI do Azure.
• Quando você está implementando cenários de diversos locatários usando várias instâncias do OpenAI do Azure, o uso de tokens de controle para um locatário específico deve ser correlacionado no gateway. A correlação do uso de tokens no gateway garante que você esteja rastreando o uso total de tokens, independentemente da instância de back-end do OpenAI do Azure para a qual a solicitação é encaminhada.

Recomendações gerais

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

Optar pelo Azure API Management (APIM) em vez de criar sua própria solução tem vários benefícios. Ele fornece orquestração de API eficiente, fácil integração 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 API, 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, além de oferecer autorização com base em políticas. Além disso, ele pode aproveitar as identidades gerenciadas para acesso seguro e de baixa manutenção ao OpenAI do Azure.

Como combinar 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 OpenAI do Azure.

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

Imposição de política de gateway

Antes que as solicitações para instâncias do OpenAI do Azure sejam enviadas por meio de um gateway, as políticas de autenticação e autorização de entrada devem ser impostas. 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 o controle granular. Esses escopos permitem que sejam permitidas operações específicas com base nas necessidades do aplicativo cliente, aumentando 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, 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 pelo 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 de API ou credenciais em aplicativos cliente.

Como as identidades gerenciadas dão suporte inerentemente ao controle de acesso com base 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 OpenAI do Azure. 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 a 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 nem 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 as IDs de cliente e usuário solicitantes, para manter a visibilidade sobre os 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 autorizadas possam ser detectadas.

Implementações de gateway

O Azure não oferece uma solução pronta para uso nem uma arquitetura de referência para criar esse gateway. Conforme mencionado no artigo de introdução, você deve criar e operar esse gateway. A seguir, alguns exemplos de implementações suportadas pela comunidade que abrangem os casos de uso mencionados anteriormente. Considere consultar esses exemplos ao criar sua própria solução de gateway.

Próximas etapas

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 adicionais que um gateway pode resolver.

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.

Recursos relacionados

• Controle de acesso baseado em função para o OpenAI do Azure
• Usar identidades gerenciadas no Gerenciamento de API do Azure
• Políticas no Gerenciamento de API do Azure
• Autenticação e autorização em APIs no Gerenciamento de API do Azure
• Proteger uma API no API Management usando o OAuth 2.0 e Microsoft Entra ID
• Proteger o back-end de Gerenciamento de API usando a autenticação de certificado do cliente