Harden the Database Server
Reducing the database server’s exposure to attacks (hardening) is a pretty big task. The physical security of the server along with that of the infrastructure on which it depends must be considered. Then there's the network and the operating system on which the database server runs and then the practices and procedures that prevent folks from inadvertently (or purposefully) compromising security.
In many organizations, there are individuals (or teams of individuals) charged with securing the computing infrastructure. There are many tools and other resources avilable to these folks to assist them with their tasks. Still, here are a few for folks just getting started in this space:
- Microsoft Security Compliance Manager
- CompTIA Security+ and Advanced Security Practitioner certifications
In addition to general infrastructure guidance, Books Online provides a few hardining recommendations specific to SQL Server servers here and here that are well worth checking out.
With the underlying infrastructure secure, attention is then turned the SQL Server software itself. The general recommendations here are:
Keep SQL Server Up-to-Date
With each version of SQL Server, security is improved. Microsoft continues to address vulnerabilities in older and even unsupported versions of the product, but working with newer versions provides access to increasingly advanced security capabilities. The product lifecycle information provided here identifies which products are currently considered supported and Books Online provides information on security enhancements availalble with a given product release. (Here is that Books Online entry for SQL Server 2008 and 2008 R2.)
As vulnerabilities are detected, Microsoft releases security-related patches (hotfixes) to fix these. These need to be applied aggressively to prevent exploits. Notification of security concerns and fixes from Microsoft can be obtained by registering here and tools such as System Center Configuration Manager can assist in getting these rapidly applied across a large infrastructure.
But tools are not enough. The principle barriers to the application of patches are the availability of personnel for testing and a lack of agreement around the speed with which hotfixes should move into production. Before a hotfix needs to be applied, it is strongly recommended that testing procedures be clearly defined and windows for the application of security-related patches be agreed to amongst the responsible and effected parties. (In some organizations, there is a minimal test performed for security-related hotfixes which allows it to get into produtcion faster while full-blown service packs and version upgrades receive much more exhaustive testing. There is a risk associated with this but as with most security considerations, it's all about balancing risks.) Automation too can help speed the testing process by reducing dependency on personnel.
Leave Off Unnecessary SQL Server Features
SQL Server has been engineered with a number of features turned off by default. These are features that are not fundamental to the operations of the database server and that could be exploited. Some of these off-by-default features are:
- Database & SQL Mail
- CLR Integration
- OLE Automation
- xp_cmdshell
- Ad Hoc Remote Queries
- HTTP & Service Broker Endpoints
- Additional Network Protocols
- Remote (Dedicated) Admin Connections
Though off-by-default, these features do play roles in specific scenarios. Before enabling these, carefully weigh the costs and benefits, consider alternative solutions, and explore ways to mitigate the risk.