Re:Deleting data distributed throughout a microservice archi...
by ijcd on Tuesday May 05, 2020 @09:53PM
(#23087198)
My favorite approach is encrypting all of a user’s data (everywhere) and just deleting the key from a central store instead of actually erasing.
[ Parent
| on HN ]
Re:Deleting data distributed throughout a microservice archi...
by noident on Tuesday May 05, 2020 @10:37PM
(#23087439)
Can you be certain that nobody has retained a copy of this key?
Re:Deleting data distributed throughout a microservice archi...
by ijcd on Wednesday May 06, 2020 @04:47AM
(#23089044)
Can’t be certain that no one has copied the unencrypted user’s data either.
Re:Deleting data distributed throughout a microservice archi...
by scollet on Thursday May 07, 2020 @04:11AM
(#23100849)
I don't know if this addresses the underlying issue.
Re:Deleting data distributed throughout a microservice archi...
by hangonhn on Tuesday May 05, 2020 @09:58PM
(#23087229)
I was about to suggest the exact same. It is literally what we do at my company. Of course you now have to them deal with searching and indexing. To mitigate this issue, we use UUIDs to reference users throughout our systems. Any fields that would link that UUID back to a real person or contain personal info is then kept encrypted. That way, we can still gather all the information from our various components but if we needed to, we can essentially make the user data unreabable.
Re:Deleting data distributed throughout a microservice archi...
by rrobukef on Wednesday May 06, 2020 @05:27AM
(#23089218)
Doesn't this still leak information? "A person known by these 5 people was in contact with the suicide hotline."
Re:Deleting data distributed throughout a microservice archi...
by Polylactic_acid on Wednesday May 06, 2020 @12:21AM
(#23087876)
Doesn't this leave you with a bunch of junk data taking up space?
Re:Deleting data distributed throughout a microservice archi...
by FridgeSeal on Wednesday May 06, 2020 @01:34AM
(#23088157)
What's the problem with actually just deleting this data when you're done with it though?
Re:Deleting data distributed throughout a microservice archi...
by vmateixeira on Wednesday May 06, 2020 @07:19AM
(#23089742)
Because FKs on a relational model.. as an example, deleting a user/account might end up being a task on going through every reference to it, and the references to its references, etc.
This is actually the reason some companies do not delete users/accounts [0].
Re:Deleting data distributed throughout a microservice archi...
by chrisacky on Wednesday May 06, 2020 @02:02PM
(#23094275)
One of our popular accounts has about 70M worth of rows. I can't imagine how we would go about deleting their data. We rotate out old data each month when it doesn't become needed, but maybe 40M records (4M new each month gets added).
Re:Deleting data distributed throughout a microservice archi...
by Xorlev on Wednesday May 06, 2020 @12:43AM
(#23087966)
Not all customers are cool with this approach.
Re:Deleting data distributed throughout a microservice archi...
by luckylion on Wednesday May 06, 2020 @03:35AM
(#23088702)
For regulatory reasons or because of "you didn't really delete it"? This is similar to deleting a file but not overwriting the space it occupied on the disk, isn't it? The data is still "there", but it's not accessible by normal means.
Re:Deleting data distributed throughout a microservice archi...
by evbpcapfxy on Wednesday May 06, 2020 @02:14AM
(#23088319)
Is that okay from a GDPR perspective? What if there's an exploit discovered in the implementation of the encryption? Or what if quantum computers can crack it easily in the future?
Re:Deleting data distributed throughout a microservice archi...
by rommel917 on Wednesday May 06, 2020 @03:34AM
(#23088695)
It is ok for GDPR, it is axon uses it in their commercial GDPR modul (better then our but same principale).
Broken encryption, 20 years better machines in future and quantum are solved with same trick. We have event sourcing.
Implement best current encryption, delete everything except event store, decrypt events with old encryption publish events and everything in now encrypted with best current encryption events in new store. Delete deprecated old event store. Skip aggregates with deleted old key.