Verschlüsselung, Schlüsselverwaltung und Secrets

Was Verschlüsselung schützt und was nicht

Verschlüsselung wird oft als Kästchen zum Abhaken behandelt: „Die Daten werden bei der Übertragung und im Ruhezustand verschlüsselt.“ Die Formulierung verdeckt die eigentlich wichtige Frage, nämlich gegen wen. Jede Verschlüsselungsschicht schützt Daten vor manchen Parteien und vor anderen nicht, und in jedem Fall ist der Schutz genau so stark wie die Kontrolle darüber, wer den Schlüssel verwenden kann. Verschlüsselung beseitigt das Problem der Zugriffskontrolle nicht; sie verlagert es von den Daten zu den Schlüsseln, wo es sich meist leichter verwalten, prüfen und widerrufen lässt.

Verschlüsselung bei der Übertragung schützt Daten, die sich durch ein Netzwerk bewegen, davor, unterwegs gelesen oder verändert zu werden. Im Web bedeutet das TLS, eingeführt in Kapitel 0; zwischen Services bedeutet es TLS oder Mutual TLS, behandelt bei Zero Trust. Verschlüsselung im Ruhezustand schützt gespeicherte Daten, doch „im Ruhezustand“ ist nicht eine einzige Sache: Die Tabelle zeigt die üblichen Schichten auf der Essenslieferplattform.

Liest man die Tabelle von oben nach unten, schützt jede Schicht vor mehr Parteien und kostet mehr Funktionalität. Ein solider Entwurf setzt die günstigen, transparenten Schichten überall ein (TLS und Speicherverschlüsselung sind heute fast kostenlos) und die teuren gezielt, für die Daten, deren Offenlegung den größten Schaden anrichten würde. Welche Daten das sind, entscheidet die Datenklassifizierung, die später in diesem Abschnitt zusammen mit Tokenisierung und einem ausgearbeiteten Beispiel behandelt wird.

Symmetrische und asymmetrische Kryptografie

Symmetrische Verschlüsselung verwendet einen einzigen geheimen Schlüssel zum Ver- und Entschlüsseln. Sie ist schnell genug für große Datenmengen, und der Standardalgorithmus ist AES (FIPS 197, 2001) mit Schlüsseln von 128 oder 256 Bit. Moderne Entwürfe verwenden authentifizierte Verschlüsselung, die neben dem Verbergen des Inhalts auch Manipulationen erkennt: AES im Galois/Counter Mode (AES-GCM) oder ChaCha20-Poly1305 (RFC 8439). Authentifizierte Modi brauchen für jede unter demselben Schlüssel verschlüsselte Nachricht eine eindeutige Nonce; die Wiederverwendung einer Nonce bei AES-GCM kann Klartext offenlegen und Fälschungen ermöglichen, einer von vielen Gründen, gut getestete Bibliotheken zu verwenden, statt Primitive selbst zusammenzusetzen.

Asymmetrische Kryptografie verwendet ein Schlüsselpaar: einen öffentlichen Schlüssel, den jeder haben darf, und einen geheim gehaltenen privaten Schlüssel. Sie ermöglicht zwei Dinge, die symmetrische Kryptografie nicht kann. Schlüsselvereinbarung lässt zwei Parteien, die sich nie begegnet sind, über ein offenes Netzwerk einen gemeinsamen symmetrischen Schlüssel festlegen (Elliptic-Curve-Diffie-Hellman in TLS 1.3). Digitale Signaturen (RSA, ECDSA, Ed25519) lassen jeden mit dem öffentlichen Schlüssel prüfen, dass Daten vom Inhaber des privaten Schlüssels stammen und nicht verändert wurden; das liefert Integrität, Authentizität und eine Grundlage für Nichtabstreitbarkeit. Asymmetrische Operationen sind langsam, daher sind reale Protokolle hybrid: TLS nutzt asymmetrische Kryptografie, um den Server zu authentifizieren und Schlüssel zu vereinbaren, und dann symmetrische Verschlüsselung für die Daten.

Ein großer Quantencomputer würde die heutigen RSA- und Elliptic-Curve-Algorithmen brechen, nicht aber AES mit ausreichend langen Schlüsseln. Im August 2024 veröffentlichte das NIST seine ersten Post-Quanten-Standards: FIPS 203 (ML-KEM, für den Schlüsselaufbau), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA), beide für Signaturen. Daten, die viele Jahre vertraulich bleiben müssen, sind schon heute durch Angreifer gefährdet, die verschlüsselten Datenverkehr jetzt aufzeichnen, um ihn später zu entschlüsseln; die architektonische Antwort lautet daher Krypto-Agilität: Führen Sie ein Inventar, wo welche Algorithmen verwendet werden, vermeiden Sie es, sie fest zu codieren, und bevorzugen Sie Bibliotheken, Protokolle und Anbieter, die wechseln können, wie es große Browser und TLS-Bibliotheken mit hybridem Post-Quanten-Schlüsselaustausch bereits begonnen haben.

Hashing, MACs, Signaturen und Verschlüsselung sind verschiedene Werkzeuge

Die Verwechslung dieser Primitive ist eine häufige Quelle von Entwurfsfehlern, etwa wenn Passwörter „verschlüsselt“ werden, sodass man sie entschlüsseln kann, oder wenn man einem einfachen Hash vertraut, um zu beweisen, dass ein Webhook von einem Zahlungsanbieter stammt. Die Tabelle stellt sie nebeneinander.

Passwörter speichern

Ein Allzweck-Hash wie SHA-256 ist darauf ausgelegt, schnell zu sein, und das ist für Passwörter genau falsch: Grafikprozessoren können Milliarden Versuche pro Sekunde gegen eine gestohlene Tabelle schneller Hashes testen. Passwort-Hashing verwendet Funktionen, die absichtlich langsam und idealerweise speicherintensiv (memory-hard) sind, sodass jeder Versuch einen Angreifer echte Zeit und echten Speicher kostet, mit einem eindeutigen zufälligen Salt pro Passwort, sodass identische Passwörter unterschiedliche Hashes ergeben und vorberechnete Tabellen nutzlos sind.

Das OWASP Password Storage Cheat Sheet gibt aktuelle Empfehlungen in der Reihenfolge ihrer Präferenz. Argon2id (eine Variante von Argon2, Gewinner der Password Hashing Competition 2015) mit mindestens 19 MiB Speicher, zwei Iterationen und einem Parallelitätsgrad von eins (oder einer gleichwertigen Abwägung, etwa 46 MiB mit einer Iteration). scrypt, wo Argon2id nicht verfügbar ist, mit einem Kostenparameter von 2¹⁷ (128 MiB), einer Blockgröße von 8 und einer Parallelität von 1. bcrypt nur für Altsysteme, mit einem Work Factor von mindestens 10, wobei zu bedenken ist, dass die meisten Implementierungen Eingaben über 72 Bytes hinaus ignorieren. Wo FIPS-140-Konformität verlangt ist, PBKDF2 mit HMAC-SHA-256 und 600.000 Iterationen. Diese Werte steigen mit besserer Hardware, also prüfen Sie das aktuelle Cheat Sheet, statt Zahlen in ein Entwurfsdokument zu kopieren.

Daraus folgen drei Entwurfspunkte. Speichern Sie Algorithmus und Parameter mit jedem Hash (die üblichen kodierten Formate tun das), damit sich die Parameter später erhöhen lassen: Meldet sich ein Nutzer erfolgreich an, prüfen Sie gegen den alten Hash und hashen Sie sofort mit den neuen Parametern neu. Erwägen Sie einen Pepper, ein Geheimnis, das vor dem Hashen jedem Passwort hinzugefügt und in einem Vault oder HSM statt in der Datenbank aufbewahrt wird; das vereitelt einen Angreifer, der nur die Datenbank stiehlt. Am wichtigsten: Fragen Sie, ob Sie Passwörter überhaupt speichern sollten. Wer die Authentifizierung an einen Identity Provider delegiert und Passkeys anbietet, entfernt das am häufigsten angegriffene Geheimnis aus den meisten seiner Services.

