Quem governa as identidades das suas aplicações no Entra ID?

O acesso continua existindo depois do projeto

Uma integração entra em produção, o projeto termina e a equipe muda. Meses depois, a aplicação pode continuar autorizada a acessar dados corporativos. A pergunta de governança é simples: alguém ainda consegue explicar por que esse acesso existe?

Na HubPartner, usamos observabilidade de identidades para descrever essa leitura conjunta de configuração, permissões, credenciais e sinais de atividade. Uma lista de nomes é o ponto de partida. O objetivo é dar contexto para decidir o que revisar e quem deve agir.

App Registration e Enterprise Application: duas perspectivas

O objeto de aplicação descreve a aplicação em seu tenant de origem. O service principal representa sua instância em um tenant. A área Enterprise Applications permite administrar esses service principals; App Registrations apresenta os registros de aplicação.

Por isso, um serviço de terceiros pode aparecer nas Enterprise Applications do cliente sem ter um App Registration local. AppID identifica a aplicação; o Object ID identifica cada objeto. Na análise de múltiplos clientes, o tenant também precisa fazer parte do contexto.

Referências: Microsoft Learn — Applications and service principals in Microsoft Entra ID

Midnight Blizzard: um caso real sobre aplicações legadas

No relato publicado em 25 de janeiro de 2024, a Microsoft descreveu como Midnight Blizzard comprometeu uma conta de um tenant de teste e alcançou uma aplicação OAuth legada com acesso elevado ao ambiente corporativo. O atacante abusou dessa aplicação e de permissões concedidas a outras aplicações para acessar caixas de correio.

A lição de governança que extraímos é revisar também os acessos concedidos a integrações de teste e legadas. O nome “teste” não delimita o impacto: é preciso verificar quais recursos a identidade consegue alcançar.

Referências: Microsoft Security Blog — Midnight Blizzard: Guidance for responders on nation-state attack · 25/01/2024

Quatro perguntas para sair da contagem e chegar à decisão

• Finalidade: qual processo depende desta identidade e qual seria o impacto de uma interrupção?
• Responsabilidade: quem valida os acessos e acompanha a próxima revisão?
• Capacidade: quais dados ela pode ler, alterar ou enviar, e em qual contexto de autorização?
• Evidência: o que a telemetria disponível permite afirmar sobre uso e mudanças recentes?

Ausência de evidência também precisa de contexto

Antes de chamar uma aplicação de inativa, registre a janela observada e confirme se a coleta foi concluída. Uma consulta incompleta não sustenta a mesma conclusão que uma janela completa sem atividade. A resposta operacional pode ser investigar a cobertura dos dados, antes de propor bloqueio.

Também vale separar a identidade de sua finalidade. Uma identidade possivelmente associada a um agente não equivale, por si só, a um agente confirmado. O inventário Entra não deve ser apresentado como o catálogo global de agentes do Microsoft 365.

Uma rotina que clientes e parceiros podem compartilhar

Como proposta de trabalho, reúna os achados por responsável, defina um prazo de revisão e registre a justificativa de cada decisão. Depois, acompanhe o que mudou. Esse ciclo permite ao parceiro agregar contexto de negócio e ao cliente consultar as evidências por conta própria.

O AppsVision foi pensado para apoiar a governança das identidades utilizadas pelas aplicações. Seu valor está na conexão entre inventário, risco e prioridade de revisão — com os limites da coleta visíveis para quem toma a decisão.