The Politics of SQL Security
-
Full marks Rob, at least you understood the implications and made changes to resolve that. My issue is the in house devs who are developing with full sysadmin access. They build an app that then gets sold to market and once clients have purchased it then everyone else has to deal with the fallout. One SQL dev I worked with constantly demanded sysadmin access but could give us no good reason for it. He knew that with that type of access his code would probably run with no issues. Better to push back and get people to fully understand what their code is trying to do.
qh
[font="Tahoma"]Who looks outside, dreams; who looks inside, awakes. – Carl Jung.[/font] -
Many many moons ago I was working for a small company of about 20 people. We were on SQL Server 6.5, everyone had "sa" access and ISQL/W was installed on their machines by default. "It was just easier to that way" :w00t:
We had a receptionist who, no offence to the receptionists of the world, was not a very bright spark. Sometimes she struggled to work out how to turn the computer on in the morning.
After many fruitless discussions with the company owner to change this situation, I sat him down at this receptionists computer, logged in as her, got him to open ISQL/W and type SHUTDOWN. Within seconds, every head in the company had popped up over the partitions asking what was wrong. Within minutes, everyone lost their "sa" access 😀 😀
--------------------
Colt 45 - the original point and click interface
-
After many fruitless discussions with the company owner to change this situation, I sat him down at this receptionists computer, logged in as her, got him to open ISQL/W and type SHUTDOWN.
Wonderful 😀
I just got a new idea!
-
quackhandle1975 (5/23/2016)
Full marks Rob, at least you understood the implications and made changes to resolve that. My issue is the in house devs who are developing with full sysadmin access. They build an app that then gets sold to market and once clients have purchased it then everyone else has to deal with the fallout. One SQL dev I worked with constantly demanded sysadmin access but could give us no good reason for it. He knew that with that type of access his code would probably run with no issues. Better to push back and get people to fully understand what their code is trying to do.qh
WOW, you said a lot there, quackhandle, because we were guilty of doing that as well. As developers we wrote our code so that it required elevated privileges. But I guess at least in this it wasn't entirely our fault. Back in the late 1990's it was common practice to store some configuration information in the registry. In some cases, storing all configuration information in the registry. We didn't know how to make it possible for regular users to be able to write into the registry, without making them all administrators on their own machines. So that's what we did, I am embarrassed to say. It may be possible to do that without making someone an administrator on their machine, but I don't know how. And honestly at this point I don't want to know. Configuration information shouldn't be in the registry. But the use of XML files to store that kind of information didn't come about until years later. Anyway, the old VB6 apps that I helped write at that agency, are still being used today, so they're still having to give admin rights on the machine to any user needing to use those apps. While I was there I lobbied to get those apps re-written so they wouldn't depend upon the registry, move them to some .NET app, but that never happened. And now it doesn't really matter, as the agency where I used to work, is going out of business at the end of 2016.
Kindest Regards, Rod Connect with me on LinkedIn.
-
Kyrilluk (5/23/2016)
Jeff Moden (5/23/2016)
I simply ask if he'll enjoy reading about himself in the morning news after the company has suffered a breach. I also explain that customers can and do sue when breaches occur and that it's really difficult to keep and get new customers after such a breach has occurred.They usually come around.
If an application has an obvious security hole (such as the sa password hard coded in the application or stored proc that can be SQL injected), is not possible to sue the software provider?
The thing is, in many cases software developers are running without a highly (or even particularly or in some cases vaguely) skilled SQL Server resource. A DBA with decent security skills isn't that easy to find, particularly when most people don't really know what they're asking for, and comes with a big ticket attached. So, if that's your bag, yeah, sue on that basis. However, this isn't particularly good for the company whose software is running part of YOUR business.
While it's not universal, you are going to get the occasional clown who is going to scream blue murder when security issues are raised rather than work towards a mature solution, in general I tend to find suppliers are pretty sympathetic or even grateful when you put such issues in front of them and very much prepared to work with you in addressing them. Provided you do it right.
This is after all improving their product, and being able to walk onto another prospect's site and go " ... and of course with security being such a critical factor in xxx industry, we've worked with our clients to ensure our product adheres to POLP ... " does them a lot of good if the competition can't. This is also good for stability in your department.
Win / win.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them. -
If developers call stored procedures and load (preferably encrypted, preferably integrated authentication) connection strings from a repository (even a file) then none of this is an issue. I cannot remember the last time a project got past a few weeks of development with a hard coded account. And NEVER sa!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply