Datenmaskierung: Leitfaden zum Schutz sensibler Daten

Datenmaskierung ist der Vorgang, sensible Datenwerte durch erfundene, aber strukturell realistische Ersatzwerte zu ersetzen. Die Originalwerte werden dadurch für Unbefugte unzugänglich, während Format und statistische Eigenschaften der Daten für Entwicklung, Test und Analyse erhalten bleiben. Sie heißt auch Verschleierung oder Anonymisierung und erlaubt Organisationen, sensible Daten gefahrlos zu teilen und zu nutzen, ohne echte Werte gegenüber Stellen offenzulegen, die sie nicht berechtigt sehen müssen.

Was Datenmaskierung ist

Das Kernproblem, das die Datenmaskierung löst, ist eine grundlegende Spannung im Datenmanagement: Sensible Daten sind oft die wertvollsten Daten für Analysen, Anwendungstests und Business Intelligence, und zugleich diejenigen, die bei falschem Umgang am ehesten Schaden anrichten. Eine Produktivdatenbank mit echten Kundennamen, E-Mail-Adressen, Zahlungskartennummern und Gesundheitsakten ist unverzichtbar, um Anwendungen zu bauen und zu pflegen. Sie in eine Entwicklungsumgebung zu kopieren legt aber all diese sensiblen Angaben gegenüber Entwicklung und Dienstleistern offen, die echte Kundendaten nie sehen sollten.

Die Datenmaskierung löst diese Spannung, indem sie eine Fassung der Daten liefert, die realistisch genug ist, um nützlich zu sein, und sicher genug, um breit geteilt zu werden. Die maskierten Werte bestehen Formatprüfungen, Anwendungslogik und Prüfregeln, sodass sich Testumgebungen genauso verhalten wie die Produktion, ohne das Risiko für den Datenschutz.

Die Maskierung unterscheidet sich in einem entscheidenden Punkt von der Verschlüsselung: Verschlüsselte Daten lassen sich mit dem richtigen Schlüssel wieder entschlüsseln, maskierte Daten stehen dagegen in keinem mathematischen Verhältnis zum Original. Es gibt keinen Schlüssel zu stehlen, denn die Umformung ist einseitig (bei der statischen Maskierung) oder regelgeleitet, auf Feldebene aber nicht umkehrbar (bei der dynamischen Maskierung).

Die Datenmaskierung hängt eng an der Klassifizierung: Wie zu maskieren ist, lässt sich erst entscheiden, wenn bekannt ist, welche Art sensibler Daten jede Spalte enthält. Sie liegt außerdem im weiteren Rahmen der Data Governance, neben Zugriffskontrolle, Aufbewahrungsregeln und Programmen für den Datenschutz.

Statische und dynamische Maskierung

Die Ansätze der Datenmaskierung fallen in zwei große Kategorien, die sich grundlegend darin unterscheiden, wann und wie maskiert wird.

Statische Datenmaskierung (SDM)

Die statische Datenmaskierung erzeugt eine dauerhaft maskierte Kopie eines Datenbestands. Die Umformung wird einmal angewandt und ergibt einen neuen Bestand, in dem sensible Werte durch maskierte Entsprechungen ersetzt sind. Die maskierte Kopie tritt dann für alle Zwecke außerhalb der Produktion an die Stelle des Originals. Die sensiblen Originaldaten bleiben im Produktivsystem unangetastet, und die maskierte Kopie enthält überhaupt keine sensiblen Werte: Es gibt weder Schlüssel noch Zuordnung, die die Originale offenlegen könnten.

Die statische Maskierung passt am besten dort, wo ein vollständiger, in sich geschlossener Datenbestand gebraucht wird: eine Testdatenbank mit realistischen, aber nicht sensiblen Daten zu füllen, einem externen Analysepartner einen maskierten Auszug zu geben oder Trainingsdaten für maschinelles Lernen zu erzeugen, die sich auf Produktivdaten rechtlich nicht aufbauen lassen. Weil die Maskierung dauerhaft auf die Kopie angewandt wird, gibt es kein Umgehungsrisiko: Die sensiblen Werte existieren in dem maskierten Bestand schlicht nicht.

Die Hauptgrenze ist der Aufwand im Betrieb. Jedes Mal, wenn der Produktivbestand aufgefrischt wird, was in vielen Organisationen täglich oder wöchentlich geschieht, muss ein neuer Maskierungslauf die maskierte Kopie aktualisieren. Bei großen Beständen kostet das erheblich Rechenzeit. Die statische Maskierung kann außerdem nicht verschiedenen Nutzern verschiedene Sichten auf dieselben Daten geben: Die Kopie ist für alle gleich maskiert.

