Aus dem Firmenalltag: Die Anwendung ist gehackt, und der Server ist zehn Jahre alt

Montagmorgen, das Kundenportal ist offline, und es war kein Ausfall. Welche Entscheidungen in den ersten drei Tagen anstehen, in welcher Reihenfolge eine Ablösung danach sinnvoll ist, und warum dieselbe Modernisierung geplant deutlich günstiger zu haben wäre.

Schematische Darstellung: ein alter Server mit einer beschädigten Einheit, daneben ein neuer Server, in den die Anwendung Modul für Modul in Containern umzieht

Unter "Aus dem Firmenalltag" beschreibe ich Situationen, wie sie in Unternehmen mit gewachsener Software vorkommen. Das Szenario ist aus typischen Abläufen zusammengesetzt und beschreibt keinen einzelnen Kunden. Die Entscheidungen darin sind trotzdem die, die jemand treffen muss, meistens unter Zeitdruck und meistens die Geschäftsführung.

Montagmorgen, das Portal ist weg

Ein Unternehmen betreibt ein Kundenportal mit Abo-Abrechnung. Die Anwendung ist sechs Jahre alt und verdient jeden Tag Geld. Am Montagmorgen ist sie nicht erreichbar. Gegen Mittag steht fest, dass es kein Ausfall war: Jemand ist eingebrochen.

Beim Versuch, das System wieder hochzufahren, kommt die eigentliche Lage ans Licht. Den Server hat vor zehn Jahren ein Dienstleister eingerichtet, den es nicht mehr gibt. Das Betriebssystem bekommt seit Jahren keine Sicherheitsupdates, PHP und MySQL sind ebenso lange aus dem Support. Niemand im Haus hat alle Zugänge, eine Dokumentation existiert nicht.

Dazu kommt etwas, das ich in Altsystemen regelmäßig finde: Der Server ist mit den Jahren Teil der Anwendung geworden. Der Code verlässt sich auf genau diese PHP-Version, genau diese MySQL-Version und darauf, wie genau dieses Betriebssystem mit Dateirechten umgeht. Aufgeschrieben hat das niemand, es lief ja. Geschlampt hat dabei auch niemand. Solche Systeme entstehen unter Druck, Schritt für Schritt, von Leuten, die echte Probleme mit der Zeit gelöst haben, die sie hatten.

Was in den ersten drei Tagen entschieden wird

Drei Entscheidungen stehen sofort an, und keine davon ist technisch.

  1. Wiederherstellen oder neu bauen. Die Antwort ist wiederherstellen. Jeder Tag offline kostet Umsatz und Vertrauen, und ein Neubau unter diesem Druck ist ein Big Bang mit noch schlechteren Karten. Erst muss das Geschäft wieder laufen.
  2. Womit das System wieder online geht. Das letzte Backup einzuspielen liegt nahe und bringt im Zweifel dieselbe Lücke zurück, durch die der Angreifer gekommen ist, samt einer Hintertür, falls er eine hinterlassen hat. Vor dem Wiederanlauf wird der Einstiegsweg geklärt, soweit das noch geht. Der Code wird aus einem Stand aufgebaut, der nachweislich sauber ist, und sämtliche Passwörter und Schlüssel werden getauscht.
  3. Wem der Vorfall gemeldet wird. Sind personenbezogene Daten betroffen, verlangt Art. 33 DSGVO in der Regel eine Meldung an die Aufsichtsbehörde binnen 72 Stunden. Die Frist läuft parallel zur Wiederherstellung. Sie liegt bei der Geschäftsführung, ein Entwickler kann sie Ihnen nicht abnehmen.

Der Angreifer gibt das Budget frei

In diesem Moment verschwindet jedes Argument gegen den Umbau der Infrastruktur. Bis zum Montag hat jemand "nicht jetzt" gesagt, vermutlich mehrfach und mit nachvollziehbaren Gründen, denn das System lief.

Entschieden wird die Modernisierung dann trotzdem, nur zum schlechtesten Zeitpunkt. Die Seite ist offline, es gibt keine Bestandsaufnahme, kein Vergleichsangebot, keine Wahl beim Termin. Wer in dieser Lage beauftragt, verhandelt weder über Umfang noch über Preis.

