Hacker News Reader

Comment by mschuster91 | Hacker News Reader

The problem with that is that under GDPR you have to support full deletion of an user's data.

Not necessarily if you have a valid reason to storing the data. You might for example have to keep user's billing data around for legal reasons.

Was this billing data though?

Crucially, you do not have to do it immediately.

Store customer data immutable and encrypted, with a unique AES encryption key per customer. Encrypt that AES key again with a single RSA key-pair and store the encrypted AES-key in a database.

You can access your customer data, using the customer-specific AES key. You can access the customer-specific AES key using your private RSA key.

When you need to delete the customer data under GDPR, you can delete the encrypted AES key for that customer from your database.

> Store customer data immutable and encrypted, with a unique AES encryption key per customer. Encrypt that AES key again with a single RSA key-pair and store the encrypted AES-key in a database.

Now you have the worst of both worlds. You also now have 2 points of failure where data can get lost, because if either has a problem you lose data.

I can't think of a mechanism where you can lose the customer's database records but can still recover files associated with that customer ...

Total systen compromise. The backup for the files worked. the ones for the DB didn't.

Right, but how to you figure which customers own which files? I don't label the assets FrankPJonesPortlandOregonUSA9095551212.jpg. If I've lost the database record I have no idea who owns cat_picture.jpg

Reply on news.ycombinator.com