Důležité informace o sítích služby Azure Files

Ke sdíleným složkám Azure můžete přistupovat přes koncový bod přístupný z veřejného internetu, přes jeden nebo více privátních koncových bodů ve vaší síti nebo ukládáním sdílené složky Azure do mezipaměti místně s Synchronizace souborů Azure (jenom sdílené složky SMB). Tento článek se zaměřuje na konfiguraci služby Azure Files pro přímý přístup k veřejným nebo privátním koncovým bodům. Informace o tom, jak ukládat sdílenou složku Azure do mezipaměti místně pomocí Synchronizace souborů Azure, najdete v tématu Úvod do Synchronizace souborů Azure.

Před přečtením této příručky doporučujeme přečíst si plánování nasazení služby Azure Files.

Přímý přístup ke sdílené složce Azure často vyžaduje další myšlenku týkající se sítí:

  • Sdílené složky SMB komunikují přes port 445, který mnoho organizací a poskytovatelů internetových služeb (ISP) blokuje odchozí (internetový) provoz. Tento postup vychází ze starších pokynů k zabezpečení o zastaralých verzích protokolu SMB, které nejsou bezpečné pro internet. Protokol SMB 3.x je sice protokol bezpečný pro internet, ale zásady organizace nebo isp nemusí být možné změnit. Připojení sdílené složky SMB proto často vyžaduje další konfiguraci sítě pro použití mimo Azure.

  • Sdílené složky NFS spoléhají na ověřování na úrovni sítě a jsou proto přístupné jenom prostřednictvím sítí s omezeným přístupem. Použití sdílené složky NFS vždy vyžaduje určitou úroveň konfigurace sítě.

Konfigurace veřejných a privátních koncových bodů pro službu Azure Files se provádí v objektu správy nejvyšší úrovně pro službu Azure Files, účet úložiště Azure. Účet úložiště je konstruktor správy, který představuje sdílený fond úložiště, ve kterém můžete nasadit více sdílených složek Azure a také prostředky úložiště pro jiné služby Úložiště Azure, jako jsou kontejnery objektů blob nebo fronty.

Toto video je průvodce a ukázka, jak bezpečně vystavit sdílené složky Azure přímo informačním pracovníkům a aplikacím v pěti jednoduchých krocích. Následující části obsahují odkazy a další kontext dokumentace, na které odkazuje video. Všimněte si, že Azure Active Directory je teď Microsoft Entra ID. Další informace najdete v tématu Nový název pro Azure AD.

Platí pro

Typ sdílené složky SMB NFS
Sdílené složky úrovně Standard (GPv2), LRS/ZRS Yes No
Sdílené složky úrovně Standard (GPv2), GRS/GZRS Yes No
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS Ano Yes

Zabezpečený přenos

Účty úložiště Azure ve výchozím nastavení vyžadují zabezpečený přenos bez ohledu na to, jestli se k datům přistupuje přes veřejný nebo privátní koncový bod. V případě služby Soubory Azure se vyžaduje nastavení zabezpečeného přenosu pro veškerý přístup protokolu k datům uloženým ve sdílených složkách Azure, včetně smb, NFS a FileREST. Pokud chcete povolit nešifrovaný provoz, můžete zakázat nastavení vyžadovat zabezpečený přenos . Na webu Azure Portal se také může zobrazit toto nastavení označené jako vyžadování zabezpečeného přenosu pro operace rozhraní REST API.

Protokoly SMB, NFS a FileREST se mírně liší vzhledem k požadovanému nastavení zabezpečeného přenosu :

  • Pokud je pro účet úložiště povolený zabezpečený přenos , budou všechny sdílené složky SMB v daném účtu úložiště vyžadovat protokol SMB 3.x s protokolem AES-128-CCM, AES-128-GCM nebo AES-256-GCM v závislosti na dostupném/požadovaném vyjednávání šifrování mezi klientem SMB a službou Azure Files. Pomocí nastavení zabezpečení SMB můžete přepínat, které algoritmy šifrování SMB jsou povolené. Zakázání nastavení vyžadovat zabezpečený přenos umožňuje připojení SMB 2.1 a SMB 3.x bez šifrování.

  • Sdílené složky NFS nepodporují mechanismus šifrování, takže pokud chcete pro přístup ke sdílené složce Azure použít protokol NFS, musíte pro účet úložiště zakázat zabezpečený přenos .

  • Pokud je vyžadován zabezpečený přenos, je možné použít protokol FileREST pouze s HTTPS. FileREST je dnes podporován pouze u sdílených složek SMB.

