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.
Multiple Remediation Paths
Azure
SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.
PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.
References for Service-Wide Patterns
- Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
- Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
- Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
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}
}
