learn.microsoft.com
Open in
urlscan Pro
2a02:26f0:3400:182::3544
Public Scan
Submitted URL: https://go.microsoft.com/fwlink/?linkid=2179708
Effective URL: https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent
Submission: On August 11 via api from DE — Scanned from DE
Effective URL: https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent
Submission: On August 11 via api from DE — Scanned from DE
Form analysis
3 forms found in the DOMName: nav-bar-search-form — GET /en-us/search/
<form class="nav-bar-search-form" method="GET" name="nav-bar-search-form" role="search" id="nav-bar-search-form" aria-label="Search" action="/en-us/search/">
<div class="autocomplete" data-bi-name="autocomplete"><!---->
<div class="field-body control ">
<input role="combobox" maxlength="100" aria-autocomplete="list" autocapitalize="off" autocomplete="off" autocorrect="off" spellcheck="false" id="site-search-input" data-test-id="site-search-input" class="autocomplete-input input input-sm
" type="search" name="terms" aria-expanded="false" aria-owns="ax-109-listbox" aria-controls="ax-109-listbox" aria-activedescendant="" aria-label="Search" aria-describedby="ms--site-search-input-description" placeholder="Search" pattern=".*">
<span aria-hidden="true" class="icon is-small is-left" hidden="">
<span class="has-text-primary docon docon-undefined"></span>
</span>
<span aria-hidden="true" class="autocomplete-loader loader has-text-primary " hidden=""></span>
<span hidden="" id="ms--site-search-input-description"> Suggestions will filter as you type </span>
</div>
<ul role="listbox" id="ax-109-listbox" data-test-id="site-search-input-listbox" class="autocomplete-suggestions is-vertically-scrollable padding-xxs " aria-label="Suggestions" hidden="">
</ul>
<!---->
</div>
<!-- mobile safari will not dispatch submit event unless there's a submit button that is not display:none -->
<button type="submit" class="visually-hidden" tabindex="-1" aria-hidden="true"></button>
<input name="category" hidden="" value="">
<input name="scope" hidden="" value="Azure">
<input name="fromNavSearch" hidden="" value="true">
</form>
Name: nav-bar-search-form — GET /en-us/search/
<form class="nav-bar-search-form" method="GET" name="nav-bar-search-form" role="search" id="nav-bar-search-form-desktop" aria-label="Search" action="/en-us/search/">
<div class="autocomplete" data-bi-name="autocomplete"><!---->
<div class="field-body control has-icons-left">
<input role="combobox" maxlength="100" aria-autocomplete="list" autocapitalize="off" autocomplete="off" autocorrect="off" spellcheck="false" id="site-search-input-desktop" data-test-id="site-search-input-desktop" class="autocomplete-input input input-sm
control has-icons-left
" type="search" name="terms" aria-expanded="false" aria-owns="ax-110-listbox" aria-controls="ax-110-listbox" aria-activedescendant="" aria-label="Search" aria-describedby="ms--site-search-input-desktop-description" placeholder="Search"
pattern=".*">
<span aria-hidden="true" class="icon is-small is-left">
<span class="has-text-primary docon docon-search"></span>
</span>
<span aria-hidden="true" class="autocomplete-loader loader has-text-primary " hidden=""></span>
<span hidden="" id="ms--site-search-input-desktop-description"> Suggestions will filter as you type </span>
</div>
<ul role="listbox" id="ax-110-listbox" data-test-id="site-search-input-desktop-listbox" class="autocomplete-suggestions is-vertically-scrollable padding-xxs " aria-label="Suggestions" hidden="">
</ul>
<!---->
</div>
<!-- mobile safari will not dispatch submit event unless there's a submit button that is not display:none -->
<button type="submit" class="visually-hidden" tabindex="-1" aria-hidden="true"></button>
<input name="category" hidden="" value="">
<input name="scope" hidden="" value="Azure">
<input name="fromNavSearch" hidden="" value="true">
</form>
javascript:
<form action="javascript:" role="search" aria-label="Search" class="margin-bottom-xxs"><label class="visually-hidden" for="ax-122">Search</label>
<div class="autocomplete display-block" data-bi-name="autocomplete"><!---->
<div class="field-body control has-icons-left">
<input role="combobox" maxlength="100" aria-autocomplete="list" autocapitalize="off" autocomplete="off" autocorrect="off" spellcheck="false" id="ax-122" data-test-id="ax-122" class="autocomplete-input input input-sm
control has-icons-left
width-full" type="text" aria-expanded="false" aria-owns="ax-123-listbox" aria-controls="ax-123-listbox" aria-activedescendant="" aria-describedby="ms--ax-122-description" placeholder="Filter by title" pattern=".*">
<span aria-hidden="true" class="icon is-small is-left">
<span class="has-text-primary docon docon-filter-settings"></span>
</span>
<span aria-hidden="true" class="autocomplete-loader loader has-text-primary " hidden=""></span>
<span hidden="" id="ms--ax-122-description"> Suggestions will filter as you type </span>
</div>
<ul role="listbox" id="ax-123-listbox" data-test-id="ax-122-listbox" class="autocomplete-suggestions is-vertically-scrollable padding-xxs " aria-label="Suggestions" hidden="">
</ul>
<!---->
</div>
</form>
Text Content
Skip to main content We use optional cookies to improve your experience on our websites, such as through social media connections, and to display personalized advertising based on your online activity. If you reject optional cookies, only cookies necessary to provide you the services will be used. You may change your selection by clicking “Manage Cookies” at the bottom of the page. Privacy Statement Third-Party Cookies Accept Reject Manage cookies This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Download Microsoft Edge More info about Internet Explorer and Microsoft Edge Documentation Global navigation * Learn * Documentation * Training * Certifications * Q&A * Code Samples * Assessments * Shows * Events * More * Documentation * Training * Certifications * Q&A * Code Samples * Assessments * Shows * Events Suggestions will filter as you type Suggestions will filter as you type Search Sign in * Profile * Settings Sign out Azure * Product documentation * Compute * Networking * Storage * Web * Mobile * Containers * Databases * All products * Architecture * Get started * Reference architectures * Cloud Adoption Framework for Azure * Azure Well-Architected Framework * Design patterns * Assessments * Learn Azure * Self-paced learning paths * Pluralsight * Instructor-led courses * Develop * Python * .NET * JavaScript * Java * Go * Resources * Pricing * Contact sales * Videos * Webinars * Updates * White papers * Blog * Support * More * Product documentation * Compute * Networking * Storage * Web * Mobile * Containers * Databases * All products * Architecture * Get started * Reference architectures * Cloud Adoption Framework for Azure * Azure Well-Architected Framework * Design patterns * Assessments * Learn Azure * Self-paced learning paths * Pluralsight * Instructor-led courses * Develop * Python * .NET * JavaScript * Java * Go * Resources * Pricing * Contact sales * Videos * Webinars * Updates * White papers * Blog * Support 1. Portal 2. Free account Table of contents Exit focus mode Search Suggestions will filter as you type * Azure Blob Storage documentation * Overview * What is Azure Blob Storage? * Compare core storage services * Blob Storage feature support * Blob storage * Overview * Quickstarts * Tutorials * Samples * Concepts * How to * Configure Blob Storage * Create and manage storage accounts * Create and manage containers * Create and manage blobs * Authorize access to blob data * Authorization options for users * Manage access rights with Azure RBAC * Authorize with Shared Key * Delegate access with shared access signatures (SAS) * Manage anonymous read access to blob data * Overview * Remediate anonymous access (Azure Resource Manager deployments) * Remediate anonymous access (classic deployments) * Configure anonymous access * Secure blob data * Protect blob data * Manage redundancy and failover * Manage blob tiering and lifecycle * Manage object replication * Host a static website * Use a custom domain * Route events to a custom endpoint * Transfer data * Develop with Blob Storage * Monitor * Reference * Resources * Data Lake Storage Gen2 Download PDF 1. Learn 2. Azure 3. Storage 4. Blobs 1. Learn 2. Azure 3. Storage 4. Blobs Read in English Add Table of contents Read in English Add Edit Print Twitter LinkedIn Facebook Email Table of contents REMEDIATE ANONYMOUS PUBLIC READ ACCESS TO BLOB DATA (AZURE RESOURCE MANAGER DEPLOYMENTS) * Article * 05/23/2023 * 10 contributors Feedback IN THIS ARTICLE 1. Remediation for Azure Resource Manager versus classic storage accounts 2. About anonymous public read access 3. Detect anonymous requests from client applications 4. Remediate anonymous public access for the storage account 5. Sample script for bulk remediation 6. Verify that anonymous access has been remediated 7. Use Azure Policy to audit for compliance 8. Use Azure Policy to enforce authorized access 9. Next steps Show 5 more Azure Blob Storage supports optional anonymous public read access to containers and blobs. However, anonymous access may present a security risk. We recommend that you disable anonymous access for optimal security. Disallowing public access helps to prevent data breaches caused by undesired anonymous access. By default, public access to your blob data is always prohibited. However, the default configuration for an Azure Resource Manager storage account permits a user with appropriate permissions to configure public access to containers and blobs in a storage account. You can disallow all public access to an Azure Resource Manager storage account, regardless of the public access setting for an individual container, by setting the AllowBlobPublicAccess property on the storage account to False. After you disallow public blob access for the storage account, Azure Storage rejects all anonymous requests to that account. Disallowing public access to a storage account prevents users from subsequently configuring public access for containers in that account. Any containers that have already been configured for public access will no longer accept anonymous requests. Warning When a container is configured for public access, any client can read data in that container. Public access presents a potential security risk, so if your scenario does not require it, we recommend that you disallow it for the storage account. REMEDIATION FOR AZURE RESOURCE MANAGER VERSUS CLASSIC STORAGE ACCOUNTS This article describes how to use a DRAG (Detection-Remediation-Audit-Governance) framework to continuously manage public access for storage accounts that are using the Azure Resource Manager deployment model. All general-purpose v2 storage accounts, premium block blob storage accounts, premium file share accounts, and Blob Storage accounts use the Azure Resource Manager deployment model. Some older general-purpose v1 accounts and premium page blob accounts may use the classic deployment model. If your storage account is using the classic deployment model, we recommend that you migrate to the Azure Resource Manager deployment model as soon as possible. Azure Storage accounts that use the classic deployment model will be retired on August 31, 2024. For more information, see Azure classic storage accounts will be retired on 31 August 2024. If you can't migrate your classic storage accounts at this time, then you should remediate public access to those accounts now. To learn how to remediate public access for classic storage accounts, see Remediate anonymous public read access to blob data (classic deployments). For more information about Azure deployment models, see Resource Manager and classic deployment. ABOUT ANONYMOUS PUBLIC READ ACCESS Anonymous public access to your data is always prohibited by default. There are two separate settings that affect public access: 1. Allow public access for the storage account. By default, a storage account allows a user with the appropriate permissions to enable public access to a container. Blob data isn't available for public access unless the user takes the additional step to explicitly configure the container's public access setting. 2. Configure the container's public access setting. By default, a container's public access setting is disabled, meaning that authorization is required for every request to the container or its data. A user with the appropriate permissions can modify a container's public access setting to enable anonymous access only if anonymous access is allowed for the storage account. The following table summarizes how both settings together affect public access for a container. Public access level for the container is set to Private (default setting) Public access level for the container is set to Container Public access level for the container is set to Blob Public access is disallowed for the storage account Recommended. No public access to any container in the storage account. No public access to any container in the storage account. The storage account setting overrides the container setting. No public access to any container in the storage account. The storage account setting overrides the container setting. Public access is allowed for the storage account (default setting) No public access to this container (default configuration). Not recommended. Public access is permitted to this container and its blobs. Not recommended. Public access is permitted to blobs in this container, but not to the container itself. When anonymous public access is permitted for a storage account and configured for a specific container, then a request to read a blob in that container that is passed without an Authorization header is accepted by the service, and the blob's data is returned in the response. DETECT ANONYMOUS REQUESTS FROM CLIENT APPLICATIONS When you disallow public read access for a storage account, you risk rejecting requests to containers and blobs that are currently configured for public access. Disallowing public access for a storage account overrides the public access settings for individual containers in that storage account. When public access is disallowed for the storage account, any future anonymous requests to that account will fail. To understand how disallowing public access may affect client applications, we recommend that you enable logging and metrics for that account and analyze patterns of anonymous requests over an interval of time. Use metrics to determine the number of anonymous requests to the storage account, and use logs to determine which containers are being accessed anonymously. MONITOR ANONYMOUS REQUESTS WITH METRICS EXPLORER To track anonymous requests to a storage account, use Azure Metrics Explorer in the Azure portal. For more information about Metrics Explorer, see Getting started with Azure Metrics Explorer. Follow these steps to create a metric that tracks anonymous requests: 1. Navigate to your storage account in the Azure portal. Under the Monitoring section, select Metrics. 2. Select Add metric. In the Metric dialog, specify the following values: 1. Leave the Scope field set to the name of the storage account. 2. Set the Metric Namespace to Blob. This metric reports requests against Blob storage only. 3. Set the Metric field to Transactions. 4. Set the Aggregation field to Sum. The new metric displays the sum of the number of transactions against Blob storage over a given interval of time. The resulting metric appears as shown in the following image: 3. Next, select the Add filter button to create a filter on the metric for anonymous requests. 4. In the Filter dialog, specify the following values: 1. Set the Property value to Authentication. 2. Set the Operator field to the equal sign (=). 3. Set the Values field to Anonymous by selecting it from the dropdown or typing it in. 5. 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: 1. 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. 2. Navigate to your storage account in the Azure portal. 3. In the Monitoring section, select Diagnostic settings. 4. Select Blob to log requests made against Blob storage. 5. Select Add diagnostic setting. 6. Provide a name for the diagnostic setting. 7. 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. 8. 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: Kusto Copy 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. 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 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. * Azure portal * PowerShell * Azure CLI * Template To disallow public access for a storage account in the Azure portal, follow these steps: 1. Navigate to your storage account in the Azure portal. 2. Locate the Configuration setting under Settings. 3. 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: PowerShell Copy $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: Azure CLI Copy Open Cloudshell 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. 1. In the Azure portal, choose Create a resource. 2. In Search the Marketplace, type template deployment, and then press ENTER. 3. Choose Template deployment (deploy using custom templates), choose Create, and then choose Build your own template in the editor. 4. 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. JSON Copy { "$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": {} } ] } 5. Save the template. 6. Specify resource group parameter, then choose the Review + create button to deploy the template and create a storage account with the allowBlobPublicAccess property configured. Note 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. Azure PowerShell Copy <# .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') { try { 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." } else { 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: PowerShell Copy $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: PowerShell Copy $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: PowerShell Copy $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: Kusto Copy 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: 1. In the Azure portal, navigate to the Azure Policy service. 2. Under the Authoring section, select Definitions. 3. Select Add policy definition to create a new policy definition. 4. For the Definition location field, select the More button to specify where the audit policy resource is located. 5. Specify a name for the policy. You can optionally specify a description and category. 6. Under Policy rule, add the following policy definition to the policyRule section. JSON Copy { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } } 7. 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: 1. In the Azure portal, navigate to the Azure Policy service. 2. Under the Authoring section, select Assignments. 3. Select Assign policy to create a new policy assignment. 4. For the Scope field, select the scope of the policy assignment. 5. For the Policy definition field, select the More button, then select the policy you defined in the previous section from the list. 6. Provide a name for the policy assignment. The description is optional. 7. Leave Policy enforcement set to Enabled. This setting has no effect on the audit policy. 8. 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: 1. In the Azure portal, navigate to the Azure Policy service. 2. Select Compliance. 3. 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. 4. 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: JSON Copy { "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. NEXT STEPS * Overview: Remediating anonymous public read access for blob data * Remediate anonymous public read access to blob data (classic deployments) * Security recommendations for Blob storage FEEDBACK Submit and view feedback for This product This page View all page feedback -------------------------------------------------------------------------------- ADDITIONAL RESOURCES -------------------------------------------------------------------------------- Documentation * Configure anonymous public read access for containers and blobs - Azure Storage Learn how to allow or disallow anonymous access to blob data for the storage account. Set the container public access setting to make containers and blobs available for anonymous access. * Overview of remediating anonymous public read access for blob data - Azure Storage Learn how to remediate anonymous public read access to blob data for both Azure Resource Manager and classic storage accounts. * Prevent authorization with Shared Key - Azure Storage To require clients to use Azure AD to authorize requests, you can disallow requests to the storage account that are authorized with Shared Key. * Require secure transfer to ensure secure connections - Azure Storage Learn how to require secure transfer for requests to Azure Storage. When you require secure transfer for a storage account, any requests originating from an insecure connection are rejected. * Remediate anonymous public read access to blob data (classic deployments) - Azure Storage Learn how to prevent anonymous requests against a classic storage account by disabling anonymous public access to containers. * Enable and manage blob versioning - Azure Storage Learn how to enable blob versioning in the Azure portal or by using an Azure Resource Manager template. * Authorize access to blob data in the Azure portal - Azure Storage When you access blob data using the Azure portal, the portal makes requests to Azure Storage under the covers. These requests to Azure Storage can be authenticated and authorized using either your Azure AD account or the storage account access key. * Blob versioning - Azure Storage Blob storage versioning automatically maintains previous versions of an object and identifies them with timestamps. You can restore a previous version of a blob to recover your data if it's erroneously modified or deleted. Show 5 more -------------------------------------------------------------------------------- Training Learning path AZ-104: Implement and manage storage in Azure - Training AZ-104: Implement and manage storage in Azure English (United States) Theme * Light * Dark * High contrast * Manage cookies * Previous Versions * Blog * Contribute * Privacy * Terms of Use * Trademarks * © Microsoft 2023 ADDITIONAL RESOURCES -------------------------------------------------------------------------------- Training Learning path AZ-104: Implement and manage storage in Azure - Training AZ-104: Implement and manage storage in Azure -------------------------------------------------------------------------------- Documentation * Configure anonymous public read access for containers and blobs - Azure Storage Learn how to allow or disallow anonymous access to blob data for the storage account. Set the container public access setting to make containers and blobs available for anonymous access. * Overview of remediating anonymous public read access for blob data - Azure Storage Learn how to remediate anonymous public read access to blob data for both Azure Resource Manager and classic storage accounts. * Prevent authorization with Shared Key - Azure Storage To require clients to use Azure AD to authorize requests, you can disallow requests to the storage account that are authorized with Shared Key. * Require secure transfer to ensure secure connections - Azure Storage Learn how to require secure transfer for requests to Azure Storage. When you require secure transfer for a storage account, any requests originating from an insecure connection are rejected. * Remediate anonymous public read access to blob data (classic deployments) - Azure Storage Learn how to prevent anonymous requests against a classic storage account by disabling anonymous public access to containers. * Enable and manage blob versioning - Azure Storage Learn how to enable blob versioning in the Azure portal or by using an Azure Resource Manager template. * Authorize access to blob data in the Azure portal - Azure Storage When you access blob data using the Azure portal, the portal makes requests to Azure Storage under the covers. These requests to Azure Storage can be authenticated and authorized using either your Azure AD account or the storage account access key. * Blob versioning - Azure Storage Blob storage versioning automatically maintains previous versions of an object and identifies them with timestamps. You can restore a previous version of a blob to recover your data if it's erroneously modified or deleted. Show 5 more IN THIS ARTICLE English (United States) Theme * Light * Dark * High contrast * Manage cookies * Previous Versions * Blog * Contribute * Privacy * Terms of Use * Trademarks * © Microsoft 2023