Pontos cegos no SaaS: o perigo silencioso das integrações e APIs sem monitoramento
Uma aplicação SaaS pode estar homologada pela empresa, ter autenticação multifator habilitada, usuários devidamente cadastrados e um fornecedor com boas práticas de segurança. Ainda assim, pode existir um caminho para dados críticos que a equipe de segurança simplesmente não está enxergando.
Esse caminho pode ter começado de maneira bastante legítima: alguém conectou uma ferramenta ao CRM para automatizar uma tarefa. Outro time autorizou um aplicativo a acessar arquivos corporativos. Uma integração via API foi criada para um projeto que terminou meses atrás. Uma conta de serviço ganhou permissões temporárias que nunca foram removidas. Nada disso parece particularmente alarmante quando observado isoladamente, o problema aparece quando essas conexões se acumulam.
O SaaS tornou mais simples contratar aplicações, integrar plataformas e automatizar processos. Essa agilidade é uma das razões de sua adoção, mas também fragmentou a superfície que TI e Segurança precisam acompanhar. Hoje, proteger o ambiente não significa apenas saber quais aplicações a empresa utiliza. É necessário entender como elas se conectam, quais dados circulam entre elas e o que cada conexão está autorizada a fazer.
O SaaS mudou onde a responsabilidade pela segurança está
Existe uma diferença importante entre utilizar um serviço seguro e utilizar esse serviço de maneira segura. Em uma aplicação SaaS, boa parte da infraestrutura é administrada pelo provedor. Isso, porém, não elimina responsabilidades da empresa sobre usuários, dados, configurações, permissões e aplicações de terceiros conectadas ao ambiente. Na prática, é justamente aí que começam muitos pontos cegos.
A contratação descentralizada contribui para esse cenário. Uma área encontra uma ferramenta que resolve um problema, cria uma conta e começa a utilizá-la. Em alguns casos, basta um plano gratuito ou um cartão corporativo. O processo pode acontecer antes mesmo de TI ou Segurança saberem que aquela aplicação existe.
Surge então o Shadow SaaS: aplicações utilizadas com dados e identidades corporativas fora da visibilidade ou da governança esperada.
A consequência não é apenas uma lista de softwares desatualizada. Uma aplicação desconhecida também pode significar um fluxo de dados desconhecido, uma nova identidade, credenciais armazenadas em outro ambiente ou mais uma integração conectada aos sistemas da empresa.
E saber quais aplicações existem é apenas parte do problema.
Você sabe o que está conectado às suas aplicações?
Imagine um CRM utilizado diariamente por centenas de pessoas. Ao longo dos anos, diferentes equipes conectam ferramentas de analytics, automação, atendimento, enriquecimento de dados e produtividade. Algumas integrações são críticas. Outras foram utilizadas durante poucos meses. Há também aquelas que ninguém se lembra exatamente por que foram instaladas.
O CRM continua no inventário. Mas e as conexões? Permissões OAuth, chaves de API, tokens de integração, contas de serviço e outras identidades não humanas podem permanecer funcionando em segundo plano. Quando não existe revisão contínua, uma autorização criada para resolver uma necessidade pontual pode continuar ativa muito depois de essa necessidade desaparecer.
Um caso apresentado pela Check Point ajuda a dimensionar o problema. Uma empresa investigava mensagens persistentes de spear phishing aparentemente enviadas por funcionários. A troca dos equipamentos e das senhas não resolveu. Ao mapear as conexões SaaS-to-SaaS, a equipe encontrou a origem: uma ferramenta de newsletter instalada nas contas dos colaboradores continha um backdoor e estava sendo utilizada para enviar as mensagens.
O SaaS principal não precisava ser comprometido. A confiança concedida à integração já oferecia um caminho. É por isso que integrações merecem ser tratadas como parte da superfície de ataque, e não somente como recursos de produtividade.
APIs esquecidas também continuam sendo APIs
O mesmo raciocínio vale para APIs. Elas aparecem em praticamente todos os lugares: aplicações web, microsserviços, plataformas cloud, integrações com parceiros, aplicativos móveis e conexões entre sistemas internos. O desafio é que o ciclo de vida da API nem sempre acompanha o ciclo de vida do projeto que a criou.
Um time muda. Um fornecedor é substituído. Uma nova versão entra em produção. O endpoint anterior deixa de fazer parte da documentação, mas continua respondendo.
É nesse contexto que aparecem Shadow APIs, desconhecidas ou fora da gestão formal, e Zombie APIs, versões ou endpoints antigos que permanecem ativos mesmo depois de perderem sua função original. A Wiz defende descoberta contínua justamente para identificar APIs conhecidas, esquecidas e invisíveis no ambiente.
O problema também está presente no OWASP API Security Top 10. A categoria API9:2023 – Improper Inventory Management destaca o risco de versões antigas e endpoints deixados em execução, além da possibilidade de exposição de dados por meio de terceiros. Em outras palavras, documentação não é sinônimo de inventário e inventário também não é sinônimo de segurança.
Quando uma integração legítima vira um caminho de ataque
Uma API não precisa estar completamente aberta à internet para representar risco. Considere uma integração autenticada que utiliza um token válido. O acesso funciona exatamente como deveria, mas o token tem privilégios muito superiores aos necessários. Se essa credencial for comprometida, o atacante passa a operar com permissões legítimas.
Esse é um ponto importante: autenticar uma integração responde quem está fazendo a chamada. Não responde, por si só, tudo o que aquela identidade deveria poder fazer.
Escopos excessivos, tokens de longa duração e contas de serviço compartilhadas aumentam o impacto potencial de um comprometimento. Por isso, autorização, menor privilégio, expiração e capacidade de revogação precisam fazer parte do desenho da integração. Há ainda outra possibilidade: o problema estar no terceiro.
A própria OWASP inclui o Unsafe Consumption of APIs entre os principais riscos de segurança de APIs. A confiança depositada em serviços externos precisa ser considerada porque o atacante pode escolher comprometer uma integração ou fornecedor menos protegido para alcançar o ambiente que realmente deseja. Esse risco cresce conforme aumenta a quantidade de conexões.
Dados da
Check Point Research ajudam a colocar essa exposição em perspectiva. Em janeiro de 2024, ataques contra APIs atingiram, em média, uma em cada 4,6 organizações por semana na telemetria analisada, 20% acima de janeiro do ano anterior. Em ambientes cloud, o crescimento observado no mesmo comparativo foi de 34%.
O problema não é ter integrações. É perder o contexto delas
Bloquear integrações indiscriminadamente não é uma resposta realista. Uma das razões para utilizar SaaS é justamente permitir que aplicações trabalhem juntas. APIs sustentam processos de negócio, conectam plataformas e eliminam uma enorme quantidade de trabalho manual.
A pergunta mais útil na verdade é: A empresa sabe o que cada integração acessa, por que esse acesso existe e o que aconteceria se ele fosse comprometido?
Isso exige mais contexto do que uma lista de endpoints. Uma API pública sem acesso a informações sensíveis não deveria necessariamente receber a mesma prioridade de uma API exposta que alcança dados pessoais. Da mesma forma, uma configuração incorreta em um serviço interno isolado pode representar menos risco do que uma combinação de exposição externa, vulnerabilidade explorável e acesso a dados críticos.
A Wiz chama essas combinações de toxic combinations e propõe analisar o caminho completo entre API, exposição, recursos cloud e dados para determinar o risco que realmente merece prioridade.
Essa visão é particularmente relevante em arquiteturas
híbridas e multi-cloud. Conforme aplicações, identidades e dados atravessam diferentes ambientes, ferramentas ou equipes olhando cada camada isoladamente podem enxergar os componentes sem enxergar o caminho completo. A fragmentação da visibilidade se torna, ela própria, parte do problema.
Um inventário feito hoje pode estar errado amanhã
Há outro detalhe incômodo: ambientes SaaS não ficam parados. Novos usuários entram, pessoas mudam de área, aplicações são contratadas, permissões são concedidas, integrações são criadas, APIs ganham novas versões e contas de serviço aparecem para atender automações. Por isso, uma revisão anual dificilmente acompanha a velocidade das mudanças.
A ManageEngine coloca a descoberta e o inventário contínuo de aplicações como ponto inicial para a gestão de SaaS. Já a Wiz recomenda revisar regularmente integrações de terceiros e implementar monitoramento contínuo de atividades, configurações, permissões e padrões incomuns de acesso.
No campo de AppSec, a Qualys segue uma linha semelhante: descoberta precisa ser contínua e incluir aplicações e APIs conhecidas, desconhecidas, esquecidas e shadow. Além de descobrir, é necessário entender o que está efetivamente alcançável no ambiente em execução e priorizar o risco de acordo com exposição, criticidade do ativo, sensibilidade dos dados e impacto para o negócio. A lógica deixa de ser a de uma fotografia periódica e passa para uma postura contínua.
Como reduzir os pontos cegos sem transformar segurança em gargalo
O primeiro passo é simples de descrever e difícil de manter: descobrir o que realmente existe.O inventário precisa ir além das aplicações aprovadas e incluir APIs, integrações SaaS-to-SaaS, plugins, contas de serviço e outras conexões capazes de acessar dados ou executar ações.
Depois, vem o contexto. Para cada integração relevante, TI e Segurança precisam conseguir responder: quem é o responsável? Qual é a finalidade? Que dados são acessados? Quais permissões foram concedidas? A conexão está exposta? Ainda é utilizada?
A partir daí, algumas práticas se tornam fundamentais:
- aplicar menor privilégio e evitar escopos desnecessariamente amplos;
- revisar periodicamente integrações e revogar acessos que perderam sua finalidade;
- manter inventário vivo de APIs, incluindo versões, proprietários, consumidores e dependências;
- monitorar alterações de configuração, permissões e comportamentos anômalos;
- estabelecer expiração e rotação para credenciais e tokens quando aplicável;
- priorizar correções considerando exposição, dados acessíveis e impacto para o negócio, em vez de olhar apenas para uma severidade isolada.
O objetivo não é criar mais uma etapa burocrática antes de cada integração. Uma governança lenta demais tende a estimular atalhos e criar justamente o Shadow SaaS que se queria evitar. O controle precisa ser proporcional ao risco.
A conexão que ninguém monitora ainda pode ter acesso aos seus dados
SaaS e APIs não criaram o problema da confiança. O que aconteceu é que eles multiplicaram a quantidade de relações de confiança que uma empresa precisa administrar. Por isso, talvez a pergunta mais útil para uma equipe de TI hoje não seja apenas “quais aplicações utilizamos?”. Pode ser muito melhor levantar os questionamentos:
- Quais aplicações estão conectadas a elas?
- Que APIs continuam acessíveis?
- Quais identidades e tokens conseguem chegar aos dados críticos?
- E quem perceberia se uma dessas conexões começasse a se comportar de maneira diferente amanhã?
Quanto mais distribuído o ambiente, menos seguro é presumir que aquilo que consta no inventário representa tudo o que existe. Porque, em segurança, o ponto cego mais perigoso não é necessariamente aquilo que está desprotegido. Muitas vezes, é aquilo que continua tendo acesso e que ninguém mais está olhando.
