How can I prevent that a server admin can see data?

I am running Apache Tomcat on a Windows 2003 Server and I have data stored in a mySQL database.

How can I prevent that a server admin can see any data?

Solution 1:

You can't, really.

The "Administrator" user on a Windows machine has complete control of that machine. That's "how it is".

Someone will probably suggest you encrypt the data in the database. Assuming that the keys for that encryption are located somewhere on that computer (since you'll wnat the application to have acess to them) the "Administrator" can just take that key and decrypt the data.

Someone else will suggest that you use some kind of file permissions. That won't work either-- the "Administrator" can just change them.

If you can't give your "Administrator" user a limited account with which they can accomplish all their day-to-day activities but otherwise is not an "Administrator", the only answer is "don't store that kind of data there". Any "answer" that involves the "Administrator" user retaining their "Administrator" rights won't give you any real protection.

An Edit for JimB's sake:

JimB left a few comments that I think deserve a longer response than I can give in a comment, so I'm dropping an edit on here.

I answered the poster's question w/ technical accuracy w/ respect to the privileges granted to the Windows "Administrators" group. The poster is certainly free to spend all the time he wants "tweaking" the default security permissions in the operating system to attempt to either (a) strip the "Administrators" group of the root-equivalent privileges (which, I would expect, Microsoft would tell you not to do) or (b) create a lesser-privileged group that could perform all the necessary day-to-day server administration functions but would not otherwise be an "Administrator".

Unless the poster's "server admin" needs are very basic, I would guess that the poster is going to end up getting into uncharted and undocumented territory.

Maybe the poster needs a "server admin" that can perform only very basic operations to the server computer and the "Administrator" password can be set to an arbitrarily complex string and stored in a locked safe. That's one possible strategy, if the poster's business requirements re: a "server admin" allow such a thing.

If the poster's requirements are more complex, I would expect that a LOT of ACLs (in the filesystem, registry, global object manager, and service control manager, at least) would need to be changed to accomodate giving a non-"Administrators" group member a close approximation of the abilities of an "Administrators" group member. The poster would also lose the utility of the well-known BUILTIN\Administrators SID, too.

I would be shocked if there aren't some assumptions running pretty deeply into the Windows NT OS about the out-of-the-box privileges assigned to members of the "Administrators" group. Attempting to take away privileges from the BUILTIN\Administrators group is, to my mind, asking for instability and problems with the OS.

I've not made any statements about "business policy" enforcing security. I don't know what JimB got out of my post or comments that gave him that idea. Business policy can't change the way that code works, and all my statements relate to how code works.

Auditing that a breach occurred doesn't mitigate that the breach occurred. You can know that someone breached confidentiality, but no auditing mechanism can tell you how many or few copies of the confidential bits were made after confidentiality was breached. It's boolean-- either confidentiality has been breached or it hasn't. Auditing can tell you that, and nothing more.

A business can attempt to "enforce security" in all the "business policy" that they would like, but unless that "business policy" is congruous with how the code, and reality, operates it's really pretty meaningless.

Solution 2:

The above, but I'd add that an unethical administrator is worth nothing. If you don't trust your sysadmin not to peek (except as required to complete his duties), then you really need to find a replacement.

Solution 3:

In general, you can make it so Administrative accounts can not do things, but the Administrators can generally enable it so they can.

For instance, you can deny read access to a directory for the user Administrator, but the administrator could give themselves access again if they wanted.

So with this, I think you can (but not sure) , just deny read access to said databases by editing the MySQL privileges for the root user in the MySQL database. But this isn't real security. Or, you can not give the administrator any of the passwords of MySQL, but they can probably find a way to view the data if they have access to the server (or even reset the root password).