--- title: "Tokenisierung vs. Verschlüsselung: Was Daten wirklich aus dem Scope nimmt" description: "\"Wir haben alles verschlüsselt\" nimmt kein System aus dem PCI-DSS-Scope, und Tokenisierung nimmt dich nicht aus der DSGVO. Ein praxisnaher Leitfaden, was beide wirklich bringen — und wo Teams sich irren." author: Aleksei Aleinikov date: 2026-08-10 lang: de tags: [tokenisierung, datensicherheit, verschlüsselung, pci dss scope, pseudonymisierung, dsgvo, format-erhaltende verschlüsselung] canonical: https://www.alekseialeinikov.com/de/blog/topics/security/tokenisierung-vs-verschluesselung-2026-was-daten-aus-dem-scope-nimmt source: alekseialeinikov.com --- # Tokenisierung vs. Verschlüsselung: Was Daten wirklich aus dem Scope nimmt Zwei Sätze, die in fast jedem Compliance-Gespräch fallen — und beide sind falsch: > *„Wir haben alles verschlüsselt, also ist dieses System außerhalb des Scopes."* > > *„Wir haben die Daten tokenisiert, also gilt die DSGVO nicht."* Beides trägt nicht. Verschlüsselung nimmt ein System selten aus dem PCI-DSS-Scope, und Tokenisierung nimmt dich nie aus der DSGVO — denn Tokenisierung ist **Pseudonymisierung**, und pseudonymisierte Daten bleiben personenbezogen. Beide Verfahren sind wirklich nützlich. Sie bringen nur etwas anderes, als die meisten Teams annehmen. Dieser Leitfaden zeigt, was jedes tatsächlich leistet, was es betrieblich kostet und wo die Grenze wirklich verläuft. ![Verschlüsselung behält die Daten im Chiffretext; Tokenisierung ersetzt sie durch ein Surrogat, das nichts enthält.](https://www.alekseialeinikov.com/blog/tokenization-2026.webp) ## Der mechanische Unterschied **Verschlüsselung** transformiert einen Wert mit Algorithmus und Schlüssel. Der Chiffretext **enthält die Information weiterhin** — das ist der Sinn, sie muss ja wiederherstellbar sein. Wer den Schlüssel hat, hat die Daten. **Tokenisierung** ersetzt den Wert durch ein unabhängiges Surrogat und legt das Original woanders ab: ``` 4111 1111 1111 1111 → tok_9f2a8b3e4c7d ``` Dieses Token hat **keine mathematische Beziehung** zur Kartennummer. Es gibt keinen Schlüssel, der es umkehrt, weil es nichts umzukehren gibt. Das Original zurückzubekommen heißt, Zugriff auf die Zuordnung zu haben. Die praktische Folge zeigt sich im Ernstfall: | Szenario | Verschlüsselung | Tokenisierung | |---|---|---| | Datenbank gestohlen | Chiffretext — sicher, **solange der Schlüssel hält** | Token — allein wertlos | | Schlüssel oder Vault kompromittiert | Alle Daten offen | Alle Daten offen | | Insider mit DB-Zugriff | Braucht den Schlüssel | Braucht Vault-Zugriff **und** Berechtigung | Beide scheitern, wenn das Geheimnis scheitert. Der Unterschied liegt darin, was ein Angreifer allein aus der Datenbank gewinnt und wie viele getrennte Systeme er kompromittieren muss. ## Was Tokenisierung für PCI DSS wirklich leistet Hier lohnt Präzision, denn hier liegt das Geld. Die Logik der Scope-Reduktion: Ein System, das ausschließlich Token hält und **aus diesen Token die ursprüngliche Kartennummer nicht gewinnen kann**, kann außerhalb der Cardholder Data Environment liegen. Das Analytics-Warehouse, die Support-Tools, die Reporting-Pipeline — keines davon berührt je eine echte PAN, keines muss also geprüft werden, als täte es das. Für ein Unternehmen mit jährlicher Prüfung ist es eine reale, messbare Ersparnis, ein Dutzend Systeme aus dem Scope zu nehmen. **Aber der Scope verschwindet nicht — er konzentriert sich.** Das Tokenisierungssystem selbst rückt fest *in* den Scope: Vault, Zuordnung, Token-Erzeugung, De-Tokenisierungspfad. Du hast sensible Daten, die dünn über viele Systeme verteilt waren, an einem Ort gebündelt. Dieser Ort ist nun dein wertvollstes Ziel und wird entsprechend geprüft. Die Leitlinien des PCI SSC sind unmissverständlich: Tokenisierung beseitigt die Pflicht zur Aufrechterhaltung und Prüfung der Konformität nicht. **Wer Tokenisierung als „PCI DSS erledigt sich" verkauft, verkauft etwas.** Was du tatsächlich gekauft hast, ist ein kleineres, schärferes Problem: Statt zwanzig Systeme ausreichend zu verteidigen, verteidigst du ein System außerordentlich gut. ![Der PCI-DSS-Scope schrumpft über die Systemlandschaft, konzentriert sich aber im Token-Vault, der zum wertvollsten Ziel wird.](https://www.alekseialeinikov.com/blog/tokenization-pci-2026.webp) ## Die DSGVO-Falle Das ist das Missverständnis, das Teams am teuersten kommt — und es lohnt, die Verordnung direkt zu zitieren. **Artikel 4 Nr. 5** definiert Pseudonymisierung als: > *„die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen…"* Das beschreibt Tokenisierung exakt. Token in der Datenbank, Zuordnung getrennt und strenger geschützt. **Erwägungsgrund 26** schließt dann die Tür: > *„Einer Pseudonymisierung unterzogene personenbezogene Daten, die durch Heranziehung zusätzlicher Informationen einer natürlichen Person zugeordnet werden könnten, **sollten als Informationen über eine identifizierbare natürliche Person betrachtet werden**."* Tokenisierte Daten sind also **weiterhin personenbezogene Daten**. Damit gilt alles weiter: - Auskunftsersuchen betroffener Personen - Recht auf Löschung - Meldepflichten bei Datenschutzverletzungen - Speicherbegrenzung - Rechtsgrundlage für die Verarbeitung Nur **wirklich anonyme** Daten fallen aus der DSGVO — und Erwägungsgrund 26 legt die Latte hoch: Maßgeblich ist, ob eine Identifikation mit *„allen Mitteln, die von dem Verantwortlichen oder einer anderen Person nach allgemeinem Ermessen wahrscheinlich genutzt werden"*, möglich ist, unter Berücksichtigung von Kosten, Zeitaufwand und verfügbarer Technologie. Ein Token, das über einen von dir betriebenen Vault umkehrbar ist, kommt dieser Latte nicht nahe. Du hältst die zusätzlichen Informationen per Design. **Was Pseudonymisierung sehr wohl bringt**, ist real, nur enger gefasst: Sie ist in Artikel 32 ausdrücklich als geeignete technische Maßnahme genannt, sie verringert die Schwere einer Datenschutzverletzung, und sie stärkt die Position bei der Datenminimierung. Das ist etwas wert. Eine Befreiung ist es nicht. ![Tokenisierung ist Pseudonymisierung nach DSGVO — die Daten bleiben personenbezogen, und alle Pflichten bleiben bestehen.](https://www.alekseialeinikov.com/blog/tokenization-gdpr-2026.webp) ## Vault oder Vaultless Zwei Architekturen, und die Wahl hat echte Konsequenzen. **Vault-basiert** hält eine Zuordnungstabelle: Token ↔ Originalwert. Einfach zu durchdenken, einzelne Token lassen sich leicht zurückziehen, gut auditierbar. Der Preis: Der Vault ist ein **Single Point of Failure für Verfügbarkeit und Sicherheit zugleich**. Jeder Tokenisierungs- und De-Tokenisierungsaufruf hängt an ihm, er wächst unbegrenzt, und er hält sämtliche Geheimnisse an einem Ort. **Vaultless** leitet Token algorithmisch ab, statt sie zu speichern. Nichts zu replizieren, nichts das wächst, kein Lookup im heißen Pfad. Bessere Skalierung, kein Verfügbarkeitsengpass. Der ehrliche Vorbehalt: Vaultless-Tokenisierung **ist Kryptografie**. Die Sicherheit ruht vollständig auf dem Key-Management, und die Grenze zwischen „Vaultless-Tokenisierung" und „Verschlüsselung mit anderem Etikett" ist dünner, als Herstellermaterial zugibt. Das ist in Ordnung — nur sollte das Wort „Tokenisierung" nicht den Eindruck erwecken, man sei dem Key-Management-Problem entkommen, das man vermeiden wollte. ## Der Trade-off, der dein Design entscheidet Dieser erwischt Teams spät, meist wenn das Analytics-Team ein Ticket aufmacht. **Deterministische Token** — dieselbe Eingabe erzeugt immer dasselbe Token. Joins über Tabellen funktionieren, Distinct-Zählungen funktionieren, Deduplizierung funktioniert. Alles Analytische bleibt am Leben. **Zufällige Token** — jedes Vorkommen bekommt ein anderes Token. Nichts sickert durch. Nichts joint aber auch. Determinismus verrät Struktur. Taucht ein Token zehntausendmal im Datensatz auf, ist das eine Tatsache über die zugrundeliegenden Daten — und mit einem Hilfsdatensatz kann das ausreichen, Personen zu re-identifizieren, obwohl kein einzelnes Token umkehrbar ist. Nach DSGVO ist das genau das *„Aussondern"*, das Erwägungsgrund 26 zu bedenken gibt. Eine allgemein richtige Antwort gibt es nicht. Falsch ist nur, zu wählen, ohne zu merken, dass man wählt: | | Deterministisch | Zufällig | |---|---|---| | Joins und Analytics | ✅ funktionieren | ❌ brechen | | Häufigkeitsleck | ⚠️ ja | ✅ keines | | Re-Identifikationsrisiko | höher | niedriger | | Typischer Einsatz | Warehouse, Analytics | Zahlungsflüsse | Ein verbreiteter Mittelweg: deterministische Token **pro Kontext getrennt**, sodass derselbe Wert in der Analytics-Domäne anders tokenisiert wird als in der Support-Domäne und beide Datensätze sich nicht trivial korrelieren lassen. ## Formaterhaltende Verschlüsselung Manchmal ist die eigentliche Einschränkung nicht Sicherheit, sondern ein Schema, das sich nicht ändern lässt. Ein Legacy-System erwartet sechzehn Ziffern mit gültiger Prüfsumme. Es validiert beim Schreiben, hat Integer-Spalten, und ein Umbau steht auf keiner Roadmap. **Formaterhaltende Verschlüsselung** löst genau das: Der Chiffretext hat dieselbe Form wie der Klartext. NIST spezifiziert dafür **FF1 und FF3** in SP 800-38G. Zwei Dinge gehören dazu gesagt, beide direkt aus der Revisionsgeschichte von NIST. **FF3 musste repariert werden.** Nach der Kryptoanalyse von Durak und Vaudenay kündigte NIST 2017 an, den Tweak-Parameter von FF3 entweder zu verkleinern oder das Verfahren ganz zurückzuziehen. Der Tweak wurde von 64 auf 56 Bit reduziert, das Ergebnis heißt **FF3-1**. Diese Änderung steht in SP 800-38G Revision 1 — die zum Zeitpunkt des Schreibens weiterhin ein **öffentlicher Entwurf** ist, keine finale Veröffentlichung. **Kleine Wertebereiche sind die eigentliche Grenze.** Arbeiten von Hoang, Tessaro und Trieu brachten NIST dazu, die Vorgabe zu verschärfen: Aus der *Empfehlung* von mindestens einer Million möglicher Eingaben wurde in Revision 1 eine **Anforderung**. Ein Feld mit wenigen möglichen Werten zu verschlüsseln ist grundsätzlich schwach, unabhängig vom Verfahren. Behandle FPE also als **Kompatibilitätswerkzeug, nicht als Standard**. Lässt sich das Schema ändern, nimm authentifizierte Standardverschlüsselung oder echte Tokenisierung. Greife zu FPE, wenn das nachgelagerte System sich wirklich nicht ändern lässt. ![Deterministische Token erhalten Joins, verraten aber Häufigkeiten; zufällige Token verraten nichts, brechen aber Analytics.](https://www.alekseialeinikov.com/blog/tokenization-tradeoffs-2026.webp) ## Die Wahl zwischen beiden Arbeite die Fragen in dieser Reihenfolge durch: 1. **Ist das Feld klein, klar umrissen und hochsensibel?** Kartennummern, Ausweisnummern, Kontonummern. Wenn ja, ist Tokenisierung ein Kandidat. Bei einem Freitextdokument nicht. 2. **Fließt der Wert durch Systeme, die ihn gar nicht sehen müssen?** Das ist die eigentliche Frage. Tokenisierung zahlt sich aus, wenn ein frühes Ersetzen den Großteil der Landschaft aus dem Wirkungsradius hält. Braucht ohnehin fast jeder Konsument den echten Wert, hast du Maschinerie gekauft und nichts gewonnen. 3. **Geht es um Prüfumfang oder um Schutz ruhender Daten?** Scope-Reduktion ist die echte Stärke der Tokenisierung. Schutz ruhender Daten ist Aufgabe der Verschlüsselung, und sie erledigt das mit weit weniger Betriebsaufwand. 4. **Kannst du einen Vault wirklich betreiben?** Hochverfügbarkeit, Notfallwiederherstellung, Schlüsselrotation, Zugriffskontrolle, Latenzbudget. Tokenisierung ist keine Bibliothek — sie ist ein System, und es sitzt im kritischen Pfad von allem, was den echten Wert braucht. 5. **Was bricht, wenn es ausfällt?** Bei Verschlüsselung ist ein KMS-Ausfall schlimm. Bei einem Vault heißt Ausfall: gar keine De-Tokenisierung mehr. Plane das ein, bevor du es herausfindest. ### Die Kurzfassung **Nimm Tokenisierung**, wenn ein kleines sensibles Feld sich über viele Systeme verteilt und du die meisten davon aus dem Scope nehmen willst. **Nimm Verschlüsselung** für alles andere — ruhende Daten, Daten in Transit, große oder unstrukturierte Inhalte und jeden Fall, in dem nahezu alle Konsumenten den echten Wert brauchen. **Nimm beides** in den meisten realen Architekturen. Sie lösen verschiedene Probleme und ergänzen sich gut. ## Was beides nicht behebt Das gehört klar gesagt, denn hier passieren die tatsächlichen Vorfälle. Keines der Verfahren hilft, wenn die Anwendung selbst zur De-Tokenisierung berechtigt ist und kompromittiert wird. Keines hilft gegen einen Insider mit legitimem Vault-Zugriff. Keines ersetzt Zugriffskontrolle, Audit-Logging oder das Wissen darüber, wo deine Daten überhaupt liegen. Wer kein genaues Bild davon hat, welche Systeme welche Daten halten, bekommt es durch Tokenisierung nicht — er bekommt nur ein System dazu. Diese Inventurarbeit kommt zuerst, und über die [Data-Governance-Seite davon auf GCP](https://www.alekseialeinikov.com/de/blog/topics/data/data-governance-gcp-2026-wer-sieht-welche-daten) habe ich separat geschrieben; das ist die natürliche Ergänzung. Und dasselbe Prinzip wie beim [Abschaffen langlebiger Service-Account-Schlüssel](https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-workload-identity-federation-2026) gilt auch hier: Die stärkste Kontrolle ist, das Geheimnis gar nicht erst dort zu haben, wo kompromittiert wird. ## Das Fazit Verschlüsselung behält die Daten im Chiffretext und übergibt das Risiko an dein Key-Management. Tokenisierung entfernt die Daten vollständig aus den Systemen, die sie nicht brauchen, und konzentriert das Risiko an einem Ort, den du richtig verteidigst. **Tokenisierung reduziert den PCI-DSS-Scope — sie beseitigt ihn nicht.** Der Vault rückt in den Scope und wird zum Kronjuwel. **Tokenisierung ist Pseudonymisierung, keine Anonymisierung.** Nach Erwägungsgrund 26 bleiben die Daten personenbezogen, und jede DSGVO-Pflicht bleibt bestehen. Gewonnen hast du eine anerkannte technische Maßnahme und einen kleineren Wirkungsradius — keine Befreiung. Wähle deterministisch oder zufällig bewusst, halte formaterhaltende Verschlüsselung für die Legacy-Systeme bereit, die dir keine Wahl lassen, und sei ehrlich, ob du einen Vault betreiben kannst, bevor du einen baust.