One of my favorite descriptions of the DBA’s job is “the guardian of data.” DBAs often get requests from developers, users, and others to access various parts of SQL Server. Often, we’ll get asked to give someone sys admin, or sa, access. This is the most powerful level of access in SQL Server and I always look at those requests with a good dose of skepticism and basically ask the person asking for the access to prove to me that they really need it.

And occasionally, I’ll get a vendor who claims their software needs sa rights to run. (If that’s truly the case, then I don’t want their software running in my environment.) I had such a request yesterday – a vendor wanted not only serveradmin rights, but sysadmin rights as well (even though the later includes the rights of the former). I refused to provide it and the person requesting it (who was stuck between me and a vendor who was telling him they needed it), rightly escalated the issue to management. Here’s how I presented the issue to managment:

Just as a brief overview, it is against not only Microsoft best practices, but IT industry-wide best practices to give sysadmin rights to a login used by an application. The security risks are huge. A SQL Server account with sysadmin rights can do anything on the server to any database, including deleting databases, creating and deleting new logins, assigning rights to other logins, extracting data, and shutting down the server. But the risks do not stop within SQL Server. SQL Server sys admins also have access to the xp_cmdshell command, which lets them issue commands against the Windows operating system, thus providing an opening to our entire network. I am not fully aware of what auditing and security regulations / laws apply to our industry, but it is entirely possible this request would violate those policies as well.

I have found in the past that most software vendors tend to not have a complete grasp of SQL Server security levels. Often, they encounter some problems that they can make go away by granting sysadmin rights. This is usually overkill. It might eliminate their problem, but it opens up a host of other potential, far greater, problems. It is my belief, based on this request from <vendor name redacted>, that they are in this situation. Indeed, their request is superfluous – if an account has sysadmin access, it already has all the rights obtained via the serveradmin access level and does not need that access granted as well.

I am happy to work with them to determine exactly which level of access they need. Sometimes, sysadmin rights are only needed temporarily, for an upgrade or new installation. I am agreeable to temporarily granting sysadmin rights in situations like these, provided I can revoke them as soon as the upgrade or installation is completed. I will also grant the requested rights if that is what the software truly needs to function on a day to day basis, but I strongly recommend against it and against using any program that requires such rights to run. I just want to make sure management is fully aware of the risks involved in this request.

(I know I can disable the xp_cmdshell function, but it is currently enabled on this particular server and, as I am still somewhat new here, I am not sure what turning it off might break.)  The goal of my email was not only to present the dangers this requests posed, but also to position myself not as someone blocking a request, but as someone who is willing to work to find an alternative solution.

The answer came back from management almost immediately – no sa access. They asked the vendor to come up with another solution.