PII-Datenverschlüsselung – Best Practices

Personenbezogene Daten (PII) sind alle Daten, die zur eindeutigen Identifizierung einer Person verwendet werden können: Name, E-Mail-Adresse, Telefonnummer, Bankkontonummern, Gesundheitsdaten und ähnliche Merkmale. Die unbefugte Offenlegung von PII birgt drei sich gegenseitig verstärkende Risiken: Vertrauensverlust der Verbraucher, direkte finanzielle Folgen (laut IBM/Ponemon Cost of a Data Breach Report 2023 belaufen sich die durchschnittlichen Kosten einer Datenschutzverletzung weltweit auf 4.45 Millionen US-Dollar) sowie rechtliche und regulatorische Strafen gemäß DSGVO , HIPAA , CCPA und PCI DSS . Empfohlene Maßnahmen: Alle PII nach Sensibilität und regulatorischer Kategorie klassifizieren, ruhende Daten mit AES-256-GCM verschlüsseln, TLS 1.3 für alle Datenübertragungen erzwingen, Schlüssel getrennt von den verschlüsselten Daten mithilfe eines FIPS-validierten Schlüsselverwaltungssystems verwalten und PII, die nicht weiterverarbeitet werden müssen, tokenisieren.

Kurzantwort: Was sind die besten Vorgehensweisen für die Verschlüsselung personenbezogener Daten?

Die Best Practices für die Verschlüsselung personenbezogener Daten (PII) umfassen drei Phasen des Datenlebenszyklus. Im Ruhezustand: Verwenden Sie AES-256-GCM für die Datenbank- und Dateiverschlüsselung; speichern Sie die Verschlüsselungsschlüssel getrennt von den verschlüsselten Daten in einem HSM oder KMS gemäß FIPS 140-2 Level 2 oder höher; rotieren Sie die Schlüssel in einem definierten Rhythmus (ein bis drei Jahre für Datenverschlüsselungsschlüssel gemäß NIST SP 800-57); und verwenden Sie Tokenisierung für PII-Werte (z. B. Zahlungskartennummern), auf die nachgelagerte Systeme zugreifen müssen, ohne den eigentlichen Wert zu verarbeiten. Während der Übertragung: Erzwingen Sie TLS 1.3 für alle zwischen Systemen übertragenen PII; validieren Sie Serverzertifikate von vertrauenswürdigen Zertifizierungsstellen; verwenden Sie Mutual TLS (mTLS) für die Kommunikation zwischen Diensten in internen Umgebungen. In der Nutzung: Wenden Sie Datenmaskierung für Nicht-Produktionsumgebungen an; erzwingen Sie Zugriffskontrollen, sodass nur Systeme und Benutzer mit einem berechtigten Interesse auf entschlüsselte PII zugreifen können; und protokollieren Sie jeden Zugriff auf PII-Datenspeicher mit ausreichendem Detailgrad für forensische Untersuchungen und den Nachweis der Compliance.

Was sind personenbezogene Daten (PII)?

Personenbezogene Daten (PII) sind alle Daten, die dazu verwendet werden können, eine Person eindeutig zu identifizieren, zu kontaktieren oder ihren Aufenthaltsort zu bestimmen, entweder allein oder in Kombination mit anderen Informationen. Die meisten Datenschutzbestimmungen definieren zwei Stufen:

• Direkte PII: Daten, die eine Person selbstständig identifizieren. Beispiele hierfür sind vollständiger Name, E-Mail-Adresse, Telefonnummer, Anschrift, nationale Identifikationsnummer (Sozialversicherungsnummer, Personalausweisnummer), Reisepassnummer, Führerscheinnummer und Kontonummern.
• Sensible personenbezogene Daten: Daten, die aufgrund potenziell schwerwiegender Schäden durch Offenlegung einen erhöhten Schutz erfordern, sind Beispiele hierfür. Dazu gehören Gesundheits- und medizinische Informationen, biometrische Daten, Finanzkontonummern, Angaben zur ethnischen Herkunft, sexuellen Orientierung und religiösen Überzeugungen. Sensible personenbezogene Daten unterliegen den strengsten Schutzbestimmungen der DSGVO, des HIPAA, des PCI DSS und ähnlicher Vorschriften.

