Summary

  • IDCF informó que el ransomware iniciado el 7 de octubre dejó máquinas virtuales detenidas e irrecuperables en cuatro zonas de East Japan Region 1 y afectó a 495 empresas y gobiernos locales. Sus comunicados no identifican al atacante ni explican la situación de IDCF Cloud Backup.
  • La oferta de respaldo describe almacenamiento fuera del sitio y una opción de inmutabilidad. Eso explica dónde se pretende guardar una copia, pero no si el cliente puede consultar el catálogo cuando se suspende la consola de IDCF o restaurar en una plataforma alternativa.
  • Six Apart y Future Shop comunicaron recuperaciones distintas: una trasladó 31 servidores a Sakura Cloud usando copias en Google Cloud; la otra reconstruyó el servicio de correo de dos productos opcionales en otro centro de datos. Ninguna dijo haber usado IDCF Cloud Backup.

La diferencia entre “hay una copia” y “el negocio puede volver” apareció en las instrucciones que IDC Frontier publicó durante la incidencia. La empresa recomendó crear otro entorno y recuperar los datos desde respaldos conservados por el cliente. Para usuarios de IDCF Cloud Storage, su FAQ describió otra salida: acceder a Google Cloud Storage desde Google Cloud Console con la cuenta y el proyecto vinculados mientras la consola de IDCF permanecía detenida.

Ese acceso directo no debe confundirse con la oferta de respaldo administrado. IDCF Cloud Storage se apoya en Google Cloud Storage; IDCF Cloud Backup es un servicio distinto. El FAQ no aclara si su aviso genérico de indisponibilidad de servicios de respaldo incluía este producto concreto, qué clientes estaban comprendidos o si alguno de los afectados lo había contratado. La ruta GCS no prueba que el repositorio Veeam-Wasabi siguiera accesible.

El tercer informe de IDCF sitúa el comienzo del incidente alrededor de las 03:40 del 7 de octubre, hora de Japón. En tesla, henry, pascal y joule, cuatro zonas de East Japan Region 1, las máquinas virtuales estaban detenidas y no podían reiniciarse. La empresa consideró difícil extraer o restaurar los datos y señaló entonces los respaldos que cada cliente tuviera en su poder como la vía de recuperación disponible. Para contener el riesgo, aisló la red regional y detuvo su consola de gestión; también suspendió las consolas externas de otras regiones mientras comprobaba su seguridad.

El cuarto informe, del 9 de octubre, describió coordinación de emergencia con SoftBank, orientación sobre respaldos y migración, y una investigación técnica con especialistas externos. No comunicó un resultado de restauración. Una estructura de respuesta acredita trabajo en curso, no que las cargas de los clientes vuelvan a estar operativas.

IDCF lanzó su servicio de respaldo en marzo de 2025 con Veeam Service Provider Backup y Wasabi Hot Cloud Storage. El precio publicado entonces era de 3.500 yenes mensuales por servidor protegido y 5 yenes por gigabyte almacenado. La página actual describe un agente de sistema operativo, copias incrementales, almacenamiento en otro sitio, una opción inmutable y restauración en otro servidor; también exige conexión a Internet y sitúa el almacenamiento disponible en el este de Japón.

El manual de usuario inicia el proceso en IDCF Cloud Console y después abre Veeam Service Provider Console. El documento de alcance permite crear usuarios locales de la consola de respaldo sin asociarlos a un usuario de IDCF Cloud. Esa separación de cuentas podría ser valiosa, pero la documentación pública no dice si el usuario local puede entrar por una URL directa cuando el portal principal está fuera de servicio, ni qué clientes lo habían configurado.

“Otro sitio” tampoco define por sí solo el dominio de fallo: una ubicación, una región, una zona, el proveedor de identidad, el portal administrativo y el destino de restauración son dimensiones distintas. El almacenamiento en el este de Japón no demuestra solapamiento con las zonas afectadas ni independencia suficiente.

Los casos de clientes muestran las condiciones que la tarifa de una copia no cubre. Six Apart informó que había trasladado 31 servidores de Movable Type Cloud a Sakura Cloud antes de las 21:00 del 8 de octubre, usando el respaldo de las 01:00 del día 7 guardado en Google Cloud Storage. Conservaba siete copias diarias. El punto elegido precedía en dos horas y cuarenta minutos al inicio publicado del incidente, aunque no se conoce qué cambios se perdieron durante ese intervalo ni si otros registros redujeron la brecha. La migración se apoyó en un plan Sakura que Six Apart ya ofrecía desde junio.

Aun así, el traslado podía cambiar direcciones IP, especificaciones y tiempos de entrega; no es un resultado aplicable a todos los clientes de IDCF.

Future Shop dependía de IDCF solo para los servidores de transferencia de correo de dos complementos. La tienda en línea y su administración operaban en otra plataforma. Tras construir un entorno nuevo en otro centro de datos, reanudó los envíos de future Scenario Cast a las 12:20 y de futureCartRecovery a las 12:30 del 9 de octubre. Los mensajes previstos durante la interrupción no se reenviaron automáticamente.

También informó que esos servidores guardaban algunas direcciones de destinatarios y partes del contenido que podían incluir nombres, cumpleaños o identificadores de miembro; los datos estaban cifrados en reposo y se eliminaban automáticamente a los catorce días. Seguían sin conocerse el inicio de la intrusión y el período de posible exposición. El servicio volvió, pero la investigación sobre una posible filtración continuaba.

El precio por servidor y por gigabyte mide la capacidad protegida, no el costo completo de reanudar operaciones. Quedan fuera el cómputo alternativo, el traslado de datos, la red, la recuperación de identidades, la validación de aplicaciones y los mensajes o transacciones que no pueden reproducirse. Una prueba útil empieza por apagar el acceso normal: comprobar quién puede consultar el catálogo desde una identidad independiente, escoger un punto conocido y restaurar una carga representativa en un destino cuya autenticación, facturación y capacidad no dependan de la consola caída.

El cronómetro debe detenerse cuando la aplicación vuelve a servir a sus usuarios, no cuando termina de copiar archivos.

La información pública no revela si IDCF Cloud Backup fue utilizado, si su consola estuvo accesible o si algún cliente afectado tenía allí una copia. Por eso, el incidente no demuestra que el producto fracasara. Sí deja clara la estructura económica de la promesa: una copia que sobrevive, acceso para administrarla y capacidad para ejecutar la carga son condiciones separadas. El valor del respaldo depende de que las conexiones entre ellas funcionen bajo la misma avería que el comprador quería cubrir.

Fuentes