In response to Sam Mason <sam@xxxxxxxxxxxxx>: > > > As far as the trust factor, you've blurred the lines a bit. My job > > is to ensure that the user doesn't know or care about the lines between > > application and database, but trusts the system as a whole. However, > > I need to clearly define those lines and ensure that each part of > > the whole has enough security measures to withstand a flaw in one > > of the other parts. Think of the design of postfix, where each > > program (smtpd, qmgr, etc) doesn't trust the input of the other > > programs and runs in its own sandbox. > > Sorry; my example of where to place trust was a bad one, lets try some > other ones: > > The Postgres process; do you trust that the database engine is secure? > This implies that the frontend program can send the user's secret to the > database engine and the decryption will be done "inside" the database. > I believe this to be the case, otherwise for the user to query on SSN, > to pick an example you were using before, you would need to send *every* > encrypted SSN to the client where they would decrypt it with their secret > to find the one they wanted. > > Backups; you mentioned that if someone stole the backups they shouldn't > be able to get any more information than if they were using the client > interface. If every sensitive field is encrypted then you're protected > against some attacks, but you'd be better encrypting the backup. Where > is it OK to place the trust here? Nowhere, really. The goal is not to trust any one part of the system. As a result, we can protect the data across multiple security failures. For example, backups will actually be encrypted twice. In order to recover data from our backups, an attacker would have to physically acquire a tape, then steal or brute-force 2 different encryption keys before they could access the data. In the end, the only person that should be trusted with the data are the users who own the data. That person will explicitly grant access to their data to program administrators, the software will simply facilitate the process. We put as many layers as we can everywhere. Usually this is limited when we start hitting performance issues and have to remove a layer to keep performance where it needs to be. The goal is to have as many layers as possible while keeping the system as performant as the client expects. We only get one shot at this. If there's a data leak, a lot of people are going to be very upset and we're going to be out of business, so we're implementing the tightest security possible at every layer. This thread is only one part of the overall process as it specifically relates to the database layer. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
