Gegevensbewaring en de alleen-toevoegen-bewijsketen

De alleen-toevoegen-bewijsketen en een AVG-conform inhoudsverwijderingsschema zijn niet in tegenspraak, omdat de keten van begin af aan geen verwijderbare inhoud opslaat.

Span-versleuteling vervangt redactie; de keten blijft alleen-toevoegen

• evidence_events is echt alleen-toevoegen, afgedwongen op databaseniveau, niet alleen door applicatiecode: databaseregels maken UPDATE/DELETE op de tabel tot no-ops, en een trigger controleert bij elke invoeging de previous_hash van de nieuwe rij tegen de hash van de vorige rij (hash-ketensintegriteit, gecontroleerd op het moment van schrijven).
• Persoonsgegevens-spans worden versleuteld, niet geredigeerd. Elke span die door de pii_scan-detectoren wordt gedetecteerd (BSN, IBAN, kaart, e-mail, telefoon, geboortedatum, postadres) wordt in opgeslagen kopieën vervangen door een token ⟦pii:v1:<TYPE>:<keyset_id>:<base64url(nonce‖ciphertext‖tag)>⟧, waarbij de omliggende tekst leesbaar blijft. De tokens worden voor het hashen en schrijven van de gebeurtenis verzegeld, zodat het cijfertekst-token deel uitmaakt van de gehashte bewijsgegevens.
• Bewijs-samenvattingen registreren welk patroon/welke frase overeenkwam en kunnen het token weergeven (dashboards tonen [Encrypted Email]-chips); de ruwe transcriptie of frasetekst wordt nooit in platte tekst meegedragen.
• Gevolg: verwijdering vereist nooit het aanraken van een enkele evidence_events-rij. De beheerder shred een gegevenssleutel via POST /v1/pii/shred of POST /v1/calls/{id}/pii/shred, en bestaande tokens worden onleesbaar zonder wijziging. De hash-keten en de Merkle/RFC-3161-tijdstempelankering die erop is gebouwd, blijven intact en manipulatie-aantoonbaar, ongeacht of de sleutels aanwezig zijn.

Identiteiten en sleutelmateriaal worden verpakt opgeslagen; alleen tokens worden in bewijs opgeslagen

• Identiteiten: Elke afzonderlijke klartekstwaarde (een naam, e-mail, telefoonnummer) wordt bijgehouden als een afzonderlijke identiteit in pii_identities, met een eigen willekeurige 32-byte gegevenssleutel. De klartekstwaarde zelf wordt nooit opgeslagen of gelogd — alleen de lookup (HMAC-SHA256 van het type en de client-hash) wordt opgeslagen, zodat de tenant deze kan vinden zonder klartekst.
• Sleutel-wrapping: Gegevenssleutels worden verpakt met de K_wrap van de tenant (uit het sleutelhanger van de tenant in Secrets Manager) met behulp van AES-256-GCM, voordat ze worden geschreven naar pii_identities.wrapped_key. De verpakte sleutel kan alleen door de tenant worden ontsleuteld; het shredden van een identiteit stelt de verpakte sleutel op NULL, waardoor de gegevens van de identiteit permanent ontoegankelijk worden.
• Keysets: Tokens worden verzegeld onder inhoudssleutels die zijn afgeleid van de identiteiten die bij de oproep betrokken zijn. Elke afzonderlijke reeks identiteiten krijgt een korte keyset_id in pii_keysets. Het shredden van een van de identiteiten in een keyset maakt elk token dat onder dat keyset is verzegeld onleesbaar.
• Verwijdering is cryptografisch: Geen achtergrondtaak doorzoekt verlopen rijen. In plaats daarvan roept de beheerder (of de tenant via de API) POST /v1/pii/shred aan met de client-hash van een identifier. De service vindt de identiteit, stelt de verpakte sleutel op NULL en publiceert een eviction op Redis pub/sub. Bestaande tokens worden [ERASED_<TYPE>] wanneer ze worden geopend, en de bewijsketen toont een PII_SHREDDED-gebeurtenis die aantoont wanneer de verwijdering plaatsvond.

Verwijderingsvertraging: wanneer zijn gegevens daadwerkelijk onherstelbaar?

Alleen-voorwaartse overgang; opnamen zijn uitgesloten

• Overgang: Vanaf deze release is versleuteling standaard ingeschakeld voor nieuwe oproepen en worden alle gedetecteerde spans versleuteld. Oproepen gestart voor deze release kunnen klartekst-spans bevatten in hun bewijs (die rijen zijn in de keten gehasht en kunnen niet worden bewerkt); ze kunnen niet achteraf worden versleuteld.
• Opnamen: Audio-opnamen worden opgeslagen in S3 met SSE-S3-versleuteling en versiebeheer, ondersteund door een 7-daagse lifecycle-vergrendeling en afzonderlijk bewaarbeleid. Ze zijn niet gedekt door cryptoshredding in deze release; verwijdering van de identiteit van een beller verwijdert de opname niet. Dit wordt bijgehouden voor een toekomstige mijlpaal.
• Namen: Naamidentiteiten bestaan alleen als de tenant ze als hashes aanlevert bij het initialiseren van de oproep of via de identity-link-API. Namen die in een gesprek worden gesproken, worden niet automatisch gedetecteerd, zodat een naamverwijdering zwakker is dan een e-mail-/telefoonverwijdering — het verwijdert alleen de identiteiten die de tenant heeft geregistreerd, niet elke vermelding in de oproep. De API-documentatie behandelt deze beperking.

Cryptoshredding levert onmiddellijke verwijdering; opnamen zijn apart

Vanaf deze release is cryptoshredding het primaire AVG-artikel-17-verwijderingsmechanisme voor PII in bewijs. Het bereikt verwijdering onmiddellijk:

• De tenant (of beheerder) roept POST /v1/pii/shred aan met de client-hash van een identifier.
• De service vindt de identiteit, stelt de verpakte sleutel op NULL en publiceert een eviction op Redis pub/sub.
• Binnen 60 seconden worden bestaande tokens die onder die identiteit zijn versleuteld onleesbaar.
• Een [ERASED_<TYPE>]-plaatshouder wordt geretourneerd bij elke volgende ontsleutelingspoging, en de bewijsketen toont een PII_SHREDDED-gebeurtenis.

Opnamen blijven een afzonderlijk vraagstuk dat voor een toekomstige mijlpaal wordt bijgehouden:

• Oproepopnamen (audiobestanden in S3) zijn niet gedekt door deze mijlpaal.
• Ze worden opgeslagen met SSE-S3-versleuteling en versiebeheer, ondersteund door een 7-daagse lifecycle-vergrendeling en afzonderlijk bewaarbeleid.
• Verwijdering van de identiteit van een beller verwijdert de opname niet.
• Een toekomstige release zal implementeren:
  • Een runbook voor out-of-band verwijdering van opnamen.
  • Mogelijke toekomstige integratie van de opname-lifecycle met identity-shredding (vereist architectuurkeuzes voor opslag-I/O).