Navigate to your storage account in the Azure portal. Under the Monitoring section, select Metrics .

Select Add metric . In the Metric dialog, specify the following values:

Next, select the Add filter button to create a filter on the metric for anonymous requests.

In the Filter dialog, specify the following values:

In the upper-right corner, select the time interval over 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.

After you have configured the metric, anonymous requests will begin to appear on the graph. The following image shows anonymous requests aggregated over the past 30 minutes.

You can also configure an alert rule to notify you when a certain number of anonymous requests are made against your storage account. For more information, see Create, view, and manage metric alerts using Azure Monitor .

Analyze logs to identify containers receiving anonymous requests

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 containers are receiving anonymous requests.

To log requests to your Azure Storage account in order to evaluate anonymous requests, 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. To create a diagnostic setting in the Azure portal, follow these steps:

Create a new Log Analytics workspace in the subscription that contains your Azure Storage account. After you configure logging for your storage account, the logs will be available in the Log Analytics workspace. For more information, see Create a Log Analytics workspace in the Azure portal .

Navigate to your storage account in the Azure portal.

In the Monitoring section, select Diagnostic settings .

Select Blob to log requests made against Blob storage.

Select Add diagnostic setting .

Provide a name for the diagnostic setting.

Under Category details , in the log section, choose which types of requests to log. All anonymous requests are read requests, so select StorageRead to capture anonymous requests.

Under Destination details , select Send to Log Analytics . Select your subscription and the Log Analytics workspace you created earlier, as shown in the following image.

After you create the diagnostic setting, requests to the storage account are subsequently logged according to that setting. For more information, see Create diagnostic setting to collect resource logs and metrics in Azure .

For a reference of fields available in Azure Storage logs in Azure Monitor, see Resource logs .

Query logs for anonymous requests

Azure Storage logs in Azure Monitor include the type of authorization that was used to make a request to a storage account. In your log query, filter on the AuthenticationType property to view anonymous requests.

To retrieve logs for the last seven days for anonymous requests against Blob storage, open your Log Analytics workspace. Next, paste the following query into a new log query and run it:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
You can also configure an alert rule based on this query to notify you about anonymous requests. For more information, see Create, view, and manage log alerts using Azure Monitor.
Responses to anonymous requests
When Blob Storage receives an anonymous request, that request will succeed if all of the following conditions are true:
Anonymous public access is allowed for the storage account.
The container is configured to allow anonymous public access.
The request is for read access.
If any of those conditions are not true, then the request will fail. The response code on failure depends on whether the anonymous request was made with a version of the service that supports the bearer challenge. The bearer challenge is supported with service versions 2019-12-12 and newer:
If the anonymous request was made with a service version that supports the bearer challenge, then the service returns error code 401 (Unauthorized).
If the anonymous request was made with a service version that does not support the bearer challenge and anonymous public access is disallowed for the storage account, then the service returns error code 409 (Conflict).
If the anonymous request was made with a service version that does not support the bearer challenge and anonymous public access is allowed for the storage account, then the service returns error code 404 (Not Found).
For more information about the bearer challenge, see Bearer challenge.
Remediate anonymous public access for the storage account
After you have evaluated anonymous requests to containers and blobs in your storage account, you can take action to remediate public access for the whole account by setting the account's AllowBlobPublicAccess property to False.
The public access setting for a storage account overrides the individual settings for containers in that account. When you disallow public access for a storage account, any containers that are configured to permit public access are no longer accessible anonymously. If you've disallowed public access for the account, you don't also need to disable public access for individual containers.
If your scenario requires that certain containers need to be available for public access, then you should move those containers and their blobs into separate storage accounts that are reserved for public access. You can then disallow public access for any other storage accounts.
Remediating blob public access requires version 2019-04-01 or later of the Azure Storage resource provider. For more information, see Azure Storage Resource Provider REST API.
Permissions for disallowing public access
To set the AllowBlobPublicAccess 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 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
Role assignments must be scoped to the level of the storage account or higher to permit a user to disallow public 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 administrative users 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.




    

