Recomendações de melhores práticas para identidade geridas

As identidades gerenciadas para recursos do Azure são um recurso do Microsoft Entra ID. Cada um dos serviços do Azure que suportam as identidades geridas para os recursos do Azure estão sujeitos à sua própria linha de tempo. Certifique-se de que revê o estado de disponibilidade das identidades geridas para o seu recurso e problemas conhecidos antes de começar.

Escolhendo identidades gerenciadas atribuídas ao sistema ou ao usuário

As identidades gerenciadas atribuídas pelo usuário são mais eficientes em uma ampla gama de cenários do que as identidades gerenciadas atribuídas pelo sistema. Consulte a tabela abaixo para alguns cenários e as recomendações para atribuídos pelo usuário ou pelo 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 aos quais estão associados. Leia quais recursos suportam identidades gerenciadas.

Esse ciclo de vida permite que você separe 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 ao sistema são criadas e excluídas junto com o recurso, as atribuições de função não podem ser criadas antecipadamente. Essa sequência pode causar falhas durante a implantação da infraestrutura se o usuário que cria o recurso também não tiver acesso para criar atribuições de função.

Se sua 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 administrativa será reduzida, pois há menos identidades distintas e atribuições de função para gerenciar.

Se você exigir que cada recurso tenha sua própria identidade ou tiver recursos que exijam 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 ao sistema.

Scenario Recomendação Notas
Criação rápida de recursos (por exemplo, computação efêmera) com identidades gerenciadas Identidade atribuída pelo utilizador 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 ao sistema – poderá exceder o limite de taxa para criações de objetos do Microsoft Entra e a solicitação falhará com um erro HTTP 429.

Se os recursos estão sendo criados ou excluídos rapidamente, você também pode exceder o limite do número de recursos no Microsoft Entra ID se estiver usando identidades atribuídas pelo sistema. Embora uma identidade atribuída ao sistema excluída não seja mais acessível por nenhum recurso, ela contará para o seu limite até ser 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 na ID do Microsoft Entra, evitando o limite de taxa. O uso de uma única identidade criada antecipadamente 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 utilizador Recursos que executam a mesma tarefa – por exemplo, servidores Web duplicados ou funcionalidade idêntica em execução em um serviço de aplicativo e em um aplicativo em uma máquina virtual – normalmente exigem as mesmas permissões.

Usando a mesma identidade atribuída pelo usuário, menos atribuições de função são necessárias, o que reduz a sobrecarga de gerenciamento. Os recursos não precisam ser do mesmo tipo.
Conformidade Identidade atribuída pelo utilizador Se sua organização exigir que toda a criação de identidade passe por um processo de aprovação, o uso de 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 de um recurso ser implantado Identidade atribuída pelo utilizador Alguns recursos podem exigir acesso a determinados recursos do Azure como parte de sua implantação.

Neste caso, uma identidade atribuída ao sistema pode não ser criada a tempo, pelo que deve ser utilizada uma identidade pré-existente atribuída pelo utilizador.
Log de auditoria Identidade atribuída pelo sistema Se você precisar registrar qual recurso específico executou uma ação, em vez de qual identidade, use uma identidade atribuída ao 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 ao sistema.

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

Os diagramas demonstram a diferença entre 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 lhes concede acesso a duas contas de armazenamento.

Four virtual machines using system-assigned identities to access a storage account and key vault.

Quando uma identidade atribuída pelo usuário é associada às quatro máquinas virtuais, apenas duas atribuições de função são necessárias, em comparação com oito com 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.

Four virtual machines using a user-assigned identity to access a storage account and key vault.

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 das identidades atribuídas pelo sistema. Embora o resultado seja semelhante, essa configuração não oferece os mesmos recursos de modelo do Gerenciador de Recursos que as identidades atribuídas pelo usuário.

Four virtual machines with their system-assigned identities added to a security group that has role assignments.

Várias identidades gerenciadas

Os recursos que suportam identidades gerenciadas podem ter uma identidade atribuída ao sistema e uma ou mais identidades atribuídas pelo usuário.

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

No exemplo abaixo, "Máquina Virtual 3" e "Máquina Virtual 4" podem acessar contas de armazenamento e cofres de chaves, dependendo da identidade atribuída pelo usuário que eles usam durante a autenticação.

Four virtual machines, two with multiple user-assigned identities.

No exemplo abaixo, a "Máquina Virtual 4" tem uma identidade atribuída pelo usuário, dando-lhe 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 ao sistema são específicas para essa máquina virtual.

Four virtual machines, one with both system-assigned and user-assigned identities.

Limites

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

Siga o princípio do menor privilégio ao conceder acesso

