Friday, August 29, 2008

Simple SQL Server Security

Do a search on the web for SQL Server security and you will find 1,000's of documents about best practices and how to secure your server. But many times, the biggest security threats come from inside.


No, I am not talking about a disgruntled employee or a DBA with a side job selling company information on EBay. Don't get me wrong, those are very real dangers and should be considered and protected against.


No, what I am talking about are small innocent mistakes that can cause HUGE problems for you and your company.


A perfect example is not having some elemental things in place like...

  • Change Control
  • Build Procedures and SOP's
  • No peer review
  • No proactive monitoring

These things are all very simple things that should be in place, but are often not or are overlooked.


Let's look at a simple one, a build check list. As part of your job, you probably build a couple of SQL servers a month. Sometimes more, sometimes less. When you build your server (hopefully you have a server department that burns a standard image for the OS) how do you do it? Do you just do it from memory because you have done a couple of hundred installs and are very good at it, or do you have a check list document that walks you through it?

The answer should be: a check list document that walks you through it. It is way to easy to be in the middle of installing a SQL Server instance and get called away for some emergency and then come back and start the build again from where you left off. But the problem is you skip a step you "know" you have already done and something gets left in place that should not or something does not get added that should. Having a build document greatly reduces the possibility of missing something vital and helps to make sure that every server is exactly the same as all the others.

I know that no process is perfect. Mistakes will be made. The question is how many? I know from experience how easy it is to not change the SQL port from the default 1433 to the company approved XXXXX and then have security call and ask why after they run their next security audit. Not a lot of fun. And potentially very serious, if you are in a PCI or similar environment.  And much more serious issues can arise like blank passwords, default accounts that should have been removed but were not, and so on.

Change control is another. A developer emails you a script and says it has to be ran right now due to the emergency nature of the issue. As soon as you see the email you run it and call the developer to let him know the change is done. Only to find out that he got tired of waiting for you (since you were in the bathroom for like 5 minutes) and he called DBA Bob and had him run it. Now you and Bob have made the same change withing minutes of each other without knowing it. Hopefully, the multiple runs don't mess anything up, but worse case is that the ecommerce site is now down and it will take you 20 minutes to fix what took 30 seconds to break. All because you don't have a defined change manage process.

Many of you are probably laughing and saying "Yea right, like that really happens.". Well I hope you are, because that means you have never had it happen to you. Yet. But it happens all to often in some fairly large shops that should know better.

So, secure your servers as suggested by Microsoft and the others, but also make sure you have the simple stuff covered as well.

The Devil is always in the details and the small ones are the ones he likes best.

Jim


No comments: