Experience Report for Feature Request
v20.07.0, backups require essentially root access (i.e.
guardians group) to trigger backup. This requires exposing the keys to be able to handle operational lifecycles like backups. Thus to have business continuity (disaster recovery, risk mitigation), users must compromise their security and increase their attack surface to facilitate backups.
What you wanted to do
I would like there to be a new group
backups whose membership will allow backup operations to be performed, and not have other unnecessary administrative privileges. This way, a user with backups membership would not be able to delete users or grant other users membership
What you actually did
Really, there is nothing that can be done to mitigate the risks of having admin credentials used stored on a system that schedules the backups.
Users can use extraordinary measures, such as sealing them in Hashicorp Vault infrastructure, but the risk of elevated admin credentials is still there.
Why that wasn’t great, with examples
The risk to have unnecessary administrative privileges to automate backups cannot be avoided.
Any external references to support your case
This is well-known security principal and required for audits in the industry.
For example, on Linux, ssh is often configured to prevent root login, because it is that dangerous.
Similarly, many systems, such as Microsoft Active Directory and Windows Server, have a backup operators group that allows members to do backups but does not have other unnecessary administrative privileges (ref. link).
Oracle Database has a
SYSBACKUP user (ref link) different from
SYSDBA that has limited privileges necessary to do backups.