SQL 2012: Best security practices for the DBA account

  • I'm getting to set-up a new SQL Server instance from scratch for the first time. I would like to follow-up best practices for security from the start. Previously, our practice has been to login as sa to perform maintenance in SSMS, and manage databases. I've read this is not best practices; I've read it a good idea to rename sa, and I've read that is not a good idea to rename sa. Therefore, if I wish to create an account solely for DBA management, what is the best method to do this?

  • If you are on a domain the most secure method is to use Windows Authentication only when you install SQL Server. If you have to have mixed authentication, you shouldn't rename sa, but you should disable it. You should still use domain accounts for DBA's, I actually recommend that this be a different account than your normal domain account, which you use only for doing DBA work. This way when you are logged in to your workstation with your regular account for email, etc... you aren't exposed if your workstation gets compromised.

  • Thank you Jack.

  • All privileged activities should be used by an account that is traceable to an individual. Auditors should be insisting on this. In fact if you are SOX or fed regulated this should be standard practice.

    Using a separate domain account for the privileged activities ta sits alongside your main domain account is also an excellent way to offer separation of roles.

    As a employee you would have standard employee access to systems and only your prv domain account as the ability to make administrator level changes.

    Starting tools using a 'runas' command only takes a few seconds longer than a double click and makes you think a little harder about what you are doing.

  • Steven thank you for the advice.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply