Recomendações de melhores práticas de identidade gerenciada

Identidades gerenciadas para recursos do Azure é um recurso do Microsoft Entra ID. Cada um dos serviços do Azure que dão suporte a identidades gerenciadas para recursos do Azure está sujeito à própria linha do tempo. Não deixe de examinar o status de disponibilidade das identidades gerenciadas do seu recurso e os problemas conhecidos antes de começar.

Escolher identidades gerenciadas atribuídas pelo usuário ou pelo sistema

Identidades gerenciadas atribuídas pelo usuário são mais eficientes em uma variedade maior de cenários do que as atribuídas pelo sistema. Confira a tabela abaixo para ver alguns cenários e as recomendações de atribuição (usuário ou sistema).

As identidades atribuídas pelo usuário podem ser usadas por vários recursos, e seus ciclos de vida são dissociados dos ciclos de vida dos recursos com os quais estão associadas. Leia quais recursos são compatíveis com identidades gerenciadas.

Esse ciclo de vida permite separar suas responsabilidades de criação de recursos e administração de identidade. As identidades atribuídas pelo usuário e suas atribuições de função podem ser configuradas antes dos recursos que as exigem. Os usuários que criam os recursos exigem apenas o acesso para atribuir uma identidade atribuída pelo usuário, sem a necessidade de criar novas identidades ou atribuições de função.

Como as identidades atribuídas pelo sistema são criadas e excluídas junto com o recurso, as atribuições de função não podem ser criadas com antecedência. Essa sequência pode causar falhas ao implantar a infraestrutura se o usuário que cria o recurso também não tiver acesso para criar atribuições de função.

Se a infraestrutura exigir que vários recursos exijam acesso aos mesmos recursos, uma única identidade atribuída pelo usuário poderá ser atribuída a eles. A sobrecarga de administração será reduzida, pois há menos identidades e atribuições de função distintas a serem gerenciadas.

Se você exigir que cada recurso tenha sua própria identidade ou tiver recursos que exigem um conjunto exclusivo de permissões e quiser que a identidade seja excluída à medida que o recurso for excluído, use uma identidade atribuída pelo sistema.

Cenário	Recomendação	Observações
Criação rápida de recursos (por exemplo, computação efêmera) com identidades gerenciadas	Identidade atribuída pelo usuário	Se você tentar criar várias identidades gerenciadas em um curto espaço de tempo – por exemplo, implantando várias máquinas virtuais cada uma com sua própria identidade atribuída pelo sistema – poderá exceder o limite de taxa para criações de objeto do Microsoft Entra e a solicitação falhará com um erro HTTP 429. Se os recursos estiverem sendo criados ou excluídos rapidamente, você também poderá exceder o limite do número de recursos no Microsoft Entra ID se usar identidades atribuídas pelo sistema. Embora uma identidade atribuída pelo sistema excluída não seja mais acessível por nenhum recurso, ela contará para o limite até que seja totalmente limpa após 30 dias. A implantação dos recursos associados a uma única identidade atribuída pelo usuário exigirá a criação de apenas uma entidade de serviço no Microsoft Entra ID, evitando o limite de taxa. Usar uma única identidade criada com antecedência também reduzirá o risco de atrasos de replicação que podem ocorrer se vários recursos forem criados cada um com sua própria identidade. Leia mais sobre os limites do serviço de assinatura do Azure.
Recursos/aplicativos replicados	Identidade atribuída pelo usuário	Recursos que executam a mesma tarefa – por exemplo, servidores Web duplicados ou funcionalidades idênticas em execução em um serviço de aplicativo e em um aplicativo em uma máquina virtual – normalmente exigem as mesmas permissões. Ao usar a mesma identidade atribuída pelo usuário, são necessárias menos atribuições de função, o que reduz a sobrecarga de gerenciamento. Os recursos não precisam ser do mesmo tipo.
Conformidade	Identidade atribuída pelo usuário	Se a organização exigir que toda a criação de identidade precise passar por um processo de aprovação, usar uma única identidade atribuída pelo usuário em vários recursos exigirá menos aprovações do que as identidades atribuídas pelo sistema, que são criadas à medida que novos recursos são criados.
Acesso necessário antes da implantação de um recurso	Identidade atribuída pelo usuário	Alguns recursos podem exigir acesso a determinados recursos do Azure como parte da implantação. Nesse caso, uma identidade atribuída pelo sistema não pode ser criada a tempo, então, uma identidade atribuída pelo usuário preexistente deve ser usada.
Log de auditoria	Identidade atribuída pelo sistema	Se você precisar registrar em log o recurso específico que executou uma ação, em vez da identidade, use uma identidade atribuída pelo sistema.
Gerenciamento do ciclo de vida de permissões	Identidade atribuída pelo sistema	Se você precisar que as permissões de um recurso sejam removidas junto com o recurso, use uma identidade atribuída pelo sistema.

