Acesso de terceiros na nuvem: como revisar integrações antes que virem brecha

Em 11 de novembro de 2026, o portal CISO Advisor publicou o relato de um ataque que chamou atenção de quem cuida de segurança em nuvem: um criminoso usou credenciais comprometidas de um fornecedor de plataforma de big data para entrar em ambientes de várias empresas clientes. Ninguém quebrou a nuvem. O invasor usou uma porta que as próprias empresas tinham aberto e esquecido.

Este artigo explica o que aconteceu, por que o problema é comum em empresas brasileiras e como fazer, em etapas, a gestão de acessos de fornecedores e integrações. A linguagem é de negócio, com os termos técnicos explicados no caminho.

Resposta direta: o que é o risco de acesso de terceiros na nuvem

É o risco de um fornecedor, uma ferramenta ou uma integração com permissão na sua nuvem ser invadido e, com isso, o invasor herdar o acesso que você deu a ele. A proteção é inventariar quem tem acesso, reduzir cada permissão ao mínimo, remover o que não é usado e monitorar o uso das credenciais.

O que aconteceu: um acesso confiável usado contra os próprios clientes

Segundo a reportagem do CISO Advisor, que se baseia em informações de pesquisadores de segurança, o ataque ocorreu entre 14 e 26 de outubro. O invasor comprometeu usuários de administração de identidade de um fornecedor de plataforma de dados e, a partir deles, assumiu funções (roles) em contas de diversos clientes que haviam configurado confiança nesse fornecedor.

O ponto central está no mecanismo. Fornecedores externos costumam usar um recurso da nuvem chamado de assunção de função: o cliente cria uma função com permissões e declara que a conta do fornecedor pode usá-la, recebendo credenciais temporárias. É uma prática legítima e muito comum. O problema é que a confiança fica registrada por meses ou anos, mesmo quando a integração já não é usada.

De acordo com a reportagem, o invasor mapeou recursos, buscou segredos em cofres de credenciais e em variáveis de ambiente de funções serverless, validou as chaves encontradas e baixou dados de armazenamento acessível. A empresa de nuvem informou que seus serviços funcionaram como projetado e recomendou revisar funções entre contas, remover acessos de integrações sem uso, aplicar privilégio mínimo e adicionar condições, como restrição de origem, nas políticas de confiança.

A lição para a gestão não é técnica. É de governança: o risco de uma empresa inclui os acessos que ela concedeu a terceiros e nunca revisou.

Por que isso importa agora para empresas brasileiras

O cenário de ameaças no país está pressionado. Uma reportagem da CNN Brasil cita estimativa da empresa de cibersegurança Vultus de que o Brasil pode acumular R$ 2,9 trilhões em prejuízos por ataques em três anos. A mesma matéria informa que o relatório Cost of a Data Breach, da IBM, apontou custo médio de uma violação de dados no Brasil de R$ 7,44 milhões em 2026, alta de 3,5% sobre os R$ 7,19 milhões do ano anterior.

São estimativas de mercado, e não previsões para uma empresa específica. Mesmo assim, ajudam a dimensionar a conta: investigação, restauração, medidas jurídicas e parada de operação custam mais do que a revisão de acessos que poderia ter evitado o incidente. Para a visão completa do relatório, consulte a página oficial do IBM Cost of a Data Breach.

Onde os acessos de terceiros se acumulam

Em quase toda empresa com mais de dois anos de nuvem, os acessos de terceiros crescem sem ninguém acompanhar. Os pontos mais comuns são:

• Plataformas de dados e BI que leem o armazenamento para gerar relatórios.
• Ferramentas de monitoramento e de backup com permissão ampla para enxergar tudo.
• Consultorias e fornecedores de implantação que receberam acesso durante um projeto já encerrado.
• Integrações entre sistemas, como o ERP da sua empresa conversando com a nuvem e com o e-commerce.
• Chaves de acesso de longo prazo guardadas em código, planilhas ou variáveis de ambiente.

Cada item é razoável sozinho. O risco aparece na soma, quando ninguém sabe dizer quantos acessos existem, quem é o dono de cada um e se ainda são necessários.

Tabela: sinal de alerta e ação recomendada

Sinal de alerta	Por que é um risco	Ação recomendada
Função de fornecedor sem uso há meses	A confiança continua válida e pode ser explorada	Remover a função ou a relação de confiança
Permissão de administrador para uma integração	Um ataque ao fornecedor vira acesso total ao seu ambiente	Trocar por permissões mínimas, só para o que a integração precisa
Chaves de acesso de longo prazo em código ou planilha	Qualquer vazamento dá acesso duradouro	Usar credenciais temporárias e guardar segredos em cofre
Ninguém responsável pelo acesso	Não há quem revise nem quem desligue	Definir um dono por fornecedor e por integração
Sem registro de uso revisado	O abuso só é notado depois do dano	Ativar logs e criar alertas para acessos fora do padrão
Acesso de consultoria após o fim do projeto	Porta aberta sem finalidade	Encerrar o acesso no checklist de término do contrato

Passo a passo: como revisar o acesso de terceiros na sua nuvem

O roteiro abaixo segue as recomendações divulgadas pela empresa de nuvem no episódio e a página de boas práticas de segurança em IAM da AWS. A ideia vale para qualquer provedor, porque o princípio é o mesmo.

Passo 1: faça o inventário de quem tem acesso

Liste todas as contas, funções, usuários de serviço e chaves que existem na nuvem. Separe o que é de pessoas, o que é de sistemas internos e o que é de fornecedores. Sem essa lista, nenhuma outra medida funciona.

Passo 2: dê um dono e uma finalidade a cada acesso

