SQL Server Security Policy

SQL Server Security Policy allows a basis for good practise and regular audits. A SQL Server environment is characterised by various developers(internal), administrators (internal) and third party access.All these groups must be considered when creating a policy.

The list becomes the basis of a customised security policy and Security Audit. An organisation will have specific security needs and also observations are made to enhance security
 I will in a future post , present a detailed framework of how to create a SQL Server Security Policy
1. Ensure the physical security of each SQL Server. Prevent any unauthorised access.
2. Only required libraries and network protocols should be installed.
3. Minimise the number of sysadmins allowed to access the SQL Servers
4. Even for DBAs, only logon with sysadmin privileges when required. Create separate accounts for DBAs to access when sysadmin privileges are not required.
5. Ensure an obscure password for SA , and NEVER use it to log onto the SQL Server. Use a Windows authentication account to access SQL Server as a sysadmin
6. Give users the least amount of permissions they need to perform their job.
7. Use stored procedures / views to allow users to access data instead of letting them directly access tables.
8.  Aim for Windows authentication logins rather than SQL Server logins.
9.  Define strong passwords for all SQL Server login accounts.
10. Ensure the public database role has no permissions.
11. Remove user login IDs who no longer need SQL Server access.
12. Remove the guest user account from every user db.
13. Disable cross database ownership chaining . Must justify a case to turn it on.Currently , can be accidentally added via the service pack install
14. Don’t allow non-sysadmins permission to xp_cmdshell.
15. Remove sample databases from all servers. Production and development. Currently prevalent on a number of servers
16. Use Windows Global groups or SQL Server roles to manage users that need similar permissions.
17. Avoid creating network shares on any SQL Server. If necessary , document and manage
18. Use login auditing to monitor who is (and isn’t logging in)
19. Don’t use the SA account , or loginIDs who are members of the sysadmin group , as accounts used to access SQL Server from applications
20. Make sure all SQL Servers are behind a firewall21. Remove the BUILTIN/Administrators group to prevent local server administrators from accessing SQL Server. Note: Slightly different if clustered.
22. Run each separate SQL Server service under a different Windows domain account.
23. Only give SQL Server service accounts the minimum rights and permissions needed to run the service. Normally local administrator rights are not required , and domain adminsiatrtor rights are never required. The setup procedure configures automatically the relevant permissions
24. Use Linked Server not remote servers for distributed queries
25. Disallow browsing from the SQL Server
26. Virus scanning. Perform virus scanning from a remote server.
27. Ensure the latest service packs/hot fixes are in place.
28. Run a SQL Server security scanner regularly.

 
Related Posts on security planning

Powershell sql server security audit 
Stored Procedure Checklist

SQL Server – How to manage Failed Logon attempts