On Fri, Apr 17, 2009 at 10:33:15AM -0400, Bill Moran wrote: > The goal is not to trust any one part of the system. > As a result, we can protect the data across multiple security failures. As far as I know this isn't a good way to go about designing secure systems. You're better off defining a set of plausible attack vectors and design the system so it's not vulnerable to them. > 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. OK, so there would be two vectors here, each entity would have their own secret they use the encrypt the backup. Breaking the backup requires the collusion (remember security is normally much easier to break from the inside) or compromise of both entities. The question then becomes what happens with the backup before it's been encrypted by both entities and how can you ensure that one can't compromise the entire system? Your trust would therefore be that at most one entity will be compromised. Once you've said that you can ask yourself whether this is appropriate. Saying that you're encrypting data twice is, from a security perspective, vacuous because you're leaving open the possibility of encrypting it twice in series on the same server and hence an attacker just needs to compromise that one server to recover both keys and break the system. If you're defining this single server as trusted then you're assuming you're capable of protecting this server from attacks. Other definitions would partition the server into parts (say different user accounts, and then you need to worry about privilege escalation) and say that some parts are trusted. The "root" user is by definition a trusted entity in any Unix system; Microsoft tried to break this assumption in Windows but I think they gave up in the end. The "root" user will normally carry more authority[1] than normal users, but it should not need absolute authority as is does in conventional operating systems. > 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. OK, but more definitions are required to understand what you mean by this statement. You don't need to send them all here, but if I was designing something similar to what you are I'd want to know what I was up against. > 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. I, personally, wouldn't recommend doing things this way. I'd define where you put your trust and design around that. You'll get a much stronger system and you'll know where to invest time in protecting it because you know what you trust and if those items are compromised everything falls down. If you don't know what you're trusting you don't know where to expend the effort. > 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. Yes, that sounds reasonable and to be expected. Hope that's all somewhat helpful! -- Sam http://samason.me.uk/ [1] I'm using "authority" in a technical sense meaning the set of actions that an entity can directly, or indirectly by talking to other actor in the system, cause to occur. Strictly speaking from a security perspective there is no difference between a normal user and root in UNIX system because of the presence of various privilege escalating mechanisms (i.e. set suid bit on executables). In practise it's OK, but not safe, to assume that the system is configured in a way that this doesn't occur and any occurrences are "bugs". -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
