Azure Files zagadnienia dotyczące sieci

✔️ Dotyczy: Wszystkich udziałów plikowych Azure

Ten artykuł opisuje decyzje sieciowe, które należy podjąć przed wdrożeniem Azure Files: jak chronić dane podczas transportu, jak klienci łączą się z udziałem plików oraz jak kontrolować dostęp przychodzący i wychodzący. Aby uzyskać informacje o krokach konfiguracji, zobacz Konfigurowanie punktów końcowych sieci dla udziałów plików platformy Azure. Inne decyzje dotyczące wdrożenia znajdziesz w artykule Planowanie wdrożenia usługi Azure Files.

Dostępne opcje zależą od dostawcy zasobów, którego używasz do tworzenia udziału plików, oraz od protokołu, z którego korzystają klienci. Klasyczne udziały plików (Microsoft.Storage) wspierają SMB, NFS i FileREST. Udostępnienia plików utworzone przez Microsoft.FileShares obsługują tylko NFS. Inne różnice między dostawcami zasobów znajdziesz w koncepcjach zarządzania Azure Files.

Poniższa tabela pokazuje, jak klienci mogą uzyskać dostęp do udziału plików, według lokalizacji klienta i protokołu:

• Protokół SMB komunikuje się za pośrednictwem portu TCP 445. Niektóre organizacje i dostawcy usług internetowych blokują ruch wychodzący przez ten port. Klienci, którzy nie mogą korzystać z portu 445, mogą łączyć się przez VPN lub ExpressRoute, albo korzystać z SMB przez QUIC przez Azure File Sync.
• NFS korzysta z uwierzytelniania sieciowego, więc nie obsługuje dostępu z Internetu.

Szyfrowanie podczas transferu

Szyfrowanie w trakcie transmisji chroni dane między klientami a Azure Files przed przechwyceniem i modyfikacją, w tym ze strony atakującego typu man-in-the-middle. Dotyczy to ruchu zarówno przez publiczne, jak i prywatne punkty końcowe.

• SMB: SMB 3.x chroni dane poprzez szyfrowanie kanałów SMB. Azure Files obsługuje AES-128-CCM z SMB 3.0 oraz AES-128-GCM i AES-256-GCM z SMB 3.1.1. Klient i usługa negocjują algorytm spośród algorytmów obsługiwanych przez obie strony. SMB 2.1 nie obsługuje szyfrowania kanałów. Jeśli ograniczysz dozwolone algorytmy, niektórzy klienci nie mogą się połączyć. Na przykład starsi klienci Windows nie obsługują AES-256-GCM.
• NFS: Udostępnienia plików NFS u jednego z dwóch dostawców zasobów wspierają szyfrowanie podczas przesyłania przez tunel TLS. Pomocnik montowania AzNFS wykorzystuje stunnel do przesyłania ruchu NFS przez połączenie TLS 1.2 lub TLS 1.3 oraz weryfikuje certyfikat serwera. Aplikacje korzystają z protokołu NFS bez zmian. TLS nie dodaje do NFS uwierzytelniania opartego na użytkowniku.
• FileREST: FileREST chroni dane przesyłane przez HTTPS, z TLS 1.2 lub TLS 1.3. Nowe konta pamięci masowej domyślnie wymagają HTTPS i odrzucają nieszyfrowane żądania HTTP. Pozostaw ten wymóg włączony. Możesz też ustawić minimalną wersję TLS.

Wymagania dotyczące szyfrowania i domyślne ustawienia zależą od dostawcy zasobów. Aby je zobaczyć i zmienić, zobacz:

• Klasyczne udostępnienia plików: Konfiguruj szyfrowanie w tranzycie dla Azure Files. Aby ograniczyć algorytmy szyfrowania SMB, zobacz Ustawienia bezpieczeństwa SMB. Aby zamontować udział plików NFS z szyfrowaniem, zobacz: Zamontuj klasyczny udział plików NFS za pomocą programu pomocniczego instalacji AzNFS.
• Microsoft.FileShares: Wymagania dotyczące szyfrowania przy tworzeniu udziału plików oraz aktualizacja właściwości udziału plików za pomocą PowerShell lub Azure CLI.