Dynamische Datenmaskierung (DDM)

Die dynamische Datenmaskierung wendet die Umformung in Echtzeit zum Zeitpunkt der Abfrage an, ohne die gespeicherten Daten zu verändern. Fragt ein Nutzer eine Tabelle mit sensiblen Spalten ab, fängt die Datenbank oder die Abfrage-Engine die Anfrage ab und ersetzt sensible Werte im Ergebnis anhand der Rolle des Nutzers und der Maskierregeln, die an diesen Spalten hängen. Die Produktivdaten bleiben unangetastet und für Befugte voll zugänglich, während Unbefugte unbemerkt maskierte Werte erhalten.

Die dynamische Maskierung ist in Snowflake (Dynamic Data Masking), in Databricks Unity Catalog (Maskierung auf Spaltenebene), in Microsoft SQL Server (Dynamic Data Masking), in Azure Synapse und in BigQuery (Sicherheit auf Spaltenebene) als Bordmittel umgesetzt. Diese Plattformen lassen Governance-Teams Maskierregeln in SQL festlegen und an Spalten hängen, sodass die richtigen Nutzer echte Werte sehen und alle anderen maskierte, ohne jede Änderung an Abfragen oder Anwendungscode.

Der wesentliche Vorteil der dynamischen Maskierung ist, dass sie auf den Produktivdaten arbeitet und weder getrennte maskierte Kopien noch Auffrischungspipelines braucht. Ihre Grenze: Sie zieht die Grenze für den Datenschutz nur auf der Abfrageschicht. Ein Nutzer mit unmittelbarem Zugriff auf den Speicher kann die Maskierung auf der Abfrageschicht möglicherweise umgehen.

Die Techniken der Maskierung

Ersetzung

Die Ersetzung tauscht echte Werte gegen zufällig gewählte aus einer Nachschlagetabelle plausibler Alternativen. Echte Namen weichen zufällig gewählten Namen aus einem Namensverzeichnis, echte Städte anderen echten Städtenamen, echte E-Mail-Adressen syntaktisch gültigen, aber nicht existierenden Adressen. Die Ersetzung erzeugt realistisch aussehende Daten, welche die Formatprüfungen und die Prüfungen der Anwendungslogik bestehen.

Formaterhaltende Ersetzung ist bei Datentypen mit strukturellen Vorgaben entscheidend. Eine maskierte Kreditkartennummer sollte weiterhin die Luhn-Prüfung bestehen. Eine maskierte US-Sozialversicherungsnummer sollte weiterhin dem Muster ###-##-#### entsprechen. Eine maskierte IBAN sollte dem richtigen länderspezifischen Format folgen. Formaterhaltende Maskierung verhindert, dass Prüfungen in Testumgebungen fehlschlagen, die in der Produktion nie fehlschlagen würden.

Tokenisierung

Die Tokenisierung ersetzt sensible Werte durch nicht sensible Token, in der Regel Zufallszeichenfolgen oder Ganzzahlen, die sich über einen gesicherten Token-Tresor auf die Originalwerte zurückführen lassen. Anders als die Verschlüsselung nutzt die Tokenisierung keine mathematische Umformung: Das Token steht in keinem kryptografischen Verhältnis zum Originalwert, also gibt es keinen Schlüssel zu stehlen. Sie wird breit für Zahlungskartendaten (PAN-Tokenisierung) und für dauerhafte Kundenkennungen in Analyseumgebungen genutzt, wo ein stabiles Token erlaubt, Datensätze über mehrere Bestände hinweg zu verknüpfen, ohne die tatsächliche E-Mail-Adresse oder Kontonummer offenzulegen.

Mischen

Das Mischen verteilt echte Werte innerhalb desselben Bestands auf andere Datensätze um. Statt den Namen eines Kunden durch einen erfundenen zu ersetzen, weist das Mischen ihm den Namen eines anderen echten Kunden aus derselben Tabelle zu. Die einzelnen Werte bleiben echt, aber ihre Verbindung zu den übrigen Attributen ist gekappt, und damit die Verbindung zwischen der maskierten Spalte und einer identifizierbaren Person. Das Mischen erhält die Verteilung der Werte exakt und ist deshalb für Analysen nützlich, bei denen Häufigkeitsverteilungen zählen.

Verschlüsselung und Teilmaskierung

