Procesbeschrijving
Het proces start bij aanvoer van plandata in Azure Storage.
Per leverancier bestaat een datacontainer met de segmenten PlanData, PII en Config, en een aparte auditcontainer met onveranderbare opslag.
De intake schrijft het plan naar PlanData onder het pad met planId en status actief, zet verplichte metadata zoals planId, leverancier, status en createdAt, en plaatst het object in Hot tier. De intake schrijft het contactrecord naar PII onder een JHASH sleutel, registreert sleutelversie en classificatie, en schermt toegang via strengere rollen. De Change Feed registreert beide creaties, de auditcontainer ontvangt een leesbaar snapshot met etag, access tier en een verwijzing naar de feedpositie.
Storage Tasks lezen de parameters uit Config, bevestigen actief in Hot en bewaken status en tier op consistentie. Een soft delete verzoek of een delta zonder plan triggert de overgang naar onzichtbaar. De taak hernoemt het pad van actief naar onzichtbaar, schrijft deletedAt, verwijdert de JHASH verwijzing uit het plan, zet de tier naar Cold en markeert het PII record als onzichtbaar in Cold. De auditcontainer slaat een nieuw snapshot op en koppelt dit aan de Change Feed. Guard controles rapporteren afwijkingen, bijvoorbeeld status onzichtbaar met een warme tier.
De retentie voor onzichtbaar loopt volgens containerconfiguratie. Na afloop selecteert de archiverings taak alle plannen met status onzichtbaar die ouder zijn dan de ingestelde termijn. De taak zet status op archief, schrijft archivedAt, wijzigt de tier naar Archive en verwijdert het PII record op JHASH. De auditcontainer legt de uitvoering vast, inclusief aantallen en eventuele uitzonderingen, en sluit de batch af met een ondertekende samenvatting. De plandata blijft beschikbaar voor zeldzame inzage, rehydraties verlopen gecontroleerd en tijdelijk, en krijgen een eigen auditrecord.
De vernietigings fase adresseert archiefobjecten die de archieftermijn overschrijden. De purge taak verwijdert het object inclusief versies, ruimt verwijzingen in indexlagen op en schrijft per object een vernietigingsrecord met reden en tijdstempel. De auditcontainer bewaart deze records onder een vergrendelde retentie, de Change Feed blijft het technische feitenarchief. Beveiliging dwingt private endpoints en least privilege af, encryptie gebruikt sleutels in Key Vault, diagnostiek stroomt naar Log Analytics, alerts signaleren mislukte runs, policywijzigingen en inconsistenties tussen status en tier.
Zo levert de opslaglaag zelf statusgestuurde retentie, scheiding van persoonsgegevens, aantoonbare auditsporen en een gecontroleerde route van aanvoer naar onherroepelijke vernietiging.