Der erste Schritt bei der Verschlüsselung personenbezogener Daten (PII) ist die Datenklassifizierung: Dabei wird ermittelt, welche Daten in den Systemen des Unternehmens als PII gelten, welcher Kategorie sie zugeordnet sind und welche regulatorischen Anforderungen dafür gelten. Diese Klassifizierung bestimmt die Schutzanforderungen. Gesundheitsdaten unterliegen dem HIPAA, Zahlungskartendaten dem PCI DSS, europäische personenbezogene Daten der DSGVO und personenbezogene Daten kalifornischer Verbraucher dem CCPA. Manche Daten unterliegen gleichzeitig mehreren Vorschriften.

Auffinden personenbezogener Daten: Datenermittlung

Sobald die Kategorien personenbezogener Daten (PII) definiert sind, besteht der nächste Schritt darin, alle PII-Daten im gesamten Unternehmen zu lokalisieren. PII-Daten befinden sich selten an einem einzigen Ort: Sie sammeln sich in Produktionsdatenbanken, Anwendungsprotokollen, Backup-Systemen, Analysedatenspeichern, Entwicklungs- und Testumgebungen, E-Mail-Archiven und Cloud-Speichern an. Die Datenermittlung umfasst die Bewertung, wo jede PII-Kategorie in all diesen Umgebungen gespeichert und verarbeitet wird. Tools zur Datenermittlung automatisieren das Scannen nach Mustern, die mit PII übereinstimmen (Namen, E-Mail-Adressen, Kreditkartennummern, Sozialversicherungsnummernformate), in strukturierten Datenbanken und unstrukturierten Dateispeichern. Das Ergebnis der Datenermittlung ist eine PII-Datenkarte: eine Aufzeichnung darüber, wo sich jede PII-Kategorie befindet, welche Systeme sie verarbeiten und welche Kontrollmechanismen vorhanden sind.

Verschlüsselungstechnologien und Algorithmenauswahl

Anwendungsfall	Empfohlener Algorithmus	Schlüsselgröße	Was man vermeiden sollte	Literaturhinweis
Ruhende personenbezogene Daten (Datenbank, Dateisystem, Cloud-Speicher)	AES-256-GCM	256-bit	DES, 3DES, RC4, AES-ECB (kein Integritätsschutz)	NIST SP 800-111; FIPS 140-3
PII bei der Übertragung (Client-Server, Dienst-zu-Dienst)	TLS 1.3 (ECDHE-Schlüsselaustausch, AES-GCM oder ChaCha20-Poly1305)	P-256 oder X25519 für Schlüsselaustausch	SSL 3.0, TLS 1.0, TLS 1.1; RC4; MD5; SHA-1-Zertifikat-Hashes	NIST SP 800-52 Rev. 2; PCI DSS Anforderung 4.2.1
Personenbezogene Daten, die durchsuchbar sein müssen (verschlüsselt)	Formatbewahrende Verschlüsselung (FPE, NIST SP 800-38G) oder deterministisches AES-SIV	256-bit	Randomisierte Verschlüsselung für Felder, die direkt abgefragt werden müssen	NIST SP 800-38G
Zahlungskartennummern und Token	Tokenisierung (Zufallstoken + sicherer Tresor) bevorzugt; AES-256-Verschlüsselung als sekundäre Kontrollmaßnahme	256-Bit-Verschlüsselungsschlüssel für den Tresor	Speichern von rohen PANs in Anwendungsprotokollen oder unverschlüsselten Feldern	PCI DSS-Anforderungen 3.3-3.5
Schlüsselverschlüsselung (Verkapselung von Datenverschlüsselungsschlüsseln)	AES-256-GCM (Schlüsselverschlüsselungsschlüssel) oder RSA-3072/ECDSA P-256 für asymmetrisches Schlüssel-Wrapping	256-Bit symmetrisch oder 3072-Bit RSA	RSA-1024; Speicherung von DEKs zusammen mit den verschlüsselten Daten	NIST SP 800-57 Teil 1

Verschlüsselung vs. Tokenisierung vs. Datenmaskierung

Drei verschiedene Techniken schützen personenbezogene Daten, jede mit unterschiedlichen Anwendungsfällen und Eigenschaften:

