Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to:
SQL Server - Windows only
Security is important for every product and every business. By following simple best practices, you can avoid many security vulnerabilities. This article discusses some security best practices that you should consider both before you install SQL Server and after you install SQL Server. Security guidance for specific features is included in the reference articles for those features.
Before installing SQL Server
Follow these best practices when you set up the server environment:
- Enhance physical security
- Use firewalls
- Isolate services
- Configure a secure file system
- Disable NetBIOS and server message block
- Install SQL Server on a ___domain controller
Enhance physical security
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 don't connect your SQL Server instances directly to the Internet.
Back up all data regularly and secure the backups in an off-site ___location.
Use firewalls
Firewalls are important to help secure the SQL Server installation. Firewalls are 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, don't 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're 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 must also 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 Configure the Windows Firewall to allow SQL Server access.
Isolate services
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 Configure Windows service accounts and permissions.
Configure a secure file system
Using the correct file system increases security. For SQL Server installations, you should do the following tasks:
Use the NT file system (NTFS) or Resilient File System (ReFS). NTFS and ReFS are the recommended file system for installations of SQL Server because it's more stable and recoverable than FAT32 file systems. NTFS or ReFS also enable security options like file and directory access control lists (ACLs). NTFS also supports Encrypting File System (EFS) - file encryption. During installation, SQL Server sets appropriate ACLs on registry keys and files if it detects NTFS. These permissions shouldn't be changed. Future releases of SQL Server might not support installation on computers with FAT file systems.
Note
If you use EFS, database files are encrypted under the identity of the account running SQL Server. Only this account is able to decrypt the files. If you must change the account that runs SQL Server, you must first decrypt the files under the old account and then re-encrypt them under the new service account.
Warning
Using file encryption via EFS might lead to slower I/O performance because encryption causes asynchronous I/O to become synchronous. See Asynchronous disk I/O appears as synchronous on Windows. Instead, you can consider using SQL Server encryption technologies like Transparent data encryption (TDE), Always Encrypted, and column-level encryption Cryptographic functions.
Disable NetBIOS and Server Message Block
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 don't require NetBIOS or SMB. On these servers, disable both protocols to reduce the threat of user enumeration.
Install SQL Server on a ___domain controller
For security reasons, we recommend that you don't install SQL Server on a ___domain controller. SQL Server Setup doesn't block installation on a computer that is a ___domain controller, but the following limitations apply:
You can't run SQL Server services on a ___domain controller under a local service account.
After SQL Server is installed on a computer, you can't change the computer from a ___domain member to a ___domain controller. You must uninstall SQL Server before you change the host computer to a ___domain controller.
After SQL Server is installed on a computer, you can't change the computer from a ___domain controller to a ___domain member. You must uninstall SQL Server before you change the host computer to a ___domain member.
SQL Server failover cluster instances aren't supported where cluster nodes are ___domain controllers.
SQL Server Setup can't create security groups or provision SQL Server service accounts on a read-only ___domain controller. In this scenario, Setup fails.
During or after installation of SQL Server
After installation, you can enhance the security of the SQL Server installation by following these best practices regarding accounts and authentication modes:
Service accounts
Run SQL Server services by using the lowest possible permissions.
Associate SQL Server services with low privileged Windows local user accounts, or ___domain user accounts.
For more information, see Configure Windows service accounts and permissions.
Authentication mode
Require Windows Authentication for connections to SQL Server.
Use Kerberos authentication. For more information, see Register a Service Principal Name for Kerberos connections.
Strong passwords
- Always assign a strong password to the sa account.
- Always enable password policy checking for password strength and expiration.
- Always use strong passwords for all SQL Server logins.
Important
During setup of SQL Server Express a login is added for the BUILTIN\Users
group. This allows all authenticated users of the computer to access the instance of SQL Server Express as a member of the public role. The BUILTIN\Users
login can be safely removed to restrict Database Engine access to computer users who have individual logins or are members of other Windows groups with logins.