Identidades gerenciadas atribuídas pelo sistema vs. atribuídas pelo usuário no Azure: qual escolher?

By Mirko Peters · 2026-10-26

Compare identidades gerenciadas atribuídas pelo sistema e atribuídas pelo usuário no Azure. Saiba qual tipo de identidade escolher para reduzir a sobrecarga administrativa e escalar com segurança.

Automatically translated with AI from the original post. Read the English original

Escolher entre identidades gerenciadas atribuídas pelo sistema e atribuídas pelo usuário no Azure é uma das decisões de arquitetura mais críticas para a segurança na nuvem e para a sobrecarga administrativa. Enquanto as identidades atribuídas pelo sistema estão diretamente ligadas ao ciclo de vida de um único recurso do Azure, as identidades atribuídas pelo usuário funcionam como entidades independentes que podem ser compartilhadas entre vários recursos, reduzindo drasticamente as atribuições de função redundantes e evitando gargalos de limite de tokens em ambientes automatizados.

Principais conclusões

• Identidades atribuídas pelo sistema são criadas, gerenciadas e excluídas automaticamente junto com o recurso do Azure ao qual pertencem.
• Identidades atribuídas pelo usuário existem de forma independente, como recursos autônomos do Azure, o que permite compartilhá-las entre várias VMs, aplicativos e funções.
• A Microsoft recomenda identidades atribuídas pelo usuário para a maioria dos cenários com vários recursos, para minimizar o trabalho de controle e as atribuições de função complexas.
• Usar identidades atribuídas pelo sistema em ambientes de teste que escalam rapidamente ou têm vida curta pode fazer com que as identidades se acumulem e acionem os limites de taxa do Azure.
• Um único recurso do Azure pode hospedar uma identidade atribuída pelo sistema para registros de log isolados e uma ou mais identidades atribuídas pelo usuário para cargas de trabalho compartilhadas.

Entendendo as principais diferenças

Quando você começa a arquitetar aplicações seguras na nuvem, sem segredos codificados diretamente no código ou cadeias de conexão fixas, precisa decidir como suas cargas de trabalho vão se autenticar no Microsoft Entra ID. O Azure oferece dois tipos distintos de identidades gerenciadas: atribuídas pelo sistema e atribuídas pelo usuário. Entender como elas funcionam por trás dos panos vai economizar incontáveis horas da sua equipe de engenharia com solução de problemas e manutenção administrativa.

Como funcionam as identidades atribuídas pelo sistema

Uma identidade gerenciada atribuída pelo sistema é ativada diretamente dentro de um recurso específico do Azure, como uma Máquina Virtual do Azure, um App Service ou um Function App. Pense nela como algo que nasce com o recurso e morre com ele. Quando você habilita uma identidade atribuída pelo sistema em uma máquina virtual, o Azure cria uma identidade no Microsoft Entra ID com exatamente o mesmo nome desse recurso.

A principal vantagem dessa abordagem é a simplicidade e o acoplamento do ciclo de vida. Como a identidade está vinculada ao recurso, você nunca precisa se preocupar com identidades órfãs permanecendo no diretório depois que uma máquina virtual é desativada. Se você excluir o recurso, o Azure exclui automaticamente a identidade para você. No entanto, esse acoplamento forte cria limitações arquiteturais quando você tem vários recursos que precisam de exatamente as mesmas permissões de acesso.

Como funcionam as identidades atribuídas pelo usuário

Já uma identidade gerenciada atribuída pelo usuário é criada primeiro como um recurso autônomo do Azure. Você lhe dá um nome personalizado, gerencia-a de forma independente dentro dos seus grupos de recursos e a associa explicitamente a um ou mais serviços do Azure que precisam de acesso. Como ela não está vinculada ao ciclo de vida de nenhuma máquina virtual ou App Service específico, ela persiste mesmo que todos os recursos associados a ela sejam excluídos.

Essa natureza independente transforma a forma como arquitetos de nuvem gerenciam o controle de acesso em escala. Em vez de tratar a autenticação como uma relação um-para-um entre um único servidor e um banco de dados, as identidades atribuídas pelo usuário permitem criar modelos de autenticação muitos-para-um, nos quais grupos de microsserviços compartilham um único contexto de segurança bem governado.

Sobrecarga administrativa e atribuições de função

As diferenças práticas entre esses dois tipos de identidade ficam muito evidentes quando você observa o gerenciamento de controle de acesso baseado em função (RBAC) em ambientes grandes. Sempre que você concede a uma identidade acesso a uma conta de armazenamento, um cofre de chaves ou um banco de dados, precisa criar uma atribuição de função do Azure.

Imagine um cenário corporativo comum: você tem quatro máquinas virtuais que precisam ler dados de duas contas de armazenamento do Azure separadas. Se você depender exclusivamente de identidades atribuídas pelo sistema, cada máquina virtual exigirá sua própria identidade dedicada. Para conceder o acesso, você precisará configurar oito atribuições de função separadas, uma para cada máquina em cada conta de armazenamento. Se você escalar para vinte máquinas virtuais, o número de atribuições de função cresce exponencialmente, criando um pesadelo administrativo.

Em contrapartida, se essas mesmas quatro máquinas virtuais compartilharem uma única identidade gerenciada atribuída pelo usuário, você precisará criar apenas duas atribuições de função no total. Você obtém exatamente o mesmo controle de acesso granular com uma fração do esforço de gerenciamento. Quando membros da equipe saem ou a infraestrutura é reconstruída, manter um diretório limpo fica drasticamente mais simples.

Armadilhas arquiteturais e casos extremos

Embora as identidades atribuídas pelo usuário sejam geralmente mais eficientes, escolher o tipo errado pode introduzir atritos operacionais ocultos. Um grande risco envolve recursos de computação de curta duração ou ambientes com escalonamento automático.

Se você provisiona e desprovisiona ambientes de desenvolvimento, teste ou em contêineres com rapidez ao longo do dia usando identidades atribuídas pelo sistema, essas identidades se acumularão no Microsoft Entra ID antes que as rotinas de limpeza sejam executadas. Com o tempo, as organizações podem atingir os limites de taxa do diretório do Azure, fazendo a plataforma rejeitar por completo novas solicitações de criação de recursos. Compartilhar uma identidade atribuída pelo usuário entre essas cargas de trabalho efêmeras evita completamente essa armadilha.

Por outro lado, as identidades atribuídas pelo sistema se destacam em dois cenários específicos:

• Auditoria e não repúdio: Se seus logs de segurança precisarem comprovar de forma definitiva qual máquina virtual exata executou determinada ação, as identidades atribuídas pelo sistema oferecem essa atribuição em nível granular, porque cada recurso mantém seu próprio objeto exclusivo no diretório.
• Limpeza rigorosa do ciclo de vida: Se os requisitos de conformidade determinarem que todas as permissões de acesso devem desaparecer exatamente no momento em que um recurso for encerrado, as identidades atribuídas pelo sistema fazem isso automaticamente, sem intervenção humana.

Lembre-se de que você não é obrigado a fazer uma escolha binária absoluta. Um único recurso do Azure pode ter ao mesmo tempo uma identidade atribuída pelo sistema para operações privadas e sensíveis e uma ou mais identidades atribuídas pelo usuário para fluxos de trabalho corporativos compartilhados.

Conclusão

Navegar pelo gerenciamento de identidades na nuvem da Microsoft exige equilibrar eficiência operacional com limites de segurança rigorosos. Ao entender as diferenças operacionais entre identidades atribuídas pelo sistema e atribuídas pelo usuário, você pode projetar arquiteturas robustas e escaláveis que eliminam segredos codificados sem gerar inchaço administrativo.

Para se aprofundar em como os tokens são emitidos, como o Azure Key Vault se integra sem senhas e quais armadilhas de segurança evitar, não deixe de ouvir o episódio completo do podcast para insights de especialistas e estratégias práticas.

Perguntas frequentes

Um único recurso do Azure pode usar identidades gerenciadas atribuídas pelo sistema e pelo usuário ao mesmo tempo?

Sim. Um recurso do Azure, como uma Máquina Virtual ou um Serviço de Aplicativo, pode ter uma identidade atribuída pelo sistema e uma ou mais identidades atribuídas pelo usuário habilitadas simultaneamente, permitindo combinar estratégias de autenticação dedicadas e compartilhadas.

O que acontece com uma identidade atribuída pelo usuário quando o recurso do Azure ao qual ela está vinculada é excluído?

Diferentemente das identidades atribuídas pelo sistema, que são excluídas automaticamente quando o recurso pai é removido, as identidades atribuídas pelo usuário persistem como objetos independentes no Azure até que um administrador as exclua explicitamente.

Por que a Microsoft recomenda identidades atribuídas pelo usuário para a maioria dos cenários com vários recursos?

A Microsoft recomenda identidades atribuídas pelo usuário principalmente para reduzir a sobrecarga administrativa e a proliferação de atribuições de função. Compartilhar uma única identidade entre vários recursos de computação reduz drasticamente o número de atribuições RBAC que você precisa criar e manter.

As identidades gerenciadas têm custo de execução no Azure?

Não, tanto as identidades gerenciadas atribuídas pelo sistema quanto as atribuídas pelo usuário são recursos gratuitos incluídos no Microsoft Entra ID para recursos do Azure, embora possam ser cobrados os custos padrão dos serviços de computação ou armazenamento aos quais você acessa.