Устранение анонимного доступа к чтению данных BLOB-хранилища (развертывание в Azure Resource Manager)

Хранилище BLOB-объектов Azure поддерживает необязательный анонимный доступ на чтение к контейнерам и BLOB-объектам. Однако анонимный доступ может представлять угрозу безопасности. Рекомендуется отключить анонимный доступ для оптимальной безопасности. Запрет анонимного доступа помогает предотвратить нарушения данных, вызванные нежелательным анонимным доступом.

По умолчанию анонимный доступ к данным BLOB-объектов всегда запрещен. Конфигурация по умолчанию для учетной записи хранения Azure Resource Manager запрещает пользователям настраивать анонимный доступ к контейнерам и BLOB-объектам в учетной записи хранения. Эта конфигурация по умолчанию запрещает всем анонимным пользователям доступ к учетной записи хранения в средстве управления ресурсами Azure, независимо от параметра доступа для отдельного контейнера.

Если анонимный доступ к учетной записи хранения запрещен, служба хранилища Azure отклоняет все анонимные запросы на чтение данных BLOB-объектов. Пользователи не могут позже настроить анонимный доступ для контейнеров в этой учетной записи. Все контейнеры, которые уже настроены для анонимного доступа, больше не будут принимать анонимные запросы.

Исправление для Azure Resource Manager и классических учетных записей хранения

В этой статье описывается, как использовать платформу DRAG (Detection-Remediation-Audit-Management) для непрерывного управления анонимным доступом для учетных записей хранения, использующих модель развертывания Azure Resource Manager. Все учетные записи хранения общего назначения версии 2, учетные записи хранения блочных BLOB-объектов класса Premium, учетные записи общего файлового ресурса класса Premium и учетные записи хранения BLOB-объектов используют модель развертывания Azure Resource Manager.

Если учетная запись хранения использует классическую модель развертывания, рекомендуется перенести в модель развертывания Azure Resource Manager. Учетные записи хранения Azure, использующие классическую модель развертывания, были прекращены 31 августа 2024 г. Для получения дополнительной информации см. обновление о завершении использования классических учетных записей хранилищ.

О анонимном доступе для чтения

Анонимный доступ к данным всегда запрещен по умолчанию. Существует два отдельных параметра, влияющих на анонимный доступ:

1. Параметр анонимного доступа для учетной записи хранения. Учетная запись хранения Azure Resource Manager предлагает параметр для разрешения или запрета анонимного доступа для учетной записи. Корпорация Майкрософт рекомендует запретить анонимный доступ для учетных записей хранения для оптимальной безопасности.

   Если анонимный доступ разрешен на уровне учетной записи, данные объектов BLOB недоступны для анонимного чтения, если пользователь не выполнит дополнительный шаг для явной настройки параметра анонимного доступа контейнера.

2. Настройте параметр анонимного доступа контейнера. По умолчанию параметр анонимного доступа контейнера отключен, то есть для каждого запроса к контейнеру или его данным требуется авторизация. Пользователь с соответствующими разрешениями может изменить параметр анонимного доступа контейнера, чтобы включить анонимный доступ только в том случае, если анонимный доступ разрешен для учетной записи хранения.

В следующей таблице показано, как два параметра влияют на анонимный доступ для контейнера.

Если анонимный доступ разрешен для учетной записи хранения и настроен для определенного контейнера, запрос на чтение большого двоичного объекта в этом контейнереAuthorization заголовка, принимается службой, а данные большого двоичного объекта возвращаются в ответе. Однако если запрос передается с заголовком Authorization , анонимный доступ к учетной записи хранения игнорируется, и запрос авторизован на основе предоставленных учетных данных.

Обнаружение анонимных запросов из клиентских приложений

Если вы запрещаете анонимный доступ на чтение для учетной записи хранения, вы рискуете отклонять запросы к контейнерам и BLOB-объектам, которые в настоящее время настроены для анонимного доступа. Запрет анонимного доступа для учетной записи хранения переопределяет параметры доступа для отдельных контейнеров в этой учетной записи хранения. Если анонимный доступ запрещен для учетной записи хранения, все будущие анонимные запросы к этой учетной записи завершаются ошибкой.

Чтобы понять, как запрет анонимного доступа может повлиять на клиентские приложения, рекомендуется включить ведение журнала и метрики для этой учетной записи и проанализировать шаблоны анонимных запросов через интервал времени. Метрики позволяют определять количество анонимных запросов к учетной записи хранения, а журналы показывают, к каким контейнерам осуществляется анонимный доступ.

Мониторинг анонимных запросов с помощью обозревателя метрик

Для отслеживания анонимных запросов к учетной записи хранения используйте обозреватель метрик Azure на портале Azure. Дополнительные сведения об обозревателе метрик см. в статье "Анализ метрик" с помощью обозревателя метрик Azure Monitor.

Для создания метрики, которая отслеживает анонимные запросы, выполните следующие действия.

1. Войдите в свою учетную запись хранения на портале Azure. В разделе Мониторинг выберите Метрики.

2. Выберите Добавить метрику. В диалоговом окне Metric (Метрики) укажите следующие значения.

   1. В поле Scope (Область) оставьте имя учетной записи хранения.
   2. Установите пространство имен метрик на Blob. Эта метрика относится только к запросам к хранилищу Blob-объектов.
   3. В поле Metric (Метрика) задайте значение Transactions (Транзакции).
   4. В поле Aggregation (Агрегат) задайте значение Sum (Сумма).

   Новая метрика отображает общее количество транзакций для хранилища блоков данных в течение заданного интервала времени. В результате эта метрика должна выглядеть, как показано на рисунке:

   

3. Затем нажмите кнопку Добавить фильтр, чтобы создать фильтр по метрике для анонимных запросов.

4. В диалоговом окне фильтра укажите следующие значения.

   1. В поле Property (свойство) задайте значение Authentication (Авторизация).
   2. В поле Operator (Оператор) укажите знак равенства (=).
   3. В поле Values (Значения) занесите значение Anonymous (Анонимный), выбрав его в раскрывающемся списке или введя с клавиатуры.

5. В правом верхнем углу выберите интервал времени, для которого вы хотите посмотреть метрику. Можно также указать, степень детализации агрегирования запросов, задав интервалы от 1 минуты до 1 месяца.

После настройки метрики анонимные запросы появятся на диаграмме. На следующем рисунке показаны анонимные запросы, агрегированные за последние 30 минут.

Вы также можете настроить правило генерации оповещений, чтобы получать уведомления, как только к вашей учетной записи хранения будет сделано определенное количество анонимных запросов. Дополнительные сведения см. в статье Создание и просмотр оповещений метрик, а также управление ими с помощью Azure Monitor.

Анализ журналов для выявления контейнеров, принимающих анонимные запросы

Журналы Службы хранилища Azure записывают сведения о запросах к учетной записи хранения, в том числе о том, как был авторизован запрос. Проанализировав журналы, можно определить, какие контейнеры получают анонимные запросы.

Для регистрации запросов к учетной записи хранилища Azure, чтобы оценить анонимные запросы, можно использовать ведение журнала запросов в Azure Monitor. Дополнительные сведения см. в разделе Мониторинг службы хранилища Microsoft Azure.

Журналирование хранилища 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 Storage. Дополнительные сведения см. в разделе REST API поставщика ресурсов службы хранилища Microsoft Azure.

Разрешения для запрета анонимного доступа

Чтобы задать свойство AllowBlobPublicAccess для учетной записи хранения, пользователь должен иметь разрешения на создание учетных записей хранения и управление ими. Роли управления доступом на основе ролей Azure (Azure RBAC), предоставляющие эти разрешения, включают действие Microsoft.Storage/storageAccounts/write . Встроенные роли с этим действием:

• Владелец Azure Resource Manager (Owner).
• участник Azure Resource Manager;
• Соавтор учетной записи хранения

Назначения ролей должны быть ограничены уровнем учетной записи хранения или выше, чтобы разрешить пользователю запретить анонимный доступ для учетной записи хранения. Дополнительные сведения об области роли см. в разделе Общие сведения об области для Azure RBAC.

Будьте осторожны, чтобы ограничить назначение этих ролей только теми пользователями администратора, которым требуется возможность создать учетную запись хранения или обновить его свойства. Используйте принцип наименьших привилегий, чтобы предоставлять пользователям минимальный набор разрешений, необходимый для выполнения их задач. Дополнительные сведения об управлении доступом с помощью Azure RBAC см. в разделе Рекомендации по использованию Azure RBAC.

Эти роли не предоставляют доступ к данным в учетной записи хранения с помощью идентификатора Microsoft Entra. Однако они включают Microsoft.Storage/storageAccounts/listkeys/action, которое предоставляет доступ к ключам доступа учетной записи. Пользователь с этим разрешением может использовать ключи доступа учетной записи для доступа ко всем данным в учетной записи хранения.

Microsoft.Storage /storageAccounts/listkeys/action сам предоставляет доступ к данным через ключи учетной записи, но не предоставляет пользователю возможность изменять свойство AllowBlobPublicAccess для учетной записи хранения. Для пользователей, которым требуется доступ к данным в вашей учетной записи хранения, но нельзя позволять изменять конфигурацию учетной записи, рекомендуется назначать роли, такие как Участник данных Blob-хранилища, Читатель данных Blob-хранилища или Читатель с доступом к данным.

Установите для учетной записи хранения значение свойства AllowBlobPublicAccess как False.

Чтобы запретить анонимный доступ для учетной записи хранения, задайте для свойства AllowBlobPublicAccess значение False.

$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

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

Пример скрипта для массового исправления

Следующий экземпляр скрипта 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 в портале Azure. Чтобы узнать больше об использовании Azure Resource Graph Explorer, см. Быстрый старт: выполнение первого запроса в Azure Resource Graph с использованием Azure Resource Graph Explorer.

При выполнении следующего запроса в обозревателе 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, выполните следующие действия.

1. На портале Microsoft Azure перейдите к службе "Политика Azure".

2. В разделе Разработка выберите Определения.

3. Выберите Добавить определение политики, чтобы создать новое определение политики.

4. В поле Расположение определения нажмите кнопку Дополнительно, чтобы указать, где находится ресурс политики аудита.

5. Укажите имя политики Azure. При необходимости можно добавить описание и категорию.

6. В разделе Правило политики добавьте следующее определение политики в раздел policyRule.

   {
     "if": {
       "allOf": [
         {
           "field": "type",
           "equals": "Microsoft.Storage/storageAccounts"
         },
         {
           "not": {
             "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
             "equals": "false"
           }
         }
       ]
     },
     "then": {
       "effect": "audit"
     }
   }
   

7. Сохраните политику.

Назначьте политику

Затем назначьте политику для ресурса. Область политики соответствует этому ресурсу и всем ресурсам на нижележащих уровнях. Дополнительные сведения о назначении политики см. в разделе Структура назначения Политики Azure.

Чтобы назначить политику на портале Microsoft Azure, выполните следующие действия.

1. На портале Microsoft Azure перейдите к службе "Политика Azure".
2. В разделе Разработка выберите Назначения.
3. Выберите Назначить политику, чтобы создать новое назначение политики.
4. В поле Область выберите область назначения политики.
5. В поле Определение Политики Azure нажмите кнопку Дополнительно, а затем выберите из списка политику, определенную в предыдущем разделе.
6. Укажите имя для назначения политики. Описание является необязательным.
7. Оставьте для параметра Применение политик значение Включено. Этот параметр не влияет на политику аудита.
8. Щелкните Просмотреть и создать, чтобы создать назначение.

Просмотр отчета о соответствии

После назначения политики можно просмотреть отчет о соответствии. Отчет о соответствии политике аудита содержит сведения о том, какие учетные записи хранения не соответствуют политике. Дополнительные сведения см. в статье Получение данных о соответствии политики.

После создания назначения политики может пройти несколько минут, прежде чем отчет о соответствии станет доступен.

Чтобы просмотреть отчет о соответствии на портале Microsoft Azure, выполните следующие действия.

1. На портале Microsoft Azure перейдите к службе "Политика Azure".

2. Выберите Соответствие.

3. Отфильтруйте результаты по имени назначения политики, созданной на предыдущем этапе. В отчете показано, сколько ресурсов не соответствует политике.

4. Вы можете углубиться в отчет, чтобы получить дополнительные сведения, включая список учетных записей хранения, не соответствующих требованиям.

   

Использование политики 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 , чтобы продолжить создание или настройку учетной записи.

На следующем рисунке показано сообщение об ошибке, возникающей при попытке создать учетную запись хранения, которая разрешает анонимный доступ, если политика с эффектом "Запретить" требует запрета анонимного доступа.

Следующие шаги

• Обзор: Устранение анонимного доступа на чтение для BLOB-данных
• Рекомендации по обеспечению безопасности для Blob-хранилища