SAP ILM trifft Cloud-Storage: Warum der „Retention-Lock“ auf File-Ebene die IT-Infrastruktur blockiert – und wie es besser geht

Das Dilemma: Compliance vs. Infrastruktur-Agilität

Die regulatorischen Anforderungen an Unternehmen wachsen kontinuierlich. Die DSGVO verlangt das strikte Löschen von personenbezogenen Daten nach Zweckfortfall (Right to be forgotten), während steuerrechtliche Vorgaben (GoBD) eine unveränderbare Aufbewahrung über viele Jahre vorschreiben. Das Werkzeug der Wahl im SAP-Kosmos ist SAP ILM.

Traditionell wurden diese Sperren (Retentions) über das WebDAV-Protokoll direkt an das darunterliegende Storage-System (z. B. klassische WORM-Speicher) übergeben. Das Storage-System sperrt die Datei physisch für den Zugriff und das Löschen bis zum Tag X.

Das Problem in der Praxis: Unternehmen migrieren heute massiv in die Cloud oder auf On-Premises-Objektspeicher (S3 / Azure Blob Storage). Wird hier ein unnachgiebiger „Object Lock“ oder „Retention Lock“ auf Storage-Ebene hart gesetzt, ist die IT-Infrastruktur für Jahre eingefroren. Eine vorzeitige Migration der Daten auf einen kostengünstigeren Cloud-Tier, die Konsolidierung von Speicherlandschaften oder der Wechsel des Cloud-Providers werden unmöglich, weil das Storage-System die Bewegung oder das Löschen der betroffenen Blöcke strikt verweigert – selbst wenn es sich um intern notwendige Systemumzüge handelt.

Warum Hard-Locks auf Speicher-Ebene ein technologischer Anachronismus sind

Wenn die IT-Infrastruktur starr an die logischen Löschfristen der Applikation gekoppelt ist, entstehen drei operative Bottlenecks für DMS-Experten und SAP-Archivare:

1. Inflexible Cloud-Strategien: Ein Providerwechsel oder der Umzug von AWS zu Azure (oder zurück in eine Private Cloud) wird blockiert, da gesperrte Objekte nicht verschoben oder gelöscht werden dürfen.
2. Kosten-Inland: Daten, die eigentlich auf kältere, günstigere Storage-Klassen (z. B. Glacier) verschoben werden könnten, verbleiben im teuren Hot-Storage, weil die Sperre granulare Verschiebungen technisch verhindert.
3. Fehlende logische Abstraktion: Die Speicher-Ebene „weiß“ nichts vom betriebswirtschaftlichen Kontext. Sie führt nur einen Timer aus.

Der Lösungsansatz: Logische vs. Physische Immutability via CMIS

Moderne IT-Architekturen verlagern die Intelligenz weg von der Hardware-Komponente (Storage) hin zu einer schlanken Middleware. Hier kommt der moderne CMIS-Standard (Content Management Interoperability Services) im Zusammenspiel mit SAP ILM ins Spiel.

Anstatt Dateien auf Dateisystem-Ebene physisch unlesbar und unverschiebbar zu sperren, verwaltet eine intelligente Archiv-Middleware wie kgs tia® den Lebenszyklus.

Wie funktioniert die anwendungsgesteuerte Aufbewahrung?

• Metadaten-basierter Schutz: Beim Ablegen eines Dokuments aus SAP ILM heraus werden die Retention-Schnittstellen via CMIS bedient. Das kgs-Archiv speichert die Aufbewahrungsfrist als geschütztes Metadatum.
• Intelligente Zugriffskontrolle: Die Middleware verhindert über strikte Protokolle jegliche Lösch- oder Änderungsbefehle von außen auf dieses Dokument, solange die Frist läuft. Für das SAP-System und Auditoren ist die Revisionssicherheit zu 100 % garantiert.
• Infrastruktur-Freiheit: Da der darunterliegende Objektspeicher (S3/Blob) keine harte, proprietäre Hardware-Sperre aufweist, kann die IT-Abteilung die Daten im Hintergrund migrieren, spiegeln, sichern oder auf kostengünstigere Tiers verschieben. Die logische Sperre wandert im Archiv-Layer einfach mit.

Fazit für SAP-Basis- und DMS-Verantwortliche

Revisionssicherheit und DSGVO-Konformität dürfen im Jahr 2026 kein Grund mehr sein, sich technologische Fesseln auf Infrastruktur-Ebene anzulegen. Wer SAP ILM einführt oder optimiert, sollte die Speicher-Sperren entkoppeln.

Durch den Einsatz einer schlanken Middleware, die nativ CMIS spricht und die logische Verwaltung von Aufbewahrungsfristen übernimmt, bleibt die IT-Infrastruktur agil. Das Ergebnis: Volle Compliance bei maximaler Freiheit in der Multi-Cloud-Strategie und spürbar reduzierten Total Cost of Ownership (TCO).

‍