Ścieżki połączeń

Klient uzyskuje dostęp do udziału plików przez publiczny punkt końcowy lub przez prywatny punkt końcowy. Oba punkty końcowe używają tej samej nazwy hosta. Rezolucja DNS decyduje, którego endpointa używa klient.

Publiczny punkt końcowy

Publiczny punkt końcowy ma publiczny adres IP. Adres publiczny nie oznacza nieograniczonego dostępu: wymagania protokołu, kontrola dostępu przychodzącego i autoryzacja decydują o tym, czy żądanie jest dozwolone.

Każdy protokół ma własne ograniczenia dostępu do publicznych punktów końcowych, oddzielne od reguł sieciowych, które konfigurujesz:

• SMB: Zaszyfrowane połączenia SMB 3.x mogą pochodzić od klientów wewnątrz lub spoza Azure. Azure Files ogranicza je tylko poprzez uwierzytelnianie i autoryzację. Nieszyfrowane połączenia SMB są ograniczone do klientów w tym samym regionie Azure i wymagają konfiguracji umożliwiającej dostęp bez szyfrowania. Klienci z tego regionu spoza Twoich sieci wirtualnych również mogą się łączyć. Jeśli zezwalasz na nieszyfrowane SMB, ogranicz publiczny punkt końcowy, stosując reguły sieciowe.
• NFS: Klienci mogą uzyskać dostęp do publicznego punktu końcowego tylko przez punkt końcowy usługi. Reguły sieciowe udziału plików muszą zezwalać na podsieć klienta. NFS nie obsługuje bezpośredniego dostępu z klientów internetowych.
• FileREST: Żądania mogą pochodzić od klientów zarówno wewnątrz, jak i spoza Azure. Azure Files ogranicza je wyłącznie za pomocą uwierzytelniania i autoryzacji. Domyślnie Azure Files również odrzuca nieszyfrowane żądania HTTP.

Punkty końcowe usługi

Punkt końcowy usługi pozwala klientom w podsieci sieci wirtualnej korzystać z publicznego punktu końcowego, gdy reguły sieciowe ograniczają go do wybranych podsieci. Ruch z podsieci trafia do Azure Files przez szkielet Azure, ale nadal korzysta z adresu IP publicznego endpointu. Warstwa sieciowa identyfikuje źródłową podsieć tego ruchu, dzięki czemu Azure Files może sprawdzić podsieć względem reguł sieciowych. Aby umożliwić podsieć, należy dodać dla niej regułę sieci wirtualnej.

Routing sieci publicznego punktu końcowego

Preferencja routowania jest dostępna tylko dla klasycznych udostępnień plików HDD, które korzystają z modelu pay-as-you-go w StorageV2 kontach magazynowych. Nie jest obsługiwany dla aprowizowanych udziałów plików w kontach magazynu FileStorage ani dla Microsoft.FileShares.

W przypadku tych kont pay-as-you-go preferencja routingu decyduje o tym, jak ruch internetowy dociera do publicznego punktu końcowego:

• Routing Microsoft (domyślne): Ruch między klientem a kontem magazynu odbywa się przez globalną sieć szkieletową firmy Microsoft tak długo, jak to możliwe, zanim trafi do Internetu. Ta opcja obsługuje scenariusze łączenia domeny Active Directory (AD) oraz synchronizację Azure File Sync.
• Routing internetowy: Ruch trafia przez publiczny internet jak najwcześniej. Ta opcja nie obsługuje scenariuszy łączenia domen AD ani Azure File Sync.

Aby sprawdzić lub zmienić preferencje routingu, zobacz Konfigurowanie preferencji routingu.

Prywatne punkty końcowe

