During discussions about Azure security, Azure Key Vault is regularly discussed. More and more organizations are aware that sensitive data such as secrets and keys can be stored here, while other resources can make use of it. But also the next question that often follows is: “How do I get a better grip on the requirements that we as an organization place on the content of this data?” In doing so, I point out the possibilities that Azure Policy has to offer, but most still find this cumbersome.

It is now made a lot easier for all these organizations, as Microsoft has defined various standard (built-in) policy definitions. This allows you to influence the requirements set for secrets, keys, and certificates. Think of the maximum validity period of a certificate, the cryptographic type of a key, that a key should be backed by a hardware security module (HSM) or that secrets should have an expiration date set.

For all these policy definitions, you can only audit which components are not compliant (will not cause any breaking changes to your environment), or you can enforce them (for new resources, existing non-compliant resources within a key vault are not affected).