Use Case: PII Personal Identifiable Information - Right to be Forgotten - Prisma Encryption

[D1no]

Hi, thank you for creating this library! I would like to provide GDPR / „right to be forgotten“ assurance while keeping schema flexibility. One way for that is pseudomization where each user has an assigned description key; when that is deleted, all data of that user is useless but doesn’t require propagating deletes.

I was wondering how you would handle that architecture and if prisma-field-encryption would be a valid solution approach. Naturally I‘d try to push this further down to DB level (i.e. the with the PostgreSOL Anonymizer) but that seems to take flexibility out schema management (requiring raw queries?).

I‘m in the concept phase, everything should be azure and end-to-end typescript. Regarding stack, prisma & co still investigating.

Thank you very much!

PS: A data science team needs to also be able to access encrypted information without going through the GraphQL API. So being able to decrypt data outside of prisma-field-encryption is useful and seems to be already on the map when reading this #12 (comment)

[franky47]

Correct me if I'm wrong, but wouldn't "right to be forgotten" require deleting the PII data itself? Unless there are legal reasons to keep that data outside of its relationship-based context.

In any case, this library uses symmetric encryption, and assumes the application owner has the keys, so for this use-case it does not do much for GDPR, it mostly prevents the database provider from unwanted access.

You can access the encrypted data with any SQL client (even Prisma without this middleware, as it will return the ciphertext as-stored), and feed it through @47ng/cloak for decryption.

[D1no]

Correct me if I'm wrong, but wouldn't "right to be forgotten" require deleting the PII data itself?

No. Pseudomization is per EU regulation is enough; meaning it is deleted if it's not accessible by deleting the associated key. However, this only applies if the data has always been treated like that. You can't store data in plain text and when a request comes in, encrypt it, create a cypher and delete the cypher. In this case: you own the key, data has always been encrypted with that, but you need to delete the key up-on request.

So back to tech 😄

Alright. So this is an option. I'm currently thinking of creating user specific keys in middle service that integrates with cerbos as a sidecar to prisma instances. Tough topic navigating requirements to backup a ton of data and at the same time make it all deletable. Well done politics.

[franky47]

I see, so if you were to use one key per row, and delete that key, you'd essentially end up with unreadable data for the PII fields, while preserving metadata (cleartext columns and foreign key connections).

This library does not provide this out of the box (it uses a single key for all encryption operations), but we're working on adding the ability to do custom ciphers in #23, which could be an entry point for your use-case.

I suppose it would need to provide context data to the cipher function to guide key management.