Рекомендации по работе с сетями Файлов Azure

  • Статья

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

Перед чтением этого руководства рекомендуется ознакомиться с планированием развертывания Файлы Azure.

Для прямого доступа к общей папке Azure часто требуется дополнительная мысль относительно сети:

  • Общие папки SMB обмениваются данными через порт 445, который многие организации и поставщики услуг Интернета блокируют для исходящего трафика (интернет-трафика). Такой запрет основан на рекомендациях по защите от нерекомендуемых и небезопасных для Интернета версий протокола SMB. Хотя SMB 3.x — безопасный для Интернета протокол, политики организации или поставщика услуг Интернета могут не подлежать изменению. Поэтому для подключения общей папки SMB часто требуется дополнительная настройка сети для использования вне Azure.

  • Общие папки NFS используют проверку подлинности на уровне сети и поэтому доступны только через ограниченные сети. Для использования общей папки NFS всегда требуется определенный уровень конфигурации сети.

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

В этом видео показано, как безопасно предоставлять общие папки Azure непосредственно информационным работникам и приложениям за пять простых шагов. В разделах ниже приведены ссылки и дополнительный контекст для документации, указанной в видео. Обратите внимание, что Azure Active Directory теперь является идентификатором Microsoft Entra. Дополнительные сведения см. в статье "Новое имя" для Azure AD.

Применяется к

Тип общей папки SMB NFS
Стандартные общие папки (GPv2), LRS/ZRS Да Нет
Стандартные общие папки (GPv2), GRS/GZRS Да Нет
Общие папки уровня "Премиум" (FileStorage), LRS/ZRS Да Да

Скорость безопасной передачи

По умолчанию для учетных записей хранения Azure обязательно требуется безопасная передача независимо от того, через какую конечную точку осуществляется доступ к данным: общедоступную или частную. Для Файлов Azure параметр обязательной безопасной передачи принудительно применяется для доступа к данным, хранящимся в общих папках Azure, включая SMB, NFS и FileREST, с использованием всех протоколов. Вы можете отключить параметр безопасной передачи , чтобы разрешить незашифрованный трафик. В портал Azure также можно увидеть этот параметр, помеченный как требование безопасной передачи для операций REST API.

Поведение протоколов SMB, NFS и FileREST в отношении параметра обязательной безопасной передачи может быть немного различным:

  • Если для учетной записи хранения включен параметр обязательной безопасной передачи, для всех общих папок SMB в этой учетной записи хранения потребуется протокол SMB 3.x с алгоритмами шифрования AES-128-CCM, AES-128-GCM или AES-256-GCM в зависимости от доступного или требуемого согласования шифрования между клиентом SMB и Файлами Azure. Вы можете переключать алгоритмы шифрования SMB с помощью параметров безопасности SMB. Если параметр обязательной безопасной передачи отключен, разрешаются подключения SMB 2.1 и SMB 3.x без шифрования.

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

  • Если параметр обязательной безопасной передачи включен, протокол FileREST можно использовать только с HTTPS. Сейчас FileREST поддерживается только в общих папках SMB.

Примечание.

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

Общедоступная конечная точка

Общедоступная конечная точка для общих папок Azure в учетной записи хранения — это доступная в Интернете конечная точка. Общедоступная конечная точка является для учетной записи хранения конечной точкой по умолчанию, но при необходимости ее можно отключить.

Протоколы SMB, NFS и FileREST могут использовать общедоступную конечную точку. Но у всех них немного разные правила для доступа:

  • Общие папки SMB доступны из любой точки мира через общедоступную конечную точку учетной записи хранения с шифрованием SMB 3.x. Это обеспечивает безопасную отправку запросов с проверкой подлинности (например, с авторизацией по идентификатору входа пользователя) изнутри или извне региона Azure. Если нужно использовать SMB 2.1 или SMB 3.x без шифрования, необходимо выполнить два условия:

    1. Параметр обязательной безопасной передачи для учетной записи хранения должен быть отключен.
    2. Запрос должен исходить из региона Azure. Как упоминалось ранее, зашифрованные запросы SMB разрешены из любого расположения как внутри, так и вне региона Azure.

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

  • FileREST доступен через общедоступную конечную точку. Если параметр обязательной безопасной передачи включен, принимаются только HTTPS-запросы. Если безопасная передача отключена, HTTP-запросы принимаются общедоступной конечной точкой, независимо от источника.

