Summary

  • IDCF a indiqué que l’attaque par ransomware du 7 octobre avait immobilisé des machines virtuelles dans quatre zones de sa première région de l’Est du Japon et touché 495 entreprises et collectivités. Ses annonces ne précisent ni l’identité de l’attaquant, ni la voie d’entrée, ni le sort du service IDCF Cloud Backup.
  • La documentation commerciale décrit des sauvegardes hors site et une option de stockage immuable. Elle ne prouve pas qu’un client puisse ouvrir le catalogue de sauvegarde quand la console IDCF est suspendue, ni qu’il dispose ailleurs de capacité pour redémarrer une charge.
  • Six Apart et Future Shop ont publié deux reprises différentes : l’une a déplacé 31 serveurs vers Sakura Cloud à partir de sauvegardes GCS ; l’autre a reconstruit un service de courriel optionnel dans un autre centre de données. Rien n’indique que l’une ou l’autre ait utilisé IDCF Cloud Backup.

La différence entre une copie et une reprise opérationnelle tient souvent à un écran de connexion. Le 8 octobre, IDCF conseillait aux clients concernés de préparer un environnement distinct et de restaurer leurs propres sauvegardes. Pour certains utilisateurs d’IDCF Cloud Storage, sa FAQ donnait une autre voie : ouvrir les objets directement depuis Google Cloud Console avec le compte Google et l’identifiant de projet associés. Ce chemin concerne le stockage GCS d’IDCF. Il ne démontre pas que le service managé IDCF Cloud Backup, fondé dans son lancement sur Veeam et Wasabi, ait partagé le même accès.

Cette distinction est centrale. Le troisième bulletin d’IDC Frontier situe le début de l’incident vers 03 h 40 le 7 octobre, heure du Japon. Les VM de quatre zones de la région East Japan 1 — tesla, henry, pascal et joule — étaient arrêtées et ne pouvaient être redémarrées. L’entreprise estimait difficile l’extraction ou la restauration des données et présentait alors les copies détenues par les clients comme la voie de restauration disponible. Pour limiter les dommages, elle avait isolé le réseau et interrompu la console de gestion de la région, puis suspendu les consoles externes d’autres régions le temps des vérifications.

Le bulletin du 9 octobre décrit une cellule d’intervention avec SoftBank, des conseils de sauvegarde et de migration, et des investigations techniques avec des spécialistes externes. Il ne constitue pas un bilan de restauration. Une équipe mobilisée prouve qu’une réponse est en cours ; elle ne prouve pas que les applications sont de nouveau disponibles.

Le produit de sauvegarde d’IDCF illustre les éléments visibles du prix. Son lancement en mars 2025 associait Veeam Service Provider Backup et Wasabi Hot Cloud Storage : 3 500 yens par serveur protégé et par mois, puis 5 yens par gigaoctet stocké. La page actuelle décrit un agent installé dans le système, des copies incrémentales, un site de stockage différent, une option d’immutabilité et une restauration vers un autre serveur. Elle précise que le service requiert Internet et indique que le stockage est actuellement proposé dans la zone de l’Est du Japon.

Le guide de l’utilisateur part de la console IDCF Cloud avant d’ouvrir Veeam Service Provider Console. Le document de périmètre autorise aussi des comptes locaux de console sans compte IDCF Cloud associé. C’est une séparation potentiellement utile des identités, mais les documents publics ne disent pas si ces comptes locaux peuvent se connecter par une adresse directe lorsque le portail IDCF est arrêté, ni quels clients les avaient configurés.

« Un autre site » ne répond pas non plus à la question du domaine de défaillance : site, région, zone, fournisseur d’identité, console d’administration et cible de restauration sont des variables distinctes. Le fait que le stockage soit situé dans l’Est du Japon ne prouve ni chevauchement avec une zone touchée ni séparation suffisante.

Les clients documentés donnent une mesure plus concrète de la reprise. Six Apart a signalé que 31 serveurs Movable Type Cloud avaient été migrés vers Sakura Cloud avant 21 h le 8 octobre, à partir d’une sauvegarde prise à 01 h le 7 octobre et stockée dans Google Cloud Storage. Son service conservait sept sauvegardes quotidiennes. Le point choisi précédait de 2 h 40 le début publié de l’incident, sans que les sources indiquent le volume de changements perdus ou la présence d’autres journaux.

Cette migration a été rendue possible par une destination Sakura déjà proposée depuis juin ; elle a toutefois entraîné des changements d’adresses IP, des écarts de capacité possibles et un délai de mise en œuvre. C’est une reprise propre à ce prestataire, pas un résultat garanti à tous les clients IDCF.

Future Shop avait une dépendance plus circonscrite : les serveurs MTA de deux options de courriel reposaient sur IDCF, tandis que la boutique en ligne et son interface d’administration fonctionnaient ailleurs. Après avoir bâti un nouvel environnement dans un autre centre de données, l’entreprise a repris l’envoi le 9 octobre à 12 h 20 pour future Scenario Cast et à 12 h 30 pour futureCartRecovery. Les messages prévus pendant la coupure n’ont pas été renvoyés automatiquement.

L’entreprise a aussi indiqué que certains serveurs contenaient des adresses de destinataires et des éléments de messages pouvant être personnels, chiffrés au repos et supprimés automatiquement après quatorze jours. L’heure de début de l’intrusion et la période potentiellement touchée restaient inconnues ; la reprise du service n’a pas clos l’enquête sur une éventuelle fuite.

La facture de sauvegarde ne chiffre pas l’ensemble de la reprise. Un prix par serveur et par gigaoctet laisse hors champ la capacité de calcul ailleurs, le transfert des données, les changements réseau, la récupération des identités, les contrôles applicatifs et les communications qui ne peuvent être rejouées. Le test pertinent commence par la panne : couper le portail normal, ouvrir le catalogue depuis une identité indépendante, sélectionner un point connu, puis restaurer une charge représentative dans une cible dont l’accès, la facturation et les ressources ne dépendent pas du portail arrêté.

Il faut chronométrer le retour d’une application utile, pas la fin d’une copie.

Le dossier public ne dit toujours pas si IDCF Cloud Backup a été utilisé, si sa console est restée joignable ou si des copies de clients concernés y existaient. Il ne démontre donc pas un échec du service. Il montre plutôt que copie, accès au catalogue et capacité de remplacement sont trois contrôles distincts. La valeur de la sauvegarde dépend de leurs raccordements précisément dans la panne pour laquelle le client a payé.

Sources