Azure Storage Access Key
ID |
azure_storage_key |
Severity |
critical |
Vendor |
Microsoft Azure |
Family |
Access key |
Description
Azure Storage is Azure’s cloud storage service.
For api access to the Azure Storage service, every request must be authorized, unless the request is for a blob or container resource that has been made publicly available.
Authentication to Azure Storage can use an storage account key (also known as Shared Key), or the newer Microsoft Entra ID, the evolution of the Active Directory. The latter is the currently recommended alternative by Microsoft.
Security
Azure Storage access keys are similar to a root password for storage accounts. These access keys must be protected carefully, using Azure Key Vault to manage and rotate keys securely. Avoid distributing access keys to other users, hard-coding them, or saving them anywhere in plain text that is accessible to others.
Microsoft now recommends to migrate from storage access keys to Microsoft Entra ID.
Examples
# Hardcoded Azure Storage access key $storageAccountKey = "lJzRc1YdHaAA2KCNJJ1tkYwF/+mKK6Ygw0NGe170Xu592euJv2wYUtBlV8z+qnlcNQSnIYVTkLWntUO1F8j8rQ=="
Instead of hardcoding access keys, you may use the PowerShell Get-AzStorageAccountKey
command:
# To get the first key (reserve the second for key rotation) $storageAccountKey = ` (Get-AzStorageAccountKey -ResourceGroupName <resource-group> ` -Name <storage-account>).Value[0]
Mitigation / Fix
-
Follow your policy for handling leaked secrets, which typically require revoking the secret in the target system(s). Rotate your keys if you believe they may have been compromised.
-
Remove the possibly leaked access key from the source code or committed configuration file. Only when needed by compliance with your security standards you would consider to rewrite the git history to change the offending commit.
You should consider any sensitive data in commits with secrets as compromised.
Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.
-
Check access logs to ensure that the secret was not used by unintended actors during the compromised period.
-
A proper key expiration policy should be in place. Avoid the
Storage account keys should not be expired
option.