Schutz vertraulicher Daten in HSM-Datenbanken

Architekturlösungen für den sicheren Schutz sensibler Daten in Datenbanken

Sensible Daten wie Kartennummern (PAN) und personenbezogene Informationen (PII) erfordern einen robusten Schutz vor Lecks durch Datenbank-Backups und Admin-Zugriffe. Wichtige Herausforderungen sind die Speicherung verschlüsselter Daten bei gleichzeitiger Suchbarkeit, sichere Schlüsselverwaltung und Minimierung von Breach-Risiken. Eine Analyse zeigt eine Trennung: PCI DSS für PAN und Gesetze wie 152-FZ/DSGVO für PII aufgrund unterschiedlicher Anforderungen, z. B. vollständige Datenlöschung auf Anfrage.

Eine Kartennummer ist kein absolutes Geheimnis: Die ersten 6–8 Ziffern sind der Banken-BIN, die letzte ein Prüfsummen-Checksum, sodass 7–9 Ziffern für Brute-Force-Angriffe übrig bleiben (10–1000 Millionen Kombinationen pro BIN). Die Speicherung gesalzener PAN-Hashes in der Datenbank ist anfällig für GPU-Angriffe, falls das Salt offengelegt wird.

Verschlüsselung und HSM-Optionen

Ein HSM (Hardware Security Module) ist ein Gerät zur sicheren Speicherung von Schlüsseln und Durchführung kryptografischer Operationen. Hardware-HSMs schützen Schlüssel physisch vor Extraktion; Software-Varianten setzen auf Zugriffssteuerungen.

Software-HSMs nutzen Shamir's Secret Sharing: Der Master-Schlüssel wird in N Teile zerlegt, von denen K aus N zur Rekonstruktion benötigt werden (K < N). Beispiel: 5 Teile, 3 zur Aktivierung. Es handelt sich um einen Kompromiss – das Risiko wird in die eigene Organisation verlagert, spart aber Kosten.

Optionen für die Suche in verschlüsselten Daten:

• TDE (Transparent Data Encryption): Verschlüsselt Dateien auf der Festplatte, aber Daten liegen im Speicher als Klartext vor. Schützt vor gestohlenen Laufwerken, nicht vor DBAs.
• Gesalzener Hash: Speichert Hash von PAN + Salt aus HSM, indiziert nach Hash. Das Salt bleibt außerhalb der DB, um Brute-Force zu verhindern.
• Deterministische Verschlüsselung: Kein IV, gleicher Klartext ergibt immer denselben Chiffretext. Ermöglicht Indizierung, aber riskant bei Schlüssellecks.

Bester Ansatz: Die DB speichert verschlüsselte PAN, Crypto-Hash und Schlüssel-ID (für Rotation). Suche nach Hash; Dienste sehen nur Hashes. PCI DSS begrenzt Hashes im Cardholder-Data-Environment – stattdessen Tokens in separatem Speicher verwenden.

Schlüsselverwaltung: Vault und seine Grenzen

Tools wie HashiCorp Vault, Azure Key Vault und AWS Secrets Manager handhaben Geheimnisse gut, versagen aber bei Kryptoschlüsseln. Sie schützen vor:

• Geheimnissen im Git-Commit.
• Env-Var-Lecks.
• Unautorisierter Lektüre.

Sie schützen nicht vor:

• Vault-Admins.
• Server-Admins (Speicherdumps).
• mTLS-Zertifikatsinhabern.

Stärken durch mTLS mit Hardware-Schlüsseln, Ratenlimits und Auditing. Vault ist kein HSM. Azure Key Vault Premium nutzt HSMs in Microsoft-Rechenzentren mit nicht-exportierbaren Schlüsseln und API-Operationen.

Kubernetes Secrets: Risiken der Containerisierung

Kubernetes Secrets sind base64-kodiert in etcd (nicht verschlüsselt). API-Server-Zugriff legt alle Secrets offen. Container sind anfällig für:

• Root-Host-Lektüre des Container-FS.
• nsenter in Prozesse.
• Speicherdumps.
• Netzwerkverkehr-Sniffing.

Unakzeptabel für Krypto-Dienste. Abhilfen wie gVisor, Kata Containers oder Confidential Computing helfen, erhöhen aber Komplexität.

Cloud-Lösungen und geteilte Verantwortung

Clouds wie AWS und Azure sind PCI-DSS-zertifiziert für Infrastruktur (Rechenzentren, Festplattenverschlüsselung), doch für Schlüssel und Zugriffe seid ihr selbst verantwortlich. Cloud-Verkehr läuft über virtuelle Netze – Provider-Admins könnten mithören. Empfehlung: Dedizierter Krypto-Dienst mit physischer Isolation (separate Verkabelung); in der Cloud isolierte HSMs einsetzen.

Konsens-Architektur

• Dedizierter Krypto-Dienst außerhalb von Containern, minimale Schnittstellen.
• Nicht-extrahierbare Schlüssel in HSM (Hardware/Software/Cloud).
• Shamir-Schema ohne Hardware-HSM.
• Crypto-Hash für Suchen, Salt aus HSM.
• Separate Behandlung von PAN/PII.
• Vollständiges Auditing.
• Schlüsselrotation.

Wichtige Erkenntnisse:

• Salts/Schlüssel außerhalb der DB halten – HSM nutzen.
• Suche via Crypto-Hashes oder Tokens; deterministische Verschlüsselung vermeiden.
• Organisatorische Kompromisse (Shamir) sparen Geld.
• Vault für Geheimnisse, HSM für Schlüssel.
• PCI DSS und PII nach Vorschriften trennen.

— Editorial Team