Usar identidades atribuídas pelo usuário para reduzir a administração

Os diagramas demonstram a diferença entre as identidades atribuídas pelo sistema e pelo usuário quando usadas para permitir que várias máquinas virtuais acessem duas contas de armazenamento.

O diagrama mostra quatro máquinas virtuais com identidades atribuídas pelo sistema. Cada máquina virtual tem as mesmas atribuições de função que concedem acesso a duas contas de armazenamento.

Quando uma identidade atribuída pelo usuário é associada às quatro máquinas virtuais, somente duas atribuições de função são necessárias, em comparação com oito nas identidades atribuídas pelo sistema. Se a identidade das máquinas virtuais exigir mais atribuições de função, elas serão concedidas a todos os recursos associados a essa identidade.

Os grupos de segurança também podem ser usados para reduzir o número de atribuições de função necessárias. Este diagrama mostra quatro máquinas virtuais com identidades atribuídas pelo sistema que foram adicionadas a um grupo de segurança com as atribuições de função adicionadas ao grupo em vez de às identidades atribuídas pelo sistema. Embora o resultado seja semelhante, essa configuração não oferece os mesmos recursos de modelo do Resource Manager que as identidades atribuídas pelo usuário.

Várias identidades gerenciadas

Recursos compatíveis com identidades gerenciadas podem ter uma identidade atribuída pelo sistema e uma ou mais identidades atribuídas pelo usuário.

Esse modelo dá flexibilidade para usar uma identidade atribuída pelo usuário compartilhada e aplicar permissões granulares quando necessário.

No exemplo a seguir, "Máquina virtual 3" e "Máquina virtual 4" podem acessar as contas de armazenamento e os cofres de chaves, dependendo da identidade atribuída pelo usuário usada durante a autenticação.

No exemplo a seguir, "Máquina virtual 4" tem uma identidade atribuída pelo usuário que dá acesso a contas de armazenamento e cofres de chaves, dependendo de qual identidade é usada durante a autenticação. As atribuições de função para a identidade atribuída pelo sistema são específicas para essa máquina virtual.

Limites

Veja os limites para identidades gerenciadas, funções personalizadas e atribuições de função.

Seguir o princípio de privilégios mínimos ao permitir acesso

Ao conceder permissões para acessar serviços a qualquer identidade, incluindo uma identidade gerenciada, sempre conceda as permissões mínimas necessárias para executar as ações desejadas. Por exemplo, se uma identidade gerenciada for usada para ler dados de uma conta de armazenamento, não será necessário permitir que essas permissões de identidade também gravem dados na conta de armazenamento. A concessão de permissões extras, por exemplo, fazer com que a identidade gerenciada seja um colaborador em uma assinatura do Azure quando isso não for necessário, aumenta o risco à segurança associado à identidade. É sempre necessário minimizar o risco à segurança para que o comprometimento dessa identidade cause o mínimo de danos.

Considerar o efeito de atribuir identidades gerenciadas a recursos do Azure e/ou conceder permissões de atribuição a um usuário

É importante observar que, quando um recurso do Azure, como um aplicativo lógico do Azure, uma função do Azure, uma máquina virtual ou outros, é atribuído a uma identidade gerenciada, todas as permissões concedidas à identidade gerenciada ficam disponíveis ao recurso do Azure. Isso é importante principalmente porque, se um usuário tiver acesso para instalar ou executar código nesse recurso, ele terá acesso a todas as identidades atribuídas/associadas ao recurso do Azure. A finalidade da identidade gerenciada é dar ao código em execução em um recurso do Azure o acesso a outros recursos, sem que os desenvolvedores precisem processar ou colocar credenciais diretamente no código para obter esse acesso.

Por exemplo, se uma identidade gerenciada (ClientId = 1234) receber acesso de leitura/gravação para StorageAccount7755 e tiver sido atribuída a LogicApp3388, então Alice, que não tem acesso direto à conta de armazenamento, mas tem permissão para executar código em LogicApp3388, poderá ler/gravar dados de e para StorageAccount7755 executando o código que usa a identidade gerenciada.

Da mesma forma, se Alice tiver permissões para atribuir a identidade gerenciada, ela poderá atribuí-la a um recurso diferente do Azure e ter acesso a todas as permissões disponíveis para a identidade gerenciada.

