Inhaltsverzeichnis
Ein verschlüsseltes HANA-Backup klingt zunächst nach mehr Sicherheit. Im Ernstfall kann es aber wertlos sein, wenn der passende Schlüssel fehlt oder niemand weiß, wie er sicher bereitgestellt wird. Genau deshalb beginnt die SAP HANA-Verschlüsselung nicht beim Aktivieren einer Funktion, sondern beim Key Management.
In vielen SAP-Landschaften wird das Thema erst relevant, wenn ein Audit ansteht, eine Security-Richtlinie greift oder der Schutz von Backups neu bewertet wird. SAP HANA bringt dafür native Funktionen mit, etwa für Data Volumes, Redo Logs und native Backups. Die Aktivierung ist in vielen Fällen technisch überschaubar. Der entscheidende Teil liegt im Betrieb: Schlüssel, Recovery-Prozess und Dokumentation müssen zusammenpassen.
Wann eine HANA-Verschlüsselung sinnvoll ist
Eine SAP HANA-Verschlüsselung sollte nicht automatisch auf jedem System aktiviert werden. Für SAP HANA On-Premise ist eine anlass- und risikobezogene Bewertung sinnvoll.
Typische Auslöser sind Audit-Anforderungen, Konzernrichtlinien, regulatorische Vorgaben oder ein konkreter Schutzbedarf für persistierte Daten und Backups. Wichtig ist die Einordnung: HANA-Verschlüsselung schützt Daten auf Dateisystemebene. Sie ersetzt kein Berechtigungskonzept, keinen sauberen Betrieb und keinen getesteten Restore.
Was SAP HANA verschlüsseln kann
SAP HANA unterstützt die Verschlüsselung in der Persistenzschicht. Dazu gehören Data Volume Encryption für Datenbereiche auf Disk, Redo Log Encryption für persistente Logbereiche und Backup Encryption für native Daten- und Log-Backups. SAP verwendet für die Verschlüsselung auf Dateisystemebene standardmäßig den AES-256-Bit-Algorithmus.
Auch die Grenzen sollten bekannt sein. Der Backup-Katalog, beziehungsweise die zugehörigen Metadaten, sind nicht im gleichen Sinn durch die HANA Backup Encryption geschützt wie die Backup-Payload selbst. Sie sollten separat in das Schutzkonzept einbezogen werden.
Storage- oder Data-Snapshot-basierte Sicherungen werden ebenfalls nicht durch die HANA Backup Encryption verschlüsselt. Ob die darin enthaltenen Daten geschützt sind, hängt unter anderem von Data Volume Encryption sowie von Storage- und Infrastrukturmaßnahmen ab.
Aktivierung: technisch einfach, organisatorisch komplex
Die technische Aktivierung kann, je nach Systemstand und Betriebsmodell, über SAP HANA Cockpit oder per SQL erfolgen. Auch der Status lässt sich im System nachvollziehen, zum Beispiel über SAP HANA-Systemviews oder Cockpit-Kacheln.
Trotzdem ist die Aktivierung nur ein Teil des Projekts. Vorher sollte klar sein, welche Systeme, Datenbanken und Tenants betroffen sind. Ebenso wichtig sind vorhandene Backup-Verfahren, Snapshot-Konzepte, System Replication und geplante Restore-Szenarien.
In der Praxis zeigt sich häufig: Der Schalter ist schnell gesetzt. Die relevanten Fragen kommen danach. Wo liegt der Key? Wer darf darauf zugreifen? Was passiert bei Urlaub, Krankheit oder Personalwechsel? Und kann ein verschlüsseltes Backup auf einem neu aufgebauten System wiederhergestellt werden?
Key Management entscheidet über den Ernstfall
SAP HANA arbeitet mit Root Keys beziehungsweise einer Schlüsselhierarchie. Für Data Volume Encryption, Redo Log Encryption und Backup Encryption sind die jeweils passenden Root Keys und deren Versionen relevant. Gerade bei Backup Encryption müssen aktuelle und ältere Versionen des Backup Encryption Root Keys gesichert bleiben, weil ältere verschlüsselte Backups ältere Key-Versionen benötigen können.
Intern verwaltet SAP HANA Schlüsselmaterial über Secure-Store-Mechanismen wie SSFS beziehungsweise, je nach Version und Konfiguration, Local Secure Store. Für Recovery-Szenarien ersetzt das jedoch nicht das separate, dokumentierte Backup der relevanten Root Keys.
Ohne passenden Root Key beziehungsweise ohne Zugriff auf die passende Root-Key-Version kann ein verschlüsseltes Backup, insbesondere bei Restore auf ein anderes oder neu aufgebautes System, nicht nutzbar sein. Besonders kritisch sind Systemkopien, Disaster-Recovery-Szenarien und tenantbezogene Wiederherstellungen. Die Backup-Datei kann vollständig vorhanden sein. Ohne Key fehlt trotzdem die Grundlage für die Wiederherstellung.
Deshalb gehört das Root-Key-Backup fest in das Backup- und Recovery-Konzept. Nach Aktivierung, Root-Key-Erzeugung oder Root-Key-Wechsel sollte geprüft werden, ob die relevanten Keys gesichert sind und ob die Wiederherstellung dokumentiert ist.
Wo wird der Key abgelegt?
Die Ablage des Keys ist kein Detail für später. Sie entscheidet darüber, ob die Verschlüsselung im Audit und im Notfall funktioniert.
Je nach Unternehmensvorgaben kommen unterschiedliche Modelle infrage: ein zentrales Secret- oder Passwort-Management-System, eine gesicherte physische Ablage, die getrennte Aufbewahrung von Backup und Key, ein Vier-Augen-Prinzip oder ein klarer Notfallzugriff für Disaster Recovery. Entscheidend ist, dass die Key-Ablage zentral definiert, geschützt und auffindbar dokumentiert ist. Sie darf nicht von Einzelwissen einzelner Administratoren abhängen.
Ein verschlüsseltes Backup hilft wenig, wenn der Key unkontrolliert verfügbar ist. Ein perfekt geschützter Key hilft aber auch nicht, wenn im Notfall niemand darauf zugreifen darf.
Zugriff nach Zuständen regeln
Ein gutes Key-Konzept unterscheidet zwischen Regelbetrieb und Ausnahmefällen. Im Alltag sollte der Zugriff auf Root-Key-Backups stark begrenzt sein. Für Restore-Tests, Audit-Nachweise, Incidents und Disaster Recovery braucht es dagegen einen dokumentierten Ablauf.
Sinnvoll ist eine klare Regelung nach Zuständen: Regelbetrieb, geplanter Restore-Test, Audit-Nachweis, Incident und Disaster-Recovery-Fall. Für jeden Zustand sollte festgelegt sein, wer Zugriff beantragen, genehmigen, durchführen und dokumentieren darf.
Spätestens im Audit oder bei einem ungeplanten Restore reicht „Das weiß Kollege X" nicht mehr aus. Die Abläufe müssen auffindbar, freigegeben und aktuell sein.
Dokumentation für Auditoren und Betrieb
Auditoren fragen selten nur nach dem technischen Status. Meist geht es um Nachvollziehbarkeit: Welche Verschlüsselung ist aktiv? Wer ist verantwortlich? Wo liegt der Key? Wer darf darauf zugreifen? Wurde die Wiederherstellung getestet?
Für Auditoren eignet sich eine kompakte Word-Dokumentation mit Scope, aktivierten Verschlüsselungsfunktionen, Zuständigkeiten, Key-Backup, Zugriffskonzept und Wiederherstellungsnachweis. Für den Betrieb sollte es zusätzlich eine gepflegte Dokumentation geben. Dort gehören technische Details, Rollen, Ablaufbeschreibungen, Notfallprozess und wiederkehrende Prüfpunkte hinein.
Typische Risiken
Die größten Risiken entstehen nicht durch die HANA-Funktion selbst, sondern durch fehlende Vorbereitung. Typische Stolpersteine sind nicht gesicherte Root Keys, unklare Zuständigkeiten, fehlende Restore-Tests, eine unsaubere Trennung von Backup und Key oder der Einsatz auf hoch ausgelasteten Systemen ohne vorherige Bewertung.
Bei System Replication, Snapshots oder Systemkopien sollte zusätzlich geprüft werden, welche Keys und Secure-Store-Informationen für das jeweilige Recovery-Szenario relevant sind. Restore im gleichen System, Restore auf einem neu aufgebauten System und Snapshot-basiertes Recovery sind nicht dasselbe.
Wenn Sie Hilfe benötigen
Wir unterstützen Unternehmen dabei, die SAP HANA-Verschlüsselung fachlich sauber, technisch kontrolliert und auditfähig umzusetzen. Dabei betrachten wir nicht nur die Aktivierung, sondern auch Key Management, Backup- und Recovery-Prozesse, Rollen, Dokumentation und Nachweise.
Das Ziel ist eine Lösung, die im Betrieb funktioniert. Die Verschlüsselung soll nicht nur eingeschaltet sein. Sie muss im Audit erklärbar sein und im Ernstfall tragen.
Sie möchten wissen, ob Ihre HANA-Landschaft auditfähig verschlüsselt ist, inklusive Key Management und Restore-Konzept? Kontaktieren Sie uns!
