Entendendo o desafio do 'shadow IT', supply chains e o escopo do TPCRM
.png)
.png)
Um programa de Gestão de Risco Cibernético de Terceiros (Third-Party Cyber Risk Management – TPCRM) deve buscar entender e mitigar os riscos oriundos de terceiros, exatamente como a terminologia sugere. Escolher as ferramentas certas, os processos e as pessoas para alcançar esse objetivo é por si só um desafio, mas há um requisito oculto e inevitável: definir o que constitui um "terceiro" e, portanto, o escopo do programa e como ele compreende a cadeia de fornecedores digitais (a "cyber supply chain").
Antes mesmo da cibersegurança entrar como uma preocupação do programa de gestão de risco de terceiros (Third-Party Risk Management – TPRM), já se mostra bastante útil a categorização de fornecedores. Afinal, só alguns fornecedores são críticos para o negócio. No caso de serviços ou produtos mais específicos, um fornecedor pode estar vinculado a um risco operacional decorrente da falta de fornecedores alternativos, ainda que a interrupção do fornecimento não represente um risco imediato.
Quando começamos a olhar com mais cuidado para o risco cibernético, contudo, as complexidades se agravam. Parceiros de negócio podem ter dados sensíveis em seus sistemas mesmo quando as redes corporativas não possuem uma conexão permanente.
Em operações normais, clientes geralmente só têm acesso a seus próprios dados, mas os privilégios de acesso concedidos a eles podem exigir um plano de mitigação para um cenário em que a conta de um cliente é comprometida ou usada por um insider mal-intencionado de maneira deliberada.
Considerando a universalização das experiências conectadas e digitais, pode parecer anacrônico lembrar da existência do "ciberespaço" hoje. Porém, não podemos esquecer que os sistemas de IT carecem da "fisicalidade" de outros produtos e serviços. Na prática, uma empresa pode estar amparada por dezenas de terceiros que ela não enxerga, cada qual atrelado a vários riscos intangíveis. São entidades que, formalmente, não são fornecedores, parceiros ou clientes, mas são terceiros vinculados à empresa.
Isso é o que chamamos do problema do "shadow IT", ou a "TI escura".
O "Shadow IT" e o "cyber supply chain"
Se alguém traz um novo objeto ou prestador de serviços ao escritório, não é difícil de ver o que está se passando. Por outro lado, se um colaborador digita dados sensíveis para realizar uma consulta em um site de buscas ou envia documentos confidenciais a uma plataforma externa, não há certeza de que haverá algo para ser visto.
Aliás, computadores e smartphones são equipamentos comuns hoje. Os colaboradores podem facilmente realizar essas tarefas em dispositivos pessoais, diminuindo a visibilidade da empresa.
Quando isso acontece, há um terceiro (e talvez dispositivos não autorizados) lidando com dados da empresa.
Infelizmente, esses são só exemplos básicos. Os casos mais extremos geralmente são característicos do setor de atuação da empresa. Nas empresas de tecnologia, os colaboradores podem ter autorização para utilizar recursos de computação em nuvem ou realizar mudanças em pipelines com integrações arbitrárias, o que abre chances para que ambientes de teste sejam expostos à rede, ou que qualquer ambiente seja conectado a outro de forma imprópria e não documentada.
Em universidades e institutos de pesquisa, sistemas de TI podem ser readaptados para novos projetos, possivelmente expondo partes da infraestrutura para a internet por acidente. Por exemplo, um servidor que havia recebido uma exceção em um firewall para um projeto anterior pode ser reutilizado em um sistema novo que deveria ser de uso interno. No entanto, a exceção no firewall permanece e, com isso, sistemas internos são expostos.
Olhando de forma mais abrangente, temos que ter em mente que um software é composto por vários componentes (ou "dependências"). Se um desses componentes têm uma falha, é bem possível que as aplicações construídas com ele possam ser comprometidas. É bem possível que algumas empresas não tenham ciência de que estão vulneráveis por causa de um componente de terceiro, especialmente quando se trata de sistemas especializados cujos componentes não foram catalogados.
Além disso, softwares podem receber atualizações ao longo do tempo, de tal maneira a invalidar avaliações de risco anteriores. Quando funções de rede ou nuvem são adicionadas, por exemplo, a empresa pode ter parte de seus dados em um sistema remoto mesmo quando não havia expectativa de que isso acontecesse.
Em certos cenários, são os próprios usuários que adicionam componentes. Extensões de navegador são um exemplo disso. Embora o alcance delas esteja teoricamente restrito ao navegador, esse perímetro não impõe muitas limitações considerando o volume de trabalho que realizamos através de plataformas e sistemas web.
Por estarem relacionados, esses problemas são agravantes uns dos outros. Quando não temos um inventário dos componentes que integram o software sendo utilizado nem temos uma lista completa de outros softwares e serviços usados por cada indivíduo da organização, os fatores desconhecidos se multiplicam.
Se não há ninguém que está tentando resolver essa lacuna de visibilidade sobre os riscos cibernéticos, pode ser preciso entregar este desafio ao programa de TPCRM.
A IA entra em cena
Embora o problema do "shadow IT" já existisse antes da adoção generalizada de sistemas e aplicações de inteligência artificial, é preciso reconhecer que a IA trouxe consigo alguns desafios nesta seara. Um deles vem da própria velocidade com que ela foi adotada, já que as empresas muitas vezes não conseguiram elaborar políticas de IA com a mesma agilidade, e nem todas encontraram formas intuitivas de integrar a IA em seus sistemas corporativos.
Enquanto algumas empresas incentivaram os colaboradores a procurarem individualmente alguma forma de usar a IA, outras organizações proibiram o uso dela, fazendo com que os colaboradores se vissem obrigados a experimentar ferramentas por conta própria sem a orientação necessária. Como a IA era uma novidade para praticamente todo mundo, até os cases de sucesso podem ocultar riscos que não foram contemplados pelas normas da empresa.
Em nosso artigo sobre o Verizon 2026 Data Breach Investigations Report, apontamos que 67% dos usuários se cadastram em serviços de IA usando contas pessoais para depois usá-los em equipamentos corporativos.
Mesmo quando os colaboradores usam um e-mail corporativo no cadastro, nem sempre isso é desejável. A IA tende a ser um produto moderno, com alta conectividade. Essas soluções podem solicitar um acesso contínuo aos dados da conta e, portanto, aos dados corporativos. Isso aumenta dramaticamente o risco de exposições.
Um incidente recente na Vercel, que comentamos em nosso newsletter, é um exemplo disso. Um colaborador concedeu permissões para um serviço de IA de tal maneira que, quando a infraestrutura dessa AI foi comprometida, os invasores puderam usar esse canal para obter tokens de autenticação e outros dados aos quais o colaborador tinha acesso. Como alguns destes dados pertenciam a clientes da Vercel, essa invasão em um terceiro que começou no fornecedor de IA se tornou um incidente para os clientes da Vercel.
Mesmo que uma empresa tenha optado por serviços que não incluem funções de IA, muitas plataformas e softwares estão adicionando essa funcionalidade em atualizações. Se a política e os processos não refletirem essa mudança, não haverá mitigação para esses riscos.
Sistemas de TI são altamente complexos, mas os provedores de serviços trabalham para mascarar essa complexidade e diminuir os obstáculos para sua utilização. A ausência de "atrito" muitas vezes faz com que os usuários não tenham total ciência dos riscos, ou mesmo a noção de que eles estão introduzindo um "terceiro" que não será monitorado como um fornecedor formal da empresa.
Um problema para todos
As empresas estão diante de uma luta árdua quando se trata de buscar conhecer quem são esses terceiros vinculados a tecnologias que entram informalmente na rede corporativa, e isso está ficando cada vez mais difícil. Mesmo assim, a escala do problema só fica realmente nítida quando percebemos que todos estão nesta luta, incluindo os próprios terceiros.
A superação dessas questões exige um conjunto multifacetado de abordagens. Conscientização de riscos, aprimoramento políticos e, talvez, o redesenho de processos corporativos. Os programas de gestão de risco cibernético de terceiros trazem resultados melhores quando eles vão além do onboarding e da verificação de contratos para conformidade.
As empresas precisam se manter a par das mudanças em seu ecossistema, incluindo aquelas derivadas de novos recursos nos softwares que utilizamos. Como as avaliações de risco pontuais rapidamente ficam defasadas diante das transformações rápidas do ambiente de TI, as empresas devem dar preferência a estratégias que tenham condições melhores de manter a visibilidade sobre os riscos que podem surgir.
Terceiros enfrentam esse mesmo desafio em seu ambiente de TI. É por isso que o monitoramento inside-out que oferece avaliações precisas e contínuas, pode contribuir de forma inestimável para a mitigação de riscos cibernéticos de terceiro, trazendo uma melhora real e mensurável para a segurança do negócio.
Quanto ao problema das aplicações e seus componentes, vale a pena integrar as listas de materiais de software (Software Bill of Materials – SBOMs) em seu inventário de ativos. Um SBOM é feito para ser consumido por um sistema com a finalidade de sustentar um catálogo das bibliotecas e dependências usadas para construir um software. Os SBOMs das várias aplicações corporativas podem ser compilados pelo sistema que os consome para oferecer insights valiosos para a gestão de riscos.
A mitigação dos riscos atrelados ao uso de IA por terceiro será assunto de um artigo dedicado que em breve estará disponível neste espaço. Não perca!


