Skip to content

security-considerations-for-a-sql-server-installation.md

Latest commit

 

History

History
179 lines (113 loc) · 12.3 KB

security-considerations-for-a-sql-server-installation.md

File metadata and controls

179 lines (113 loc) · 12.3 KB
title Security Considerations
description This article discusses some security best practices that you should consider both before and after you install SQL Server.
author MikeRayMSFT
ms.author mikeray
ms.reviewer randolphwest
ms.date 08/14/2025
ms.service sql
ms.subservice security
ms.topic conceptual
helpviewer_keywords
firewall systems [SQL Server]
server message blocks [SQL Server]
disabling protocols
security [SQL Server], installations
protocols [SQL Server], disabling
NetBIOS [SQL Server]
services [SQL Server], security
SMB [SQL Server]
isolating services [SQL Server]
Setup [SQL Server], security
low SQL Server installation privileges
NTFS [SQL Server]
physical security [SQL Server]
file system security [SQL Server]
installing SQL Server, security

Security considerations for a SQL Server installation

[!INCLUDE 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 [!INCLUDE ssNoVersion] and after you install [!INCLUDE ssNoVersion]. 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

Physical and logical isolation make up the foundation of [!INCLUDE ssNoVersion] security. To enhance the physical security of the [!INCLUDE ssNoVersion] 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 [!INCLUDE ssNoVersion] 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 [!INCLUDE msCoName] 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 [!INCLUDE ssNoVersion].

For more information about the default Windows Firewall settings, and a description of the TCP ports that affect the [!INCLUDE ssDE], [!INCLUDE ssASnoversion], [!INCLUDE ssRSnoversion], and [!INCLUDE ssISnoversion], 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:

Configure a secure file system

Using the correct file system increases security. For [!INCLUDE ssNoVersion] 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 [!INCLUDE ssNoVersion] 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, [!INCLUDE ssNoVersion] sets appropriate ACLs on registry keys and files if it detects NTFS. These permissions shouldn't be changed. Future releases of [!INCLUDE ssNoVersion] 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 [!INCLUDE ssNoVersion]. Only this account is able to decrypt the files. If you must change the account that runs [!INCLUDE ssNoVersion], 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 [!INCLUDE ssNoVersion] on a domain controller. [!INCLUDE ssNoVersion] Setup doesn't block installation on a computer that is a domain controller, but the following limitations apply:

  • You can't run [!INCLUDE ssNoVersion] services on a domain controller under a local service account.

  • After [!INCLUDE ssNoVersion] is installed on a computer, you can't change the computer from a domain member to a domain controller. You must uninstall [!INCLUDE ssNoVersion] before you change the host computer to a domain controller.

  • After [!INCLUDE ssNoVersion] is installed on a computer, you can't change the computer from a domain controller to a domain member. You must uninstall [!INCLUDE ssNoVersion] before you change the host computer to a domain member.

  • [!INCLUDE ssNoVersion] failover cluster instances aren't supported where cluster nodes are domain controllers.

  • [!INCLUDE ssNoVersion] Setup can't create security groups or provision [!INCLUDE ssNoVersion] service accounts on a read-only domain controller. In this scenario, Setup fails.

Ensure required user rights are assigned for successful installation

Setup requires that the following user rights are granted to the account under which [!INCLUDE ssNoVersion] is installed:

  • Backup files and directories
  • Debug programs
  • Manage auditing and security log

These user privileges are usually granted by default to the local administrator group (BUILTIN\Administrators). In most cases, no action is required to assign them. However, if a security policy revokes these privileges, you must make sure they are correctly assigned, or [!INCLUDE ssNoVersion] Setup fails with the following error:

The account that is running SQL Server Setup doesn't have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights.

During or after installation of SQL Server

After installation, you can enhance the security of the [!INCLUDE ssNoVersion] installation by following these best practices regarding accounts and authentication modes:

Service accounts

Authentication mode

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 [!INCLUDE ssNoVersion] logins.

Important

During setup of [!INCLUDE ssExpress] a login is added for the BUILTIN\Users group. This allows all authenticated users of the computer to access the instance of [!INCLUDE ssExpress] as a member of the public role. The BUILTIN\Users login can be safely removed to restrict [!INCLUDE ssDE] access to computer users who have individual logins or are members of other Windows groups with logins.

Related content