- Databases are prime targets because they are foundational to many applications and are the principle stores of sensitive data.
- Responsibility for the protection of our 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
- Control network communications
- Limit access to database services
- Assign minimal permissions
- Encrypt your data
- Defend against common exploits
- 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. ..."
This looks like an interesting series to watch... In looking at the topic list, it seems like all we've heard or already "know," but the "know" is very different than the "do." If you use SQL Server, from any side of any fence, this looks to be an informative series (and call to action.)