Métodos de autenticação com suporte pelo OpenAI do Azure
O OpenAI do Azure dá suporte para 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 OpenAI do Azure 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 ao serviço OpenAI do Azure. Esse método de autenticação não é recomendado do ponto de vista de segurança e deve ser usado apenas como último recurso. Se você precisar usar esse método de autenticação, é importante manusear as chaves de API com segurança e girá-las periodicamente para reduzir o risco de acesso não autorizado.
- Microsoft Entra ID: Esse método aproveita as robustas funcionalidades de gerenciamento de identidade e acesso do Microsoft Entra. Usuários e aplicativos se autenticam 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 OpenAI do Azure.
- Identidades Gerenciadas do Entra: Identidades gerenciadas para recursos do Azure fornecem uma identidade gerenciada automaticamente no Microsoft Entra para aplicativos usarem ao conectar-se a recursos que dão suporte à autenticação do Microsoft Entra. Essas identidades podem ser atribuídas pelo 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 aprimoram a segurança ao eliminar a necessidade de credenciais embutidas em código 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 manusearem credenciais diretamente, reduzindo assim o risco de exposição ou uso indevido acidental.
- Ao usar chaves de API, os desenvolvedores devem inserir essas chaves no código do aplicativo ou nos 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. Em contraste, as identidades gerenciadas fornecem uma identidade gerenciada automaticamente para aplicativos usarem ao conectar-se 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 é alcançado usando tokens emitidos pelo Microsoft Entra, que são gerenciados e girados 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, o que pode ser propenso a erros e muitas vezes negligenciado, levando a possíveis vulnerabilidades. Ao usar identidades gerenciadas, os desenvolvedores podem aproveitar os recursos de segurança internos do Azure, como o controle de acesso baseado em função (RBAC), para conceder permissões precisas aos recursos, aprimorando ainda mais a segurança.
A Microsoft recomenda que você use Identidade Gerenciada em vez de chaves de API ao autenticar no OpenAI do Azure ou em qualquer outro serviço do Azure que dê suporte à Identidade Gerenciada.
Diferenças entre o uso de chaves de API e identidades gerenciadas no OpenAI do Azure
Vamos avaliar o impacto de uma ID de cliente vazada versus uma chave de API vazada.
Uma chave de API funciona de maneira semelhante a uma senha regular. Se for comprometida, qualquer pessoa com a chave poderá acessar o recurso. Para o OpenAI do Azure, isso significa uso irrestrito de modelos de IA como o GPT-4. Se a rede for acessível publicamente, o impacto na segurança poderá ser ainda maior.
Por outro lado, se a ID do cliente for vazada, os riscos são mínimos. Isso ocorre porque a ID do cliente sozinha não pode estabelecer uma conexão com o OpenAI do Azure. Para usar uma Identidade Gerenciada, o serviço deve estar operando no Azure e, mesmo que o OpenAI do Azure 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 uma ID de cliente vazada envolve várias etapas, tornando a exploração mais difícil para agentes mal-intencionados.
Por esses motivos, as Identidades Gerenciadas oferecem um método mais seguro para gerenciar operações em comparação com as chaves de API. É altamente recomendável que você use Identidade Gerenciada em vez de chaves de API ao autenticar no OpenAI do Azure ou em qualquer outro serviço do Azure que dê suporte à Identidade Gerenciada.
Identidades atribuídas pelo sistema versus pelo 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 segurança e gerenciamento de recursos ideais.
- Identidades atribuídas pelo sistema são criadas e gerenciadas pelo Azure para um recurso específico. Quando um recurso é excluído, sua identidade atribuída pelo sistema associada também é excluída, garantindo que o ciclo de vida da identidade esteja intimamente ligado 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, proporcionando simplicidade e reduzindo a sobrecarga administrativa, já que o Azure gerencia as credenciais da identidade.
- 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. Identidades atribuídas pelo usuário persistem mesmo após os recursos que as utilizam serem excluídos, permitindo maior flexibilidade na reimplantação e reutilização de identidades.
Escolher 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 gestão mínima são prioridades, identidades atribuídas pelo sistema são geralmente a melhor escolha. Por outro lado, para aplicativos que exigem uma identidade compartilhada em vários recursos, identidades atribuídas pelo usuário oferecem maior flexibilidade e reutilização.
