Integrate Azure Key Vault with Azure Policy

บทความ
09/27/2024

Azure Policy is a governance tool that gives users the ability to audit and manage their Azure environment at scale, allowing them to place guardrails on Azure resources to ensure they're compliant with assigned policy rules. It allows users to perform audit, real-time enforcement, and remediation of their Azure environment. The results of audits performed by policy are available to users in a compliance dashboard where they can see to see a drill-down of which resources and components are compliant and which aren't. For more information, see the Overview of the Azure Policy service.

Example Usage Scenarios:

You want to improve the security posture of your company by implementing requirements around minimum key sizes and maximum validity periods of certificates in your company's key vaults but you don't know which teams will be compliant and which aren't.
You currently don't have a solution to perform an audit across your organization, or you're conducting manual audits of your environment by asking individual teams within your organization to report their compliance. You're looking for a way to automate this task, perform audits in real time, and guarantee the accuracy of the audit.
You want to enforce your company security policies and stop individuals from creating self-signed certificates, but you don't have an automated way to block their creation.
You want to relax some requirements for your test teams, but you want to maintain tight controls over your production environment. You need a simple automated way to separate enforcement of your resources.
You want to be sure that you can roll back enforcement of new policies in the event that there is a live-site issue. You need a one-click solution to turn off enforcement of the policy.
You're relying on a third-party solution for auditing your environment and you want to use an internal Microsoft offering.

Types of policy effects and guidance

When enforcing a policy, you can determine its effect over the resulting evaluation. Each policy definition allows you to choose one of multiple effects. Therefore, policy enforcement may behave differently depending on the type of operation you're evaluating. In general, the effects for policies that integrate with Key Vault include:

Audit: when the effect of a policy is set to Audit, the policy won't cause any breaking changes to your environment. It will only alert you to components such as certificates that don't comply with the policy definitions within a specified scope, by marking these components as noncompliant in the policy compliance dashboard. Audit is default if no policy effect is selected.
Deny: when the effect of a policy is set to Deny, the policy blocks the creation of new components (such as certificates) and blocks new versions of existing components that don't comply with the policy definition. Existing noncompliant resources within a key vault aren't affected. The 'audit' capabilities continue to operate.
Disabled: when the effect of a policy is set to Disabled, the policy will still be evaluated but enforcement won't take effect, thus being compliant for the condition with Disabled effect. This is useful to disable the policy for a specific condition as opposed to all conditions.
Modify: when the effect of a policy is set to Modify, you can perform addition of resource tags, such as adding the Deny tag to a network. This is useful to disable access to a public network for Azure Key Vault managed HSM. It's necessary to configure a manage identity for the policy definition via the roleDefinitionIds parameter to utilize the Modify effect.
DeployIfNotExists: when the effect of a policy is set to DeployIfNotExists, a deployment template is executed when the condition is met. This can be used to configure diagnostic settings for Key Vault to log analytics workspace. It's necessary to configure a manage identity for the policy definition via the roleDefinitionIds parameter to utilize the DeployIfNotExists effect.
AuditIfNotExists: when the effect of a policy is set to AuditIfNotExists, you can identify resources that lack the properties specified in the details of the policy condition. This is useful to identify key vaults that have no resource logs enabled. It's necessary to configure a manage identity for the policy definition via the roleDefinitionIds parameter to utilize the DeployIfNotExists effect.

Available Built-In Policy Definitions

Predetermined policies, referred to as 'built-ins', facilitate governance over your key vaults so you don't have to write custom policies in JSON format to enforce commonly used rules associated with best security practices. Even though built-ins are predetermined, certain policies require you to define parameters. For example, by defining the effect of the policy, you can audit the key vault and its objects before enforcing a deny operation to prevent outages. Current built-ins for Azure Key Vault are categorized in four major groups: key vault, certificates, keys, and secrets management. Within each category, policies are grouped towards driving specific security goals.

Key Vaults

Access Control

Using the Azure Policy service, you can govern the migration to the RBAC permission model across your vaults. Learn more at Migrate from vault access policy to an Azure role-based access control permission model

Policy	Effects
Azure Key Vault should use RBAC permission model	Audit (Default), Deny, Disabled

Network Access

