By: Jeremy Kadlec | Comments | Related: > Auditing and Compliance
Problem
In earlier tips from the sa series we outlined 'When not to use the sa password' and 'When was the last time the sa password changed?'. In this installment of the sa series we will be outlining options for password management. In a nutshell, depending on the security needs of the organization dictates how the sa password should be managed. Although at a certain level, the sa login needs to be protected even in environments without specific legal or regulatory requirements. As the security needs increase, then it is necessary to implement additional measures to manage and protect the most privileged (out of the box) login in SQL Server, the sa login.
Solution
As a DBA\Developer it is necessary to handle any privileged account's password with great care. As such, here are some techniques to do so:
- Do not use the sa login unless necessary and when you think it is necessary research other options to validate no other options exist
- Do not let any applications get promoted to the production environment if they use the sa login
- Use an electronic or physical password safe to manage the passwords to ensure they are stored in a secure location as opposed to a sticky note or some other easily accessible location
- Create a password with 20+ characters (mixed case), numbers, symbols
- Have a limited number of DBAs\Developers know the password or have access to the password to limit the potential exposure
- Audit the login usage to the SQL Server error log or capture the usage with Profiler or a third party tool
|
SQL Server 2005 - Login Audits |
|
|
- Change the password on a regular basis whether that is monthly, quarterly, semi-annually
- Ensure that changing the password is not a chore
- Change the password when a DBA\Developer who knows the sa password leaves the organization
- If you are in a secure environment, split the password between 2 DBAs so 1 DBA knows the first half of the password and another DBA knows the second half of the password
- If you are using SQL Server 2005, leverage the new password options of 'Enforce password policy' and 'Enforce password expiration'
|
SQL Server 2005 Password Management Options |
|
|
- Setup different sa passwords for each server, so that if the sa password is compromised on 1 server all of the servers are not compromised
- If that is not feasible, setup different sa passwords between environments i.e. development, test and production or setup different sa passwords based on the application environment i.e. financial, legal, manufacturing, human resources, etc.
- Move to mixed mode authentication model and rely on the Windows capabilities to manage the user name and passwords in SQL Server
- Know the portions of SQL Server (i.e. Reporting Services, Analysis Services, etc.) that do not use the sa password and have a separate administrative access paradigm
Next Steps
- Evaluate how the sa password or any login\account password is handled in your environment to determine if it is secure enough or if changes should be made for how the passwords are managed.
- Take a good hard look at your environment to determine how the passwords should be managed in a reasonable manner. What works for 1 environment may not work for another, but at some level the passwords should be managed to offer a viable means for protecting the most privileged login in SQL Server.
- Check out these related tips on MSSQLTips.com:
About the author
Jeremy Kadlec is a Co-Founder, Editor and Author at MSSQLTips.com with more than 300 contributions. He is also the CTO @ Edgewood Solutions and a six-time SQL Server MVP. Jeremy brings 20+ years of SQL Server DBA and Developer experience to the community after earning a bachelor's degree from SSU and master's from UMBC.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