Параметры брандмауэра общедоступных конечных точек

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

При ограничении трафика общедоступной конечной точки на одну или несколько виртуальных сетей вы используете возможность виртуальной сети, называемой конечными точками службы. Запросы, направленные в конечную точку службы "Файлы Azure" по-прежнему отправляются на общедоступный IP-адрес учетной записи хранения. Но сетевой уровень выполняет дополнительную проверку запроса, чтобы убедиться, что он поступает из авторизованной виртуальной сети. Протоколы SMB, NFS и FileREST поддерживают конечные точки служб. Но, в отличие от SMB и FileREST, общие папки NFS можно получить только с использованием общедоступной конечной точки и конечной точки службы.

Дополнительные сведения о том, как настраивать брандмауэр учетной записи хранения, см. в статье Configure Azure Storage firewalls and virtual networks (Настройка брандмауэров и виртуальных сетей службы хранилища Azure).

Маршрутизация сети общедоступной конечной точки

Служба "Файлы Azure" поддерживает несколько вариантов сетевой маршрутизации. Маршрутизация Майкрософт, являющаяся вариантом по умолчанию, работает со всеми конфигурациями службы "Файлы Azure". Параметр маршрутизации через Интернет не поддерживает сценарии присоединения к домену AD или Синхронизация файлов Azure.

Частные конечные точки

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

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

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

  • Безопасное подключение к общим папкам Azure из локальных сетей через VPN или ExpressRoute с частным пирингом.
  • Защита общих папок Azure путем настройки брандмауэра учетной записи хранения на блокировку всех подключений к общедоступной конечной точке. По умолчанию создание частной конечной точки не блокирует подключения к общедоступной конечной точке.
  • Повышение уровня безопасности виртуальной сети благодаря предотвращению утечки данных через границы виртуальной сети (и пиринга).

Сведения о создании частной конечной точки см. в статье Настройка частных конечных точек для службы "Файлы Azure".

Туннелирование трафика через виртуальную частную сеть или ExpressRoute

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

Служба "Файлы Azure" поддерживает следующие механизмы для туннелирования трафика между локальными рабочими станциями, серверами и общими папками SMB или NFS в Azure:

  • VPN-шлюз Azure — это особый тип шлюза виртуальной сети, используемый для отправки зашифрованного трафика между виртуальной сетью Azure и альтернативным расположением (например, в локальной среде) через Интернет. VPN-шлюз Azure — это ресурс Azure, который можно развернуть в группе ресурсов вместе с учетной записью хранения или другими ресурсами Azure. VPN-шлюзы предоставляют два различных типа подключений:
  • ExpressRoute, который позволяет создать определенный маршрут между Azure и локальной сетью, которая не проходит через Интернет. Так как ExpressRoute предоставляет выделенный путь между локальным центром обработки данных и Azure, ExpressRoute может оказаться полезным при рассмотрении производительности сети. ExpressRoute также является хорошим вариантом, если политика или нормативные требования вашей организации предполагают детерминированный путь к ресурсам в облаке.

Примечание.

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

DNS configuration (Настройка DNS)

При создании частной конечной точки по умолчанию также создается (или обновляется, если она уже существует) частная зона DNS, соответствующая поддомену privatelink. Строго говоря, создание частной зоны DNS не требуется для использования частной конечной точки для учетной записи хранения. Тем не менее, настоятельно рекомендуется, и это явно необходимо при подключении общей папки Azure с субъектом-пользователем Active Directory или доступом к нему из API FileREST.

Примечание.

В этой статье используется DNS-суффикс учетной записи хранения core.windows.net, выделенный для общедоступных регионов Azure. Этот комментарий также относится к облакам Azure Sovereign, таким как облако Azure для государственных организаций США и Microsoft Azure, управляемый облаком 21Vianet, просто замените соответствующие суффиксы для вашей среды.

