Exercise 3: Why a Backup Can Be Riskier Than the Live Database — Possible Solution
====================================================================

A live production database is usually the single most carefully
guarded asset an organization runs: strict network rules, monitored
access, dedicated accounts, active auditing. A BACKUP of that exact
same data is routinely treated as "just a file" — stored on a general
file share, an object storage bucket, an old decommissioned server, or
a laptop used to test a restore procedure — often without the same
encryption, access controls, or monitoring the live system has.

The data inside the backup is IDENTICAL to the live database's data —
same customer records, same password hashes, same everything — but
the barrier protecting it can be dramatically weaker. An attacker
doesn't need to defeat the live database's firewall rules, encrypted
connections, and access logging at all if a complete, unencrypted copy
of the same data is sitting in a publicly readable storage bucket or
an unattended old server nobody remembers exists.

WHAT THIS IMPLIES ABOUT WHERE SECURITY EFFORT SHOULD GO: security
effort has to follow the DATA, not just the currently-running system
that happens to be labeled "the database." Every place a copy of that
data exists — backups, replicas, exports, a developer's local dump
used for testing — needs the same level of protection as the live
system, or it becomes the actual weakest link an attacker will find
and use, regardless of how well-defended the "real" database is.