Backups Are a Target Too: Encryption, Access Control & Ransomware-Aware Retention

Backup & Disaster Recovery Basics

Chapter 8 · Backups Are a Target Too: Encryption, Access Control & Ransomware-Aware Retention

Chapter 3 flagged ransomware as the modern reason "1 offsite" matters. Chapter 7 flagged a lost encryption key as a real restore failure. This chapter ties both together: a backup isn't just a recovery tool sitting quietly in the background — it's a complete copy of everything sensitive an organization has, and it needs to be protected as seriously as the production systems it exists to save.

Why Backups Are an Attractive Target

A backup often contains a full copy of every sensitive record an organization holds, frequently with less day-to-day scrutiny than the production systems it was copied from — a backup server is sometimes treated as "just storage," monitored and access-controlled less carefully than the systems everyone already watches closely. This is the same reasoning `secsupport1` applied to a support workstation being a pivot point — broad reach, sitting behind comparatively weak protection.

Encryption: At Rest and In Transit

An unencrypted backup is a second complete copy of every sensitive record, potentially sitting with weaker protection than the original ever had. Backups need encryption both at rest (while stored) and in transit (while being copied offsite or to the cloud) — a backup traveling across a network unencrypted is exposed exactly the same way any other unencrypted transfer would be.

Key Management, Done Separately From the Data

Chapter 7 covered what happens when a decryption key is lost or inaccessible — a genuine restore failure, distinct from any problem with the backup's own data. The underlying discipline that prevents this is the same one Chapter 3 already established for the backup itself: a key stored alongside the data it protects doesn't provide real protection, since anything that reaches the backup also reaches the key sitting right next to it. Keys need their own separate, secured storage — accessible when genuinely needed, but never bundled with the data they unlock.

Access Control: Least Exposure Applied to Backup Systems

Not everyone who has legitimate access to production data should automatically have access to the backup systems that store copies of it, and the reverse holds too. This is `secsupport1`'s own least-exposure principle, applied specifically to backup infrastructure: access to restore, and especially access to delete, backups should be limited to the people who genuinely need it — not granted broadly just because an account already has administrative rights elsewhere.

Immutable Backups: The Direct Ransomware Defense

An immutable backup can't be modified or deleted by anyone — including an account with otherwise-full administrative rights — until a defined retention period actually expires. This directly defeats the specific ransomware behavior Chapter 3 already flagged: ransomware that seeks out and destroys accessible backups can't touch a copy that's locked against deletion, even if it manages to compromise an account that would normally have permission to delete it.

Worked example: the backup that survived because it couldn't be deleted
A ransomware attack compromises an organization's admin credentials and specifically targets its own backup NAS first, deleting weeks of backups before encrypting production data — exactly the pattern Chapter 3 warned about. One copy survives: an immutable offsite backup that the retention lock prevented from being deleted, even using the very admin credentials the attacker had already compromised. That one surviving copy is what makes real recovery possible at all.

Retention: Neither Extreme Is Right

Keeping backups for too short a window limits how far back a recovery can reach — directly relevant when a problem isn't noticed immediately, exactly as Chapter 4's own three-week silent failure demonstrated, or when corruption or a slow-burning compromise isn't discovered until well after it began. Keeping backups indefinitely raises storage cost and creates more copies of sensitive data sitting around, each one its own potential exposure. A deliberate, defined retention window balances both concerns, rather than defaulting to either extreme.

Don't grant deletion rights routinely, even to trusted admin accounts
The worked example above only ended well because the deletion permission itself was restricted by an immutability lock, not merely by trusting that whoever held admin credentials wouldn't misuse them. An attacker who compromises a trusted account inherits every permission that account has — routine backup-deletion rights on a broadly-held admin account are exactly the kind of unnecessary exposure `secsupport1`'s own least-privilege material warned against.

Hands-On Exercises

Exercise 1

Explain why storing an encryption key alongside the backup it protects is described as the same underlying mistake Chapter 3 already identified for backups themselves.

📄 View solution
Exercise 2

Using the worked example, explain specifically why an immutable backup survived an attack in which the attacker had already compromised admin credentials that would normally be able to delete it.

📄 View solution
Exercise 3

Explain why this chapter says neither a very short nor a very long retention window is correct, connecting the short-window risk back to a specific earlier chapter in this course.

📄 View solution

Chapter 8 Quick Reference

  • Backups are a target too — often more sensitive data with less scrutiny than production systems
  • Encrypt at rest and in transit; store the decryption key separately from the data it protects
  • Apply least-exposure access control to backup systems — especially deletion rights
  • Immutable/offline backups defeat ransomware that specifically targets accessible backups, even via a compromised admin account
  • Set a deliberate retention window — too short limits how far back recovery can reach, too long increases exposure
  • Next: Chapter 9, communicating honestly during a data-loss incident