SQL DBA Guru

Security Standards And Best Practices

• Ensure the physical security of  each SQL Server, preventing any  unauthorized users to physically  accessing your servers.
• Only install required network libraries and network protocols on your SQL  Server instances.
• Minimize the number of sysadmins  allowed to access SQL Server.
• As a DBA, log on with sysadmin  privileges only when needed. Create separate accounts for DBAs to access SQL Server when sysadmin privileges are not needed.
• Assign the SA account a very obscure password, and never use it to log  onto SQL Server. Use a Windows Authentication account to access SQL Server as a sysadmin instead.
• Give users the least amount of  permissions they need to perform their  job.
• Use stored procedures or views to allow  users to access data instead of letting them directly access tables. 8.  When possible, use Windows  Authentication logins instead of SQL Server logins.
• Use strong passwords for all SQL Server  login accounts.
• Don’t grant permissions to the public  database role.
• Remove user login IDs who no longer  need access to SQL Server.
• Remove the guest user account from  each user database.
• Disable cross database ownership  chaining if not required.
• Never grant permission to the xp_ cmdshell to non-sysadmins.
• Remove sample databases from all production SQL Server instances.
• Use Windows Global Groups, or SQL Server Roles to manage groups of users  that need similar permissions.
• Avoid creating network shares on any SQL Server.
• Turn on login auditing so you can see who has succeeded, and failed, to login.
• Don’t use the SA account, or login IDs who are members of the Sysadmin group, as accounts used to access SQL Server from applications.
• Ensure that your SQL Servers are behind a firewall and are not exposed  directly to the Internet. 
• Remove the BUILTIN/Administrators group to prevent local server administrators from being able to access SQL Server. Before you do this on a clustered SQL Server, check Books Online for more information.
• Run each separate SQL Server service  under a different Windows domain  account.
• Only give SQL Server service accounts the minimum rights and permissions needed to run the service. In most cases, local administrator rights are not required, and domain administrator rights are never needed. SQL Server setup will automatically configure  service accounts with the necessary permissions for them to run correctly,  you don’t have to do anything.
•  When using distributed queries, use linked servers instead of remote servers.
• Do not browse the web from a SQL  Server.
• Instead of installing virus protection on a SQL Server, perform virus scans from a remote server during a part of the day when user activity is less.
•  A d d   o p e r a t i n g   s y s t e m   a n d   S Q L S e r v e r   service packs and hot fixes soon after  they are released and tested, as they often include security enhancements.
• Encrypt all SQL Server backups with a third-party backup tool, such as SQL Backup Pro.
• Only enable C2 auditing or Common  Criteria compliance if required.
• Consider running a SQL Server security scanner against your SQL servers to identify security holes.
• Consider adding a certificate to your  SQL Server instances and enable SSL or IPSEC for connections to clients.
• If using SQL Server 2005, enable password policy checking.
• Implement database encryption to protect confidential data.
• If using SQL Server 2005, don’t use the SQL Server Surface Area Configuration  tool to unlock features you don’t absolutely need.
• If using SQL Server 2005 and you create endpoints, only grant CONNECT permissions to the logins that need access to them. Explicitly deny CONNECT permissions to endpoints that are not needed by users.