Die Verschlüsselung formt sensible Werte mit einem kryptografischen Verfahren um und erzeugt einen Geheimtext, den nur Stellen mit dem richtigen Schlüssel wieder entschlüsseln können. Formaterhaltende Verschlüsselung (FPE, etwa FF3-1) erzeugt Geheimtext im Format des Klartexts: Eine 16-stellige Kreditkartennummer wird zu einer anderen 16-stelligen Zahl. Das ist dort wertvoll, wo verschlüsselte Werte Formatprüfungen bestehen müssen.

Die Teilmaskierung (Schwärzung) zeigt nur einen Teil des Originalwerts. Die letzten vier Ziffern einer Kreditkartennummer oder der Domänenteil einer E-Mail-Adresse sind gängige Beispiele. Teilmaskierung wird breit in kundenseitigen Oberflächen und in Werkzeugen für den Support genutzt, wo Mitarbeitende eine Identität bestätigen müssen, ohne vollständige Kontonummern zu sehen.

Verrauschen der Daten

Das Verrauschen fügt numerischen Werten zufälliges Rauschen hinzu und verändert sie leicht, während die statistischen Eigenschaften erhalten bleiben. Ein Gehalt von 65.000 £ wird vielleicht zu 63.847 £ oder 66.412 £. Für einen einzelnen Datensatz ist der verrauschte Wert für eine Re-Identifizierung wertlos; für die Auswertung im Aggregat bleiben Mittelwerte, Standardabweichungen und Korrelationen innerhalb vertretbarer Grenzen.

Anwendungsfälle

Entwicklungs- und Testumgebungen

Die häufigste Anwendung der statischen Datenmaskierung ist, Entwicklungs- und Testumgebungen mit realistischen Daten zu füllen. Wer Funktionen baut, die Kundenbestellungen verarbeiten, braucht Testdaten, die echten Bestellungen in Aufbau und Inhalt ähneln, aber niemand in der Entwicklung sollte Zugriff auf echte Kundennamen, Adressen oder Zahlungsdaten haben. Viele aufsehenerregende Datenpannen sind über Entwicklungs- und Testumgebungen entstanden, die ungeschützte Kopien von Produktivdaten enthielten. Die Datenmaskierung nimmt diese Angriffsfläche weg, indem Umgebungen außerhalb der Produktion nie echte sensible Werte enthalten.

Analysen auf sensiblen Daten

Die dynamische Maskierung ermöglicht Analysen auf sensiblen Daten, indem sie eine Zugriffskontrolle auf Spaltenebene liefert, die zu den Rollen der Nutzer passt. Wer das Kaufverhalten von Kunden untersucht, braucht vielleicht Beträge und Produktkategorien, aber keine Namen oder E-Mail-Adressen. Maskierregeln in Snowflake oder Databricks erlauben es, die Transaktionstabelle abzufragen und maskierte Namen und Adressen zu erhalten, während die Transaktionsdaten echt bleiben, ohne besondere Abfragesyntax und ohne Filter in der Anwendung.

DSGVO und Compliance im Datenschutz

Die Datenmaskierung ist eine zentrale technische Maßnahme für die Compliance im Datenschutz. Die DSGVO erkennt die Pseudonymisierung ausdrücklich an, also das Ersetzen identifizierender Angaben durch Pseudonyme mit getrennt gespeicherter Zuordnung, als Maßnahme, die das Risiko für den Datenschutz senkt und eine rechtmäßige Verarbeitung unter weniger strengen Bedingungen ermöglichen kann. Die Maskierung stützt auch den Grundsatz der Datenminimierung der DSGVO, indem personenbezogene Daten nicht unnötig gegenüber Stellen oder Systemen offengelegt werden, die sie für ihren erklärten Zweck nicht brauchen.

Data Sharing mit Dritten

Organisationen teilen Daten häufig mit Dritten, mit Analysepartnern, Cloud-Anbietern, ausgelagerten Entwicklungsteams und Forschenden, die berechtigt mit den Daten arbeiten, aber keine sensiblen Werte sehen sollen. Die statische Maskierung erzeugt einen bereinigten Bestand, der die strukturellen und statistischen Eigenschaften behält, die der Dritte für seinen Zweck braucht, und den sensiblen Inhalt entfernt.

Bezug zur Klassifizierung

Datenmaskierung lässt sich ohne Klassifizierung nicht wirksam umsetzen. Bevor maskiert werden kann, muss das Governance-Team wissen, welche Spalten sensible Daten enthalten, welche Art von Schutzbedarf sie tragen und welche Technik der Maskierung für welche Art angemessen ist. Eine Spalte mit einer Kreditkartennummer verlangt formaterhaltende Maskierung. Eine Spalte mit einer ärztlichen Notiz im Freitext verlangt eine andere Behandlung als eine Spalte mit einem strukturierten Geburtsdatum. Genau diese Auskunft liefern die Metadaten der Klassifizierung.

