Azure Policy built-in definitions for Key Vault
This page is an index of Azure Policy built-in policy definitions for Key Vault. For additional Azure Policy built-ins for other services, see Azure Policy built-in definitions.
The name of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the Version column to view the source on the Azure Policy GitHub repo.
Key Vault (service)
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Azure Key Vault should disable public network access | Disable public network access for your key vault so that it's not accessible over the public internet. This can reduce data leakage risks. Learn more at: https://aka.ms/akvprivatelink. | Audit, Deny, Disabled | 1.0.0 |
| Azure Key Vault should have firewall enabled | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: https://docs.azure.cn/key-vault/general/network-security | Audit, Deny, Disabled | 3.0.0 |
| Certificates should be issued by the specified integrated certificate authority | Manage your organizational compliance requirements by specifying the Azure integrated certificate authorities that can issue certificates in your key vault such as Digicert or GlobalSign. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should be issued by the specified non-integrated certificate authority | Manage your organizational compliance requirements by specifying the custom or internal certificate authorities that can issue certificates in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should have the specified lifetime action triggers | Manage your organizational compliance requirements by specifying whether a certificate lifetime action is triggered at a specific percentage of its lifetime or at a certain number of days prior to its expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should use allowed key types | Manage your organizational compliance requirements by restricting the key types allowed for certificates. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using elliptic curve cryptography should have allowed curve names | Manage the allowed elliptic curve names for ECC Certificates stored in key vault. More information can be found at https://aka.ms/akvpolicy. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using RSA cryptography should have the specified minimum key size | Manage your organizational compliance requirements by specifying a minimum key size for RSA certificates stored in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Configure key vaults to enable firewall | Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: https://docs.azure.cn/key-vault/general/network-security | Modify, Disabled | 1.1.1 |
| Deploy - Configure diagnostic settings for Azure Key Vault to Log Analytics workspace | Deploys the diagnostic settings for Azure Key Vault to stream resource logs to a Log Analytics workspace when any Key Vault which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 2.0.1 |
| Deploy Diagnostic Settings for Key Vault to Event Hub | Deploys the diagnostic settings for Key Vault to stream to a regional Event Hub when any Key Vault which is missing this diagnostic settings is created or updated. | deployIfNotExists | 3.0.0 |
| Deploy Diagnostic Settings for Key Vault to Log Analytics workspace | Deploys the diagnostic settings for Key Vault to stream to a regional Log Analytics workspace when any Key Vault which is missing this diagnostic settings is created or updated. | DeployIfNotExists, Disabled | 3.0.0 |
| Key Vault keys should have an expiration date | Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault secrets should have an expiration date | Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault should use a virtual network service endpoint | This policy audits any Key Vault not configured to use a virtual network service endpoint. | Audit, Disabled | 1.0.0 |
| Key vaults should have purge protection enabled | Malicious deletion of a key vault can lead to permanent data loss. A malicious insider in your organization can potentially delete and purge key vaults. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Azure will be able to purge your key vaults during the soft delete retention period. | Audit, Deny, Disabled | 2.0.0 |
| Key vaults should have soft delete enabled | Deleting a key vault without soft delete enabled permanently deletes all secrets, keys, and certificates stored in the key vault. Accidental deletion of a key vault can lead to permanent data loss. Soft delete allows you to recover an accidentally deleted key vault for a configurable retention period. | Audit, Deny, Disabled | 3.0.0 |
| Keys should be the specified cryptographic type RSA or EC | Some applications require the use of keys backed by a specific cryptographic type. Enforce a particular cryptographic key type, RSA or EC, in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have more than the specified number of days before expiration | If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a key can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Keys should not be active for longer than the specified number of days | Specify the number of days that a key should be active. Keys that are used for an extended period of time increase the probability that an attacker could compromise the key. As a good security practice, make sure that your keys have not been active longer than two years. | Audit, Deny, Disabled | 1.0.1 |
| Keys using elliptic curve cryptography should have the specified curve names | Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys using RSA cryptography should have a specified minimum key size | Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. | Audit, Deny, Disabled | 1.0.1 |
| Resource logs in Key Vault should be enabled | Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes when a security incident occurs or when your network is compromised | AuditIfNotExists, Disabled | 5.0.0 |
| Secrets should have content type set | A content type tag helps identify whether a secret is a password, connection string, etc. Different secrets have different rotation requirements. Content type tag should be set on secrets. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have more than the specified number of days before expiration | If a secret is too close to expiration, an organizational delay to rotate the secret may result in an outage. Secrets should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should not be active for longer than the specified number of days | If your secrets were created with an activation date set in the future, you must ensure that your secrets have not been active for longer than the specified duration. | Audit, Deny, Disabled | 1.0.1 |
Key Vault (objects)
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| [Preview]: [Preview]: Certificates should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.2.0-preview |
| [Preview]: [Preview]: Certificates should not expire within the specified number of days | Manage certificates that will expire within a specified number of days to ensure your organization has sufficient time to rotate the certificate prior to expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0-preview |
| Certificates should be issued by the specified integrated certificate authority | Manage your organizational compliance requirements by specifying the Azure integrated certificate authorities that can issue certificates in your key vault such as Digicert or GlobalSign. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should be issued by the specified non-integrated certificate authority | Manage your organizational compliance requirements by specifying the custom or internal certificate authorities that can issue certificates in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should have the specified lifetime action triggers | Manage your organizational compliance requirements by specifying whether a certificate lifetime action is triggered at a specific percentage of its lifetime or at a certain number of days prior to its expiration. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates should use allowed key types | Manage your organizational compliance requirements by restricting the key types allowed for certificates. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using elliptic curve cryptography should have allowed curve names | Manage the allowed elliptic curve names for ECC Certificates stored in key vault. More information can be found at https://aka.ms/akvpolicy. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Certificates using RSA cryptography should have the specified minimum key size | Manage your organizational compliance requirements by specifying a minimum key size for RSA certificates stored in your key vault. | audit, Audit, deny, Deny, disabled, Disabled | 2.1.0 |
| Key Vault keys should have an expiration date | Cryptographic keys should have a defined expiration date and not be permanent. Keys that are valid forever provide a potential attacker with more time to compromise the key. It is a recommended security practice to set expiration dates on cryptographic keys. | Audit, Deny, Disabled | 1.0.2 |
| Key Vault secrets should have an expiration date | Secrets should have a defined expiration date and not be permanent. Secrets that are valid forever provide a potential attacker with more time to compromise them. It is a recommended security practice to set expiration dates on secrets. | Audit, Deny, Disabled | 1.0.2 |
| Keys should be the specified cryptographic type RSA or EC | Some applications require the use of keys backed by a specific cryptographic type. Enforce a particular cryptographic key type, RSA or EC, in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have more than the specified number of days before expiration | If a key is too close to expiration, an organizational delay to rotate the key may result in an outage. Keys should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Keys should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a key can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Keys should not be active for longer than the specified number of days | Specify the number of days that a key should be active. Keys that are used for an extended period of time increase the probability that an attacker could compromise the key. As a good security practice, make sure that your keys have not been active longer than two years. | Audit, Deny, Disabled | 1.0.1 |
| Keys using elliptic curve cryptography should have the specified curve names | Keys backed by elliptic curve cryptography can have different curve names. Some applications are only compatible with specific elliptic curve keys. Enforce the types of elliptic curve keys that are allowed to be created in your environment. | Audit, Deny, Disabled | 1.0.1 |
| Keys using RSA cryptography should have a specified minimum key size | Set the minimum allowed key size for use with your key vaults. Use of RSA keys with small key sizes is not a secure practice and doesn't meet many industry certification requirements. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have content type set | A content type tag helps identify whether a secret is a password, connection string, etc. Different secrets have different rotation requirements. Content type tag should be set on secrets. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have more than the specified number of days before expiration | If a secret is too close to expiration, an organizational delay to rotate the secret may result in an outage. Secrets should be rotated at a specified number of days prior to expiration to provide sufficient time to react to a failure. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should have the specified maximum validity period | Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault. | Audit, Deny, Disabled | 1.0.1 |
| Secrets should not be active for longer than the specified number of days | If your secrets were created with an activation date set in the future, you must ensure that your secrets have not been active for longer than the specified duration. | Audit, Deny, Disabled | 1.0.1 |
Next steps
- See the built-ins on the Azure Policy GitHub repo.
- Review the Azure Policy definition structure.
- Review Understanding policy effects.