2.2. Secure Secrets and Keys by Using Azure Key Vault

💡 First Principle: Secrets, keys, and certificates are the credentials that make every other control in this guide trustworthy — an NSG rule doesn't matter if the database password behind it is sitting in a config file. Key Vault exists to be the one place those credentials live, so protecting Key Vault well is disproportionately important relative to its single-service footprint.

Because Key Vault is where an application's downstream access ultimately traces back to, a misconfigured vault doesn't just risk the vault — it risks everything the secrets inside it unlock. That's why this section pairs deployment and access configuration with the detection layer (Defender CSPM and Defender for Key Vault) that catches what preventive configuration missed.

Mental model: think of Key Vault less like a filing cabinet and more like a bank vault with two separate questions to answer — who's allowed to walk up to the vault at all (network/firewall access), and once they're at the vault, what are they allowed to take out (permission model — access policy or RBAC)?

⚠️ Common Misconception: Enabling soft-delete alone does not fully protect secrets from permanent deletion. Soft-delete keeps a deleted object recoverable during a retention window, but a vault owner can still purge it immediately unless purge protection — a separate, additive setting — is also enabled.