Datenschutz und Datenhaltung: Bedrohung, Verfahren und Schlüssel

Nach einem Datenabfluss über eine Einschleusung von SQL wird die Verschlüsselung im Ruhezustand eingeschaltet. Sie funktioniert einwandfrei und hätte den Vorfall nicht verhindert — denn sie ist gegen gestohlene Datenträger gebaut, nicht gegen eine gültige Verbindung. Dieses Modul ordnet jedes gängige Verfahren der Bedrohung zu, gegen die es laut Dokumentation wirkt, und behandelt das Problem, das jede Verschlüsselung erzeugt: den Schlüssel, ohne den die Sicherung nur noch eine Datei ist.

Lehrtext · 10 Abschnitte · zuletzt geprüft: 2026-09-12

Erst die Bedrohung, dann die Maßnahme

„Die Datenbank ist verschlüsselt“ ist keine Aussage über Sicherheit, solange nicht dabeisteht, wogegen. Jedes der üblichen Verfahren deckt einen genau umrissenen Fall ab und einen anderen ausdrücklich nicht — und die Dokumentation beider Systeme sagt das selbst, in ungewöhnlicher Deutlichkeit.

Die PostgreSQL-Dokumentation ist an dieser Stelle sogar nach Bedrohungen gegliedert statt nach Techniken. Dieses Modul folgt derselben Ordnung, weil sie die einzige ist, in der sich eine Maßnahme begründen lässt.

Gestohlene Platte oder Sicherungsband: Jemand nimmt den Datenträger mit und liest ihn woanders.
Mitlesen auf der Leitung: Jemand sieht den Netzverkehr zwischen Anwendung und Datenbank.
Gültige Verbindung, missbraucht: Ein kompromittiertes Anwendungskonto oder eine Einschleusung von SQL stellt echte Abfragen.
Der Serveradministrator selbst: Jemand mit vollem Zugriff auf den Datenbankserver.

Warum diese Reihenfolge so wichtig istFast jede fehlgeleitete Sicherheitsmaßnahme im Datenbankbetrieb entsteht daraus, dass ein Verfahren gegen die falsche Zeile dieser Tabelle eingesetzt wird — typischerweise Verschlüsselung im Ruhezustand gegen eine Bedrohung, die eine gültige Verbindung benutzt. Das Verfahren funktioniert dann einwandfrei und nützt nichts.

Verschlüsselung im Ruhezustand — und ihre ausdrückliche Grenze

Bei SQL Server heißt das Verfahren Transparente Datenverschlüsselung. Die Dokumentation benennt die Bedrohung, gegen die es gebaut ist, wörtlich: Eine böswillige Partei, die physische Medien wie Laufwerke oder Sicherungsbänder stiehlt, kann die Datenbank sonst wiederherstellen oder anhängen und ihre Daten durchsehen.

Es verschlüsselt Daten- und Protokolldateien in Echtzeit beim Lesen und Schreiben. Anwendungen merken davon nichts — daher der Name. Und genau daraus folgt die Grenze: Wer eine gültige Verbindung hat, bekommt entschlüsselte Daten, weil das der Zweck des Verfahrens ist.

Zwei Sätze aus der Dokumentation, die den Umfang festlegenErstens: Die Verschlüsselung schützt Daten im Ruhezustand, also Daten- und Protokolldateien. Zweitens: Sie bietet keine Verschlüsselung über Kommunikationskanäle hinweg. Wer sie einschaltet und glaubt, damit sei auch die Verbindung geschützt, hat eine Lücke, die die Referenz in einem Satz ausschließt.

Auf der PostgreSQL-Seite gibt es kein gleichnamiges Bordmittel; die Dokumentation verweist stattdessen auf Verschlüsselung durch das Dateisystem oder die Blockebene — unter Linux etwa dm-crypt mit LUKS. Die Bewertung fällt identisch aus, und sie ist genauso unmissverständlich formuliert.

Wörtlich zur Platten-VerschlüsselungDieser Mechanismus verhindert, dass unverschlüsselte Daten von den Laufwerken gelesen werden, wenn die Laufwerke oder der ganze Rechner gestohlen werden. Er schützt nicht gegen Angriffe, während das Dateisystem eingehängt ist, denn im eingehängten Zustand liefert das Betriebssystem eine unverschlüsselte Sicht auf die Daten. Und: Um das Dateisystem einzuhängen, muss der Schlüssel irgendwie zum Betriebssystem gelangen — manchmal liegt er dazu irgendwo auf dem Host, der die Platte einhängt.

Verschlüsselung auf der Leitung

Die zweite Zeile der Bedrohungstabelle braucht ein anderes Verfahren. Die Dokumentation beschreibt den Umfang genau: SSL-Verbindungen verschlüsseln alle über das Netz gesendeten Daten — das Passwort, die Abfragen und die zurückgegebenen Daten.

Durchgesetzt wird das an derselben Stelle, an der auch die Anmeldung entschieden wird. In pg_hba.conf steht host für Verbindungen, die auch unverschlüsselt zustande kommen dürfen, und hostssl für solche, die eine SSL-verschlüsselte Verbindung verlangen. Analog verlangt hostgssenc eine GSSAPI-verschlüsselte Verbindung, bei der überdies gar kein Passwort über das Netz geht.

Warum die Erlaubnis nicht reichtEin Eintrag mit host erlaubt SSL, er verlangt es nicht. Ein Client, der ohne anfragt, kommt durch — und niemand bemerkt es, weil nichts fehlschlägt. Wer Verschlüsselung auf der Leitung zusagt, muss hostssl schreiben; alles andere ist eine Erlaubnis, keine Anforderung. Clients können dieselbe Anforderung zusätzlich von ihrer Seite stellen, aber darauf kann sich ein Server nicht verlassen.

Die Dokumentation nennt noch eine Stufe darüber: Client und Server können einander Zertifikate vorlegen. Das erfordert auf beiden Seiten zusätzliche Einrichtung, liefert aber eine stärkere Identitätsprüfung als bloße Passwörter — es verhindert, dass sich ein Rechner gerade lange genug als Server ausgibt, um das vom Client gesendete Passwort mitzulesen, und hilft gegen Angriffe, bei denen ein Rechner zwischen Client und Server sich als Server ausgibt und alles mitliest und weiterreicht.

Spaltenverschlüsselung — und wer sie trotzdem lesen kann

Manchmal ist nur ein Teil der Daten schutzbedürftig. Dafür gibt es die Verschlüsselung einzelner Felder; bei PostgreSQL über das Modul pgcrypto. Die Dokumentation beschreibt den Ablauf — und im nächsten Absatz die Lücke, die daraus folgt.

Der Ablauf und seine Folge, aus der DokumentationDer Client liefert den Entschlüsselungsschlüssel, die Daten werden auf dem Server entschlüsselt und dann an den Client gesendet. Die entschlüsselten Daten und der Schlüssel sind dabei für einen kurzen Moment auf dem Server vorhanden. Das ist ein kurzer Moment, in dem Daten und Schlüssel von jemandem abgefangen werden können, der vollen Zugriff auf den Datenbankserver hat — etwa dem Systemadministrator.

Damit ist die vierte Zeile der Bedrohungstabelle nicht abgedeckt. Spaltenverschlüsselung hilft gegen jemanden, der die Dateien liest, und gegen einen Anwendungszugriff ohne Schlüssel — sie hilft nicht gegen den, der die Maschine kontrolliert.

Für genau diesen Fall nennt die Dokumentation ein eigenes Verfahren: Kann dem Systemadministrator der Servermaschine nicht vertraut werden, muss der Client die Daten verschlüsseln; dann erscheinen unverschlüsselte Daten nie auf dem Datenbankserver. Verschlüsselt wird vor dem Senden, entschlüsselt nach dem Empfangen.

Der Preis dieser einzigen vollständigen LösungWas der Server nie im Klartext sieht, kann er auch nicht durchsuchen, sortieren, indizieren oder in einer Bedingung verwenden. Clientseitige Verschlüsselung nimmt der Datenbank genau die Fähigkeiten, wegen derer man eine Datenbank benutzt. Sie ist deshalb kein Standardverfahren, sondern eine Entscheidung für einzelne, klar abgegrenzte Felder.

Kurzcheck