• Verschlüsselung: Wandelt personenbezogene Daten mithilfe eines Schlüssels in Geheimtext um. Der ursprüngliche Wert kann durch Entschlüsselung wiederhergestellt werden. Verwenden Sie diese Funktion, wenn das System, das die Daten empfängt oder speichert, berechtigterweise auf den ursprünglichen Wert zugreifen muss (z. B. um einem Kundendienstmitarbeiter die Adresse eines Kunden anzuzeigen oder eine Zahlung zur Überprüfung einer Bankkontonummer zu verarbeiten).
• Tokenisierung: Ersetzt personenbezogene Daten durch ein zufällig generiertes Token, das in keiner mathematischen Beziehung zum Originalwert steht. Der Originalwert wird in einem sicheren Token-Tresor gespeichert; nur Systeme mit Zugriff auf den Tresor können ihn abrufen. Diese Anwendung eignet sich, wenn nachgelagerte Systeme auf die Daten zugreifen müssen, ohne den eigentlichen PII-Wert zu verarbeiten (z. B. bei der Tokenisierung von Zahlungskarten im Einzelhandel: Das Token durchläuft die Zahlungsabwicklungskette, während die eigentliche Kartennummer im Tresor verbleibt).
• Datenmaskierung: Ersetzt personenbezogene Daten durch verschleierte Werte, die das Format beibehalten, aber nicht die tatsächlichen Werte darstellen und nicht rückgängig gemacht werden können. Geeignet für Nicht-Produktionsumgebungen (Entwicklung, Test, Analyse), in denen Entwickler oder Analysten, die keinen berechtigten Bedarf an den tatsächlichen Werten haben, Zugriff auf die echten personenbezogenen Daten hätten.

Bedrohungsmodell für die Verschlüsselung personenbezogener Daten

Bedrohung	Angriffsszenario	Verschlüsselungskontrolle	Warum es die Auswirkungen verringert
Datenbankverletzung	Angreifer erlangt unbefugten Lesezugriff auf eine Produktionsdatenbank mit personenbezogenen Daten (durch SQL-Injection, gestohlene Zugangsdaten oder falsch konfigurierte Zugriffskontrollen).	AES-256-GCM-Verschlüsselung ruhender Daten mit Schlüsseln, die in einem separaten KMS/HSM gespeichert sind	Gestohlener Geheimtext ohne den Verschlüsselungsschlüssel ist für den Angreifer wertlos; personenbezogene Daten können nicht gelesen oder verwendet werden.
Netzwerkabfang (MITM)	Angreifer fängt personenbezogene Daten während der Übertragung zwischen Client und Server oder zwischen internen Diensten ab.	TLS 1.3 mit Serverzertifikatsvalidierung; mTLS für die Kommunikation zwischen Diensten	Verschlüsselte Übertragung gewährleistet, dass abgefangene Pakete nicht gelesen werden können; Zertifikatsvalidierung verhindert Identitätsdiebstahl.
Backup-Exfiltration	Angreifer erlangt Zugriff auf unverschlüsselte Sicherungsdateien, die auf externen Speichermedien oder Datenträgern abgelegt sind.	AES-256-GCM-Verschlüsselung der Sicherungsdateien vor der Speicherung; Verschlüsselungsschlüssel werden nicht in der Sicherung gespeichert.	Physischer oder logischer Zugriff auf Sicherungsmedien legt ohne den Verschlüsselungsschlüssel keine personenbezogenen Daten offen.
Insider-Bedrohung	Ein privilegierter Mitarbeiter mit Datenbankzugriff exportiert oder exfiltriert personenbezogene Daten.	Verschlüsselung auf Feldebene für besonders sensible personenbezogene Datenfelder; Zugriffsprotokollierung; Zugriffskontrollen nach dem Need-to-know-Prinzip	Verschlüsselung beschränkt den Zugriff privilegierter Insider; Protokollierung liefert forensische Spuren zur Aufdeckung und Zuordnung von Straftaten.
Cloud-Fehlkonfiguration	Personenbezogene Daten, die in Cloud-Objektspeichern (S3, Azure Blob) gespeichert sind, wurden versehentlich öffentlich zugänglich gemacht	Serverseitige oder clientseitige Verschlüsselung mit vom Kunden verwalteten Schlüsseln vor dem Upload	Der öffentliche Zugriff auf verschlüsselte Speicherobjekte legt ohne den Verschlüsselungsschlüssel keine personenbezogenen Daten offen.
Wichtigster Kompromiss	Der Verschlüsselungsschlüssel wurde gestohlen oder ist durchgesickert, wodurch die Entschlüsselung verschlüsselter personenbezogener Daten ermöglicht wird.	HSM-Speicherung von Verschlüsselungsschlüsseln; Schlüsselrotationsplan; Zugriffskontrollen, die die Schlüsselnutzung auf autorisierte Systeme beschränken	HSM verhindert den Export von Schlüsseln; die Schlüsselrotation begrenzt die Menge der offengelegten Daten, falls ein älterer Schlüssel kompromittiert wird; Zugriffskontrollen beschränken, welche Systeme die Daten entschlüsseln können.

