Salt-Lifecycle: HSM, Rotation und das Audit jeder Lese-Zugriff

Der HMAC-Salt ist das Geheimnis, dass Pseudonymisierung deterministisch UND nicht-rückführbar macht. Wer den Salt hat plus die anonymisierten Daten, kann pseudonymisierte IDs zurückrechnen. Wo der Salt liegt (HANA Secure Store), wie oft er rotiert (12 Monate), und warum jeder Lese-Zugriff im Audit-Log auftauchen muss.

Warum der Salt das Schloss ist

Pseudonymisierung mit HMAC macht aus „Müller AG“ deterministisch immer „a3f9c2...“ – egal wie oft. Vorteil: Joins über Datensätze hinweg funktionieren. Nachteil: wer den Salt hat, kann jeden Klartext-Wert hashen und gegen die anonymisierten Werte abgleichen → Re-Identifikation.

Der Salt ist nicht ein Geheimnis – er ist das Geheimnis.

Wo der Salt lebt

```mermaid flowchart TD Salt[HMAC-Salt
32 Bytes, generiert von HSM] Salt --> SS[HANA Secure Store
im PRD-Subaccount] SS -.->|nur Anonymizer-Service
zur Laufzeit, in-Memory| Anon[Anonymizer-Pipeline]

HSM[Azure Key Vault HSM
für Disaster Recovery] HSM -.-|verschlüsselter Backup
nicht in PRD-DB| SS

Audit[BTP Audit Log
jeder Lese-Zugriff] SS --> Audit

style SS fill:#fef3c7,stroke:#d97706 style HSM fill:#fecaca,stroke:#b91c1c ```

HANA Secure Store

Die Live-Quelle des Salts. Ein verschlüsselter Key-Value-Store innerhalb der HANA-Instanz, mit Encryption-at-Rest (HANA Native Storage Encryption).

Wichtige Eigenschaften: - Nur lokal in der PRD-Subaccount-HANA verfügbar - Cross-Subaccount-Read: technisch nicht möglich - Per-Tenant-Isolation auf DB-Level - Audit-Log bei jedem Zugriff

Azure Key Vault HSM

Disaster-Recovery-Kopie. Nicht für regulären Betrieb gedacht. Wenn der Salt in HANA Secure Store korrumpiert ist (sehr selten), kommt er aus dem HSM zurück.

Zugriff: - Nur AI Privacy & Operations Lead - Mit 4-Augen-Approval - Mit Sicherheits-Vorfall-Begründung dokumentiert

Wie der Anonymizer den Salt nutzt

```typescript // services/anonymizer/src/runtime.ts async function getSalt(): Promise { const conn = await cds.connect.to('prd-hdi-secure-store'); const result = await conn.run("CALL HANA_SECURE_STORE_GET('hmac_salt')"); // Salt landet kurz im Memory, wird nach Pipeline-Run sofort überschrieben return Buffer.from(result.value, 'hex'); }

// Nach Pipeline-Run: salt.fill(0); // Memory-Zeroing, falls supportet ```

Lebensdauer: Salt lebt nur während der Pipeline-Run-Dauer (~5 Min) im Memory. Danach: Memory-Zeroing, Garbage-Collection. Persistiert wird er in der QAS-Subaccount nirgendwo.

Rotation-Schedule

Monat 1-12: Salt-v1 aktiv Monat 13: neue Salt-v2 generiert (im HSM) Monat 13-15: Übergangs-Periode – beide Salts in Pipeline aktiv Monat 15-16: Komplett-Re-Anonymisierung der QAS-Population mit Salt-v2 Monat 16: Salt-v1 invalidiert

Was bei Rotation passiert: - Pseudonyme ändern sich. Alte QAS-Daten haben „a3f9c2...“ für Müller, neue haben „f8e1d4...“. Joins über die Rotation hinweg brechen. - Tester müssen ihre Test-Setups ggf. neu aufbauen, falls sie deterministische IDs erwartet haben. - Für externe Reports, die anonymisierte IDs referenzieren: Mapping-Tabelle alt→neu wird gepflegt (im PRD, nicht in QAS!).

Warum 12 Monate: kürzer = mehr Operations-Aufwand, länger = höheres Re-ID-Risiko bei Salt-Kompromittierung. 12 Monate ist ein vernünftiger Mittelwert.

Wer den Salt lesen darf

Niemand direkt – nicht einmal der AI Privacy & Operations Lead. Der Salt wird nur vom Anonymizer-Service-Tech-User (BAMVP_ANON_RO) gelesen, im Pipeline-Lauf, im Memory.

Menschliche Zugriffe auf den Salt: - Salt-Generation (initial + Rotation): vom HSM, mit 4-Augen-Approval - Salt-Restore aus HSM bei Disaster-Recovery: 4-Augen-Approval, Vorfall-dokumentiert

Alle anderen menschlichen Zugriffs-Versuche werden von HANA Secure Store zurückgewiesen.

Audit-Log bei jedem Zugriff

sql -- Audit-Log-Struktur CREATE TABLE SECURE_STORE_AUDIT ( timestamp TIMESTAMP, caller_user NVARCHAR(100), operation NVARCHAR(20), -- READ, WRITE, ROTATE key_name NVARCHAR(100), result NVARCHAR(20), -- SUCCESS, DENIED, ERROR request_id NVARCHAR(50) );

Pro Anonymizer-Lauf: ein READ-Eintrag mit BAMVP_ANON_RO als Caller. Das ist erwartet und unauffällig.

Was nie erwartet wird: - READ durch andere User - WRITE durch andere User als HSM-Initialisierung - DENIED-Einträge in grosser Zahl (= Versuchs-Spuren)

Der DPO reviewt das Audit-Log monatlich.

Was bei Salt-Kompromittierung passiert

Sev-1-Vorfall, sofort: 1. Notbetrieb: Anonymizer-Pipeline pausiert 2. Salt-Rotation hochgezogen (innerhalb 24h, nicht 12 Monate) 3. Komplett-Re-Anonymisierung der QAS-Population 4. Forensische Analyse: wer hatte Zugang, wann 5. DPO meldet (in CH: an EDÖB, in EU: an nationale Behörde)

In den 18 Monaten BAMVP-Betrieb hatten wir 0 Salt-Kompromittierungen. Das ist die Norm bei sauberer Konfiguration.

Operations-Aufwand

Wer das einrichten will

Ein Workshop (halbtägig) baut Ihren Salt-Lifecycle: HSM-Setup, HANA Secure Store, Rotation-Pipeline, Audit-Log-Konfiguration. Output: lauffähiger Salt-Setup mit Disaster-Recovery-Pfad.

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt