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 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 o aplicativo recupera a chave de API, ele usa a chave 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 conjuntos para recursos de Azure (Key Vault e Armazenamento)

• Um conjunto 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. Essa situação cria um problema circular: o aplicativo precisa de credenciais para acessar Key Vault, mas você deve armazenar essas credenciais com segurança. Sem uma solução segura, esse problema 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. Lide com essa chave com extremo cuidado:

  • Nunca codifique-o no código-fonte ou nos arquivos de configuração
  • Nunca registre isso no stdout, no stderr ou nos logs da aplicação
  • Segure-o somente na memória e acesse-o em runtime, pouco antes do uso
  • Descarte-o 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 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 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.

  Esse requisito significa:

  • Não insira segredos específicos do ambiente no código
  • Não alterne manualmente credenciais ou caminhos lógicos
  • Usar a autenticação baseada em identidade de forma consistente entre ambientes

Autenticação com prioridade para Azure usando o Microsoft Entra ID

À 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. Azure oferece um modelo de identidade centrado no Azure 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 inserir credenciais no código do aplicativo , uma prática propensa a riscos de segurança, 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:

• 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

  Azure pode atribuir automaticamente uma identidade gerenciada ao seu aplicativo, para que ele possa acessar com segurança serviços como Key Vault, Armazenamento e SQL sem credenciais extras.

• Consistência do ambiente

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

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. O SDK do Azure DefaultAzureCredential fornece essa consistência selecionando automaticamente o método de identidade apropriado com base no ambiente.

Ambiente do Azure

Ao implantar o aplicativo no Azure:

• O aplicativo obtém automaticamente uma identidade gerenciada.
• Azure gerencia a emissão de token e o ciclo de vida da credencial internamente, portanto, você não precisa lidar com segredos.
• O aplicativo acessa serviços usando Role-Based Controle de Acesso (RBAC) ou Key Vault políticas de acesso.

Ambiente de desenvolvimento local

Durante o desenvolvimento local:

• Uma entidade de serviço serve como a identidade do aplicativo.
• Os desenvolvedores se autenticam usando as integrações CLI do Azure (az login), variáveis de ambiente ou Visual Studio/VS Code.
• O mesmo código da aplicação é executado sem nenhuma modificação — 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 automaticamente o método adequado.

Práticas recomendadas para desenvolvimento seguro

Embora você possa definir segredos como variáveis de ambiente (por exemplo, por meio de configurações de Azure App), essa abordagem tem desvantagens:

• Você deve replicar manualmente segredos em ambientes locais.
• Há o risco de segredos vazarem no controle do código-fonte.
• Talvez seja necessário uma lógica extra para diferenciar entre ambientes.

Em vez disso, use a seguinte abordagem:

• Use o Key Vault para armazenar chaves de API de terceiros e outros segredos.
• Atribua uma 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.
• 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 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 >>>