So wurde unser souveränes GitLab-ERP-System implementiert

Betriebliches Kontinuitätsmanagement ist eines unserer Geschäftsfelder. Wie wird es bei uns eingesetzt? Das Gehirn des Unternehmens ist ein ERP-System, wodurch die Einsatzplanung der vorhandenen Ressourcen stattfindet. Eigentlich wird dadurch alles verwaltet, was etwas mit dem Geschäft zu tun hat, auch die Veröffentlichung dieses Schreibens.

Aus Erfahrung haben wir GitLab gewählt. Damit meinen wir nicht die Dienstleistung gitlab.com sondern die Einrichtung der quelloffenen Software in unserem eigenen privaten Netzwerk.

Wegen der Datensicherheit setzen wir einen eigenen geschlossenen LDAP-Verzeichnisdienst und eine private Infrastruktur für digitale Zertifikate ein. Die sämtlichen Container unserer Dienste werden mithilfe von GitLab-Pipelines in geschlossenen gitlab-runner-Containern in einer isolierten Umgebung aufgebaut. Dank einer zentralen Logbuchverwaltung haben wir stets ein Überblick über das verteilte System. Auf einer ähnlichen Weise funktioniert auch der GitLab-Dienst, den wir unseren Kunden anbieten.

GitLab ist uns nicht nur eine schicke Web-Oberfläche zum Versionsverwaltungssystem git. Einsatzplanung, Verwaltung, standardisierte Betriebsmethoden, Kundenprojekte und der Quelltext der sämtlichen Infrastruktur werden in demselben System untergebracht. Dadurch werden alle Änderungen geplant, rezensiert und getestet bevor sie bereitgestellt werden. Das System der kontinuierlichen Integration und Bereitstellung hält unter anderen unser VPN-Gateway und unsere Nameserver stetig auf dem neuesten Stand, egal ob es um von uns vorgenommene Änderungen, Sicherheitsaktualisierungen oder Zertifikaten geht.

Wegen der Datensicherheit haben wir die Gültigkeitsdauer unserer privaten Zertifikate auf wenige Tage verkürzt. Sollte ein gültiges Zertifikat kompromittiert werden, wird es umgehend durch eine Sperrliste und unseren OCSP-Validierungsdienst entzogen.

Die Gültigkeitsdauer unserer öffentlichen Zertifikate wird von der Zertifikatsstelle Let’s Encrypt festgestellt. Auch sie wird schrittweise von Monaten auf Wochen gekürzt. Eine kurze Gültigkeitsdauer macht praktisch eine automatisierte Erneuerung erforderlich.

Wären wir für die Adresse example.com zuständig und möchte unser Kunde den Dienst https://download.example.com bereitstellen, würden wir die erforderlichen Änderungen (unsere Nameserver aktualisieren und ein öffentliches oder privates Zertifikat für den Namen besorgen) durch GitLab planen, verwirklichen, überprüfen und bereitstellen.

Containerisierte Dienste

Zugunsten der Datensicherheit und Verwaltbarkeit haben wir die Dienste in Containern eingerichtet, die durch sorgfältig begrenzte TCP/IP-Ports miteinander verbunden sind. Die Container ermöglichen eine einfache Aktualisierung und Verteilung der Dienste zwischen Servern. Unsere GitLab-Pipelines und Zeitpläne bestimmen, wie, wo und wann die Container erneuert, geprüft und eingesetzt werden.

Unsere Dienst-Container basieren auf einem aktuellen Basissystem, oft alpine:latest, das nach den in der Versionskontrolle gespeicherten Regeln der jeweiligen Aufgabe angepasst wird.

Die Grundgedanke ist, dass GitLab den sämtlichen Inhalt der Container regelmäßig erneuert und nach einer Funktionsfähigkeitsprüfung in einer Produktionsumgebung bereitstellt. Sollte beispielsweise ein Angriff gegen unseren Webserver erfolgreich sein, könnte der Angreifer möglicherweise den Inhalt verändern. Die nächste planmäßige oder manuell vorgenommene Erneuerung würde den Zustand wiederherstellen und möglicherweise zugleich eine Sicherheitsaktualisierung einbringen, die die ausgenutzte Sicherheitslücke schließen würde.

Der Kern unseres GitLab-Dienstes besteht aus Containern, die sich auf GitLab-Docker-Abbildern und einem Postgres-Abbild gründen. Zu weiteren Diensten drumherum zählen ein LDAP-Verzeichnisdienst und ein Mailserver.

Container aufräumen

Ein Nachteil unserer Arbeitsweise mit oft erneuerten Containern ist der enorme Speicherplatzbedarf. Obwohl die Container normalerweise beim Bedarf relativ schnell wieder aufgebaut werden können, setzen wir ein gesichertes Container-Repository ein. Dadurch ist es uns möglich, diverse Dienste wiederherzustellen, auch wenn eine eingeschränkte Verbindung zum Internet einige Systemverteilungen unverfügbar macht.

Um Platz zu sparen haben wir einen mehrstufigen Aufräumdienst entwickelt, der alle jeweils zur Produktion benötigten Container aufbewahrt, sowie alle Container, die aktiv entwickelt werden. Das Löschen darf nicht einfach vom Datum des letzten Änderung abhängen, denn der Zeitplan zur Erneuerung ist abwechselnd. Außerdem könnte der Inhalt lange unverändert bleiben, falls sich weder die Basis noch unsere Anpassungen seit der letzten Aktualisierung geändert haben.

Ziele der Wiederherstellung und Risikoniveau

Zwei Ziele sind für eine Notwiederherstellung wichtig: Wie viel Datenverlust kann in Kauf genommen werden (der Zeitraum zwischen zwei Datensicherungen: recovery point objective, RPO) und wie lange darf das System ausfallen (die Dauer der Wiederherstellung: recovery time objective, RTO).

Mit der Ausnahme von E-Mail und sicher aufbewahrten privaten Schlüsseln sind fast alle Daten unseres Unternehmens in GitLab gespeichert. Deswegen ist es wichtig, die Verfügbarkeit unseres GitLab-ERP-Systems sicherzustellen.

Ein Ausfall unseres ERP-Systems hat keine direkte Wirkung auf die geleisteten Dienste. Sie werden ja nach unserer verschachtelten Sicherheitsarchitektur in voll isolierten Umgebungen produziert. Nur wenn ein Dienst gleichzeitig mit unserem GitLab-ERP ausfallen sollte, könnte es länger als erwartet dauern, einen der Öffentlichkeit verfügbaren Dienst wiederherzustellen.

Unsere gezielte Wiederherstellungsdauer ist also relativ locker, vielleicht einige Arbeitstage. So lange könnten wir schlimmstenfalls brauchen, um das System zum Beispiel nach einem Brand in einem neuen Standort einzurichten.

Zur Zeit sichern wir die Daten einmal pro Woche. Wir könnten also die Daten von einigen Arbeitstagen verlieren. Die wichtigsten davon könnten manuell wiederhergestellt werden, mithilfe der gesandten E-Mail-Nachrichten und der git-Repositories einzelner Mitarbeiter.

Das Risikoniveau und die Wiederherstellungsdauer könnten durch den Aufbau eines hochverfügbaren Dienstes drastisch reduziert werden, so dass beim Ausfall schnell zu einem anderen Gerät gewechselt wird. Eine Echtzeit-Replizierung zwischen geographisch verteilten Standorten ist jedoch mühsam zu verwirklichen und zu überprüfen.

Gesicherte Schnappschüsse zur Wiederherstellung