Schlüsselverwaltung und Envelope Encryption

Schlüssel haben einen Lebenszyklus, beschrieben in NIST SP 800-57 Part 1: Erzeugung (aus einer geeigneten Zufallsquelle), Speicherung, Verteilung, Verwendung, Rotation am Ende einer festgelegten Kryptoperiode, Widerruf bei Kompromittierung und Vernichtung. All das sicher von Hand zu erledigen, ist unpraktikabel; deshalb stützen sich Architekturen auf einen Key Management Service (KMS) wie AWS KMS, Azure Key Vault oder Google Cloud KMS oder auf ein selbst betriebenes System wie HashiCorp Vault. Ein KMS hält Master Keys in Hardware-Sicherheitsmodulen (HSMs), manipulationsresistenten, nach FIPS 140 validierten Geräten, und führt Operationen mit diesen Schlüsseln auf Anfrage aus, gemäß einer Zugriffsrichtlinie, sodass Anwendungen die Master Keys nie zu sehen bekommen und jede Verwendung protokolliert wird.

Jeden Datensatz zum Verschlüsseln an den KMS zu schicken, wäre langsam und teuer, und KMS-APIs begrenzen die Größe von Anfragen. Envelope Encryption löst das. Die Anwendung fordert beim KMS einen frischen Data Encryption Key (DEK) an; der KMS gibt ihn zweimal zurück, im Klartext und verpackt (verschlüsselt) unter einem Key-Encryption-Key (KEK), der das HSM nie verlässt. Die Anwendung verschlüsselt die Daten lokal mit dem Klartext-DEK, entfernt den DEK aus dem Speicher und speichert den Chiffretext zusammen mit dem verpackten DEK. Zum Entschlüsseln sendet sie nur den kleinen verpackten DEK an den KMS, der die Berechtigung des Aufrufers prüft, die Anfrage protokolliert und den DEK zurückgibt.

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_field(plaintext: bytes, kms, kek_id: str, context: bytes) -> dict:
    dek = AESGCM.generate_key(bit_length=256)            # fresh data key
    nonce = os.urandom(12)                               # never reuse with this key
    ct = AESGCM(dek).encrypt(nonce, plaintext, context)  # context binds it to its row
    wrapped = kms.encrypt(key_id=kek_id, plaintext=dek)  # KEK stays inside the KMS
    return {"ct": ct, "nonce": nonce, "wrapped_dek": wrapped, "kek": kek_id}

def decrypt_field(rec: dict, kms, context: bytes) -> bytes:
    dek = kms.decrypt(key_id=rec["kek"], ciphertext=rec["wrapped_dek"])  # checked, logged
    return AESGCM(dek).decrypt(rec["nonce"], rec["ct"], context)

Envelope Encryption hat mehrere architektonische Vorteile. Rotation ist günstig: Das Rotieren eines KEK erzeugt eine neue Schlüsselversion für neue Verpackungsvorgänge, während alte Versionen zum Entschlüsseln verfügbar bleiben; vorhandene DEKs lassen sich neu verpacken, ohne die Daten anzufassen, und eine vollständige Neuverschlüsselung ist nur nötig, wenn ein DEK selbst offengelegt worden sein könnte. Der Blast Radius ist begrenzt: Bei einem DEK pro Datensatz, Datei oder Partition legt ein geleakter DEK wenig offen. Funktionstrennung wird möglich: Der Bestellservice darf seinen KEK zum Entpacken verwenden, aber weder dessen Richtlinie ändern noch ihn löschen, während Sicherheitsadministratoren Schlüssel verwalten, aber keine Daten entschlüsseln können. Schlüsselhierarchien lassen sich auf die Organisation abbilden: ein KEK pro Service und Datenklasse oder pro Mandant, sodass eine große Restaurantkette sogar ihren eigenen Schlüssel liefern und kontrollieren könnte. Und das Vernichten eines Schlüssels ist ein mächtiges Werkzeug: Crypto-Shredding macht jede Kopie der damit verschlüsselten Daten unlesbar, einschließlich Backups und unveränderlicher Event-Logs, was für die Löschung nach der DSGVO und für Systeme mit Event-Sourcing wichtig ist.

Der Preis ist eine neue kritische Abhängigkeit. Ist der KMS nicht verfügbar, lassen sich verschlüsselte Daten nicht lesen; wird ein Schlüssel versehentlich gelöscht, sind die Daten für immer verloren. Cloud-KMS erzwingen deshalb eine Wartefrist vor dem Löschen, und Architekten sollten das Löschen von Schlüsseln und Änderungen an Schlüsselrichtlinien als privilegierte, protokollierte Vorgänge nach dem Vier-Augen-Prinzip behandeln, entpackte DEKs kurz zwischenspeichern, wo die Latenz von KMS-Aufrufen ins Gewicht fällt, und den KMS in die Disaster-Recovery-Pläne aufnehmen.

Secrets-Management

Ein Secret ist jede Art von Zugangsdaten, die Zugriff gewährt: Datenbankpasswörter, API-Schlüssel für den Zahlungsanbieter, private Schlüssel, Signaturschlüssel, OAuth-Client-Secrets, Webhook-Secrets. Secrets-Management beginnt mit einer Regel: Secrets gehören nie in den Quellcode, auch nicht in Container-Images oder in Konfigurationsdateien, die in Repositories committet werden, denn diese werden kopiert, gecacht, geforkt und von weit mehr Menschen und Systemen gelesen, als das Secret sollte. Ist ein Secret einmal in der Historie eines Repositorys, bleibt es dort, auch nachdem die Zeile gelöscht wurde.

Secrets gehören in einen Vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager), der sie verschlüsselt speichert, sie nur gemäß Richtlinie an authentifizierte Workloads herausgibt, jeden Zugriff protokolliert und Rotation unterstützt. Besser als langlebige Secrets zu rotieren, ist es, keine zu haben: Ein Vault kann dynamische Secrets ausstellen, etwa ein Datenbankkonto, das für eine einzelne Service-Instanz mit einer Lease von einer Stunde angelegt wird, und Workload Identity lässt Services sich gegenüber Cloud-APIs und untereinander ganz ohne gespeichertes Secret authentifizieren. Zur Laufzeit injizierte Secrets sollten aus Dateien oder über die API des Vaults gelesen werden statt aus breit sichtbaren Umgebungsvariablen, die gern in Crash-Dumps und Debug-Logs landen.

Vorbeugung braucht Automatisierung, weil Menschen Fehler machen. Pre-Commit-Hooks und Pipeline-Scanner (etwa gitleaks und detect-secrets) fangen Secrets ab, bevor sie gepusht werden; Repository-Hoster scannen nach bekannten Secret-Formaten, und GitHubs Push Protection blockiert Pushes, die solche enthalten. Öffentliche Repositories werden von Angreifern innerhalb von Minuten nach einem Push gescannt. Die Folgen sind gut dokumentiert: 2016 verschafften sich Angreifer Zugang zu einem privaten GitHub-Repository, das Uber-Entwickler nutzten, fanden dort einen Zugriffsschlüssel für Ubers Cloud-Speicher und luden personenbezogene Daten von rund 57 Millionen Fahrgästen und Fahrern herunter.

Tokenisierung und Verkleinerung des PCI-DSS-Geltungsbereichs

Tokenisierung ersetzt einen sensiblen Wert durch ein Token, das in keiner mathematischen Beziehung zu ihm steht; der echte Wert wird in einem separaten, streng geschützten Vault aufbewahrt, und nur der Vault kann das Token zurück zuordnen. Anders als bei Verschlüsselung lässt sich ein gestohlenes Token nicht mit einem Schlüssel umkehren, weil es keinen Schlüssel gibt, nur ein Nachschlagen in einem System, das der Angreifer nicht kontrolliert.