Prywatny punkt końcowy nadaje zasobowi (kontu magazynu lub udziałowi plików Microsoft.FileShares) prywatny adres IP w podsieci Twojej sieci wirtualnej. Klienci mogą dotrzeć do tego adresu z tej samej sieci wirtualnej, z połączonych sieci wirtualnych oraz z sieci lokalnych łączących się z siecią wirtualną przez VPN lub ExpressRoute. Aby uzyskać dostęp z większej liczby sieci wirtualnych, możesz stworzyć więcej niż jeden prywatny punkt końcowy dla tego samego zasobu.

Publiczny endpoint pozostaje dostępny po utworzeniu prywatnego endpointu. Aby umożliwić dostęp tylko przez prywatne punkty końcowe, wyłącz dostęp do sieci publicznej. Prywatny endpoint nie ogranicza też miejsc, gdzie klienci mogą wysyłać ruch. Informacje o tych kontrolach znajdziesz w Kontrola dostępu wychodzącego.

Aby utworzyć prywatny punkt końcowy, zobacz Tworzenie prywatnego punktu końcowego.

Połącz ze środowiska lokalnego

Klienci w środowisku lokalnym mogą dotrzeć do prywatnego punktu końcowego przez VPN lub prywatne połączenie peeringowe ExpressRoute. To podejście dotyczy zarówno SMB, jak i NFS. Klienci SMB i FileREST mogą również dotrzeć do publicznego endpointu przez internet lub peering ExpressRoute Microsoft. Jeśli reguły sieciowe ograniczają publiczny punkt końcowy, dodaj regułę adresu IP dla publicznych adresów IP klientów.

W przypadku SMB połączenie z publicznym punktem końcowym często nie działa w sieciach lokalnych w środowisku lokalnym. To ograniczenie występuje, ponieważ SMB korzysta z portu TCP 445, a wiele organizacji i dostawców usług internetowych blokuje ruch wychodzący na tym porcie. Połączenie VPN lub ExpressRoute przenosi ruch SMB do prywatnego punktu końcowego wewnątrz połączenia, więc blokada nie ma zastosowania. W przypadku lokalnych klientów SMB zaplanuj prywatny punkt końcowy z połączeniem VPN lub ExpressRoute, chyba że potwierdzisz, że Twoja sieć zezwala na wychodzący ruch TCP na porcie 445 do platformy Azure.

Następujące opcje łączą klientów lokalnych z Azure:

• VPN punkt-to-site: Łączy pojedynczego klienta z wirtualną siecią Azure. Obsługuje użytkowników zdalnych oraz urządzenia, które nie są połączone przez sieć lokalizacji organizacji. Kroki konfiguracji znajdziesz w artykule Konfiguruj ustawienia serwera dla uwierzytelniania certyfikatu VPN Gateway P2S.

• Sieć VPN typu lokacja-lokacja: Łączy sieć organizacji z wirtualną siecią Azure za pośrednictwem bramy VPN. Klienci w połączonej sieci dzielą to połączenie. Szczegóły dotyczące konfiguracji zobacz Tutorial: Create a site-to-site VPN connection w portalu Azure.

• ExpressRoute: Prywatny peering łączy sieć lokalną z sieciami wirtualnymi Azure bez konieczności korzystania z publicznego internetu. ExpressRoute domyślnie nie szyfruje ruchu. Używaj szyfrowania danych podczas przesyłania, aby chronić dane pliku na połączeniu. Opcje łączności znajdziesz w artykule Co to jest Azure ExpressRoute?.

• SMB przez QUIC: Przenosi ruch SMB przez port UDP 443, więc działa, gdy port TCP 445 jest zablokowany. Azure Files nie obsługuje SMB bezpośrednio przez QUIC. Klienci łączą się z pamięcią podręczną klasycznego udziału plików SMB w systemie Windows Server, a Azure File Sync utrzymuje pamięć podręczną w synchronizacji z udziałem plików. Pamięć podręczna może być lokalna lub w Azure. Serwer pamięci podręcznej zapewnia punkt końcowy QUIC, a klienci potrzebują obsługi SMB przez QUIC. Więcej informacji można znaleźć w SMB over QUIC w dokumentacji Windows Server oraz SMB over QUIC dla Azure File Sync.

  Poniższy diagram pokazuje SMB przez QUIC z pamięcią podręczną Azure File Sync:

  

