Como Auditar Aplicações OAuth de Terceiros no Slack, GitHub e Microsoft 365

Para auditar aplicações OAuth de terceiros, verifique separadamente a lista de autorizações própria de cada plataforma: a página Installed Apps do Slack, a política de aplicações OAuth da organização no GitHub, e a lista Enterprise applications do Microsoft Entra. Cada uma mostra uma fatia diferente do mesmo problema subjacente — que aplicações podem atuar sobre os seus dados — e nenhuma delas mostra as outras duas.

Este guia indica o caminho exato para cada plataforma, o que cada uma mostra, e onde uma auditoria por plataforma se esgota.

Onde vejo as aplicações OAuth autorizadas no Slack?

Vá a Settings & administration → Manage apps, o que abre o Slack Marketplace com âmbito limitado ao seu workspace, e depois selecione Installed Apps no topo da barra lateral. Isto está disponível em todos os planos do Slack e lista cada aplicação instalada com os scopes para os quais foi aprovada.

No Enterprise Grid, a secção Integrations do painel de administração acrescenta uma vista abrangendo toda a organização, em simultâneo, para todos os workspaces. Essa vista entre workspaces é alimentada pelo scope admin.apps:read, que está restrito ao Enterprise Grid e — mesmo aí — apenas revela quais aplicações estão aprovadas, restringidas ou pendentes; não expõe a lista completa de scopes de cada aplicação nessa mesma chamada. Num único workspace, a página Installed Apps continua a ser a fonte fidedigna sobre o que uma aplicação pode realmente fazer.

Onde vejo as aplicações OAuth autorizadas no GitHub?

Vá a Settings → Third-party Access → OAuth app policy da sua organização. As organizações novas têm as restrições de acesso a aplicações OAuth ativadas por predefinição, pelo que esta página é também onde os membros solicitam acesso a uma nova aplicação e onde um proprietário aprova ou nega esse pedido. Para revogar uma aplicação previamente aprovada, encontre-a na mesma lista e selecione Deny access.

As GitHub Apps (um mecanismo distinto das OAuth Apps clássicas, utilizado pela maioria das integrações modernas) são revistas noutro local: Settings → Integrations → GitHub Apps (ou Installed GitHub Apps) da organização lista o que está instalado e a que repositórios cada uma pode aceder.

A partir de 2026, uma organização pode também definir controlos graduados sobre quem sequer tem permissão para *solicitar* uma nova aplicação em primeiro lugar, a partir de Settings → Third-party Access: membros e colaboradores externos podem ambos solicitar aplicações (a predefinição há muito estabelecida), os colaboradores externos podem ser bloqueados enquanto os membros ainda podem solicitar, ou ambos os grupos podem ser impedidos de solicitar qualquer aplicação — reduzindo o âmbito da auditoria antes de um pedido sequer chegar à fila de um proprietário. A própria restrição de acesso a aplicações OAuth ao nível da organização também pode ser totalmente desativada, o que remove o passo de aprovação para todos os membros — uma definição que vale a pena confirmar que continua ativa antes de confiar na lista de política de aplicações OAuth como um registo completo do que foi autorizado.

Onde vejo as aplicações OAuth autorizadas no Microsoft 365?

Inicie sessão no Microsoft Entra admin center e vá a Identity → Applications → Enterprise applications → All applications. Selecione uma aplicação e depois Permissions. O separador Admin consent mostra as permissões concedidas para todo o tenant — e podem ser revogadas diretamente ali. O separador User consent mostra o que cada utilizador aprovou individualmente para si próprio — e o portal não oferece um botão de revogação para isso; para retirar essa autorização é necessária uma chamada à API Microsoft Graph ou um cmdlet do PowerShell executado por alguém com a função Cloud Application Administrator. Se um tenant bloquear totalmente o consentimento do utilizador, um Global Administrator pode ativar em alternativa um fluxo de aprovação de consentimento do administrador, transformando um pedido bloqueado num pedido revisível em vez de um beco sem saída — consulte o guia de acesso ao Microsoft 365 para perceber exatamente como funciona essa fila de revisão.

Por que motivo é difícil manter atualizada uma auditoria por plataforma?

Três consolas, três formatos, três funções de administrador diferentes apenas para as conseguir abrir. A vista programática de toda a organização no Slack exige Enterprise Grid; as concessões ao nível do utilizador na Microsoft exigem PowerShell ou Graph, e não um simples clique no portal; o GitHub separa as OAuth Apps clássicas das GitHub Apps como duas listas distintas que um administrador tem de saber verificar em separado. O Slack divide ainda a sua própria vista Installed Apps nos separadores Approved, Restricted e Requests, pelo que uma verificação completa implica confirmar três filtros para além das três plataformas. Nenhuma das três classifica uma aplicação por risco, e nenhuma delas indica se o mesmo fornecedor também está ligado nas outras duas plataformas com um conjunto de permissões mais amplo aí.

O que uma lista por plataforma não consegue mostrar, e como o 8200.dev responde a isso

Cada consola indica o que está autorizado nessa única plataforma. Nenhuma delas mostra o quadro combinado — o mesmo assistente de notas com IA ligado a canais do Slack, a um repositório do GitHub e a uma caixa de correio do Microsoft 365, cada um com o seu próprio scope concedido separadamente. O Agent Guard do 8200.dev lê as três com scopes de leitura apenas e de privilégio mínimo — no Slack, channels:read, groups:read, files:read, users:read e scopes de leitura relacionados, mais uma auditoria à configuração do workspace; no GitHub, read:org, acesso apenas de leitura a repositórios, read:user, inventário de instalações, visibilidade apenas de leitura da faturação do Copilot, e read:audit_log; e no Microsoft 365, Sites.Read.All, Files.Read.All, Directory.Read.All, Application.Read.All, User.Read.All, Policy.Read.All, Reports.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory e DelegatedPermissionGrant.Read.All — e reúne todas as conclusões das três plataformas num único inventário classificado por risco. O conector de Microsoft 365 funciona com o diretório de trabalho ou escolar próprio de qualquer organização, não com um único tenant fixo, pelo que se liga da mesma forma quer a sua organização seja a única em análise, quer seja uma entre várias.

Todos esses scopes são apenas de leitura. Nada aqui revoga por si só o acesso de uma aplicação — isso continua a ser uma recomendação sobre a qual uma organização atua deliberadamente, ou uma adesão explícita para a regra específica que pretende automatizar.

Consulte as páginas de conectores do Slack, do GitHub e do Microsoft 365 para a lista completa de scopes e o que cada um analisa.