Como Ver Quais Aplicações Têm Acesso ao Seu Microsoft 365

Pode ver todas as aplicações com acesso ao seu tenant Microsoft 365 a partir do Microsoft Entra admin center, em Identity → Applications → Enterprise applications → All applications. Ao selecionar uma aplicação e abrir o seu separador Permissions, vê exatamente que dados do Microsoft Graph esta pode aceder, divididos entre permissões aprovadas pelos administradores da sua organização e permissões que os próprios utilizadores aprovaram para si mesmos.

Este guia aborda esse caminho na íntegra, a distinção entre consentimento de administrador e consentimento de utilizador que costuma confundir as pessoas, e o que uma revisão aplicação a aplicação não consegue mostrar.

Onde encontro a lista de aplicações com acesso no Entra?

1. Inicie sessão em entra.microsoft.com com uma conta que tenha, pelo menos, a função Cloud Application Administrator ou Application Administrator.
2. Aceda a Identity → Applications → Enterprise applications → All applications.
3. Selecione a aplicação que pretende rever e abra Permissions.

Isto lista todas as aplicações que foram adicionadas ao seu tenant através de consentimento de utilizador ou de administrador — incluindo assistentes de IA, bots de reuniões e extensões de produtividade que se ligam através da plataforma de identidade da Microsoft, a par das aplicações de negócio. A lista abrange tanto aplicações Microsoft de primeira parte como registos de terceiros, pelo que vale a pena percorrer a lista para além dos nomes familiares e ver que outras aplicações foram acumulando permissões silenciosamente ao longo do tempo.

Qual é a diferença entre consentimento de administrador e consentimento de utilizador?

O separador Permissions divide-se em duas partes:

• Admin consent — permissões concedidas para toda a organização por um administrador. Estas aplicam-se a todos os utilizadores abrangidos pela concessão, não apenas à pessoa que porventura clicou para aceitar.
• User consent — permissões que um indivíduo aprovou para si próprio, uma pessoa de cada vez, sem envolvimento de um administrador (quando as definições de consentimento do tenant o permitem).

Ao selecionar qualquer permissão listada, abre-se um painel Permission Details que descreve exatamente o que ela permite.

Como revogo o acesso de uma aplicação?

Para uma concessão de admin consent: abra a permissão na lista, selecione o controlo … junto a ela e escolha Revoke permission — isto funciona diretamente no portal.

Para uma concessão de user consent, o portal não tem botão de revogação. Retirá-la exige uma chamada à API do Microsoft Graph (DELETE /oAuth2PermissionGrants/{id} para permissões delegadas, ou a chamada equivalente a appRoleAssignments para permissões de aplicação) ou o cmdlet PowerShell correspondente, executado por alguém com a função Cloud Application Administrator. Revogar uma concessão também não impede que o mesmo utilizador volte a consentir da próxima vez que a aplicação o solicitar — para impedir isso é necessário alterar separadamente a política de consentimento do tenant, em Enterprise apps → Consent and permissions → User consent settings.

O que acontece quando um utilizador se depara com uma permissão que não pode conceder a si próprio?

Se um tenant restringir o consentimento de utilizador, uma pessoa que tente iniciar sessão numa aplicação que solicite uma permissão acima desse limite encontra um bloqueio em vez de uma concessão. Um Global Administrator pode ativar o admin consent workflow em Enterprise apps → Consent and permissions → Admin consent settings, o que permite a essa pessoa enviar um pedido em vez disso: este é enviado por email para os utilizadores, grupos ou funções definidos como revisores, que podem aprová-lo, bloqueá-lo ou negá-lo a partir do seu separador My Pending. Apenas um Global Administrator pode aprovar um pedido de permissões de aplicação do Microsoft Graph — ser designado revisor não confere, por si só, esse privilégio. Cada pedido também expira ao fim de um número configurável de dias, para que um pedido não revisto não fique pendente indefinidamente.

E se a minha organização abranger vários tenants Microsoft 365 ou um diretório de parceiro?

Uma revisão dentro de um único tenant mostra apenas esse tenant. Se a sua organização trabalhar em mais do que um diretório Microsoft 365 — uma empresa-mãe e uma subsidiária adquirida, por exemplo, ou o próprio tenant de um parceiro — cada um deles precisa deste mesmo procedimento em separado, com sessão iniciada com a função correta em cada um. As ferramentas fixas a um único tenant, criadas para uma única organização, deixam de funcionar assim que um segundo diretório entra em cena, pelo que qualquer ferramenta destinada a cobrir mais do que um tenant precisa de suportar o consentimento a partir do diretório próprio de qualquer organização, e não apenas daquele para o qual foi originalmente configurada.

O que é que uma revisão aplicação a aplicação não consegue mostrar, e como é que o 8200.dev responde a isso?

Percorrer as Enterprise applications uma aplicação de cada vez diz-lhe o que cada aplicação está *autorizada* a aceder. Não classifica as aplicações consoante o risco real que representam, não sinaliza que concessões ficaram desatualizadas, e não permanece estática enquanto percorre a lista — pode surgir um novo consentimento enquanto ainda está a rever o anterior. O conector Microsoft 365 do 8200.dev lê Sites, Files, Directory, Application registrations, Users, políticas de segurança do tenant, relatórios de registo de MFA, registos de auditoria, atribuições de funções e concessões de permissões delegadas — tudo através de âmbitos Graph só de leitura — e transforma tudo isso num inventário único, continuamente atualizado e classificado por risco, em vez de uma lista que tem de reabrir manualmente. O mesmo acesso só de leitura executa também uma auditoria de configuração à escala do tenant, a par do inventário de aplicações: estado das Security Defaults e das políticas de Conditional Access, política de consentimento de aplicações e definições de colaboração externa, de modo que uma aplicação com permissões excessivas e uma política de tenant demasiado permissiva que a deixou entrar aparecem em conjunto, em vez de em duas revisões distintas e sem ligação entre si. Liga-se da mesma forma ao próprio diretório de trabalho ou escolar do Microsoft de qualquer organização, pelo que um grupo que abranja mais do que um tenant não precisa de uma configuração separada para cada um. Todos os âmbitos aqui referidos são só de leitura: nada altera uma permissão ou uma política, a menos que a organização opte separadamente por automatizar uma ação específica.

Consulte a lista completa de conectores para perceber como isto se encaixa a par do Google Workspace, Slack e GitHub.