Reduce the risk of data leakage by restricting public network access, enabling Azure Private Link connections, creating private DNS zones to override DNS resolution for a private endpoint, and enabling firewall protection so that the key vault isn't accessible by default to any public IP.

Policy	Effects
Azure Key Vault should disable public network access	Audit (Default), Deny, Disabled
[Preview] Azure Key Vault Managed HSM should disable public network access	Audit (Default), Deny, Disabled
[Preview]: Configure Key Vault Managed HSMs to disable public network access	Modify (Default), Disabled
[Preview]: Azure Key Vaults should use private link	Audit (Default), Deny, Disabled
[Preview]: Azure Key Vault Managed HSMs should use private link	Audit (Default), Disabled
[Preview]: Configure Azure Key Vaults with private endpoints	DeployIfNotExists (Default), Disabled
[Preview]: Configure Azure Key Vault Managed HSM with private endpoints	DeployIfNotExists (Default), Disabled
[Preview]: Configure Azure Key Vaults to use private DNS zones	DeployIfNotExists (Default), Disabled
Key Vaults should have firewall enabled	Audit (Default), Deny, Disabled
Configure Key Vaults to enable firewall	Modify (Default), Disabled

Deletion Protection

Prevent permanent data loss of your key vault and its objects by enabling soft-delete and purge protection. While soft-delete allows you to recover an accidentally deleted key vault for a configurable retention period, purge protection protects you from insider attacks by enforcing a mandatory retention period for soft-deleted key vaults. Purge protection can only be enabled once soft-delete is enabled. No one inside your organization or Microsoft can purge your key vaults during the soft delete retention period.

Policy	Effects
Key Vaults should have soft delete enabled	Audit (Default), Deny, Disabled
Key Vaults should have purge protection enabled	Audit (Default), Deny, Disabled
Azure Key Vault Managed HSM should have purge protection enabled	Audit (Default), Deny, Disabled

Diagnostics

Drive the enabling of resource logs to recreate activity trails to use for investigation purposes when a security incident occurs or when your network is compromised.

Policy	Effects
Deploy diagnostic settings for Key Vaults to Event Hubs	DeployIfNotExists (Default)
Deploy - Configure diagnostic settings for Key Vault managed HSMs to Event Hubs	DeployIfNotExists (Default), Disabled
Deploy - Configure diagnostic settings for Key Vaults to Log Analytics workspace	DeployIfNotExists (Default), Disabled
Resource logs in Key Vaults should be enabled	AuditIfNotExists (Default), Disabled
Resource logs in Key Vault managed HSMs should be enabled	AuditIfNotExists (Default), Disabled

Certificates

Lifecycle of Certificates

Promote the use of short-lived certificates to mitigate undetected attacks, by minimizing the time-frame of ongoing damage and reducing the value of the certificate to attackers. When implementing short-lived certificates it is recommended to regularly monitor their expiration date to avoid outages, so that they can be rotated adequately before expiration. You can also control the lifetime action specified for certificates that are either within a certain number of days of their expiration or have reached a certain percentage of their usable life.

Policy	Effects
[Preview]: Certificates should have the specified maximum validity period	Effects: Audit (Default), Deny, Disabled
[Preview]: Certificates should not expire within the specified number of days	Effects: Audit (Default), Deny, Disabled
Certificates should have the specified lifetime action triggers	Effects: Audit (Default), Deny, Disabled

Note

It's recommended to apply the certificate expiration policy multiple times with different expiration thresholds, for example, at 180, 90, 60, and 30-day thresholds.

Certificate Authority

Audit or enforce the selection of a specific certificate authority to issue your certificates either relying on one of Azure Key Vault's integrated certificate authorities (Digicert or GlobalSign), or a nonintegrated certificate authority of your preference. You can also audit or deny the creation of self-signed certificates.

Policy	Effects
Certificates should be issued by the specified integrated certificate authority	Audit (Default), Deny, Disabled
Certificates should be issued by the specified nonintegrated certificate authority	Audit (Default), Deny, Disabled

Certificate Attributes

Restrict the type of your key vault's certificates to be RSA, ECC, or HSM-backed. If you use elliptic curve cryptography or ECC certificates, you can customize and select curve names such as P-256, P-256K, P-384, and P-521. If you use RSA certificates, you can choose a minimum key size for your certificates to be 2,048 bits, 3,072 bits, or 4,096 bits.

