Como Auditar Aplicações OAuth de Terceiros no Google Workspace

Pergunte à maioria dos administradores de TI quantas aplicações de terceiros têm acesso aos dados do seu Google Workspace e obterá um palpite, não um número. Essa incerteza é o problema. Sempre que um utilizador clica em "Iniciar sessão com o Google" ou instala um suplemento do Marketplace, concede a uma aplicação OAuth uma fatia duradoura de acesso aos dados organizacionais — e essa concessão sobrevive ao interesse do utilizador, à relevância do fornecedor e, muitas vezes, ao conhecimento do administrador.

Este artigo é um método prático para auditar essas concessões: onde encontrá-las, como avaliar quais são arriscadas e como fazer uma limpeza segura.

O que é, na prática, uma concessão OAuth

Quando um utilizador autoriza uma aplicação "com o Google", não está a entregar a sua palavra-passe. Está a conceder à aplicação um token delimitado a permissões específicas — *scopes* — que lhe permitem chamar APIs do Google em nome do utilizador (ou da organização). Um scope pode ser tão restrito como "ver o seu endereço de email" ou tão amplo como "ver, editar, criar e eliminar todos os seus ficheiros do Google Drive".

Duas propriedades tornam estas concessões dignas de auditoria:

• Persistem. Um token continua a funcionar até ser explicitamente revogado, a aplicação ser removida ou a conta ser desativada. "Deixei de usar essa ferramenta há um ano" não revoga nada.
• São iniciadas pelo utilizador. O acesso é concedido pela pessoa que clicou em "Permitir", não é aprovisionado pela TI. Esta é a definição clássica de shadow IT, e significa que o seu inventário de acessos está, por defeito, incompleto.

Onde encontrar o inventário

Existem dois pontos de observação.

A visão do utilizador encontra-se na Conta Google de cada pessoa, em *Segurança → Aplicações e serviços de terceiros* (anteriormente "Aplicações com acesso à sua conta"). Mostra o que um utilizador autorizou. Útil para verificações pontuais, impraticável em escala.

A visão do administrador encontra-se na consola de administração do Google, em *Segurança → Controlos de API → Controlo de acesso a aplicações* (juntamente com os relatórios de aplicações ligadas). Esta é a imagem ao nível de toda a organização: quais as aplicações ligadas, que scopes possuem e quantos utilizadores autorizaram cada uma. Para uma auditoria, é aqui que se trabalha.

Se tiver os privilégios de administrador adequados, os relatórios de tokens do Admin SDK podem enumerar os mesmos dados de forma programática, o que torna possível uma revisão contínua e automatizada, em vez de uma tarefa manual anual e morosa.

Como avaliar o risco

Nem toda a aplicação ligada é um problema. Uma ferramenta de agendamento de calendário que pode ler horários livres/ocupados é de baixo risco; uma aplicação de notas com acesso total ao Drive, usada por uma pessoa, é uma história diferente. Classifique cada aplicação segundo algumas dimensões:

• Amplitude do scope. Acesso total ao Drive, leitura/envio do Gmail e acesso ao diretório de administração são os scopes de risco elevado. Uma aplicação que pode ler e exfiltrar todos os ficheiros é a sua prioridade máxima, independentemente da confiança que aparente merecer.
• Sensibilidade daquilo a que pode aceder. O conteúdo do Drive e o acesso à caixa de correio superam em importância os metadados de perfil ou de calendário.
• Número e amplitude de utilizadores. Uma aplicação usada por uma só pessoa mas com acesso amplo é um risco silencioso e concentrado. Uma aplicação usada por toda a empresa merece atenção porque o seu raio de impacto é grande.
• Confiança no editor. Editores verificados e fornecedores conhecidos são apostas mais seguras do que aplicações não verificadas ou anónimas. O estado de verificação de aplicações do Google é um sinal útil, não uma garantia.
• Atividade. Uma aplicação que ninguém usa há meses é pura desvantagem: todo o risco, nenhum valor.

Uma forma simples de combinar estes fatores: tudo o que tenha um scope de risco elevado *e* baixa confiança *ou* nenhuma utilização recente vai para o topo da lista de limpeza.

Uma auditoria repetível, passo a passo

1. Enumerar. Retire a lista completa de aplicações ligadas e os respetivos scopes a partir da consola de administração (ou via API).
2. Classificar scopes. Assinale os perigosos — Drive completo, envio/leitura do Gmail, diretório e quaisquer scopes de administração.
3. Cruzar com a utilização. Identifique aplicações sem atividade recente e aplicações usadas por muito poucos utilizadores.
4. Verificar o editor. Assinale editores não verificados ou desconhecidos.
5. Decidir. Para cada aplicação: manter, restringir ou revogar. Documente a razão — o registo de decisões é o que torna a próxima auditoria mais rápida.
6. Revogar com segurança. Remova o acesso das aplicações que decidiu retirar e comunique com os poucos utilizadores que dependiam de uma ferramenta que está a remover.
7. Definir salvaguardas. Passe da limpeza para a prevenção: restrinja as instalações do Marketplace a aplicações aprovadas pelo administrador e bloqueie ou coloque em lista de permissões o acesso a scopes de alto risco, para que a dispersão não volte simplesmente a crescer.

