September 19, 2003 at 7:02 am
We've got one of these "HR versus IT" meetings brewing where HR are demanding that ALL IT personnel be excluded from accessing the HR SQL server. As an interim measure we are proposing:
Remove the server from the domain and add to it's own workgroup.
Remove the BUILTIN\Administrators group.
Allow HR to control the local server passwords.
I assume this would achieve the objective of keeping IT staff off this server? Even with the domain admin password we wouldn't be able to authenticate, correct? And as we can't log on locally as HR hold the passwords we wouldn't be able to add ourselves back into the database?
Ignoring for the moment all the issues around, server support, sql support, access to backup tapes and the whole "trust your administrators" argument, would the above scenario be relatively secure?
Any thoughts on a compromise solution greatly accepted.
cheers
September 19, 2003 at 7:20 am
Also remember the sa password.
Putting it in a DMZ which only allows access from named machines (ie HR's) may also help secure it.
Other idea's/Comments
1. Encrypting the backups using something like sqllightspeed. The backup could then be copied off the server, ready to go to tape.
2. Turn sql auditing on, to record access to the sql server.
3. If you control access to the server ie using a DMZ. Access could be granted on a ad-hoc basic whenever access is required, which may help with your admin problems.
Hope this helps
Steven
Steven
September 19, 2003 at 7:33 am
Would this lead to a secure system? I would say no.
Let's assume HR controls all the users and all the passwords, that includes the local administrator account for the OS. Have they blocked access to the administrators? Yes. Have they produced a secure box? No, not based on any security personnel's definition of the word secure.
The administrative effort of patch management, auditing, etc., which helps maintain security is completely being neglected unless HR is suddenly willing to take on these roles as well (and have the skillsets... but wouldn't that make them admins). And that also means they have to be capable of spotting warning signs.
Blaster, Welchia, and the host of MS03-026 worms provide a classic example. Looking in the event log you *might* have seen that the system was infected *if* RPC came down. But it didn't always for all systems. AV products like Norton could detect new files from being written that were part of the infection, but it couldn't stop the Worm from executing code through the vulnerability. Only with the patch were you safe. Similar story with SQL Slammer... without the right patch, that server was vulnerable to attack. Now take it a step further. Once the system was compromised in both of the cases I've given, they began trying to spread, putting the entire infrastructure at risk.
Without these ancillary "admin tasks," the system can't be considered a secure one... The administrators may not have access to the systems, but there are a lot of other considerations on whether the system is secure and whether it poses a threat to the infrastructure as a whole.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
September 19, 2003 at 7:41 am
One other considerations is the HR software itself, is that secure?
I looked at a HR system this year which had an intranet frontend, where you could inject sql using the web pages, and basically do what you wanted.
Steven
September 19, 2003 at 2:49 pm
Very good point. I had to consult on a friend's security setup (ISP with web and SQL Server hosting) a few months ago. The customer was complaining someone had hacked the SQL Server and valuable data was being lost.
Taking a look at the code, it was obviously vulnerable to SQL Injection. I forwarded relevant docs to the ISP who in turn passed on the docs to the customer. The customer then authorized the ISP to perform a basic SQL Injection attack to verify that it could be used to delete the data in the manner they were seeing. It took all of about five minutes to prove it.
So if the app isn't secure, locking out the admins isn't going to do any good. Moreover, the folks who would be the most likely to spot such an intrusion would be the very ones you are preventing from accessing the system.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
September 20, 2003 at 1:17 pm
Hi beath,
quote:
We've got one of these "HR versus IT" meetings brewing where HR are demanding that ALL IT personnel be excluded from accessing the HR SQL server. As an interim measure we are proposing:Remove the server from the domain and add to it's own workgroup.
Remove the BUILTIN\Administrators group.
Allow HR to control the local server passwords.
I assume this would achieve the objective of keeping IT staff off this server? Even with the domain admin password we wouldn't be able to authenticate, correct? And as we can't log on locally as HR hold the passwords we wouldn't be able to add ourselves back into the database?
Ignoring for the moment all the issues around, server support, sql support, access to backup tapes and the whole "trust your administrators" argument, would the above scenario be relatively secure?
apparently all HR department in the world seem to share the same kind of paranoia.
In addition to what has been said before, our HR department was urged to have a service contract with some external consultant for 'their' SQL Server. That has been a demand from IT. Guess now who they call first when something happens?
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply