Ausgangslage
Ein Logistikunternehmen in Vilnius, Litauen, mit 80 Mitarbeitenden betreibt zwei Lager und einen eigenen Fuhrpark. Der gesamte Betrieb dreht sich um das Lagerverwaltungssystem: Wareneingang, Kommissionierung, Versand, Papiere für die Fahrer. Fällt das System aus, stehen die Gabelstapler im Lager still, und die Lkw warten an der Rampe.
Das System lief auf zwei physischen Servern in einem Büroraum – ein Serverraum, der in Wirklichkeit eine ehemalige Abstellkammer mit Klimagerät war. Die Server waren sieben Jahre alt, die Garantie längst abgelaufen, und einer von ihnen hatte sich im vergangenen Jahr zweimal wegen Überhitzung abgeschaltet. Jeder Ausfall kostete das Lager mehrere Stunden Handarbeit und verzögerte Lieferungen.
Hinzu kam ein Sicherheitsproblem. Fahrer und Lagerpersonal griffen von Handys und Tablets über einen offenen Remote-Desktop-Port auf das System zu. Als der Betriebsleiter sah, welche Fragen Kunden zur Cybersicherheit von Lieferanten stellten, wurde ihm klar, dass das so nicht weitergehen konnte.
Was gebraucht wurde
Mit dem Betriebsleiter und dem Finanzleiter vereinbarten wir folgende Ziele:
- Die Abhängigkeit von physischer Hardware im Büro beseitigen: keine Server mehr kaufen und keinen Serverraum mehr betreiben.
- Das Lagersystem muss für beide Schichten laufen, die Migration durfte daher nur wenige Stunden Unterbrechung verursachen und musste an einem Wochenende erfolgen.
- Sicherer Zugriff aus den Lagern, von unterwegs und von zu Hause, ohne offene Ports im Internet.
- Backups an mehr als einem Standort und eine schriftlich festgelegte Wiederherstellungszeit, die man Kunden zeigen kann.
- Updates und Wartung sind nicht mehr Sache des Unternehmens.
- Termin: der Beginn der Hauptsaison, etwa fünf Wochen später.
Was wir getan haben
Woche 1: Audit und Plan
Wir haben gemessen, was das System tatsächlich verbraucht: Prozessorlast, Arbeitsspeicher und Festplattenzugriffe zu Spitzenzeiten. Das war wichtig, weil der Hersteller des Lagersystems deutlich mehr Ressourcen empfohlen hatte, als in der Praxis nötig waren. Mit dem Hersteller stimmten wir das Verfahren zur Datenbankmigration und das Testszenario ab. Wir erstellten einen Migrationsplan mit Rückfalloption für den Fall, dass etwas schiefgeht.
Woche 2: die Cloud-Umgebung
In unserem Rechenzentrum in Litauen richteten wir drei Cloud-Server mit Betreuung ein: für die Anwendungsebene des Lagersystems, für die Datenbank und für das Buchhaltungssystem, das sich bis dahin einen Server mit dem Lagersystem geteilt hatte. Auf allen Servern wurden Bitdefender GravityZone, Monitoring und eine automatisierte Update-Verwaltung installiert.
Parallel bauten wir ein VPN-Netz auf, das beide Lager, das Büro und die Cloud verbindet. Für mobile Geräte stellten wir einen VPN-Client mit Zwei-Faktor-Authentifizierung bereit. Der offene Remote-Desktop-Port wurde geschlossen.
Woche 3: Probemigration
Wir verschoben eine Kopie des Systems in die Cloud und ließen die Lagerleiter zwei Tage lang in der Testumgebung arbeiten: Waren annehmen, kommissionieren, Dokumente drucken. Hier kam der schwierigste Punkt ans Licht. Die Etikettendrucker in den Lagern waren auf die IP-Adresse des alten Servers eingestellt, und für einige gab es gar keine Dokumentation. In zwei Tagen gingen wir alle 14 Drucker durch und korrigierten die Konfiguration über das VPN.
Woche 4: Migration
Die Migration führten wir in der Nacht auf Samstag durch. Wir hielten das alte System an, übertrugen den letzten Stand der Datenbank und stellten Arbeitsplätze und Geräte um. Der Lagerleiter prüfte am Sonntagmorgen die wichtigsten Abläufe. Die tatsächliche Nichtverfügbarkeit betrug etwa vier Stunden, alle außerhalb der Arbeitszeit. Die alten Server blieben noch zwei Wochen als Rückfallebene eingeschaltet und wurden dann abgeschaltet.
Woche 5: Backups und Betrieb
Wir richteten das Server-Backup mit Veeam ein: Die täglichen Sicherungen bleiben in Litauen, eine zweite Kopie geht an ein Amazon-Rechenzentrum in Deutschland. Die Wiederherstellung haben wir getestet und gemessen: Das gesamte Lagersystem ist in unter drei Stunden aus dem Backup zurück, daher haben wir mit etwas Reserve eine RTO von vier Stunden in den Vertrag geschrieben. Das Wartungsfenster wurde auf die Nacht von Dienstag auf Mittwoch gelegt, wenn im Lager am wenigsten los ist.
Ergebnis
In den ersten sechs Monaten nach der Migration gab es beim Lagersystem keinen einzigen ungeplanten Ausfall. Wir messen das mit einem Monitoring-System, das jede Minute Nichtverfügbarkeit erfasst, und der Kunde erhält jeden Monat einen Bericht. Geplante Updates laufen nachts, die Mitarbeitenden bemerken sie nicht.
Die vereinbarte Wiederherstellungszeit beträgt 4 Stunden und ist durch einen echten Test bestätigt, nicht durch eine Berechnung. Die Backups liegen an zwei Orten: in Litauen und in Deutschland. Dadurch konnte der Betriebsleiter die Sicherheitsfragebögen von Kunden mit konkreten Fakten statt mit Versprechen beantworten.
Der Serverraum im Büro ist abgebaut, das Klimagerät abgeschaltet. Der Finanzleiter hat im Budget die Position für den Server-Austausch durch eine monatliche Servicegebühr ersetzt, die im Voraus bekannt ist.
„Früher habe ich montagmorgens nachgesehen, ob die Server noch leben. Jetzt schaue ich nur noch in den Bericht.“
Was wir in einer ähnlichen Situation raten
- Messen Sie die tatsächliche Last, bevor Sie Server umziehen. Die Empfehlungen von Anwendungsherstellern enthalten oft einen großen Puffer, und Sie zahlen die Ressourcen jeden Monat.
- Machen Sie eine Probemigration und lassen Sie echte Mitarbeitende in der Testumgebung arbeiten. Drucker, Scanner und Schnittstellen zu Lieferanten zeigen Probleme nur auf diesem Weg.
- Schreiben Sie die Wiederherstellungszeit erst nach einem echten Test in den Vertrag. Vier Stunden auf dem Papier und vier Stunden in der Praxis sind nicht dasselbe.
- Schließen Sie offene Remote-Desktop-Ports sofort, vor jeder Migration. Das ist der häufigste Weg, auf dem Ransomware in Logistikunternehmen gelangt.