Eine Anwendung wird über eine Einschleusung von SQL angegriffen und liest Kundendaten aus. Die Datenbank verwendet Verschlüsselung im Ruhezustand. Was hat sie verhindert?

Nichts an diesem Angriff — er läuft über eine gültige Verbindung
Sie hat den Zugriff auf die Spalten mit personenbezogenen Daten blockiert
Sie hat die Übertragung der Daten an den Angreifer verhindert

Treffer. Richtig. Die Verschlüsselung im Ruhezustand entschlüsselt für jeden Zugriff über die Engine; das ist ihr Zweck. Gegen eine missbrauchte, aber gültige Verbindung richtet sie nichts aus.

Jetzt ist der Schlüssel das Problem

Jede Verschlüsselung verschiebt die Frage: Statt der Daten muss nun der Schlüssel gehütet werden. Und weil ein Schlüssel klein und leicht zu vergessen ist, entsteht hier die häufigste selbstverschuldete Katastrophe.

Die Anweisung der Dokumentation, Wört für Wort ernst zu nehmenNach dem Einschalten der Verschlüsselung sofort das Zertifikat und den zugehörigen privaten Schlüssel sichern. Ist das Zertifikat nicht verfügbar, oder wird die Datenbank auf einem anderen Server wiederhergestellt oder angehängt, braucht man diese Sicherungen — andernfalls lässt sich die Datenbank nicht öffnen.

Das verbindet dieses Modul unmittelbar mit dem über Backup und Recovery: Eine verschlüsselte Sicherung ohne gesichertes Zertifikat ist keine Sicherung, sondern eine Datei. Sie lässt sich kopieren, prüfen und jahrelang aufbewahren — und am Tag der Wiederherstellung auf einer neuen Maschine ist sie wertlos. Der Wiederherstellungstest auf einer getrennten Instanz ist der einzige Ablauf, der diesen Fehler findet, weil nur er das Zertifikat tatsächlich braucht.

Zwei Feinheiten mit langer NachwirkungDie Dokumentation rät, das verschlüsselnde Zertifikat auch dann aufzubewahren, wenn die Verschlüsselung wieder abgeschaltet wurde — Teile des Transaktionsprotokolls können weiterhin geschützt sein, und für manche Vorgänge braucht man es bis zur nächsten Vollsicherung. Und: Ein Zertifikat, dessen Ablaufdatum überschritten ist, lässt sich weiterhin zum Ver- und Entschlüsseln verwenden — eine abgelaufene Gültigkeit ist hier also kein Grund zur Panik, aber auch kein Freibrief für fehlende Sicherungen.

Eine dritte Eigenheit betrifft den Umfang: Die Verschlüsselung steht für Systemdatenbanken nicht zur Verfügung — master, model und msdb lassen sich nicht verschlüsseln. tempdb dagegen wird automatisch mitverschlüsselt, sobald eine Nutzdatenbank es ist, lässt sich aber nicht direkt verschlüsseln. Wer also glaubt, mit dem Einschalten sei die ganze Instanz erfasst, irrt in beide Richtungen.

Wo der Schlüssel liegt, entscheidet mit

Eine Verschlüsselung ist so stark wie die Verwahrung ihres Schlüssels — und beide Systeme bauen dafür eine Kette, deren Glieder man kennen muss, bevor man sie sichert.

Bei SQL Server verschlüsselt ein symmetrischer Datenbank-Verschlüsselungsschlüssel die Daten. Dieser wird laut Dokumentation seinerseits geschützt — entweder durch ein Zertifikat, das die master-Datenbank des Servers speichert, oder durch einen asymmetrischen Schlüssel, den ein externes Schlüsselverwaltungsmodul hütet. Der Startsatz der Datenbank hält den Schlüssel dabei für die Wiederherstellungsphase verfügbar. Verschlüsselt wird mit AES oder 3DES, ohne dass vorhandene Anwendungen geändert werden müssten.

Zertifikat in master: Bequem, weil alles auf der Instanz liegt. Genau deshalb ist es beim Verlust der Instanz mit weg — und die Sicherung der Nutzdatenbank allein nützt nichts.
Externes Schlüsselverwaltungsmodul: Der Schlüssel lebt außerhalb der Datenbank. Trennt Schlüssel und Daten sauber, bringt aber ein zweites System mit eigener Verfügbarkeit ins Spiel: Fällt es aus, lässt sich die Datenbank nicht öffnen.

