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.
Unknown, no evidence if Policy definition is/not available in AzureUSGovernment
Assessment(s)
Assessments count: 1 Assessment Id: 93b78b68-5f3f-46b2-acf1-c3e9e6e646d1 DisplayName: API Management secret named values should be stored in Azure Key Vault 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. Related OWASP API Security Top 10 Risks: (API8:2023) Security Misconfiguration Remediation description: To utilize secrets stored in Key Vault in API Management: 1. In the Azure portal, find your API Management Resource 2. Navigate to the Named Values blade 3. Select 'Add' to create a new Named Value 4. Select 'Type' of Key Vault 5. Select the Key Vault and Secret associated with the Named Value. Learn more at: https://docs.microsoft.com/azure/api-management/api-management-howto-properties?tabs=azure-portal#key-vault-secrets Categories: Compute Severity: Medium User impact: High Threats: DataSpillage
The following 4 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)
**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
**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