Vergessene Testsysteme und alte Subdomains aufräumen

Die Liste entsteht nicht aus dem Gedächtnis. Wer sie aus der Erinnerung schreibt, bekommt die Systeme, die im Gespräch vorkommen – und genau die sind das kleinere Problem. Belastbar wird die Aufstellung erst, wenn sie aus Quellen kommt, die unabhängig voneinander geführt werden: der DNS-Zone beim Anbieter, der Konfiguration des Webservers, den ausgestellten Zertifikaten, dem Dateisystem und den Rechnungen. Wo zwei dieser Quellen voneinander abweichen, liegt in der Regel ein Eintrag, um den sich seit Langem keine Zuständigkeit kümmert.

Dass auch gut ausgestattete Organisationen hier Lücken haben, zeigt eine Messung des BSI an der eigenen Verwaltung: Im Berichtszeitraum waren im Mittel rund 3.800 IP-Adressen der Bundesverwaltung aus dem Internet erreichbar, bei etwa 7 Prozent davon bestand ein Verdacht auf eine Schwachstelle (BSI, Lagebericht 2025). Für einen Shop mit einer Handvoll Subdomains ist die Zahl kleiner, die Mechanik aber dieselbe: Erreichbarkeit entsteht schneller, als sie dokumentiert wird. Eine Wartungsübernahme von einem anderen Anbieter ist erfahrungsgemäß der Moment, in dem die Abweichung zwischen Liste und Wirklichkeit besonders groß ausfällt.

Die Tabelle zeigt ein Muster: Kein Eintrag ist für sich genommen ungewöhnlich, jeder hatte einmal einen guten Grund. Zum Risiko wird er durch die Zeit. Eine Staging-Umgebung mit klarer Aufgabe gehört in jede geordnete Update-Kette; problematisch ist die Kopie, die nach dem Projektende stehen blieb, obwohl ihr Zweck erfüllt war. Die Unterscheidung zwischen beidem ist keine technische, sondern eine organisatorische: Zu einem Testsystem gehört ein Enddatum, und wer die laufenden Sicherheitsupdates verantwortet, braucht die Liste der Systeme, für die sie gelten sollen.

Steht die Liste, folgt je Eintrag eine von drei Entscheidungen. Abschalten heißt: Der Dienst wird beendet, die Dateien werden gesichert und entfernt, der DNS-Eintrag verschwindet aus der Zone. Archivieren heißt: Die Inhalte werden aus dem Betrieb genommen, aber nachvollziehbar aufbewahrt – außerhalb des ausgelieferten Verzeichnisses, verschlüsselt und mit einem Ende der Aufbewahrung. Sperren heißt: Das System bleibt in Betrieb, wird aber auf einen benannten Personenkreis eingeschränkt und aus dem Suchindex genommen.

Die Entscheidung fällt nach dem Zweck, nicht nach der Technik. Ein Testsystem, das für den nächsten Versionssprung gebraucht wird, wird gesperrt und mitgepflegt. Ein Testsystem ohne geplanten nächsten Einsatz wird abgeschaltet – der Aufwand, später ein zweites, sauberes System aufzusetzen, ist in der Regel kleiner als das Risiko, ein ungepflegtes über Monate offen zu lassen. Aufbewahrungspflichten betreffen dabei die Daten, nicht die laufende Anwendung: Wer Belege vorhalten muss, exportiert sie, statt den alten Shop weiterlaufen zu lassen. Was für Rechnungsdaten gilt, verändert sich mit der Umstellung auf die E-Rechnung noch einmal – ein Grund mehr, Archivierung und Betrieb sauber zu trennen.

Die Konfiguration erledigt drei Dinge auf einmal: Sie begrenzt den Zugang auf ein benanntes Netz und eine Anmeldung, sie setzt den Antwortkopf für die Suchmaschinen, und sie beantwortet Anfragen nach Abzügen, Archiven und Metadatenverzeichnissen mit einem Fehler. Der dritte Punkt wird häufig vergessen: Ein Zugangsschutz vor der Anwendung hilft wenig, wenn daneben ein Archiv ohne Schutz im selben Verzeichnis liegt. Das genannte Netz stammt aus einem für Dokumentation reservierten Adressbereich und wird durch das eigene ersetzt.

Für das Sperren gilt dieselbe Sorgfalt wie für den produktiven Betrieb. Ein gesperrtes System bleibt ein System: Es braucht Updates, ein Protokoll und eine verantwortliche Person. Wer die Sperre als Ersatz für Pflege einsetzt, verschiebt das Problem nur – und zwar an eine Stelle, an der es seltener auffällt. Ein Zugangsschutz, der über Jahre an dieselben zwei Kennwörter gebunden ist, gehört mit in das Rechteinventar und das Offboarding.

