Autenticação no Cofre da Chave do Azure

A autenticação com o Azure Key Vault funciona em conjunto com o Microsoft Entra ID, que é responsável por autenticar a identidade de qualquer principal de segurança.

Uma entidade de segurança é um objeto que representa um utilizador, grupo, serviço ou aplicação que está a solicitar acesso aos recursos da Azure. O Azure atribui um identificador de objeto exclusivo a cada entidade de segurança.

• Um principal de segurança de utilizador identifica uma pessoa que tem um perfil no Microsoft Entra ID.

• Uma principal de segurança de grupo identifica um conjunto de utilizadores criados no Microsoft Entra ID. Quaisquer funções ou permissões atribuídas ao grupo são concedidas a todos os usuários dentro do grupo.

• Uma entidade de serviço é um tipo de entidade de segurança que identifica um aplicativo ou serviço, ou seja, uma parte do código em vez de um usuário ou grupo. O ID de objeto de uma entidade de serviço age como seu nome de usuário; O segredo do cliente da entidade de serviço funciona como sua senha.

Para aplicações, há duas maneiras de obter um principal de serviço:

• Recomendado: habilite uma identidade gerenciada atribuída ao sistema para o aplicativo.

  Com a identidade gerenciada, o Azure gerencia internamente a entidade de serviço do aplicativo e autentica automaticamente o aplicativo com outros serviços do Azure. A identidade gerenciada está disponível para aplicativos implantados em uma variedade de serviços.

  Para obter mais informações, consulte a Visão geral da identidade gerenciada. Consulte também Serviços do Azure que dão suporte à identidade gerenciada, que vincula a artigos que descrevem como habilitar a identidade gerenciada para serviços específicos (como Serviço de Aplicativo, Azure Functions, Máquinas Virtuais, etc.).

• Se não puder usar a identidade gerenciada, registre o aplicativo com seu locatário do Microsoft Entra, conforme descrito em Guia de início rápido: registrar um aplicativo com a plataforma de identidade do Azure. O registro também cria um segundo objeto de aplicativo que identifica o aplicativo em todos os locatários.

Cenários de autenticação do Cofre de Chaves

Quando crias um cofre de chaves numa subscrição do Azure, ele é automaticamente associado ao tenant Microsoft Entra da subscrição. Todos os chamadores em ambos os planos devem registar-se neste tenant e autenticar-se para aceder ao cofre de chaves. As aplicações podem aceder ao Key Vault de três formas:

• Aplicação apenas: A aplicação representa um principal de serviço ou uma identidade gerida por gestão. Esta identidade é o cenário mais comum para aplicações que necessitam periodicamente de aceder a certificados, chaves ou segredos do cofre de chaves. Para que este cenário funcione ao utilizar políticas de acesso (herdadas), o objectId da aplicação deve ser especificado na política de acesso e o applicationIdnão deve ser especificado ou deve ser null. Ao utilizar Azure RBAC, atribua papéis apropriados à identidade gerida ou principal de serviço da aplicação.

• Apenas utilizador: O utilizador acede ao cofre de chaves a partir de qualquer aplicação registada no inquilino. Exemplos deste tipo de acesso incluem o Azure PowerShell e o portal Azure. Para que este cenário funcione ao utilizar políticas de acesso (legacy), o objectId do utilizador deve ser especificado na política de acesso, e o applicationId não deve ser especificado ou deve ser null. Ao usar Azure RBAC, atribua funções apropriadas ao utilizador.

• Application-plus-user (por vezes referido como identidade composta): O utilizador é obrigado a aceder ao cofre de chaves a partir de uma aplicação específica e a aplicação deve usar o fluxo on-behalf-of authentication (OBO) para se fazer passar pelo utilizador. Para que este cenário funcione com políticas de acesso (legacy), tanto applicationId quanto objectId devem ser especificados na política de acesso. O applicationId identifica a aplicação necessária e o objectId identifica o utilizador. Atualmente, esta opção não está disponível para o plano de dados Azure RBAC.

