October 4, 2018 at 8:26 am
Within a SQL Server 2008R2 setup what can the SA login do/access outside of SQL Server? Specifically are there any security risks to using the SQL Server SA login that are not within SQL Server? For example if you gave someone local computer admin access then they would have the ability to do more then a standard windows user. But when you connect as the SA login in a Mixed Security SQL Server implementation are there any security issues for doing this that are not SQL Server specific. For example can you some home screw with the Windows OS services by connecting to SQL Server as the SA SQL login?
BACKGROUND: We are in the process of moving our primary mission critical accounting system from being hosted in our local network to a private SASS/CLOUD provided by the software vendor. There area a number of things we currently do that require SA (or similar) access to the SQL Server instance from executing DCL commands to using all of SQL Servers tools without access issues. We've requested the use/access to the SA SQL Login or another SQL Login that is a member of the sysadmin server role and were getting push back because this is not how the vendor normally operates. Even though this is a private cloud and a private SQL Server (not shared with any of their other clients) the most they are willing to do is give us the DBOwner login info for the database itself. Its rather ironic that the vendor takes the stance that for security reasons we can;t let you access your private SQL Server when the vendors recommended security setup (how to configure the SQL Server DB to be accessed by their application) is to setup a single SQL Login with a corresponding DB User that is the DBO of that DB and have all connections from their application connect as the DBO. We of course have not followed that recommendation in our implementation which is why we need serveradmin like access to execute DCL commands. I know that there are other server roles that would allow for working with security but that's just one example of why myself and my backup are able to access the SQL Server as a serveradmin. We don't actually use the SA login but have our domain accounts members of the serveradmin role.
Ultimately we could damage the data with just DBO Login access so its not as if disallowing serveradmin access to SQL Server is somehow better protecting our data and since we've been managing this on our own for over a decade its not like as if we aren't experienced with what to do or how. I even had Paul Randals firm do a review of our SQL Server Implementation a few years back after we moved to hosting SQL Server on a VMWare setup and we got high remarks.
So in closing are there any security risks outside of SQL Server that come with allowing use of the SA SQL Login or another SQL Login that is a member of the sysadmin SQL server role?
Kindest Regards,
Just say No to Facebook!October 4, 2018 at 9:55 am
yes, the sa login can do anything inside the SQL Server, which has XPs, cmdshell, etc, with potential access outside the system. In essence, the concern is that Sa can do anything that any SQL server account can do. That's core db engine service, agent, others. Secure those, and limit permissions.
There are some permissions that are required, this includes some registry access with xp_regwrite, but I'm unsure of the scope of security vulnerabilities here.
October 5, 2018 at 12:58 pm
Steve Jones - SSC Editor - Thursday, October 4, 2018 9:55 AMyes, the sa login can do anything inside the SQL Server, which has XPs, cmdshell, etc, with potential access outside the system. In essence, the concern is that Sa can do anything that any SQL server account can do. That's core db engine service, agent, others. Secure those, and limit permissions.There are some permissions that are required, this includes some registry access with xp_regwrite, but I'm unsure of the scope of security vulnerabilities here.
What about a SQL login that is not the SA but a member of the serveradmin role?
Kindest Regards,
Just say No to Facebook!October 11, 2018 at 11:44 am
have to be careful here Serveradmin gives you some stuff. Not sure to the extent they can get to xp_cmdshell, but if you can change the registry, you can really mess with the machine. I won't pretend to know all attack vectors, but I tend to assume that anyone with server/sys admin needs to be watched.
October 11, 2018 at 12:38 pm
Ok thanks for the input Steve. The one good bit about this is that when performance goes to SHFT it will be ne the Vendor to explain to our CFO/CEO what's going on and not me.
Kindest Regards,
Just say No to Facebook!Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply