What's the issue?
The sysadmin fixed server role in SQL Server grants its members complete control over the entire SQL Server instance and every database it hosts. Membership is granted by adding logins (Windows accounts, Active Directory groups, or SQL logins) to the role, either explicitly through sp_addsrvrolemember or ALTER SERVER ROLE, or implicitly through other paths such as the local Windows Administrators group on older configurations and the SQL Server service account itself.
This finding identifies the logins currently included in the sysadmin role on a SQL Server instance. The intent of the review is to confirm that only approved accounts have this level of access and to remove any that do not require it.
Why is this a problem?
Membership in sysadmin is the most powerful permission inside SQL Server and bypasses all permission checks within the database engine. Any account in this role can read, modify, or drop any object in any database on the instance, regardless of the explicit permissions assigned to those objects.
A sysadmin can take and restore backups, including restoring databases to other servers or external locations, which is effectively a path to data exfiltration. They can change the permissions of every other login and user on the instance, create and modify SQL Server Agent jobs that run arbitrary code under the service account context, and enable features such as xp_cmdshell to execute operating system commands. They can also alter audit configuration, drop traces and Extended Events sessions, and modify or remove evidence of their own activity.
Sysadmin level access also extends beyond the database engine in subtle ways. A sysadmin can change the SQL Server service account configuration through certain features, install or modify CLR assemblies, and use linked servers to reach other SQL Server instances with the credentials configured on those links. In environments with multiple instances or trust relationships between servers, a single compromised sysadmin account can become a pivot point for broader compromise.
Excessive membership in sysadmin also undermines audit and compliance posture. Regulatory frameworks such as PCI DSS, HIPAA, SOX, and ISO 27001 require that administrative access be granted on a least privilege basis and that membership in privileged roles be reviewed and justified. A sysadmin role with many members, with stale entries from former employees, or with broad Active Directory groups granted membership creates audit findings and increases the blast radius of any compromised credential.
What should you do about this?
Evaluate the current members of the sysadmin role by querying sys.server_principals joined to sys.server_role_members, filtering for the sysadmin role. Capture the membership and review each entry with the security team and the SQL Server owners.
Confirm that every member belongs in the role based on a current, documented job role. Remove individual user accounts that do not require sysadmin and grant them the more specific permissions they actually need using fixed server roles such as dbcreator, securityadmin, serveradmin, or processadmin, or with granular permissions on specific databases and objects. Most developers, analysts, and application support staff do not need sysadmin to do their jobs. For applications that connect with sysadmin level accounts, work with the application owners to identify the actual permissions required and reconfigure the application to use a least privilege account. Many applications request sysadmin during installation but only need a smaller set of permissions for ongoing operation, and the difference matters significantly for security posture.
Remove broad Active Directory groups from sysadmin and replace them with narrowly scoped groups whose membership is managed centrally and reviewed regularly. The SQL Server service account itself does not need an explicit sysadmin login, since SQL Server grants the service account the necessary internal access without requiring a login at all on modern installations.
Read more...
Vulnerability
Category
What do the Vulnerability Levels mean?
0 - Information only. This is stuff you should know about your instances like version and service account used, but if you don't know it…well, now you do.
1 - High vulnerability requiring action. These are the issues that could most likely lead to your company being front page news for all the wrong reasons. If your instances have any results at this level then we recommend cancelling that 3-martini lunch and instead huddling with your team to figure out when to address these issues.
2 - High vulnerability to review. These include settings and assigned permissions you should review soon, if not immediately. These findings may not necessarily indicate a clear vulnerability, but we've found unexpected vulnerabilities in these categories at many, many clients.
3 - Potential vulnerability to review. These are configurations or assigned permissions you may be using that could lead to problems for users. Or maybe they're just required for your applications. Either way, we recommend reviewing these to make sure these are correct.
4 – Low vulnerability with recommended action. These are typically security inconsistencies that should be addressed. They aren't likely to cause problems, but you should clean up the mess.