Geplant beginnt dieselbe Arbeit mit einer Inventur: welche Versionen laufen, was hängt am Server, wer hat welche Zugänge, wo liegt ein Backup, das schon einmal zurückgespielt wurde. Das dauert wenige Tage. Danach ist "nicht jetzt" eine Entscheidung mit bekanntem Risiko und keine Wette mehr. Warum eine Plattform ohne Sicherheitsupdates dieses Risiko mit jedem Monat vergrößert, steht im Beitrag über veraltete PHP-Versionen.

Wie die Ablösung danach abläuft

Ist das Portal wieder erreichbar, beginnt die eigentliche Arbeit. Die Reihenfolge, in der ich sie angehe:

Kontrolle über die Infrastruktur

Der alte Stack zieht so, wie er ist, in Container auf einen frischen, gepflegten Server um und wird nach außen abgeschottet. Sicherer wird ein altes PHP dadurch nicht. Aber die Abhängigkeit vom Server ist danach aufgeschrieben und wiederholbar, und das System lässt sich an einem Nachmittag neu aufsetzen statt gar nicht.

Tests um die kritischen Pfade

In solchen Anwendungen steckt Geschäftslogik in SQL-Abfragen, das Datenbankschema enthält Annahmen, die nirgends stehen, und manche Lesezugriffe verändern nebenbei Daten. Das Verhalten des alten Systems ist damit die einzige Spezifikation. Charakterisierungstests schreiben es fest, bevor jemand etwas ändert. Ohne sie bemerkt die Abweichung zuerst Ihr Kunde.

Modul für Modul ablösen

Neuer Code entsteht neben dem alten und übernimmt den Verkehr Stück für Stück, nach dem Strangler-Fig-Prinzip. Zuerst kommt der Teil dran, über den der Angreifer hereinkam. Danach folgt, was Geld bewegt, also Zahlungen und Anmeldung, und zum Schluss der Rest. Die Zielarchitektur wird einmal zu Beginn festgelegt. Wer je Modul ein anderes Muster einführt, hat am Ende ein System, das an manchen Stellen modern ist und an anderen alt, und die Grenze dazwischen wird selbst zur Fehlerquelle.

Jede Etappe mit einem Ende

Umfang, Festpreis und Abnahme je Etappe, sodass Sie nach jeder aufhören könnten und ein lauffähiges System hätten. Die gesamte Ablösung darf lange dauern, die einzelne Etappe darf nicht offen sein.

Woran es scheitert

  • Der Einbruch zieht mit um. Ein kompromittiertes System bleibt im Container kompromittiert, wenn vorher niemand bereinigt hat.
  • Die neue Plattform ist größer als das Team, das sie betreibt. Kubernetes wird bei solchen Umzügen gern gleich mitbestellt. Für eine einzelne Anwendung reichen Container auf ein oder zwei gewöhnlichen Servern häufig aus, und ein Cluster, den in drei Jahren niemand mehr pflegt, ist derselbe vergessene Server, nur eine Schicht höher.
  • Die Migration hat kein Ende. Ohne abgenommene Etappen laufen altes und neues System auf unbestimmte Zeit nebeneinander, und Sie bezahlen den Betrieb von beiden.

Fünf Fragen für einen ruhigen Dienstag

  • Wann hat das Betriebssystem Ihres Servers zuletzt Sicherheitsupdates bekommen, und wer spielt sie ein?
  • Ließe sich die Anwendung morgen auf einem frischen Server starten, ohne den alten zu kopieren?
  • Wurde ein Backup schon einmal testweise zurückgespielt?
  • Kennen Sie alle Zugänge zu Server und Domain, und wissen Sie, wer sie hat?
  • Wer entscheidet und meldet, wenn bei einem Vorfall personenbezogene Daten betroffen sind?

Bleiben mehrere davon offen, ist das der Zustand vom Sonntagabend in diesem Szenario. Es fehlt nur der Angriff.

Befund: ab 2.980 €, 2–3 Werktage

Wir lesen Ihren Code, Ihre Datenbank und Ihre Infrastruktur und schreiben auf, was wirklich Sache ist. Sie schildern uns Ihr System in drei kurzen Schritten, wir antworten mit einer ehrlichen Einschätzung und einem Festpreis.

Befund anfragen