From: | Steve Midgley <science(at)misuse(dot)org> |
---|---|
To: | Jason Aleski <jason(dot)aleski(at)gmail(dot)com> |
Cc: | postgres list <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Replication and Field Level Encryption |
Date: | 2017-08-10 22:11:30 |
Message-ID: | CAJexoS+FFnLiYucoBk8WWuR45oUY-tzvJPBCvn5P+0PfFco+2g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Aug 10, 2017 10:07 AM, "Jason Aleski" <jason(dot)aleski(at)gmail(dot)com> wrote:
1. Should the encryption and decryption be at the client or server?
1. Advantage to the client
1. Data is secured end-to-end
2. Disadvantage
1. Managing application changes during security key changes.
3. Advantage to the server
1. Consolidates programming logic and reduces the encryption
process on the client
4. Disadvantage to the server
1. Data relies on communications SSL/TLS for encryption
Any thoughts or items I should also consider?
If I were building this I'd put a middle tier api layer between the sql
server and the various clients. I think you'll get more expressiveness in
the api design and therefore even dumber clients (a good goal). You should
also have an easier time building a test harness and all the tests you'll
want.
You'd abstract the encryption and similar stuff into the api, and it can
either be handled there are delegated down to postgres (and as you point
out you can change your strategy over time).
Getting the api design right is an important early goal for the project.
That and quality tests..
Common middle tier api options are ruby, python, node.js, and Java.
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan Moules | 2017-08-11 13:57:39 | Always getting back a row, even with no results |
Previous Message | Jason Aleski | 2017-08-10 17:04:41 | Replication and Field Level Encryption |