Udostępnij za pomocą

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średni dostęp do zasobu plikowego w Azure często wymaga dodatkowego myślenia w kontekście sieci.

  • Udziały plików SMB komunikują się za pośrednictwem portu 445, który wiele organizacji i dostawców usług internetowych (ISP) blokuje dla ruchu wychodzącego (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 zasobu 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 zasobu 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 magazynowe to struktura zarządzania, która reprezentuje wspólną pulę zasobów magazynowych, w której można wdrożyć wiele udziałów plikowych Azure, a także zasoby magazynowe dla innych usług Azure, takich jak kontenery obiektów blob lub kolejki.

Ten film jest przewodnikiem i pokazem dotyczącym bezpiecznego udostępniania plików w usłudze Azure bezpośrednio dla użytkowników i aplikacji 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. Więcej informacji można znaleźć w sekcji Nowa nazwa usługi Azure AD.

Odnosi się do

Typ współdzielenia plików SMB NFS
Standardowe udostępnianie plików (GPv2), LRS/ZRS Tak Nie.
Udziały plików standardowe (GPv2), GRS/GZRS Tak Nie.
Premiumowe udostępnienia plików (FileStorage), LRS/ZRS Tak Tak

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 Wymagany bezpieczny transfer jest wymuszane dla wszystkich protokołów dostępu do danych przechowywanych w udziałach plików platformy Azure, w tym SMB, NFS i FileREST. Możesz wyłączyć ustawienie Wymagany bezpieczny transfer , aby zezwolić na niezaszyfrowany ruch.

Protokoły SMB, NFS i FileREST mają nieco inne zachowanie w odniesieniu do ustawienia Wymagany bezpieczny transfer :

  • Jeśli wymagany jest bezpieczny transfer na koncie magazynu, wszystkie udziały plików SMB w 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 Wymagany bezpieczny transfer umożliwia instalowanie protokołu SMB 2.1 i SMB 3.x bez szyfrowania.

  • Udziały plików platformy Azure NFS używają pakietu narzędzi AZNFS, aby uprościć zaszyfrowane instalacje, instalując i konfigurując stunnel (otokę PROTOKOŁU TLS typu open source) na kliencie. Zobacz Szyfrowanie w transporcie dla udziałów plików NFS Azure.

  • Gdy wymagany jest bezpieczny transfer, protokół FileREST może być używany tylko z protokołem HTTPS.

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. Użytkownicy, którzy wolą zachować elastyczność między połączeniami TLS a połączeniami bez TLS na tym samym koncie magazynowym, powinni wyłączyć Wymaganie bezpiecznego przesyłu.

Publiczny punkt końcowy

Publiczny punkt końcowy udziałów plików Azure w ramach konta magazynu jest uwidocznionym w internecie punktem końcowym. Publiczny punkt końcowy jest domyślnym punktem końcowym dla konta magazynowego, 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 magazynowego 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:

    1. Ustawienie Wymagany bezpieczny transfer na koncie magazynowym powinno być wyłączone.
    2. Żą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. Zobacz ustawienia zapory punktu końcowego publicznego dla dodatkowych informacji na temat punktów końcowych usługi.

  • FileREST 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 sieciowej punktu końcowego publicznego

Zapora konta przechowywania ogranicza dostęp do publicznego punktu końcowego dla konta przechowywania. 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 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, udziały plików NFS można jednak uzyskać tylko poprzez publiczny punkt końcowy za pomocą punktu końcowego usługi.

Aby dowiedzieć się więcej na temat konfigurowania zapory sieciowej konta magazynu, zobacz Konfigurowanie zapór sieciowych 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. Gdy tworzysz prywatny punkt końcowy dla swojego konta magazynu, konto to otrzymuje prywatny adres IP z przestrzeni adresowej twojej sieci wirtualnej, podobnie jak serwer plików lub urządzenie NAS w lokalnej sieci otrzymuje adres IP wewnątrz dedykowanej przestrzeni adresowej twojej sieci lokalnej.

Pojedynczy prywatny punkt końcowy jest skojarzony z określoną podsiecią sieci wirtualnej platformy Azure. Konto magazynowe może mieć prywatne punkty końcowe w więcej niż jednej sieci wirtualnej.

Używanie prywatnych punktów końcowych z usługą Azure Files umożliwia:

  • 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, czyli VNet, jest podobna do tradycyjnej sieci stacjonarnej. 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 oraz serwerami a udziałami plików SMB/NFS w 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 magazynowym lub innymi zasobami Azure. Bramy sieci VPN uwidaczniają dwa różne typy połączeń:
  • 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 ręcznego przypisania adresu IP dla publicznego punktu końcowego klastra Azure Storage, który obsługuje twoje konto magazynowe. 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 magazynowego. Jednak zdecydowanie zaleca się to w sposób ogólny i jest to wyraźnie wymagane podczas zestawiania udziału plików platformy Azure za pomocą jednostki użytkownika usługi Active Directory lub uzyskiwania dostępu do udziału z interfejsu API FileREST.

Uwaga

W tym artykule używany jest sufiks DNS dla konta magazynu dla publicznych regionów 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 przechowywania, zgodnej 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 magazynowe storageaccount.file.core.windows.net odnosi się do prywatnego adresu IP prywatnego punktu końcowego, którym jest 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 elementu storageaccount.privatelink.file.core.windows.net, który z kolei jest rekordem CNAME klastra usługi Azure Storage, który hostuje 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.net rozpoznania 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 zamontować udziały plików platformy Azure, a zmiany dotyczące konta magazynu lub prywatnego punktu końcowego nie będą automatycznie obsługiwane.
  • Tworzenie rekordu A dla storageaccount.file.core.windows.net w lokalnych serwerach DNS. Ma to zaletę, że klienci w środowisku lokalnym będą mogli automatycznie rozwiązywać konto magazynowe bez konieczności konfigurowania każdego klienta. Jednak to rozwiązanie jest równie mało odporne, jak modyfikacja pliku hosts, 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.net z 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ą przekazywane core.windows.net do 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.

SMB over QUIC (protokół dla udostępniania plików z użyciem 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 pomocą 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).

Diagram tworzenia uproszczonej pamięci podręcznej udziałów plików platformy Azure w systemie Windows Server 2022 Azure Edition V M przy użyciu usługi Azure File Sync.

Zobacz też

  • Last updated on