6 Datenverschlüsselung ist einer dieser Begriffe, die in jedem Compliance-Rahmenwerk, jeder Checkliste für Sicherheitsaudits und jeder Vertriebspräsentation von Anbietern auftauchen – und doch wird sie gerade auf der Ebene, die für regulierte Organisationen wirklich zählt, häufig missverstanden. Die meisten Teams wissen, dass Verschlüsselung vorgeschrieben ist. Weit weniger verstehen genau, was sie leistet, wo sie angewendet werden muss, wovor sie nicht schützt und wie Verschlüsselungsentscheidungen auf der Speicherebene die Compliance-Lage in Bezug auf DSGVO, HIPAA, FIPS, NIS2 und DORA beeinflussen. Dieser Leitfaden richtet sich an Compliance-Verantwortliche, IT-Leiter im öffentlichen Sektor und Speicherarchitekten, die über die oberflächliche Definition hinausgehen und Verschlüsselung im Kontext von Enterprise-Datenspeicher verstehen wollen – dort, wo die praktischen Entscheidungen fallen und Compliance-Risiken entstehen oder beseitigt werden. Was Datenverschlüsselung tatsächlich leistet Im Kern ist Datenverschlüsselung der Prozess, lesbare Daten – Klartext – mithilfe eines mathematischen Algorithmus und eines Verschlüsselungsschlüssels in ein unlesbares Format – Chiffretext – umzuwandeln. Nur wer über den richtigen Entschlüsselungsschlüssel verfügt, kann den Vorgang umkehren und die ursprünglichen Daten lesen. Der Zweck ist einfach: Gelangt eine unbefugte Partei an verschlüsselte Daten – durch eine Datenpanne, eine Insider-Bedrohung, eine falsch konfigurierte Berechtigung oder ein beschlagnahmtes Speichergerät –, sind die Daten ohne den Schlüssel unlesbar. Verschlüsselung verhindert keinen unbefugten Zugriff. Sie macht diesen Zugriff wertlos. Diese Unterscheidung ist für die Compliance wichtig. Vorschriften verlangen nicht, dass es nie zu Datenpannen kommt. Sie verlangen, dass der Schaden bei unbefugtem Zugriff auf Daten minimiert wird. Verschlüsselung ist die wichtigste technische Maßnahme, um diese Anforderung zu erfüllen. Nach Art. 32 DSGVO etwa wird Verschlüsselung ausdrücklich als geeignete technische Maßnahme zum Schutz personenbezogener Daten genannt. Unter HIPAA ist die Verschlüsselung geschützter Gesundheitsdaten im Ruhezustand und bei der Übertragung eine anerkannte „addressable“ Umsetzungsvorgabe, die in der Praxis von den meisten betroffenen Einrichtungen wie eine Pflicht umgesetzt wird. Zu verstehen, was Verschlüsselung leistet – und was nicht –, ist der Ausgangspunkt für eine Speicherarchitektur, die Compliance-Pflichten tatsächlich erfüllt, statt dies nur vorzugeben. Verschlüsselung im Ruhezustand vs. Verschlüsselung bei der Übertragung Es gibt zwei Hauptkontexte, in denen Datenverschlüsselung bei Enterprise-Speicher greift, und Compliance-Rahmenwerke behandeln sie unterschiedlich. Verschlüsselung im Ruhezustand schützt Daten, die auf physischen Medien gespeichert sind – Festplatten, SSDs, Band oder beliebigem persistentem Speicher. Wird ein Laufwerk aus einem Rechenzentrum entfernt, gestohlen oder ohne ordnungsgemäße Datenlöschung ausgemustert, stellt die Verschlüsselung im Ruhezustand sicher, dass die Daten darauf unlesbar sind. Sie schützt außerdem vor unbefugtem Zugriff auf die rohe Speicherinfrastruktur unterhalb der Anwendungs- oder API-Ebene. Verschlüsselung bei der Übertragung schützt Daten, während sie zwischen Systemen übertragen werden – zwischen einem Client und einer Speicherplattform, zwischen Rechenzentren, zwischen On-Premises-Infrastruktur und Cloud-Umgebungen. Ohne Verschlüsselung bei der Übertragung können Daten im Netzwerk abgefangen und gelesen werden. TLS (Transport Layer Security) ist der Standardmechanismus für die Verschlüsselung bei der Übertragung in modernen Speicherumgebungen und wird typischerweise über HTTPS für die gesamte S3-API-Kommunikation erzwungen. Die meisten Compliance-Rahmenwerke verlangen beides. Konformer S3-Speicher für regulierte Umgebungen (auf Englisch) erzwingt die Verschlüsselung im Ruhezustand auf Objektebene und verlangt, dass alle übertragenen Daten über verschlüsselte Verbindungen laufen. Wer eines davon als optional behandelt, schafft eine Compliance-Lücke, die Prüfer finden werden. Der Verschlüsselungsstandard, auf den es ankommt: AES-256 Wenn in der Dokumentation von Enterprise-Speicher von Verschlüsselung die Rede ist, ist fast immer AES gemeint – der Advanced Encryption Standard – und insbesondere AES-256 mit einer Schlüssellänge von 256 Bit. AES-256 ist der weltweite Standard für die Verschlüsselung sensibler Daten im Ruhezustand. Er ist vom NIST zugelassen, wird von FIPS 140-2 und FIPS 140-3 für Workloads der US-Bundesbehörden verlangt und von allen wichtigen Compliance-Rahmenwerken akzeptiert, darunter DSGVO, HIPAA, PCI-DSS und NIS2. Die Schlüssellänge von 256 Bit bedeutet 2²⁵⁶ mögliche Schlüssel – eine so große Zahl, dass Brute-Force-Angriffe mit absehbarer Technologie rechnerisch nicht durchführbar sind. Ein praktischer Vorteil für Enterprise-Speicherumgebungen: Moderne Prozessoren verfügen über Hardwarebeschleunigung für AES-Operationen, sodass sich AES-256-Verschlüsselung ohne nennenswerte Performance-Einbußen universell auf Speicher im Petabyte-Bereich anwenden lässt. Verschlüsselung muss nicht selektiv für sensible Datenkategorien aktiviert werden – sie kann und sollte standardmäßig für alle Objekte erzwungen werden. Das beseitigt das betriebliche Risiko unverschlüsselter Daten in der Umgebung, nur weil jemand vergessen hat, die Einstellung zu aktivieren. Verschlüsselungsmodi in S3-kompatiblem Speicher Für Unternehmen, die S3-kompatiblen Object Storage nutzen – inzwischen die Mehrheit der Unternehmensdatenumgebungen –, steht Verschlüsselung über drei standardisierte serverseitige Verschlüsselungsmodi zur Verfügung. Die Unterschiede zu verstehen ist für Architekturentscheidungen im Sinne der Compliance unerlässlich. SSE-S3 (serverseitige Verschlüsselung mit plattformverwalteten Schlüsseln) ist der Basismodus. Die Speicherplattform verschlüsselt jedes Objekt automatisch mit AES-256. Die Schlüssel werden intern erzeugt und verwaltet. Für viele Workloads bietet das starke Verschlüsselung bei minimaler betrieblicher Komplexität. Die Einschränkung: Die Speicherplattform hält sowohl die Daten als auch die Schlüssel – das erfüllt möglicherweise keine Compliance-Anforderungen, die eine Trennung von Schlüsselmanagement und Datenspeicherung vorschreiben. SSE-KMS (serverseitige Verschlüsselung mit einem externen Key Management System) führt eine externe Schlüssel-Governance ein. Die Verschlüsselungsschlüssel werden von einem separaten KMS verwaltet, das On-Premises oder in der Cloud betrieben werden kann. Das erzwingt eine kritische Sicherheitsgrenze: Das Speichersystem hält die verschlüsselten Daten, die Schlüssel zum Entschlüsseln liegen jedoch in einem separaten, unabhängig kontrollierten System. Diese Trennung entspricht direkt den Prinzipien einer Zero-Trust-Architektur und erfüllt die Compliance-Anforderung, dass Unternehmen die Kontrolle über ihre eigenen Verschlüsselungsschlüssel behalten. Sie ermöglicht außerdem Crypto-Shredding – die Möglichkeit, Daten dauerhaft unlesbar zu machen, indem statt der Daten selbst der Verschlüsselungsschlüssel gelöscht wird. Das ist wertvoll für die Pflichten aus dem Recht auf Löschung nach DSGVO. SSE-C (serverseitige Verschlüsselung mit kundenseitig bereitgestellten Schlüsseln) gibt dem Kunden die volle Kontrolle: Er stellt den Verschlüsselungsschlüssel mit jeder API-Anfrage bereit. Die Speicherplattform führt die Verschlüsselung durch, speichert den Schlüssel aber nie. Dieses Modell bietet maximale Kontrolle über die Schlüssel auf Kosten deutlich höherer betrieblicher Komplexität und ist in der Regel bestimmten Anwendungsfällen mit sehr hohen Sicherheitsanforderungen vorbehalten. Für die meisten regulierten Unternehmen stellt SSE-KMS mit einem externen Hardware-Sicherheitsmodul (HSM) die richtige Balance dar – starke Verschlüsselung, unabhängige Kontrolle über die Schlüssel und eine prüfbare Kette des Schlüsselmanagements, die Compliance-Teams gegenüber Aufsichtsbehörden nachweisen können. Warum sich die Compliance beim Schlüsselmanagement entscheidet Verschlüsselung an sich ist ein gut gelöstes Problem. AES-256 ist kryptografisch robust. Die Implementierung ist standardisiert. Der Performance-Aufwand ist beherrschbar. Was Unternehmen mit wirklich starker Verschlüsselungsstrategie von solchen mit einem bloßen Compliance-Häkchen unterscheidet, ist das Schlüsselmanagement. Verschlüsselungsschlüssel müssen mindestens so sorgfältig geschützt werden wie die Daten, die sie schützen. Werden Schlüssel zusammen mit den verschlüsselten Daten gespeichert, erhält ein Angreifer mit Zugriff auf die Speicherumgebung Zugriff auf alles. Werden Schlüssel nie rotiert, kann eine einzige historische Kompromittierung alle mit diesem Schlüssel verschlüsselten Daten offenlegen. Wird der Zugriff auf Schlüssel nicht protokolliert, lässt sich gegenüber Aufsichtsbehörden nicht nachweisen, dass die Verschlüsselungskontrollen wie vorgesehen funktioniert haben. Für Compliance-Verantwortliche sind beim Schlüsselmanagement diese Fragen am wichtigsten: Wer hält die Schlüssel? Kann das Unternehmen nachweisen, dass der Zugriff auf Schlüssel protokolliert und prüfbar ist? Werden die Schlüssel nach einem festgelegten Zeitplan rotiert? Gibt es ein Verfahren für den Widerruf von Schlüsseln und für Crypto-Shredding, wenn Daten gelöscht werden müssen? Kann das Unternehmen bei einem Audit die Trennung der Schlüssel von der Speicherinfrastruktur nachweisen? FIPS 140-2- und FIPS 140-3-Compliance – erforderlich für Workloads von US-Bundesbehörden und Verteidigungsprogramme – gilt speziell für die kryptografischen Module, die Verschlüsselung und Schlüsselmanagement ausführen, nicht für Speichersysteme als Ganzes. Diese Unterscheidung ist bei der Beschaffung wichtig: Eine Speicherplattform ist nicht pauschal FIPS-zertifiziert. Die konkreten kryptografischen Komponenten darin müssen validiert sein, und die bereitgestellte Konfiguration muss der validierten Umgebung entsprechen. Hier müssen technische Prüfer und Compliance-Teams sorgfältig zusammenarbeiten. Verschlüsselung und Unveränderlichkeit: zwei Kontrollen, die zusammenwirken müssen Ein verbreiteter Irrtum in der Compliance-Architektur ist, dass Verschlüsselung allein zum Schutz regulierter Daten ausreicht. Das tut sie nicht – und die Lücke wird bei Ransomware-Szenarien sichtbar. Ransomware-Angriffe zielen zunehmend gezielt auf Backup- und Speicherinfrastruktur, weil Angreifer wissen, dass es wertvoller ist, die Wiederherstellungsfähigkeit eines Unternehmens zu zerstören, als Daten zu stehlen. Erlangt ein Angreifer Administratorzugriff auf eine Speicherumgebung, kann er Daten löschen oder überschreiben, die nicht unveränderlich geschützt sind – selbst wenn sie verschlüsselt sind. Die Verschlüsselung verhindert, dass der Angreifer die Daten liest. Sie verhindert nicht, dass er sie zerstört. Deshalb müssen Unveränderlichkeit mit S3 Object Lock (auf Englisch) und Verschlüsselung gemeinsam als sich ergänzende Kontrollen eingesetzt werden. Auf Objektebene erzwungene Unveränderlichkeit stellt sicher, dass Daten für eine festgelegte Aufbewahrungsfrist weder gelöscht noch überschrieben werden können – unabhängig davon, welche Zugangsdaten ein Angreifer besitzt. Verschlüsselung stellt sicher, dass unbefugt abgerufene Daten unlesbar sind. Zusammen adressieren sie die beiden Hauptbedrohungen, gegen die Compliance-Rahmenwerke schützen sollen: unbefugten Zugriff und unbefugte Zerstörung. Konformer S3-Speicher für regulierte Branchen (auf Englisch) behandelt diese beiden Kontrollen als untrennbar. Compliance-Sperren auf Objektebene verhindern das Löschen. AES-256-Verschlüsselung verhindert unbefugtes Lesen. Die Kombination schafft faktisch einen logischen Air Gap – Daten, die von Unbefugten nicht gelesen und selbst von Personen mit Administratorrechten nicht zerstört werden können. Verschlüsselungspflichten in den wichtigsten Compliance-Rahmenwerken Für Compliance-Verantwortliche, die Pflichten aus mehreren Regelwerken steuern, ist es hilfreich zu verstehen, wie sich die Schwerpunkte der Verschlüsselungsanforderungen zwischen den Rahmenwerken unterscheiden. Die DSGVO verlangt geeignete technische Maßnahmen zum Schutz personenbezogener Daten und nennt Verschlüsselung ausdrücklich als Beispiel. Genauer gesagt verlangt sie, dass Unternehmen die Anwendung dieser Maßnahmen nachweisen können – Audit-Trails der Verschlüsselungskonfiguration, Zugriffslogs für Schlüssel und Belege für die Durchsetzung der Verschlüsselung sind also ebenso wichtig wie die Verschlüsselung selbst. DSGVO-Anforderungen an die Datenspeicherung gehen über Verschlüsselung hinaus und umfassen Aufbewahrung, Löschung und die Fähigkeit, Betroffenenrechte im großen Maßstab zu erfüllen. HIPAA verlangt von betroffenen Einrichtungen die Verschlüsselung geschützter Gesundheitsdaten im Ruhezustand und bei der Übertragung als „addressable“ Vorgabe – Unternehmen müssen sie also entweder umsetzen oder eine begründete Alternative dokumentieren. In der Praxis ist der Dokumentationsaufwand für den Verzicht auf Verschlüsselung weit höher als die einfache Umsetzung von AES-256, und die meisten Prüfer behandeln sie faktisch als verpflichtend. FIPS 140 regelt die konkreten kryptografischen Module, die in Umgebungen von US-Bundesbehörden und im Verteidigungsbereich für die Verschlüsselung eingesetzt werden. Der Standard gilt für die Implementierung der Verschlüsselung, nicht nur für ihr Vorhandensein – verwendete Algorithmen, Schlüssellängen und Betriebskonfiguration müssen also validierten Standards entsprechen. FIPS-Compliance ist besonders relevant für IT-Leiter im öffentlichen Sektor, die Speicher für Workloads von US-Bundesbehörden beschaffen. NIS2 und DORA verlangen beide, dass Unternehmen geeignete technische Maßnahmen zum Schutz von Daten und zur Aufrechterhaltung der operativen Resilienz umsetzen. Verschlüsselung ist in beiden Rahmenwerken eine Grunderwartung; NIS2 betont dabei besonders die Verschlüsselung von Daten bei der Übertragung über Netzwerkgrenzen hinweg – relevant für Hybrid-Cloud-Umgebungen, in denen Daten zwischen On-Premises- und Cloud-Infrastruktur fließen. Wie Compliance bei der Verschlüsselung in der Praxis aussieht Prüft ein Compliance-Verantwortlicher die Verschlüsselungsstrategie eines Unternehmens für ein Speicher-Audit, zählt nicht, ob Verschlüsselung theoretisch aktiviert ist – sondern ob sie standardmäßig erzwungen, konsistent angewendet, unabhängig prüfbar und gemeinsam mit Unveränderlichkeit und Zugriffskontrollen in eine schlüssige Sicherheitsarchitektur eingebunden ist. Das bedeutet: AES-256-Verschlüsselung für alle Objekte bei der Aufnahme, nicht selektiv. Es bedeutet Verschlüsselungsschlüssel, die extern und unabhängig von der Speicherplattform verwaltet werden. Es bedeutet TLS, erzwungen für alle übertragenen Daten. Es bedeutet Zugriffslogs für Schlüssel, die Prüfern vorgelegt werden können. Es bedeutet Zero-Trust-IAM-Kontrollen, die das Prinzip der minimalen Rechte für den Zugriff auf die Verschlüsselungskonfiguration durchsetzen. Und es bedeutet auf Objektebene erzwungene Unveränderlichkeit, damit verschlüsselte Daten selbst bei kompromittierten Administratorzugangsdaten nicht zerstört werden können. Speicherplattformen, die all dies standardmäßig erzwingen – statt es als Konfigurationsoption zu belassen –, senken das Compliance-Risiko drastisch, weil menschliche Konfigurationsfehler ausgeschlossen werden. Die Compliance-Lage sollte nicht davon abhängen, dass jemand daran denkt, die Verschlüsselung für einen neuen Bucket zu aktivieren. Weiterführende Artikel AES-Verschlüsselung für die Datensicherheit in Unternehmen Konformer S3-Speicher für regulierte Daten (auf Englisch) FIPS-Compliance-Leitfaden für sicheren Speicher DSGVO-Anforderungen an die Datenspeicherung für IT- und Speicherteams S3 Object Lock: Unveränderlichkeit und WORM (auf Englisch) Was ist unveränderlicher Speicher? Definition, Vorteile und Funktionsweise Best Practices für Zero-Trust-Sicherheit: Niemals vertrauen, immer überprüfen Was ist NIS2? Die EU-Cybersicherheitsrichtlinie erklärt Digital Operational Resilience Act (DORA) erklärt Was ist das NIST Cybersecurity Framework? Erfahren Sie, wie Scality AES-256-Verschlüsselung standardmäßig in On-Premises-Umgebungen und hybridem Cloud-Speicher durchsetzt – mit externem Schlüsselmanagement, Unveränderlichkeit durch S3 Object Lock und integrierten, auditfähigen Compliance-Kontrollen. Persönliche Demo anfordern →