Bewährte Verfahren für das Schlüsselmanagement bei der Verschlüsselung personenbezogener Daten

Die letztendliche Wirksamkeit der PII-Verschlüsselung hängt nicht vom Algorithmus ab, sondern von der Qualität der Schlüsselverwaltung. Ein Angreifer, der den Verschlüsselungsschlüssel erlangt, kann alle mit diesem Schlüssel verschlüsselten personenbezogenen Daten entschlüsseln, unabhängig von der Stärke des Algorithmus. Anforderungen an die Schlüsselverwaltung für die PII-Verschlüsselung:

1. Trennen Sie verschlüsselte Daten von Verschlüsselungsschlüsseln: Verschlüsselungsschlüssel müssen getrennt von den zu schützenden Daten gespeichert werden. Eine Datenbank, deren Schlüssel in derselben Datenbank gespeichert sind, bietet nur minimalen Schutz vor einem Datenbankangriff. Die Schlüssel sollten in einem dedizierten Schlüsselverwaltungssystem (KMS) oder Hardware-Sicherheitsmodul (HSM) gespeichert werden.
2. Verwenden Sie HSM-gestützte Schlüsselspeicherung für sensible personenbezogene Daten: Ein HSM gemäß FIPS 140-2 Level 2 oder höher speichert Schlüssel in manipulationssicherer Hardware und verhindert deren Export. Alle kryptografischen Operationen mit dem Schlüssel (Verschlüsselung, Entschlüsselung) werden innerhalb des HSM durchgeführt. Ein Angreifer, der den Anwendungsserver kompromittiert, kann den Schlüssel nicht aus dem HSM extrahieren. Siehe HSM als Service für hardwaregestütztes Schlüsselmanagement ohne lokale HSM-Infrastruktur.
3. Schlüsselrotation implementieren: Datenverschlüsselungsschlüssel (DEKs) sollten gemäß einem vom Datenschutz und dem Datenvolumen abhängigen Zeitplan rotiert werden. NIST SP 800-57 empfiehlt für symmetrische Inhaltsverschlüsselungsschlüssel Kryptoperioden von zwei bis drei Jahren. Die Rotation erfordert die erneute Verschlüsselung aller Daten mit dem neuen Schlüssel. Daher wird in den meisten Produktionsumgebungen die Envelope-Verschlüsselung (das Einbetten eines DEK in einen Key Encryption Key, KEK) verwendet: Die Rotation des KEK ist deutlich einfacher als die erneute Verschlüsselung des gesamten Datensatzes.
4. Zugriffskontrollen für die Schlüsselnutzung durchsetzen: Der Zugriff auf Schlüsseloperationen (Verschlüsselung, Entschlüsselung) sollte ausschließlich autorisierten Systemen und Prozessen über identitätsbasierte Zugriffskontrollen gewährt werden. Alle Schlüsselverwendungsereignisse sollten mit Zeitstempel, der Identität des anfragenden Systems und der verwendeten Schlüsselkennung protokolliert werden.
5. Plan für das Schlüsselmanagement nach der Quantentechnologie: AES-256 ist nicht anfällig für Quantencomputer (symmetrische Algorithmen sind von Shors Algorithmus nicht betroffen). Allerdings sind die in einigen Schlüsselverwaltungssystemen verwendeten Schlüsselverschlüsselungs- und Schlüsselaustauschmechanismen RSA und ECC quantenanfällig. Organisationen sollten daher ihre Schlüsselverwaltungsinfrastruktur im Hinblick auf Quantenanfälligkeit prüfen. PQC-Migrationsplanung.