Testsysteme entstehen meist als Kopie: Datenbank ziehen, Dateien kopieren, Adresse ändern, fertig. Damit wandern Bestellungen, Anschriften, Zahlungsangaben und Kundenkonten in eine Umgebung, für die weder das Update-Regime noch die Zugriffsregeln des produktiven Systems gelten. Der IT-Grundschutz ist an dieser Stelle deutlich: Enthalten Testdaten personenbezogene Informationen, dann müssen sie mindestens pseudonymisiert werden; wo es möglich ist, sollen sie vollständig anonymisiert werden (BSI, IT-Grundschutz OPS.1.1.6.A11).

Datenschutzrechtlich gilt für die Kopie dasselbe wie für das Original. Personenbezogene Daten dürfen nur so lange in identifizierbarer Form gespeichert werden, wie es für die Zwecke der Verarbeitung erforderlich ist (Art. 5 Abs. 1 Buchstabe e DSGVO), und die Sicherheit der Verarbeitung verlangt technische und organisatorische Maßnahmen, die dem Risiko angemessen sind – ausdrücklich einschließlich Pseudonymisierung und Verschlüsselung (Art. 32 Abs. 1 DSGVO). Ein Testsystem mit echten Bestelldaten und ohne Zugriffsbeschränkung erfüllt beides nicht. Wie lange welche Daten aufzubewahren sind, gehört in dieselbe Betrachtung wie die Aufbewahrung der Datensicherungen.

Aufräumen ist kein Projekt mit Ende, sondern eine wiederkehrende Prüfung. Das Ausnutzen von Schwachstellen war der Startpunkt von 20 Prozent der untersuchten Einbrüche mit bekanntem Zugangsweg und hat damit erneut zugenommen (Verizon, DBIR 2025). Für die ausgenutzten Schwachstellen in Perimetersystemen zeigte dieselbe Auswertung: Nur etwa 54 Prozent wurden im Jahresverlauf vollständig behoben, im Median dauerte das 32 Tage (Verizon). Diese Werte stammen aus gepflegten Umgebungen mit Patch-Prozess. Ein vergessenes System hat diese Kurve gar nicht – bei ihm bleibt die Lücke offen, bis jemand es abschaltet.

Der Termin dafür braucht keine eigene Organisation. Er hängt sich an Termine, die es ohnehin gibt: an das Quartalsgespräch, an die Erneuerung der Zertifikate oder an den Änderungsstopp vor dem Weihnachtsgeschäft. Der Änderungsstopp eignet sich besonders, weil vor ihm ohnehin aufgeräumt wird und weil in der ruhigen Phase auffällt, welche Systeme trotzdem Anfragen bekommen. Praktisch ist ein fester Takt je Quartal, ergänzt um eine Prüfung nach jedem Relaunch und jedem Projektende mit externen Beteiligten.

Die Ausgabe ist gekürzt; entscheidend ist ihre Struktur. Jede Zeile trägt drei Angaben: den Namen, die Antwort und den Grund für die Einstufung. Ein Eintrag ohne Antwort ist dabei genauso auffällig wie einer mit Antwort – der erste steht für ein Ziel, das verschwunden ist, der zweite für ein System, das noch bedient wird. Wichtig ist, dass die Prüfung über die vollständige Liste läuft und nicht über die Hosts, die man ohnehin im Blick hat.

Für den ersten Durchgang hat sich eine feste Reihenfolge bewährt: zuerst die DNS-Zone, weil sie den Rahmen absteckt; dann die ausgestellten Zertifikate, weil sie Namen liefern, die in der Zone fehlen; dann Webserver und Dateisystem, weil dort steht, was tatsächlich ausgeliefert wird; zuletzt die Verträge, weil sie die verbleibenden Lücken zeigen. Erst danach fällt je Eintrag die Entscheidung, und erst danach wird etwas abgeschaltet.

Zwei Punkte verkürzen den Durchgang erfahrungsgemäß deutlich. Erstens: gleich beim ersten Fund die vier Angaben notieren – Name, Zweck, verantwortliche Person, letztes Änderungsdatum – statt sie später zusammenzusuchen. Zweitens: nichts abschalten, ohne vorher eine Sicherung gezogen und sie einmal zurückgespielt zu haben. Ein abgeschaltetes System, dessen Sicherung sich nicht öffnen lässt, erzeugt eine zweite Baustelle an der Stelle, an der gerade eine geschlossen wurde.