Re: Looking for advice on database encryption

> > Take the performance hit, If people on high want the data encrypted,
then
> > they have to suffer the performance penalty, however bad.
>
> As reasonable as that sounds, I don't think it's true. We've already
> brainstormed a dozen ways to work around the performance issue (creative
> hashing, backgrounding the decryption and using ajax to display the
> results as they're decrypted ...)
>
> Problem is that all of these methods complicate things in the
> application. I was hoping there were better approaches to the
> solution, but I'm starting to think that we're already on the
> right path.
>
> > Could you not write some server extensions to encrypt / decrypt the
data
> > server side, coupled with a custom index implementation?
>
> Not sure how the index implementation would work. The server-side
> encryption doesn't really help much ... it's difficult to add more
> DB servers in order to improve throughput, but adding more web
> servers fits easily into our load balanced setup. In any event,
> the addition of processing cores (not matter where) doesn't speed
> up the decryption of individual items, it only allows us to do more
> in parallel.

Move all DB calls to stored procedures, let the stored procedures handle
the encryption / decryption with a given key.
If your communication channels are secure then this is just as secure as
decrypting the data in the application.

This also allows DB's to be clustered, with the likes of PL/Proxy.

You could create a custom datatype to hold the encrypted data, then
functions to access it.

> > Can you use a global server side key or do you need fine grained
> > encryption?
> >
> > Is a database the correct tool for the job if you want this level of
> > encryption and granularity?

> The global side key puts us in pretty much the same situation that
> filesystem encryption does, which is not quite as strong as we're
> looking for.

> I've considered the possibility of using something other than the
> DB, but I can't think of any storage method that gains us anything over
> the DB. Also, if we use something different than the DB, we then have
> to come up with a way to replicated it to the backup datacenter. If
> we put the data in the DB, slony is already set up to take care of that.

File system, Leave the replication upto the SAN. Store your data in flat
files which are encrypted with each key, an Index per user etc.

>
> > Also, how secure are you communication channels, what stops me
snooping
> > the data in transit, ARP posioning and other techniques etc.
>
> We do what we can. Everything is transferred over HTTPS, and we log and
> monitor activity. We're constantly looking for ways to improve that
> side of things as well, but that's a discussion for a different forum.
>
> --
> Bill Moran
> http://www.potentialtech.com
> http://people.collaborativefusion.com/~wmoran/
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

******************************************************************************
If you are not the intended recipient of this email please do not send it on
to others, open any attachments or file the email locally.
Please inform the sender of the error and then delete the original email.
For more information, please refer to http://www.shropshire.gov.uk/privacy.nsf
******************************************************************************