3 ms·
Regarding backups: what is your suggestion for backups of databases that contain individual rows that might need to be deleted?
by areyousure 6y ago
Regarding backups: what is your suggestion for backups of databases that contain individual rows that might need to be deleted?
- jacquesm 6y agoYou have several options, none of them pretty. The first is to load, update and rewrite the backup. Time consuming, error prone and you may fuck up the backup that you need. The second starts way further back: encrypt sensitive fields at rest, drop the keys when the user requests a deletion. That way you never even have to touch the backups in order to have the right end result.
- areyousure 6y agoSo you have per-row or perhaps per-user keys? Do you back them up?
- jacquesm 6y agoNot currently running a user visible service. Fortunately. The one I did run was started in 1998 and had turned into a very large pile of super insecure PHP and was shut down. If I were to start a user visible service today I would think really long and hard about whether or not the kind of superstructure required would be offset by the potential gains. The web is no longer a place for amateur projects with a focus on the happy path, you need to do it all 'just so' or you can expect to be compromised. And doing it right isn't simple nor is it cheap.
- areyousure 6y agoSorry, what I meant was to clarify your proposal, not to ask what you literally do now. I'm wondering, more or less, whether the key management is another case of backups and deletion being hard.
- jacquesm 6y agoAh, apologies. Key management is indeed just another - hopefully simpler - version of the same problem. The reason why it simplifies things is because a single key can invalidate a lot of data stored in places that are out of reach such as cold backups. But you still have the same essential problem.