Aby skonfigurować dostęp dla klientów lokalnych przez prywatny punkt końcowy, należy postępować zgodnie z następującymi krokami:

1. Stwórz prywatny punkt końcowy dla udziału plików. Zobacz Tworzenie prywatnego punktu końcowego.
2. Połącz sieć lokalną lub klienta z wirtualną siecią prywatnego punktu końcowego za pomocą jednej z opcji z poprzedniej listy.
3. Skonfiguruj system DNS tak, aby klienci w środowisku lokalnym rozpoznawali nazwę hosta udziału plików jako adres IP prywatnego punktu końcowego. Zobacz Konfigurowanie przekazywania DNS dla usługi Azure Files. Klienci punkt-to-site mogą nie korzystać z lokalnych serwerów DNS. Dla tych klientów dodaj serwer przekazujący DNS lub resolver jako niestandardowy serwer DNS w kliencie VPN. Zobacz opcjonalne ustawienia klienta VPN Azure.
4. Sprawdź, czy nazwa hosta rozwiązuje się na adres IP prywatnego punktu końcowego. Zobacz Sprawdź, czy przekazywanie DNS działa.
5. Zamontuj udział sieciowy. Zobacz Instalowanie udziału plików SMB platformy Azure w systemie Windows, Instalowanie udziału plików platformy Azure w systemie macOS, Instalowanie udziałów plików SMB platformy Azure na klientach systemu Linux lub Instalowanie udziałów plików NFS platformy Azure w systemie Linux.

Rozwiązanie DNS

Klienci używają tej samej nazwy hosta dla publicznego endpointu i dla prywatnego endpointu. DNS określa, na który adres IP rozwiązuje się nazwa hosta.

• Klasyczne udostępnienia plików: Nazwa hosta to <storage-account-name>.file.core.windows.net.
• Microsoft.FileShares: Każdy udział plików ma własną wygenerowaną nazwę hosta we właściwości hostName udziału plików. Nazwa hosta jest oddzielna od nazwy zasobu udziału plików oraz od nazwy punktu instalacji.

Gdy tworzysz prywatny punkt końcowy, publiczny rekord DNS dla nazwy hosta staje się aliasem (CNAME) dla nazwy w strefie privatelink.file.core.windows.net. Klienci w sieci wirtualnej powiązanej z prywatną strefą DNS o tej nazwie rozwiązują alias na adres IP prywatnego punktu końcowego. Inni klienci rozwiązują alias do publicznego adresu IP punktu końcowego. Aby utworzyć prywatną strefę DNS z prywatnym punktem końcowym, zobacz Tworzenie prywatnego punktu końcowego. Aby sprawdzić wynik, zobacz Weryfikacja łączności.

Klienci lokalni nie używają domyślnie Azure DNS, więc samo połączenie VPN lub ExpressRoute nie daje im prywatnego rozwiązywania nazw DNS. Przekieruj ich zapytania DNS dotyczące domeny udziału plików do Azure przez Azure DNS Private Resolver lub wirtualną maszynę do przekazywania DNS. Kroki można znaleźć w artykule Configure DNS forwarding for Azure Files. Aby poznać inne projekty DNS w środowisku lokalnym, zobacz Integracja DNS usługi Azure Private Endpoint.

Nazwy hostów i stref w tej sekcji dotyczą publicznej chmury Azure. Inne chmury Azure korzystają z innej domeny, na przykład core.usgovcloudapi.net w Azure Government. Aby uzyskać nazwy prywatnych stref DNS w każdej chmurze, zobacz wartości stref prywatnych DNS w Azure Private Endpoint.

Kontrola dostępu dla ruchu przychodzącego

Mechanizmy kontroli dostępu przychodzącego decydują, którzy klienci mogą uzyskać dostęp do udziału plików:

• Ruch prywatnych punktów końcowych dostępu nie podlega ustawieniu dostępu do sieci publicznej, regułom sieciowym ani granicom zabezpieczeń sieci.
• Ruch na publicznym punkcie końcowym musi być zgodny z ustawieniem dostępu do sieci publicznej. Jeśli konto pamięci jest powiązane z perymetrem zabezpieczeń sieciowych, zasady dostępu tego perymetru mają pierwszeństwo przed regułami sieci. W przeciwnym razie o dostępie decydują reguły sieci.
• Autoryzacja dotyczy każdego żądania docierającego do udziału plików przez dowolny punkt końcowy.

Dostęp do sieci publicznej

Możesz wyłączyć dostęp do sieci publicznej lub zostawić go włączonego i ograniczyć za pomocą reguł sieciowych. Wyłączenie dostępu do sieci publicznej uniemożliwia również dostęp klienta przez punkty końcowe usługi. Prywatny dostęp do punktów końcowych jest niezależny od tego ustawienia. W przypadku klasycznych udostępnień plików istniejące wyjątki zaufanych usług i instancji zasobów pozostają w mocy po wyłączeniu dostępu do sieci publicznej.

Kroki konfiguracji dla obu dostawców zasobów znajdziesz w artykule Ogranicz dostęp do publicznych punktów końcowych.

Reguły sieci

Reguły sieciowe decydują, które klienty mogą dotrzeć do publicznego punktu końcowego. Istnieją dwa rodzaje:

• Reguły sieci wirtualnej pozwalają klientom w podsieci, która posiada punkt końcowy usługi. Obaj dostawcy zasobów obsługują reguły sieci wirtualnej. Klienci NFS potrzebują punktu końcowego usługi, więc za pomocą reguł sieci wirtualnej zezwalasz im na dostęp.
• Reguły adresów IP umożliwiają zezwalanie klientom na podstawie publicznego adresu IP. Tylko klasyczne udostępnienia plików obsługują reguły adresów IP, zarówno dla SMB, jak i FileREST.

Reguły sieciowe dotyczą dostępu do danych przez SMB, NFS i FileREST. Nie dotyczą one operacji zarządzania przez Azure Resource Manager, takich jak tworzenie udziału plików czy zmiana jego właściwości. Podczas przeglądania danych plików w portalu Azure przeglądarka wysyła żądania FileREST do punktu końcowego usługi plików, więc reguły sieciowe muszą zezwalać na dostęp z Twojego komputera. Aby uzyskać uprawnienia, których wymaga przeglądanie portalu, zobacz Autoryzuj dostęp do danych plików w portalu Azure.

Reguły sieci wirtualnej

Reguła sieci wirtualnej pozwala na ruch z podsieci, która ma punkt końcowy usługi Microsoft.Storage lub Microsoft.Storage.Global. Zarówno dostawcy zasobów Microsoft.Storage (konta pamięci masowej), jak i Microsoft.FileShares używają tych nazw punktów końcowych usługi. Należy pamiętać o następujących kwestiach:

• Podsieć może znajdować się w innym regionie niż zasób. Aby uzyskać dostęp z innych regionów, użyj punktu końcowego usługi Microsoft.Storage.Global. Podsieć może mieć tylko jeden z tych dwóch punktów końcowych usługi.
• Podsieć może być w innej subskrypcji lub w dzierżawie Microsoft Entra. Aby dodać podsieć z innego tenanta, użyj Azure PowerShell lub Azure CLI. Portal Azure nie pokazuje podsieci w innych tenantach.
• Każdy zasób obsługuje do 400 reguł sieci wirtualnej. Aby dodać regułę, potrzebujesz uprawnienia Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action do podsieci.
• Usunięcie podsieci usuwa ją z reguł sieciowych konta magazynowego. Nowa podsieć o tej samej nazwie nie dostaje dostępu, dopóki nie dodasz jej do reguł sieciowych. (Tylko klasyczne udostępnienia plików.)
• Jeśli planujesz przełączenie awaryjne georedundantnego konta magazynu, stwórz sieci wirtualne w regionie drugorzędnym, zanim będą potrzebne. Dodaj reguły sieci wirtualnych dla ich podsieci, aby klienci w tych sieciach mogli się łączyć po przełączeniu awaryjnym. (Tylko klasyczne udostępnienia plików.)

