Microsoft's SQL Server 2005 is an enterprise-class database server, suitable
for the toughest workloads and boasting some impressive security features. Yet
enterprises might be placing themselves at risk if they simply deploy SQL Server
and neglect to take advantage of the security features.
In general, Microsoft recommends a defense-in-depth approach to securing infrastructure
components such as database servers. This approach focuses on perimeter, network,
host, application, data, and physical defenses. Here are 10 steps to securing
SQL Server 2005 that you should take before, during, and after installation,
based on the defense-in-depth approach.
1. Preparing for SQL Server 2005 Installation: Remove Unnecessary Services
Properly preparing for an installation of SQL Server 2005 is one of the most
important ways you can protect your databases and the data contained within
them.
The first step is to carefully prepare the server on which you'll
install SQL Server 2005. In particular, the server should be dedicated to running SQL Server 2005. It should not also be used to
run other services such as Microsoft IIS, provide general Web-server
functionality, serve applications, or be configured as a domain controller (DC). It's important that a server dedicated to SQL Server
2005 not run other services because if those other services become
compromised, perhaps due to poor configuration, an attacker might
be able to gain system-level access to the host OS and then to SQL
Server 2005 and the databases it manages.
All unnecessary services and applications should be removed. For
example, if you're repurposing an existing server that was a DHCP
or DNS server, you shouldn't just disable those services, you should
remove them by using the Optional Components Wizard that's
part of Add/Remove Programs in Control Panel. Likewise, remove
all third-party applications that aren't required, such as WinZip
and Microsoft Office applications. You should also disable file and
printer sharing. If you don't need them, I recommend that you also
disable the administrative shares (e.g., C$, D$, ADMIN$).
Note that depending on what features of SQL Server 2005 you wish to install
(e.g., Reporting Services), you might need to install IIS and .NET Framework
2.0. If this is the case, you should limit the use of these additional services
and features to SQL Server 2005 only, and you should configure them as securely
as possible by using the appropriate best practices for each. Security best
practices and guidance for Microsoft technologies can be found at http://www.microsoft.com/technet/security/guidance/default.mspx.
You might also want to check http://msdn.microsoft.com/security.
2. Apply All Service Packs and Security Updates to the Host OS
The second step in preparing for installation of SQL Server 2005 also concentrates
on the host and is to ensure that all the latest service packs and software
updates are applied to the OS on the server on which you'll install SQL Server
2005. This step is crucial to securing your SQL Server 2005 installation. Just
as attackers can gain access to your system through services and applications
running on it, they can get access to the host through vulnerabilities in the
OS itself.
Visit http://update.microsoft.com
to ensure that you have the latest service packs and updates, or use the Windows
Update or Microsoft Update tool on the Start menu if you don't have an enterprise
software update distribution mechanism such as Microsoft Systems Management
Server (SMS).
3. Limit Access to the Host
The third step is a combination of focus on the host, perimeter, and physical
environment and is to restrict access to the server. An attacker has several
ways to gain access to a server, including interactively, over the network,
and physically when the OS isn't running.
You limit interactive access to the host by
ensuring that the local SAM database contains no unnecessary accounts and that only
permitted domain accounts can be used to
log on to the system. You can examine and
remove accounts in the local SAM database by using the Microsoft Management
Console (MMC) Computer Management
snap-in (compmgmt.msc).
To prevent domain accounts from logging on interactively to the server and
accessing a desktop, you can use Group Policy or the MMC Local Security Settings
snap-in (secpol.msc) to set User Rights Assignment. If using Group Policy, expand
Computer Configuration, Windows Settings, Security Settings, Local Policies,
and User Rights Assignment. If using the Local Security Settings snap-in, expand
Local Policies, User Rights Assignment.
Use the Allow log on locally and Deny logon locally settings
to configure who is permitted to log on at the console. If you permit access
to your server through Terminal Services, even if only for remote administration,
you should also use the Allow log on through Terminal Services and Deny
log on through Terminal Services settings to configure who can log on interactively.