3 ms·
How does this work in practice? If each customers data has a unique encryption key, then how do you do SQL joins ?
by sandGorgon 9y ago
How does this work in practice? If each customers data has a unique encryption key, then how do you do SQL joins ?
- whalesalad 9y agoIt’s pretty straightforward: you don’t encrypt the data necessary for a join. Data for a join, ie foreign keys, are used to inform your structure. They aren’t really data a person owns... they just describe how that data (theirs) fits into your database (yours).
- PeterisP 9y agoYou'd still need to decrypt the whole table to do e.g. aggregation. For example, a customer's address is private information; statistics about how many customers come from each town/region is not, but calculating a simple "select town, count(*) from x group by town" requires decrypting every address.
- leifg 9y agoyou can store whatever you want unencrypted on the read model. That‘s the place where you do joins/aggregation anyway.
- DelightOne 9y ago> you can store whatever you want unencrypted on the read model. So to recap correct me if I’m wrong: You store everything encrypted. You have an api on it which hides the encryption and shows everything unencrypted. On the unencrypted api you do joins/aggregations. RightToBeForgotten then means delete its decryption key and remove it from the in-memory api. Right?
- xyzzy_plugh 9y agoYou can always join on decrypt(key, a.column) = decrypt(key,b.column).