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

Question

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?

Answer 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.

Answer 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.

Answer 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).

Answer 4

The points Evan brought up are one of the reasons sysadmins get such heavy background checks at my job. Everyone ultimately has to trust their data to us, and each has their own requirements for 'trust'. On some systems it is possible to lock out the sysadmin, but Windows is not such a system.

There are some things you can do at the application level to obfuscate your data from nosy sysadmins, such as using tables with encrypted data in them. That relies on having the encryption keys and the data in different sysadmin-domains though, otherwise there isn't much point. An example of this would be a Tomcat/PHP application running on a Linux server, and under the ageis of the Linux sysadmins, with the database in MS-SQL, under the ageis of the Microsoft sysadmins. Presuming the Linux/MS admins don't collude, the data is less likely to be snooped into.

Answer 5

You can deny the administrator access to anything you want. Administrator simply has, by default, rights over just about everything. What you can't remove (at least I've never done it- it might atually be possible but I wouldn't recommend it) is the abilty for the administrator to take ownership of the files in question and read them- however, that's auditable and irreversable- there's no grant ownership power.

administrator is a special account but it is not equivalent to root on a unix box. This is as common misconception.

You can also use the file classification infrastructure in a month or so when 2008 R2 comes out.

Answer 6

Most mainstream operating systems (Linux, Windows, Mac OS X) cannot do this directly. There is always an account that may do everything on the system (Administrator, or root), and this account is necessary for many administrative tasks. No way around it, really.

To make this possible, you need something like a Multi-level secure OS, or one that supports Mandatory access controls. Something like SELinux, or Trusted Solaris, or Mandatory Integrity Control under Windows Vista.

Still, this is very complex to set up, and may cause compatibility problems with apps that were not written with the restrictions in mind. And ultimately someone will still have to have access to change security settings.

So while it is technically possible, you should carefully evaluate whether it is worth the extra complications and expenses.

Answer 7

Access the payroll from designated workstations that the particular admin does not have any rights or physical access to.

Encrypt/Decrypt the data client side so when it arrives/leaves the server, it is always encrypted. It is only unencrypted at the client end and then only when the user provides the proper passphrase or keys.

Build a client program that encrypts the data before sending it off or copy the code from the OpenSource ClipperZ password management project. ClipperZ uses javascript to do this encryption in the browser. Needless to say, only use a very locked down selinux sandboxed webbrowser with a firefox profile specifically setup just for payroll. Not email. Nothing else.

You may even consider still having the server encrypt it to mitigate some forms of client side rootkits - especially a man-in-the-browser.