Wegen der Störempfindlichkeit vermeiden wir differenzielle und inkrementelle Sicherung. Wir setzen auf Komplettsicherung und logische Sicherung des Datenbankinhalts. Obwohl das GitLab-System aus locker gekoppelten Komponenten besteht und somit der persistente Zustand verteilt gespeichert ist, ist es heute möglich, einen konsistenten Schnappschuss anzufordern ohne das System anzuhalten.

Das Wiederherstellen der Datenbank aus einer logischen Sicherung mag länger dauern als aus einer physischen Sicherung, wo die Indexe vorhanden wären. Das Datenvolumen einer logischen Sicherung ist geringer, und bei der Wiederherstellung wird eine mögliche interne Korruption geheilt. Das logische Format ist weniger störanfällig, sollte eine aktualisierte Version des Datenbanksystems das physische Format verändern.

Vor jeder Aktualisierung des Systems ist es sinnvoll, eine Datensicherung durchzuführen. Falls Probleme auftauchen, kann das System mit der alten Programmversion und Dateninhalt wiederhergestellt werden. Das Datenformat kann sich ja bei der Aktualisierung dermaßen ändern, dass ein Rückkehr auf die alte Version unmöglich ist. Besonders große Aktualisierungen sollten in einer separaten Umgebung sorgfältig getestet werden, bevor die Produktionsumgebung umgesetzt wird.

Wir begrenzen den Speicherbedarf der Datensicherung. Vor einem Sicherungsvorgang werden die Container aufgeräumt, welches das Ausführen von GitLab-Pipelines für eine kurze Zeit blockiert. Wir setzen das Generationenprinzip (Großvater, Vater, Sohn) ein: Von den gesicherten Schnappschüssen bewahren wir nur einige der letzten auf. Von Sicherungen, die älter als einige Monate sind, wird eine pro Monat aufbewahrt. Von monatlichen Sicherungen, die älter als ein paar Jahre sind, wird nur eine pro Jahr verwahrt.

Diese Vorgehensweise begründen wir damit, dass Daten selten gelöscht werden, üblicherweise durch Aufbewahrungsfristen verpflichtet. Zwischen den gesicherten Schnappschüssen werden typisch nur neue Daten eingetragen. Wenn etwas in einer Versionsverwaltung gelöscht oder geändert wird, wird eine neue Version angelegt. Der gesamte Änderungsverlauf wird in git verlagert. Nur das Löschen eines Repositoriums wäre endgültig – und sehr selten.

Wiederherstellung prüfen

Das Wiederherstellen aus einem gesicherten Schnappschuss muss regelmäßig geprüft werden und nicht erst bei einem Notfall. Ansonsten könnte eine doppelte Katastrophe vorkommen: wenn es sich herausstellt, dass der letzte brauchbare Schnappschuss sehr alt ist, muss wesentlich mehr Datenverlust als erwartet in Kauf gekommen werden.

Weil unsere Daten sowohl im Ruhezustand als auch während der Übertragung verschlüsselt sind, ist die Wiederherstellung mit Schlüsselverwaltung verbunden. Die Schlüssel müssen natürlich von den verschlüsselten Daten getrennt aufbewahrt werden, ansonsten ist ja die Verschlüsselung nutzlos.

Zu dem durch GitLab-Pipelines und Zeitpläne gesteuerten regelmäßigen Sicherungsvorgang gehört natürlich auch das Prüfen der Wiederherstellung in einer isolierten Container-Umgebung. Sollte das scheitern, wird ein Alarm ausgelöst.

Wir prüfen regelmäßig und protokolliert die Wiederherstellung aus einer Fernsicherung.

Fazit

Ein Unternehmen, das in einem regulierten Geschäftsfeld tätig ist, muss seine Datensicherheit, Datenschutz und Geschäftskontinuität gewährleisten. Durch ein ERP-System, das standardisierte Betriebsmethoden und automatisierte Vorgänge unterstützt, wird das gezielte Serviceniveau erreicht. Heute ist es möglich, all das anbieterunabhängig mithilfe quelloffener Software zusammenzustellen.