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

  A aplicação deve autenticar-se com o Azure Key Vault para recuperar uma chave API armazenada de forma segura necessária para chamar um serviço de terceiros.

• API de terceiros

  Assim que a aplicação recupera a chave da API, utiliza a chave 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 conjuntos para recursos do Azure (Key Vault e Storage)

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

Principais desafios de autenticação

Construir aplicações cloud seguras requer um tratamento cuidadoso das credenciais, especialmente quando estão envolvidos múltiplos serviços. 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. Esta situação cria um problema circular: a aplicação precisa de credenciais para aceder ao Key Vault, mas tem de guardar essas credenciais de forma segura. Sem uma solução segura, este problema pode levar a credenciais codificadas fixamente 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. Manuseie esta chave com extremo cuidado:

  • Nunca codifiques isso diretamente no código-fonte nem em ficheiros de configuração
  • Nunca faça login em stdout, stderr ou registos de aplicações
  • Mantenha-o apenas na memória e aceda a ele em tempo de execução, pouco antes de o usar
  • Elimine-o imediatamente após a conclusão da solicitação.

  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.

  Este requisito significa:

  • Não incorpore segredos específicos do ambiente no código
  • Não alterne manualmente credenciais ou caminhos lógicos
  • Use autenticação baseada em identidade de forma consistente em todos os ambientes

Autenticação com o Azure em primeiro lugar 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 através do Microsoft Entra ID, permitindo gestão unificada de identidades e integração perfeita com os serviços do Azure para autenticação segura e sem credenciais.

Em vez de gerir manualmente segredos ou incorporar credenciais no código da aplicação — uma prática propensa a riscos de segurança — o Microsoft Entra ID permite que as aplicações se autentiquem de forma segura usando identidades geridas.

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 gerida à sua aplicação, para que possa aceder de forma segura a serviços como Key Vault, Storage e SQL sem credenciais adicionais.

• Consistência dos ambientes

  O mesmo código e modelo de identidade funcionam tanto no desenvolvimento local como em ambientes alojados no Azure, utilizando o 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. O DefaultAzureCredential do SDK do Azure fornece esta consistência ao selecionar automaticamente o método de autenticação apropriado em função do ambiente.

Ambiente do Azure

Quando implementa a aplicação no Azure:

• A aplicação recebe automaticamente uma identidade gerida.
• O Azure gere internamente a emissão de tokens e o ciclo de vida das credenciais, por isso não precisa de lidar com segredos.
• A aplicação acede aos serviços utilizando políticas de acesso Role-Based Controlo de Acesso (RBAC) ou Key Vault.

Ambiente de desenvolvimento local

Durante o desenvolvimento local:

• Um principal de serviço serve como a identidade da aplicação.
• Os programadores autenticam-se usando a CLI do Azure (az login), variáveis de ambiente ou integrações com Visual Studio/VS Code.
• O mesmo código da aplicação corre sem qualquer 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 correto.

Melhores práticas para um desenvolvimento seguro

Embora possa definir segredos como variáveis de ambiente (por exemplo, através do Aplicação Azure AD Settings), esta abordagem tem desvantagens:

• Você deve replicar manualmente segredos em ambientes locais.
• Existe o risco de segredos serem infiltrados no controlo de fontes.
• Podes precisar de lógica extra para diferenciar os ambientes.

Em vez disso, use a seguinte abordagem:

• Use o Cofre de Chaves para armazenar chaves de API de terceiros e outros segredos.
• Atribua uma identidade gerida à tua aplicação implementada.
• 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

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

• Seu código cria uma DefaultAzureCredential instância.
• Usa esta 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 >>>