The account the backup software uses to read production usually holds far more privilege than the job requires. Domain administrator, or a role close to it, plus full rights on the hypervisor, plus local administrator on every guest. It gets provisioned that way because it is the fastest path to a working backup, and it stays that way because nobody wants to be the person who broke the nightly run by removing a permission.
The consequence is that a single credential can read every file in the estate and, in most configurations, write to the backup repository as well. Anyone who obtains it inherits both halves of the problem: the ability to copy data out and the ability to interfere with the copies meant to recover from it. Least privilege is the standard answer, but it gives no guidance on which rights to remove first, or how to tell whether removing one will fail a job three nights later.
Backup requirements are workload specific and narrower than most deployments assume. For virtual machines backed up through the hypervisor, the backup account needs rights to create and delete snapshots, read virtual disks and browse the inventory. It does not need to power machines on or off, reconfigure hardware, modify networking or manage hosts, although the built in roles that grant snapshot rights frequently include all of those.
For file servers, the requirement is read access to the data and the ability to read security descriptors so that permissions restore correctly. That is often satisfied by a backup operator style privilege rather than by membership in an administrators group. For databases, the requirement is the backup role the database engine defines, not ownership of the instance and not membership in the server administrator role.
Application aware processing is where the line moves. Quiescing a database inside a guest requires credentials inside that guest, which is a genuine need rather than convenience. It is still a per guest need, so it can be met by a credential scoped to the guests running those applications rather than one that works everywhere.
Excess privilege arrives from three directions. The first is the initial deployment, where the fastest way to get every job green is an account that already works on everything. The second is troubleshooting: a job fails, rights are added to test a theory, the job succeeds and nothing is removed afterward. The third is creep in the estate rather than the account, since an account sized for twelve servers is rarely revisited at eighty.
Built in roles contribute as well. Platform vendors ship coarse roles that bundle backup relevant permissions with unrelated ones, so selecting the obvious role grants a superset of what is required. Custom roles are supported on every major platform and are the mechanism by which the superset gets trimmed.
The result is worth naming plainly, since it is the same failure of separation that makes separating backup administration from general administration worth doing. One identity that can read everything and write to the backup target collapses two controls into one.
The production side credential and the storage side credential have different blast radii, and treating them as one is the common structural mistake. The production credential reads source data. The storage credential writes backups to the repository. Neither needs the other's rights, yet they are often the same account or stored in the same place, so one compromise yields both.
On object storage, the storage side credential is an S3 access key with a policy attached, and that policy is where scope gets expressed concretely. A backup job needs to put objects and list a bucket. Whether it needs to delete objects depends on how the backup software manages retention, and it is worth establishing rather than assuming, because a key without delete rights is a materially different thing to lose than one with them.
Object Lock adds a second distinction. Writing objects under a retention period and being able to lower that retention are separate permissions. A key that can write immutable objects but cannot alter lock settings is the configuration most environments want, which is part of what distinguishes a hardened repository from object storage with Object Lock in practice.
| Workload | What backup genuinely needs | What it is commonly granted |
|---|---|---|
| Virtual machines via hypervisor | Snapshot create and delete, virtual disk read, inventory browse | A built in administrator role covering power state, hardware and host configuration |
| File servers | Read access to data plus the right to read security descriptors | Local or domain administrator on each server |
| Databases | The engine's own backup role on the specific instances | Server administrator or instance ownership |
| In guest application processing | A credential valid on the guests running those applications | One domain credential valid on every guest in the estate |
| Object storage repository | Put and list on one bucket, delete only if retention requires it | A key with full access across all buckets in the account |
| Lock and policy administration | Held by a person, used rarely, outside the job credential | Included in the same key the backup jobs use nightly |
Reduction fails when it is done in one pass across the whole estate, because the first failure is attributed to the change rather than to a specific missing right, and the change gets reverted wholesale. A narrower method works better. Create the reduced role alongside the existing one, apply it to a single job covering a representative workload, and leave the original account in place on everything else.
Run that job through a full cycle rather than a single pass. Many permissions are exercised only on operations that do not occur nightly: synthetic full builds, retention processing, health checks and consistency verification. A reduced scope that survives one incremental run and fails on the first synthetic full has not been tested, it has been sampled.
Then test restore, the step most often skipped. Restore paths use permissions that backup paths do not, particularly for writing files back with original security descriptors and for registering a recovered virtual machine. A scope that backs up cleanly and cannot restore is worse than the broad account it replaced. Where the reduced account lives matters too, which is the argument for keeping backup identities off the production domain.
ARTESCA is object storage software used as a backup target, presenting an S3 compatible API. The credential a backup application uses to write to it is an S3 access key governed by a bucket policy, which is a separate object from whatever account the backup software uses to read production. That separation is structural rather than a matter of configuration discipline, since the two credentials are issued by different systems.
Immutability is provided through S3 Object Lock, so retention is enforced on the object by the storage layer. The permission to write locked objects and the permission to change lock configuration on a bucket are distinct, which allows the key used by nightly jobs to be narrower than the key used to administer the bucket.
Because deployment happens on infrastructure the customer runs, key issuance, rotation and storage remain local decisions. How many keys exist, which hosts hold them and how often they change is set by the operating team rather than by the platform.
Produce one page listing every identity involved in backup: the production side account, the storage side keys, and any in guest credentials. For each, record what it can reach, where it is stored, which host uses it and when it last changed. Most teams find during this exercise that at least one credential has no clear owner.
Review that page twice a year and after any material change to the estate. The question is not whether permissions are minimal in the abstract, but whether each right is still exercised by a job that still exists. Rights granted for a decommissioned workload are the easiest to remove safely.
Rotate the storage side key on a schedule and confirm afterward that jobs continued under the same identity. Rotation is also a useful control signal, since an unscheduled rotation appearing in a log is one of the configuration changes worth reading twice rather than skimming.