AzPolicyAdvertizer

last sync: 2024-Apr-26 17:46:54 UTC

API Management secret named values should be stored in Azure Key Vault

Azure BuiltIn Policy definition

Source Azure Portal
Display name API Management secret named values should be stored in Azure Key Vault
Id f1cc7827-022c-473e-836e-5a51cae0b249
Version 1.0.2
Details on versioning
Category API Management
Microsoft Learn
Description Named values are a collection of name and value pairs in each API Management service. Secret values can be stored either as encrypted text in API Management (custom secrets) or by referencing secrets in Azure Key Vault. To improve security of API Management and secrets, reference secret named values from Azure Key Vault. Azure Key Vault supports granular access management and secret rotation policies.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
Audit, Disabled, Deny
RBAC role(s) none
Rule aliases IF (4)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.ApiManagement/service/namedValues/displayName Microsoft.ApiManagement service/namedValues properties.displayName false
Microsoft.ApiManagement/service/namedValues/keyVault Microsoft.ApiManagement service/namedValues properties.keyVault false
Microsoft.ApiManagement/service/namedValues/keyVault.secretIdentifier Microsoft.ApiManagement service/namedValues properties.keyVault.secretIdentifier false
Microsoft.ApiManagement/service/namedValues/secret Microsoft.ApiManagement service/namedValues properties.secret false
Rule resource types IF (1)
Microsoft.ApiManagement/service/namedValues
Compliance
The following 2 compliance controls are associated with this Policy definition 'API Management secret named values should be stored in Azure Key Vault' (f1cc7827-022c-473e-836e-5a51cae0b249)
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 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 3
Azure_Security_Benchmark_v3.0 IM-8 Azure_Security_Benchmark_v3.0_IM-8 Microsoft cloud security benchmark IM-8 Identity Management Restrict the exposure of credential and secrets Shared **Security Principle:** Ensure that application developers securely handle credentials and secrets: - Avoid embedding the credentials and secrets into the code and configuration files - Use key vault or a secure key store service to store the credentials and secrets - Scan for credentials in source code. Note: This is often governed and enforced through a secure software development lifecycle (SDLC) and DevOps security process **Azure Guidance:** Ensure that secrets and credentials are stored in secure locations such as Azure Key Vault, instead of embedding them into the code and configuration files. - Implement Azure DevOps Credential Scanner to identify credentials within the code. - For GitHub, use the native secret scanning feature to identify credentials or other form of secrets within the code. Clients such as Azure Functions, Azure Apps services, and VMs can use managed identities to access Azure Key Vault securely. See Data Protection controls related to the use of Azure Key Vault for secrets management. **Implementation and additional context:** How to setup Credential Scanner: https://secdevtools.azurewebsites.net/helpcredscan.html GitHub secret scanning: https://docs.github.com/github/administering-a-repository/about-secret-scanning n/a link 3
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2023-02-10 18:41:56 change Patch (1.0.1 > 1.0.2)
2022-07-08 16:32:07 change Patch (1.0.0 > 1.0.1)
2022-06-17 16:31:08 add f1cc7827-022c-473e-836e-5a51cae0b249
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC