SQL Server Security

Security should be everyone’s business,  but it’s often seen as someone else’s problem.  When it comes to SQL Server there are at least three parts to the puzzle:

• The infrastructure guys will provide secure comms and accounts with which to access SQL Server.
• The developers be they in house or  employed by the vendor you bought your app from will be using a secure development lifecycle (SDL) approach and their code will be proof against SQL injection (the business of putting extra code into a parameter passed to piece of dynamic SQL.
• You the DBA  will have mad SQL Server as secure as possible.

 

Sadly in many environments not all these pieces are put in place, except where there is some external pressure to do so e.g. in the public sector and in financial services.  For example at the session I did to the ISSA (Information Systems Security Association) last week several of the audience were very interested in the resources and guidance on how to make SQL Server compliant with the rules for working in the credit (payment) card industry (PCI).  They were also interested in the practical advice they could pass onto the developers and dbas they work with as virtually everyone in the room was running SQL Server.

There is a  whitepaper on this on the SQL Server compliance micro-site as well as a web cast, and this site also addresses other industry guidance although is for American based companies.

The rest of this site calls out the features in SQL Server 2008 related to security and compliance, which may well be familiar to you but not to the security guys you might be working with so you could do worse than point them to this. 

Finally for the ISSA guys here are my slides now that I have re-edited the deck following the hard disk crash I had just before presenting!

 

Technorati Tags: SQL Server 2008,PCI,security,payment card industry