Summary

  • IDCF teilte mit, dass der am 7. Oktober begonnene Ransomware-Angriff virtuelle Maschinen in vier Zonen der East Japan Region 1 stoppte und 495 Unternehmen sowie Kommunen betraf. Die öffentlichen Meldungen benennen weder Angreifer noch Zugangsweg und klären den Status von IDCF Cloud Backup nicht.
  • Die Produktunterlagen beschreiben eine externe Sicherung und eine optionale unveränderbare Speicherung. Sie belegen weder, dass Kunden den Sicherungskatalog bei abgeschalteter IDCF-Konsole erreichen können, noch dass an anderer Stelle genügend Rechenkapazität bereitsteht.
  • Six Apart und Future Shop veröffentlichten unterschiedliche Wiederanlaufwege: Six Apart verlagerte 31 Server mit Sicherungen aus Google Cloud zu Sakura Cloud; Future Shop baute den Versand zweier optionaler E-Mail-Dienste in einem anderen Rechenzentrum neu auf. Keines der Unternehmen erklärte, IDCF Cloud Backup genutzt zu haben.

Zwischen einer vorhandenen Kopie und einem wieder arbeitenden Dienst liegt mehr als ein Kopierjob. IDCF empfahl betroffenen Kunden, eine separate Umgebung einzurichten und aus eigenen Sicherungen neu aufzubauen. Für Nutzer von IDCF Cloud Storage nannte der FAQ eine zweite Tür: Mit dem verknüpften Google-Konto und den Projektangaben sollte sich Google Cloud Storage über die Google Cloud Console erreichen lassen, während die IDCF Cloud Console ausgesetzt war.

Diese Umgehung betrifft GCS-Speicher, nicht automatisch den verwalteten Backupdienst. IDCF Cloud Storage und IDCF Cloud Backup sind getrennte Produkte. Der FAQ sagt nicht, ob seine allgemeine Meldung zur Nichtverfügbarkeit von Backupdiensten auch das beim Start mit Veeam und Wasabi angebotene BaaS umfasst, welche Kunden erfasst waren oder ob betroffene Kunden es abonniert hatten. Der direkte GCS-Zugang ist daher kein Beleg dafür, dass auch das Veeam/Wasabi-Repository erreichbar blieb.

Laut dem dritten IDCF-Bericht begann der Vorfall gegen 03:40 Uhr japanischer Zeit am 7. Oktober. In den vier Zonen tesla, henry, pascal und joule der East Japan Region 1 waren virtuelle Maschinen gestoppt und ließen sich nicht neu starten. IDCF hielt es für schwierig, Daten aus diesen Zonen auszulesen oder wiederherzustellen; damals seien kundeneigene Sicherungen der verfügbare Wiederherstellungsweg. Zur Eindämmung trennte das Unternehmen das betroffene Netzwerk und stoppte die Verwaltungskonsole. Auch die extern erreichbaren Konsolen anderer Regionen wurden während der Sicherheitsprüfung ausgesetzt.

Der vierte Bericht vom 9. Oktober beschrieb eine Notfallstruktur mit SoftBank, Hinweise zu Sicherung und Migration sowie technische Untersuchungen mit externen Sicherheitsexperten. Ein Wiederherstellungsergebnis nannte er nicht. Eine eingerichtete Reaktion belegt laufende Arbeit, aber keine wieder verfügbaren Kundenanwendungen.

Bei der Einführung im März 2025 beschrieb IDCF Cloud Backup eine Veeam-Service-Provider-Sicherung mit Wasabi Hot Cloud Storage. Der veröffentlichte Startpreis betrug 3.500 Yen pro geschütztem Server und Monat zuzüglich 5 Yen pro gespeichertem Gigabyte. Die aktuelle Produktseite nennt einen Betriebssystem-Agenten, inkrementelle Sicherungen, Speicherung an einem anderen Standort, eine Option für unveränderbare Kopien und die Wiederherstellung auf einen anderen Server. Der Dienst benötigt eine Internetverbindung; die Speichermöglichkeit wird derzeit für die Region Ostjapan angegeben.

