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

Parte anterior: Introdução e plano de fundo

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 de API é recuperada, o aplicativo a usa para autenticar com a API de terceiros externa.

• Armazenamento de Filas do Azure

  Depois de processar a solicitação, o aplicativo deve se autenticar 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 (Key Vault 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 no Key Vault

  O aplicativo usa o Azure Key Vault para armazenar segredos com segurança, como chaves de API de terceiros ou credenciais de Armazenamento do Azure. No entanto, para recuperar esses segredos, o aplicativo deve primeiro se autenticar com o Key Vault. Isso cria um problema circular: o aplicativo precisa de credenciais para acessar o Key Vault, 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.

• Manipulação segura de chaves de API de terceiros

  Depois de recuperar a chave de API do Key Vault, o aplicativo deve usá-la para chamar um serviço externo de terceiros. Essa chave deve ser tratada com extremo cuidado:

  • Nunca codificado em código-fonte ou arquivos de configuração
  • Nunca registrado em stdout, stderr ou logs de aplicativo
  • Mantido somente na memória e acessado no runtime, pouco antes do uso
  • Descartado imediatamente após a conclusão da solicitação

  A falha ao seguir essas práticas aumenta o risco de vazamento de credenciais ou uso não autorizado.

• Protegendo credenciais do Azure Queue Storage

  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 Key Vault
  • Não deve aparecer em logs, rastreamentos de pilha ou ferramentas de desenvolvedor
  • Deve ser acessado somente por meio de mecanismos de runtime seguros
  • Exigir configuração de RBAC adequada se estiver usando a identidade gerenciada

• Flexibilidade de ambiente

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

  Isso significa:

  • Nenhum segredo específico do ambiente inserido no código
  • Não é necessário alternar manualmente credenciais ou caminhos lógicos
  • Uso consistente da autenticação baseada em identidade em ambientes

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

À medida que os aplicativos de nuvem escalam em complexidade e se integram a mais serviços, a autenticação segura e simplificada torna-se essencial. O Azure oferece um modelo de identidade "Azure-first" por meio da ID do Microsoft Entra, 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 inserir credenciais no código do aplicativo , uma prática propensa a riscos de segurança, a ID do Microsoft Entra permite que os aplicativos se autentiquem com segurança usando identidades gerenciadas.

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

• Nenhum segredo no código

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

• Identidade interna para aplicativos

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

• Consistência do ambiente

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

Fluxo de identidade específico para o ambiente

Os aplicativos que usam a ID do Microsoft Entra para autenticação se beneficiam de um modelo de identidade flexível que funciona perfeitamente em ambientes de desenvolvimento locais e hospedados no 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 com a emissão de token e o ciclo de vida da credencial internamente — nenhum segredo manual é necessário.
• O aplicativo usa políticas de acesso do RBAC (Controle de Acesso Role-Based) ou do Key Vault para acessar serviços

Ambiente de desenvolvimento local

Durante o desenvolvimento local:

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

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

Práticas recomendadas para desenvolvimento seguro

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

• Você deve replicar manualmente segredos em ambientes locais.
• Há o risco de segredos vazarem no controle do código-fonte.
• Uma lógica adicional pode ser necessária para diferenciar entre ambientes.

Em vez disso, a abordagem recomendada é:

• Use o Key Vault para armazenar chaves de API de terceiros e outros segredos.
• Atribua a identidade gerenciada ao aplicativo implantado.
• Use um principal de serviço para desenvolvimento local e atribua a ele os mesmos direitos de acesso.
• Use DefaultAzureCredential em seu código para abstrair a lógica de autenticação.
• Evite armazenar ou fazer log das credenciais.

Fluxo de autenticação na prática

Veja como a autenticação funciona em runtime:

• Seu código cria uma DefaultAzureCredential instância.
• Use 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 ela tem a função ou a 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 inserir segredos em arquivos de código ou configuração. Ele também permite alternar perfeitamente entre o desenvolvimento local e a implantação de nuvem sem alterar sua lógica de autenticação.

Parte 3 – Implementação da API de terceiros >>>