This checklist reviews key options to use when connecting to the SQL Server Database Engine. Use this checklist to review your environment to make sure that connections are made to the Database Engine as securely as necessary for your business needs.
Is the Database Engine configured to listen on the required protocols and no others?
Tip Use SQL Server Configuration Manager to enable TCP/IP or named pipes only if required by clients. For more information, see Choosing a Network Protocol, and How to: Enable or Disable a Server Network Protocol (SQL Server Configuration Manager).
Are Service Broker, HTTP, and database-mirroring endpoints only created if necessary?
Tip For more information, see Network Protocols and TDS Endpoints.
Are connections made using Windows Authentication whenever possible?
Tip For more information, see Choosing an Authentication Mode.
Is the Database Engine configured to use a certificate from a trusted authority to secure communications?
Tip The default configuration using a self-signed certificate is less secure. Use the Windows certificates tool (certmgr.msc) and then SQL Server Configuration Manager to install a certificate. For more information, see How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
Is SQL Server configured to allow only secure connections over the network?
Tip Use the Force Encryption server setting in SQL Server Configuration Manager. For more information, see How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
When possible, is SQL Server using Kerberos authentication for Windows Authentication clients?
Tip For more information, see Kerberos Authentication and SQL Server.
On Windows Server 2003 and Windows XP, is the Database Engine running under a domain account that is not used by any other service?
Tip Using separate accounts for services helps prevent a compromised service from accessing other services.
If the Database Engine is running under a domain account, is the password of the account changed on a regular basis?
Tip On Windows 7 and Windows Server 2008 R2, consider running the Database Engine under a Managed Service Account so that the domain manages the password. Network Service is a good choice. For more information about Managed Service Accounts, see Service Accounts Step-by-Step Guide.
Are named instances of the Database Engine configured to listen on a fixed port?
Tip Fixed ports allow you to open only the correct port in the firewall. Use SQL Server Configuration Manager to configure fixed ports. For more information, see Configuring a Fixed Port.
Did you configure login auditing to retain a record of failed logins?
Tip Configure by using the Server Properties (Security Page) in SQL Server Management Studio.
Have you configured SQL Server audit to audit failed logins?
Tip For more information, see Understanding SQL Server Audit.
Have you removed unnecessary or obsolete logins from the Database Engine?
Tip This may require periodic manual review. Enabling access primarily through Windows groups can make this task easier.
Are clients configured to only connect using Secured Sockets Layer (SSL)?
Tip Use the Force Protocol Encryption client setting in SQL Server Configuration Manager. For more information, see How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager).
Are clients configured to connect using accounts with the least privilege necessary for the business need?
Tip Applications should not connect by using accounts that are members of the sysadmin fixed server role or members of the dbo_owner database role. Configuring applications to connect with accounts that have limited privileges helps reduce the risk from application problems, such as SQL injection.
Do administrators connect using Windows logins instead of the sa account?
Tip Windows accounts that are members of the sysadmin fixed server role have the same privileges as the sa account. When using their Windows logins, administrators are still individually identified and can be audited. When using the sa account, it might be unclear which administrator performed an action. Consider disabling the sa account when using mixed mode authentication.
Do administrators connect using lesser privileged accounts when not performing administrative actions?
Tip Reducing the number of administrator connections helps to reduce the risk of errors and malicious actions. Consider creating lower privileged accounts for users that rarely require administrative access.
Is the SQL Server computer protected by a firewall with only the necessary exceptions?
Tip Use wf.msc (or firewall.cpl) to configure the Windows firewall. For more information, see Configuring the Windows Firewall to Allow SQL Server Access.
Are the server and client operating systems configured to use Extended Protection for Authentication?
Tip For more information, see Connecting to the Database Engine Using Extended Protection and Extended Protection for Authentication.
Database Engine Security Checklist: Database Engine Security Configuration
Database Engine Security Checklist: Limiting Access to Data
Database Engine Security Checklist: Encrypting Sensitive Data