Security Considerations for a SQL Server Installation

Physical and logical isolation make up the foundation of SQL Server security. To enhance the physical security of the SQL Server installation, do the following tasks:

• Place the server in a room accessible only to authorized persons.

• Place computers that host a database in a physically protected location, ideally a locked computer room with monitored flood detection and fire detection or suppression systems.

• Install databases in the secure zone of the corporate intranet and do not connect your SQL Servers directly to the Internet.

• Back up all data regularly and secure the backups in an off-site location.

Firewalls are important to help secure the SQL Server installation. Firewalls will be most effective if you follow these guidelines:

• Put a firewall between the server and the Internet. Enable your firewall. If your firewall is turned off, turn it on. If your firewall is turned on, do not turn it off.

• Divide the network into security zones separated by firewalls. Block all traffic, and then selectively admit only what is required.

• In a multi-tier environment, use multiple firewalls to create screened subnets.

• When you are installing the server inside a Windows domain, configure interior firewalls to allow Windows Authentication.

• If your application uses distributed transactions, you might have to configure the firewall to allow Microsoft Distributed Transaction Coordinator (MS DTC) traffic to flow between separate MS DTC instances. You will also have to configure the firewall to allow traffic to flow between the MS DTC and resource managers such as SQL Server.

For more information about the default Windows firewall settings, and a description of the TCP ports that affect the Database Engine, Analysis Services, Reporting Services, and Integration Services, see Configuring the Windows Firewall to Allow SQL Server Access.

Isolating services reduces the risk that one compromised service could be used to compromise others. To isolate services, consider the following guidelines:

• Run separate SQL Server services under separate Windows accounts. Whenever possible, use separate, low-rights Windows or Local user accounts for each SQL Server service. For more information, see Setting Up Windows Service Accounts.

Using the correct file system increases security. For SQL Server installations, you should do the following tasks:

• Use the NTFS file system (NTFS). NTFS is the preferred file system for installations of SQL Server because it is more stable and recoverable than FAT file systems. NTFS also enables security options like file and directory access control lists (ACLs) and Encrypting File System (EFS) file encryption. During installation, SQL Server will set appropriate ACLs on registry keys and files if it detects NTFS. These permissions should not be changed. Future releases of SQL Server might not support installation on computers with FAT file systems.

  Notes

  If you use EFS, database files will be encrypted under the identity of the account running SQL Server. Only this account will be able to decrypt the files. If you must change the account that runs SQL Server, you should first decrypt the files under the old account and then re-encrypt them under the new account.

• Use a redundant array of independent disks (RAID) for critical data files.

Servers in the perimeter network should have all unnecessary protocols disabled, including NetBIOS and server message block (SMB).

NetBIOS uses the following ports:

• UDP/137 (NetBIOS name service)

• UDP/138 (NetBIOS datagram service)

• TCP/139 (NetBIOS session service)

SMB uses the following ports:

• TCP/139

• TCP/445

Web servers and Domain Name System (DNS) servers do not require NetBIOS or SMB. On these servers, disable both protocols to reduce the threat of user enumeration.