Compliance-Mapping

Rechtliches	abgedeckte PII-Kategorie	Verschlüsselungsanforderung	Schlüsselmanagement-Anforderung
DSGVO (Artikel 32)	Alle personenbezogenen Daten von EU-Bürgern	Verschlüsselung wird als geeignete technische Maßnahme aufgeführt; auf die Meldepflicht bei verschlüsselten Sicherheitslücken wird verzichtet.	Risikobasiert; die ENISA-Leitlinien empfehlen AES-256 und TLS 1.3.
HIPAA-Sicherheitsregel	Elektronisch geschützte Gesundheitsinformationen (ePHI)	Adressierbare Spezifikation (Implementierung oder Dokumentation der Gründe); die OCR-Durchsetzung behandelt das Fehlen einer Verschlüsselung konsequent als Verstoß.	Schlüssel müssen getrennt von verschlüsselten elektronischen Gesundheitsdaten (ePHI) verwaltet werden; die NIST-Richtlinien (NIST SP 800-111) sind die Standardreferenz.
PCI-DSS v4.0	Karteninhaberdaten (PAN, SAD)	Anforderung 3.5: Starke Kryptografie für gespeicherte PAN; Anforderung 4.2.1: TLS für PAN während der Übertragung	Anforderung 3.7: dokumentierte Schlüsselverwaltungsverfahren einschließlich Erstellung, Verteilung, Aufbewahrung, Außerbetriebnahme, Rotation und Zugriffskontrolle
CCPA	Persönliche Daten von Verbrauchern in Kalifornien	Keine Verschlüsselungspflicht; Schutz vor Klagen Dritter bei verschlüsselten Daten.	Es gibt keine spezifischen Anforderungen an das Schlüsselmanagement; es gelten die bewährten Verfahren der Verschlüsselung.
NYDFS-Cybersicherheitsverordnung (23 NYCRR 500)	Nichtöffentliche Informationen von Kunden des New Yorker Finanzdienstleistungssektors	Verschlüsselung ist für nicht-öffentliche Informationen im Ruhezustand und während der Übertragung erforderlich.	Schlüsselverwaltungsprogramm erforderlich; Schlüssel müssen vor unbefugtem Zugriff geschützt werden

Einsatzbeispiel: Verschlüsselung personenbezogener Daten von Gesundheitsdienstleistern

Ein Gesundheitsdienstleister, der Patientendaten einschließlich Namen, Geburtsdaten, Diagnosecodes und Versicherungsinformationen speichert, implementiert die PII-Verschlüsselung in sechs Schritten:

