Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A ID do Microsoft Entra, quando usada com o Azure Key Vault, fornece uma abordagem robusta e segura para autenticar aplicativos para serviços do Azure e plataformas de terceiros que exigem chaves de acesso ou credenciais. Essa combinação elimina a necessidade de codificar segredos no código do aplicativo, dependendo de identidades gerenciadas, RBAC (controle de acesso baseado em função) e gerenciamento centralizado de segredos por meio do Key Vault. Essa abordagem simplifica o gerenciamento de identidades e aprimora a postura de segurança em ambientes de nuvem.
Este passo a passo explora esses mecanismos de autenticação por meio de um exemplo prático fornecido no repositório GitHub: github.com/Azure-Samples/python-integrated-authentication.
O exemplo demonstra como um aplicativo Python pode:
Autenticar com o Azure usando DefaultAzureCredential
Acessar segredos do Azure Key Vault sem armazenar credenciais
Comunicar-se com segurança com outros serviços do Azure, como Armazenamento do Azure, Cosmos DB e muito mais
Este artigo faz parte de uma série que fornece um passo a passo detalhado de como autenticar um aplicativo Python com a ID do Microsoft Entra, o Azure Key Vault e o Armazenamento de Filas do Azure usando a biblioteca do SDK azure-identity do Python do Azure.
Parte 1: Plano de fundo
Embora muitos serviços do Azure dependam exclusivamente do RBAC (controle de acesso baseado em função), enquanto outros exigem acesso por meio de segredos ou chaves. Esses serviços incluem Azure Storage, bancos de dados, Foundry Tools, Key Vault e Event Hubs.
Ao criar aplicativos de nuvem que interagem com esses serviços, os desenvolvedores podem usar o portal do Azure, a CLI ou o PowerShell para gerar e configurar chaves de acesso específicas do serviço. Essas chaves estão vinculadas a políticas de acesso específicas para impedir o acesso não autorizado. No entanto, esse modelo exige que seu aplicativo gerencie as chaves explicitamente e autentique-se separadamente com cada serviço, um processo entediante e propenso a erros.
Inserir segredos diretamente no código ou armazená-los em computadores desenvolvedores corre o risco de expô-los em:
- Controle do código-fonte
- Ambientes locais inseguros
- Logs acidentais ou exportações de configuração
O Azure oferece dois serviços-chave para melhorar a segurança e simplificar a autenticação:
- Azure Key Vault O Azure Key Vault fornece um repositório seguro baseado em nuvem para segredos, incluindo chaves de acesso, cadeias de conexão e certificados. Ao recuperar segredos do Key Vault somente em runtime, os aplicativos evitam expor dados confidenciais em arquivos de código-fonte ou de configuração.
- Com as identidades gerenciadas do Microsoft Entra, seu aplicativo pode se autenticar uma vez com a ID do Microsoft Entra. A partir daí, ele pode acessar outros serviços do Azure, incluindo o Key Vault, sem gerenciar credenciais diretamente.
Essa abordagem fornece:
- Código sem credenciais (sem segredos no controle do código-fonte)
- Integração perfeita com os serviços do Azure
- Consistência do ambiente: o mesmo código é executado localmente e na nuvem com configuração mínima
Este passo a passo mostra como usar a identidade gerenciada do Microsoft Entra e o Key Vault juntos no mesmo aplicativo. Usando a ID do Microsoft Entra e o Key Vault juntos, seu aplicativo nunca precisa se autenticar com serviços individuais do Azure e pode acessar com facilidade e segurança todas as chaves necessárias para serviços de terceiros.
Importante
Este artigo usa o termo genérico comum "key" para se referir ao que são armazenados como "segredos" no Azure Key Vault, como uma chave de acesso para uma API REST. Esse uso não deve ser confundido com o gerenciamento de chaves criptográficas do Key Vault, que é um recurso separado dos segredos do Key Vault.
Exemplo de cenário de aplicativo de nuvem
Para entender mais profundamente o processo de autenticação do Azure, considere o seguinte cenário: um aplicativo Web Flask é implantado no Serviço de Aplicativo do Azure. Ele expõe um ponto de extremidade de API público e não autenticado que retorna dados JSON em resposta a solicitações HTTP.
Para gerar sua resposta, a API invoca uma API de terceiros que requer uma chave de acesso. Em vez de armazenar essa chave em arquivos de código ou configuração, o aplicativo a recupera com segurança no runtime do Azure Key Vault usando a identidade gerenciada do Microsoft Entra.
Antes de retornar sua resposta ao cliente, o aplicativo grava uma mensagem em uma Fila de Armazenamento do Azure para processamento assíncrono. A mensagem pode representar uma tarefa, log ou sinal, embora o processamento downstream não seja o foco desse cenário.
Observação
Embora os pontos de extremidade da API pública sejam normalmente protegidos por suas próprias chaves de acesso ou mecanismos de autenticação, esse passo a passo pressupõe que o ponto de extremidade esteja aberto e não autenticado.
Essa simplificação ajuda a isolar os requisitos de autenticação interna do aplicativo, como acessar o Azure Key Vault e o Armazenamento do Azure, de quaisquer preocupações de autenticação relacionadas a clientes externos.
O cenário se concentra exclusivamente no comportamento do aplicativo e não demonstra ou envolve um chamador externo autenticando-se com o ponto de extremidade.