Build Secure Database Applications with Microsoft SQL Server
The recent spate of breaches and attacks targeting various business and government computing systems drives home the message that our (collective) systems are at risk from threats both internal and external. As a database professional, I'm inclined to believe our databases are at particular risk, and here's why:
- Databases are prime targets because they are foundational to many applications and are the principle stores of sensitive data.
- In most organizations, responsibility for the protection of databases is distributed between multiple groups. While an optimist might see this as providing multiple layers of protection, I'm concerned that without one group or individual having overarching responsibility, there tend to be significant gaps in security policies and procedures.
With this in mind, I am speaking with folks about ways they can improve the security of their database applications built upon Microsoft SQL Server. My objectives are to:
- Improve awareness of features and practices that can be used to make SQL Server databases tougher targets, and
- Encourage folks to engage in dialogs within their organizations about database security to ensure gaps are identified and addressed.
In order to engage a broader audience, I am providing much of this information here as a series of blog posts organized around the high-level practices that should be employed. As entries are posted, I'll convert each of these practices into links to make accessing of this information a bit easier:
- Harden the database server
- Regulate network connectivity
- Secure the authentication process
- Assign minimal permissions
- Encrypt the data
- Defend against SQL injection
- Monitor and enforce policies
Before jumping into specific topics, it's important to note that Microsoft provides guidance on meeting specific security standards. Here are links to the ones of which I am aware. (If you are aware of others, please let me know and I'll work to get them posted here.)
The guidance above and many of the features I'll present in subsequent posts flow from a combination of customer-demand and a commitment to security established following some high-profile failures in the early part of the last decade. Following those incidents, Microsoft now develops all products using the Security Development Lifecycle (SDL) process (which can be adapted for use in your organization).
For SQL Server, the SDL and the overall commitment to security has meant a dramatic drop in the number of vulnerabilities relative to both earlier releases and competitor database management systems. For very security concious organizations, this has meant the adoption of SQL Server for many of their mission critical applications.