Hi,
The situation you described highlights a common challenge in balancing security requirements (STIG V-213934) with the operational needs of a system (Microsoft DPM backups). Let's explore the options and potential solutions:
- Revoking sysadmin role from NT AUTHORITY\SYSTEM: As per the STIG requirement (V-213934), the sysadmin role should not be assigned to the NT AUTHORITY\SYSTEM account. However, as you mentioned, this prevents DPM from performing database-level backups.
- Creating a new account with sysadmin role: One possible approach is to create a new SQL Server login with sysadmin privileges and use this account for DPM backups instead of NT AUTHORITY\SYSTEM. This should allow you to revoke sysadmin role from NT AUTHORITY\SYSTEM while still enabling backups through DPM. Ensure that the new account has the necessary permissions to perform backups.
- Using a service account for backups: Instead of using NT AUTHORITY\SYSTEM or creating a new login, you can use a dedicated service account with the sysadmin role for DPM backups. This service account should only be used for backup purposes, reducing the risk associated with having the sysadmin role granted to a widely used account like NT AUTHORITY\SYSTEM.
- Custom backup solution: If none of the above options work, you might consider building a custom backup solution that handles database backups outside of the sysadmin role context. This solution could use a combination of SQL Server permissions and other mechanisms to perform backups without relying on the sysadmin role.