Die wichtigste Anwendung sind Kartenzahlungen. Der Payment Card Industry Data Security Standard (PCI DSS, derzeit Version 4.0.1, veröffentlicht im Juni 2024) gilt für jede Systemkomponente, die Karteninhaberdaten speichert, verarbeitet oder überträgt oder die mit diesen Komponenten verbunden ist oder deren Sicherheit beeinflussen könnte. Eine Plattform, die Kartennummern durch ihre Server laufen lässt, holt ihr API-Gateway, ihre Services, Logs, Netzwerke und Administratoren in den Geltungsbereich, mit Hunderten von Anforderungen und einer jährlichen Prüfung. Eine Plattform, die die gehosteten Zahlungsfelder oder die Weiterleitung des Zahlungsanbieters nutzt, sodass Kartennummern direkt vom Gerät des Kunden zum Anbieter gehen, erhält nur ein Token und vielleicht die letzten vier Ziffern, und ihr PCI-DSS-Geltungsbereich schrumpft drastisch: Ein kleinerer Händler kann sich für den kürzesten Selbstbewertungsfragebogen qualifizieren, und selbst die größten Händler, die weiterhin eine jährliche Prüfung durch einen qualifizierten Assessor brauchen, haben weit weniger Systeme zu prüfen. Das ist der Entwurf im Bedrohungsmodell für den Checkout: Die am billigsten zu schützenden Kartendaten sind die, die Sie nie besitzen. Kartennummern selbst zu verschlüsseln, erreicht nicht dieselbe Verkleinerung, denn wer sie entschlüsseln kann, bleibt im Geltungsbereich.

Dieselbe Idee funktioniert für andere sensible Kennungen. Ein interner Tokenisierungsservice kann Sozialversicherungs- oder Passnummern auf der ganzen Plattform durch Tokens ersetzen, sodass nur ein kleiner, stark geschützter Service je die echten Werte sieht.

Datenklassifizierung

Verschlüsselung, Tokenisierung, Logging, Aufbewahrung und Zugriffsentscheidungen hängen alle davon ab, zu wissen, welche Daten wie sensibel sind. Ein Schema zur Datenklassifizierung legt einige Stufen mit zugehörigen Umgangsregeln fest, sodass Teams nicht jeden Fall von Grund auf entscheiden. Vier Stufen sind üblich; wichtig ist, dass jeder Datenbestand im Datenkatalog oder Schema der Plattform eine Stufe trägt und dass die Regeln durch Vorlagen und Prüfungen durchgesetzt werden statt durch das Gedächtnis.

Verschlüsselung auf Feldebene

Verschlüsselung auf Feldebene, die Schicht auf Anwendungsebene aus der ersten Tabelle, verschlüsselt einzelne Felder, bevor sie geschrieben werden, typischerweise mit Envelope Encryption und einem KEK pro Datenklasse. Ihre Stärke ist, dass alles, was der Anwendung nachgelagert ist, nur Chiffretext hält: Datenbankadministratoren, Read Replicas, Backups und das per Change Data Capture gespeiste Data Warehouse. Ein Einbruch in eines davon legt nichts Lesbares offen, und der Zugriff auf den Klartext beschränkt sich auf die Services, die den KMS mit diesem Schlüssel aufrufen können, wobei jeder Aufruf protokolliert wird.

Ihre Kosten sind real. Die Datenbank kann das verschlüsselte Feld nicht mehr indizieren, durchsuchen, sortieren oder für Joins nutzen. Gleichheitsabfragen lassen sich mit einem Blind Index wiederherstellen, einer separaten Spalte mit einem schlüsselbasierten Hash (HMAC) des normalisierten Werts, um den Preis, dass sichtbar wird, welche Zeilen denselben Wert teilen. Deterministische Verschlüsselung hat dasselbe Leck, während Bereichsabfragen spezielle Verfahren brauchen oder auf solchen Feldern schlicht unterbleiben sollten. Manche Datenbanken bieten clientseitige Verschlüsselung auf Feldebene oder abfragbare Verschlüsselung an, die diese Techniken bündelt. Wegen dieser Kosten sollte Verschlüsselung auf Feldebene streng vertraulichen Daten vorbehalten bleiben, deren Felder ohnehin selten abgefragt werden.