Policy	Effects
Certificates should use allowed key types	Audit (Default), Deny, Disabled
Certificates using elliptic curve cryptography should have allowed curve names	Audit (Default), Deny, Disabled
Certificates using RSA cryptography should have the specified minimum key size	Audit (Default), Deny, Disabled

Keys

HSM-backed keys

An HSM is a hardware security module that stores keys. An HSM provides a physical layer of protection for cryptographic keys. The cryptographic key can't leave a physical HSM which provides a greater level of security than a software key. Some organizations have compliance requirements that mandate the use of HSM keys. You can use this policy to audit any keys stored in your Key Vault that isn't HSM backed. You can also use this policy to block the creation of new keys that aren't HSM backed. This policy will apply to all key types, including RSA and ECC.

Policy	Effects
Keys should be backed by a hardware security module (HSM)	Audit (Default), Deny, Disabled

Lifecycle of Keys

With lifecycle management built-ins you can flag or block keys that don't have an expiration date, get alerts whenever delays in key rotation may result in an outage, prevent the creation of new keys that are close to their expiration date, limit the lifetime and active status of keys to drive key rotation, and preventing keys from being active for more than a specified number of days.

Policy	Effects
Keys should have a rotation policy ensuring that their rotation is scheduled within the specified number of days after creation	Audit (Default), Disabled
Key Vault keys should have an expiration date	Audit (Default), Deny, Disabled
[Preview]: Managed HSM keys should have an expiration date	Audit (Default), Deny, Disabled
Keys should have more than the specified number of days before expiration	Audit (Default), Deny, Disabled
[Preview]: Azure Key Vault Managed HSM Keys should have more than the specified number of days before expiration	Audit (Default), Deny, Disabled
Keys should have the specified maximum validity period	Audit (Default), Deny, Disabled
Keys should not be active for longer than the specified number of days	Audit (Default), Deny, Disabled

Important

If your key has an activation date set, the policy above will calculate the number of days that have elapsed from the activation date of the key to the current date. If the number of days exceeds the threshold you set, the key will be marked as non-compliant with the policy. If your key does not have an activation date set, the policy will calculate the number of days that have elapsed from the creation date of the key to the current date. If the number of days exceeds the threshold you set, the key will be marked as non-compliant with the policy.

Key Attributes

Restrict the type of your Key Vault's keys to be RSA, ECC, or HSM-backed. If you use elliptic curve cryptography or ECC keys, you can customize and select curve names such as P-256, P-256K, P-384, and P-521. If you use RSA keys, you can mandate the use of a minimum key size for current and new keys to be 2048 bits, 3072 bits, or 4096 bits. Keep in mind that using RSA keys with smaller key sizes isn't a secure design practice, thus it is recommended to block the creation of new keys that don't meet the minimum size requirement.

Policy	Effects
Keys should be the specified cryptographic type RSA or EC	Audit (Default), Deny, Disabled
Keys using elliptic curve cryptography should have the specified curve names	Audit (Default), Deny, Disabled
[Preview]: Azure Key Vault Managed HSM keys using elliptic curve cryptography should have the specified curve names	Audit (Default), Deny, Disabled
Keys using RSA cryptography should have a specified minimum key size	Audit (Default), Deny, Disabled
[Preview]: Azure Key Vault Managed HSM keys using RSA cryptography should have a specified minimum key size	Audit (Default), Deny, Disabled

Secrets

Lifecycle of Secrets

With lifecycle management built-ins you can flag or block secrets that don't have an expiration date, get alerts whenever delays in secret rotation may result in an outage, prevent the creation of new keys that are close to their expiration date, limit the lifetime and active status of keys to drive key rotation, and preventing keys from being active for more than a specified number of days.

Policy	Effects
Secrets should have an expiration date	Audit (Default), Deny, Disabled
Secrets should have more than the specified number of days before expiration	Audit (Default), Deny, Disabled
Secrets should have the specified maximum validity period	Audit (Default), Deny, Disabled
Secrets should not be active for longer than the specified number of days	Audit (Default), Deny, Disabled

Important

