Title: The DBA role must not be assigned excessive or unauthorized privileges.
Vulnerability ID: V-32242
STIG ID: SRG-APP-000063-DB-000019
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. Audit of privileged activity may require physical separation employing information systems on which the user does not have privileged access. To limit exposure and provide forensic history of activity 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. If feasible, applications should provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. DBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.
Check Text: Review access permissions for objects owned by application owners or other non-administrative users. If DBA or administrative accounts have unauthorized application roles or permissions beyond those needed for administration, this is a finding.
Fix Text: Remove permissions from DBAs and other administrative users beyond those required for administrative functions.[divider]
This STIG primarily covers the risk of “Data Snooping”. Usually the DBA is given god like rights in SQL Server, because it is easiest. They can create users, databases, files, even modify security and data if they want. This is the concern. modifying data in an application database is probably supposed to be dealt with through the application, not through the back end.
This can all be controlled using SQL Server’s server roles and database roles. By setting up security properly, you can perform actions such as prevent change and select on application data tables to the DBA. This will help prevent the “data snooping” mentioned earlier, but also helps to more clearly define the rights of the administrators to do just that, administer the database environment.
To be able to comply with this STIG means you have to know what the DBA needs to do. If you ask 6 different people the role of a DBA, you will get 8 different answers (that’s not a typo). A clear definition of their role needs to be determined by the company, documented and enforced. On a similar note, we had a situation in the past where we needed to prevent our development team from changing schema, procedures and data in the primary dbo schema of a database. This was handled using SQL Server’s native security features and helped to keep things safe and under control. Similar steps can be taken to secure the DBA users. One way is to not use the sa account. After you specify the access each user, group or role has in the system you can disable the sa account. If needed the sa account can always be re-enabled and used if full access is needed for some reason (maintenance, etc). Disabling the sa account also adds to the security because it is the most common account focused on by hackers.