Para cada item, registre quem na empresa responde por ele e para que serve. Acesso sem dono e sem finalidade é candidato imediato a desligamento.

Passo 3: identifique o que não é usado

Use os relatórios de último uso que os provedores oferecem. Funções e chaves sem uso recente devem ser desativadas primeiro e removidas depois de um período de observação. Desativar antes de apagar permite voltar atrás se algo quebrar.

Passo 4: aplique o privilégio mínimo

Privilégio mínimo significa dar só a permissão necessária para a tarefa. Uma ferramenta de relatórios, por exemplo, precisa ler um conjunto de dados, não administrar a conta inteira. Comece pelos acessos de fornecedores com permissões mais amplas.

Passo 5: adicione condições na confiança

Nas políticas que permitem a um fornecedor assumir uma função, é possível exigir condições, como origem de rede conhecida ou um identificador combinado com o fornecedor. Isso reduz o estrago se as credenciais dele forem roubadas.

Passo 6: troque chaves de longo prazo por credenciais temporárias

Chaves permanentes em código e variáveis de ambiente são o alvo favorito de quem invade. Prefira credenciais temporárias e mantenha segredos em um cofre próprio, com rotação periódica.

Passo 7: ative logs, alertas e revisão periódica

Registre o uso de cada acesso e crie alertas para comportamentos fora do padrão, como leitura em massa de armazenamento. Marque no calendário uma revisão trimestral de todos os acessos de terceiros. A empresa de nuvem, no caso relatado, orientou administradores a revisar os registros desde 1º de outubro e a rotacionar credenciais expostas.

Passo 8: transforme o processo em rotina de contrato

Inclua em todo contrato com fornecedor a exigência de acesso mínimo, o prazo de validade e o desligamento no fim do projeto. O encerramento de acesso precisa constar no checklist de saída da consultoria ou do projeto.

Curiosidades que ajudam a entender o problema

• A nuvem não foi invadida. No caso relatado, a empresa de nuvem afirmou que seus serviços operaram como projetado. O erro estava em como as contas dos clientes confiavam em um terceiro.
• Funções sem uso foram o alvo. A reportagem destaca que o invasor assumiu funções que não vinham sendo usadas, o que mostra o custo de não limpar acessos antigos.
• O ataque foi oportunista. Segundo a reportagem, o invasor baixou dados do que estava acessível, sem buscar um alvo específico. Quem tem acesso aberto vira vítima por acaso.
• Velocidade. A reportagem cita a coleta de 100 senhas e chaves em sete minutos em um dos ambientes, o que torna inviável reagir só depois que o ataque começa.
• A IA reduz o custo de atacar. Na matéria da CNN Brasil, o CTO da Vultus afirma que a inteligência artificial permite encontrar e explorar vulnerabilidades com mais velocidade e menor custo.

Como isso se conecta ao restante da sua segurança

A revisão de acessos é uma peça de um conjunto. Ela funciona melhor quando combinada com outras medidas que a DKP já discutiu aqui no blog:

• Backup que resiste a ataque: veja backup corporativo contra ransomware.
• Proteção dos dados do sistema de gestão: leia ERP seguro e a proteção dos dados da empresa.
• Permissões para automações com IA: veja controle de acesso de agentes de IA.
• Ambientes em mais de um provedor, que multiplicam os pontos de acesso: leia multicloud e novos provedores no Brasil.

Se a sua empresa precisa de apoio para mapear acessos, desenhar a arquitetura e organizar a operação em nuvem, a consultoria em cloud da DKP trabalha exatamente nesse ponto, e a área de DevOps cuida de automação, segredos e entrega contínua com segurança.

Perguntas frequentes

Meu fornecedor foi invadido. O que faço primeiro?

Revogue as sessões e as relações de confiança com esse fornecedor, rotacione as credenciais que ele possa ter lido e revise os registros de acesso do período. Depois avalie quais dados ficaram expostos e acione o jurídico para verificar obrigações de comunicação.

Remover acessos sem uso pode quebrar alguma integração?

Pode, se a integração for usada raramente. Por isso a recomendação é desativar primeiro, observar por um período e só então apagar. Todo acesso removido deve ser anotado para facilitar a recuperação.

Preciso mesmo de revisão trimestral?

A frequência depende do tamanho do ambiente, mas uma data fixa no calendário evita que a revisão dependa de memória. Em ambientes que mudam muito, a revisão pode ser mensal para os acessos mais amplos.

Isso vale só para a AWS?

Não. O caso citado envolve a AWS, mas o princípio vale para qualquer provedor de nuvem: terceiros com acesso, permissões amplas e credenciais antigas formam o mesmo risco.

Qual o primeiro passo para uma empresa pequena?

Fazer o inventário e desligar o que ninguém sabe explicar. Só isso já reduz uma parte relevante da superfície de ataque, sem custo de ferramenta.

Quem deve ser o dono dos acessos de terceiros?

Quem contrata o fornecedor responde pelo acesso dele, com apoio da área de TI ou de segurança. Ter um nome por acesso é mais importante do que o cargo.

Conclusão

O ataque relatado em novembro de 2026 mostra que a segurança de uma empresa depende também da segurança de quem ela conectou à sua nuvem. A boa notícia é que a defesa é conhecida e está ao alcance da gestão: inventário, dono para cada acesso, privilégio mínimo, remoção do que não é usado e revisão periódica.

Comece esta semana pelo passo 1. Uma lista honesta de quem tem acesso à sua nuvem já mostra onde estão os maiores riscos. Se quiser ajuda para estruturar isso, fale com a DKP sobre consultoria em cloud.