SQL Server user-security checklist

As DBAs, security is not usually a primary concern. Connectivity and availability are more immediate concerns, but unless you want an angry visit from your security administrator, security should be added to the list. Below is a checklist that SearchSecurity.com writer Mike Chapple advises security administrators to use when locking down SQL Server; it can be taken into consideration by DBAs as well.


Here are four actions you can take today to help ensure the security of your SQL Server:

  1. Limit the number of database administrators. This is a common-sense rule that's often violated. Make sure that only people who need administrative powers (and know how to use them!) have DBA access. SQL Server's tight integration with Windows makes it far too easy to simply grant database administration rights to all domain administrators. This can be a grave mistake.
  2. Apply the rule of least privilege. Ensure that folks with administrative access (and user-level access, for that matter) have the smallest subset of privileges necessary to carry out their job functions.
  3. Avoid hard-coded passwords like the plague. Database developers like to hard-code passwords in their programs because it's the easy way out.

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information:

By submitting your registration information to SearchSQLServer.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here

  • Your use of SearchSQLServer.com is governed by our Terms of Use
  • We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
  • If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.
  1. Don't let them do it! Use SQL Server's Integrated Authentication mode to tie into Windows security or force users to authenticate to the database itself. If you hear the statement, "We can't change the password or XYZ will break," consider it a big red flag waving in your face!
  2. Make use of roles. SQL Server offers a number of predefined user roles that grant specific administrative privileges. You may also create your own customized roles for your environment-specific needs. Assign permissions on your database to these roles, and then add and remove users/groups from these roles as their job responsibilities change. This makes for a much tidier security environment and allows you to keep tabs on access controls.

Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.


This was first published in March 2005

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.