Microsoft AzureOverview
Azure Key Vault will store multiple types of sensitive information, such as encryption keys, certificate thumbprints, and Managed Identity Credentials. Access to these secrets can be controlled through granular permissions.
Rationale
The credentials given to an application have permission to create, delete, or modify data stored within the systems they access. If these credentials are stored within the application, anyone with access to it or a copy of the code can access them. Storing within Azure Key Vault as secrets increases security by controlling access. This also allows for updates of the credentials without redeploying the entire application.
Impact
References to secrets within the key vault must be specifically integrated within the application code. This will require additional configuration during application writing or refactoring. Additional costs are also charged per 10,000 requests to the Key Vault.
Remediation guidance
For connecting to Azure services, there are more secure ways that do not require secrets.
However, if you need to provide secrets to your web app, we recommend storing them in Azure Key Vault and referencing them. The procedure is relatively simple and well described in the Azure documentation.
In short, you will need to:
- Create or use an existing Azure Key Vault.
- Add the secrets to the Key Vault.
- Grant permission for the Web App to the Key Vault. This implies your web app uses a managed identity (system or user-assigned). You can use the predefined role
Key Vault Secrets Userfor RBAC Key Vaults, or assignGetsecrets permissions if using access policies. - Reference the Key Vault secrets from the app settings using the special value
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)or@Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret)
Azure Portal (Asset-Level)
- Open the affected resource from the finding details in Azure Portal.
- Navigate to the relevant Security/Configuration/Networking blade.
- Apply the control-specific secure setting.
- Save and re-run the check.
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
Azure
Use management group or subscription Azure Policy assignments, remediation tasks where supported, landing-zone standards, and IaC modules so drift is prevented at scale.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
FunctionApps with secrets that are not keyvault references
Connectors
Covered asset types
Expected check: eq []
{
functionApps(
where: {
applicationConfig: {
settings_SOME: {
type: "AppService"
key_MATCHES: "(.*)(_*?)(key|pass|secret|salt|connectionstring|connection_string)(.*)"
}
}
}
) {...AssetFragment}
}Sites with secrets that are not keyvault references
Connectors
Covered asset types
Expected check: eq []
{
sites(
where: {
applicationConfig: {
settings_SOME: {
type: "AppService"
key_MATCHES: "(.*)(_*?)(key|pass|secret|salt|connectionstring|connection_string)(.*)"
}
}
}
) {...AssetFragment}
}
