Verwijderen van klantgegevens, hoe omgaan met backups?

[Haan]

Dit is simpel gezegd de situatie: er is een multi-tenant cloudapplicatie, waarbij meerdere gebruikers (tenants) dezelfde SQL database delen. Aangevuld met data die in blobs is opgeslagen.
Deze applicatie bestaat nu een paar jaar en nu begint het moment te komen dat sommige gebruikers met deze applicatie stoppen en hun data verwijderd willen hebben.

Opzich niet heel lastig zou je zeggen, blobs verwijderen, SQL data verwijderen en klaar is kees. Maar, zoals de titel al zegt, hoe ga je om met backups? Wij maken gebruiken van SQL Azure, dat automatisch 30 dagen point-in-time restore biedt, en ook de blobs worden dagelijks gebackupt.

Ik ben dus benieuwd naar eventuele ervaringen van anderen op dit gebied. Laat je de backups gewoon voor wat ze zijn, of ga je daar ook data uit verwijderen, en zo ja, hoe dan?

[BoAC]

Deze vraag is toch alleen relevant wanneer een restore van die backup plaats vindt.
De oplossing is denk ik loggen welke gebruikers verwijderd moeten zijn en bij restore die gebruikers alsnog verwijderen uit die backup.
Hoe doe je dat trouwens met andere wijzigingen die na backup plaats vinden?

[ Voor 15% gewijzigd door BoAC op 22-03-2017 13:09 ]

[Gerco]

@BoAC Er zijn wettelijke eisen voor het verwijderen van klanten data en die zijn verschillend voor natuurlijke personen en voor bedrijven. Het zal er dus van af hangen wat voor klanten dit zijn en welke wetten daarvoor opgaan.

Volgens Arnoud Engelfriet lijkt het erop dat je backups evengoed moet verwijderen op grond van de Wet Bescherming Persoonsgegevens.

Nu is het natuurlijk wel zo dat je een redelijke termijn mag hanteren voor het verwijderen van die data. Als je backups maximaal 30 dagen oud zijn kun je je klanten vertellen dat hun data na 30 dagen verwijderd zal zijn. Mijns inziens is dat een redelijke termijn.

[ Voor 22% gewijzigd door Gerco op 22-03-2017 14:13 ]

[Haan]

Dat artikel van Arnoud had ik ook gelezen ja, veel meer is er over het onderwerp ook niet te vinden. De aard van de gegevens is overigens voor een groot deel privacy-gevoelig en het gaat voornamelijk om gegevens van derden (de gegevens van de klanten van onze gebruikers, die bij ons zijn opgeslagen). Onze gebruikers zijn altijd bedrijven (of zzp-ers), geen particulieren.

[chaoscontrol]

Wij hebben er toentertijd voor gekozen om het niet multitenant te doen maar voor elke klant een eigen database op te spinnen, precies om o.a. deze reden.

[MeZZiN]

Je kan eigenlijk niet binnen AWS (en waarschijnlijk Azure) de backups niet manipuleren. Dus kan je deze feature eigenlijk niet gebruiken.
Of je moet de tijd dat je jezelf gunt om alles recht te trekken. Dus als iemand zijn account verwijderd dan haal je die direct weg uit de systemen en dan valt hij vanzelf uit de backups. Maar of dat mag is een ander verhaal.

Om een systeem om te zetten die alle backups maakt per dag. en dan deze in een instantie leest en dan de gegevens verwijderd en dan weer terug in de backup zet. Snap wel waarom een database per klant heel nuttig is. Maar dan nog als het op de dezelfde database machine staat heb je nog steeds het zelfde probleem omdat je hem niet uit de backups kan vissen.

Alternatief zou zijn dat je de oude data exporteert per klant naar een storage unit als archief en alleen maar backups houdt voor een aantal dagen voor technische issues.