It comes down to physical access (in the sense as they can log into the box as root) - if you value security someone (single or "multiple person user") must be able to log in as root. Someone must be able to access the data hardware that contains the data, otherwise you'll might as well not store it and save the headache. Once you have admins with the ability to be root on the box, they can get the data. There is no way around it. What you can (and should do) is have access logs saved at least at one location where noone can delete anything. I suppose you could encrypt the data and save the key on a dedicated tamperproof box (are IBM still the main provider of these?), but someone must manage this box. Trust is inevitable, at best you can divide it in such a way that the combined entity is unlikely to go rogue.
It's actually more complex than that. One of the things that really gets in the way of encrypted storage, when you think about it, is the reality that key management involves tradeoffs too. For example, we could divide things up that you could get the encryption key only on a separate system and so only a public key and the public key encrypted symmetric key are stored. In this model you only get either symmetric key-encrypted data, or the public key-encrypted symmetric key.
The problem though is that someone still has to have the right to rotate keys and this process can be attacked too. For example, one could rotate keys to a known value thus giving the attacker access to the plain text. Worse, the person who can rotate the keys has to have the right to access both old and new keys in an unencrypted state.
Now, given that reality, it isn't clear to me that the fact that someone could set up the database to log all queries, and allowing passphrases for encryption to be passed in in the query poses a real added danger.
Another option is just not to allow key rotation but that allows for attacks on the key itself. You can get aroudn this by having a different key for each piece of data and thus limit the utility of cracking each piece.
However if you go that route, then you have two computers to secure instead of one, and it is vulnerable to more types of attacks than before since you are now trusting the client.....
You hint at it: There are certainly ways to spread the trust. Require a physical key to allow root logins, and keep it in a monitored safe in the data centre. Require logs of who pulls the key, and entrust access to that physical key only to a separate group of people from those with the root passwords.
Of course the problem is that methods like this takes a lot of effort, and so it is a tradeoff between safety and the cost and convenience, and in reality very little data.
