Parte 2: Necessidades de autenticação neste cenário de exemplo

Parte anterior: Introdução e antecedentes

Neste cenário de exemplo, o aplicativo principal tem três requisitos de autenticação distintos:

• Azure Key Vault

  O aplicativo deve se autenticar com o Azure Key Vault para recuperar uma chave de API armazenada com segurança necessária para chamar um serviço de terceiros.

• API de terceiros

  Depois que a chave da API é recuperada, o aplicativo a usa para autenticar com a API externa de terceiros.

• Armazenamento de Filas do Azure

  Depois de processar a solicitação, o aplicativo deve autenticar-se com o Armazenamento de Filas do Azure para enfileirar uma mensagem para processamento assíncrono ou adiado.

Essas tarefas exigem que o aplicativo gerencie três conjuntos de credenciais:

• Dois para recursos do Azure (Cofre de Chaves e Armazenamento)

• Um para um serviço externo (API de terceiros)

Principais desafios de autenticação

A criação de aplicativos de nuvem seguros requer um tratamento cuidadoso das credenciais, especialmente quando vários serviços estão envolvidos. Este cenário de exemplo apresenta vários desafios críticos:

• Dependência circular do Cofre da Chave

  O aplicativo usa o Azure Key Vault para armazenar segredos com segurança, como chaves de API de terceiros ou credenciais do Armazenamento do Azure. No entanto, para recuperar esses segredos, o aplicativo deve primeiro autenticar-se com o Cofre da Chave. Isso cria um problema circular: o aplicativo precisa de credenciais para acessar o Cofre da Chave, mas essas credenciais devem ser armazenadas com segurança. Sem uma solução segura, isso pode levar a credenciais codificadas ou configurações inseguras em ambientes de desenvolvimento.

• Tratamento seguro de chaves API de terceiros

  Depois de recuperar a chave de API do Cofre da Chave, o aplicativo deve usá-la para chamar um serviço de terceiros externo. Esta chave deve ser manuseada com extremo cuidado:

  • Nunca codificado em código-fonte ou arquivos de configuração
  • Nunca fez login em stdout, stderr ou logs de aplicativos
  • Mantido apenas na memória e acessado em tempo de execução, imediatamente antes do uso
  • Eliminado imediatamente após a conclusão do pedido

  O não cumprimento dessas práticas aumenta o risco de vazamento de credenciais ou uso não autorizado.

• Protegendo as credenciais do Armazenamento de Filas do Azure

  Para gravar mensagens no Armazenamento de Filas do Azure, o aplicativo normalmente precisa de uma cadeia de conexão ou token de acesso compartilhado. Estas credenciais:

  • Deve ser armazenado em um local seguro, como o Cofre da Chave
  • Não deve aparecer em logs, rastreamentos de pilha ou ferramentas de desenvolvedor
  • Deverá ser acedido somente por meio de mecanismos seguros em tempo de execução
  • Exigir configuração RBAC adequada se estiver usando identidade gerenciada

• Flexibilidade Ambiental

  O aplicativo deve ser executado de forma confiável em ambientes de desenvolvimento local e produção em nuvem, usando a mesma base de código e lógica condicional mínima.

  Isto significa:

  • Nenhum segredo específico do ambiente incorporado no código
  • Não há necessidade de alternar manualmente credenciais ou caminhos lógicos
  • Uso consistente da autenticação baseada em identidade entre ambientes

Azure-First autenticação com o Microsoft Entra ID

À medida que as aplicações na nuvem aumentam em complexidade e se integram com mais serviços, a autenticação segura e simplificada torna-se essencial. O Azure oferece um modelo de identidade "Azure-first" por meio do Microsoft Entra ID, permitindo o gerenciamento unificado de identidades e a integração perfeita com os serviços do Azure para autenticação segura e sem credenciais.

Em vez de gerenciar manualmente segredos ou incorporar credenciais no código do aplicativo — uma prática propensa a riscos de segurança — o Microsoft Entra ID permite que os aplicativos se autentiquem com segurança usando identidades gerenciadas.

Os principais benefícios das identidades gerenciadas do Microsoft Entra são:

• Sem segredos no código

  Os aplicativos não exigem mais cadeias de conexão codificadas, segredos de cliente ou chaves.

• Identidade incorporada para aplicações

  O Azure pode atribuir automaticamente uma identidade gerenciada ao seu aplicativo, permitindo acesso seguro a serviços, como Cofre de Chaves, Armazenamento e SQL sem credenciais adicionais.

• Consistência dos ambientes

  O mesmo código e modelo de identidade funcionam no desenvolvimento local e em ambientes hospedados pelo Azure usando a DefaultAzureCredential do SDK do Azure.

Fluxo de identidade específico do ambiente

Os aplicativos que usam o Microsoft Entra ID para autenticação se beneficiam de um modelo de identidade flexível que funciona perfeitamente em ambientes de desenvolvimento local e hospedados pelo Azure. Essa consistência é obtida usando o SDK do DefaultAzureCredentialAzure, que seleciona automaticamente o método de identidade apropriado com base no ambiente.

Ambiente do Azure

Quando o aplicativo é implantado no Azure:

• Uma identidade gerenciada é atribuída automaticamente ao aplicativo.
• O Azure lida internamente com a emissão de tokens e o ciclo de vida das credenciais, sem necessidade de segredos manuais.
• O aplicativo usa políticas de acesso Role-Based Access Control (RBAC) ou Key Vault para acessar serviços

Ambiente de desenvolvimento local

Durante o desenvolvimento local:

• Um principal de serviço atua como a identidade do aplicativo.
• Os desenvolvedores autenticam usando a CLI do Azure (az login), variáveis de ambiente ou integrações do Visual Studio/VS Code.
• O mesmo código de aplicativo é executado sem modificação — apenas a origem da identidade é alterada.

Em ambos os ambientes, os SDKs do Azure usam o DefaultAzureCredential, que abstrai a fonte de identidade e seleciona o método certo automaticamente.

Melhores práticas para um desenvolvimento seguro

Embora seja possível definir segredos como variáveis de ambiente (por exemplo, por meio das Configurações do Aplicativo do Azure), essa abordagem tem desvantagens:

• Você deve replicar manualmente segredos em ambientes locais.
• Há um risco de segredos vazarem para o controle da fonte.
• Pode ser necessária uma lógica adicional para diferenciar entre ambientes.

Em vez disso, a abordagem recomendada é:

• Use o Cofre de Chaves para armazenar chaves de API de terceiros e outros segredos.
• Atribua identidade gerenciada ao seu aplicativo implantado.
• Utilize uma entidade de serviço para o desenvolvimento local e atribua-lhe os mesmos direitos de acesso.
• Use DefaultAzureCredential em seu código para abstrair a lógica de autenticação.
• Evite armazenar ou registrar quaisquer credenciais.

Fluxo de autenticação na prática

Veja como a autenticação funciona em tempo de execução:

• Seu código cria uma DefaultAzureCredential instância.
• Você usa essa credencial para instanciar um cliente (por exemplo, SecretClient, QueueServiceClient).
• Quando o aplicativo invoca um método (por exemplo, get_secret()), o cliente usa a credencial para autenticar a solicitação.
• O Azure verifica a identidade e verifica se tem a função ou política correta para executar a operação.

Esse fluxo garante que seu aplicativo possa acessar com segurança os serviços do Azure sem incorporar segredos em arquivos de código ou configuração. Ele também permite que você alterne perfeitamente entre o desenvolvimento local e a implantação na nuvem sem alterar sua lógica de autenticação.

Parte 3 - Implementação de API de terceiros >>>