Helpful first: Assets and the CIA triad: what we protect and how it fails · Threat, vulnerability, and risk: the core equation
Key points
- Separate what encryption at rest and in transit protect from what they leave vulnerable
- Explain why synchronous database replication and writable network shares fail during ransomware or destructive incidents
- Design a 3-2-1-1-0 backup and recovery architecture validated by routine restore drills against RTO and RPO targets
When the database is encrypted twice: once by you, once by ransomware
Suppose a ground-station telemetry cluster at Meridian Space & Robotics (chronos.orbital) uses full-disk AES-256 encryption at rest and TLS 1.3 in transit. On Tuesday night, an attacker compromises a service account with write permissions and runs a destructive script that drops the primary tables and encrypts the mounted backup NFS share.
Notice that Meridian’s disk encryption and TLS worked flawlessly: the attacker used an authorized path through the running OS and filesystem. Because encryption is a Confidentiality control, it did nothing to prevent Destruction (Availability) or Alteration (Integrity). To survive destructive faults or ransomware, architecture must separate data protection from operational resilience.
| Mechanism | Solves This Failure | Fails Against This Scenario |
|---|---|---|
| Encryption in Transit (TLS 1.3 / IPsec) | Passive wiretapping and on-path packet tampering across untrusted networks | Compromised endpoint, stolen application credentials, or malicious insider query |
| Encryption at Rest (AES-256 Disk / KMS) | Physical drive theft, improper media disposal, or unmounted snapshot exposure | Queries against a live, mounted database or ransomware running as a privileged OS process |
| Multi-AZ Synchronous Replication (RAID / Standby DB) | Single hardware disk failure or data-center power loss (high availability) | Logical corruption, DROP TABLE, or ransomware (deletions replicate instantly to all nodes) |
| Immutable, Isolated Backups (WORM / Object Lock) | Ransomware, rogue admin deletion, and catastrophic logical corruption | Fails if the team never tests restores and discovers at crisis time that decryption keys are missing |
Why replication and writable shares are not backups
Engineers often confuse high-availability replication with backup. If primary database db-east replicates every transaction within 10 milliseconds to standby db-west, and a buggy migration or attacker deletes 10 million telemetry rows on db-east, db-west faithfully deletes those same 10 million rows 10 milliseconds later.
Similarly, writing nightly backups to a standard network file share (\\nas\backups) mounted with read/write credentials on the production server means the first thing a ransomware payload or compromised root session does is delete or encrypt the backup folder before touching production.
Immutable Object Lock, blast-radius isolation, and key separation
At Meridian, Staff Infrastructure Engineer Kael Cho enforces the modern 3-2-1-1-0 resilience rule: at least 3 copies of critical data, across 2 different storage media/tiers, with 1 copy offsite in another region, 1 copy that is immutable (WORM / Object Lock Compliance Mode in a separate cloud account with a separate IAM control plane), and 0 unverified backup errors.
3
3 copies of critical data
2
2 different storage media/tiers
1 offsite
1 copy offsite in another region
1 immutable
1 copy that is immutable (WORM / Object Lock Compliance Mode in a separate cloud account with a separate IAM control plane)
0
0 unverified backup errors
Because the backup vault lives in an isolated security domain with WORM retention locks, even if an attacker compromises the production root account, they cannot delete or overwrite existing backup snapshots before the retention timer expires.
A backup does not exist until a restore drill succeeds
Nobody actually cares about backing data up; the business only cares about restoring it within the required Recovery Time Objective (RTO) (how long the service can be down) and Recovery Point Objective (RPO) (how many minutes or hours of data loss the mission can tolerate). If Meridian backs up encrypted snapshots every hour, but stores the KMS recovery key inside the exact same production database that just crashed, the backup is an unrecoverable brick. Routine, automated restore drills into an isolated staging environment are the only real proof of resilience.
CHECK YOUR JUDGMENT
During an architecture review at Meridian Space & Robotics (chronos.orbital), a team proposes protecting their mission-critical PostgreSQL cluster against ransomware by enabling AWS EBS volume encryption (AES-256), configuring a synchronous Multi-AZ standby replica, and writing nightly pg_dump files to an S3 bucket using the database server’s own IAM role (which has s3:* permissions). What is the fatal flaw in this resilience plan?
NEXT FIELD LESSON