Conceitos e riscos

Registros de aplicativos e Aplicativos empresariais: aplicações, identidades e agentes de IA

Entenda os nomes do Microsoft EntraID, a diferença entre aplicação e identidade e como agentes de IA usam identidades para acessar recursos.

Duas visões que se complementam

App Registrations reúne os registros de aplicações do tenant de origem. Enterprise Applications reúne suas representações locais, chamadas service principals. Uma aplicação própria pode aparecer nas duas áreas; elas não são inventários mutuamente exclusivos.

Referências: Microsoft Learn: Aplicações e service principals

Application ID e Object ID não são credenciais

O Application (client) ID identifica a aplicação. O registro e sua entidade de serviço têm Object IDs próprios. Em diferentes tenants, as representações de uma mesma aplicação podem compartilhar o Application ID, mas possuem Object IDs diferentes.

Saber um ID não basta para acessar dados. O fluxo precisa atender aos requisitos de autenticação e autorização. Proteja as credenciais e revise as permissões efetivas, em vez de tratar um identificador como senha.

Referências: Microsoft Learn: Aplicações e service principals

Onde entram as Apps Externas?

Chamamos de externas as soluções de fornecedores ou de outras organizações. Elas podem aparecer nas Enterprise Applications do cliente enquanto seu registro permanece no tenant do fornecedor. Portanto, “externa” e “Enterprise Application” não são sinônimos.

Exemplo: um sistema desenvolvido pela sua equipe pode ter registro e representação local no seu tenant. Já um serviço SaaS de terceiros pode ter apenas a representação local no seu ambiente.

Referências: Microsoft Learn: Aplicações e service principals

Como agentes de IA usam essas identidades

Assim como APIs e automações, agentes podem usar identidades para obter tokens e chamar serviços autorizados. A implementação pode utilizar uma entidade de serviço de aplicação, uma identidade gerenciada ou os recursos específicos do Microsoft EntraID Agent ID.

A Microsoft distingue identidades específicas de agentes das entidades de serviço tradicionais, embora compartilhem infraestrutura. Portanto, não é correto afirmar que todo agente aparece apenas como um App Registration comum.

Exemplo: um agente que consulta documentos precisa de autorização para essa consulta. Permitir também alterações ou acesso a informações sem relação com sua finalidade amplia o impacto de uma falha.

Um AppID isolado não comprova a existência de um agente de IA. Também não garante que o inventário de aplicações cubra todos os agentes de todas as plataformas.

Referências: Microsoft Learn: Agent identities, service principals and applications · Microsoft Learn: Atribuir identidades de agentes a aplicações

Login não é autorização irrestrita

Usar SSO permite autenticar usuários, mas não concede automaticamente acesso a todos os dados. O alcance depende das autorizações efetivas. Permissões delegadas envolvem o contexto de um usuário; permissões de aplicação podem permitir operação sem usuário conectado.

Referências: Microsoft Learn: Operações de segurança para aplicações

Riscos concretos quando falta gestão

  • Credencial exposta: alguém pode se passar pela aplicação e explorar o acesso que ela recebeu.
  • Permissões excessivas: uma integração comprometida pode alcançar mais dados ou executar mais ações do que o processo necessita.
  • Consentimento sem revisão: um serviço abandonado pode continuar autorizado.
  • Credenciais vencidas: integrações e rotinas de negócio podem parar.
  • Ausência de responsável: alertas e decisões de revisão podem ficar sem tratamento.

Referências: Microsoft Learn: Operações de segurança para aplicações

Um roteiro prático de revisão

Nossa sugestão é começar pela finalidade e pelo responsável. Depois, comparar as permissões concedidas com a necessidade real, verificar credenciais e investigar atividade recente.

Não exclua uma aplicação apenas porque não há data de último uso: a cobertura da coleta e as dependências precisam ser verificadas. Registre a decisão, o responsável e o resultado da revisão. O AppsVision ajuda a organizar essas informações para orientar o acompanhamento.

Sem uso não significa sem risco

Permissões excessivas ampliam o que agentes de IA, APIs e automações podem fazer e o impacto de um erro ou comprometimento. Mesmo sem uso, uma integração com credenciais válidas e autorizações ativas pode continuar sendo uma porta de acesso aos dados. Revise a necessidade de cada permissão e, após validar as dependências com o responsável, revogue os acessos que não são mais necessários.

Referências: Microsoft Learn: Operações de segurança para aplicações

Como o AppsVision ajuda a reduzir essa exposição

É nesse ponto que o AppsVision atua: reúne informações sobre permissões, credenciais, responsáveis e sinais de atividade das aplicações no Microsoft EntraID para ajudar sua equipe a identificar acessos excessivos, aplicações sem responsável e acessos cuja necessidade precisa ser reavaliada. Assim, o inventário se transforma em prioridades de revisão, inclusive para identidades usadas por agentes de IA, APIs e automações, quando presentes nos dados coletados.

A gestão dos AppIDs com o apoio do AppsVision contribui para reduzir a superfície de ataque, proteger a privacidade dos dados e tornar o ambiente de negócios mais seguro.

Fontes e leituras

  1. Microsoft Learn: Aplicações e service principals
  2. Microsoft Learn: Operações de segurança para aplicações
  3. Microsoft Learn: Agent identities, service principals and applications
  4. Microsoft Learn: Atribuir identidades de agentes a aplicações

Transforme informações em prioridades.

Conheça o AppsVision e sua proposta de governança das identidades utilizadas por aplicações no Microsoft EntraID.

Conhecer o AppsVision →