Pular para o conteúdo

Inteligência de ameaças

Ransomware em provedor de nuvem no Japão para 495 clientes e testa planos de continuidade

O ataque à IDC Frontier, em 7 de outubro, deixou 495 empresas e governos locais sem acesso às próprias máquinas, inclusive uma emissora de cartões. Uma semana depois, só parte dos clientes tinha caminho claro para recuperar os dados.

Rede de pontos ligados por traços finos sobre fundo escuro esverdeado, com um único nó verde aceso, e o título One provider down, many businesses stopped.
Rede de pontos ligados por traços finos sobre fundo escuro esverdeado, com um único nó verde aceso, e o título One provider down, many businesses stopped.

Na madrugada de 7 de outubro de 2026, um ataque de ransomware parou parte da nuvem da IDC Frontier, provedora japonesa controlada pela SoftBank, e deixou 495 empresas e governos locais sem acesso às próprias máquinas virtuais, segundo a empresa. Uma semana depois, só os clientes que usavam a função de cópia instantânea (snapshot) da própria nuvem tinham caminho claro para recuperar os dados. Na leitura da Indene, o caso mostra o limite de um plano de continuidade que depende do mesmo provedor que falhou.

O que aconteceu

data fato fonte
7 de outubro, por volta das 3h40 acesso não autorizado à região Leste 1 da IDCF Cloud; no mesmo dia, a empresa confirma ransomware e isola a região IDC Frontier
7 de outubro 495 empresas e governos locais afetados; consoles de gestão acessíveis pela internet suspensos em todas as regiões, inclusive nas que não pararam IDC Frontier
8 de outubro a empresa diz que os dados das quatro zonas atingidas devem ser difíceis de recuperar e que a restauração depende das cópias guardadas pelos próprios clientes IDC Frontier
9 de outubro a Nissui retoma parte da entrada e saída de mercadorias da sua empresa de logística, cliente do provedor Nissui
14 de outubro backups confirmados íntegros: 194 dos 495 clientes, os que usavam a função de snapshot, podem extrair seus dados; nenhum sinal de que dados das máquinas virtuais tenham saído; registros cadastrais de 48 clientes consultados indevidamente no portal IDC Frontier

O efeito chegou a clientes de setores diferentes. A empresa de logística do grupo Nissui ficou dois dias sem conseguir movimentar mercadorias. A Six Apart desistiu de esperar e migrou seus servidores para outro provedor, a partir dos próprios backups, segundo a Impress Watch. No setor financeiro, a ViewCard, emissora de cartões do grupo JR East, informou em 9 de outubro a possibilidade de exposição de cerca de 4 milhões de endereços de e-mail de clientes guardados num serviço de envio hospedado no provedor, segundo a ITmedia e a NHK; a IDC Frontier concluiu depois que não houve saída de dados das máquinas virtuais.

O que os reguladores já mediram

O caso japonês não é isolado. No relatório de 2025 sobre incidentes graves de tecnologia sob o DORA, as autoridades europeias de supervisão financeira (ESAs) contaram 3.383 incidentes graves no setor financeiro da União Europeia, e 29% deles foram causados por falha de um prestador terceiro. Cerca de um terço teve impacto em mais de um país.

O panorama de ameaças de 2026 da ENISA, a agência europeia de cibersegurança, publicado em 22 de setembro, registra que ataques a cadeias de fornecimento, prestadores terceiros e ambientes de nuvem continuaram a produzir incidentes de grande escala. Na mesma direção, a União Europeia passou a supervisionar diretamente 19 provedores de tecnologia considerados críticos para o setor financeiro, e o Reino Unido fez o mesmo com quatro grandes provedores de nuvem a partir de julho de 2026.

O que isso significa para instituições financeiras

O primeiro aprendizado é sobre redundância. A IDC Frontier vende a separação entre regiões do Leste e do Oeste como forma de continuidade. Ainda assim, ao conter o ataque, suspendeu o console de gestão de todas as regiões. Os servidores das outras regiões continuaram funcionando, mas os clientes perderam o acesso direto à gestão deles: a própria empresa passou a ligar e desligar máquinas a pedido. Redundância dentro do mesmo provedor protege contra falha de um data center, não contra falha do provedor.

O segundo é sobre a cópia. Até 14 de outubro, o caminho de volta passava por backup que o cliente tivesse fora do ambiente atingido ou por uma função de snapshot que acabou preservada. Quem dependia só do que estava nas máquinas paradas ficou à espera do provedor.

A regra brasileira já pede o que faltou a muitos clientes. A Resolução CMN nº 4.893 exige que a instituição preveja alternativas de continuidade quando o serviço de nuvem relevante contratado no exterior não puder ser mantido, que o contrato garanta a transferência dos dados na saída e que o plano de resposta descreva o que fazer na interrupção do serviço contratado, incluindo a substituição do prestador. E o resultado dos testes de continuidade vai para o relatório anual ao conselho. A pergunta que o caso japonês deixa é se esse teste já simulou a parada do provedor inteiro, e não só de um servidor.

O que fazer agora

  1. Liste os serviços relevantes em nuvem e, para cada um, o que acontece se o provedor ficar indisponível por uma semana: o que para, quanto custa e quem decide.
  2. Mantenha cópia dos dados críticos fora do provedor principal, ou ao menos fora do mesmo plano de gestão, e teste a restauração dessa cópia.
  3. Inclua no teste de continuidade o cenário de parada total do provedor, com a perda do console de gestão, e registre o tempo real de retomada.
  4. Confira se os contratos de nuvem garantem a entrega dos dados na saída e se a instituição sabe executar essa saída sob pressão.
  5. Mapeie quantos serviços críticos dependem do mesmo provedor; a concentração que a Europa passou a supervisionar começa nesse inventário.

Na leitura da Indene, a parada de um provedor crítico é um dos cenários de perda que precisam de número: quanto tempo a operação aguenta, quanto custa cada dia e que prova existe de que a alternativa funciona. Leia a metodologia.


Referências