Resetting resources before Expiration in Azure Key Vault

Year over year, we are seeing cyber attacks and security hacking incidents get stronger and stronger. As a result of these attacks, corporations have to bear losses in billions of dollars and they have tightened the compliance requirements.

Before Software is shipped, these compliance requirements are line items in the Software quality control checklist. Softwares developed today are complex, and integrate with other systems/applications to exchange data, combine and/or enhance functionality. As an example, an e-commerce enterprise would want a Product Information Management (PIM) that not only integrates with their corporate Single Sign-On but also provides support to do so using multiple standards and protocols — SAML, OAuth, MFA, you name it. With this, comes the challenge of maintaining integration tokens, secrets, keys, certificates, passwords.

OWASP cheat sheet [1] guides on key management lifecycle and while developers pay attention to key generation, storage, and distribution to avoid red flags by code scanners; expiration and rotation of keys often get neglected. If you are using Azure Key Vault for the management of these security tokens, a built-in policy comes in very handy.

Taking an example of ‘Secret’ management in Azure Key Vault (same would apply to Keys, Certificates and other resources), when creating a new secret, only ‘Name’ and ‘Value’ are mandatory fields, and ‘Set expiration date’ is optional & unchecked by default. Unchecked value of this field keeps the ‘Lifetime Actions’ policy disabled and these secrets never expire.

Some of the disadvantages of not setting expiration date, are:

a. These secrets never expire in key vault, but they may have an expiration time after which these keys wouldn’t successfully authenticate. For e.g. an authentication provider (3rd party) may have the policy to expire issued keys every ‘x’ months which is different than your corporate policy.

b. Responsibility to rotate these keys (enabling a newer version) is the sole responsibility of administrators — keep track of the time when a key was last reset and when will it expire.

c. Non-compliant flags on the resource if not renewed on time.

Refer to [2] and [3] for additional policy details.

All of the cons mentioned above can be mitigated by checking ‘Set expiration date’ (screenshot below) which internally sets an ‘exp’ property on the resource to indicate the date when this resource will become inactive. As mentioned in [3], you can define a policy that will trigger a notification ‘x’ days or x% of lifetime days, before the expiration of the resource & thus automate expiration tracking, prevent issues arising from corporate non-compliance or a broken 1st/3rd party integration due to an expired key.

So, are you going to implement this practice of setting expiration date for resources managed in Azure Key Vault?

References:

[1]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html

[2]: https://docs.microsoft.com/en-us/azure/key-vault/policy-reference

[3]: GitHub for Lifetime Action policy: https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_LifetimeAction.json