1. Datenklassifizierung und -erkennung: Die personenbezogenen Datenfelder in der Patientendatenbank werden nach Sensibilität klassifiziert (Name und Kontaktdaten gelten als direkte personenbezogene Daten; Diagnosecodes und Versicherungsnummern als sensible personenbezogene Daten/elektronische Gesundheitsdaten). Ein Datenscan ermittelt, wo Patientendaten auch in Anwendungsprotokollen, Backup-Systemen und einer vom Analyseteam genutzten Berichtsdatenbank gespeichert sind.
2. Feldverschlüsselung für elektronische Gesundheitsdaten: Diagnosecodes, Versicherungsnummern und andere ePHI-Felder in der Produktionsdatenbank werden auf Feldebene mit AES-256-GCM verschlüsselt. Die Verschlüsselungsschlüssel werden in einem HSM-gestützten KMS gespeichert, nicht in der Datenbank oder auf dem Anwendungsserver.
3. Vollständige Datenbankverschlüsselung für Backups: Datenbank-Backups werden vor dem Speichern im Backup-Speicher mit AES-256-GCM verschlüsselt. Der Backup-Verschlüsselungsschlüssel ist von den Feldschlüsseln getrennt und wird über dasselbe KMS mit einer separaten, auf das Backup-System beschränkten Zugriffsrichtlinie verwaltet.
4. TLS 1.3 für die gesamte patientenbezogene und dienstübergreifende Kommunikation: Das Patientenportal, die mobile Anwendung und alle internen Serviceaufrufe, die Patientendaten verarbeiten, sind so konfiguriert, dass sie TLS 1.3 als Mindestprotokollversion verwenden. TLS-Zertifikate werden über einen Zertifikatslebenszyklusverwaltungsprozess mit automatischer Erneuerung verwaltet.
5. Datenmaskierung für Analyseumgebungen: Die vom Analyseteam verwendete Berichtsdatenbank enthält anonymisierte Kopien von Patientendaten: Echte Diagnosecodes und Aufnahmemuster bleiben für die statistische Analyse erhalten, Namen, Geburtsdaten und Versicherungsnummern werden jedoch durch synthetische Werte ersetzt. Analysten können so Bevölkerungsgesundheitsanalysen durchführen, ohne auf die personenbezogenen Daten (PII) realer Patienten zugreifen zu müssen.
6. Zugriffsprotokollierung und -prüfung: Sämtliche Zugriffe auf das KMS für Entschlüsselungsvorgänge werden protokolliert. Die Protokolle werden vierteljährlich auf Anomalien (unerwartete Systemanfragen zur Entschlüsselung, Zugriffe außerhalb der Geschäftszeiten, Zugriffe auf Schlüssel für stillgelegte Datenspeicher) überprüft und für den von HIPAA vorgeschriebenen Zeitraum (sechs Jahre) aufbewahrt.

Einschränkungen der PII-Verschlüsselung

• Verschlüsselung schützt personenbezogene Daten nicht, wenn diese aktiv genutzt werden: Wenn eine Anwendung personenbezogene Daten (PII) entschlüsselt, um sie zu verarbeiten (z. B. einem Benutzer anzuzeigen, in eine E-Mail einzufügen oder zu Debugging-Zwecken zu protokollieren), werden die Klartextdaten kurzzeitig im Anwendungsspeicher und möglicherweise in Protokollen angezeigt. Das Anwendungsdesign muss daher die Verweildauer von personenbezogenen Daten im Klartext im Speicher minimieren, deren Erscheinen in Protokollen verhindern und die Weitergabe an nachgelagerte Systeme, die diese Daten nicht benötigen, vermeiden.
• Das Schlüsselmanagement ist das schwächste Glied: Die Sicherheit verschlüsselter personenbezogener Daten ist nur so stark wie die Sicherheit der Verschlüsselungsschlüssel. Ein unsachgemäß verwalteter Schlüssel (gespeichert in einer Konfigurationsdatei neben der Datenbank, für alle Entwickler zugänglich und nie rotiert) bietet nur minimalen Schutz. Die meisten Fehler bei der Verschlüsselung personenbezogener Daten sind in der Praxis auf Fehler im Schlüsselmanagement und nicht auf Schwächen des Algorithmus zurückzuführen.
• Verschlüsselte personenbezogene Daten werden nicht anonymisiert: Verschlüsselte personenbezogene Daten bleiben gemäß DSGVO und anderen Datenschutzbestimmungen personenbezogene Daten, da der Verantwortliche den Schlüssel besitzt und die Daten entschlüsseln kann. Eine vollständige Anonymisierung (sodass die betroffene Person selbst von der Organisation nicht wieder identifiziert werden kann) entzieht die Daten zwar dem Anwendungsbereich der meisten Datenschutzbestimmungen, ist aber in der Praxis schwer zu erreichen, ohne die Nutzbarkeit der Daten zu beeinträchtigen.
• Leistungsmehraufwand bei der Verschlüsselung großer Datenmengen auf Feldebene: Die Ver- und Entschlüsselung einzelner PII-Felder in einer Datenbank erhöht die Latenz bei Lese- und Schreibvorgängen. Bei Anwendungen mit hohem Durchsatz reduziert hardwarebeschleunigtes AES (AES-NI) diesen Overhead deutlich, jedoch kann die Verschlüsselung auf Feldebene die Abfrageleistung bei umfangreichen analytischen Abfragen verschlüsselter Felder weiterhin beeinträchtigen.

