Shadow SaaS: a superfície de aplicações que ninguém homologou nem está olhando

Shadow IT existe desde muito antes de IA generativa virar pauta de segurança — e continua existindo, em paralelo, numa escala que a maioria das empresas subestima. Times de marketing assinam ferramenta de automação, times de produto conectam app de analytics, alguém do financeiro autoriza uma planilha em nuvem com "Entrar com Google" — tudo em minutos, sem passar por procurement nem por revisão de segurança.

O problema raramente é a ferramenta em si. É que ninguém no time de segurança sabe que ela existe, quais dados ela recebe, e qual nível de acesso ela ganhou no momento em que alguém clicou "permitir" numa tela de autorização OAuth.

Por que shadow SaaS nunca foi resolvido

A barreira de adoção despencou nos últimos anos: a maioria das ferramentas SaaS modernas não exige nem cartão corporativo — basta login social via Google ou Microsoft, e a conta está criada. Isso tira do radar dos controles tradicionais de compra qualquer sinal de que uma nova ferramenta entrou no ambiente.

Diferente de comprar um servidor ou contratar uma licença enterprise, esse tipo de adoção não gera nota fiscal visível pro financeiro nem ticket pra TI — só aparece, meses depois, quando alguém audita permissões OAuth concedidas e encontra dezenas de aplicativos que ninguém lembra de ter autorizado.

O que fica exposto quando ninguém homologa

Cada "Entrar com Google" ou "Entrar com Microsoft" concede escopo de permissão — às vezes leitura de e-mail, calendário, arquivo no Drive ou OneDrive — que raramente é revisado depois da concessão inicial. Um aplicativo de produtividade aparentemente inofensivo pode ter acesso de leitura a toda a caixa de entrada corporativa de quem autorizou, e continuar tendo esse acesso indefinidamente.

Isso é estruturalmente diferente do risco que shadow AI representa — lá o risco central é vazamento de dado via prompt; aqui é concessão de acesso persistente via integração, que sobrevive muito além do uso ativo da ferramenta.

Descoberta antes de bloqueio, de novo

A mesma lógica que vale pra shadow AI se aplica aqui: tentar bloquear sem antes mapear é começar pelo fim. CASB e ferramentas de SSPM (SaaS security posture management) conseguem hoje listar quais aplicativos têm OAuth ativo no ambiente, com qual escopo de permissão e usados por quantas pessoas — informação que normalmente surpreende até times de segurança maduros na primeira vez que rodam esse relatório.

Só com esse inventário é possível decidir com critério: quais integrações valem homologação formal, quais têm escopo de permissão desproporcional ao valor que entregam, e quais devem ser revogadas sem gerar reclamação, porque ninguém as usa há meses.

O risco que sobrevive ao desligamento do funcionário

Um padrão recorrente: um funcionário autoriza uma dúzia de aplicativos ao longo de dois anos de empresa, sai, e o processo de desligamento revoga o acesso dele aos sistemas principais — mas não toca nas integrações OAuth de terceiros que ele autorizou individualmente. Esses aplicativos continuam com acesso ativo aos dados corporativos, sem ninguém monitorando, potencialmente por anos.

Esse é o mesmo tipo de lacuna que aparece em identidade de máquina sem dono claro — só que aqui a credencial nasceu de uma ação individual de um funcionário, não de um pipeline técnico, o que a torna ainda mais fácil de esquecer no processo de offboarding.

Pequeno em cada caso, estrutural na soma

Nenhuma integração isolada parece grande risco — é exatamente por isso que a soma delas vira ponto cego. Empresas que já mapearam shadow SaaS costumam descobrir dezenas, às vezes centenas, de aplicativos com algum nível de acesso a dado corporativo, a maioria deles nunca avaliada por ninguém. Esse volume, mais do que qualquer aplicativo específico, é o verdadeiro tamanho do problema — e o motivo pelo qual tratar a stack de segurança como soma de decisões isoladas sempre subestima o risco real.

Nenhum app é pequeno demais pra auditar

A pergunta certa nunca foi "proibimos ferramenta nova" — é "sabemos o que já está conectado, com que acesso, e isso ainda faz sentido". A UNIQ ajuda clientes a construir essa visibilidade de SaaS como parte da arquitetura de Cloud & SaaS, sem tratar cada aplicativo descoberto como incidente, só como dado que faltava.