If your secret has an activation date set, the policy above will calculate the number of days that have elapsed from the activation date of the secret to the current date. If the number of days exceeds the threshold you set, the secret will be marked as non-compliant with the policy. If your secret does not have an activation date set, this policy will calculate the number of days that have elapsed from the creation date of the secret to the current date. If the number of days exceeds the threshold you set, the secret will be marked as non-compliant with the policy.

Secret Attributes

Any plain text or encoded file can be stored as an Azure key vault secret. However, your organization may want to set different rotation policies and restrictions on passwords, connection strings, or certificates stored as keys. A content type tag can help a user see what is stored in a secret object without reading the value of the secret. You can audit secrets that don't have a content type tag set or prevent new secrets from being created if they don't have a content type tag set.

Policy	Effects
Secrets should have content type set	Audit (Default), Deny, Disabled

Example Scenario

You manage a key vault used by multiple teams that contains 100 certificates, and you want to make sure that none of the certificates in the key vault are valid for longer than 2 years.

You assign the Certificates should have the specified maximum validity period policy, specify that the maximum validity period of a certificate is 24 months, and set the effect of the policy to "audit".
You view the compliance report on the Azure portal, and discover that 20 certificates are non-compliant and valid for > 2 years, and the remaining certificates are compliant.
You contact the owners of these certificates and communicate the new security requirement that certificates can't be valid for longer than 2 years. Some teams respond and 15 of the certificates were renewed with a maximum validity period of 2 years or less. Other teams don't respond, and you still have 5 non-compliant certificates in your key vault.
You change the effect of the policy you assigned to "deny". The 5 non-compliant certificates aren't revoked, and they continue to function. However, they can't be renewed with a validity period that is greater than 2 years.

Enabling and managing a key vault policy through the Azure portal

Select a Policy Definition

Log in to the Azure portal.
Search "Policy" in the Search Bar and Select Policy.
In the Policy window, select Definitions.
In the Category Filter, Unselect Select All and select Key Vault.
Now you should be able to see all the policies available for Public Preview, for Azure Key Vault. Make sure you have read and understood the policy guidance section above and select a policy you want to assign to a scope.

Assign a Policy to a Scope

Select a policy you wish to apply, in this example, the Manage Certificate Validity Period policy is shown. Click the assign button in the top-left corner.
Select the subscription where you want the policy to be applied. You can choose to restrict the scope to only a single resource group within a subscription. If you want to apply the policy to the entire subscription and exclude some resource groups, you can also configure an exclusion list. Set the policy enforcement selector to Enabled if you want the effect of the policy (audit or deny) to occur or Disabled to turn the effect (audit or deny) off.
Click on the parameters tab at the top of the screen in order to specify the maximum validity period in months that you want. If you need to input the parameters, you can uncheck 'Only show parameters that need input or review' option. Select audit or deny for the effect of the policy following the guidance in the sections above. Then select the review + create button.

View Compliance Results

Go back to the Policy blade and select the compliance tab. Click on the policy assignment you wish to view compliance results for.
From this page you can filter results by compliant or non-compliant vaults. Here you can see a list of non-compliant key vaults within the scope of the policy assignment. A vault is considered non-compliant if any of the components (certificates) in the vault are non-compliant. You can select an individual vault to view the individual non-compliant components (certificates).
View the name of the components within a vault that are non-compliant
If you need to check whether users are being denied the ability to create resources within the key vault, you can click on the Component Events (preview) tab to view a summary of denied certificate operations with the requestor and timestamps of requests.

Feature Limitations

Assigning a policy with a "deny" effect may take up to 30 mins (average case) and 1 hour (worst case) to start denying the creation of non-compliant resources. The delay refers to following scenarios -

A new policy is assigned.
An existing policy assignment is modified.
A new KeyVault (resource) is created in a scope with existing policies.

The policy evaluation of existing components in a vault may take up to 1 hour (average case) and 2 hours (worst case) before compliance results are viewable in the portal UI.

If the compliance results show up as "Not Started" it may be due to the following reasons:

The policy valuation hasn't completed yet. Initial evaluation latency can take up to 2 hours in the worst-case scenario.
There are no key vaults in the scope of the policy assignment.
There are no key vaults with certificates within the scope of the policy assignment.