Datenspeicherung und die Nur-Anhängen-Beweiskette

Die Nur-Anhängen-Beweiskette und ein DSGVO-konformer Inhaltslöschplan stehen nicht im Widerspruch, weil die Kette von vornherein keine löschbaren Inhalte speichert.

Span-Verschlüsselung ersetzt Schwärzung; die Kette bleibt Nur-Anhängen

• evidence_events ist echtes Nur-Anhängen, auf Datenbankebene erzwungen, nicht nur durch Anwendungscode: Datenbankregeln wandeln UPDATE/DELETE auf der Tabelle in No-Ops um, und ein Trigger prüft beim Einfügen den previous_hash jeder neuen Zeile gegen den hash der vorherigen Zeile (Hash-Kettenintegrität, zur Schreibzeit geprüft).
• Personenbezogene Daten-Spans werden verschlüsselt, nicht geschwärzt. Jeder von den pii_scan-Detektoren erkannte Span (BSN, IBAN, Karte, E-Mail, Telefon, Geburtsdatum, Postadresse) wird in gespeicherten Kopien durch ein Token ⟦pii:v1:<TYPE>:<keyset_id>:<base64url(nonce‖ciphertext‖tag)>⟧ ersetzt, wobei der umgebende Text lesbar bleibt. Die Tokens werden vor dem Hashen und Schreiben des Ereignisses versiegelt, sodass das Ciphertext-Token Teil der gehashten Beweisdaten wird.
• Beweiszusammenfassungen zeichnen auf, welches Muster/welcher Ausdruck übereinstimmte, und können das Token rendern (Dashboards zeigen [Encrypted Email]-Chips); der rohe Transkript- oder Ausdruckstext wird nie im Klartext mitgeführt.
• Konsequenz: Löschung erfordert nie das Ändern einer einzelnen evidence_events-Zeile. Der Betreiber shreddet einen Datenschlüssel über POST /v1/pii/shred oder POST /v1/calls/{id}/pii/shred, und vorhandene Tokens werden ohne Änderung unlesbar. Die Hash-Kette sowie die darauf aufbauende Merkle/RFC-3161-Zeitstempelverankerung bleiben unabhängig davon, ob die Schlüssel vorhanden sind, intakt und manipulationserkennbar.

Identitäten und Schlüsselmaterial werden verschlüsselt gespeichert; nur Tokens werden in Beweisen gespeichert

• Identitäten: Jeder eindeutige Klartextwert (ein Name, eine E-Mail, eine Telefonnummer) wird als separate Identität in pii_identities mit einem eigenen zufälligen 32-Byte-Datenschlüssel verfolgt. Der Klartextwert selbst wird niemals gespeichert oder protokolliert — nur sein lookup (HMAC-SHA256 des Typs und des Client-Hashes) wird gespeichert, sodass der Mandant ihn ohne Klartext finden kann.
• Schlüssel-Wrapping: Datenschlüssel werden mit dem K_wrap des Mandanten (aus dem Schlüsselbund des Mandanten im Secrets Manager) mittels AES-256-GCM gewrapped, bevor sie in pii_identities.wrapped_key geschrieben werden. Der gewrappte Schlüssel kann nur vom Mandanten entschlüsselt werden; das Shredden einer Identität setzt ihren gewrappten Schlüssel auf NULL, wodurch die Daten der Identität dauerhaft unzugänglich werden.
• Keysets: Tokens werden unter Content-Keys versiegelt, die von den an dem Anruf beteiligten Identitäten abgeleitet werden. Jede eindeutige Gruppe von Identitäten erhält eine kurze keyset_id in pii_keysets. Das Shredden einer beliebigen Identität in einem Keyset macht jeden unter diesem Keyset versiegelten Token unlesbar.
• Löschung ist kryptografisch: Kein Hintergrundjob durchsucht abgelaufene Zeilen. Stattdessen ruft der Betreiber (oder der Mandant über die API) POST /v1/pii/shred mit dem Client-Hash eines Bezeichners auf. Der Dienst findet die Identität, setzt ihren gewrappten Schlüssel auf NULL und veröffentlicht eine Eviction auf Redis Pub/Sub. Vorhandene Tokens werden beim Öffnen zu [ERASED_<TYPE>], und die Beweiskette zeigt ein PII_SHREDDED-Ereignis, das belegt, wann die Löschung erfolgte.

Löschverzögerung: Wann sind Daten tatsächlich nicht wiederherstellbar?

Nur-Vorwärts-Umstellung; Aufzeichnungen sind ausgeschlossen

• Umstellung: Ab dieser Version ist die Verschlüsselung für neue Anrufe standardmäßig aktiviert und alle erkannten Spans werden verschlüsselt. Anrufe, die vor dieser Version gestartet wurden, können Klartext-Spans in ihren Beweisen enthalten (diese Zeilen sind in die Kette gehasht und können nicht bearbeitet werden); sie können nicht nachträglich verschlüsselt werden.
• Aufzeichnungen: Audioaufzeichnungen werden in S3 mit SSE-S3-Verschlüsselung und Versionierung gespeichert, gestützt durch eine 7-tägige Lifecycle-Sperre und separate Aufbewahrungsrichtlinien. Sie sind nicht durch Krypto-Shredding in dieser Version abgedeckt; die Löschung der Identität eines Anrufers löscht die Aufzeichnung nicht. Dies wird für einen zukünftigen Meilenstein verfolgt.
• Namen: Namensidentitäten existieren nur, wenn der Mandant sie als Hashes bei der Anrufinitiierung oder über die Identity-Link-API bereitstellt. Im Gespräch gesprochene Namen werden nicht automatisch erkannt, sodass eine Namenslöschung schwächer ist als eine E-Mail-/Telefonlöschung — sie löscht nur die Identitäten, die der Mandant registriert hat, nicht jede Erwähnung im Anruf. Die API-Dokumentation behandelt diese Einschränkung.

Krypto-Shredding liefert sofortige Löschung; Aufzeichnungen sind separat

Ab dieser Version ist Krypto-Shredding der primäre DSGVO-Artikel-17-Löschmechanismus für PII in Beweisen. Es erreicht die Löschung sofort:

• Der Mandant (oder Betreiber) ruft POST /v1/pii/shred mit dem Client-Hash eines Bezeichners auf.
• Der Dienst findet die Identität, setzt ihren gewrappten Schlüssel auf NULL und veröffentlicht eine Eviction auf Redis Pub/Sub.
• Innerhalb von 60 Sekunden werden vorhandene Tokens, die unter dieser Identität verschlüsselt sind, unlesbar.
• Ein [ERASED_<TYPE>]-Platzhalter wird bei jedem nachfolgenden Entschlüsselungsversuch zurückgegeben, und die Beweiskette zeigt ein PII_SHREDDED-Ereignis.

Aufzeichnungen bleiben ein separates Thema, das für einen zukünftigen Meilenstein verfolgt wird:

• Anrufaufzeichnungen (Audiodateien in S3) sind durch diesen Meilenstein nicht abgedeckt.
• Sie werden mit SSE-S3-Verschlüsselung und Versionierung gespeichert, gestützt durch eine 7-tägige Lifecycle-Sperre und separate Aufbewahrungsrichtlinien.
• Die Löschung der Identität eines Anrufers löscht die Aufzeichnung nicht.
• Eine zukünftige Version wird implementieren:
  • Ein Runbook für die Out-of-Band-Aufzeichnungslöschung.
  • Mögliche zukünftige Integration des Aufzeichnungs-Lifecycles mit dem Identity-Shredding (erfordert Architekturentscheidungen zur Speicher-I/O).