Entenda quais identidades representam suas aplicações e automações e conecte cada uma a uma finalidade, um responsável e aos acessos necessários.
Uma integração que consulta dados, um serviço que acessa armazenamento e uma automação de implantação precisam se autenticar. A identidade usada pelo software permite relacionar essa autenticação aos acessos concedidos.
A Microsoft usa o termo workload identities para identidades de cargas de trabalho, como aplicações, serviços e scripts. No Microsoft Entra, esse conjunto inclui aplicações, service principals e managed identities.
“Identidades não humanas” é uma categoria mais ampla: também pode abranger identidades de dispositivos. Este guia se concentra nas identidades de software e nas decisões de governança associadas a elas.
| Objeto | Papel no ambiente | Pergunta de governança |
|---|---|---|
| Objeto de aplicação | Define a aplicação no tenant de origem e serve de base para suas representações em tenants. | Quem mantém a configuração e a finalidade dessa aplicação? |
| Service principal | Representa a aplicação localmente em um tenant. Uma aplicação multitenant pode ter representações em diferentes tenants. | Que acessos foram concedidos à identidade neste tenant? |
| Managed identity | É representada por um service principal, sem um objeto de aplicação associado. Permite autenticação sem que a equipe gerencie credenciais desse mecanismo. | Qual recurso utiliza a identidade e quem responde por seus acessos? |
Esses objetos têm relações entre si. Evite contar cada registro como se fosse uma integração independente. Para os detalhes, consulte o guia de Service Principals.
Uma managed identity atribuída pelo sistema acompanha o ciclo de vida do recurso Azure ao qual está vinculada. Uma identidade atribuída pelo usuário tem ciclo de vida independente e pode ser associada a mais de um recurso.
Essa diferença muda a investigação de dependências. Antes de alterar uma identidade compartilhada, identifique todos os recursos que a utilizam.
A gestão automática de credenciais não determina quais acessos são necessários ao negócio. Registre a finalidade, os responsáveis operacionais e os recursos acessados, mesmo quando não houver um secret para renovar.
Descreva a integração em linguagem de negócio e indique os sistemas envolvidos. Um nome técnico sozinho raramente explica por que o acesso deve continuar existindo.
Registre o tenant, o tipo de identidade e os identificadores. Relacione aplicação, service principal e recurso associado quando isso se aplicar ao caso.
Identifique um contato técnico e um responsável pelo processo. Diferencie a responsabilidade operacional documentada dos owners configurados nos objetos.
Relacione as concessões observadas aos recursos de destino e à finalidade informada. Permissões de API e atribuições de acesso no Azure devem ser investigadas nas fontes correspondentes.
Combine uma data e gatilhos, como troca de fornecedor, mudança de função ou encerramento do sistema. Antes de retirar acessos, avalie dependências e valide os efeitos com os responsáveis.
| Sinal observado | Próxima investigação |
|---|---|
| Ninguém confirma a finalidade | Localizar os responsáveis e documentar a necessidade. |
| A justificativa de acesso está incompleta | Revisar as permissões e a decisão de consentimento. |
| Há credenciais mantidas pela equipe | Organizar vencimentos e renovação. |
| Não foram observados eventos de atividade | Verificar a cobertura antes de concluir desuso. |
Esses sinais orientam perguntas. A prioridade depende também dos dados acessíveis, da criticidade do processo e das dependências confirmadas; a tabela não representa uma pontuação automática de risco.
Conheça a proposta do AppsVision para reunir contexto sobre aplicações, responsáveis, permissões e credenciais no Microsoft Entra ID.
Ao avaliar a solução, confirme a cobertura necessária para seus tipos de identidade e suas fontes de acesso. Os dados disponíveis dependem das permissões concedidas e dos módulos habilitados.
Não exatamente. Identidades não humanas podem incluir dispositivos. Workload identities representam software; esse é o recorte deste guia.
Não. A equipe continua precisando justificar os acessos e acompanhar a finalidade, os responsáveis e as dependências da identidade.
Não. É necessário distinguir o objeto de aplicação de suas representações locais como service principals. O inventário deve preservar essas relações para evitar conclusões baseadas em contagens duplicadas.