Wie Verschlüsselungsberatung helfen kann

• Verschlüsselungsberatungsdienste: UNSERE Verschlüsselungsberatung Bewerten Sie den aktuellen PII-Schutzstatus Ihrer Organisation, identifizieren Sie Lücken in der Verschlüsselungsabdeckung (unverschlüsselte PII-Felder, Backups, die im Ruhezustand nicht verschlüsselt sind, veraltete Protokolle für Daten während der Übertragung) und empfehlen Sie einen Sanierungsplan, der mit den Richtlinien der DSGVO, HIPAA, PCI DSS und NIST übereinstimmt.
• HSM als Dienstleistung: HSM als Service bietet FIPS 140-3-validierten hardwaregestützten Speicher für die Verschlüsselungsschlüssel zum Schutz Ihrer personenbezogenen Daten und gewährleistet, dass die Schlüssel nicht aus dem HSM exportiert werden können und dass alle Schlüsseloperationen protokolliert und nachvollziehbar sind.
• Beratungsleistungen im Bereich Compliance: UNSERE Compliance-Beratungsdienste Wir unterstützen Organisationen bei der Entwicklung von PII-Verschlüsselungsprogrammen, die den spezifischen Anforderungen der jeweiligen Vorschriften entsprechen, einschließlich der Dokumentations- und Prüfnachweisanforderungen, die von Aufsichtsbehörden und Gutachtern gefordert werden.
• CBOM Secure: CBOM Secure Er ermittelt alle kryptografischen Implementierungen in Ihrer Umgebung, einschließlich der Bereiche, in denen PII-Verschlüsselung angewendet wird, welche Algorithmen und Schlüssellängen verwendet werden und wo PII-Datenspeicher keine Verschlüsselungskontrollen aufweisen. Dadurch wird das erforderliche Inventar bereitgestellt, um Lücken zu schließen und die PQC-Migration für die Schlüsselverwaltungsinfrastruktur zu planen.

Fazit

Jedes Unternehmen, das personenbezogene Daten verarbeitet, ist verpflichtet, diese vor Missbrauch, unbefugtem Zugriff und Verstößen gegen gesetzliche Bestimmungen zu schützen. Verschlüsselung ist die direkteste technische Schutzmaßnahme: Werden verschlüsselte personenbezogene Daten gestohlen, sind sie für den Angreifer ohne den Verschlüsselungsschlüssel wertlos. Die drei Risiken eines Datenschutzverstoßes – Vertrauensverlust der Verbraucher, direkte finanzielle Einbußen und behördliche Strafen – werden deutlich reduziert, wenn es sich um ordnungsgemäß verschlüsselte Daten handelt.

Eine effektive Verschlüsselung personenbezogener Daten erfordert die Wahl des richtigen Algorithmus (AES-256-GCM für ruhende Daten, TLS 1.3 für Daten während der Übertragung), ein rigoroses Schlüsselmanagement (HSM-gestützte Speicherung, Rotationspläne, Zugriffskontrollen nach dem Prinzip der minimalen Berechtigungen), die Datenermittlung zur Gewährleistung der Abdeckung in allen Umgebungen sowie ergänzende Kontrollmechanismen (Tokenisierung für Zahlungsdaten, Maskierung für Entwicklungsumgebungen). Der häufigste Fehler liegt nicht in einem schwachen Algorithmus, sondern in einem unzureichenden Schlüsselmanagement: Schlüssel werden zusammen mit den Daten gespeichert, nie rotiert oder sind für Systeme zugänglich, die sie nicht benötigen. Wenn Ihr Unternehmen seine Verschlüsselungsstrategie für personenbezogene Daten im Hinblick auf regulatorische Anforderungen und Best Practices der Branche überprüfen möchte, wenden Sie sich an Encryption Consulting.

Häufig gestellte Fragen

Was sind personenbezogene Daten (PII)?

Personenbezogene Daten (PII) sind alle Daten, die eine Person allein oder in Kombination mit anderen Informationen identifizieren können. Direkte PII umfassen Name, E-Mail-Adresse, Telefonnummer und Personalausweisnummer. Sensible PII umfassen Gesundheitsdaten, Bankkontonummern und biometrische Daten. Die meisten Datenschutzbestimmungen definieren die von ihnen erfassten PII-Kategorien und legen für jede Kategorie spezifische Schutzpflichten fest.