В этой частной зоне DNS мы создадим запись A для storageaccount.privatelink.file.core.windows.net и запись CNAME для обычного имени учетной записи хранения, которое имеет формат storageaccount.file.core.windows.net. Так как частная зона DNS Azure подключается к виртуальной сети, которая содержит частную конечную точку, вызывая командлет Resolve-DnsName из PowerShell на виртуальной машине Azure (или nslookup в Windows и Linux), вы получите следующую конфигурацию DNS:

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

В этом примере учетная запись storageaccount.file.core.windows.net хранения разрешает частный IP-адрес частной конечной точки, которая происходит 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

При выполнении той же команды из локальной среды вы увидите, что то же имя учетной записи хранения разрешается на общедоступный IP-адрес учетной записи хранения. Например, это запись CNAME, storageaccount.privatelink.file.core.windows.netдля которой, в свою очередь, storageaccount.file.core.windows.net является записьЮ CNAME для кластера хранилища Azure, на котором размещена учетная запись хранения:

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Такая конфигурация отражает тот факт, что учетная запись хранения может одновременно предоставлять общедоступную конечную точку и одну или несколько частных конечных точек. Чтобы имя учетной записи хранения гарантированно разрешалось в частный IP-адрес частной конечной точки, необходимо изменить конфигурацию на локальных DNS-серверах. Это можно сделать несколькими способами.

  • Измените файл hosts во всех клиентах, чтобы storageaccount.file.core.windows.net разрешалась в нужный частный IP-адрес частной конечной точки. Это настоятельно не рекомендуется для рабочих сред, так как вам потребуется внести эти изменения в каждый клиент, который хочет подключить общие папки Azure, и изменения в учетной записи хранения или частной конечной точке не будут обрабатываться автоматически.
  • Создание записи A для storageaccount.file.core.windows.net на локальных DNS-серверах. Этот вариант более предпочтителен тем, что клиенты в локальной среде смогут автоматически разрешать адреса учетной записи хранения без индивидуальной настройки каждого клиента. Однако это решение аналогично сбоем в изменении файла узлов , так как изменения не отражаются. Хотя это решение является хрупким, это может быть лучшим выбором для некоторых сред.
  • Переадресация зоны core.windows.net с локальных DNS-серверов в частную зону DNS Azure. Частный DNS-узел Azure доступен по специальному IP-адресу 168.63.129.16, который имеет видимость только внутри виртуальных сетей, связанных с частной зоной DNS Azure. Чтобы обойти это ограничение, можно создать в виртуальной сети дополнительные DNS-серверы для переадресации core.windows.net в частную зону DNS Azure. Чтобы упростить эту настройку, мы предоставили командлеты PowerShell, которые будут автоматически развертывать DNS-серверы в виртуальной сети Azure и настраивать их по мере необходимости. Сведения о настройке перенаправления DNS для службы "Файлы Azure" см. в этой статье.

SMB по QUIC

Windows Server 2022 Azure Edition поддерживает новый транспортный протокол с именем QUIC для сервера SMB, предоставляемого ролью файлового сервера. QUIC — это замена TCP, созданная на основе UDP и обеспечивающая многочисленные преимущества по сравнению с TCP. При этом поддерживается надежный механизм транспортировки. Одним из ключевых плюсов протокола SMB является то, что вместо использования порта 445 транспортировка полностью выполняется через порт 443, который широко открыт для исходящего трафика по HTTPS. Это фактически означает, что SMB по QUIC предлагает "VPN SMB" для совместного использования файлов через общедоступный Интернет. Windows 11 поставляется с использованием SMB через клиент с поддержкой QUIC.

Сейчас служба "Файлы Azure" не поддерживает SMB через QUIC напрямую. Однако доступ к общим папкам Azure можно получить с помощью Синхронизации файлов Azure, запущенной на сервере Windows, как показано на схеме ниже. Это также дает вам возможность иметь кэши Azure File Sync как локально, так и в разных центрах обработки данных Azure, чтобы обеспечить локальные кэши для распределенных рабочих ресурсов. Дополнительные сведения об этом параметре см. в разделе Развертывание Синхронизации файлов Azure и SMB по QUIC.

Схема создания упрощенного кэша общих папок Azure в Windows Server 2022 Azure Edition V M с помощью Синхронизация файлов Azure.

См. также