These roles don't provide access to data in a storage account via Azure Active Directory (Azure AD). 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.
The Microsoft.Storage/storageAccounts/listkeys/action itself grants data access via the account keys, but doesn't grant a user the ability to change the AllowBlobPublicAccess property for a storage account. For users who need to access data in your storage account but shouldn't have the ability to change the storage account's configuration, consider assigning roles such as Storage Blob Data Contributor, Storage Blob Data Reader, or Reader and Data Access.
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 storage accounts and manage account configuration. For more information, see Azure roles, Azure AD roles, and classic subscription administrator roles.
Set the storage account's AllowBlobPublicAccess property to False
To disallow public access for a storage account, set the account's AllowBlobPublicAccess property to False. This property is available for all storage accounts that are created with the Azure Resource Manager deployment model. For more information, see Storage account overview.
The AllowBlobPublicAccess property isn't set for a storage account by default and doesn't return a value until you explicitly set it. The storage account permits public access when the property value is either null or true.
Important
Disallowing public access for a storage account overrides the public access settings for all containers in that storage account. When public access is disallowed for the storage account, any future anonymous requests to that account will fail. Before changing this setting, be sure to understand the impact on client applications that may be accessing data in your storage account anonymously by following the steps outlined in Detect anonymous requests from client applications.
To disallow public access for a storage account in the Azure portal, follow these steps:
Navigate to your storage account in the Azure portal.
Locate the Configuration setting under Settings.
Set Blob public access to Disabled.
To disallow public access for a storage account with PowerShell, install Azure PowerShell version 4.4.0 or later. Next, configure the AllowBlobPublicAccess property for a new or existing storage account.
The following example creates a storage account and explicitly sets the AllowBlobPublicAccess property to false. Remember to replace the placeholder values in brackets with your own values:
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$location = "<location>"
# Create a storage account with AllowBlobPublicAccess set to false.
New-AzStorageAccount -ResourceGroupName $rgName `
    -Name $accountName `
    -Location $location `
    -SkuName Standard_GRS `
    -AllowBlobPublicAccess $false
# Read the AllowBlobPublicAccess property for the newly created storage account.
(Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName).AllowBlobPublicAccess
To disallow public access for a storage account with Azure CLI, install Azure CLI version 2.9.0 or later. For more information, see Install the Azure CLI. Next, configure the allowBlobPublicAccess property for a new or existing storage account.
The following example creates a storage account and explicitly sets the allowBlobPublicAccess property to false. Remember to replace the placeholder values in brackets with your own values:
az storage account create \
    --name <storage-account> \
    --resource-group <resource-group> \
    --kind StorageV2 \
    --location <location> \
    --allow-blob-public-access false
az storage account show \
    --name <storage-account> \
    --resource-group <resource-group> \
    --query allowBlobPublicAccess \
    --output tsv
