Métodos de autenticação suportados pelo Azure OpenAI
O Azure OpenAI dá suporte a vários métodos de autenticação para garantir acesso seguro e controlado aos seus recursos. Os principais métodos são:
- Chaves de API: o Azure OpenAI também dá suporte à autenticação baseada em chave de API. As chaves de API são geradas no portal do Azure e podem ser usadas para autenticar solicitações para o serviço Azure OpenAI. Este método de autenticação não é recomendado do ponto de vista da segurança e só deve ser usado como último recurso. Se você precisar usar esse método de autenticação, é importante manipular chaves de API com segurança e girá-las periodicamente para reduzir o risco de acesso não autorizado.
- Microsoft Entra ID: Este método aproveita os recursos robustos de gerenciamento de identidade e acesso do Microsoft Entra. Os usuários e aplicativos são autenticados usando identidades do Microsoft Entra, que podem ser contas de usuário tradicionais ou identidades gerenciadas. Esse método garante que apenas usuários autenticados e autorizados possam acessar os recursos do Azure OpenAI.
- Identidades gerenciadas do Entra: as identidades gerenciadas para recursos do Azure fornecem uma identidade gerenciada automaticamente no Microsoft Entra para aplicativos usarem ao se conectar a recursos que oferecem suporte à autenticação do Microsoft Entra. Essas identidades podem ser atribuídas ao sistema, o que significa que estão vinculadas a um recurso específico do Azure, ou atribuídas pelo usuário, o que permite que uma única identidade seja compartilhada entre vários recursos. As identidades gerenciadas simplificam o gerenciamento de credenciais e aumentam a segurança, eliminando a necessidade de credenciais codificadas no código do aplicativo.
Por que as identidades gerenciadas são mais seguras do que as chaves de API
As identidades gerenciadas no Microsoft Azure oferecem uma alternativa mais segura às chaves de API por vários motivos:
- As identidades gerenciadas eliminam a necessidade de os desenvolvedores lidarem diretamente com as credenciais, reduzindo assim o risco de exposição acidental ou uso indevido.
- Ao usar chaves de API, os desenvolvedores devem incorporar essas chaves em seu código de aplicativo ou arquivos de configuração.
As chaves de API podem ser expostas inadvertidamente por meio de repositórios de código-fonte, logs ou outros meios. Essa exposição pode levar a acesso não autorizado e possíveis violações de segurança. Por outro lado, as identidades gerenciadas fornecem uma identidade gerenciada automaticamente para os aplicativos usarem ao se conectarem a recursos que dão suporte à autenticação do Microsoft Entra (anteriormente Azure AD). Isso significa que as credenciais não são armazenadas no código do aplicativo, reduzindo o risco de vazamentos e acesso não autorizado.
Além disso, as identidades gerenciadas simplificam o processo de autenticação, permitindo que os serviços do Azure se autentiquem em outros serviços do Azure com segurança sem a necessidade de credenciais explícitas. Isso é conseguido usando tokens emitidos pelo Microsoft Entra, que são gerenciados e alternados automaticamente, garantindo que as credenciais estejam sempre atualizadas e reduzindo o risco de roubo de credenciais. As chaves de API, por outro lado, são estáticas e requerem rotação manual, que pode ser propensa a erros e muitas vezes negligenciada, levando a potenciais vulnerabilidades. Usando identidades gerenciadas, os desenvolvedores podem aproveitar os recursos de segurança internos do Azure, como RBAC (controle de acesso baseado em função), para conceder permissões precisas aos recursos, aumentando ainda mais a segurança.
A Microsoft recomenda que você use a Identidade Gerenciada sobre chaves de API ao autenticar no Azure OpenAI ou em qualquer outro serviço do Azure que ofereça suporte à Identidade Gerenciada.
Diferenças entre usar chaves de API e identidades gerenciadas no Azure OpenAI
Vamos avaliar o impacto de um ID de cliente vazado versus uma chave de API vazada.
Uma chave de API funciona de forma semelhante a uma senha comum. Se estiver comprometido, qualquer pessoa com a chave pode acessar o recurso. Para o Azure OpenAI, isso significa o uso irrestrito de modelos de IA como GPT-4. Se a rede for acessível ao público, o impacto na segurança poderá ser ainda maior.
Por outro lado, se o ID do cliente for vazado, os riscos são mínimos. Isso ocorre porque a ID do cliente sozinha não pode estabelecer uma conexão com o Azure OpenAI. Para utilizar uma Identidade Gerenciada, o serviço deve estar operando no Azure e, mesmo que o Azure OpenAI seja público, você não pode se conectar de um ambiente local ou através de uma rede usando um aplicativo.
Em resumo, em comparação com as ramificações de uma chave de API vazada, explorar um ID de cliente vazado envolve várias etapas, tornando mais difícil para atores mal-intencionados explorarem.
Por esses motivos, as identidades gerenciadas oferecem um método mais seguro para gerenciar operações em comparação com chaves de API. É recomendado, nos termos mais fortes possíveis, que você use a Identidade Gerenciada sobre chaves de API ao autenticar no Azure OpenAI ou em qualquer outro serviço do Azure que ofereça suporte à Identidade Gerenciada.
Sistema versus identidades atribuídas ao usuário
Ao criar um aplicativo OpenAI do Azure, entender a distinção entre identidades atribuídas pelo sistema e pelo usuário é crucial para a segurança ideal e o gerenciamento de recursos.
- As identidades atribuídas ao sistema são criadas e gerenciadas pelo Azure para um recurso específico. Quando um recurso é excluído, sua identidade atribuída ao sistema associada também é excluída, garantindo que o ciclo de vida da identidade seja fortemente acoplado ao recurso ao qual pertence. Esse tipo de identidade é ideal para cenários em que a identidade só precisa ser usada por um único recurso, fornecendo simplicidade e reduzindo a sobrecarga administrativa, já que o Azure gerencia as credenciais da identidade.
- As identidades atribuídas pelo usuário são criadas independentemente de qualquer recurso específico e podem ser compartilhadas entre vários recursos. Isso os torna altamente versáteis para aplicativos que exigem uma identidade consistente em diferentes recursos, permitindo um gerenciamento mais fácil de permissões e controles de acesso. As identidades atribuídas pelo usuário persistem mesmo depois que os recursos que as usam são excluídos, permitindo maior flexibilidade na reimplantação e reutilização de identidades.
A escolha entre identidades atribuídas pelo sistema e pelo usuário depende das necessidades específicas do seu aplicativo. Para aplicativos de recurso único em que a simplicidade e o gerenciamento mínimo são prioridades, as identidades atribuídas ao sistema geralmente são a melhor escolha. Por outro lado, para aplicativos que exigem uma identidade compartilhada entre vários recursos, as identidades atribuídas pelo usuário oferecem maior flexibilidade e reutilização.