Em geral, ao conceder a um usuário acesso administrativo a um recurso que possa executar código (como um aplicativo lógico) e tenha uma identidade gerenciada, considere se a função que está sendo atribuída a ele pode instalar ou executar código no recurso e, se puder, atribua essa função somente se o usuário realmente precisar dela.

Manutenção

As identidades atribuídas pelo sistema são excluídas automaticamente quando o recurso é excluído, enquanto o ciclo de vida de uma identidade atribuída pelo usuário é independente de todos os recursos com os quais está associado.

Você precisará excluir manualmente uma identidade atribuída pelo usuário quando ela não for mais necessária, mesmo que nenhum recurso esteja associado a ela.

As atribuições de função não são excluídas automaticamente quando as identidades gerenciadas atribuídas pelo sistema ou pelo usuário são excluídas. Essas atribuições de função devem ser excluídas manualmente para que o limite de atribuições de função por assinatura não seja excedido.

As atribuições de função associadas a identidades gerenciadas excluídas serão exibidas com "Identidade não encontrada" quando mostradas no portal. Leia mais.

As atribuições de função que não estão mais associadas a um usuário ou uma entidade de serviço serão exibidas com um valor ObjectType de Unknown. Para removê-las, você pode combinar vários comandos do Azure PowerShell para primeiro obter todas as atribuições de função, filtrar somente as que têm um valor ObjectType de Unknown e, em seguida, remover essas atribuições de função do Azure.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

Limitação no uso de identidades gerenciadas para autorização

O uso de grupos do Microsoft Entra ID para permitir acesso a serviços é uma ótima maneira de simplificar o processo de autorização. A ideia é simples: conceder permissões a um grupo e adicionar identidades ao grupo para que os membros herdem as mesmas permissões. Esse é um padrão bem estabelecido em vários sistemas locais e funciona bem quando as identidades representam os usuários. Outra opção para controlar a autorização no Microsoft Entra ID é usar funções de aplicativo, que permite declarar funções específicas a um aplicativo (em vez de grupos, que são um conceito global no diretório). Assim, você pode atribuir funções de aplicativo para identidades gerenciadas (bem como usuários ou grupos).

Nos dois casos, para identidades que não são de pessoas, como identidades de aplicativos do Microsoft Entra e gerenciadas, o mecanismo exato de apresentação dessas informações de autorização ao aplicativo não muito adequado hoje em dia. A implementação atual com o Microsoft Entra ID e o Azure RBAC (controle de acesso baseado em função do Azure) usa tokens de acesso emitidos pelo Microsoft Entra ID para autenticação de cada identidade. Se a identidade for adicionada a um grupo ou uma função, isso será expresso como declarações no token de acesso emitido pelo Microsoft Entra ID. O Azure RBAC usa essas declarações para avaliar ainda mais as regras de autorização a fim de permitir ou negar o acesso.

Considerando que os grupos e as funções de identidade são declarações no token de acesso, as alterações de autorização não entram em vigor até que o token seja atualizado. Para pessoas, isso não é problema, pois o usuário pode adquirir um novo token de acesso fazendo logoff e logon novamente (ou aguardando o tempo de vida do token expirar, que é uma hora por padrão). Já os tokens de identidade gerenciada são armazenados em cache pela infraestrutura subjacente do Azure para fins de desempenho e resiliência: os serviços de back-end das identidades gerenciadas mantêm um cache por URI de recurso durante cerca de 24 horas. Isso significa que pode levar várias horas para que as alterações em uma associação de grupo ou de função de uma identidade gerenciada entrem em vigor. No momento, não é possível forçar o token de uma identidade gerenciada a ser atualizado antes da expiração. Se você alterar a associação de grupo ou de função de uma identidade gerenciada para adicionar ou remover permissões, poderá ser necessário aguardar várias horas para que o recurso do Azure que usa a identidade tenha o acesso correto.

Se esse atraso não for aceitável para seus requisitos, considere alternativas ao uso de grupos ou funções no token. Para garantir que as alterações nas permissões de identidades gerenciadas entrem em vigor rapidamente, recomendamos agrupar recursos do Azure usando uma identidade gerenciada atribuída pelo usuário com permissões aplicadas diretamente à identidade, em vez de adicionar ou remover identidades gerenciadas de um grupo do Microsoft Entra que tenha permissões. Uma identidade gerenciada atribuída pelo usuário pode ser usada como um grupo porque ela pode ser atribuída a um ou mais recursos do Azure que a usarão. A operação de atribuição pode ser controlada usando a função Colaborador de identidade gerenciada e Operador de identidade gerenciada.