January 23, 2008 at 1:11 pm
In the ideal world I would agree with you entirely. Block them at the firewall and remove db_datareader/db_datawriter access.
However the problem described in the article was of a business critical legacy application that used standard security so the normal methods of securing the database were off limits.
The application used a mix of stored procedures and dynamic SQL so removing any privileges would break the application.
February 2, 2008 at 9:36 am
There are still other ways that can both secure the environment as well as allow for existing applications to run as originally designed.
The real problem here is that instead of suggesting that the user fix his original problem which is a big security hole, we are telling him how he can monitor that hole. The emphasis should be how to migrate out of that situation into a more secure environment.
When we had a similar issue we forced all of the developers to connect via a different firewall which can easily be done by adding a route statement to their ports. Once they were going through that firewall the access restrictions were put into place. The developers had a test machine that they could use to test their applications but the security on that machine was limited so they could not install their own software with out the Administrator password. This way developers could only hit the sandbox environment and could only test production apps with the same security and interface that the users had. It was more elegant and no one had to worry about them running some dangerous query on our production environment.
On the whole people are generally good natured and not out to do harm, but if you give them access then they can mistakenly use that access. DBA's tend to have this belief that when there is something wrong with the system it must be a rogue query from a dev that caused it. I used to be this way too and that's when I realized this is not the best way to build relationships with people.
Viewing 2 posts - 31 through 31 (of 31 total)
You must be logged in to reply to this topic. Login to reply