it does further restrict who can access data which is good and it seems to come at a serious cost in complexity. if your db admin is bleeding company data i think your problems are just beginning...
it does further restrict who can access data which is good and it seems to come at a serious cost in complexity. if your db admin is bleeding company data i think your problems are just beginning...
Right now, if you want to store sensitive data, you basically have to do it all in-house, which costs big money (think of all the PCI regulations you have to satisfy and auditors that you need to pacify).
This doesn't just defend the data from unscrupulous sysadmins, it also defends data from hackers who manage to gain access and run a mysqldump.
My understanding is that CryptDB offers no protection from attackers who sit between the proxy and the web server. Obviously the web server (or other client) must deal with plaintext, otherwise application software would require changes. The authors of CryptDB assert in no uncertain terms that this is a drop in solution that requires zero application changes, therefore the proxy must do all the work.
The idea is to run the proxy on a different machine than the database, thus allowing the maintenance of the database server's hardware, OS, and RDBMS software to be outsourced without providing access to your data. No amount of monitoring of traffic between the proxy and the RDBMS should matter.
The weakest part of this system is that is appears to store the data in the database with different types of encryption that allow for various operations to be performed on the cipher text. I think that anyone who controls the database system can obtain some of the weaker cipher texts of the data and possibly break them.
I really can't be sure until I test it out... I'm kinda disappointed that it doesn't come with quick instructions to get it going on postgres.