- Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- The DBA Survival Guide: The 10 Minute SQL Server Overview
- Preparing (or Tuning) a Windows System for SQL Server, Part 1
- Preparing (or Tuning) a Windows System for SQL Server, Part 2
- Installing SQL Server
- Upgrading SQL Server
- SQL Server 2000 Management Tools
- SQL Server 2005 Management Tools
- SQL Server 2008 Management Tools
- SQL Azure Tools
- Automating Tasks with SQL Server Agent
- Run Operating System Commands in SQL Agent using PowerShell
- Automating Tasks Without SQL Server Agent
- Storage – SQL Server I/O
- Service Packs, Hotfixes and Cumulative Upgrades
- Tracking SQL Server Information with Error and Event Logs
- Change Management
- SQL Server Metadata, Part One
- SQL Server Meta-Data, Part Two
- Monitoring - SQL Server 2005 Dynamic Views and Functions
- Monitoring - Performance Monitor
- Unattended Performance Monitoring for SQL Server
- Monitoring - User-Defined Performance Counters
- Monitoring: SQL Server Activity Monitor
- SQL Server Instances
- DBCC Commands
- SQL Server and Mail
- Database Maintenance Checklist
- The Maintenance Wizard: SQL Server 2000 and Earlier
- The Maintenance Wizard: SQL Server 2005 (SP2) and Later
- The Web Assistant Wizard
- Creating Web Pages from SQL Server
- SQL Server Security
- Securing the SQL Server Platform, Part 1
- Securing the SQL Server Platform, Part 2
- SQL Server Security: Users and other Principals
- SQL Server Security – Roles
- SQL Server Security: Objects (Securables)
- Security: Using the Command Line
- SQL Server Security - Encrypting Connections
- SQL Server Security: Encrypting Data
- SQL Server Security Audit
- High Availability - SQL Server Clustering
- SQL Server Configuration, Part 1
- SQL Server Configuration, Part 2
- Database Configuration Options
- 32- vs 64-bit Computing for SQL Server
- SQL Server and Memory
- Performance Tuning: Introduction to Indexes
- Statistical Indexes
- Backup and Recovery
- Backup and Recovery Examples, Part One
- Backup and Recovery Examples, Part Two: Transferring Databases to Another System (Even Without Backups)
- SQL Profiler - Reverse Engineering An Application
- SQL Trace
- SQL Server Alerts
- Files and Filegroups
- Full-Text Indexes
- Read-Only Data
- SQL Server Locks
- Monitoring Locking and Deadlocking
- Controlling Locks in SQL Server
- SQL Server Policy-Based Management, Part One
- SQL Server Policy-Based Management, Part Two
- SQL Server Policy-Based Management, Part Three
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Securing the SQL Server Platform, Part 1
Last updated Jul 15, 2011.
Security should always be a concern for a technical professional, but as I write this article it is certainly in the forefront of the news. High-profile break-ins at companies large and small, releasing sensitive data that in some cases is even life-threatening show up as stories by the day.
For the data professional, security is especially important. After all, the bad guys don't want programs, software or the hardware — they are after names, bank numbers, and other private data. It is our first job to protect it. That's right, even before I make data available to a program in a functional way I build in the security for it. I would rather the project be late because the database isn't ready than I would for it to go out the door on-time but insecure.
In this article I will provide an overview of securing the SQL Server platform at a base level. The key is knowledge and action — you need to be aware of the surface area of your systems, and then take proper action to secure them. This is not meant as an exhaustive treatment, but should give you a baseline of terms for you to investigate further.
Security is a series of mechanisms, and all layers are equally important. If someone can steal the hardware or hack the program, all of the data security you put in may not stop the criminals from obtaining that data. The layers I work with on a SQL Server system are as follows:
- Physical — From the servers to the network cables, this layer involves the things you can touch and feel. Even if you aren't the one that secures them, you need to ensure someone is following the best practices for security at this layer.
- Operating System (OS) — The OS has a huge surface area, many features, and endpoints for multiple types and kinds of network connections. Even though there are tools and other references to assist you in securing this layer, make sure you check with a System Administrator to verify your configuration. This includes all drivers, utilities and other software packages used for the OS to function in your organization.
- Platform — This layer is where the Relational Database Management System (RDBMS) is installed and configured, and the subject of this overview.
- Principals — The Principals are any person, group, code base, function or other entity that can take an action in or through the RDBMS or OS.
- Securables — These are the objects within (and without) the RDBMS that require access.
- Programmatic Elements — This involves code of any type, from Stored Procedures and Functions through Dynamic SQL, and I'll spend more time in another article on writing secure code using Transact-SQL.
Basic System Surface Area
Even though I'll cover an overview in this article, there are some practical, basic steps you can take for your own systems. You may not be a System Administrator by training, but you might still own the system you are working with. If you do inherit a new Windows Server, I recommend that you immediately pull down the Microsoft Baseline Security Analyzer (MBSA) from this location (search for that title if this link goes stale): http://technet.microsoft.com/en-us/security/cc184924.aspx.
Once you download that product, run it and select SQL Server as an additional product for it to scan.
After you run the scan (it won't change anything on your system, don't worry) you'll get a report showing any issues that it finds.
You'll also get links for what the issue that was scanned is about, and what can be done to fix the problem. Read both of those. In some cases, the issues can be safely ignored. I can't specify which those are, since it depends on what the issue is and the level of security your system needs. For instance, you may have a non-expiring password on your SQL Server service accounts — and that might be just fine, if the passwords are complex enough and only key people know what they are.
The point is that tools like this one and others can quickly scan for things that you're not aware of. It certainly doesn't guarantee a completely secure system (there's no such thing anyway) but it helps to take care of the basics and even a few advanced areas you might not be familiar with.
A security evaluation is all about who can access what. So your goal to keep in mind at all times is this: Only put on the system the least amount of “what”, and only allow the least amount of “who” to access only “what” they need. It's a simple rule that I see violated all the time.
For instance — I see many systems that are used not only for SQL Server but print and file access, streaming video and more. Not only does this impact performance, but it has security implications as well.
Opening and controlling the operating system's firewall is a special topic, depending on which OS and firewall you have. Short version: open ports required to talk to SQL Server and the query source. Longer version here: http://technet.microsoft.com/en-us/library/ms175043.aspx. The basic ports you are interested in are TCP 1433 and UDP 1434. If you aren't familiar with ports on a network, read up on that topic here: http://en.wikipedia.org/wiki/TCP_and_UDP_port
As much as possible, use the very latest versions of your operating system and SQL Server software. You'll need to ensure that the software that accesses SQL Server allows the latest versions, but if it doesn't, contact the vendor and ask them to upgrade their software so that you are protected. Remember, it's your name and address out there on some server that a vendor won't take the time to upgrade. Don't let them lose your private data (or mine) simply because someone wanted to save a little money.
Also install the latest service packs, updates and hotfixes for the operating system, drivers, SQL Server and any other software you have installed. Those fixes often include security vectors, so read and apply the latest available for your software according to version.
SQL Server Configuration for Security
Once you're run the MBSA tool and installed all the latest versions, service packs and hotfixes, It's time to conduct a post-installation check or conduct a security review of SQL Server.
Although you can change almost any setting for the security of SQL Server using Transact-SQL (T-SQL) you'll probably learn to use the Graphical User Interface (GUI) tools first. That's actually not only OK, it may be best, since a GUI allows for discovery better than commands. I have most of my security scripted out already, but I still look at the graphical tools on a system to make sure I consider everything I can.
The first tool you'll use is the SQL Server Configuration Manager (SCM). This tool shows two primary areas for the security of your system: the networking protocols installed (along with their configuration) and the Windows Services that start SQL Server and its related programs.
I'll start with the Services. You should *always* use the SCM tool to work with SQL Server Services. The reason is that the SCM tool not only controls the Windows Services like the Control Panel in Windows does, but it takes care of the security for those accounts in SQL Server and even handles file-level permissions in some cases.
Opening the SCM program, you see a panel similar to this one:
Double-click any service to set how it starts up, and use a low-privilege account to start SQL Server. That's right, the SQL Server account does not need to be (nor should it be) a domain or any other kind of administrator on the system — as long as you use the SCM tool to control it. Remember, the SCM tool handles all of the proper rights and permissions in Windows to allow SQL Server to operate properly at a low level. Do not use system-level accounts for SQL Server unless the system does that for you, such as in the case of SQL Express or certain features in SQL Server. Create a standard domain (or system) account, set a strong password, and use that for the services. It's also not a bad idea to use a separate account for each and every Windows Service that SQL Server needs.
This might sound like a bit of overkill, but if you've ever had to troubleshoot an issue on the system or trace down a security attack, you'll be glad you did. But how do you do this in a practical way? Let me explain one system I've used for this in the past successfully.
I define a naming structure that works well for the organization. I tend not to name Service Accounts in such a way that an attacker can easily glean what they do — although they probably have other means to find that out, no reason to give them a hand. I then vary the name based on what it does. For instance:
SamQLentin — (Initials are SQL, starts the SQL Server Engine)
AgnesSSmith — (Stands for Agent, SQL Server)
RobertSenkill — (Stands for Reporting Services)
And so on. Note that I do not include any information in the notes or anywhere in Active Directory that would offer a clue on these accounts, including these descriptions I've mentioned here.
But what about the passwords? If you have to change the passwords on the accounts, you have to take down SQL Server — or at least you used to. In the newer versions of SQL Server this requirement is relaxed, so that you can change the password without having to re-start SQL Server. Books Online has more on this topic based on the version you have installed. If you do have to make the passwords static in Windows, there is a way that I've found to be fairly secure.
Make the password ridiculously long and complex. Set the account not to expire, record the password, seal it in an envelope, and have the administrator for the company keep it in a safe or other secure location. That way you'll be able to access it if something goes wrong, you'll be able to tell if anyone else has accessed it, and you'll be able to leave the password for longer periods. Whenever you can, it's still a good idea to rotate passwords as often as possible.
Once you've set the accounts, the next area in the SCM tool to control are the network protocols. I'll pick back up there in the next article.