Poznámka:

Komunikace mezi klientem a účtem úložiště Azure je šifrovaná pomocí protokolu TLS (Transport Layer Security). Služba Azure Files spoléhá na implementaci PROTOKOLU SSL pro Windows, která není založena na OpenSSL, a proto není vystavená ohrožením zabezpečení souvisejících s OpenSSL.

Veřejný koncový bod

Veřejný koncový bod pro sdílené složky Azure v rámci účtu úložiště je internetový vystavený koncový bod. Veřejný koncový bod je výchozím koncovým bodem pro účet úložiště, ale v případě potřeby ho můžete zakázat.

Protokoly SMB, NFS a FileREST můžou používat veřejný koncový bod. Každý z nich má ale mírně odlišná pravidla pro přístup:

  • Sdílené složky SMB jsou přístupné odkudkoli na světě prostřednictvím veřejného koncového bodu účtu úložiště s protokolem SMB 3.x s šifrováním. To znamená, že ověřené požadavky, jako jsou žádosti autorizované přihlašovací identitou uživatele, mohou bezpečně pocházet z oblasti Azure nebo mimo tuto oblast. Pokud se vyžaduje protokol SMB 2.1 nebo SMB 3.x bez šifrování, musí být splněny dvě podmínky:

    1. Účet úložiště vyžaduje nastavení zabezpečeného přenosu , musí být zakázané.
    2. Požadavek musí pocházet z oblasti Azure. Jak už jsme zmínili dříve, šifrované požadavky SMB jsou povolené odkudkoli, uvnitř oblasti Azure nebo mimo ji.
  • Sdílené složky NFS jsou přístupné z veřejného koncového bodu účtu úložiště, pokud je veřejný koncový bod účtu úložiště omezený na konkrétní virtuální sítě využívající koncové body služby. Další informace o koncových bodech služby najdete v nastavení brány firewall veřejného koncového bodu.

  • FileREST je přístupný prostřednictvím veřejného koncového bodu. Pokud je vyžadován zabezpečený přenos, přijímají se pouze požadavky HTTPS. Pokud je zabezpečený přenos zakázaný, veřejné koncové body přijímají požadavky HTTP bez ohledu na původ.

Nastavení brány firewall veřejného koncového bodu

Brána firewall účtu úložiště omezuje přístup k veřejnému koncovému bodu pro účet úložiště. Pomocí brány firewall účtu úložiště můžete omezit přístup k určitým IP adresům nebo rozsahům IP adres, konkrétním virtuálním sítím nebo úplně zakázat veřejný koncový bod.

Když omezíte provoz veřejného koncového bodu do jedné nebo více virtuálních sítí, používáte funkci virtuální sítě označované jako koncové body služby. Požadavky směrované na koncový bod služby služby Azure Files stále přejdou na veřejnou IP adresu účtu úložiště; Síťová vrstva však provádí dodatečné ověření požadavku, aby ověřila, že pochází z autorizované virtuální sítě. Protokoly SMB, NFS a FileREST podporují všechny koncové body služby. Na rozdíl od protokolu SMB a FileREST je ale ke sdíleným složkám NFS možné přistupovat pouze s veřejným koncovým bodem prostřednictvím koncového bodu služby.

Další informace o tom, jak nakonfigurovat bránu firewall účtu úložiště, najdete v tématu Konfigurace bran firewall služby Azure Storage a virtuálních sítí.

Směrování sítě veřejného koncového bodu

Azure Files podporuje více možností síťového směrování. Výchozí možnost Směrování Microsoftu funguje se všemi konfiguracemi služby Soubory Azure. Možnost internetového směrování nepodporuje scénáře připojení k doméně AD ani Synchronizace souborů Azure.

Privátní koncové body

Kromě výchozího veřejného koncového bodu pro účet úložiště nabízí služba Azure Files možnost mít jeden nebo více privátních koncových bodů. Privátní koncový bod je koncový bod, který je přístupný pouze ve virtuální síti Azure. Když pro svůj účet úložiště vytvoříte privátní koncový bod, získá váš účet úložiště privátní IP adresu z adresního prostoru vaší virtuální sítě, podobně jako místní souborový server nebo zařízení NAS obdrží IP adresu v rámci vyhrazeného adresního prostoru vaší místní sítě.