Em todos os tipos de acesso, a aplicação autentica-se com o Microsoft Entra ID. A aplicação utiliza qualquer método de autenticação suportado com base no tipo de aplicação. A aplicação adquire um token para um recurso no avião para conceder acesso. O recurso é um endpoint no plano de gestão ou de dados, baseado no ambiente Azure. A aplicação utiliza o token e envia um pedido de API REST para o Key Vault. Para saber mais, consulte todo o processo de autenticação.

O modelo de um único mecanismo de autenticação em ambos os planos tem vários benefícios:

• As organizações podem controlar o acesso de forma central a todos os cofres-chave da organização.
• Caso um utilizador saia, perde imediatamente o acesso a todos os cofres de chaves da organização.
• As organizações podem personalizar a autenticação utilizando as opções do Microsoft Entra ID, como ativar a autenticação multifator para maior segurança.

Configurar o firewall do Cofre de Chaves

Por padrão, o Cofre da Chave permite o acesso a recursos por meio de endereços IP públicos. Para maior segurança, você também pode restringir o acesso a intervalos IP específicos, pontos de extremidade de serviço, redes virtuais ou pontos de extremidade privados.

Para obter mais informações, consulte Access Azure Key Vault behind a firewall.

O fluxo de operação de solicitação do Cofre da Chave com autenticação

A autenticação do Cofre da Chave ocorre como parte de cada operação de solicitação no Cofre da Chave. Uma vez recuperado, o token pode ser reutilizado para chamadas subsequentes. Exemplo de fluxo de autenticação:

1. Um token solicita autenticação com o Microsoft Entra ID, por exemplo:

   • Um recurso do Azure, como uma máquina virtual ou um aplicativo do Serviço de Aplicativo com uma identidade gerenciada, entra em contato com o ponto de extremidade REST para obter um token de acesso.
   • Um usuário faz logon no portal do Azure usando um nome de usuário e senha.

2. Se a autenticação com o Microsoft Entra ID for bem-sucedida, a entidade de segurança receberá um token OAuth.

3. Uma chamada para a API REST do Key Vault através do ponto de extremidade (URI) do Key Vault.

4. O Key Vault Firewall verifica os seguintes critérios. Se algum critério for atendido, a chamada é permitida. Caso contrário, a chamada é bloqueada e uma resposta proibida é retornada.

   • A firewall está desativada e o ponto de extremidade público do Cofre da Chave pode ser acedido a partir da Internet pública.
   • O chamador é um Serviço Confiável do Cofre de Chaves, permitindo que ele ignore o firewall.
   • O chamador é listado no firewall por endereço IP, rede virtual ou ponto de extremidade de serviço.
   • O chamador pode acessar o Cofre da Chave através de uma conexão de link privado configurada.

5. Se o firewall permitir a chamada, o Azure Key Vault chamará o Microsoft Entra ID para validar o token de acesso do principal de segurança.

6. O Cofre da Chave verifica se a entidade de segurança tem a permissão necessária para a operação solicitada. Caso contrário, o Azure Key Vault devolve uma resposta de acesso negado.

7. Key Vault executa a operação solicitada e retorna o resultado.

O diagrama seguinte ilustra o processo em que uma aplicação chama a API "Get Secret" do Cofre de Chaves:

Autenticação no Cofre de Chaves no código da aplicação

O SDK do Cofre da Chave está usando a biblioteca de cliente do Azure Identity, que permite a autenticação contínua no Cofre da Chave em ambientes com o mesmo código

Bibliotecas de cliente do Azure Identity

Para mais informações sobre práticas recomendadas e exemplos de desenvolvedores, veja Autenticar no Cofre de Chaves no código

Próximas Etapas

• Guia do desenvolvedor do Key Vault

• Atribuir uma política de acesso ao Cofre da Chave usando o portal do Azure

• Atribuir a função RBAC do Azure ao Key Vault

• Solução de problemas da política de acesso ao Cofre da Chave

• Códigos de erro da API REST do Key Vault

• O que é o controlo de acesso baseado em funções do Azure (Azure RBAC)?