SQLSecurity Checklist: Enhance the Security of Database Engine Connections
아티클
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.
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).
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 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.
Operating System Settings
...
Description
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.