Reguły adresu IP

Klasyczne udostępnienia plików obsługują reguły adresów IP dla dostępu SMB i FileREST z internetu. Microsoft.FileShares nie obsługuje reguł dotyczących adresów IP. Należy pamiętać o następujących kwestiach:

• Reguły adresów IP akceptują wyłącznie publiczne adresy IPv4. Nie można dodawać prywatnych zakresów adresów, takich jak adresy zaczynające się od 10, 172.16 do 172.31 czy 192.168.
• Określ zakresy adresów w notacji CIDR, taką jak 203.0.113.0/24. Zakresy z prefiksem /31 lub /32 nie są obsługiwane. Dodaj te adresy jako indywidualne reguły adresów IP.
• Reguły adresów IP nie mają wpływu na żądania pochodzące od klientów w tym samym regionie Azure co konto pamięci masowej ani od klientów w podsieci, która ma punkt końcowy usługi. Dla tych klientów używaj reguł sieci wirtualnych. Wyjątkiem jest reguła dotycząca adresu IP standardowego punktu końcowego usługi.
• Konto pamięci masowej obsługuje do 400 reguł adresów IP.
• Aby umożliwić klientom w sieci lokalnej, należy dodać publiczne adresy IP, których sieć używa do ruchu internetowego. Jeśli używasz Azure ExpressRoute z peeringiem Microsoft, dodaj adresy IP translacji adresów sieciowych (NAT), których używa peering Microsoft.

Wyjątki dla usług Azure

W przypadku klasycznych udostępnień plików możesz pozwolić na usługi Azure, które nie mogą korzystać z reguł sieci wirtualnej lub adresów IP:

• Zaufane usługi: Wyjątek Zezwalaj zaufanym usługom Microsoft na dostęp do tego zasobu umożliwia korzystanie z usług takich jak Azure File Sync. Włączaj go tylko wtedy, gdy wymaga tego integracja. Listę usług można znaleźć w Trusted Azure services.
• Instancje zasobów: Reguła instancji zasobów pozwala konkretnemu zasobowi Azure w Twojej dzierżawie Microsoft Entra dotrzeć do publicznego punktu końcowego. Zasób nadal wymaga autoryzacji do dostępu do danych plików.

Perymetr zabezpieczeń sieci to nowszy sposób umożliwiający usługom Azure dostęp. Kontroluje dostęp do wielu zasobów w jednym miejscu. Zalecamy wyznaczenie granicy, gdy usługi, z których Państwo korzystają, są do niej dołączane. Takie wyjątki mogą być nadal potrzebne dla usług, które nie są objęte, takich jak Azure Backup, lub jeśli nie używasz perymetru.

Microsoft. FileShares nie obsługuje tych wyjątków.

Obwód zabezpieczeń sieci

Perymetr bezpieczeństwa sieciowego umieszcza zasoby PaaS wewnątrz logicznej granicy i kontroluje publiczny dostęp sieciowy do nich. Tylko klasyczne udziały plików obsługują granice zabezpieczeń sieci.

Gdy przypisujesz konto magazynu do perymetru, reguły dostępu w profilu perymetru nadpisują zasady sieciowe konta magazynu. Strefa ma dwa tryby dostępu:

• Tryb przejścia: Domyślny tryb. Jeśli żadna reguła obwodu nie zezwala na połączenie, obowiązują własne reguły sieciowe konta pamięci masowej i wyjątki dla usług platformy Azure. Korzystając z logów diagnostycznych, możesz znaleźć ruch, na który nie zezwalają reguły obwodowe. Tryb Transition używaj tylko jako tymczasowego kroku.
• Wymuszane: Obowiązują tylko reguły obwodu. Reguły sieci wirtualnej, reguły adresów IP oraz wyjątki dla usług platformy Azure dla konta magazynu nie mają zastosowania. Aby umożliwić usłudze Azure, która nie jest dołączona do granicy zabezpieczeń sieci, dodaj regułę dostępu przychodzącego opartą na subskrypcji.