Der Bezug geht in beide Richtungen: Die Klassifizierung treibt den Entwurf der Maskierregeln, und die Anwendung einer Maskierregel erzeugt Metadaten, die in den Eintrag der Klassifizierung zurückfließen sollten. Wird eine Maskierregel auf eine Spalte angewandt, sollte das im Datenkatalog als Nachweis der getroffenen Schutzmaßnahme festgehalten werden. Das ist wertvoll für Nachweise der Compliance gegenüber der Aufsicht, die nicht nur nach Kennzeichen der Klassifizierung fragt, sondern nach der konkret angewandten Maskierregel und dem Zeitpunkt ihrer Aktivierung.

Werkzeuge und Plattformen

Mehrere Kategorien von Werkzeugen tragen die Datenmaskierung im großen Maßstab. Maskierung als Bordmittel der Cloud gibt es in Snowflake (Dynamic Data Masking), in Databricks Unity Catalog (Maskierregeln auf Spaltenebene), in Microsoft SQL Server und Azure Synapse (Dynamic Data Masking) und in BigQuery (Sicherheit auf Spaltenebene). Diese Plattformen lassen Governance-Teams Maskierregeln in SQL festlegen und unmittelbar an Spalten hängen.

Eigenständige Werkzeuge zur Maskierung wie Informatica Data Masking, IBM InfoSphere Optim und Delphix liefern Pipelines für statische Maskierung in Unternehmensqualität für große, heterogene Datenlandschaften. Sie beherrschen die referenzielle Integrität, also dass derselbe Kunde in jeder Tabelle, die auf ihn verweist, dieselbe maskierte Kennung erhält, was zu den technisch schwierigsten Punkten statischer Maskierung im großen Maßstab gehört.

Die referenzielle Integrität über verwandte Tabellen hinweg zu wahren verlangt deterministische Maskierung: Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. Ohne das enthält ein maskierter Bestand gebrochene Beziehungen und taugt nicht mehr dazu, relationale Anwendungslogik zu testen. Die Leistung ist die zweite Überlegung bei der dynamischen Maskierung: Umformungen auf jede Zeile eines Abfrageergebnisses anzuwenden kostet Zeit, die bei Lasten mit hohem Durchsatz zu bewerten ist.

Governance und Dawiso

Wirksame Governance der Datenmaskierung braucht einen zentralen Nachweis darüber, welche Maskierregeln es gibt, an welchen Spalten sie hängen, wann sie zuletzt geprüft wurden und wer für ihre Pflege verantwortlich ist. Ohne diesen Nachweis wird die Maskierung zu einer zersplitterten Sammlung einzeln gepflegter Regeln, die sich im großen Maßstab weder prüfen noch pflegen lässt.

Dawiso verbindet die Kennzeichen der Klassifizierung mit der Dokumentation der Maskierregeln in seiner Plattform für Metadatenmanagement. Wenn Data Stewards sensible Spalten finden und klassifizieren, können sie die Anforderungen an die Maskierung unmittelbar im Dawiso-Katalog mit diesen Klassifizierungen verknüpfen. Werden die Maskierregeln dann in Snowflake, Databricks oder anderen Plattformen umgesetzt, werden ihre Einzelheiten, also Technik, betroffene Rollen, Prüfdatum und Verantwortung, in Dawiso neben den technischen und fachlichen Metadaten der Spalte festgehalten.

Die Lineage in Dawiso sorgt dafür, dass Anforderungen an die Maskierung durch die Ketten der Transformation wandern. Trägt eine Tabelle der Silver-Schicht eine als PII klassifizierte Spalte mit einer Maskierregel, und wird diese Spalte in eine abgeleitete Spalte einer Gold-Tabelle für Berichte umgeformt, zeigt Dawiso die Verbindung in der Lineage, sodass das Governance-Team prüfen kann, ob die Maskierregel auch auf die abgeleitete Spalte angewandt wurde. Das verhindert das häufige Fehlerbild, dass sensible Daten an der Quelle klassifiziert und maskiert sind und in nachgelagerten abgeleiteten Beständen versehentlich offenliegen.

Dawiso stützt außerdem die Berichterstattung zur Compliance der Maskierung: Governance-Teams können Berichte erzeugen, die alle Spalten mit aktiven Maskierregeln zeigen, dazu die Art der Regel, das letzte Prüfdatum und die Verantwortlichen, und damit den Audit-Trail liefern, den Rahmenwerke der Compliance verlangen.