Warum kryptografische Schlüssel genauso wichtig sind wie Ihre Daten

Was viele vergessen: Backups sichern keine Schlüssel

In der Praxis wird häufig angenommen, dass ein vollständiges Backup, etwa via Backint, Veeam oder klassischen Filesystem-Backups, auch automatisch alle notwendigen Schlüssel enthält. Doch genau hier liegt ein Trugschluss:
Kryptografische Schlüssel werden oft außerhalb der Datenbank oder Applikation gehalten, sei es:

• in dedizierten Schlüsseldateien (wie dem SSFS bei SAP HANA)
• in Trusted Platform Modules (Chip auf der Hauptplatine)
• Hardware-Sicherheitsmodul (z.B. USB HSM)

Diese Schlüssel sind nicht unbedingt automatisch Teil eines Standard-Backups und ihr Verlust bedeutet im schlimmsten Fall: Die Daten sind zwar vorhanden, aber dauerhaft unlesbar.Das Runde passt nicht ins Eckige

Praxisbeispiel: Datenbank-Tenant gelöscht, Schlüsselspeicher neugeschrieben

In einem konkreten Fall sollte ein Datenbank-Tenant aus einem Backup auf neuer, dedizierter Hardware wiederhergestellt werden. Die HANA®-Datenbank lief zuvor stabil, der Tenant wurde jedoch für den weiteren Prozess der Dekommissionierung schon übereifrig gelöscht. Aus einem Backint-Backup sollte die Datenbank auf einem frischen System wiederhergestellt werden.

Die Crux:
Der dazugehörige Schlüssel der Verschlüsselung war im Secure Store (SSFS) gespeichert und die Datei wurde durch das Löschen des Tenants auf dem alten System bereits neugeschrieben.
Das neue System hatte logischerweise keine Kopie dieser Datei und somit keine Möglichkeit das Backup zu entschlüsseln und wiederherzustellen.

Was macht das SSFS so besonders?

Das „Secure Store in the File System“ (SSFS) ist eine zentrale Datei bei SAP®-Systemen, die Verschlüsselungsschlüssel speichert. Etwa für HANA®, ABAP®-Instanzen oder Kommunikationszertifikate. Es handelt sich um eine binäre Datei mit definierter Struktur. In ihr stehen viele Metadaten, wie auch die Schlüssel zu den verschiedenen Backups der Tenants. Die enthaltenen Schlüssel können aber auch irrelevant sein, wenn man zum Beispiel die Verschlüsselung generell deaktiviert hat, sodass bessere Möglichkeiten der Speicher-Deduplikation genutzt werden können. Das Problem: Auch wenn Verschlüsselung global deaktiviert wurde, kann diese für einen einzelnen Tenant aktiviert sein oder auch durch neue Sicherheitsupdates aktiviert worden sein.

Technische Tiefenrettung: Reverse Engineering, da kein Restore möglich

Leider können wir in den HTTP-Request nicht einfach die URL eingeben, wie wir sie sonst in SharePoint nutzen. Wir brauchen IDs… Je nachdem, wie universell die Lösung eingesetzt werden soll, resultiert dies in viele Unterabfragen zur Ermittlung von der Site-ID über die Library-ID bis zur (Sub-)Folder-ID und Datei-ID. Falls die Abfragen bei anderen/zukünftigen Flows einen Nutzen bringen, empfiehlt es sich das Ganze als Child-Flow aufzubauen. Hiermit lässt sich der Ablauf dann als Funktion aus dem Haupt-Flow aufrufen. Der Übersicht kommt dies ebenfalls zugute.

Da keine Versionierung oder Kopie der Datei existierte und daher …

• keine Backups des Betriebssystems existierten,
• ein Dateisystem vorlag, was eine Wiederherstellung praktisch unmöglich machte,
• keine Kopie der Datei auf andere Server oder andere Verzeichnisse gemacht worden ist,
• keine Snapshots oder Crashdumps existierten,

war eine Wiederherstellung nicht möglich.

Genauere Analyse:

• angelegte Trace-Dateien (Aufzeichnungen aller SAP®-Befehlsausführungen)

(Vgl. Grafik 1)

• SSFS-Dateistrukturen

(Vgl. Grafik 2)
(Quelle: https://pysap.readthedocs.io/en/latest/fileformats/SAPSSFS.html)

• ursprüngliche Schlüsselstrukturen und Behandlung der enthaltenen Meta-Daten durch Reverse Engineering

Hierdurch konnten die entsprechenden Daten der Schlüssel wiederhergestellt werden, wodurch auch eine komplette Wiederherstellung des Datenbankbackups möglich war.

Fazit: Schlüsselmanagement ist ein kritischer Punkt in der IT-Sicherheit

Das Beispiel zeigt:
Kryptografische Schlüssel sind genauso wichtig wie die Daten selbst.
Ein Restore ohne Schlüssel ist wie ein Tresor ohne korrekte Kombination – der Inhalt ist sicher, aber er bleibt verschlossen.

Empfehlungen für Unternehmen:

• Sichern Sie Schlüsseldateien separat und versioniert
• Dokumentieren Sie alle Orte, an denen Schlüssel gespeichert werden und ob gegebenenfalls die Verschlüsselung durch Updates automatisch aktiviert wurde
• Behandeln Sie die Schlüsseldateien so kritisch wie das Backup selbst
• Integrieren Sie Backup-Validierung in Ihre Betriebsprozesse

Wie sieht es bei Ihnen aus? Werden Backups verschlüsselt oder werden diese nur über gesicherte Kanäle geschickt? Existierte auch schon ein nicht mehr wiederherstellbares Backup?

Wir helfen gerne, die richtige Backup Strategie zu implementieren oder bei der Wiederherstellung von Backups oder Backup-Validierungen.

Einfach schreiben an service@inwerken.de. Unser IT-Infrastruktur-Team meldet sich bei Ihnen! Leistungen darüber hinaus finden Sie in unserem Portfolio.