Strefa ochrony decyduje, którzy klienci mogą dotrzeć do konta magazynu przez publiczny punkt końcowy. Umożliwia klientom działanie na dwa sposoby:

• Zasób do zasobu: Inne zasoby PaaS na obwodzie oraz zasoby Azure w subskrypcjach, do których dostęp zezwala przychodząca reguła oparta na subskrypcji. Perimetr identyfikuje tych klientów na podstawie ich tożsamości Microsoft Entra, którą posiadają tylko żądania OAuth. Dla Azure Files ten dostęp dotyczy tylko FileREST z OAuth.
• Klienci według adresu IP: Przychodzące reguły oparte na adresach IP zezwalają klientom na podstawie ich publicznego adresu IP.
  • Klienci w sieciach wirtualnych Azure łączą się przez standardowy punkt końcowy usługi. Reguła oparta na IP dla adresu IP punktu końcowego usługi zezwala na dostęp SMB, NFS i FileREST. W trybie wymuszonym perymetr odmawia ruchu przez punkty końcowe usług, które nie mają przypisanego adresu IP.
  • Klienci spoza platformy Azure łączą się ze swojego publicznego adresu IP. Reguła oparta na IP dla tego adresu pozwala na SMB i FileREST. NFS nie obsługuje klientów poza Azure.

Ruch prywatnego punktu końcowego nie podlega regułom perymetru.

Poniższa tabela pokazuje, które reguły przychodzące mają zastosowanie do każdego protokołu i metody uwierzytelniania:

Sprawdź te integracje, zanim połączysz konto pamięci z perymetrem:

• Klucze zarządzane przez klienta: Jeśli sejf kluczy, w którym jest przechowywany klucz zarządzany przez klienta, znajduje się w perymetrze, umieść konto magazynowe w tym samym perymetrze. W przeciwnym razie skonfiguruj profil granicy magazynu kluczy, aby zezwolić na dostęp konta magazynu.
• Azure Backup: Azure Backup nie został wdrożony do obwodu zabezpieczeń sieci. Nie używaj obwodu dla kont pamięci masowej, które korzystają z Azure Backup.
• Azure File Sync: Nie możesz powiązać usługi synchronizacji pamięci z granicą sieci. Skonfiguruj usługę Storage Sync Service tak, aby używała zarządzanych tożsamości. Następnie dodaj przychodzącą regułę dostępu opartą na subskrypcji, która zezwala na dostęp usłudze Storage Sync Service.

Aby powiązać perymetr z kontem magazynu, zobacz Przejście do perymetru zabezpieczeń sieci w Azure.

Standardowe punkty końcowe usług

Standardowy punkt końcowy usługi to punkt końcowy usługi, któremu przypisano publiczny adres IP. Tworzysz publiczny adres IP i przypisujesz go do punktu końcowego usługi Microsoft.Storage podsieci. Azure Storage wykorzystuje ten adres do identyfikacji ruchu z podsieci. Adres tylko etykietuje ruch. Ruch nie jest przez niego kierowany, a klienci z niego nie korzystają, więc publiczny adres IP klienta nie może go zastąpić. Dokumentacja sieci Azure nazywa ten adres identyfikatorem sieciowym, a punkt końcowy usługi bez niego nazywa punktem końcowym usługi podstawowym.

Standardowe punkty końcowe usługi pozwalają klientom w sieciach wirtualnych uzyskać dostęp do konta pamięci masowej w granicy zabezpieczeń sieci bez prywatnego punktu końcowego. Aby je umożliwić, dodaj do profilu perymetru regułę przychodzącego dostępu opartą na adresie IP dla adresu IP punktu końcowego usługi. Reguła pozwala na ruch SMB, NFS i FileREST z każdej podsieci korzystającej z adresu IP. Jeden adres IP może reprezentować wiele podsieci i sieci wirtualnych w tym samym regionie, w tym sieci wirtualne w innych subskrypcjach w tej samej dzierżawie Microsoft Entra. Gdy dodajesz lub usuwasz podsieci korzystające z adresu IP, nie musisz zmieniać reguł perymetru.

