A backup is a second copy of your breach
When security teams review production, they look at the database, the network and the application. Backups are easy to overlook, yet each one is a complete copy of what attackers want. It is often held in less carefully guarded storage, with broader access and a longer life than the live data. A stolen backup bypasses every control you placed around production.
The reverse risk matters too. An attacker who gains administrative access will go after your backups first, because deleting them removes your ability to recover. Backup security therefore has two goals: keep the contents confidential, and keep the copies available. This page is the security layer of our backup and disaster recovery service.
What good looks like
- Every backup is encrypted at rest and in transit.
- Sensitive backups use customer-managed keys with documented owners.
- Roles that write, restore and delete backups are distinct.
- Production credentials cannot delete the only copy.
- Access to backups is logged and anomalies are alerted.
- A restore using the key has been rehearsed.
Encryption in practice
Keys
On AWS, most services encrypt backups with a KMS key. The default AWS managed key is convenient, but you cannot edit its policy, and encrypted snapshots that use it cannot be shared with another account. For anything you will copy across accounts, use a customer-managed key. Its policy states exactly who can encrypt, decrypt and administer.
A sensible layout is one key per environment or per data class rather than one for the whole organisation. A compromised key then exposes less, and key policies stay readable. Enable automatic rotation where the key type supports it. For cross-region copies you either create a key in the destination region or use a multi-Region key, which keeps the same key material available in both.
On Azure, use Key Vault with customer-managed keys where the backup workload supports them, and confirm the supported combinations in current documentation.
Dangers of key management
Encryption turns a backup problem into a key problem. If the key is deleted, scheduled for deletion or locked inside a closed account, the backups become unreadable. We therefore:
- Document who owns each key and how access is granted in an emergency.
- Use deletion waiting periods and alarms on key deletion events.
- Make sure the disaster recovery environment can reach the keys in the recovery region or account.
- Never place encryption passphrases for file-level tools in scripts or repositories. If you use a tool such as restic, the repository password lives in a secrets manager.
Access control in practice
Separate duties
The identity that creates backups should not be the one that deletes them. A simple model uses three roles:
| Role | Can do | Cannot do |
|---|---|---|
| Backup writer | Create and copy recovery points | Delete, restore into production |
| Restorer | Restore into a named recovery environment | Delete recovery points |
| Backup administrator | Change policy under approval | Act without review and logging |
Humans rarely need standing access to any of them. Access is granted through short-lived, audited sessions, with a break-glass path for a real disaster. See our approach to least privilege in the wider security work we do for managed clients.
Protect the storage itself
A restrictive resource policy on the vault or bucket is a second line of defence. On AWS, an example statement that denies deletion of recovery points except by a named administrative role looks like this:
{
"Sid": "DenyDeleteExceptBackupAdmin",
"Effect": "Deny",
"Principal": "*",
"Action": [
"backup:DeleteRecoveryPoint",
"backup:PutBackupVaultAccessPolicy"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::111122223333:role/backup-admin"
}
}
}
The account ID is a documentation placeholder. Pair this with Vault Lock or immutable storage so even the administrator cannot shorten retention below an agreed floor, and with organisation-level controls that block changes from workload accounts. On Azure, soft delete, immutability and a Resource Guard serve the same purpose.
Log and alert
Management events for restores, deletions and policy changes should go to a log destination outside the production account. We alert on deletion attempts, vault policy changes, failed access to a key and restores outside agreed windows. These feed your monitoring and incident response process, so a suspicious delete is treated as an incident.
Decisions and trade-offs
Immutability versus flexibility. Compliance-mode locks cannot be undone, which is the point, and also a risk if you set the wrong retention. We test in a sandbox account first.
Central key account or per-account keys. Central keys are easier to audit; per-account keys limit blast radius. The right choice depends on organisation size and team autonomy.
Client-side encryption. For especially sensitive data, encrypt before it leaves the source so the storage provider never holds plaintext. It protects more but complicates restores and key handling.
When it is too much. If backups contain no sensitive data and are easily regenerated, provider-managed encryption and basic role separation are enough.
Common failure modes
- Shared keys across everything, so one mistake affects all.
- Admin roles with delete rights on the same account as workloads.
- Backup buckets that are public or broadly readable.
- Keys not accessible from the recovery site.
- No alert when someone changes a vault policy.
Separating duties: who can do what
Encryption protects data at rest, but access design decides who can actually harm your backups. We split responsibilities into distinct roles so no single credential can both create and destroy recovery points.
- Backup operator: can start and monitor jobs, cannot delete recovery points or change vault policy.
- Restore operator: can initiate a restore into a designated recovery account, with approval and an audit trail.
- Vault administrator: manages policy and keys, ideally a small group using short-lived, multi-factor access rather than standing credentials.
- Auditor: read-only access to configuration and logs.
For high-value vaults, a second approval step before deletion or policy change is worth the friction. During a ransomware event, the attacker usually inherits whichever permissions the compromised account had, so keeping deletion rights away from daily accounts is the single most useful control. We test this by attempting forbidden actions with each role and confirming they are denied and alerted. Pair this with cross-region and cross-account backup so a copy sits behind a separate trust boundary.
Delivery and handover
Keys, policies and roles are defined as Terraform in your repositories. We document owners, rotation, break-glass procedure and the alert list, and show your team how to request a restore under the right controls. The restore itself is validated in automated restore testing.
How to tell it is working
An access review shows only expected principals, deletion attempts are denied and alerted, keys have owners and tested recovery paths, and an external audit of your backups finds nothing public or unencrypted. To harden your backups, book a consultation.