Устранение ошибок авторизации брандмауэра учётных записей хранения Azure

Введение

Усиление доступа к плоскости данных учётной записи хранения — распространённая практика повышения безопасности. Однако при использовании ресурсов Azure с интеграцией виртуальной сети (VNET) или доступе к конечным точкам хранения с частных IP-адресов или из других арендаторов могут возникать ошибки авторизации, если источник не внесён должным образом в белый список. В этой статье рассматриваются распространённые сценарии, приводящие к таким ошибкам, и предлагаются практические решения.


Распространённые сценарии ошибок авторизации

Сценарий 1: доступ из другого региона

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


Сценарий 2: сбой доступа из того же региона

Запросы из того же региона Azure часто используют частные IP-адреса Azure вместо общедоступных IP-адресов. В этом случае внесение общедоступных IP-адресов в белый список не сработает. См. Настройка брандмауэров и виртуальных сетей службы хранилища Azure для получения дополнительной информации.


Сценарий 3: ограничение доступа к определённой подсети

Если у ресурсов нет общедоступных IP-адресов, но клиент хочет ограничить доступ к определённой подсети, могут возникнуть проблемы из-за ограничений видимости. Брандмауэр учётной записи хранения может не отображать целевую подсеть, поэтому требуется ручное внесение в белый список кем-то, обладающим доступом RBAC участника (Contributor) или выше.


Сценарий 4: доступ из другого арендатора Azure

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


Шаги решения

Добавление подсети из другого арендатора

Чтобы внести в белый список подсеть из виртуальной сети другого арендатора Azure, необходимо использовать параметр VirtualNetworkResourceId должен быть использован. Для этого нужно указать URI подсети в форме:

/subscriptions/<subscription-ID>/resourceGroups/<resourceGroup-Name>/providers/Microsoft.Network/virtualNetworks/<vNet-name>/subnets/<subnet-name>

Пример команды PowerShell

Чтобы получить URI подсети, используйте следующую команду:

$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"

Если у пользователя недостаточно доступа для выполнения этой команды в исходном арендаторе, он может получить URI подсети, проверив тело JSON ресурса VNET в Azure. Для этого требуется доступ READ к плоскости управления к ресурсу.


Включение конечной точки службы хранилища

Перед внесением подсети в белый список убедитесь, что конечная точка службы Microsoft.Storage или Microsoft.Storage.Global включена. Это можно сделать с помощью Azure PowerShell, CLI или портала Azure. Пошаговые инструкции см. в разделе Настройка брандмауэров и виртуальных сетей службы хранилища Azure.

Пример команды для внесения в белый список

После получения URI подсети используйте следующую команду, чтобы добавить сетевое правило:

Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount" -VirtualNetworkResourceId $subnet

Проверка

Чтобы проверить соединение, используйте команду curl с токеном SAS:

curl https://storageaccountname.blob.core.windows.net/container/hello.txt?<SAS token>

Совет:

  • Флаг -v в команде curl включает подробный вывод, который может помочь определить HTTP-ответы, такие как 403 Forbidden. Уберите флаг для более чистого вывода.

Пример ниже покажет подсеть в брандмауэре целевой учётной записи хранения 

Совет: Выделенное предупреждение можно спокойно игнорировать; оно связано с доступом READ к плоскости управления для подсети, внесённой в белый список; доступ к плоскости данных будет разрешён. 


Дополнительные соображения

  1. Включение конечных точек службы: Включение конечной точки службы хранилища может вызвать временные перебои в подключении. Дополнительные сведения см. в разделе Конечные точки службы виртуальной сети Azure.
  2. Частные конечные точки: Частные конечные точки обходят сетевые правила брандмауэра, поскольку они полагаются на DNS и подключение через авторизованную подсеть. См. Использование частных конечных точек – служба хранилища Azure.
  3. Плоскость управления и плоскость данных: Понимание разницы между операциями плоскости управления и плоскости данных крайне важно для устранения неполадок. Подробнее см. в разделе Операции плоскости управления и плоскости данных.

Заключение

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

Оставить комментарий