Title: Use of the DBMS software installation account must be restricted to DBMS software installation.
Vulnerability ID: V-32245
IA Controls: None
Description: This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.
To limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.
Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.
The DBMS software installation account may require privileges not required for database administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them.
Check Text: Review system documentation to identify the installation account. Verify whether the account is used for anything beyond DBMS software installation, upgrade, and maintenance actions. If the account is used for anything beyond DBMS software installation, upgrade, and maintenance actions, this is a finding.
Fix Text: Restrict usage of the DBMS software installation account to DBMS software installation, upgrade, and maintenance actions only.
Disable installation accounts when authorized actions are not being performed.[divider]
This STIG is basically saying you should not use the service, or DBA accounts to perform actions on the server itself. This includes patching SQL Server with service packs or hot fixes. There should be a separate account created for this activity, and it should be left in an inactive or disabled state until it is required for an update or patch.
You can try to determine what account was used to perform the installa c ouple of ways. One is to check the applicatiobn log for the login used.
To do this you need to know when SQL Server was installed.
SELECT createdate as Sql_Server_Install_Date
where sid = 0x010100000000000512000000
The above snippet of code will tell you when the default system account was installed / created in SQL Server.
Then, if your server application log had not been cleaned since install, you can check around the time returned by the query for the installation. Don’t forget to add the login column to the viewer though.
If you cannot determine the account used for the installation, verify the accounts that are active on the system that are used regularly, document accordingly and remove or disable any accounts that have excessive access. If you know which accounts did perform the installations, make sure to update documentation accordingly, and adjust permissions on the server properly. If you used your own local admin account, then setup a new account to use for future updates, and modify the permissions of the active account accordingly.