Summary

  • A IDCF informou que o ransomware iniciado em 7 de outubro paralisou máquinas virtuais em quatro zonas da East Japan Region 1 e afetou 495 empresas e governos locais. Os comunicados não identificam o invasor nem esclarecem a situação do IDCF Cloud Backup.
  • A documentação do serviço de backup descreve cópias fora do local de produção e uma opção de armazenamento imutável. Isso não demonstra que o cliente possa acessar o catálogo quando o console da IDCF está suspenso, nem que tenha computação alternativa pronta.
  • Six Apart e Future Shop relataram caminhos distintos: a primeira migrou 31 servidores para a Sakura Cloud a partir de backups no Google Cloud; a segunda reconstruiu o envio de e-mails de dois serviços opcionais em outro data center. Nenhuma afirmou ter usado o IDCF Cloud Backup.

A diferença entre guardar uma cópia e recuperar um serviço apareceu nas próprias instruções da IDC Frontier. O terceiro comunicado recomendava preparar outro ambiente e reconstruir a partir de backups mantidos pelo cliente. Para usuários do IDCF Cloud Storage, a FAQ apresentava uma segunda rota: abrir o Google Cloud Storage pelo Google Cloud Console usando a conta e o projeto vinculados enquanto o console da IDCF estivesse fora do ar.

Essa rota trata do armazenamento GCS, não necessariamente do backup gerenciado. IDCF Cloud Storage e IDCF Cloud Backup são produtos distintos. A FAQ não diz se a referência genérica a serviços de backup indisponíveis incluía o BaaS da IDCF, quais clientes estavam nessa situação ou se algum cliente afetado o contratara. O acesso ao GCS não comprova que o repositório Veeam-Wasabi estivesse acessível.

A IDCF situa o início da ocorrência por volta das 03h40 do dia 7 de outubro, no horário do Japão. Nas zonas tesla, henry, pascal e joule, dentro da East Japan Region 1, as máquinas virtuais pararam e não podiam ser reiniciadas. A empresa avaliou que seria difícil extrair ou restaurar os dados e indicou, naquele momento, os backups em posse dos clientes como a via de recuperação disponível. Para conter danos, isolou a rede e interrompeu o console de gestão da região; também suspendeu consoles externos de outras regiões enquanto verificava sua segurança.

O quarto informe, publicado em 9 de outubro, descreveu uma estrutura emergencial com a SoftBank, orientações sobre backup e migração e investigação técnica com especialistas externos. Não comunicou que as cargas haviam sido restauradas. Ter uma equipe de resposta demonstra atividade, não a volta dos serviços ao usuário final.

O lançamento do IDCF Cloud Backup, em março de 2025, combinava o serviço Veeam para provedores com o Wasabi Hot Cloud Storage. A tabela publicada à época cobrava 3.500 ienes por servidor protegido ao mês e mais 5 ienes por gigabyte armazenado. A página atual fala em agente no sistema operacional, cópias incrementais, armazenamento em outro local, opção imutável e restauração em outro servidor; exige conexão à internet e informa que o armazenamento está disponível atualmente na área leste do Japão.

O guia começa a configuração no IDCF Cloud Console e depois abre o Veeam Service Provider Console. O documento de escopo também permite usuários locais do console de backup que não estejam vinculados a uma conta IDCF Cloud. Separar identidades pode ajudar, mas a documentação pública não demonstra se esses usuários conseguem entrar por um endereço direto quando o portal IDCF está parado, nem quais clientes tinham esse acesso pronto. “Outro local” também não define o domínio de falha: instalação, região, zona, provedor de identidade, console administrativo e destino da restauração não são a mesma coisa.

O fato de o armazenamento estar na região leste não prova nem sobreposição nem independência em relação às zonas atingidas.

Os relatos de clientes mostram o trabalho que não aparece na cobrança da cópia. A Six Apart disse que migrou 31 servidores do Movable Type Cloud para a Sakura Cloud até 21h de 8 de outubro, usando um backup das 01h de 7 de outubro armazenado no Google Cloud Storage. Mantinha sete cópias diárias. O ponto escolhido precedia o início divulgado da ocorrência em duas horas e quarenta minutos, mas não há informação sobre o volume de alterações perdido nesse intervalo nem sobre outros registros que possam ter reduzido a lacuna. A Sakura já fazia parte de uma oferta anunciada pela Six Apart em junho.

Ainda assim, a troca podia alterar endereços IP, capacidade e prazo; o caso não é uma promessa para todos os clientes da IDCF.

A dependência da Future Shop era mais delimitada. Só os servidores MTA de dois serviços opcionais de e-mail ficavam na IDCF; a loja virtual e o painel administrativo estavam em outra plataforma. A empresa construiu uma nova estrutura de envio em outro data center e retomou o future Scenario Cast às 12h20 e o futureCartRecovery às 12h30 de 9 de outubro. As mensagens previstas durante a interrupção não foram reenviadas automaticamente.

A Future Shop também informou que os servidores guardavam alguns endereços e trechos de mensagens que poderiam conter nomes, aniversários ou números de membro; os dados estavam criptografados em repouso e eram excluídos automaticamente após 14 dias. O início da invasão e o período potencialmente afetado continuavam desconhecidos. A volta do envio não encerrou a investigação sobre vazamento.

O preço por servidor e por gigabyte mede capacidade protegida, não o custo total para restabelecer a operação. Ficam de fora a computação de destino, a transferência de dados, as mudanças de rede e endereço, a recuperação de identidade, os testes da aplicação e a comunicação que não pode ser reenviada. Um exercício útil começa desligando o portal normal: verificar quem acessa o catálogo com outra identidade, escolher um ponto de restauração conhecido e recuperar uma carga representativa em um destino cuja autenticação, cobrança e capacidade não dependam do console indisponível.

O relógio deve parar quando o serviço volta a funcionar para o usuário, não quando termina a cópia dos arquivos.

As fontes públicas não mostram se o IDCF Cloud Backup foi usado, se seu console permaneceu acessível ou se algum cliente afetado tinha uma cópia ali. O episódio, portanto, não prova que o serviço falhou. Mostra que preservação dos dados, acesso ao catálogo e capacidade em outra plataforma são condições diferentes. O valor comercial do backup depende de todas as conexões necessárias sobreviverem justamente à falha que o cliente queria cobrir.

Fontes