Jednotlivý privátní koncový bod je přidružený ke konkrétní podsíti virtuální sítě Azure. Účet úložiště může mít privátní koncové body ve více než jedné virtuální síti.

Použití privátních koncových bodů s Azure Files umožňuje:

  • Bezpečné připojení ke sdíleným složkám Azure z místních sítí pomocí připojení VPN nebo ExpressRoute s privátním partnerským vztahem
  • Zabezpečení sdílených složek Azure takovou konfigurací brány firewall účtu úložiště, aby byla blokována všechna připojení ve veřejném koncovém bodu Vytvoření privátního koncového bodu ve výchozím nastavení neblokuje připojení k veřejnému koncovému bodu.
  • Zvyšte zabezpečení virtuální sítě tím, že umožníte blokování exfiltrace dat z virtuální sítě (a hranic partnerského vztahu).

Pokud chcete vytvořit privátní koncový bod, přečtěte si téma Konfigurace privátních koncových bodů pro azure Files.

Tunelování provozu přes virtuální privátní síť nebo ExpressRoute

Pokud chcete používat privátní koncové body pro přístup ke sdíleným složkám SMB nebo NFS z místního prostředí, musíte vytvořit síťový tunel mezi místní sítí a Azure. Virtuální síť nebo virtuální síť se podobá tradiční místní síti. Podobně jako účet úložiště Azure nebo virtuální počítač Azure je virtuální síť prostředek Azure, který je nasazený ve skupině prostředků.

Azure Files podporuje následující mechanismy pro tunelování provozu mezi místními pracovními stanicemi a servery a sdílenými složkami Azure SMB/NFS:

  • Azure VPN Gateway: Brána VPN je konkrétní typ brány virtuální sítě, která se používá k odesílání šifrovaného provozu mezi virtuální sítí Azure a alternativním umístěním (například místně) přes internet. Azure VPN Gateway je prostředek Azure, který je možné nasadit ve skupině prostředků společně s účtem úložiště nebo jinými prostředky Azure. Brány VPN zpřístupňují dva různé typy připojení:
  • ExpressRoute, která umožňuje vytvořit definovanou trasu mezi Azure a místní sítí, která neprochází internetem. Vzhledem k tomu, že ExpressRoute poskytuje vyhrazenou cestu mezi místním datovým centrem a Azure, může být ExpressRoute užitečná v případě, že je potřeba zvážit výkon sítě. ExpressRoute je také dobrou volbou, když zásady nebo zákonné požadavky vaší organizace vyžadují deterministický přístup k vašim prostředkům v cloudu.

Poznámka:

Přestože doporučujeme používat privátní koncové body, které vám pomůžou rozšířit vaši místní síť do Azure, je technicky možné směrovat na veřejný koncový bod přes připojení VPN. To ale vyžaduje pevné kódování IP adresy pro veřejný koncový bod pro cluster úložiště Azure, který obsluhuje váš účet úložiště. Vzhledem k tomu, že se účty úložiště můžou přesouvat mezi clustery úložiště kdykoli a nové clustery se často přidávají a odebírají, vyžaduje to pravidelné pevné kódování všech možných IP adres úložiště Azure do pravidel směrování.

Konfigurace DNS

Při vytváření privátního koncového bodu vytvoříme ve výchozím nastavení také (nebo aktualizujeme existující) zónu privátního DNS odpovídající privatelink subdoméně. Přísně řečeno, vytvoření privátní zóny DNS není nutné k použití privátního koncového bodu pro váš účet úložiště. Obecně se ale důrazně doporučuje a explicitně se vyžaduje při připojování sdílené složky Azure pomocí instančního objektu uživatele Active Directory nebo přístupu k ní z rozhraní FileREST API.

Poznámka:

Tento článek používá příponu DNS účtu úložiště pro veřejné oblasti Azure. core.windows.net Tento komentář platí také pro suverénní cloudy Azure, jako je cloud Azure US Government a Microsoft Azure provozovaný cloudem 21Vianet, a stačí nahradit příslušné přípony pro vaše prostředí.

