Additional Considerations

In addition to the steps described in this chapter, consider the following guidelines:

• Install a certificate on the database server . If you use Windows authentication (NTLM or Kerberos), logon credentials are not passed over the network to SQL Server. If you use SQL authentication, it is a good idea to secure the credentials because they are passed to SQL Server in unencrypted format. Do this by installing a certificate on the database server. This automatically results in the encryption of SQL credentials over the wire. It is also a good idea to make sure that your application securely stores database connection strings. For more information, see Chapter 14, "Building Secure Data Access."

• Restrict access to sensitive commands and stored procedures . SQL Server provides powerful hooks into the operating system. For example, you can use the xp_cmdshell extended stored procedure to run any operating system command. If an attacker manages to run arbitrary commands in the database, for example through a SQL injection vulnerability, the ability to execute operating system commands is limited only by the security credentials of the account used to run SQL Server. This is the primary reason for running SQL Server with a least privileged local account.

• Use a dedicated computer as a database server . Also cluster it for failover.

• Physically protect the database server . Locate the server in a secure computer room.

• Restrict local logons . Do not allow anyone to locally log on to the server, apart from the administrator.