DEV Community

jeffrey
jeffrey

Posted on

Database Backups Are an Identity Problem Before They Are a Storage Problem

#backup #ransomware #identity

Database Backups Are an Identity Problem Before They Are a Storage Problem

Backup programmes are usually evaluated on coverage and restore time. Both matter, and both miss the question that decides whether a backup survives an incident: who can read the backup, and who can delete it.

A backup that is encrypted at rest but readable by the same account that was compromised provides no protection. A backup that can be deleted by a domain administrator provides no recovery. The controls that decide this are identity controls, and they are often the least examined part of the backup design.

The two failure modes that matter

Backup failures during a ransomware incident fall into two categories.

Destruction. The attacker deletes or encrypts the backups before triggering the main event. This is common because backup infrastructure is usually reachable with the same credentials as the rest of the estate. If the backup server is domain-joined and the backup service account is a domain account, compromising the domain is enough to destroy the recovery path.

Exfiltration. The attacker reads the backups instead of destroying them. A database backup contains the data the organisation was protecting, often in a form that is easier to parse than the live system. Encryption at rest does not help if the attacker can obtain the key through the same identity path.

Both failure modes trace back to the same design question: does the backup system share an identity boundary with the systems it protects?

Why shared identity defeats immutability

Immutability features are valuable and frequently misunderstood. Object-lock and write-once storage prevent modification of backup data for a defined retention period. They do not prevent a privileged identity from deleting the bucket, changing the retention policy, or disabling the feature, unless the identity that can do so is separate from the identity that can compromise the production estate.

The practical test is simple: if an attacker who has obtained domain administrator rights can reach the controls that govern backup retention, the immutability is a configuration rather than a boundary.

Separating the boundaries means the backup platform has its own administrative identity, its own authentication path, and its own logging that production administrators cannot modify. That is a meaningful architectural commitment, and it is the difference between a backup that can be destroyed and one that cannot.

Restore testing is the only proof

A backup that has never been restored is a hypothesis. Coverage reports describe what was scheduled, not what can be recovered.

Useful restore testing has three properties:

  • It restores to an isolated environment. Restoring over production proves nothing about the backup and risks the production system.
  • It measures time to a usable state. The relevant number is how long until the application is serving again, not how long the file copy took.
  • It includes the identity path. The test should confirm that the restore can be performed by the recovery team using credentials that are available during an incident, which may not be the credentials used day to day.

The third property is the one most often skipped. Teams test that the data restores and never test that they can authenticate to the restore process when the primary identity provider is unavailable.

Credentials that survive the incident

Recovery depends on access to credentials that the attacker does not have. This requires at least one identity path that is outside the compromised domain.

Common approaches include:

  • A separate administrative directory for backup infrastructure, not trusting the production domain.
  • Break-glass accounts with credentials stored offline and rotated after use.
  • Hardware-backed authentication for the recovery path, so a stolen password alone is insufficient.

Each of these adds operational cost. The cost is the point: the recovery path should not be reachable with the same ease as the systems it protects.

What to check first

A short audit that produces useful answers:

  1. List every identity that can delete a backup or change its retention. Include service accounts, management planes and any role that can modify the storage policy.
  2. Confirm whether those identities are in the same directory as production administrators. If they are, the boundary does not exist.
  3. Verify the last successful restore to a usable state, with the time recorded. A restore that has not been performed is not evidence.
  4. Test the recovery path with the primary identity provider offline. This is the scenario the design is supposed to survive.

The answers are usually uncomfortable, which is why the exercise is worth running before an incident forces it.

Defensive implications and limits

Separating backup identity from production identity reduces the chance that a single compromise destroys recovery. It does not make the organisation immune, and it does not remove the need for detection. An attacker who can operate inside the backup platform for long enough may still find a path, particularly if the platform itself has an unpatched vulnerability.

The limits are worth stating. Immutability features vary in how completely they resist a privileged administrator, and the details depend on the specific platform and configuration. Restore testing consumes time and infrastructure. Break-glass credentials require a rotation discipline that many teams do not maintain.

The argument is not that these controls are perfect. It is that a backup programme evaluated only on coverage and restore time is measuring the wrong things. The question that decides survival is who can reach the backup, and that question has an identity answer.

References

Top comments (0)