In der Nacht auf den 7. Oktober verschafften sich Unbekannte Zugang zur Testumgebung des Schweizer Onlinehändlers Offerz. Bemerkt wurde das erst am Morgen des 9. Oktober. Betroffen sind rund 115 000 Kunden.
Abgeflossen sind Namen, Wohn- und E-Mail-Adressen, Telefonnummern, IP-Adressen und Angaben zum Zahlungsmittel. Passwörter und Zahlungsdaten waren nicht dabei.
Der Satz, auf den es ankommt
Das Unternehmen erklärt den Hergang selbst: Bei technischen Arbeiten am Shop sei eine Kopie der Bestelldaten erstellt und in einem Cloud-Speicher abgelegt worden — auf den auch die Testumgebung Zugriff hatte.
Zwei Angaben machen daraus eine Geschichte, die über diesen einen Fall hinausgeht.
Die Kopie stammte aus dem Januar. Sie lag also neun Monate dort.
Sie hätte nach Abschluss der Arbeiten gelöscht werden müssen. Das sagt das Unternehmen selbst.
Damit ist das Problem kein Einbruch in ein gut gesichertes System. Es ist ein vergessener Rest.
Warum das so verbreitet ist
Wer eine Website oder einen Shop umbaut, braucht eine zweite Umgebung zum Ausprobieren. Und wer dort etwas Ernsthaftes testen will, braucht Daten darin — eine leere Datenbank zeigt nicht, ob die Bestellübersicht bei 4000 Positionen noch lädt oder ob die Suche mit Umlauten in echten Namen zurechtkommt.
Der naheliegende Weg ist deshalb immer derselbe: Eine Kopie der Produktionsdatenbank einspielen. Das dauert zwei Minuten und löst das Problem sofort.
Danach gilt für diese Kopie alles, was für die Produktivdaten auch gilt — nur dass sich niemand so darum kümmert. Die Testumgebung hat selten dieselbe Absicherung, sie steht oft auf einer Nebenadresse, sie taucht in keiner Übersicht auf, und niemand sieht sich ihre Protokolle an.
Dass der Zugriff zwei Tage lang unbemerkt blieb, passt in dieses Bild.
Der Unterschied, der sich machen lässt
Die Frage ist nicht, ob man eine Testumgebung braucht. Man braucht sie.
Die Frage ist, welche Daten darin stehen müssen. Und die Antwort fällt fast immer kleiner aus, als man zunächst denkt.
Um zu prüfen, ob eine Bestellübersicht bei grosser Datenmenge noch lädt, braucht es viele Zeilen — aber keine echten Namen. Um ein Layout zu prüfen, braucht es einen Datensatz — aber nicht hunderttausend. Um eine Zahlungsschnittstelle zu testen, gibt es Testkonten der Anbieter, die genau dafür da sind.
Wie wir es bei uns halten
Das lässt sich schlecht raten, deshalb hier unser eigenes Vorgehen, nachprüfbar im Projekt hinterlegt.
Unsere Entwicklungsumgebung holt sich von der Produktion das Schema aller Tabellen, aber Daten nur aus den öffentlichen Inhaltstabellen — also dem, was ohnehin auf der Website steht: Seiteninhalte, Angebote, Beiträge, Bilder, Referenzen, Team.
Leer bleiben, bewusst und als blosse Struktur: Support-Anfragen und ihre Antworten, Kontaktnachrichten, Newsletter-Empfänger und die Warteschlange, Bestellungen, Zugriffsanfragen, Administratoren und die Kundenstimmen — Letztere, weil darin Einladungs-Tokens stecken.
Der Grund steht in derselben Notiz in einem Satz: Personenbezogenes gehört nicht auf den Entwicklungsrechner.
Das ist kein Verzicht. Die Entwicklungsumgebung ist damit vollständig benutzbar — nur dass ein verlorener Laptop oder eine schlecht gesicherte Testadresse nichts preisgibt, was jemandem schaden könnte.
Was heute zu tun ist
Nachsehen, ob es eine Testumgebung gibt — und wenn ja, was darin liegt. In vielen Betrieben weiss das nur die Agentur, die den Umbau gemacht hat. Das ist eine Frage, die sich in einer Mail stellen lässt.
Nach Kopien suchen, nicht nur nach Systemen. Der Schaden entstand hier nicht in der Testumgebung selbst, sondern in einer Datei in einem Cloud-Speicher, auf den sie zugreifen konnte. Solche Kopien entstehen bei jeder Migration, jedem Umzug, jeder Fehlersuche.
Eine Regel vereinbaren, die ohne Disziplin auskommt. «Daran denken, es nachher zu löschen» funktioniert nicht — der Fall zeigt es. Besser ist, dass echte Daten gar nicht erst in die Testumgebung gelangen.
Bei Offerz war ein externer Dienstleister für Serverbetrieb und Programmierung zuständig. Das ist der Normalfall bei Betrieben dieser Grösse — und es ist dieselbe Konstellation wie bei den Fällen, über die wir gestern und vergangene Woche geschrieben haben: Der Angriff trifft den Dienstleister, die Folgen treffen die Kunden.
Deshalb gehört diese Frage auch ins Gespräch mit dem Dienstleister, nicht nur ins eigene Haus.