Ve vaší privátní zóně DNS vytvoříme záznam A pro storageaccount.privatelink.file.core.windows.net běžný název účtu úložiště a záznam CNAME, který se řídí vzorem storageaccount.file.core.windows.net. Vzhledem k tomu, že vaše privátní zóna DNS Azure je připojená k virtuální síti obsahující privátní koncový bod, můžete sledovat konfiguraci DNS voláním rutiny Resolve-DnsName z PowerShellu na virtuálním počítači nslookup Azure (případně ve Windows a Linuxu):

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

V tomto příkladu se účet storageaccount.file.core.windows.net úložiště přeloží na privátní IP adresu privátního koncového bodu, což se 192.168.0.4stane .

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

Pokud spustíte stejný příkaz z místního prostředí, uvidíte, že stejný název účtu úložiště se místo toho překládá na veřejnou IP adresu účtu úložiště. Jedná se například storageaccount.file.core.windows.net o záznam CNAME, který storageaccount.privatelink.file.core.windows.netje zase záznamem CNAME pro cluster úložiště Azure, který je hostitelem účtu úložiště:

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

To odráží skutečnost, že účet úložiště může zveřejnit veřejný koncový bod i jeden nebo více privátních koncových bodů. Pokud chcete zajistit, aby se název účtu úložiště přeložil na privátní IP adresu privátního koncového bodu, musíte změnit konfiguraci na místních serverech DNS. Toho lze dosáhnout několika způsoby:

  • Úprava souboru hostitelů na vašich klientech tak, aby se přeložil storageaccount.file.core.windows.net na privátní IP adresu požadovaného privátního koncového bodu. To se důrazně nedoporučuje v produkčních prostředích, protože tyto změny budete muset provést u každého klienta, který chce připojit sdílené složky Azure, a změny účtu úložiště nebo privátního koncového bodu se automaticky nezpracují.
  • Vytvoření záznamu A pro storageaccount.file.core.windows.net místní servery DNS To má výhodu, že klienti ve vašem místním prostředí budou moct automaticky přeložit účet úložiště, aniž by museli konfigurovat jednotlivé klienty. Toto řešení se ale podobá úpravě souboru hostitelů , protože se neprojeví změny. I když je toto řešení křehké, může být pro některá prostředí nejlepší volbou.
  • Přesměrujte zónu core.windows.net z místních serverů DNS do privátní zóny DNS Azure. Privátního hostitele DNS Azure je možné dosáhnout prostřednictvím speciální IP adresy (168.63.129.16), která je přístupná pouze ve virtuálních sítích propojených se zónou Azure Private DNS. Pokud chcete toto omezení obejít, můžete ve své virtuální síti spustit další servery DNS, které se budou předávat core.windows.net do zóny Azure Private DNS. Abychom tuto nastavení zjednodušili, poskytli jsme rutiny PowerShellu, které automaticky nasadí servery DNS ve vaší virtuální síti Azure a nakonfigurují je podle potřeby. Informace o nastavení předávání DNS najdete v tématu Konfigurace DNS se službou Azure Files.

SMB přes QUIC

Windows Server 2022 Azure Edition podporuje nový přenosový protokol s názvem QUIC pro server SMB poskytovaný rolí souborového serveru. QUIC je náhradou za TCP, která je postavena na UDP a poskytuje mnoho výhod oproti protokolu TCP a zároveň poskytuje spolehlivý transportní mechanismus. Jednou z klíčových výhod protokolu SMB je, že místo použití portu 445 se veškerý přenos provádí přes port 443, který je široce otevřený pro podporu HTTPS. To znamená, že SMB přes QUIC nabízí síť SMB VPN pro sdílení souborů přes veřejný internet. Windows 11 se dodává s klientem podporujícím protokol SMB přes QUIC.

Služba Azure Files v tuto chvíli nepodporuje protokol SMB přes QUIC. Přístup ke sdíleným složkám Azure ale můžete získat prostřednictvím Synchronizace souborů Azure spuštěného na Windows Serveru, jak je znázorněno v následujícím diagramu. To vám také umožňuje mít Synchronizace souborů Azure ukládat do mezipaměti jak místní, tak i v různých datacentrech Azure, aby bylo možné poskytovat místní mezipaměti distribuovaným pracovníkům. Další informace o této možnosti najdete v tématu Nasazení Synchronizace souborů Azure a SMB přes QUIC.

Diagram vytvoření zjednodušené mezipaměti sdílených složek Azure na windows Serveru 2022 Azure Edition V M pomocí Synchronizace souborů Azure

Viz také