Prevent Shared Key authorization for an Azure Storage account
Every secure request to an Azure Storage account must be authorized. By default, requests can be authorized with either Microsoft Entra credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Microsoft Entra ID provides superior security and ease of use over Shared Key, and is recommended by Azure. To require clients to use Microsoft Entra ID to authorize requests, you can disallow requests to the storage account that are authorized with Shared Key.
When you disallow Shared Key authorization for a storage account, Azure Storage rejects all subsequent requests to that account that are authorized with the account access keys. Only secured requests that are authorized with Microsoft Entra ID will succeed. For more information about using Microsoft Entra ID, see Authorize access to data in Azure Storage.
The AllowSharedKeyAccess property of a storage account is not set by default and does not return a value until you explicitly set it. The storage account permits requests that are authorized with Shared Key when the property value is null or when it is true.
This article describes how to use a DRAG (Detection-Remediation-Audit-Governance) framework to continuously manage Shared Key authorization for your storage account.
Prerequisites
Before disallowing Shared Key access on any of your storage accounts:
- Understand how disallowing Shared Key affects SAS tokens
- Consider compatibility with other Azure tools and services
- Consider the need to disallow Shared Key authorization to use Microsoft Entra Conditional Access
- Authorize access to file data or transition Azure Files workloads
Understand how disallowing Shared Key affects SAS tokens
When Shared Key access is disallowed for the storage account, Azure Storage handles SAS tokens based on the type of SAS and the service that is targeted by the request. The following table shows how each type of SAS is authorized and how Azure Storage will handle that SAS when the AllowSharedKeyAccess property for the storage account is false.
Type of SAS | Type of authorization | Behavior when AllowSharedKeyAccess is false |
---|---|---|
User delegation SAS (Blob storage only) | Microsoft Entra ID | Request is permitted. Azure recommends using a user delegation SAS when possible for superior security. |
Service SAS | Shared Key | Request is denied for all Azure Storage services. |
Account SAS | Shared Key | Request is denied for all Azure Storage services. |
Azure metrics and logging in Azure Monitor do not distinguish between different types of shared access signatures. The SAS filter in Azure Metrics Explorer and the SAS field in Azure Storage logging in Azure Monitor both report requests that are authorized with any type of SAS. However, different types of shared access signatures are authorized differently, and behave differently when Shared Key access is disallowed:
- A service SAS token or an account SAS token is authorized with Shared Key and will not be permitted on a request to Blob storage when the AllowSharedKeyAccess property is set to false.
- A user delegation SAS is authorized with Microsoft Entra ID and will be permitted on a request to Blob storage when the AllowSharedKeyAccess property is set to false.
When you are evaluating traffic to your storage account, keep in mind that metrics and logs as described in Detect the type of authorization used by client applications may include requests made with a user delegation SAS.
For more information about shared access signatures, see Grant limited access to Azure Storage resources using shared access signatures (SAS).
Consider compatibility with other Azure tools and services
A number of Azure services use Shared Key authorization to communicate with Azure Storage. If you disallow Shared Key authorization for a storage account, these services will not be able to access data in that account, and your applications may be adversely affected.
Some Azure tools offer the option to use Microsoft Entra authorization to access Azure Storage. The following table lists some popular Azure tools and notes whether they can use Microsoft Entra ID to authorize requests to Azure Storage.
Azure tool | Microsoft Entra authorization to Azure Storage |
---|---|
Azure portal | Supported. For information about authorizing with your Microsoft Entra account from the Azure portal, see Choose how to authorize access to blob data in the Azure portal. |
AzCopy | Supported for Blob Storage. For information about authorizing AzCopy operations, see Choose how you'll provide authorization credentials in the AzCopy documentation. |
Azure Storage Explorer | Supported for Blob Storage, Queue Storage, Table Storage, and Azure Data Lake Storage. Microsoft Entra ID access to File storage is not supported. Make sure to select the correct Microsoft Entra tenant. For more information, see Get started with Storage Explorer |
Azure PowerShell | Supported. For information about how to authorize PowerShell commands for blob or queue operations with Microsoft Entra ID, see Run PowerShell commands with Microsoft Entra credentials to access blob data or Run PowerShell commands with Microsoft Entra credentials to access queue data. |
Azure CLI | Supported. For information about how to authorize Azure CLI commands with Microsoft Entra ID for access to blob and queue data, see Run Azure CLI commands with Microsoft Entra credentials to access blob or queue data. |
Azure IoT Hub | Supported. For more information, see IoT Hub support for virtual networks. |
Disallow Shared Key authorization to use Microsoft Entra Conditional Access
To protect an Azure Storage account with Microsoft Entra Conditional Access policies, you must disallow Shared Key authorization for the storage account.
Authorize access to file data or transition Azure Files workloads
Azure Storage supports Microsoft Entra authorization for requests to Azure Files, Blob Storage, Queue Storage, and Table Storage. However, by default the Azure portal uses Shared Key authorization to access Azure file shares. If you disallow Shared Key authorization for a storage account that isn't configured with the proper RBAC assignments, requests to Azure Files will fail, and you won't be able to access Azure file shares in the Azure portal.
To mitigate this, we recommend taking one of three approaches:
- Follow these steps to authorize access to file data using your Microsoft Entra account, or
- Migrate any Azure Files data to a separate storage account before you disallow access to an account via Shared Key, or
- Don't apply this setting to storage accounts that support Azure Files workloads.
Identify storage accounts that allow Shared Key access
There are two ways to identify storage accounts that allow Shared Key access:
- Check the Shared Key access setting for multiple accounts
- Configure the Azure Policy for Shared Key access in audit mode
Check the Shared Key access setting for multiple accounts
To check the Shared Key access setting across a set of storage accounts with optimal performance, you can use the Azure Resource Graph Explorer in the Azure portal. To learn more about using the Resource Graph Explorer, see Quickstart: Run your first Resource Graph query using Azure Resource Graph Explorer.
Running the following query in the Resource Graph Explorer returns a list of storage accounts and displays the Shared Key access setting for each account:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowSharedKeyAccess = parse_json(properties).allowSharedKeyAccess
| project subscriptionId, resourceGroup, name, allowSharedKeyAccess
Configure the Azure Policy for Shared Key access in audit mode
Azure Policy Storage accounts should prevent shared key access prevents users with appropriate permissions from configuring new or existing storage accounts to permit Shared Key authorization. Configure this policy in audit mode to identify storage accounts where Shared Key authorization is allowed. After you have changed applications to use Microsoft Entra rather than Shared Key for authorization, you can update the policy to prevent allowing Shared Key access.
For more information about the built-in policy, see Storage accounts should prevent shared key access in List of built-in policy definitions.
Assign the built-in policy for a resource scope
Follow these steps to assign the built-in policy for the appropriate scope in the Azure portal:
In the Azure portal, search for Policy to display the Azure Policy dashboard.
In the Authoring section, select Assignments.
Choose Assign policy.
On the Basics tab of the Assign policy page, in the Scope section, specify the scope for the policy assignment. Select the More button (...) to choose the subscription and optional resource group.
For the Policy definition field, select the More button (...), and enter shared key access in the Search field. Select the policy definition named Storage accounts should prevent shared key access.
Select Review + create.
On the Review + create tab, review the policy assignment then select Create to assign the policy definition to the specified scope.
Monitor compliance with the policy
To monitor your storage accounts for compliance with the Shared Key access policy, follow these steps:
On the Azure Policy dashboard under Authoring, select Assignments.
Locate and select the policy assignment you created in the previous section.
Select the View compliance tab.
Any storage accounts within the scope of the policy assignment that do not meet the policy requirements appear in the compliance report.
To get more information about why a storage account is non-compliant, select Details under Compliance reason.
Detect the type of authorization used by client applications
To understand how disallowing Shared Key authorization may affect client applications before you make this change, enable logging and metrics for the storage account. You can then analyze patterns of requests to your account over a period of time to determine how requests are being authorized.
Use metrics to determine how many requests the storage account is receiving that are authorized with Shared Key or a shared access signature (SAS). Use logs to determine which clients are sending those requests.
A SAS may be authorized with either Shared Key or Microsoft Entra ID. For more information about interpreting requests made with a shared access signature, see Understand how disallowing Shared Key affects SAS tokens.
Determine the number and frequency of requests authorized with Shared Key
To track how requests to a storage account are being authorized, use Azure Metrics Explorer in the Azure portal. For more information about Metrics Explorer, see Analyze metrics with Azure Monitor metrics explorer.
Follow these steps to create a metric that tracks requests made with Shared Key or SAS:
Navigate to your storage account in the Azure portal. Under the Monitoring section, select Metrics.
The new metric box should appear:
If it doesn't, select Add metric.
In the Metric dialog, specify the following values:
- Leave the Scope field set to the name of the storage account.
- Set the Metric Namespace to Account. This metric will report on all requests against the storage account.
- Set the Metric field to Transactions.
- Set the Aggregation field to Sum.
The new metric will display the sum of the number of transactions against the storage account over a given interval of time. The resulting metric appears as shown in the following image:
Next, select the Add filter button to create a filter on the metric for type of authorization.
In the Filter dialog, specify the following values:
- Set the Property value to Authentication.
- Set the Operator field to the equal sign (=).
- In the Values field, select Account Key and SAS.
In the upper-right corner, select the time range for which you want to view the metric. You can also indicate how granular the aggregation of requests should be, by specifying intervals anywhere from 1 minute to 1 month. For example, set the Time range to 30 days and the Time granularity to 1 day to see requests aggregated by day over the past 30 days.
After you have configured the metric, requests to your storage account will begin to appear on the graph. The following image shows requests that were authorized with Shared Key or made with a SAS token. Requests are aggregated per day over the past thirty days.
You can also configure an alert rule to notify you when a certain number of requests that are authorized with Shared Key are made against your storage account. For more information, see Create, view, and manage metric alerts using Azure Monitor.
Analyze logs to identify clients that are authorizing requests with Shared Key or SAS
Azure Storage logs capture details about requests made against the storage account, including how a request was authorized. You can analyze the logs to determine which clients are authorizing requests with Shared Key or a SAS token.
To log requests to your Azure Storage account in order to evaluate how they are authorized, you can use Azure Storage logging in Azure Monitor. For more information, see Monitor Azure Storage.
Azure Storage logging in Azure Monitor supports using log queries to analyze log data. To query logs, you can use an Azure Log Analytics workspace. To learn more about log queries, see Tutorial: Get started with Log Analytics queries.
Create a diagnostic setting in the Azure portal
To log Azure Storage data with Azure Monitor and analyze it with Azure Log Analytics, you must first create a diagnostic setting that indicates what types of requests and for which storage services you want to log data. After you configure logging for your storage account, the logs are available in the Log Analytics workspace. To create a workspace, see Create a Log Analytics workspace in the Azure portal.
To learn how to create a diagnostic setting in the Azure portal, see Create diagnostic settings in Azure Monitor.
For a reference of fields available in Azure Storage logs in Azure Monitor, see Resource logs.
Query logs for requests made with Shared Key or SAS
Azure Storage logs in Azure Monitor include the type of authorization that was used to make a request to a storage account. To retrieve logs for requests made in the last seven days that were authorized with Shared Key or SAS, open your Log Analytics workspace. Next, paste the following query into a new log query and run it. This query displays the ten IP addresses that most frequently sent requests that were authorized with Shared Key or SAS:
StorageBlobLogs
| where AuthenticationType in ("AccountKey", "SAS") and TimeGenerated > ago(7d)
| summarize count() by CallerIpAddress, UserAgentHeader, AccountName
| top 10 by count_ desc
You can also configure an alert rule based on this query to notify you about requests authorized with Shared Key or SAS. For more information, see Create, view, and manage log alerts using Azure Monitor.
Remediate authorization via Shared Key
After you have analyzed how requests to your storage account are being authorized, you can take action to prevent access via Shared Key. But first, you need to update any applications that are using Shared Key authorization to use Microsoft Entra ID instead. You can monitor logs and metrics as described in Detect the type of authorization used by client applications to track the transition. For more information about using Microsoft Entra ID to access data in a storage account, see Authorize access to data in Azure Storage.
When you are confident that you can safely reject requests that are authorized with Shared Key, you can set the AllowSharedKeyAccess property for the storage account to false.
Warning
If any clients are currently accessing data in your storage account with Shared Key, then Azure recommends that you migrate those clients to Microsoft Entra ID before disallowing Shared Key access to the storage account.
Permissions for allowing or disallowing Shared Key access
To set the AllowSharedKeyAccess property for the storage account, a user must have permissions to create and manage storage accounts. Azure role-based access control (Azure RBAC) roles that provide these permissions include the Microsoft.Storage/storageAccounts/write or Microsoft.Storage/storageAccounts/* action. Built-in roles with this action include:
- The Azure Resource Manager Owner role
- The Azure Resource Manager Contributor role
- The Storage Account Contributor role
These roles do not provide access to data in a storage account via Microsoft Entra ID. However, they include the Microsoft.Storage/storageAccounts/listkeys/action, which grants access to the account access keys. With this permission, a user can use the account access keys to access all data in a storage account.
Role assignments must be scoped to the level of the storage account or higher to permit a user to allow or disallow Shared Key access for the storage account. For more information about role scope, see Understand scope for Azure RBAC.
Be careful to restrict assignment of these roles only to those who require the ability to create a storage account or update its properties. Use the principle of least privilege to ensure that users have the fewest permissions that they need to accomplish their tasks. For more information about managing access with Azure RBAC, see Best practices for Azure RBAC.
Note
The classic subscription administrator roles Service Administrator and Co-Administrator include the equivalent of the Azure Resource Manager Owner role. The Owner role includes all actions, so a user with one of these administrative roles can also create and manage storage accounts. For more information, see Azure roles, Microsoft Entra roles, and classic subscription administrator roles.
Disable Shared Key authorization
Using an account that has the necessary permissions, disable Shared Key authorization in the Azure portal, with PowerShell or using the Azure CLI.
To disallow Shared Key authorization for a storage account in the Azure portal, follow these steps:
After you disallow Shared Key authorization, making a request to the storage account with Shared Key authorization will fail with error code 403 (Forbidden). Azure Storage returns an error indicating that key-based authorization is not permitted on the storage account.
The AllowSharedKeyAccess property is supported for storage accounts that use the Azure Resource Manager deployment model only. For information about which storage accounts use the Azure Resource Manager deployment model, see Types of storage accounts.
Verify that Shared Key access is not allowed
To verify that Shared Key authorization is no longer permitted, you can query the Azure Storage Account settings with the following command. Replace the placeholder values in brackets with your own values.
az storage account show \
--name <storage-account-name> \
--resource-group <resource-group-name> \
--query "allowSharedKeyAccess"
The command returns false if Shared Key authorization is disallowed for the storage account.
Note
Anonymous requests are not authorized and will proceed if you have configured the storage account and container for anonymous read access. For more information, see Configure anonymous read access for containers and blobs.
Monitor the Azure Policy for compliance
After disallowing Shared Key access on the desired storage accounts, continue to monitor the policy you created earlier for ongoing compliance. Based on the monitoring results, take the appropriate action as needed, including changing the scope of the policy, disallowing Shared Key access on more accounts or allowing it for accounts where more time is needed for remediation.
Update the Azure Policy to prevent allowing Shared Key access
To begin enforcing the Azure Policy assignment you previously created for policy Storage accounts should prevent shared key access, change the Effect of the policy assignment to Deny to prevent authorized users from allowing Shared Key access on storage accounts. To change the effect of the policy, perform the following steps:
On the Azure Policy dashboard, locate and select the policy assignment you previously created.
Select Edit assignment.
Go to the Parameters tab.
Uncheck the Only show parameters that need input or review checkbox.
In the Effect drop-down change Audit to Deny, then select Review + save.
On the Review + save tab, review your changes, then select Save.
Note
It might take up to 30 minutes for your policy change to take effect.