0

I was wondering, how is crypto-shredding implemented in an environment, where data backups/mirroring is mandatory for the "key database" - as it must not be possible to lose the machine/db with all the keys and shred everything by accident :-).

I always get in my mental model to the point, where I delete the encryption key for the given entry...but it still exists in some kind of offline backup. Or is there a restriction that for crypto-shredding all replicas of the "key database" are online and the DB may not be snapshotted?

malejpavouk
  • 101
  • 2

1 Answers1

1

Crypto keys for database encryption are stored and backed up separately from the database itself. To read a backup, you'd need both the backup file itself and a copy of the key.

To crypto-shred the database backup, you would simply destroy any copies of the key and any backups of the key. Because the key backup is much smaller and changes much less frequently (and therefore has fewer backups), it is much simpler to delete the key than hunt down all the database backups and destroy them.

John Wu
  • 9,101
  • 1
  • 28
  • 39
  • my situation is a bit more complex, as I may have few millions of keys, as those will be used to be able to shred data, which needs to be encrypted with high granularity and there will be many thousand new keys a day... So I will essentially need a database of keys itself...and this is where it gets problematic, as this DB would need backups... – malejpavouk Nov 15 '18 at 21:57
  • Right, and this DB would have encrypted backups, right? You just need to delete the key for those and all the other keys will become inaccessible. – John Wu Nov 15 '18 at 22:04
  • I get the point, just trying to figure out, if there is some less painful approach. While this is possible, goal of this task is GDPR...so there may be quite a lot of delete operations. But yeah, it can be bulk deleted daily with process of: delete_keys -> new_backup -> shred_old_backup – malejpavouk Nov 15 '18 at 22:24