Fornecendo credenciais de identidade de aplicativo quando não há usuário

  • Artigo

Quando você, como desenvolvedor, está criando aplicativos que não são de usuário, não tem um usuário a quem possa solicitar um nome de usuário e senha ou MFA (Multifactor Authentication). Você precisa fornecer a identidade do aplicativo por conta própria. Este artigo explica por que a melhor prática de credenciais de cliente de Confiança Zero para serviços (aplicativos que são não de usuários) no Azure é Identidades gerenciadas para recursos do Azure.

Problemas com contas de serviço

Usar uma "conta de serviço" (criar uma conta de usuário e usá-la para um serviço) não é uma boa solução. O Microsoft Entra ID não tem um conceito de conta de serviço. Quando os administradores criam contas de usuário para um serviço e, em seguida, compartilham senhas com desenvolvedores, isso é inseguro. Ele não pode ser sem senha ou ter um MFA. Em vez de utilizar uma conta de usuário como uma conta de serviço, sua melhor solução é utilizar uma das opções de credenciais de cliente descritas abaixo.

Opções de credenciais do cliente

Há quatro tipos de credenciais de cliente que podem identificar um aplicativo.

Chave secreta ou certificado?

Chaves secretas são aceitáveis quando você tem uma infraestrutura sofisticada de gerenciamento de segredos (como o Azure Key Vault) na empresa. No entanto, chaves secretas em cenários em que o profissional de TI gera uma chave secreta e, em seguida, envia-a por e-mail para um desenvolvedor que, em seguida, pode armazená-la em um local inseguro, como uma planilha, faz com que as chaves secretas não sejam protegidas adequadamente.

Credenciais do cliente baseadas em certificados são mais seguras do que chaves secretas. Os certificados são melhor gerenciados, pois não são o segredo em si. O segredo não faz parte de uma transmissão. Quando você utiliza uma chave secreta, seu cliente envia o valor real da chave secreta para o Microsoft Entra ID. Quando você utiliza um certificado, a chave privada do certificado nunca sai do dispositivo. Mesmo que alguém intercepte, decodifice e descriptografe a transmissão, o segredo ainda é seguro porque a parte interceptadora não tem a chave privada.

Melhor prática: usar identidades gerenciadas para recursos do Azure

Quando você está desenvolvendo serviços (aplicativos que são não de usuários) no Azure, o recurso Identidades gerenciadas para recursos do Azure fornece uma identidade gerenciada automaticamente no Microsoft Entra ID. Você pode usar a identidade para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem nenhuma credencial no seu código. Você não precisa gerenciar segredos; você não precisa lidar com a possibilidade de perdê-los ou manipulá-los indevidamente. Os segredos não podem ser interceptados porque eles não se movem pela rede. O recurso Identidades gerenciadas para recursos do Azure é a melhor prática se você está criando serviços no Azure.

Próximas etapas