8.4 Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.

Rationale:

The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The exp (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes.

Impact:

Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used.

Solution

From Azure Portal:

Go to Key vaults.

For each Key vault, click on Secrets.

In the main pane, ensure that the status of the secret is Enabled.

Set an appropriate Expiration date on all secrets.

From Azure CLI:
Update the Expiration date for the secret using the below command:

az keyvault secret set-attributes --name <secretName> --vault-name <vaultName> --expires Y-m-d'T'H:M:S'Z'

Note:
To view the expiration date on all secrets in a Key Vault using Microsoft API, the List Key permission is required.
To update the expiration date for the secrets:

Go to Key vault, click on Access policies.

Click on Create and add an access policy with the Update permission (in the Secret Permissions - Secret Management Operations section).

From PowerShell:
For each Key vault with the EnableRbacAuthorization setting set to False or empty, run the following command.

Set-AzKeyVaultSecret -VaultName <Vault Name> -Name <Secret Name> -Expires <DateTime>

Default Value:

By default, secrets do not expire.

See Also

https://workbench.cisecurity.org/benchmarks/10624