Separation of duties is written for organizations with enough people to separate. A team of four that owns servers, networking, virtualization and backup between them cannot hand each privilege to a different person, and pretending otherwise produces a policy document nobody follows. The useful question is narrower. Out of everything a backup administrator can do, which two or three actions are worth pulling into a different account, and what does that actually cost to run.
The answer is not determined by job titles. It is determined by which actions destroy data permanently and which are reversible. A bad restore can be run again. Deleting a repository, shortening retention, or rotating the storage keys cannot be undone, and those actions happen rarely enough that friction around them costs almost nothing.
That asymmetry is what makes separation affordable. The goal is not to prevent the backup administrator from working. It is to ensure that a single compromised session, or a single bad afternoon, cannot remove the copies recovery depends on.
Why the textbook model does not fit four people
Formal separation of duties assumes roles that never overlap: an operator who runs jobs, an administrator who configures them, a security owner who approves changes, an auditor who reviews. In a team of four with on-call rotation, each of those people will eventually need to do all four at two in the morning, and any control that blocks that is removed within a month.
The version that survives contact with a small team is different. Everyone keeps the daily work under their normal account. A few high-consequence actions require a second account that is not used daily, is not in the same groups, and is not logged in on the workstation where email is read.
That is one extra credential per person, or in many cases one shared credential with a documented checkout procedure. It is a real cost, and it is small enough to be sustainable, which matters more than whether it matches a framework diagram.
Restores and retention are not the same privilege
The first seam worth cutting is between running a restore and changing what is kept. Restoring is the operation the team performs under pressure, and it should be available to everyone without an approval step. It reads data and writes into production. It does not reduce the protection that exists.
Changing retention does reduce it, and it does so quietly. A retention value edited from thirty days to seven produces no alert in most environments, no failed job and no visible change for three weeks. By then the copies are gone. Removing a machine from a job's inclusion list has the same practical result as deleting its backups, delayed by the retention period.
Most backup products express this split through built-in roles, with a restore operator role that cannot modify job configuration. Where the product cannot, account discipline achieves the same thing: a daily account that performs restores and a separate administrative account used only for configuration, with changes to retention and job scope alerted on.
Storage credentials do not belong to the backup administrator
The second seam is the one most often missed. The credentials the backup software uses to write into object storage are not the same thing as the credentials that administer the storage platform, and they should not be held by the same person or stored in the same place.
The reason is mechanical. The access key configured in the backup job needs permission to put objects and, depending on the design, to list and read them. It does not need permission to change bucket configuration, alter lock settings or delete the bucket. When those permissions travel together, an attacker who reads the backup server's configuration inherits the ability to reconfigure the protection rather than only to write through it. Scoping that key is the subject of what a backup service account actually needs.
The storage administrative credential should live somewhere the backup server cannot reach: a password manager entry for a separate account on the storage platform, ideally authenticated outside the production directory. It is used a handful of times a year, so the inconvenience is bounded.
| Action | Who should be able to do it | How the split is enforced |
|---|---|---|
| Restore a file, mailbox or virtual machine | Everyone on the team | A product role limited to restore operations |
| Change job retention, schedule or scope | Two named people | A separate admin account, with alerts on the change |
| Delete a repository, job or backup chain | One person, with a second informed | Restricted role plus lock settings that outlive the deletion |
| Create a bucket or change lock settings | The storage owner, not the backup admin | Storage-side credentials held outside the backup console |
| Rotate or reissue storage access keys | The storage owner | Password manager entry with checkout recorded |
| Change membership of backup admin groups | The directory owner | Group change alerting, reviewed quarterly |
Repository deletion and bucket policy
The third seam concerns the two actions that remove protection outright. Deleting a repository or a job inside the backup product removes the index and, depending on configuration, may issue delete calls against the storage. Changing the bucket policy or lock configuration on the storage side changes whether those calls succeed.
Keeping these on different sides of a boundary is the most valuable split available to a small team, since no single account can then both request deletion and authorize it. A backup administrator can delete a job, and the objects stay under retention until their dates pass. A storage administrator can change a bucket policy, and has no reason to be in the backup console.
The choice of lock mode determines how firm that boundary is. Governance mode retention can be lifted by an identity holding the right permission, which makes the question of who holds that permission the whole control. Compliance mode cannot be lifted by anyone, which removes the question and replaces it with a capacity commitment. The tradeoff is worked through in governance and compliance mode.
Deletion pressure does not only come from outside. A departing administrator, or one under a performance process, holds exactly the access the model above constrains, which is why the same splits are the practical answer to insider deletion risk.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs, at capacities from roughly 50 TB to 8.5 PB. It presents an S3-compatible API with S3 Object Lock, so retention is enforced by the storage layer against any request, including requests from an administrator of the backup software.
Because it runs on the customer's own equipment, the identity arrangement around it is a customer decision rather than a platform default. Administrative access can be authenticated separately from the production directory, and the access key issued to the backup application can be a different credential with a narrower permission set.
That separation is what turns the splits described above from a policy statement into an enforced boundary. Where both credentials resolve to the same account, the boundary exists only in documentation.
What to write down and review
Produce one page listing four things: who can run a restore, who can change retention or job scope, who can delete a repository, and who holds the storage administrative credential. Names, not roles. A team of four can fill this in during one meeting, and the exercise usually surfaces at least one credential nobody could account for.
Review it quarterly and after every personnel change. The review is short: confirm the group memberships still match the page, confirm the storage credential has not been copied into the backup console for convenience, and confirm that the alerts on retention changes and repository deletion still fire by triggering one deliberately.
The last part matters more than it sounds, since an alert that has never been tested is an assumption. Change a retention value on a test job, confirm somebody receives the notification, change it back, and record the date. Three splits that are enforced and monitored beat a full model that exists only on paper.