Episode Details

(00:00:00) The Backup Operator from Hell
(00:00:35) The Silent Threat of Defaults
(00:01:01) The Many Faces of the Backup Operator
(00:01:38) The Lullaby of Defaults
(00:03:30) Debunking Backup Myths
(00:06:44) The Three Paths of Destruction
(00:10:57) The Three-Step Protection Strategy
(00:15:49) VM Backups: The Favorite Meal
(00:17:20) Files and Azure Storage: The Next Victims
(00:18:32) The Demo: A Step-by-Step Protection

In this episode of M365.fm, Mirko Peters exposes how one overpowered identity, leaked token, or careless admin can quietly destroy your Azure backups — and shows how to harden Recovery Services vaults so even the “Backup Operator from Hell” can’t kill your recovery plan.

WHAT YOU WILL LEARN

• Why “all green” backup blades are the most dangerous false sense of security in Azure
• How one identity can delete items, cut retention, disable protection, and purge soft‑deleted points
• Why Azure Backup is not secure or immutable by default — and what secure actually looks like
• How soft delete, Multi‑User Authorization (MUA), and vault lock work together to protect recovery points
• The most common attack paths: overprivileged automation, wide vault roles, and shadow admins with hidden DataActions
• A three‑step hardening strategy that separates duties, locks the vault, and continuously monitors high‑risk actions
• The one rule that matters most: if one person can kill your backups, you don’t have backups

THE CORE INSIGHT

Backups rarely fail when you configure them; they fail when you need them and discover what your IAM and defaults really allowed.
Azure Backup feels “official” and safe, but immutability and protection are configurations, not marketing words — you have to turn them on, test them, and defend them against your own identities.
The real threat is not a missing feature; it is a design where a single Owner, service principal, or CI/CD pipeline can silently erase history while logs look like normal operations.
This episode argues that serious Azure backup design is less about “more copies” and more about identity, separation of duties, and controls that even you can’t bypass on a bad day.

WHY AZURE BACKUP HARDENING WORKS

• Soft delete forces a time delay, so even destructive actions have a recovery window
• Multi‑User Authorization (MUA) ensures no single human can delete, disable, or slash retention alone
• Vault lock prevents later “just this once” changes that weaken protection after go‑live
• Split roles and PIM mean no one identity can both deploy and purge, or both operate and weaken policy
• Isolation of vaults (subscriptions, resource groups, and narrow scopes) reduces blast radius
• Logging and alerting on delete, retention change, and purge events turn silent risk into visible incidents

KEY TAKEAWAYS

• Azure Backup is only as safe as your IAM, DataActions, and automation identities
• Immutability requires soft delete, MUA, and vault lock — tested with real delete → restore drills
• Any identity that can both change policy and purge recovery points is a design bug, not a convenience
• Automation should be tightly scoped and never have purge or policy‑weakening permissions
• Monitoring must cover role assignments, PIM activations, retention changes, and purge operations, not just job success
• If your design allows one click or one compromised token to kill all recovery points, you don’t have a backup solution — you have a comfort illusion

WHO