Assume the attacker has your admin key
Production is fully automated and its automation holds broad permissions over production resources. That is not going to change, and the exercise is not to argue with it.
Design on the assumption that somebody else obtains those permissions. After that has happened, recoverable copies of the data must still exist — which rules out every backup that the compromised credentials can reach.
- R1The thing production uses to make copies may create them and must not be able to remove or replace them. Stealing it must buy the ability to write another copy and nothing else.
- R2A copy must be impossible to delete or shorten before its retention period ends. Not difficult, not requiring approval — impossible, including for the most privileged principal of the account holding it.
- R3Any attempt to weaken any of this must be recorded somewhere that outlives the attempt, so that a failed attempt is visible afterwards rather than only while it is happening.
Boundaries, outermost first: PRODUCTION ACCOUNT: Backup job (runs in production), Production data (broad automation), an empty slot for the what production is allowed to do, tier 1 SEPARATE ACCOUNT: Second region (a copy of the vault), an empty slot for the where copies land, and stay, tier 1 Outside every boundary: Recovery account (empty, restores here), an empty slot for the records the attempt that failed, tier 2 Connections: Production data calls Backup job Backup job controls what production is allowed to do what production is allowed to do sends outbound traffic to where copies land, and stay — write, never delete where copies land, and stay publishes to Second region where copies land, and stay controls records the attempt that failed Second region calls Recovery account — restore