Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A autenticação com o Key Vault funciona em conjunto com o Microsoft Entra ID, que é responsável por autenticar a identidade de qualquer entidade de segurança.
Um principal de segurança é um objeto que representa um usuário, grupo, serviço ou aplicativo que solicita acesso aos recursos do Azure. O Azure atribui uma ID de objeto exclusiva a cada principal de segurança.
A entidade de segurança de usuário identifica um indivíduo que tem um perfil no Microsoft Entra ID.
Uma entidade de segurança de grupo identifica um conjunto de usuários criado 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, um pedaço de código em vez de um usuário ou grupo. A ID do objeto de uma entidade de serviço age como seu nome de usuário; O segredo do cliente da entidade de serviço age como sua senha.
Para aplicativos, há duas maneiras de obter uma entidade de serviço:
Recomendado: habilitar uma identidade gerenciada atribuída pelo 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 os serviços do Azure que dão suporte à identidade gerenciada, que são vinculados 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 você não puder usar a identidade gerenciada, registre o aplicativo com seu locatário do Microsoft Entra, conforme descrito no Início Rápido: registrar um aplicativo na 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 Key Vault
Quando você cria um cofre de chaves em uma assinatura do Azure, ele é automaticamente associado ao locatário do Microsoft Entra da assinatura. Todos os chamadores em ambos os planos devem se registrar neste locatário e se autenticar para acessar o cofre de chaves. Os aplicativos podem acessar o Key Vault de três maneiras:
Somente aplicativo: o aplicativo representa uma entidade de serviço ou uma identidade gerenciada. Essa identidade é o cenário mais comum para aplicativos que precisam acessar periodicamente certificados, chaves ou segredos do cofre de chaves. Para que esse cenário funcione ao usar políticas de acesso (herdadas), o
objectIddo aplicativo deve ser especificado na política de acesso e oapplicationIdnão deve ser especificado ou deve sernull. Ao usar o RBAC do Azure, atribua funções apropriadas à identidade gerenciada do aplicativo ou ao principal de serviço.Somente usuário: o usuário acessa o cofre de chaves de qualquer aplicativo registrado no locatário. Exemplos desse tipo de acesso incluem o Azure PowerShell e o portal do Azure. Para que esse cenário funcione ao usar políticas de acesso (legadas), o
objectIddo usuário deve ser especificado na política de acesso eapplicationIdnão deve ser especificado ou deve sernull. Ao usar o RBAC do Azure, atribua funções apropriadas ao usuário.Application-plus-user (às vezes chamado de identidade composta): o usuário é solicitado a acessar o cofre de chaves de um aplicativo específico e o aplicativo deve usar o fluxo de autenticação em nome de (OBO) para representar o usuário. Para que esse cenário funcione com políticas de acesso (herdadas), tanto
applicationIdquantoobjectIddevem ser especificados na política de acesso. IdentificaapplicationIdo aplicativo necessário e identificaobjectIdo usuário. Atualmente, essa opção não está disponível para o RBAC do Azure (plano de dados).
Em todos os tipos de acesso, o aplicativo é autenticado com a ID do Microsoft Entra. O aplicativo usa qualquer método de autenticação com suporte com base no tipo de aplicativo. O aplicativo adquire um token para um recurso no plano para conceder acesso. O recurso é um ponto de extremidade no plano de gerenciamento ou de dados, com base no ambiente do Azure. O aplicativo usa o token e envia uma solicitação de API REST para o Key Vault. Para saber mais, examine todo o fluxo 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 centralmente o acesso a todos os repositórios de chaves em sua organização.
- Se um usuário parte, ele perde instantaneamente o acesso a todos os cofres de chaves na organização.
- As organizações podem personalizar a autenticação usando as opções na ID do Microsoft Entra, como habilitar a autenticação multifator para maior segurança.
Configurar o firewall do Key Vault
Por padrão, o Key Vault permite o acesso a recursos por meio de endereços IP públicos. Para maior segurança, também é possível restringir o acesso a intervalos de IP específicos, pontos de extremidade de serviço, redes virtuais ou pontos de extremidade privados.
Para obter mais informações, confira Acessar o Azure Key Vault por trás de um firewall.
O fluxo da operação de solicitação do Key Vault com a autenticação
A autenticação do Key Vault ocorre como parte de cada operação de solicitação no Key Vault. Depois que o token é recuperado, ele pode ser reutilizado para chamadas posteriores. Exemplo de fluxo de autenticação:
Um token solicita a autenticação com a ID do Microsoft Entra, 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 uma senha.
Se a autenticação no Microsoft Entra ID for bem-sucedida, a entidade de segurança receberá um token OAuth.
Uma chamada à API REST do Key Vault por meio do ponto de extremidade (URI) do Key Vault.
O Firewall do Key Vault verifica os critérios a seguir. Se algum critério for atendido, a chamada será permitida. Caso contrário, a chamada é bloqueada e uma resposta com a mensagem "proibido" é retornada.
- O firewall está desabilitado e o ponto de extremidade público do Key Vault pode ser acessado pela Internet pública.
- O chamador é um serviço confiável do Key Vault, permitindo que ele ignore o firewall.
- O chamador está listado no firewall por endereço IP, rede virtual ou ponto de extremidade de serviço.
- O chamador pode acessar o Key Vault por meio de uma conexão de link privado configurada.
Caso o firewall permita a chamada, o Key Vault chamará o Microsoft Entra ID para validar o token de acesso do principal de segurança.
O Key Vault verifica se a entidade de segurança tem a permissão necessária para a operação solicitada. Caso contrário, o Key Vault retornará uma resposta proibida.
O Key Vault executa a operação solicitada e retorna o resultado.
O diagrama a seguir ilustra o processo de um aplicativo que chama uma API "Obter Segredo" do Key Vault:
Observação
Os clientes do SDK do Key Vault para segredos, certificados e chaves criam uma chamada adicional para o Key Vault sem um token de acesso, o que resulta na resposta 401 para recuperar as informações de locatário. Para obter mais informações , consulte Autenticação, solicitações e respostas
Autenticação no Key Vault no código do aplicativo
O SDK do Key Vault usa a biblioteca de clientes da Identidade do Azure, que permite a autenticação direta no Key Vault entre ambientes com o mesmo código
Bibliotecas de clientes da Identidade do Azure
| .NET | Python | Java | JavaScript |
|---|---|---|---|
| SDK da Identidade do Azure para .NET | SDK de Identidade do Azure Python | SDK da Identidade do Azure para Java | SDK da Identidade do Azure para JavaScript |
Para obter mais informações sobre as práticas recomendadas e os exemplos de desenvolvedor, consulte Autenticar-se no Key Vault dentro do código