Partilhar via


Passo a passo: Autenticação integrada para aplicativos Python com serviços do Azure

O Microsoft Entra ID, quando usado com o Azure Key Vault, fornece uma abordagem robusta e segura para autenticar aplicativos em 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, confiando em identidades gerenciadas, controle de acesso baseado em função (RBAC) e gerenciamento centralizado de segredos via Key Vault. Essa abordagem simplifica o gerenciamento de identidades e melhora 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 Cofre da Chave do Azure sem armazenar credenciais

  • Comunique-se com segurança com outros serviços do Azure, como o Armazenamento do Azure, o 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 o Microsoft Entra ID, o Azure Key Vault e o Azure Queue Storage usando a biblioteca do SDK azure-identity do Azure Python.

Parte 1: Antecedentes

Enquanto muitos serviços do Azure dependem 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, bases 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, CLI ou 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 chaves explicitamente e se autentique separadamente com cada serviço, um processo tedioso e propenso a erros.

Incorporar segredos diretamente no código ou armazená-los em máquinas de desenvolvedores corre o risco de expô-los em:

  • Controlo de origem
  • Ambientes locais inseguros
  • Logs acidentais ou exportações de configuração

O Azure oferece dois serviços principais para melhorar a segurança e simplificar a autenticação:

  • Azure Key Vault O Azure Key Vault fornece um armazenamento seguro e baseado na nuvem para segredos, incluindo chaves de acesso, cadeias de conexão e certificados. Ao recuperar segredos do Cofre da Chave apenas em tempo de execução, os aplicativos evitam expor dados confidenciais no código-fonte ou em arquivos de configuração.
  • Com as identidades gerenciadas do Microsoft Entra, seu aplicativo pode se autenticar uma vez com o Microsoft Entra ID. A partir daí, ele pode acessar outros serviços do Azure, incluindo o Cofre da Chave, sem gerenciar credenciais diretamente.

Esta abordagem prevê:

  • Código livre de 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 Cofre da Chave juntos no mesmo aplicativo. Ao usar o Microsoft Entra ID 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 quaisquer chaves necessárias para serviços de terceiros.

Importante

Este artigo usa o termo comum e genérico "chave" para se referir ao que são armazenados como "segredos" no Cofre da Chave do Azure, 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 na nuvem

Para entender o processo de autenticação do Azure mais profundamente, 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 em tempo de execução do Cofre de Chaves do Azure 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.

Diagrama do cenário do aplicativo

Observação

Embora os pontos de extremidade de API públicos sejam normalmente protegidos por suas próprias chaves de acesso ou mecanismos de autenticação, este passo a passo pressupõe que o ponto de extremidade está aberto e não autenticado.

Essa simplificação ajuda a isolar os requisitos de autenticação interna do aplicativo, como acessar o Cofre de Chaves do Azure e o Armazenamento do Azure, de quaisquer preocupações de autenticação relacionadas a clientes externos.

O cenário foca exclusivamente no comportamento da aplicação e não demonstra nem envolve um chamador externo a autenticar-se no endpoint.