Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Вы можете получить доступ к общим папкам 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, таких как контейнеры BLOB или очереди.
В этом видео показано, как безопасно предоставлять общие папки Azure непосредственно информационным работникам и приложениям за пять простых шагов. В разделах ниже приведены ссылки и дополнительные контексты документации, на которые ссылается видео. Обратите внимание, что Azure Active Directory теперь является идентификатором Microsoft Entra. Дополнительные сведения см. в разделе Новое название для Azure AD.
Применимо к
Тип общей папки | Малый и средний бизнес (SMB) | Сетевая файловая система (NFS) |
---|---|---|
Стандартные общие папки (GPv2), LRS/ZRS |
![]() |
![]() |
Стандартные общие папки (GPv2), GRS/GZRS |
![]() |
![]() |
Премиальные файловые хранилища (FileStorage), LRS/ZRS |
![]() |
![]() |
Безопасная передача
По умолчанию учетные записи хранения Azure требуют безопасной передачи независимо от того, осуществляется ли доступ к данным через общедоступную или частную конечную точку. Для Azure Files настройка требования безопасной передачи применяется ко всем протоколам доступа к данным, хранящимся в общих файлах 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 Files. Вы можете переключить алгоритмы шифрования SMB с помощью параметров безопасности SMB. Отключение параметра требования безопасной передачи позволяет монтировать SMB 2.1 и SMB 3.x без шифрования.
Облачные файлы NFS не поддерживают механизм шифрования, поэтому, чтобы использовать протокол NFS для доступа к облачному файлу Azure, необходимо отключить требование безопасной передачи для учетной записи хранения.
Если требуется безопасная передача, протокол FileREST может использоваться только с HTTPS. FileREST поддерживается только в общих папках SMB сегодня.
Примечание.
Обмен данными между клиентом и учетной записью хранения Azure шифруется с помощью протокола TLS. Azure Files полагаются на реализацию SSL в Windows, которая не основана на OpenSSL и поэтому не подвержена уязвимостям, связанным с OpenSSL.
Общедоступная конечная точка
Общедоступная конечная точка для общих папок Azure в учетной записи хранения — это подключённая к интернету конечная точка. Общедоступная конечная точка — это конечная точка по умолчанию для учетной записи хранения, но ее можно отключить при необходимости.
Протоколы SMB, NFS и FileREST могут использовать общедоступную конечную точку. Однако у каждого есть несколько разных правил для доступа:
Общие папки SMB доступны из любой точки мира через общедоступную конечную точку учетной записи хранения с помощью SMB 3.x с шифрованием. Это означает, что прошедшие проверку подлинности запросы, такие как запросы, авторизованные удостоверением входа пользователя, могут безопасно выполняться изнутри или за пределами региона Azure. Если требуется SMB 2.1 или SMB 3.x без шифрования, необходимо выполнить два условия:
- Настройка требования безопасной передачи для учетной записи хранения должна быть отключена.
- Запрос должен происходить из региона Azure. Как упоминалось ранее, зашифрованные запросы SMB разрешены из любого места, внутри или за пределами региона Azure.
Общие папки NFS доступны из общедоступной конечной точки учетной записи хранения, если и только если общедоступная конечная точка учетной записи хранения ограничена определенными виртуальными сетями с помощью конечных точек службы. См. параметри брандмауэра для общедоступной конечной точки в разделе параметры брандмауэра общедоступной конечной точки для получения дополнительных сведений о конечных точках службы.
FileREST доступен через общедоступную конечную точку. Если требуется безопасная передача, принимаются только HTTPS-запросы. Если безопасная передача отключена, HTTP-запросы принимаются общедоступной конечной точкой независимо от источника.
Параметры брандмауэра общедоступной конечной точки
Брандмауэр учетной записи хранения ограничивает доступ к общедоступной конечной точке для учетной записи хранения. С помощью брандмауэра учетной записи хранения можно ограничить доступ к определенным IP-адресам или диапазонам IP-адресов, определенным виртуальным сетям или полностью отключить общедоступную конечную точку.
При ограничении трафика общедоступной конечной точки на одну или несколько виртуальных сетей вы используете возможность виртуальной сети, называемой конечными точками службы. Запросы, направленные на конечную точку службы файлов Azure, по-прежнему отправляются в общедоступный IP-адрес учетной записи хранения; однако сетевой уровень выполняет дополнительную проверку запроса, чтобы убедиться, что он поступает из авторизованной виртуальной сети. Протоколы SMB, NFS и FileREST поддерживают все конечные точки службы. В отличие от SMB и FileREST, доступ к общим папкам NFS возможен только через общедоступную конечную точку, используя конечную точку службы.
Дополнительные сведения о настройке брандмауэра учетной записи хранения см. в статье о настройке брандмауэров службы хранилища 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 поддерживают следующие механизмы туннелирования трафика между локальными рабочими станциями и серверами и общими папками Azure SMB/NFS:
-
VPN-шлюз Azure — это особый тип шлюза виртуальной сети, используемый для отправки зашифрованного трафика между виртуальной сетью Azure и альтернативным расположением (например, в локальной среде) через Интернет. VPN-шлюз Azure — это ресурс Azure, который можно развернуть в группе ресурсов вместе с учетной записью хранения или другими ресурсами Azure. VPN-шлюзы предоставляют два различных типа подключений:
- VPN-шлюзы типа "точка-сайт" (P2S), которые представляют собой VPN-подключения между Azure и отдельным клиентом. Это решение в первую очередь полезно для устройств, которые не являются частью локальной сети организации. Распространенный вариант использования — это для удаленных сотрудников, которые хотят иметь возможность подключить общую папку Azure из дома, кафе или отеля, находясь в пути. Чтобы использовать VPN-подключение P2S с файлами Azure, необходимо настроить VPN-подключение P2S для каждого клиента, который хочет подключиться. Сведения о настройке VPN типа "точка — сеть" (P2S) в Windows для использования с файлами Azure и настройке VPN типа "точка — сеть" в Linux для использования с файлами Azure.
- VPN типа "сеть — сеть" (S2S), которые являются VPN-подключениями между Azure и сетью вашей организации. VPN-подключение S2S позволяет настроить VPN-подключение один раз для VPN-сервера или устройства, размещенного в сети вашей организации, а не настраивать подключение для каждого клиентского устройства, необходимого для доступа к общей папке Azure. См. статью Настройка VPN типа "сеть — сеть" (S2S) при работе с файлами Azure.
- ExpressRoute, который позволяет создать определенный маршрут между Azure и локальной сетью, которая не проходит через Интернет. Так как ExpressRoute предоставляет выделенный путь между локальным центром обработки данных и Azure, ExpressRoute может оказаться полезным при рассмотрении производительности сети. ExpressRoute также является хорошим вариантом, если политика или нормативные требования вашей организации предполагают детерминированный путь к ресурсам в облаке.
Примечание.
Хотя мы рекомендуем использовать частные конечные точки для расширения локальной сети в Azure, технически можно перенаправляться на общедоступную конечную точку через VPN-подключение. Однако для этого требуется жесткое кодирование IP-адреса общедоступной конечной точки для кластера хранилища Azure, который служит вашей учетной записи хранения. Так как учетные записи хранения могут перемещаться между кластерами хранения в любое время и новые кластеры часто добавляются и удаляются, это требует регулярного жесткого написания всех возможных IP-адресов службы хранилища Azure в правилах маршрутизации.
DNS configuration (Настройка DNS)
При создании частной конечной точки по умолчанию мы также создадим частную зону DNS (или обновим существующую) частную зону DNS, соответствующую поддомену privatelink
. Строго говоря, создание частной зоны DNS не требуется для использования частной конечной точки для учетной записи хранения. Тем не менее, настоятельно рекомендуется для использования в общем случае, и это явно необходимо при монтировании общего ресурса файлов Azure с использованием субъекта-пользователя Active Directory или доступа к нему через FileREST API.
Примечание.
В этой статье используется DNS-суффикс учетной записи хранения для общедоступных регионов Azure core.windows.net
. Этот комментарий также относится к облакам Azure Sovereign, таким как облако Azure для государственных организаций США и Microsoft Azure, управляемый облаком 21Vianet, просто замените соответствующие суффиксы для вашей среды.
В частной зоне DNS мы создадим запись A и запись storageaccount.privatelink.file.core.windows.net
CNAME для регулярного имени учетной записи хранения, которая соответствует шаблону storageaccount.file.core.windows.net
. Так как частная зона DNS Azure подключена к виртуальной сети, содержащей частную конечную точку, можно наблюдать за конфигурацией DNS, вызвав Resolve-DnsName
командлет из PowerShell на виртуальной машине Azure (или nslookup
в Windows и Linux):
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-серверах. Преимущество заключается в том, что клиенты в локальной среде смогут автоматически разрешать доступ к учетной записи без необходимости в настройках каждого клиента. Однако это решение аналогично изменению файла hosts, так как изменения не отражаются. Хотя это решение является хрупким, это может быть лучшим выбором для некоторых сред. -
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, смотрите Настройка DNS с помощью Azure Files.
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 Server, как показано на схеме ниже. Это также позволяет кэшировать кэши службы "Синхронизация файлов Azure" как в локальной среде, так и в разных центрах обработки данных Azure для предоставления локальных кэшей для распределенной рабочей силы. Дополнительные сведения об этом параметре см. в статье "Развертывание службы "Синхронизация файлов Azure " и SMB по QUIC.