When it comes to attacking SQL Server, whether we're talking about the security of an installation or as a piece towards a larger solution, I first stop and realize that SQL Server is the sum of its parts. For instance, take SQL Server installed on a VM. Areas that concern me:
- Does the physical host have enough capacity to run the VM properly?
- Does the Guest OS have the proper configuration to support my SQL Server?
- Is the OS configured optimally for my SQL Server?
- How is my SQL Server configured?
The last one by itself can be broken up into many more parts. Some of the considerations we make is how to locate the user database files and logs, how to setup and configure TempDB, and what the max degree of parallelism should be for this particular instance. There's more than that, sure, but that shows just how much control we have over the performance of SQL Server.
When it comes to security, I also break down SQL Server into different parts and take a look at them individually and as a whole. That's what I'll look at and discuss this week - how to do just that. Here are the parts I'll consider:
- Server Level
- Individual Database Level
- Surface Area
- Windows and Active Directory
