AzPolicyAdvertizer

last sync: 2025-Oct-31 18:22:59 UTC

Secrets should have the specified maximum validity period

Azure BuiltIn Policy definition

Source Azure Portal
Display name Secrets should have the specified maximum validity period
Id 342e8053-e12e-4c44-be01-c3c2f318400f
Version 1.0.1
Details on versioning
Versioning Versions supported for Versioning: 1
1.0.1
Built-in Versioning [Preview]
Category Key Vault
Microsoft Learn
Description Manage your organizational compliance requirements by specifying the maximum amount of time in days that a secret can be valid within your key vault.
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '1.0.1'
Repository: Azure-Policy 342e8053-e12e-4c44-be01-c3c2f318400f
Mode Microsoft.KeyVault.Data
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
Audit, Deny, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types none
Compliance
The following 1 compliance controls are associated with this Policy definition 'Secrets should have the specified maximum validity period' (342e8053-e12e-4c44-be01-c3c2f318400f)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v3.0 DP-6 Azure_Security_Benchmark_v3.0_DP-6 Microsoft cloud security benchmark DP-6 Data Protection DP-6 Use a secure key management process Shared **Security Principle:** Document and implement an enterprise cryptographic key management standard, processes, and procedures to control your key lifecycle. When there is a need to use customer-managed key in the services, use a secured key vault service for key generation, distribution, and storage. Rotate and revoke your keys based on the defined schedule and when there is a key retirement or compromise. **Azure Guidance:** Use Azure Key Vault to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in Azure Key Vault and your service based on the defined schedule and when there is a key retirement or compromise. When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices: - Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault. - Ensure keys are registered with Azure Key Vault and implement via key IDs in each service or application. If you need to bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into Azure Key Vault), follow the recommended guideline to perform the key generation and key transfer. Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance level. - Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1 - HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2 - HSM-protected keys in Managed HSM: FIPS 140-2 Level 3 **Implementation and additional context:** Azure Key Vault overview: https://docs.microsoft.com/azure/key-vault/general/overview Azure data encryption at rest--Key Hierarchy: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#key-hierarchy BYOK(Bring Your Own Key) specification: https://docs.microsoft.com/azure/key-vault/keys/byok-specification n/a link 11
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Preview]: Microsoft cloud security benchmark v2 e3ec7e09-768c-4b64-882c-fcada3772047 Security Center Preview BuiltIn unknown
Enforce recommended guardrails for Azure Key Vault Enforce-Guardrails-KeyVault Key Vault GA ALZ
History
Date/Time (UTC ymd) (i) Change type Change detail
2021-08-30 14:27:30 change Patch, old suffix: preview (1.0.0-preview > 1.0.1)
2020-10-16 12:27:50 add 342e8053-e12e-4c44-be01-c3c2f318400f
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC