Исправление анонимного доступа на чтение к данным BLOB-объектов (развертывания Azure Resource Manager)
Хранилище BLOB-объектов Azure поддерживает необязательный анонимный доступ на чтение к контейнерам и BLOB-объектам. Однако анонимный доступ может представлять угрозу безопасности. Рекомендуется отключить анонимный доступ для оптимальной безопасности. Запрет анонимного доступа помогает предотвратить нарушения данных, вызванные нежелательным анонимным доступом.
По умолчанию анонимный доступ к данным BLOB-объектов всегда запрещен. Конфигурация по умолчанию для учетной записи хранения Azure Resource Manager запрещает пользователям настраивать анонимный доступ к контейнерам и BLOB-объектам в учетной записи хранения. Эта конфигурация по умолчанию запрещает всем анонимным доступом к учетной записи хранения Azure Resource Manager независимо от параметра доступа для отдельного контейнера.
Если анонимный доступ к учетной записи хранения запрещен, служба хранилища Azure отклоняет все анонимные запросы на чтение данных BLOB-объектов. Пользователи не могут позже настроить анонимный доступ для контейнеров в этой учетной записи. Все контейнеры, которые уже настроены для анонимного доступа, больше не будут принимать анонимные запросы.
Предупреждение
Когда контейнер настроен для анонимного доступа, любой клиент может считывать данные в этом контейнере. Анонимный доступ представляет собой потенциальный риск безопасности, поэтому если сценарий не требует его, рекомендуется запретить его для учетной записи хранения.
Исправление для Azure Resource Manager и классических учетных записей хранения
В этой статье описывается, как использовать платформу DRAG (Detection-Remediation-Audit-Management) для непрерывного управления анонимным доступом для учетных записей хранения, использующих модель развертывания Azure Resource Manager. Все учетные записи хранения общего назначения версии 2, учетные записи хранения блочных BLOB-объектов класса Premium, учетные записи общего файлового ресурса класса Premium и учетные записи хранения BLOB-объектов используют модель развертывания Azure Resource Manager. Некоторые старые учетные записи общего назначения версии 1 и учетные записи страничных BLOB-объектов категории "Премиум" могут использовать классическую модель развертывания.
Если ваша учетная запись хранения использует классическую модель развертывания, рекомендуется перенести ее в модель развертывания Azure Resource Manager как можно скорее. служба хранилища Azure учетные записи, использующие классическую модель развертывания, будут прекращены 31 августа 2024 г. Дополнительные сведения см. в записи о прекращении использования классических учетных записей хранения Azure 31 августа 2024 г.
Если вы не можете перенести классические учетные записи хранения в настоящее время, необходимо исправить анонимный доступ к этим учетным записям. Сведения об исправлении анонимного доступа для классических учетных записей хранения см. в статье "Исправление анонимного доступа на чтение" к данным BLOB-объектов (классические развертывания). Дополнительные сведения о моделях развертывания Azure, см. в статье Resource Manager и классическое развертывание.
О анонимном доступе для чтения
Анонимный доступ к данным всегда запрещен по умолчанию. Существует два отдельных параметра, влияющих на анонимный доступ:
Параметр анонимного доступа для учетной записи хранения. Учетная запись хранения Azure Resource Manager предлагает параметр для разрешения или запрета анонимного доступа для учетной записи. Корпорация Майкрософт рекомендует запретить анонимный доступ для учетных записей хранения для оптимальной безопасности.
Если анонимный доступ разрешен на уровне учетной записи, данные BLOB-объектов недоступны для анонимного доступа на чтение, если пользователь не выполняет дополнительный шаг, чтобы явно настроить параметр анонимного доступа контейнера.
Настройте параметр анонимного доступа контейнера. По умолчанию параметр анонимного доступа контейнера отключен, то есть для каждого запроса к контейнеру или его данным требуется авторизация. Пользователь с соответствующими разрешениями может изменить параметр анонимного доступа контейнера, чтобы включить анонимный доступ только в том случае, если анонимный доступ разрешен для учетной записи хранения.
В следующей таблице показано, как два параметра влияют на анонимный доступ для контейнера.
| Для контейнера задан уровень анонимного доступа (параметр по умолчанию) | Уровень анонимного доступа для контейнера имеет значение Container | Уровень анонимного доступа для контейнера имеет значение BLOB-объект | |
|---|---|---|---|
| Анонимный доступ запрещен для учетной записи хранения | Анонимный доступ к любому контейнеру в учетной записи хранения не существует. | Анонимный доступ к любому контейнеру в учетной записи хранения не существует. Параметр учетной записи хранения переопределяет параметр контейнера. | Анонимный доступ к любому контейнеру в учетной записи хранения не существует. Параметр учетной записи хранения переопределяет параметр контейнера. |
| Анонимный доступ разрешен для учетной записи хранения | Анонимный доступ к этому контейнеру (конфигурация по умолчанию) отсутствует. | Анонимный доступ разрешен для этого контейнера и его больших двоичных объектов. | Анонимный доступ разрешен для больших двоичных объектов в этом контейнере, но не к самому контейнеру. |
Если анонимный доступ разрешен для учетной записи хранения и настроен для определенного контейнера, запрос на чтение большого двоичного объекта в этом контейнере, передаваемом Authorization без заголовка, принимается службой, а данные большого двоичного объекта возвращаются в ответе. Однако если запрос передается с заголовком Authorization , анонимный доступ к учетной записи хранения игнорируется, и запрос авторизован на основе предоставленных учетных данных.
Обнаружение анонимных запросов из клиентских приложений
Если вы запрещаете анонимный доступ на чтение для учетной записи хранения, вы рискуете отклонять запросы к контейнерам и BLOB-объектам, которые в настоящее время настроены для анонимного доступа. Запрет анонимного доступа для учетной записи хранения переопределяет параметры доступа для отдельных контейнеров в этой учетной записи хранения. Если анонимный доступ запрещен для учетной записи хранения, все будущие анонимные запросы к этой учетной записи завершаются ошибкой.
Чтобы понять, как запрет анонимного доступа может повлиять на клиентские приложения, рекомендуется включить ведение журнала и метрики для этой учетной записи и проанализировать шаблоны анонимных запросов через интервал времени. Метрики позволяют определять количество анонимных запросов к учетной записи хранения, а журналы показывают, к каким контейнерам осуществляется анонимный доступ.
Мониторинг анонимных запросов с помощью обозревателя метрик
Для отслеживания анонимных запросов к учетной записи хранения используйте обозреватель метрик Azure на портале Azure. Дополнительные сведения об обозревателе метрик см. в статье "Анализ метрик" с помощью обозревателя метрик Azure Monitor.
Для создания метрики, которая отслеживает анонимные запросы, выполните следующие действия.
Войдите в свою учетную запись хранения на портале Azure. В разделе Мониторинг выберите Метрики.
Выберите Добавить метрику. В диалоговом окне Metric (Метрики) укажите следующие значения.
- В поле Scope (Область) оставьте имя учетной записи хранения.
- Задайте для пространства имен метрик значение BLOB-объект. Эта метрика сообщает только запросы к хранилищу BLOB-объектов.
- В поле Metric (Метрика) задайте значение Transactions (Транзакции).
- В поле Aggregation (Агрегат) задайте значение Sum (Сумма).
Новая метрика отображает сумму количества транзакций для хранилища BLOB-объектов в течение заданного интервала времени. В результате эта метрика должна выглядеть, как показано на рисунке:
Затем нажмите кнопку Добавить фильтр, чтобы создать фильтр по метрике для анонимных запросов.
В диалоговом окне фильтра укажите следующие значения.
- В поле Property (свойство) задайте значение Authentication (Авторизация).
- В поле Operator (Оператор) укажите знак равенства (=).
- В поле Values (Значения) занесите значение Anonymous (Анонимный), выбрав его в раскрывающемся списке или введя с клавиатуры.
В правом верхнем углу выберите интервал времени, для которого вы хотите посмотреть метрику. Можно также указать, степень детализации агрегирования запросов, задав интервалы от 1 минуты до 1 месяца.
После настройки метрики анонимные запросы появятся на диаграмме. На следующем рисунке показаны анонимные запросы, агрегированные за последние 30 минут.
Вы также можете настроить правило генерации оповещений, чтобы получать уведомления, как только к вашей учетной записи хранения будет сделано определенное количество анонимных запросов. Дополнительные сведения см. в статье Создание и просмотр оповещений метрик, а также управление ими с помощью Azure Monitor.
Анализ журналов для выявления контейнеров, принимающих анонимные запросы
Журналы Службы хранилища Azure записывают сведения о запросах к учетной записи хранения, в том числе о том, как был авторизован запрос. Проанализировав журналы, можно определить, какие контейнеры получают анонимные запросы.
Для регистрации запросов к учетной записи служба хранилища Azure для оценки анонимных запросов можно использовать служба хранилища Azure ведение журнала в Azure Monitor. Дополнительные сведения см. в разделе Мониторинг службы хранилища Microsoft Azure.
Функция "Журнал службы хранилища Microsoft Azure" в Azure Monitor поддерживает использование запросов журналов для анализа. Для запроса журналов можно использовать рабочую область Azure Log Analytics. Дополнительные сведения о запросах журналов см. в разделе Руководство: начало работы с запросами Log Analytics.
Создание параметра диагностики на портале Azure
Чтобы регистрировать в журнале данные службы хранилища Azure с помощью Azure Monitor и анализировать их с помощью Azure Log Analytics, необходимо сначала создать параметр диагностики, который указывает, данные каких типов запросов для каких служб хранилища следует регистрировать в журнале. После настройки ведения журнала для учетной записи хранения журналы доступны в рабочей области Log Analytics. Сведения о создании рабочей области см. в статье "Создание рабочей области Log Analytics" в портал Azure.
Сведения о создании параметра диагностики в портал Azure см. в статье "Создание параметров диагностики" в Azure Monitor.
Ссылка на поля, доступные в журналах служба хранилища Azure в Azure Monitor, см. в журналах ресурсов.
Журналы запросов для анонимных запросов
Журналы службы хранилища Azure в Azure Monitor включают тип авторизации, который использовался для выполнения запроса к учетной записи хранения. В запросе журнала выполните фильтрацию по свойству AuthenticationType для просмотра анонимных запросов.
Чтобы получить журналы за последние семь дней для анонимных запросов к хранилищу BLOB-объектов, откройте рабочую область Log Analytics. Затем вставьте следующий запрос в поле создания запроса к журналу и запустите его.
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
Вы также можете настроить правило генерации оповещений на основе этого запроса, чтобы получать уведомления об анонимных запросах. Дополнительные сведения см. в статье Создание и просмотр оповещений журналов, а также управление ими с помощью Azure Monitor.
Ответы на анонимные запросы
Если хранилище BLOB-объектов получает анонимный запрос, этот запрос будет выполнен успешно, если выполнены все следующие условия:
- Анонимный доступ разрешен для учетной записи хранения.
- Целевой контейнер настроен для предоставления анонимного доступа.
- Запрос предназначен для доступа на чтение.
Если одно из этих условий не соответствует действительности, запрос завершается ошибкой. Код ответа от сбоя зависит от того, был ли выполнен анонимный запрос с версией службы, поддерживающей вызов носителя. Задача носителя поддерживается с версиями служб 2019-12-12 и более поздними версиями:
- Если анонимный запрос был выполнен с версией службы, поддерживающей вызов носителя, служба возвращает код ошибки 401 (несанкционированный).
- Если анонимный запрос был выполнен с версией службы, которая не поддерживает вызов носителя и анонимный доступ запрещен для учетной записи хранения, служба возвращает код ошибки 409 (конфликт).
- Если анонимный запрос был выполнен с версией службы, которая не поддерживает вызов носителя и анонимный доступ разрешен для учетной записи хранения, служба возвращает код ошибки 404 (не найден).
Дополнительные сведения о вызове носителя см. в разделе "Вызов носителя".
Исправление анонимного доступа для учетной записи хранения
После оценки анонимных запросов к контейнерам и BLOB-объектам в учетной записи хранения вы можете предпринять действия по исправлению анонимного доступа для всей учетной записи, установив для учетной записи свойство AllowBlobPublicAccess значение False.
Параметр анонимного доступа для учетной записи хранения переопределяет отдельные параметры контейнеров в этой учетной записи. Если вы запрещаете анонимный доступ для учетной записи хранения, все контейнеры, настроенные для разрешения анонимного доступа, больше не доступны анонимно. Если вы запрещаете анонимный доступ для учетной записи, вам также не нужно отключить анонимный доступ для отдельных контейнеров.
Если в вашем сценарии требуется, чтобы определенные контейнеры были доступны для анонимного доступа, необходимо переместить эти контейнеры и их большие двоичные объекты в отдельные учетные записи хранения, зарезервированные для анонимного доступа. Затем вы можете запретить анонимный доступ для любых других учетных записей хранения.
Для исправления анонимного доступа требуется версия 2019-04-01 или более поздняя версия поставщика ресурсов служба хранилища Azure. Дополнительные сведения см. в разделе REST API поставщика ресурсов службы хранилища Microsoft Azure.
Разрешения для запрета анонимного доступа
Чтобы задать свойство AllowBlobPublicAccess для учетной записи хранения, пользователь должен иметь разрешения на создание учетных записей хранения и управление ими. Роли управления доступом на основе ролей Azure (Azure RBAC), предоставляющие эти разрешения, включают действие Microsoft.Storage/storageAccounts/write . Встроенные роли с этим действием:
Назначения ролей должны быть ограничены уровнем учетной записи хранения или выше, чтобы разрешить пользователю запретить анонимный доступ для учетной записи хранения. Дополнительные сведения об области роли см. в разделе Общие сведения об области для Azure RBAC.
Будьте осторожны, чтобы ограничить назначение этих ролей только теми пользователями администратора, которым требуется возможность создать учетную запись хранения или обновить его свойства. Используйте принцип наименьших привилегий, чтобы предоставлять пользователям минимальный набор разрешений, необходимый для выполнения их задач. Дополнительные сведения об управлении доступом с помощью Azure RBAC см. в разделе Рекомендации по использованию Azure RBAC.
Эти роли не предоставляют доступ к данным в учетной записи хранения с помощью идентификатора Microsoft Entra. Однако они включают в себя разрешение Microsoft. Storage/storageAccounts/listkeys/Action, которое предоставляет доступ к ключам доступа учетной записи. Пользователь с этим разрешением может использовать ключи доступа учетной записи для доступа ко всем данным в учетной записи хранения.
Microsoft.Storage /storageAccounts/listkeys/action сам предоставляет доступ к данным через ключи учетной записи, но не предоставляет пользователю возможность изменять свойство AllowBlobPublicAccess для учетной записи хранения. Для пользователей, которым требуется доступ к данным в вашей учетной записи хранения, но не должно быть возможности изменять конфигурацию учетной записи хранения, рекомендуется назначать такие роли, как участник данных хранилища, читатель blob-объектов хранилища или читатель и доступ к данным.
Примечание.
Роли администратора классической подписки "администратор службы" и "соадминистратор" включают в себя эквивалент роли владельца Azure Resource Manager. Роль владельца включает все действия, поэтому пользователь с одной из этих административных ролей также может создавать учетные записи хранения и управлять конфигурацией учетной записи. Дополнительные сведения см. в статье о ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки.
Задайте для свойства AllowBlobPublicAccess учетной записи хранения значение False
Чтобы запретить анонимный доступ для учетной записи хранения, задайте для свойства AllowBlobPublicAccess значение False.
Внимание
Запрет анонимного доступа для учетной записи хранения переопределяет параметры доступа для всех контейнеров в этой учетной записи хранения. Если анонимный доступ запрещен для учетной записи хранения, все будущие анонимные запросы к этой учетной записи завершаются ошибкой. Прежде чем изменить этот параметр, обязательно понять влияние на клиентские приложения, которые могут получать доступ к данным в учетной записи хранения анонимно, выполнив действия, описанные в статье "Обнаружение анонимных запросов от клиентских приложений".
Чтобы запретить анонимный доступ для учетной записи хранения в портал Azure, выполните следующие действия.
Войдите в свою учетную запись хранения на портале Azure.
Выберите параметр Configuration (Конфигурация) в разделе Settings (Параметры).
Задайте для параметра "Разрешить анонимный доступ к BLOB-объектам" для отключенного.
Примечание.
Запрет анонимного доступа для учетной записи хранения не влияет на статические веб-сайты, размещенные в этой учетной записи хранения. Контейнер $web всегда является общедоступным.
После обновления параметра анонимного доступа для учетной записи хранения может потребоваться до 30 секунд до полного распространения изменения.
Пример скрипта для массового исправления
Следующий пример скрипта PowerShell выполняется для всех учетных записей хранения Azure Resource Manager в подписке и задает параметр AllowBlobPublicAccess для этих учетных записей значение 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 {
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 ($null -eq $account.AllowBlobPublicAccess -or $account.AllowBlobPublicAccess -eq $true) {
Write-host "Account:" $account.StorageAccountName " isn't 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"
}
Проверка параметра анонимного доступа для нескольких учетных записей
Чтобы проверить параметр анонимного доступа в наборе учетных записей хранения с оптимальной производительностью, можно использовать обозреватель Azure Resource Graph в портал Azure. Дополнительные сведения об использовании песочницы Graph для ресурсов см. в статье Краткое руководство: выполнение первого запроса по Azure Resource Graph с помощью песочницы Graph.
При выполнении следующего запроса в обозревателе resource Graph возвращается список учетных записей хранения и отображается параметр анонимного доступа для каждой учетной записи:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
На следующем рисунке показаны результаты запроса в подписке. Для учетных записей хранения, в которых свойство AllowBlobPublicAccess явно задано, оно отображается в результатах как true или false. Если свойство AllowBlobPublicAccess не задано для учетной записи хранения, оно отображается как пустое (или null) в результатах запроса.
Использование Политики Azure для аудита соответствия
Если у вас есть большое количество учетных записей хранения, может потребоваться выполнить аудит, чтобы убедиться, что эти учетные записи настроены для предотвращения анонимного доступа. Чтобы выполнить аудит набора учетных записей хранения на предмет их соответствия требованиям, используйте Политику Azure. Политика Azure — это служба, которую можно использовать для создания политик для применения правил к ресурсам Azure, их назначения и управления ими. Использование службы "Политика Azure" обеспечивает соответствие ресурсов корпоративным стандартам и соглашениям об уровне обслуживания. Дополнительные сведения см. в статье Что такое служба "Политика Azure"?.
Создание политики с использованием эффекта "Аудит"
Политика Azure поддерживает эффекты, которые определяют действия при оценке правила политики для ресурса. Эффект аудита создает предупреждение, если ресурс не соответствует требованиям, но не останавливает запрос. Дополнительные сведения об эффектах см. в статье Общие сведения об эффектах Политики Azure.
Чтобы создать политику с эффектом аудита для параметра анонимного доступа для учетной записи хранения с портал Azure, выполните следующие действия.
На портале Microsoft Azure перейдите к службе "Политика Azure".
В разделе Разработка выберите Определения.
Выберите Добавить определение политики, чтобы создать новое определение политики.
В поле Расположение определения нажмите кнопку Дополнительно, чтобы указать, где находится ресурс политики аудита.
Укажите имя политики Azure. При необходимости можно добавить описание и категорию.
В разделе Правило политики добавьте следующее определение Политики Azure в раздел policyrule.
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }Сохраните политику.
Назначение политики
Затем назначьте политику для ресурса. Область политики соответствует этому ресурсу и всем ресурсам на нижележащих уровнях. Дополнительные сведения о назначении политики см. в разделе Структура назначения Политики Azure.
Чтобы назначить политику на портале Microsoft Azure, выполните следующие действия.
- На портале Microsoft Azure перейдите к службе "Политика Azure".
- В разделе Разработка выберите Назначения.
- Выберите Назначить политику, чтобы создать новое назначение политики.
- В поле Область выберите область назначения политики.
- В поле Определение Политики Azure нажмите кнопку Дополнительно, а затем выберите из списка политику, определенную в предыдущем разделе.
- Введите имя для назначения политики. Описание является необязательным.
- Оставьте для параметра Применение политик значение Включено. Этот параметр не влияет на политику аудита.
- Щелкните Просмотреть и создать, чтобы создать назначение.
Просмотр отчета о соответствии
После назначения политики можно просмотреть отчет о соответствии. Отчет о соответствии политике аудита содержит сведения о том, какие учетные записи хранения не соответствуют политике. Дополнительные сведения см. в статье Получение данных о соответствии политики.
После создания назначения политики может пройти несколько минут, прежде чем отчет о соответствии станет доступен.
Чтобы просмотреть отчет о соответствии на портале Microsoft Azure, выполните следующие действия.
На портале Microsoft Azure перейдите к службе "Политика Azure".
Выберите Соответствие.
Отфильтруйте результаты по имени назначения политики, созданной на предыдущем этапе. В отчете показано, сколько ресурсов не соответствует политике.
Дополнительные сведения см. в отчете, включая список учетных записей хранения, которые не соответствуют требованиям.
Использование политики Azure для принудительного авторизованного доступа
Политика Azure поддерживает управление облаком, гарантируя, что ресурсы Azure соответствуют требованиям и стандартам. Чтобы учетные записи хранения в организации разрешали только авторизованные запросы, можно создать политику, которая предотвращает создание новой учетной записи хранения с параметром анонимного доступа, который разрешает анонимные запросы. Эта политика также предотвратит все изменения конфигурации существующей учетной записи, если параметр анонимного доступа для этой учетной записи не соответствует политике.
Политика принудительного применения использует эффект "Запрет" для предотвращения запроса, который создаст или изменит учетную запись хранения, чтобы разрешить анонимный доступ. Дополнительные сведения об эффектах см. в статье Общие сведения об эффектах Политики Azure.
Чтобы создать политику с эффектом запрета для параметра анонимного доступа, который разрешает анонимные запросы, выполните те же действия, описанные в разделе "Использование Политика Azure для аудита соответствия требованиям", но укажите следующий код JSON в разделе policyRule определения политики:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
После создания политики с эффектом "Запретить" и назначения ее области пользователь не может создать учетную запись хранения, которая разрешает анонимный доступ. Пользователь не может вносить изменения в конфигурацию существующей учетной записи хранения, которая в настоящее время разрешает анонимный доступ. Попытка сделать это приведет к ошибке. Параметр анонимного доступа для учетной записи хранения должен иметь значение false , чтобы продолжить создание или настройку учетной записи.
На следующем рисунке показано сообщение об ошибке, возникающей при попытке создать учетную запись хранения, которая разрешает анонимный доступ, если политика с эффектом "Запретить" требует запрета анонимного доступа.