To disallow public access for a storage account with a template, create a template with the AllowBlobPublicAccess property set to false. The following steps describe how to create a template in the Azure portal.
In the Azure portal, choose Create a resource.
In Search the Marketplace, type template deployment, and then press ENTER.
Choose Template deployment (deploy using custom templates), choose Create, and then choose Build your own template in the editor.
In the template editor, paste in the following JSON to create a new account and set the AllowBlobPublicAccess property to false. Remember to replace the placeholders in angle brackets with your own values.
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {},
    "variables": {
        "storageAccountName": "[concat(uniqueString(subscription().subscriptionId), 'template')]"
    "resources": [
        "name": "[variables('storageAccountName')]",
        "type": "Microsoft.Storage/storageAccounts",
        "apiVersion": "2019-06-01",
        "location": "<location>",
        "properties": {
            "allowBlobPublicAccess": false
        "dependsOn": [],
        "sku": {
          "name": "Standard_GRS"
        "kind": "StorageV2",
        "tags": {}
Save the template.
Specify resource group parameter, then choose the Review + create button to deploy the template and create a storage account with the allowBlobPublicAccess property configured.
Disallowing public access for a storage account does not affect any static websites hosted in that storage account. The $web container is always publicly accessible.
After you update the public access setting for the storage account, it may take up to 30 seconds before the change is fully propagated.
Sample script for bulk remediation
The following sample PowerShell script runs against all Azure Resource Manager storage accounts in a subscription and sets the AllowBlobPublicAccess setting for those accounts to False.
.SYNOPSIS
Finds storage accounts in a subscription where AllowBlobPublicAccess is True or null.
.DESCRIPTION
This script runs against all Azure Resource Manager storage accounts in a subscription
and sets the "AllowBlobPublicAccess" property to False.
Standard operation will enumerate all accounts where the setting is enabled and allow the 
user to decide whether or not to disable the setting.  
Classic storage accounts will require individual adjustment of containers to remove public
access, and will not be affected by this script.
Run with BypassConfirmation=$true if you wish to disallow public access on all Azure Resource Manager 
storage accounts without individual confirmation.
You will need access to the subscription to run the script.
.PARAMETER BypassConformation
Set this to $true to skip confirmation of changes. Not recommended.
.PARAMETER SubscriptionId
The subscription ID of the subscription to check.
.PARAMETER ReadOnly
Set this parameter so that the script makes no changes to any subscriptions and only reports affect accounts.
.PARAMETER NoSignin
Set this parameter so that no sign-in occurs -- you must sign in first. Use this if you're invoking this script repeatedly for multiple subscriptions and want to avoid being prompted to sign-in for each subscription.
.OUTPUTS
This command produces only STDOUT output (not standard PowerShell) with information about affect accounts.
param(
    [boolean]$BypassConfirmation=$false,
    [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName='SubscriptionId')]
    [String] $SubscriptionId,
    [switch] $ReadOnly, # Use this if you don't want to make changes, but want to get information about affected accounts
    [switch] $NoSignin # Use this if you are already signed in and don't want to be prompted again
begin {
    if ( ! $NoSignin.IsPresent ) {
        login-azaccount | out-null
process {
    Write-Host "NOTE: If you are using OAuth authorization on a storage account, disabling public access at the account level may interfere with authorization."
    try {
        select-azsubscription -subscriptionid $SubscriptionId -erroraction stop | out-null
    } catch {
        write-error "Unable to access select subscription '$SubscriptionId' as the signed in user -- ensure that you have access to this subscription." -erroraction stop
    foreach ($account in Get-AzStorageAccount) 
        if($account.AllowBlobPublicAccess -eq $null -or $account.AllowBlobPublicAccess -eq $true)
            Write-host "Account:" $account.StorageAccountName " is not disallowing public access."
            if ( ! $ReadOnly.IsPresent ) {
                if(!$BypassConfirmation)
                    $confirmation = Read-Host "Do you wish to disallow public access? [y/n]"
                if($BypassConfirmation -or $confirmation -eq 'y')
                        set-AzStorageAccount -Name $account.StorageAccountName -ResourceGroupName $account.ResourceGroupName -AllowBlobPublicAccess $false
                        Write-Host "Success!"
                    catch
                        Write-output $_
        elseif($account.AllowBlobPublicAccess -eq $false)
            Write-Host "Account:" $account.StorageAccountName " has public access disabled, no action required."
            Write-Host "Account:" $account.StorageAccountName ". Error, please manually investigate."
end {
    Write-Host "Script complete"
Verify that anonymous access has been remediated
To verify that you've remediated anonymous access for a storage account, you can test that anonymous access to a blob isn't permitted, that modifying a container's public access setting isn't permitted, and that it's not possible to create a container with anonymous access enabled.
Verify that public access to a blob isn't permitted
To verify that public access to a specific blob is disallowed, you can attempt to download the blob via its URL. If the download succeeds, then the blob is still publicly available. If the blob isn't publicly accessible because public access has been disallowed for the storage account, then you'll see an error message indicating that public access isn't permitted on this storage account.
The following example shows how to use PowerShell to attempt to download a blob via its URL. Remember to replace the placeholder values in brackets with your own values:
$url = "<absolute-url-to-blob>"
$downloadTo = "<file-path-for-download>"
Invoke-WebRequest -Uri $url -OutFile $downloadTo -ErrorAction Stop
Verify that modifying the container's public access setting isn't permitted
To verify that a container's public access setting can't be modified after public access is disallowed for the storage account, you can attempt to modify the setting. Changing the container's public access setting fails if public access is disallowed for the storage account.
The following example shows how to use PowerShell to attempt to change a container's public access setting. Remember to replace the placeholder values in brackets with your own values:
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
Set-AzStorageContainerAcl -Context $ctx -Container $containerName -Permission Blob
Verify that creating a container with public access enabled isn't permitted
If public access is disallowed for the storage account, then you won't be able to create a new container with public access enabled. To verify, you can attempt to create a container with public access enabled.
The following example shows how to use PowerShell to attempt to create a container with public access enabled. Remember to replace the placeholder values in brackets with your own values:
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
New-AzStorageContainer -Name $containerName -Permission Blob -Context $ctx
Check the public access setting for multiple accounts
To check the public 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.
The AllowBlobPublicAccess property isn't set for a storage account by default and doesn't return a value until you explicitly set it. The storage account permits public access when the property value is either null or true.
Running the following query in the Resource Graph Explorer returns a list of storage accounts and displays public access setting for each account:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
The following image shows the results of a query across a subscription. For storage accounts where the AllowBlobPublicAccess property has been explicitly set, it appears in the results as true or false. If the AllowBlobPublicAccess property hasn't been set for a storage account, it appears as blank (or null) in the query results.
Use Azure Policy to audit for compliance
If you have a large number of storage accounts, you may want to perform an audit to make sure that those accounts are configured to prevent public access. To audit a set of storage accounts for their compliance, use Azure Policy. Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Policy helps you to keep those resources compliant with your corporate standards and service level agreements. For more information, see Overview of Azure Policy.
Create a policy with an Audit effect
Azure Policy supports effects that determine what happens when a policy rule is evaluated against a resource. The Audit effect creates a warning when a resource isn't in compliance, but doesn't stop the request. For more information about effects, see Understand Azure Policy effects.
To create a policy with an Audit effect for the public access setting for a storage account with the Azure portal, follow these steps:
In the Azure portal, navigate to the Azure Policy service.
Under the Authoring section, select Definitions.
Select Add policy definition to create a new policy definition.
For the Definition location field, select the More button to specify where the audit policy resource is located.
Specify a name for the policy. You can optionally specify a description and category.
Under Policy rule, add the following policy definition to the policyRule section.
  "if": {
    "allOf": [
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
        "not": {
          "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
          "equals": "false"
  "then": {
    "effect": "audit"
Save the policy.
Assign the policy
Next, assign the policy to a resource. The scope of the policy corresponds to that resource and any resources beneath it. For more information on policy assignment, see Azure Policy assignment structure.
To assign the policy with the Azure portal, follow these steps:
In the Azure portal, navigate to the Azure Policy service.
Under the Authoring section, select Assignments.
Select Assign policy to create a new policy assignment.
For the Scope field, select the scope of the policy assignment.
For the Policy definition field, select the More button, then select the policy you defined in the previous section from the list.
Provide a name for the policy assignment. The description is optional.
Leave Policy enforcement set to Enabled. This setting has no effect on the audit policy.
Select Review + create to create the assignment.
View compliance report
After you've assigned the policy, you can view the compliance report. The compliance report for an audit policy provides information on which storage accounts aren't in compliance with the policy. For more information, see Get policy compliance data.
It may take several minutes for the compliance report to become available after the policy assignment is created.
To view the compliance report in the Azure portal, follow these steps:
In the Azure portal, navigate to the Azure Policy service.
Select Compliance.
Filter the results for the name of the policy assignment that you created in the previous step. The report shows how many resources aren't in compliance with the policy.
You can drill down into the report for additional details, including a list of storage accounts that aren't in compliance.
Use Azure Policy to enforce authorized access
Azure Policy supports cloud governance by ensuring that Azure resources adhere to requirements and standards. To ensure that storage accounts in your organization permit only authorized requests, you can create a policy that prevents the creation of a new storage account with a public access setting that allows anonymous requests. This policy will also prevent all configuration changes to an existing account if the public access setting for that account isn't compliant with the policy.
The enforcement policy uses the Deny effect to prevent a request that would create or modify a storage account to allow public access. For more information about effects, see Understand Azure Policy effects.
To create a policy with a Deny effect for a public access setting that allows anonymous requests, follow the same steps described in Use Azure Policy to audit for compliance, but provide the following JSON in the policyRule section of the policy definition:
  "if": {
    "allOf": [
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
        "not": {
          "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
          "equals": "false"
  "then": {
    "effect": "deny"
After you create the policy with the Deny effect and assign it to a scope, a user can't create a storage account that allows public access. Nor can a user make any configuration changes to an existing storage account that currently allows public access. Attempting to do so results in an error. The public access setting for the storage account must be set to false to proceed with account creation or configuration.
The following image shows the error that occurs if you try to create a storage account that allows public access (the default for a new account) when a policy with a Deny effect requires that public access is disallowed.
Overview: Remediating anonymous public read access for blob data
Remediate anonymous public read access to blob data (classic deployments)
Security recommendations for Blob storage