k-Anonymity (k≥5) im SAP-Kontext – warum Pseudonymisierung allein nicht reicht
Pseudonymisierung schützt direkte Identifizierung, aber Quasi-Identifier-Kombinationen reichen oft, einzelne Records auf eine Person zurückzuführen. Was k≥5 bedeutet, wann es genug ist, und welche zwei Felder in SAP-Daten am häufigsten den Anonymitäts-Schwellwert reissen.
Die Lücke zwischen Pseudonymisierung und Anonymisierung
Sie haben alle direkten Identifier (Name, Email, GLN, VAT) per HMAC pseudonymisiert. Eigentlich sicher? Nein. Wer Ihre Datentabelle hat plus eine Wahrscheinlichkeitsdatenbank über die Schweizer Bevölkerung, kann oft einzelne Datensätze auf konkrete Personen zurückführen.
Das klassische Beispiel: 87 % der US-Bevölkerung sind durch die Kombination Postleitzahl + Geburtsdatum + Geschlecht eindeutig identifizierbar. Diese drei Felder sind keine direkten Identifier – aber zusammen wirken sie wie eine ID.
Quasi-Identifier: Felder, die alleine nicht identifizieren, aber in Kombination doch.
Was k≥5 bedeutet
Ein Datensatz erfüllt k-Anonymity mit k=5, wenn es mindestens 5 weitere Datensätze mit derselben Quasi-Identifier-Kombination gibt. Ein Angreifer mit Hintergrundwissen kann den konkreten Datensatz also nicht eindeutig auf eine Person abbilden – er bleibt zwischen 5 möglichen.
mermaid
flowchart LR
D[Datensatz X<br/>Postcode 8800<br/>Branche Pharma<br/>Periode Q1/2026]
D --> Q{wie viele weitere Records<br/>mit derselben Kombi?}
Q -->|≥5| OK[k-Anon erfüllt]
Q -->|<5| Fail[Re-ID-Risiko<br/>Bucketing nötig]
style OK fill:#bbf7d0,stroke:#15803d
style Fail fill:#fecaca,stroke:#b91c1c
In der EU-DSGVO gibt es keinen festen Wert für k, aber die Aufsichtsbehörden empfehlen k≥5 als Minimum, k≥10 für sensible Datenkategorien.
Wo SAP-Daten typisch reissen
In den BAMVP-Daten haben wir das Risiko in zwei Feldern besonders gesehen:
Feld 1 – industry + invoicePeriod
„Pharma-Mittelstand mit Rechnungs-Periode Q1/2026“ gibt es in der Schweiz vielleicht 4 Firmen. Wenn der Datensatz dazu kommt, ist die Identifizierung in 4 Möglichkeiten reduziert – über k=5 Schwelle.
Mitigation: Bucketing der Periode auf Halbjahr oder Jahr; Industry-Aggregation auf NOGA-2-Ziffer statt 4-Ziffer.
Feld 2 – senderGln + recipientGln (auch wenn beide pseudonymisiert)
Selbst wenn beide GLNs HMAC-pseudonymisiert sind, ist das Tupel deterministisch. Wenn es dann nur eine Beziehung zwischen Sender X und Recipient Y in den Daten gibt, ist Re-Identifikation möglich (z.B. „der Sender, der mit Y abrechnet – wir wissen wer das ist“).
Mitigation: für seltene Kombinationen die GLN-Tupel zusätzlich gruppieren oder löschen.
Wie der Validator das prüft
```typescript function kAnonymityCheck(rows: Row[], quasiIds: string[], k = 5) { // Quasi-IDs zusammensetzen const groupKey = (r: Row) => quasiIds.map(f => r[f]).join('|');
// Zähle pro Kombination
const counts = new Map
// Verstoss-Liste const violators: { key: string, count: number }[] = []; for (const [key, count] of counts) { if (count < k) violators.push({ key, count }); }
return violators; // empty = pass } ```
Bei BAMVP nehmen wir als Quasi-Identifier-Set: {industry, region, invoicePeriod-bucketed, transactionVolume-bucketed}.
Was bei k<5-Violations passiert
Drei Optionen, je nach Tiefe:
Option A – Bucketing
Quasi-Identifier vergröbern: Q1 → H1, Pharma+Diagnostics → Pharma, Postcode 8800 → 88xx.
Option B – Top/Bottom-Coding
Extrem-Werte (1 % oben, 1 % unten) auf den 99-Perzentil bzw. 1-Perzentil schneiden.
Option C – Drop
Datensatz raus aus der QAS-Population.
In BAMVP nutzen wir A/B als Default, C nur wenn die ersten zwei nicht reichen. Drop reduziert die Aussagekraft der QAS-Daten – manchmal muss es trotzdem sein.
Was k-Anonymity nicht leistet
- Schutz vor Aggregat-Inferenz: aus 100 anonymisierten Datensätzen können statistische Eigenschaften abgeleitet werden, die für eine Person sensibel sind. → für solche Anforderungen
differential privacymit Noise-Injection. - Schutz vor Hintergrundwissen-Updates: was heute k=5 ist, kann morgen k=2 sein, wenn neue Datenquellen verfügbar werden. → halbjährliches Re-Test.
- Schutz vor Free-Text-Re-ID: wenn
descriptioneinen Hinweis enthält der nur auf einen Kunden passt – ist k irrelevant. → NER-Scrub davor.
Halbjährlicher Re-ID-Test
Pflicht in unserem Compliance-Setup: 1. 100 Random-Rows aus QAS ziehen 2. Externes Re-ID-Team (oder Penetration-Tester) versucht, Ursprungs-Person zu finden 3. Erfolgs-Quote dokumentieren – Ziel: 0 % Re-ID 4. Bei Erfolg: Anonymizer-Regel verschärfen, neu validieren
Diese Übung kostet 2-3 Tage pro Jahr und gibt dem DPO eine ehrliche Antwort.
Wer das einmal sauber prüfen will
Ein Architektur-Review (30 Min) prüft Ihre Anonymisierungs-Konfiguration gegen k-Anonymity-Verfahren und identifiziert die Quasi-Identifier-Kombinationen, die Ihre Daten reissen lassen. Output: Konkrete Bucketing-Empfehlung pro Entity.
Stand: 2026-06-25