Der Leitfaden beginnt in der IDCF Cloud Console und führt dann zur Veeam Service Provider Console. Laut Leistungsumfang können lokale Nutzer der Backup-Konsole ohne Verknüpfung mit einem IDCF-Cloud-Konto eingerichtet werden. Getrennte Konten können hilfreich sein. Die öffentlichen Unterlagen zeigen aber nicht, ob ein lokaler Nutzer bei abgeschaltetem IDCF-Portal über eine direkte Adresse einsteigen kann oder welche Kunden diesen Weg eingerichtet hatten. Auch „anderer Standort“ bestimmt keine unabhängige Fehlerdomäne: Standort, Region, Zone, Identitätsanbieter, Administrationskonsole und Wiederherstellungsziel sind verschiedene Merkmale.

Aus der Angabe Ostjapan lässt sich weder eine Überlappung mit den betroffenen Zonen noch deren Unabhängigkeit ableiten.

Die Kundenerfahrungen zeigen Arbeit, die im Preis pro Server und Gigabyte nicht auftaucht. Six Apart meldete, bis 21 Uhr am 8. Oktober 31 Movable-Type-Cloud-Server zu Sakura Cloud verlagert zu haben, und zwar mit einer am 7. Oktober um 01 Uhr erstellten Sicherung in Google Cloud Storage. Der Dienst hielt sieben tägliche Generationen vor. Der gewählte Zeitpunkt lag 2 Stunden und 40 Minuten vor dem von IDCF gemeldeten Beginn; wie viele Änderungen in diesem Zeitraum anfielen oder ob andere Protokolle die Lücke schlossen, ist nicht bekannt. Sakura Cloud war bereits seit Juni als Plan verfügbar.

Dennoch konnten sich IP-Adressen und Spezifikationen ändern, und der Wechsel konnte Zeit kosten. Das ist ein kundenspezifischer Ablauf, keine Zusage für andere IDCF-Kunden.

Bei Future Shop war nur ein enger Teil des Angebots von IDCF abhängig: die MTA-Server zweier optionaler E-Mail-Dienste. Online-Shop und Verwaltungsoberfläche liefen auf einer anderen Plattform. Nach dem Aufbau einer neuen Versandumgebung in einem anderen Rechenzentrum nahm Future Shop den Versand für future Scenario Cast am 9. Oktober um 12:20 Uhr und für futureCartRecovery um 12:30 Uhr wieder auf. Während der Unterbrechung geplante Nachrichten wurden nicht automatisch nachgesendet.

Das Unternehmen sagte außerdem, dass auf den Servern einige Empfängeradressen und Nachrichtenteile mit Namen, Geburtstagen oder Mitgliedsnummern gelegen haben könnten. Die Daten waren im Ruhezustand verschlüsselt und wurden nach 14 Tagen automatisch gelöscht. Beginn und möglicher betroffener Zeitraum des Eindringens blieben unklar. Der wiederaufgenommene Versand bedeutete nicht, dass die Untersuchung eines möglichen Datenabflusses abgeschlossen war.

Ein Preis pro Server und Speichermenge beziffert geschützte Kapazität, nicht die Gesamtkosten des Wiederanlaufs. Hinzu kommen Ersatzrechner, Datentransfer, Netz- und Adressänderungen, die Wiederherstellung von Identitäten, Anwendungstests und Kommunikation, die sich nicht nachholen lässt. Eine belastbare Übung beginnt mit dem Ausfall: das normale Portal abschalten, den Zugriff auf den Katalog mit einer unabhängigen Identität testen, einen bekannten Stand auswählen und eine repräsentative Anwendung in eine Umgebung zurückspielen, deren Anmeldung, Abrechnung und Rechenkapazität nicht vom abgeschalteten Portal abhängen.

Entscheidend ist die Zeit bis zur wieder nutzbaren Anwendung, nicht bis zum Ende des Kopiervorgangs.

Die öffentlichen Quellen zeigen nicht, ob IDCF Cloud Backup genutzt wurde, seine Konsole verfügbar blieb oder ein betroffener Kunde dort Kopien hatte. Der Vorfall belegt daher kein Versagen des Produkts. Er zeigt, dass eine erhaltene Kopie, der Zugriff auf Katalog und Zugangsdaten sowie eine alternative Laufzeitumgebung unterschiedliche Bedingungen sind. Der wirtschaftliche Wert eines Backups hängt davon ab, ob die Verbindungen zwischen ihnen gerade bei dem Ausfall halten, gegen den der Kunde sich absichern wollte.

Quellen