Compartilhar via

Autenticação sem segredo para recursos do Azure

Senhas e chaves de segurança foram a base da segurança digital por décadas, mas não podem mais acompanhar as ameaças modernas. A autenticação sem segredo, alinhada com o modelo de Confiança Zero, desloca o controle de acesso e a verificação do usuário para uma abordagem sem credenciais. A autenticação sem segredo envolve a criação de aplicativos seguros na nuvem sem depender de credenciais tradicionais e compartilhadas, como senhas, certificados, segredos ou chaves de segurança. A autenticação sem segredo fornece os seguintes benefícios:

  • Redução dos riscos de credencial: eliminando senhas, a autenticação sem segredo reduz os riscos associados ao roubo de credenciais, ataques de phishing e ataques de força bruta. Essa abordagem usa elementos de identidade verificáveis, como biometria, certificados digitais e tokens de hardware.
  • Controle de acesso simplificado: ele aprimora a segurança e simplifica a experiência do usuário, contando com mecanismos que verificam a identidade verdadeira em vez de segredos compartilhados. Isso se alinha aos princípios da Confiança Zero verificando cada solicitação de acesso com base na identidade verdadeira.
  • Experiência aprimorada do usuário final: os usuários se beneficiam de um processo de autenticação mais contínuo e seguro, o que reduz a necessidade de redefinições de senha e melhora a satisfação geral do usuário.

Este artigo explora a autenticação sem segredo no Azure, seus benefícios e como implementá-la em vários cenários, incluindo aplicativos cliente, comunicação serviço a serviço do Azure e cargas de trabalho externas.

Desafios de segurança de senhas e segredos

Senhas e outros segredos devem ser usados com cuidado, e os desenvolvedores nunca devem colocá-los em um local não seguro. Muitos aplicativos se conectam a serviços de banco de dados de back-end, cache, mensagens e eventos usando nomes de usuário, senhas e chaves de acesso. Se expostas, essas credenciais poderão ser usadas para obter acesso não autorizado a informações confidenciais, como um catálogo de vendas criado para uma campanha futura ou dados do cliente que devem ser privados.

A inserção de senhas em um aplicativo em si representa um enorme risco de segurança por muitos motivos, incluindo a descoberta por meio de um repositório de código. Muitos desenvolvedores externalizam essas senhas usando variáveis de ambiente para que os aplicativos possam carregá-las de ambientes diferentes. No entanto, isso apenas desloca o risco do próprio código para um ambiente de execução. Qualquer pessoa que obtém acesso ao ambiente pode roubar senhas, o que, por sua vez, aumenta o risco de exfiltração de dados.

Desafios de segurança de chaves

O uso de chaves criptográficas no desenvolvimento de aplicativos do Azure apresenta vários desafios que podem complicar a segurança e a eficiência operacional. Um dos principais problemas são as complexidades do gerenciamento de chaves, que envolvem as tarefas complicadas de rotacionar, distribuir e armazenar chaves com segurança em diferentes serviços e ambientes. Esse processo contínuo requer recursos dedicados e pode aumentar significativamente os custos operacionais devido à necessidade de manutenção e monitoramento regulares. Além disso, há riscos substanciais de segurança associados à exposição ou uso indevido de chaves, pois o acesso não autorizado devido a chaves vazadas pode comprometer dados confidenciais. Além disso, os métodos de autenticação baseados em chave geralmente não têm a escalabilidade e a flexibilidade necessárias para ambientes dinâmicos, dificultando a adaptação às mudanças de requisitos e operações de escala efetivamente. Esses desafios destacam a importância de adotar métodos de autenticação mais seguros e eficientes, como identidades gerenciadas, para mitigar riscos e simplificar as operações.

O aplicativo cliente (voltado para o usuário) acessa os recursos protegidos do Microsoft Entra

Funcionalidades como a autenticação multifator (MFA) são uma excelente forma de proteger a sua organização, mas os utilizadores muitas vezes ficam frustrados com a camada de segurança adicional, além de terem de memorizar as palavras-passe. Os métodos de autenticação sem palavra-passe são mais convenientes porque a palavra-passe é removida e substituída por algo que tem ou algo que é ou sabe.

Cada organização tem necessidades diferentes quando se trata de autenticação. O Microsoft Entra ID e o Azure Government integram as seguintes opções de autenticação sem senha:

  • Windows Hello para Empresas
  • Credencial de Plataforma para macOS
  • Início de sessão único da plataforma (PSSO) para macOS com autenticação de card inteligente
  • Microsoft Authenticator
  • Chaves de acesso (FIDO2)
  • Autenticação baseada em certificado

Para saber mais, leia a entrada sem senha do Microsoft Entra.

Serviço de serviço do Azure para o Azure (no Azure)

Ao autenticar entre recursos do Azure (autenticação serviço a serviço), a abordagem recomendada é usar identidades gerenciadas para recursos do Azure. No entanto, ao autenticar e acessar recursos entre locatários, você deve configurar uma identidade gerenciada como uma credencial de identidade federada em um aplicativo.

