Share via

Fornecer credenciais de identidade do aplicativo quando não houver usuário

  • Artigo

Quando você, como desenvolvedor, está criando aplicativos não usuários, não tem um usuário a quem possa solicitar um nome de usuário e senha ou autenticação multifator (MFA). Você precisa fornecer a identidade do aplicativo por conta própria. Este artigo explica por que a melhor prática de credenciais de cliente Zero Trust para serviços (aplicativos não 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. Não pode ser sem senha ou ter um MFA. Em vez de usar uma conta de usuário como uma conta de serviço, sua melhor solução é usar uma das seguintes opções de credenciais de cliente.

Opções de credenciais do cliente

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

Chave secreta ou certificado?

As chaves secretas são aceitáveis quando você tem uma infraestrutura sofisticada de gerenciamento de segredos (como o Azure Key Vault) em sua 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 pode armazená-la em um local inseguro, como uma planilha, faz com que as chaves secretas não sejam protegidas corretamente.

As credenciais de cliente baseadas em certificado são mais seguras do que as 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ê usa uma chave secreta, seu cliente envia o valor real da chave secreta para o Microsoft Entra ID. Quando você usa um certificado, a chave privada do certificado nunca sai do dispositivo. Mesmo que alguém intercete, decodifice e descriptografe a transmissão, o segredo ainda é seguro porque a parte interceptante não tem a chave privada.

Prática recomendada: usar identidades gerenciadas para recursos do Azure

Quando você está desenvolvendo serviços (aplicativos não usuários) no Azure, as Identidades Gerenciadas para Recursos do Azure fornecem uma identidade gerenciada automaticamente na ID do Microsoft Entra. O aplicativo pode se autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem gerenciar credenciais. Você não precisa gerenciar segredos; Você não precisa lidar com a possibilidade de perdê-los ou manuseá-los incorretamente. Os segredos não podem ser intercetados porque não se movem pela rede. Identidades gerenciadas para recursos do Azure é a prática recomendada se você estiver criando serviços no Azure.

Próximos passos