Welcher Verschlüsselungsalgorithmus sollte für ruhende personenbezogene Daten verwendet werden?

AES-256-GCM ist der empfohlene Algorithmus. Er bietet eine 256-Bit-Verschlüsselung (ausreichend für Daten, die langfristig geschützt werden müssen), authentifizierte Verschlüsselung (Erkennung von Manipulationen) und Hardwarebeschleunigung. Er wird von NIST, PCI DSS und HIPAA empfohlen oder vorgeschrieben. Die häufigste Fehlerursache ist das Schlüsselmanagement, nicht die Schwäche des Algorithmus.

Worin besteht der Unterschied zwischen Verschlüsselung, Tokenisierung und Datenmaskierung für personenbezogene Daten?

Verschlüsselung wandelt personenbezogene Daten in einen Geheimtext um, der mit dem richtigen Schlüssel wiederhergestellt werden kann. Sie eignet sich, wenn autorisierte Systeme den Originalwert benötigen. Tokenisierung ersetzt personenbezogene Daten durch ein zufälliges Token, das in einem sicheren Datenspeicher abgelegt wird. Sie ist geeignet, wenn nachgelagerte Systeme auf die eigentlichen personenbezogenen Daten zugreifen, diese aber nicht verarbeiten. Datenmaskierung ersetzt personenbezogene Daten durch verschleierte Werte, die nicht rückgängig gemacht werden können. Sie eignet sich für Testumgebungen, in denen keine echten personenbezogenen Daten benötigt werden.

Welche Vorschriften schreiben die Verschlüsselung personenbezogener Daten vor?

Die DSGVO führt Verschlüsselung als geeignete technische Maßnahme auf und verzichtet auf die Meldung von Datenschutzverletzungen bei verschlüsselten Daten. HIPAA definiert Verschlüsselung als eine adressierbare Spezifikation (Implementierung oder Dokumentation der Gründe für deren Nichtimplementierung); die Durchsetzung durch das OCR wertet fehlende Verschlüsselung elektronischer Gesundheitsdaten (ePHI) konsequent als Verstoß. PCI DSS fordert eine starke Verschlüsselung gespeicherter Karteninhaberdaten und TLS für Daten während der Übertragung. Der CCPA bietet Schutz vor Klagen Dritter bei Datenschutzverletzungen im Zusammenhang mit Verschlüsselung. NYDFS 23 NYCRR 500 schreibt die Verschlüsselung ruhender und übertragener nicht-öffentlicher Informationen vor.

Wie sollten Verschlüsselungsschlüssel für personenbezogene Daten verwaltet werden?

Schlüssel müssen getrennt von den zu schützenden Daten in einem FIPS 140-2 Level 2- oder höherkonformen HSM oder einem dedizierten KMS gespeichert werden. Der Zugriff ist ausschließlich autorisierten Systemen zu gewähren. Die Schlüssel müssen in einem festgelegten Rhythmus rotiert werden (ein bis drei Jahre für DEKs gemäß NIST SP 800-57). Jegliche Schlüsselnutzung ist zu protokollieren. Um die Rotation praktikabel zu gestalten, ohne ganze Datensätze neu verschlüsseln zu müssen, empfiehlt sich die Verwendung von Envelope-Verschlüsselung (Umhüllung von DEKs mit einem KEK).

Unterscheidet sich die Verschlüsselung von personenbezogenen Daten im Ruhezustand von der Verschlüsselung von personenbezogenen Daten während der Übertragung?

Ja. Die Verschlüsselung ruhender Daten schützt gespeicherte personenbezogene Daten vor unbefugtem Zugriff auf die Speichermedien. Die Verschlüsselung während der Übertragung (TLS 1.3) schützt personenbezogene Daten, die zwischen Systemen übertragen werden, vor dem Abfangen im Netzwerk. Beides ist erforderlich: Die Verschlüsselung ruhender Daten schützt die Daten nicht während der Übertragung, und die Verschlüsselung während der Übertragung schützt keine gespeicherten Daten. Alle wichtigen Datenschutzbestimmungen fordern beides.