Ransomware atinge a IDC Frontier, da SoftBank: falha afeta 495 clientes

Em 7 de outubro de 2026, a IDC Frontier, empresa de Tóquio que oferece serviços de nuvem e pertence à SoftBank, informou que sofreu um ciberataque com ransomware. A falha na infraestrutura de TI afetou 495 clientes corporativos e órgãos de governo local do Japão. Segundo o The Asahi Shimbun, em 8 de outubro os especialistas em cibersegurança ainda trabalhavam nas consequências do incidente. A operação de logística e os serviços de governo eletrônico foram interrompidos.

O que se sabe e o que ainda não se sabe

O quadro público é escasso. A empresa confirmou o ataque de ransomware em si e a dimensão do problema: 495 clientes. A imprensa japonesa cita os setores afetados: logística e serviços digitais do governo. Não há mais nada em fontes abertas.

Não se sabe qual família de ransomware os atacantes usaram nem se exigiram resgate. Não foi divulgado se dados de clientes foram roubados ou se a criptografia ficou restrita à infraestrutura do provedor. Também não há estimativa de prazo para a recuperação completa. Essas lacunas importam: delas depende se o incidente continuará sendo uma falha operacional ou se evoluirá para um vazamento de dados.

• Empresa: IDC Frontier Inc., Tóquio, serviços de nuvem e data centers
• Controladora: SoftBank
• Data do anúncio do ataque: 7 de outubro de 2026
• Tipo de ataque: ransomware (malware de criptografia)
• Afetados: 495 clientes corporativos e órgãos de governo local
• Setores atingidos: logística, serviços de governo eletrônico
• Situação em 8 de outubro: investigação e recuperação em andamento

Por que um ataque a um provedor é mais perigoso do que um ataque a uma

única empresa

Quando um ransomware entra na infraestrutura de um operador de nuvem, ele atinge de uma vez todos os que rodam ali. Um único ponto de entrada vira centenas de paralisações. Os clientes, nesse caso, não cometeram erro nenhum: seus próprios sistemas podem estar perfeitamente protegidos, mas simplesmente não têm onde rodar.

A indústria já viu casos parecidos. Em 2022, um ataque ao provedor de hospedagem Rackspace derrubou seu serviço de Exchange hospedado. Em 2024, um ransomware paralisou a CDK Global, fornecedora de software para concessionárias de veículos nos EUA, e milhares de revendas voltaram a trabalhar no papel. No Japão, em 2023, um ataque ao sistema do porto de Nagoia interrompeu a operação de um terminal de contêineres. A lógica é sempre a mesma: quanto mais processos dependem de uma plataforma compartilhada, maior o custo da sua falha.

Para o Japão, o caso é emblemático também porque há municípios entre os afetados. Serviços públicos cada vez mais ficam em provedores de nuvem comerciais, e a resiliência desse arranjo é definida pelo elo mais fraco da cadeia de fornecedores.

Os data centers estão no centro das atenções agora por outro motivo. A SoftBank investe pesado em infraestrutura para IA, e as cargas de treinamento e inferência estão migrando para as mesmas nuvens e data centers de colocation onde já operam empresas e governo. Quanto mais densa fica essa infraestrutura, mais alto é o risco em torno de sua proteção.

O que as equipes que dependem da nuvem devem verificar

O que justifica uma revisão é o próprio formato do risco, além deste incidente. Um conjunto mínimo de perguntas para a arquitetura de TI da sua empresa é este:

• Os backups ficam fora da infraestrutura do provedor principal e isolados da rede (armazenamento offline ou immutable)?
• Quando foi a última vez que a restauração completa a partir do backup foi testada, com medição do tempo real?
• Existe um processo manual de emergência para operações críticas, como expedições ou recebimento de solicitações, para o caso de vários dias de paralisação?
• O que o contrato com o provedor diz sobre prazos de notificação de incidentes e sobre compensações?
• Os serviços críticos estão distribuídos entre locais ou provedores independentes, e não apenas entre zonas de um mesmo operador?
• Os acessos administrativos têm proteção por autenticação multifator e os privilégios são segregados?

É recomendável também definir com antecedência quem na empresa toma as decisões em caso de falha em um fornecedor e como os clientes serão avisados do problema. As primeiras horas de paralisação costumam ser gastas descobrindo quem é responsável por quê. O desdobramento do caso da IDC Frontier vai mostrar a rapidez com que o provedor restabeleceu os serviços e se dados de clientes foram afetados.