Acessa recursos protegidos do Microsoft Entra (mesmo tenant)

Para cenários em que você precisa de autenticação serviço a serviço entre recursos do Azure e os recursos estão no mesmo locatário, as identidades gerenciadas e a classe DefaultAzureCredential na biblioteca de cliente da Azure Identity são a opção recomendada.

Uma identidade gerenciada é uma identidade que pode ser atribuída a um recurso de computação do Azure (por exemplo, Máquinas Virtuais do Azure, Azure Functions ou Kubernetes do Azure) ou qualquer serviço do Azure que dê suporte a identidades gerenciadas. Depois que uma identidade gerenciada é atribuída no recurso de computação, ela pode ser autorizada a acessar recursos de dependência downstream, como uma conta de armazenamento, banco de dados SQL, Cosmos DB e assim por diante. As identidades gerenciadas substituem segredos como chaves de acesso, senhas e certificados ou outras formas de autenticação para dependências de serviço a serviço.

Para obter mais informações, leia O que são identidades gerenciadas para recursos do Azure?.

Implemente DefaultAzureCredential e gerencie identidades em seu aplicativo para criar conexões sem senha com os serviços do Azure por meio da ID do Microsoft Entra e do RBAC (controle de acesso baseado em função). DefaultAzureCredential dá suporte a vários métodos de autenticação e determina automaticamente quais devem ser usados no runtime. Essa abordagem permite que seu aplicativo use diferentes métodos de autenticação em ambientes diferentes (desenvolvimento local versus produção) sem implementar código específico do ambiente.

Para obter mais informações sobre como usar DefaultAzureCredential e uma identidade gerenciada em seu aplicativo, leia Configurar conexões sem segredo entre aplicativos e serviços do Azure.

Acessa recursos protegidos do Microsoft Entra (entre locatários)

As identidades gerenciadas são recomendadas para cenários em que você precisa de autenticação serviço a serviço entre os recursos do Azure. No entanto, não há suporte para identidades gerenciadas para acessar recursos entre locatários (aplicativos multilocatários). Anteriormente, você criou um aplicativo multilocatário com um segredo do cliente ou certificado como credenciais para autenticar e acessar recursos em vários locatários. Isso deixa você com riscos significativos em relação à exposição de segredos e adiciona a carga de armazenar, rodar e manter ciclos de vida de certificados.

As cargas de trabalho do Azure agora podem usar identidades gerenciadas como credenciais de identidade federadas para acessar com segurança os recursos protegidos do Microsoft Entra entre locatários sem depender de segredos ou certificados.

Para saber mais, leia Configurar um aplicativo para confiar em uma identidade gerenciada.

O serviço do Azure acessa recursos externos ou não protegidos do Microsoft Entra

Para cargas de trabalho do Azure que autenticam e acessam recursos que não são protegidos pelos serviços do Microsoft Entra ou do Azure que exigem uma senha, segredo, chave ou certificado para acesso, você não pode usar diretamente identidades gerenciadas. Nesse caso, use o Azure Key Vault para armazenar as credenciais do recurso de destino. Utilize uma identidade gerenciada da carga de trabalho para obter as credenciais do cofre de chaves e acessar o recurso de destino usando as credenciais.

Para obter mais informações, leia Autenticar no Key Vault em código.

A carga de trabalho externa (fora do Azure) acessa os recursos protegidos do Microsoft Entra

Quando uma carga de trabalho de software está em execução fora do Azure (por exemplo, datacenter local, no computador de um desenvolvedor ou em outra nuvem) e precisa acessar recursos do Azure, você não pode usar uma identidade gerenciada do Azure diretamente. No passado, você registrava um aplicativo na plataforma de identidade da Microsoft e usava um segredo do cliente ou certificado para que o aplicativo externo pudesse autenticar-se. Essas credenciais representam um risco de segurança e precisam ser armazenadas com segurança e trocadas regularmente. Você também corre o risco do tempo de inatividade do serviço se as credenciais expirarem.

Você usa a federação de identidade para carga de trabalho para configurar uma identidade gerenciada atribuída pelo usuário ou um registro de aplicativo no Microsoft Entra ID para confiar em tokens de um provedor de identidade externo (IdP), como o GitHub ou o Google. Quando essa relação de confiança é criada, sua carga de trabalho de software externa troca tokens confiáveis do IdP externo por tokens de acesso da plataforma de identidade da Microsoft. A carga de trabalho do software usa esse token de acesso para acessar os recursos protegidos do Microsoft Entra aos quais a carga de trabalho recebeu acesso. Você elimina a carga de manutenção do gerenciamento manual de credenciais e elimina o risco de vazamento de segredos ou de expiração de certificados.

Para saber mais, leia Federação de Identidade de Workloads.

Próximas etapas