Reguły adresów IP konta magazynu mogą również zezwalać na adres IP punktu końcowego usługi bez granicy perymetru. Bez perymetru podstawowy punkt końcowy usługi z regułami sieci wirtualnej zapewnia ten sam dostęp bez dodatkowych opłat.

Należy pamiętać o następujących kwestiach:

• Standardowy punkt końcowy usługi nadal identyfikuje źródłową podsieć. Reguły sieci wirtualnej zezwalające podsieci nadal obowiązują po przypisaniu adresu IP, aż do momentu, gdy perymetr jest w trybie wymuszonym.
• Przypisanie lub zmiana adresu IP resetuje aktywne połączenia z podsieci. Zaplanuj zmianę na czas okna konserwacyjnego.
• Standardowe punkty końcowe usług nie obsługują ruchu z sieci lokalnych. Do dostępu lokalnego używaj prywatnego endpointu .
• Standardowe punkty końcowe usług to płatna funkcja, za którą opłata jest naliczana za każdą sieć wirtualną. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Private Link.

Klienci w podsieci, która ma standardowy punkt końcowy usługi, nadal mogą uzyskać dostęp do udziału plików Microsoft.FileShares, jeśli podsieć znajduje się w dozwolonych podsieciach udziału plików.

Aby skonfigurować standardowy punkt końcowy usługi, zobacz Zezwalanie na dostęp ze standardowego punktu końcowego usługi.

Kontrola dostępu wychodzącego

Reguły sieciowe dla udostępniania plików kontrolują dostęp przychodzący. Nie ograniczają one docelowych adresów połączeń wychodzących. Na przykład klient, który potrafi odczytać udostępnione pliki, może kopiować dane do innego zasobu, do którego ma uprawnienia do zapisu.

Ogranicz dostęp wychodzący za pomocą polityk punktów końcowych usługi

Dla klasycznych udostępnień plików możesz użyć polityki endpointów usług, aby ograniczyć, do których kont pamięci masowej klienci w podsieci mogą mieć dostęp przez punkty końcowe usługi. Polityka dotyczy wszystkich klientów w tej podsieci. Zasady sieci i wymagania autoryzacyjne miejsca docelowego nadal obowiązują.

Zasady punktu końcowego usługi współpracują z innymi kontrolami sieciowymi:

• Trasy punktu końcowego usługi nadpisują trasy definiowane przez użytkownika (UDR) dla odpowiadających prefiksów adresów usług. Ruch kierowany przez punkt końcowy usługi nie przechodzi przez Azure Firewall ani wirtualne urządzenie sieciowe (NVA), więc te urządzenia nie mogą go kontrolować ani rejestrować. Aby uzyskać więcej informacji, zobacz Punkty końcowe usługi dla sieci wirtualnej.
• Reguły grupy bezpieczeństwa sieciowego (NSG) mogą używać tagów usług, takich jak Storage.WestUS, aby ograniczyć ruch wychodzący do regionu. Tagi serwisowe nie mogą ograniczać ruchu do konkretnego konta pamięci.

Lista dozwolonych w polityce może zawierać poszczególne konta pamięci, grupy zasobów lub subskrypcje. Polityka blokuje klientom w powiązanej podsieci dostęp do innych kont pamięci masowej przez punkty końcowe usługi. Nie ogranicza innych ścieżek wychodzących z podsieci.

Zasady punktów końcowych usługi nie mają zastosowania do ruchu prywatnych punktów końcowych.

Aby skonfigurować politykę punktu końcowego usługi, zobacz Ogranicz dostęp wychodzący do konkretnych kont pamięci masowej.

Treści powiązane

• Omówienie Azure Files
• Planowanie wdrożenia Azure Files