Ao conceder qualquer identidade, incluindo uma identidade gerenciada, permissões para acessar serviços, sempre conceda o mínimo de permissões 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 há necessidade de permitir que essas permissões de identidade também gravem dados na conta de armazenamento. Conceder permissões extras, por exemplo, tornando a identidade gerenciada um colaborador em uma assinatura do Azure quando não é necessário, aumenta o raio de explosão de segurança associado à identidade. Deve-se sempre minimizar o raio de explosão de segurança para que o comprometimento dessa identidade cause danos mínimos.

Considere 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 ou uma Máquina Virtual, etc., recebe uma identidade gerenciada, todas as permissões concedidas à identidade gerenciada agora estão disponíveis para o recurso do Azure. Isso é importante porque, se um usuário tiver acesso para instalar ou executar código nesse recurso, o usuário terá acesso a todas as identidades atribuídas/associadas ao recurso do Azure. O objetivo da identidade gerenciada é dar ao código executado em um recurso do Azure acesso a outros recursos, sem que os desenvolvedores precisem manipular ou colocar credenciais diretamente no código para obter esse acesso.

Por exemplo, se uma Identidade gerenciada (ClientId = 1234) tiver recebido acesso de leitura/gravação a StorageAccount7755 e tiver sido atribuída a LogicApp3388, Alice, que não tem acesso direto à conta de armazenamento, mas tem permissão para executar código em LogicApp3388, também poderá ler/gravar dados de/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 mesma, ela poderá atribuí-la a um recurso diferente do Azure e ter acesso a todas as permissões disponíveis para a identidade gerenciada.

security scenario

Em geral, ao conceder a um usuário acesso administrativo a um recurso que pode executar código (como um aplicativo lógico) e tem uma identidade gerenciada, considere se a função que está sendo atribuída ao usuário pode instalar ou executar código no recurso e, em caso afirmativo, atribuir essa função apenas 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 quaisquer recursos aos quais ela esteja associada.

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 visualizadas no portal. Ler mais.

Identity not found for role assignment.

As atribuições de função que não estão mais associadas a um usuário ou entidade de serviço aparecerão com um ObjectType valor de Unknown. Para removê-los, você pode canalizar vários comandos do Azure PowerShell juntos para primeiro obter todas as atribuições de função, filtrar apenas aquelas com um ObjectType valor de e, em seguida, remover essas atribuições de Unknown função do Azure.

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

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

Usar grupos de ID do Microsoft Entra para conceder 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 herdem as mesmas permissões. Este é um padrão bem estabelecido de vários sistemas locais e funciona bem quando as identidades representam usuários. Outra opção para controlar a autorização no Microsoft Entra ID é usando Funções de Aplicativo, que permite declarar funções específicas de um aplicativo (em vez de grupos, que são um conceito global no diretório). Em seguida, você pode atribuir funções de aplicativo a identidades gerenciadas (bem como usuários ou grupos).

Em ambos os casos, para identidades não humanas, como Aplicativos Microsoft Entra e identidades gerenciadas, o mecanismo exato de como essas informações de autorização são apresentadas ao aplicativo não é ideal atualmente. A implementação atual com o Microsoft Entra ID e o Azure Role Based Access Control (Azure RBAC) usa tokens de acesso emitidos pelo Microsoft Entra ID para autenticação de cada identidade. Se a identidade for adicionada a um grupo ou função, isso será expresso como declarações no token de acesso emitido pela ID do Microsoft Entra. O RBAC do Azure usa essas declarações para avaliar melhor as regras de autorização para permitir ou negar acesso.

Dado que os grupos e funções da identidade são declarações no token de acesso, quaisquer alterações de autorização não terão efeito até que o token seja atualizado. Para um usuário humano, isso normalmente não é um problema, porque um usuário pode adquirir um novo token de acesso fazendo logout e entrando novamente (ou aguardando o tempo de vida do token expirar, que é de 1 hora por padrão). Os tokens de identidade gerenciados, por outro lado, são armazenados em cache pela infraestrutura subjacente do Azure para fins de desempenho e resiliência: os serviços back-end para identidades gerenciadas mantêm um cache por URI de recurso por cerca de 24 horas. Isso significa que pode levar várias horas para que as alterações no grupo ou associação de função de uma identidade gerenciada entrem em vigor. Hoje, não é possível forçar o token de uma identidade gerenciada a ser atualizado antes de seu vencimento. Se você alterar a associação de grupo ou função de uma identidade gerenciada para adicionar ou remover permissões, talvez seja 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 suas necessidades, considere alternativas ao uso de grupos ou funções no token. Para garantir que as alterações nas permissões para identidades gerenciadas entrem em vigor rapidamente, recomendamos que você agrupe os 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 pode ser atribuída a um ou mais recursos do Azure para usá-la. A operação de atribuição pode ser controlada usando a função Contribuidor de identidade gerenciada e Operador de identidade gerenciada.