3 ms·

This is very easy to work around. Associate each user with an encryption key and store in a separate database which backed up with some retention time. It shoul

This is very easy to work around. Associate each user with an encryption key and store in a separate database which backed up with some retention time. It shouldn't be huge so that's not a big problem. Encrypt all data related to the user with this key. When you make a backup, this data is stored in the same encrypted form. When you delete user, just delete his record together with this key. After this the user's data is virtually irretrievable and for all practical purposes is deleted.

will_hughes 9y ago
Unless I'm misreading you, you've just created a more complicated version of things. How do you delete the immutably backed up keys? You've gone from: backup.bak to backup-encrypted.bak and backup-keys.bak
- yorwba 9y ago
  Obviously, you can't keep insisting on immutable backups. Instead, you'll have to modify a single key in the backup file to become invalid. This does make your backups slightly less reliable, because it's one more thing that touches them, but if you do a sane implementation and exhaustively test it, the risk is manageable. I'm also not sure you really need to keep that many backups of this file. Replicate it and make sure you can roll back when your replication is borked, but if you really need to restore your database from months ago, using a newer list of encryption keys shouldn't be a problem.