Revogar sem quebrar nada

O medo que impede a maioria das limpezas é "e se revogar algo de que as pessoas precisam?". Mitigue-o:

• Comece pelas vitórias inequívocas: aplicações não verificadas com scopes amplos e nenhuma utilização recente.
• Para aplicações com uma pequena base de utilizadores, envie um aviso prévio antes de revogar; se ninguém se opuser, avance.
• Mantenha um registo do que revogou e quando, para que, se algo falhar, possa restaurá-lo de forma rápida e deliberada.

A revogação nas ferramentas do Google é imediata e reversível — um utilizador pode sempre voltar a autorizar uma aplicação de que genuinamente precise, desta vez com as suas salvaguardas em vigor.

Torne-a contínua

Uma auditoria pontual dá uma boa sensação e degrada-se imediatamente. Novas aplicações são ligadas no dia seguinte àquele em que terminou. A resposta duradoura é a deteção contínua: enumerar automaticamente as aplicações ligadas e os respetivos scopes, classificar cada uma e alertar quando surgir uma nova concessão de alto risco ou quando uma aplicação inativa detiver acesso amplo.

Essa mudança — de uma folha de cálculo periódica para um inventário sempre atualizado — é a diferença entre conhecer a sua exposição OAuth hoje e andar a adivinhá-la. É também um dos pilares de uma segurança mais abrangente do Google Workspace, ao lado da identidade, da partilha e da configuração.

Os scopes que devem fazê-lo parar para pensar

Como a amplitude do scope é o maior fator de risco isolado, ajuda saber quais os scopes OAuth que carregam peso real. Alguns padrões que vale a pena reconhecer ao ler a lista de permissões de uma aplicação:

• `drive` (Drive completo) — ler, criar, modificar e eliminar *todos* os ficheiros do Drive de um utilizador. Este é o scope de dados mais amplo que uma aplicação pode possuir, e é muito mais comum do que deveria ser; muitas aplicações pedem-no quando bastaria um scope mais restrito por ficheiro.
• `gmail.send` / `gmail.modify` / `mail.google.com` — a capacidade de enviar correio como o utilizador, ou de ler e modificar a caixa de correio. Uma aplicação com acesso à caixa de correio pode tanto exfiltrar correspondência como fazer-se passar pelo utilizador perante terceiros.
• **admin.directory.*** — ler ou gerir o seu diretório de utilizadores e grupos. Uma aplicação que detenha isto alcança toda a organização, não apenas um utilizador.
• `spreadsheets` / `documents` — acesso ao conteúdo do Sheets e do Docs, que frequentemente contêm exatamente os dados sensíveis (dados financeiros, planos, credenciais coladas "temporariamente") que mais deseja proteger.

Os scopes restritos e apenas de leitura — userinfo.email, calendar.readonly, drive.file (acesso apenas aos ficheiros que a própria aplicação criou) — são os que se deve incentivar. Ao avaliar uma nova ferramenta, prefira a versão que pede o mínimo possível.

Transformar a auditoria numa política

Uma auditoria bem-feita vale muito mais se terminar numa política permanente em vez de numa purga pontual. Três políticas evitam que a maior parte da dispersão volte a crescer:

• Instalações no Marketplace aprovadas pelo administrador. Exija a aprovação do administrador antes de os utilizadores poderem instalar aplicações do Marketplace, para que novas ligações sejam uma decisão e não uma predefinição.
• Controlo de acesso baseado em scopes. Bloqueie ou coloque explicitamente em lista de permissões os scopes de alto risco (Drive completo, Gmail, diretório). Uma aplicação que pretenda acesso total ao Drive deve ultrapassar uma fasquia; uma aplicação que pretenda apenas um endereço de email não deve.
• Um responsável fixo pela revisão periódica. Atribua a alguém a tarefa permanente de rever, de forma agendada, as novas concessões e as de alto risco. Revisões sem dono não acontecem.

Estas salvaguardas mudam a predefinição de "qualquer utilizador pode conceder qualquer acesso a qualquer aplicação" para "o acesso amplo é uma escolha deliberada e revista" — sem bloquear as ferramentas legítimas de que as pessoas genuinamente precisam.

A 8200.dev descobre as aplicações de terceiros ligadas ao seu Workspace, classifica-as por scope, confiança no editor e utilização, e destaca primeiro as arriscadas — de forma apenas de leitura e contínua. Consulte o que verificamos para a visão completa.

Quer ver que aplicações podem aceder aos seus dados neste momento? Inicie a sua auditoria de segurança gratuita e obtenha um inventário das aplicações OAuth ligadas, classificadas por risco, em todo o seu Google Workspace.