Dieselbe Frage auf der PostgreSQL-SeiteBei Verschlüsselung durch Dateisystem oder Blockebene stellt sich das Problem in anderer Form. Die Dokumentation benennt es unumwunden: Um das Dateisystem einzuhängen, muss der Schlüssel irgendwie zum Betriebssystem gelangen — und manchmal liegt er dazu irgendwo auf dem Host, der die Platte einhängt. Ein Schlüssel, der auf derselben Maschine liegt wie die verschlüsselte Platte, schützt gegen den Diebstahl der Platte, aber nicht gegen den Diebstahl des Rechners.

Daraus folgt die Prüffrage, die jede Verschlüsselungsentscheidung begleiten sollte: Was muss ein Angreifer zusätzlich mitnehmen, um die Daten lesen zu können? Liegt die Antwort „nichts, der Schlüssel ist auf demselben Gerät“, dann deckt das Verfahren nur den Fall ab, dass ein einzelnes Laufwerk das Haus verlässt — nicht den, dass ein ganzer Server verschwindet.

Und die Kehrseite derselben FrageJe weiter Schlüssel und Daten getrennt liegen, desto stärker der Schutz — und desto mehr Fälle gibt es, in denen die eigene Wiederherstellung scheitert, weil ein zweites System nicht verfügbar ist. Das ist keine Schwäche der Trennung, sondern ihr Preis: Sie muss in dieselben Verfügbarkeitsüberlegungen aufgenommen werden wie die Datenbank selbst.

Passwörter sind ein eigener Fall

Ein Sonderfall, der oft mit der Datenverschlüsselung in einen Topf geworfen wird, aber anderen Regeln folgt. Datenbankpasswörter werden laut Dokumentation als Hashes gespeichert; der Administrator kann das tatsächliche Passwort eines Benutzers nicht ermitteln.

Wichtiger ist, was beim Anmelden passiert. Wird scram-sha-256 für die Client-Authentifizierung verwendet, ist das unverschlüsselte Passwort nie, auch nicht vorübergehend, auf dem Server vorhanden — der Client verarbeitet es, bevor es über das Netz geht. Die Dokumentation bevorzugt dieses Verfahren ausdrücklich, weil es ein Internet-Standard und sicherer ist als das PostgreSQL-eigene MD5-Verfahren.

Ein Hinweis mit VerfallsdatumDie Dokumentation führt eine ausdrückliche Warnung: Die Unterstützung für MD5-verschlüsselte Passwörter ist veraltet und wird in einer künftigen Version entfernt. Das ist eine der wenigen Stellen in diesem Track, an der eine Maßnahme nicht nur besser, sondern terminiert ist — ein Bestand mit MD5-Passwörtern hat ein Ablaufdatum, das mit dem nächsten größeren Versionswechsel zusammenfällt.

Produktivdaten außerhalb der Produktion

Die häufigste Stelle, an der personenbezogene Daten aus der Kontrolle geraten, ist keine Angriffsfläche, sondern eine Bequemlichkeit: die Kopie der Produktivdatenbank auf einem Test- oder Entwicklungssystem.

Die Kopie ist verständlich gewollt, weil nur echte Daten echte Fehler zeigen. Sie bringt aber alles mit, was am Original hing — und nichts, was das Original geschützt hat: Das Testsystem hat andere Rechte, andere Netzzonen, andere Sicherungen, oft keine Verschlüsselung und deutlich mehr Personen mit Zugang.

Vollkopie: Maximaler Realismus, maximales Risiko. Nur vertretbar, wenn das Zielsystem dieselben Schutzmaßnahmen trägt wie die Produktion — was den Sinn eines billigeren Testsystems meist aufhebt.
Anonymisierung: Personenbezug wird unumkehrbar entfernt. Sicherste Variante; verändert aber Verteilungen und kann Fehlerbilder verdecken, die an echten Werten hängen.
Pseudonymisierung: Kennungen werden ersetzt, die Zuordnung bleibt über eine getrennt verwahrte Tabelle möglich. Erhält Verknüpfungen — aber die Zuordnungstabelle ist dann selbst schutzbedürftig.
Erzeugte Testdaten: Kein Personenbezug, voller Freiheitsgrad. Bildet die Eigenheiten echter Bestände oft nicht ab — genau die, die Fehler auslösen.

