Zagadnienia dotyczące sieci usługi Azure Files
Dostęp do udziałów plików platformy Azure można uzyskać za pośrednictwem publicznego punktu końcowego dostępnego w Internecie, za pośrednictwem co najmniej jednego prywatnego punktu końcowego w sieci lub buforując lokalny udział plików platformy Azure za pomocą usługi Azure File Sync (tylko udziały plików SMB). W tym artykule opisano sposób konfigurowania usługi Azure Files pod kątem bezpośredniego dostępu za pośrednictwem publicznych i/lub prywatnych punktów końcowych. Aby dowiedzieć się, jak buforować lokalny udział plików platformy Azure za pomocą usługi Azure File Sync, zobacz Wprowadzenie do usługi Azure File Sync.
Zalecamy przeczytanie tematu Planowanie wdrożenia usługi Azure Files przed przeczytaniem tego przewodnika.
Bezpośrednie uzyskiwanie dostępu do udziału plików platformy Azure często wymaga dodatkowej myślenia w odniesieniu do sieci:
Udziały plików SMB komunikują się za pośrednictwem portu 445, który wiele organizacji i dostawców usług internetowych (ISPs) blokuje ruch wychodzący (internet). Ta praktyka wynika ze starszych wskazówek dotyczących zabezpieczeń dotyczących przestarzałych i nieinternestycznych wersji protokołu SMB. Mimo że protokół SMB 3.x jest protokołem bezpiecznym dla Internetu, zasady organizacji lub usługodawcy internetowego mogą nie być możliwe do zmiany. W związku z tym instalowanie udziału plików SMB często wymaga dodatkowej konfiguracji sieci do użycia poza platformą Azure.
Udziały plików NFS korzystają z uwierzytelniania na poziomie sieci i dlatego są dostępne tylko za pośrednictwem sieci z ograniczeniami. Korzystanie z udziału plików NFS zawsze wymaga pewnego poziomu konfiguracji sieci.
Konfigurowanie publicznych i prywatnych punktów końcowych dla usługi Azure Files odbywa się w obiekcie zarządzania najwyższego poziomu dla usługi Azure Files, konta usługi Azure Storage. Konto magazynu to konstrukcja zarządzania, która reprezentuje udostępnioną pulę magazynu, w której można wdrożyć wiele udziałów plików platformy Azure, a także zasoby magazynu dla innych usług Azure Storage, takich jak kontenery obiektów blob lub kolejki.
Ten film wideo jest przewodnikiem i pokazem dotyczącym bezpiecznego uwidaczniania udziałów plików platformy Azure bezpośrednio dla pracowników i aplikacji informacyjnych w pięciu prostych krokach. Poniższe sekcje zawierają linki i dodatkowy kontekst do dokumentacji, do których odwołuje się film wideo. Pamiętaj, że usługa Azure Active Directory jest teraz identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.
Dotyczy
| Typ udziału plików | SMB | NFS |
|---|---|---|
| Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS |  |
 |
| Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS | |
|
| Udziały plików w warstwie Premium (FileStorage), LRS/ZRS | |
|
Bezpieczny transfer
Domyślnie konta usługi Azure Storage wymagają bezpiecznego transferu, niezależnie od tego, czy dane są dostępne za pośrednictwem publicznego lub prywatnego punktu końcowego. W przypadku usługi Azure Files ustawienie wymagaj bezpiecznego transferu jest wymuszane dla całego dostępu protokołu do danych przechowywanych w udziałach plików platformy Azure, w tym SMB, NFS i FileREST. Możesz wyłączyć ustawienie wymagaj bezpiecznego transferu , aby zezwolić na niezaszyfrowany ruch. W witrynie Azure Portal to ustawienie może być również oznaczone etykietą wymaganie bezpiecznego transferu dla operacji interfejsu API REST.
Protokoły SMB, NFS i FileREST mają nieco inne zachowanie w odniesieniu do ustawienia wymaganego bezpiecznego transferu :
W przypadku włączenia bezpiecznego transferu na koncie magazynu wszystkie udziały plików SMB na tym koncie magazynu będą wymagały protokołu SMB 3.x z protokołem AES-128-CCM, AES-128-GCM lub AES-256-GCM, w zależności od dostępnych/wymaganych negocjacji szyfrowania między klientem SMB i usługą Azure Files. Można przełączać, które algorytmy szyfrowania SMB są dozwolone za pośrednictwem ustawień zabezpieczeń protokołu SMB. Wyłączenie ustawienia wymagaj bezpiecznego transferu umożliwia instalowanie protokołu SMB 2.1 i SMB 3.x bez szyfrowania.
Udziały plików NFS nie obsługują mechanizmu szyfrowania, dlatego aby używać protokołu NFS do uzyskiwania dostępu do udziału plików platformy Azure, należy wyłączyć opcję Wymagaj bezpiecznego transferu dla konta magazynu.
Gdy wymagany jest bezpieczny transfer, protokół FileREST może być używany tylko z protokołem HTTPS. PlikREST jest obecnie obsługiwany tylko w udziałach plików SMB.
Uwaga
Komunikacja między klientem a kontem usługi Azure Storage jest szyfrowana przy użyciu protokołu Transport Layer Security (TLS). Usługa Azure Files opiera się na implementacji protokołu SSL systemu Windows, która nie jest oparta na protokole OpenSSL i dlatego nie jest widoczna dla luk w zabezpieczeniach związanych z protokołem OpenSSL.
Publiczny punkt końcowy
Publiczny punkt końcowy udziałów plików platformy Azure w ramach konta magazynu jest internetowym uwidoczniony punkt końcowy. Publiczny punkt końcowy jest domyślnym punktem końcowym dla konta magazynu, jednak w razie potrzeby można go wyłączyć.
Protokoły SMB, NFS i FileREST mogą używać publicznego punktu końcowego. Jednak każdy z nich ma nieco inne reguły dostępu:
Udziały plików SMB są dostępne z dowolnego miejsca na świecie za pośrednictwem publicznego punktu końcowego konta magazynu z szyfrowaniem SMB 3.x. Oznacza to, że uwierzytelnione żądania, takie jak żądania autoryzowane przez tożsamość logowania użytkownika, mogą bezpiecznie pochodzić z wewnątrz lub poza regionem świadczenia usługi Azure. Jeśli protokół SMB 2.1 lub SMB 3.x bez szyfrowania jest wymagany, należy spełnić dwa warunki:
- Ustawienie wymaganego bezpiecznego transferu na koncie magazynu musi być wyłączone.
- Żądanie musi pochodzić z regionu świadczenia usługi Azure. Jak wspomniano wcześniej, zaszyfrowane żądania SMB są dozwolone z dowolnego miejsca lub poza regionem świadczenia usługi Azure.
Udziały plików NFS są dostępne z publicznego punktu końcowego konta magazynu, jeśli i tylko wtedy, gdy publiczny punkt końcowy konta magazynu jest ograniczony do określonych sieci wirtualnych przy użyciu punktów końcowych usługi. Aby uzyskać dodatkowe informacje na temat punktów końcowych usługi, zobacz ustawienia zapory publicznego punktu końcowego.
PlikREST jest dostępny za pośrednictwem publicznego punktu końcowego. Jeśli wymagany jest bezpieczny transfer, akceptowane są tylko żądania HTTPS. Jeśli bezpieczny transfer jest wyłączony, żądania HTTP są akceptowane przez publiczny punkt końcowy niezależnie od źródła.
Ustawienia zapory publicznego punktu końcowego
Zapora konta magazynu ogranicza dostęp do publicznego punktu końcowego dla konta magazynu. Za pomocą zapory konta magazynu można ograniczyć dostęp do określonych adresów IP/zakresów adresów IP, do określonych sieci wirtualnych lub całkowicie wyłączyć publiczny punkt końcowy.
Jeśli ograniczasz ruch publicznego punktu końcowego do co najmniej jednej sieci wirtualnej, używasz możliwości sieci wirtualnej nazywanej punktami końcowymi usługi. Żądania kierowane do punktu końcowego usługi usługi Azure Files nadal przechodzą do publicznego adresu IP konta magazynu; Jednak warstwa sieci wykonuje dodatkową weryfikację żądania w celu sprawdzenia, czy pochodzi z autoryzowanej sieci wirtualnej. Wszystkie protokoły SMB, NFS i FileREST obsługują punkty końcowe usługi. W przeciwieństwie do protokołu SMB i FileREST, jednak udziały plików NFS mogą być dostępne tylko z publicznym punktem końcowym za pomocą punktu końcowego usługi.
Aby dowiedzieć się więcej na temat konfigurowania zapory konta magazynu, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.
Routing sieci publicznego punktu końcowego
Usługa Azure Files obsługuje wiele opcji routingu sieciowego. Opcja domyślna, routing firmy Microsoft, współpracuje ze wszystkimi konfiguracjami usługi Azure Files. Opcja routingu internetowego nie obsługuje scenariuszy przyłączania do domeny usługi AD ani usługi Azure File Sync.
Prywatne punkty końcowe
Oprócz domyślnego publicznego punktu końcowego dla konta magazynu usługa Azure Files udostępnia opcję posiadania co najmniej jednego prywatnego punktu końcowego. Prywatny punkt końcowy to punkt końcowy, który jest dostępny tylko w sieci wirtualnej platformy Azure. Podczas tworzenia prywatnego punktu końcowego dla konta magazynu konto magazynu pobiera prywatny adres IP z przestrzeni adresowej sieci wirtualnej, podobnie jak sposób odebrania lokalnego serwera plików lub urządzenia NAS adresu IP w dedykowanej przestrzeni adresowej sieci lokalnej.
Pojedynczy prywatny punkt końcowy jest skojarzony z określoną podsiecią sieci wirtualnej platformy Azure. Konto magazynu może mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.
Użycie prywatnych punktów końcowych z usługą Azure Files zapewnia następujące możliwości:
- bezpieczne łączenie się z udziałami plików platformy Azure z sieci lokalnych przy użyciu sieci VPN lub połączenia ExpressRoute z prywatną komunikacją równorzędną,
- zabezpieczenie udziałów plików platformy Azure przez skonfigurowanie zapory konta magazynu w celu blokowania wszystkich połączeń w publicznym punkcie końcowym, Domyślnie tworzenie prywatnego punktu końcowego nie blokuje połączeń z publicznym punktem końcowym.
- zwiększenie bezpieczeństwa sieci wirtualnej przez umożliwienie blokowania eksfiltracji danych z sieci wirtualnej (i granic komunikacji równorzędnej).
Aby utworzyć prywatny punkt końcowy, zobacz Konfigurowanie prywatnych punktów końcowych dla usługi Azure Files.
Tunelowanie ruchu za pośrednictwem wirtualnej sieci prywatnej lub usługi ExpressRoute
Aby używać prywatnych punktów końcowych do uzyskiwania dostępu do udziałów plików SMB lub NFS ze środowiska lokalnego, należy ustanowić tunel sieciowy między siecią lokalną a platformą Azure. Sieć wirtualna lub sieć wirtualna jest podobna do tradycyjnej sieci lokalnej. Podobnie jak konto usługi Azure Storage lub maszyna wirtualna platformy Azure, sieć wirtualna to zasób platformy Azure wdrożony w grupie zasobów.
Usługa Azure Files obsługuje następujące mechanizmy tunelowania ruchu między lokalnymi stacjami roboczymi i serwerami i udziałami plików SMB/NFS platformy Azure:
- Azure VPN Gateway: brama sieci VPN to określony typ bramy sieci wirtualnej, która służy do wysyłania zaszyfrowanego ruchu między siecią wirtualną platformy Azure a alternatywną lokalizacją (taką jak lokalna) przez Internet. Usługa Azure VPN Gateway to zasób platformy Azure, który można wdrożyć w grupie zasobów wraz z kontem magazynu lub innymi zasobami platformy Azure. Bramy sieci VPN uwidaczniają dwa różne typy połączeń:
- Połączenia bramy sieci VPN typu punkt-lokacja (P2S), które są połączeniami sieci VPN między platformą Azure i pojedynczym klientem. To rozwiązanie jest szczególnie przydatne w przypadku urządzeń, które nie są częścią sieci lokalnej organizacji. Typowym przypadkiem użycia są osoby dojeżdżających do pracy telekomunikacyjnej, które chcą mieć możliwość zainstalowania udziału plików platformy Azure z domu, kawiarni lub hotelu w drodze. Aby użyć połączenia sieci VPN punkt-lokacja z usługą Azure Files, należy skonfigurować połączenie sieci VPN punkt-lokacja dla każdego klienta, który chce nawiązać połączenie. Zobacz Konfigurowanie sieci VPN typu punkt-lokacja (P2S) w systemie Windows do użycia z usługą Azure Files i Konfigurowanie sieci VPN typu punkt-lokacja (P2S) w systemie Linux do użycia z usługą Azure Files.
- Sieć VPN typu lokacja-lokacja (S2S), która jest połączeniami sieci VPN między platformą Azure i siecią organizacji. Połączenie sieci VPN S2S umożliwia skonfigurowanie połączenia sieci VPN raz dla serwera sieci VPN lub urządzenia hostowanego w sieci organizacji zamiast konfigurowania połączenia dla każdego urządzenia klienckiego, które musi uzyskać dostęp do udziału plików platformy Azure. Zobacz Konfigurowanie sieci VPN typu lokacja-lokacja (S2S) do użycia z usługą Azure Files.
- Usługa ExpressRoute, która umożliwia utworzenie zdefiniowanej trasy między platformą Azure i siecią lokalną, która nie przechodzi przez Internet. Ponieważ usługa ExpressRoute zapewnia dedykowaną ścieżkę między lokalnym centrum danych a platformą Azure, usługa ExpressRoute może być przydatna, gdy należy wziąć pod uwagę wydajność sieci. Usługa ExpressRoute jest również dobrym rozwiązaniem, gdy zasady lub wymagania prawne organizacji wymagają deterministycznej ścieżki do zasobów w chmurze.
Uwaga
Mimo że zalecamy używanie prywatnych punktów końcowych w celu ułatwienia rozszerzania sieci lokalnej na platformę Azure, technicznie możliwe jest kierowanie do publicznego punktu końcowego za pośrednictwem połączenia sieci VPN. Wymaga to jednak twardego kodowania adresu IP dla publicznego punktu końcowego klastra usługi Azure Storage obsługującego konto magazynu. Ponieważ konta magazynu mogą być przenoszone między klastrami magazynu w dowolnym momencie, a nowe klastry są często dodawane i usuwane, wymaga to regularnego kodowania wszystkich możliwych adresów IP usługi Azure Storage do reguł routingu.
Konfiguracja DNS
Podczas tworzenia prywatnego punktu końcowego domyślnie tworzymy również prywatną strefę DNS (lub aktualizując istniejącą) odpowiadającą privatelink poddomenie. Mówiąc ściśle, tworzenie prywatnej strefy DNS nie jest wymagane do korzystania z prywatnego punktu końcowego dla konta magazynu. Jednak jest to zdecydowanie zalecane ogólnie i jest jawnie wymagane podczas instalowania udziału plików platformy Azure za pomocą podmiotu zabezpieczeń użytkownika usługi Active Directory lub uzyskiwania do niego dostępu z interfejsu API FileREST.
Uwaga
W tym artykule jest używany sufiks DNS konta magazynu dla regionów publicznych platformy Azure. core.windows.net Ten komentarz dotyczy również chmur suwerennych platformy Azure, takich jak chmura platformy Azure DLA instytucji rządowych USA i platformy Microsoft Azure obsługiwanej przez chmurę 21Vianet — wystarczy zastąpić odpowiednie sufiksy dla danego środowiska.
W prywatnej strefie DNS utworzymy rekord A dla storageaccount.privatelink.file.core.windows.net i rekord CNAME dla regularnej nazwy konta magazynu, który jest zgodny ze wzorcem storageaccount.file.core.windows.net. Ponieważ prywatna strefa DNS platformy Azure jest połączona z siecią wirtualną zawierającą prywatny punkt końcowy, możesz obserwować konfigurację DNS, wywołując Resolve-DnsName polecenie cmdlet z programu PowerShell na maszynie wirtualnej platformy Azure (alternatywnie nslookup w systemach Windows i Linux):
Resolve-DnsName -Name "storageaccount.file.core.windows.net"
W tym przykładzie konto storageaccount.file.core.windows.net magazynu jest rozpoznawane jako prywatny adres IP prywatnego punktu końcowego, który ma wartość 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
Jeśli uruchomisz to samo polecenie ze środowiska lokalnego, zobaczysz, że ta sama nazwa konta magazynu jest rozpoznawana jako publiczny adres IP konta magazynu. Na przykład storageaccount.file.core.windows.net jest rekordem CNAME dla storageaccount.privatelink.file.core.windows.netelementu , który z kolei jest rekordem CNAME klastra usługi Azure Storage hostujące konto magazynu:
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
Odzwierciedla to fakt, że konto magazynu może uwidocznić zarówno publiczny punkt końcowy, jak i co najmniej jeden prywatny punkt końcowy. Aby upewnić się, że nazwa konta magazynu jest rozpoznawana jako prywatny adres IP prywatnego punktu końcowego, należy zmienić konfigurację na lokalnych serwerach DNS. Można to zrobić na kilka sposobów:
- Modyfikowanie pliku hostów na klientach w celu
storageaccount.file.core.windows.netrozpoznania adresu IP żądanego prywatnego punktu końcowego. Jest to zdecydowanie odradzane w środowiskach produkcyjnych, ponieważ należy wprowadzić te zmiany do każdego klienta, który chce zainstalować udziały plików platformy Azure, a zmiany na koncie magazynu lub prywatnym punkcie końcowym nie będą automatycznie obsługiwane. - Tworzenie rekordu A dla
storageaccount.file.core.windows.netw lokalnych serwerach DNS. Ma to zaletę, że klienci w środowisku lokalnym będą mogli automatycznie rozpoznawać konto magazynu bez konieczności konfigurowania każdego klienta. Jednak to rozwiązanie jest podobnie kruche, aby zmodyfikować plik hostów , ponieważ zmiany nie są odzwierciedlane. Chociaż to rozwiązanie jest kruche, może to być najlepszy wybór dla niektórych środowisk. - Przekaż strefę
core.windows.netz lokalnych serwerów DNS do prywatnej strefy DNS platformy Azure. Prywatny host DNS platformy Azure można uzyskać za pośrednictwem specjalnego adresu IP (168.63.129.16), który jest dostępny tylko w sieciach wirtualnych połączonych z prywatną strefą DNS platformy Azure. Aby obejść to ograniczenie, możesz uruchomić dodatkowe serwery DNS w sieci wirtualnej, które będą przekazywanecore.windows.netdo prywatnej strefy DNS platformy Azure. Aby uprościć tę konfigurację, udostępniliśmy polecenia cmdlet programu PowerShell, które będą automatycznie wdrażać serwery DNS w sieci wirtualnej platformy Azure i konfigurować je zgodnie z potrzebami. Aby dowiedzieć się, jak skonfigurować przekazywanie DNS, zobacz Konfigurowanie usługi DNS przy użyciu usługi Azure Files.
Komunikacja SMB przez protokół QUIC
System Windows Server 2022 Azure Edition obsługuje nowy protokół transportowy o nazwie QUIC dla serwera SMB udostępnionego przez rolę serwera plików. QUIC to zamiennik protokołu TCP, który jest oparty na UDP, zapewniając wiele zalet w porównaniu z protokołem TCP, jednocześnie zapewniając niezawodny mechanizm transportu. Jedną z kluczowych zalet protokołu SMB jest to, że zamiast używać portu 445, cały transport odbywa się za pośrednictwem portu 443, który jest powszechnie otwarty dla obsługi protokołu HTTPS. Oznacza to, że protokół SMB over QUIC oferuje "SMB VPN" do udostępniania plików za pośrednictwem publicznego Internetu. System Windows 11 jest dostarczany z klientem obsługującym protokół SMB za pośrednictwem interfejsu QUIC.
Obecnie usługa Azure Files nie obsługuje bezpośrednio protokołu SMB za pośrednictwem pliku QUIC. Jednak dostęp do udziałów plików platformy Azure można uzyskać za pośrednictwem usługi Azure File Sync uruchomionej w systemie Windows Server, jak pokazano na poniższym diagramie. Zapewnia to również możliwość buforowania usługi Azure File Sync zarówno lokalnie, jak i w różnych centrach danych platformy Azure w celu zapewnienia lokalnych pamięci podręcznych dla rozproszonej siły roboczej. Aby dowiedzieć się więcej na temat tej opcji, zobacz Deploy Azure File Sync and SMB over QUIC (Wdrażanie usługi Azure File Sync i protokołu SMB za pośrednictwem rozwiązania QUIC).