Der Punkt, an dem die Umwandlung stattfinden mussSie gehört vor die Ablage auf dem Zielsystem, nicht danach. Eine Vollkopie, die erst auf dem Testsystem verändert wird, war für die Dauer des Vorgangs vollständig dort — und ist es in dessen Sicherungen weiterhin. Praktisch heißt das: umwandeln auf einem System mit Produktionsschutz, und erst das Ergebnis weitergeben.

Löschen und Sicherungen widersprechen einander

Der letzte und unbequemste Punkt. Eine Löschpflicht verlangt, dass ein Datensatz verschwindet. Ein Sicherungskonzept verlangt, dass sich jeder vergangene Zustand wiederherstellen lässt. Beides zusammen ist ein Widerspruch, und er löst sich nicht technisch auf.

Aus dem Modul über Backup und Recovery folgt unmittelbar: Wird eine Zeile heute gelöscht, ist sie in jeder Vollsicherung davor weiterhin enthalten, und die Protokollkette erlaubt die Rückkehr auf jeden Zeitpunkt, an dem es sie noch gab. Die Zeile ist aus der laufenden Datenbank verschwunden und aus dem Sicherungsbestand nicht.

Die Aufbewahrungsdauer der Sicherungen ist die tatsächliche Frist, nach der ein gelöschter Datensatz endgültig weg ist — nicht der Zeitpunkt des Löschens.
Sicherungen einzeln zu bereinigen ist keine Option. Eine veränderte Sicherung ist keine Sicherung mehr; sie wäre nicht mehr das, was sie zu sein vorgibt, und ihre Wiederherstellbarkeit wäre unbelegt.
Der gangbare Weg ist die Frist. Aufbewahrungsdauer und Löschzusage werden aufeinander abgestimmt und gemeinsam dokumentiert — als bewusste Entscheidung, nicht als Übersehen.
Das ist eine Entscheidung mit Rechtsbezug, keine technische. Sie gehört zu denen, die eine Fachseite trifft; der Betrieb liefert die Zahlen und die Machbarkeit.

Kennzeichnung einer UnsicherheitWelche Aufbewahrungsdauer im Einzelfall zulässig ist und wie eine Löschzusage gegenüber Sicherungsbeständen rechtlich zu formulieren ist, hängt von Rechtsrahmen, Branche und Vertragslage ab. Dieses Modul benennt den technischen Sachverhalt und die Entscheidungspunkte — es ersetzt keine rechtliche Bewertung, und es wäre unredlich, hier eine Zahl zu nennen.

Die Reihenfolge, die das zusammenhält

Bedrohung benennen, bevor ein Verfahren gewählt wird→Maßnahme zuordnen — und ihre dokumentierte Grenze mitlesen→Schlüsselverwahrung klären, bevor verschlüsselt wird→Kopien außerhalb der Produktion vor der Weitergabe umwandeln→Löschzusage gegen Aufbewahrungsdauer abgleichen

Bedrohung vor Verfahren

Schritt drei ist der, dessen Versäumnis am teuersten wird. Eine fehlende Verschlüsselung ist ein Risiko; ein fehlender Schlüssel ist ein Totalverlust, und er fällt erst am Wiederherstellungstag auf. Deshalb gehört die Sicherung des Schlüssels in dieselbe Arbeitsanweisung wie das Einschalten der Verschlüsselung — nicht in eine spätere.

AbgrenzungWer welche Rechte auf welchen Objekten hat und wie Rollen zugeschnitten werden, steht im Modul über Zugriff und Identitäten. Wie eine Sicherung konfiguriert und nachgewiesen wird, steht im Modul über Backup und Recovery. Datenklassifikation, Schutzbedarfsfeststellung und Freigabeprozesse als Verfahren stehen im Track itsm-operations. Hier ging es darum, welche technische Maßnahme welche Bedrohung tatsächlich abdeckt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12