Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł zawiera wskazówki dotyczące zabezpieczeń dla Azure Files, w tym klasycznych udziałów plików utworzonych przy użyciu Microsoft.Storage oraz udziałów plików utworzonych przy użyciu Microsoft.FileShares. Obejmuje zasoby przechowujące Twoje udziały, dostęp klientów, ochronę danych oraz kontrolę operacyjną.
Mechanizmy zabezpieczeń zależą od dostawcy zasobów i protokołu. Dla porównania obsługiwanych funkcji zobacz koncepcje zarządzania Azure Files.
Izolacja zasobów
Traktuj konto pamięci jako granicę zaufania: Tworzenie oddzielnych klasycznych udostępnień plików w tym samym koncie nie izoluje ich reguł sieciowych, źródła tożsamości SMB ani konfiguracji klucza szyfrującego. Zmiany w tych ustawieniach na poziomie konta dotyczą wszystkich udostępnień na koncie. Grupuj klasyczne elementy udostępnione tylko wtedy, gdy mogą współdzielić te ustawienia. Microsoft.FileShares unika tej współdzielonej granicy na poziomie konta, zapewniając niezależną konfigurację sieci i zabezpieczeń dla każdego udziału.
Chroń systemy klienckie: Klient z dostępem do zapisu może modyfikować lub usuwać dane plików. Utrzymuj systemy operacyjne klienta na bieżąco i ograniczaj lokalny dostęp administracyjny. Stosuj ochronę endpointów odpowiednią dla środowiska klienta. Izolacja sieci i szyfrowanie nie uniemożliwiają autoryzowanemu klientowi wprowadzania destrukcyjnych zmian.
Bezpieczeństwo sieci
Dostęp przychodzący i filtrowanie wychodzące
Ogranicz dostęp przychodzący do klientów, którzy go potrzebują: Oba dostawcy zasobów wspierają prywatne punkty końcowe oraz punkty końcowe usługi z ograniczeniami sieci wirtualnej. Dostęp do udostępnionych plików NFS Azure wymaga jednej z tych ścieżek. Klasyczne klienty SMB i FileREST również mogą korzystać z publicznych punktów końcowych z regułami adresów IP. W przypadku klasycznych udostępnień plików standardowy punkt końcowy usługi umożliwia jednej regule adresu IP objęcie wielu podsieci dla SMB, NFS i FileREST. Aby uzyskać informacje o krokach konfiguracji, zobacz Konfigurowanie punktów końcowych sieci dla udziałów plików platformy Azure.
Wyłącz dostęp publiczny, gdy nie jest on potrzebny: Publiczne punkty końcowe mogą być używane bezpiecznie dzięki kontroli dostępu do sieci, uwierzytelnianiu i szyfrowaniu dostosowanym do protokołu. Utrzymuj dostęp publiczny włączony, gdy Twoje obciążenia tego wymagają, a model bezpieczeństwa na to pozwala, także dla połączeń przez punkty końcowe usługi. Utworzenie prywatnego endpointu nie wyłącza automatycznie dostępu publicznego. W przypadku klasycznych udziałów plików przejrzyj wszelkie wyjątki zaufanych usług lub instancji zasobów, które mogą pozostać skuteczne po wyłączeniu dostępu publicznego. Więcej informacji można znaleźć w artykule Ogranicz dostęp do publicznego punktu końcowego.
Włącz dostęp do zaufanych usług tylko wtedy, gdy jest to potrzebne: Dostępne tylko dla klasycznych udostępnień plików, ustawienie zaufanych usług pozwala obsługiwanym usługom Azure omijać reguły sieciowe konta pamięciowego. Włączaj go tylko wtedy, gdy integracja wymaga takiego dostępu. Te usługi muszą nadal być autoryzowane do dostępu do Twoich danych w plikach.
Opcjonalne filtrowanie ruchu punktów końcowych usług: Gdy klienci korzystają z punktów końcowych usług, aby uzyskać dostęp do klasycznych udostępnionych plików, możesz opcjonalnie zastosować zasady punktu końcowego usługi do ich podsieci. Polityka ogranicza, do których kont pamięci masowej ci klienci mogą uzyskiwać dostęp za pośrednictwem punktów końcowych usługi, przy czym ruch przez te punkty końcowe omija usługę Azure Firewall i wirtualne urządzenia sieciowe. Dotyczy tylko ruchu punktów końcowych usług i nie filtruje ruchu prywatnych punktów końcowych ani innych ścieżek wychodzących. Zasady sieci i wymagania autoryzacyjne miejsca docelowego nadal obowiązują. Microsoft.FileShares obecnie nie obsługuje tych polityk. Klienci w podsieci z zasadą muszą korzystać z prywatnego punktu końcowego, aby uzyskać dostęp do udziałów Microsoft.FileShares. Więcej informacji można znaleźć w artykule Zasady punktów końcowych usługi.
Sprawdź, czy protokół jest obsługiwany przed użyciem perymetru zabezpieczeń sieciowych: Perymetry zabezpieczeń sieciowych są dostępne tylko dla klasycznych udziałów plików. W przypadku udziałów klasycznych obsługa granicy sieci różni się w zależności od protokołu i metody uwierzytelniania. W trybie wymuszonym, klienci SMB i NFS w sieciach wirtualnych Azure muszą łączyć się przez prywatny punkt końcowy lub przez standardowy punkt końcowy usługi z regułą dostępu przychodzącego dla swojego adresu IP. Granica zabezpieczeń blokuje ruch SMB i NFS przez punkty końcowe usług, które nie mają przypisanego adresu IP. SMB i NFS nie obsługują dostępu między zasobami pomiędzy członkami perymetru ani reguł dostępu opartych na subskrypcji. Ruch prywatnego punktu końcowego jest poza wymuszaniem zasad granicy sieci. Sprawdź ograniczenia dla Azure Backup i Azure File Sync przed zastosowaniem granicy sieci. Więcej informacji można znaleźć w artykule Obszar bezpieczeństwa sieci.
Wzmacnianie protokołu SMB
Te zalecenia dotyczą klasycznych udziałów plików SMB.
Wymagaj szyfrowania kanału SMB: Używaj zaszyfrowanych połączeń SMB 3.x. SMB 2.1 nie obsługuje szyfrowania kanałów. Wymóg HTTPS dla FileREST nie zastępuje konfiguracji szyfrowania SMB. Więcej informacji można znaleźć w artykule Szyfrowanie SMB i ustawienia zabezpieczeń.
Ogranicz wersje protokołów i algorytmy do tych, których potrzebują Twoi klienci: Używaj najbardziej bezpiecznego profilu SMB kompatybilnego z twoimi obciążeniami. Sprawdź wsparcie klienta przed wymaganiem SMB 3.1.1 lub AES-256-GCM, ponieważ niekompatybilni klienci nie mogą się połączyć. Szyfrowanie kanałów SMB oraz szyfrowanie biletów Kerberos to oddzielne mechanizmy kontroli. Więcej informacji można znaleźć w ustawieniach bezpieczeństwa SMB.
Ogranicz metody uwierzytelniania SMB: Używaj Kerberosa do dostępu opartego na tożsamości. Jeśli żaden klient nie potrzebuje uwierzytelniania klucza konta pamięci przez SMB, usuń NTLMv2 z dozwolonych metod uwierzytelniania SMB po testach. Ta kontrola dotyczy SMB; nie wyłącza dostępu do FileREST opartego na kluczach.
Utrzymuj dane uwierzytelniające AD DS w stosownych przypadkach: W przypadku uwierzytelniania AD DS zarządzaj hasłem podmiotu zabezpieczeń katalogu reprezentującego konto magazynu zgodnie z zasadami katalogu. Postępuj zgodnie z udokumentowaną procedurą rotacji, aby synchronizować hasło katalogu i klucz Kerberos konta magazynu. Więcej informacji można znaleźć w artykule Zaktualizuj hasło tożsamości konta magazynowego w AD DS.
Udostępnienia plików NFS 4.1
Te zalecenia dotyczą udostępniania plików NFS z jednym lub drugim dostawcą zasobów. NFS wykorzystuje uwierzytelnianie sieciowe i uprawnienia POSIX, a nie uwierzytelnianie tożsamościowe SMB.
Ogranicz dostęp do zaufanych sieci: Pozwól tylko na podsieci i prywatne połączenia potrzebne przez obciążenie robocze. NFS opiera się na tożsamościach prezentowanych przez klienta, dlatego należy kontrolować, które systemy i administratorzy mogą korzystać z tych połączeń.
Zarządzaj uprawnieniami POSIX i tożsamościami klientów: Używaj spójnych identyfikatorów użytkowników i grup na wszystkich klientach. Ogranicz uprawnienia do plików i katalogów dla użytkowników i grup, które potrzebują dostępu. Uprawnienia Azure RBAC do zarządzania zasobem Azure nie dają dostępu do plików NFS. Więcej informacji można znaleźć w artykule Uwierzytelnianie NFS i dostęp do sieci.
Konfiguruj root squash tam, gdzie jest to zgodne z obciążeniem roboczym: root squash mapuje żądania z UID/GID 0 na anonimową tożsamość. Nie ogranicza innych tożsamości ani nie sprawia, że udostępnienie jest tylko do odczytu. Aby uzyskać ustawienia i kroki konfiguracyjne dla obu dostawców zasobów, zobacz Root squashing for NFS Azure file shares.
Wymagaj szyfrowania podczas przesyłania: Obaj dostawcy zasobów obsługują TLS za pomocą pomocnika instalowania AZNFS. Microsoft.FileShares domyślnie wymaga szyfrowania podczas transportu. Klasyczne udziały plików mają ustawienia szyfrowania NFS na poziomie konta magazynu. Domyślne ustawienia i linki konfiguracyjne: zobacz szyfrowanie NFS.
Zarządzanie tożsamością i dostępem
Zarządzanie zasobami platformy Azure
Używaj najmniejszych uprawnień do dostępu zarządczego: Przyznaj uprawnienia Azure RBAC w najmniejszym zakresie potrzebnym do tworzenia, konfigurowania lub usuwania zasobów. W przypadku klasycznych udziałów uprawnienia na poziomie konta mogą wpływać na każdy udział w koncie. Możesz niezależnie zarządzać zasobami Microsoft.FileShares. Role zarządcze i uprawnienia dostępu do danych mają różne zastosowania. Aby uzyskać więcej informacji, zobacz płaszczyznę kontrolną i płaszczyznę danych Azure.
Ogranicz stały dostęp administracyjny: Używaj Microsoft Entra Privileged Identity Management tam, gdzie to stosowne, dla ról uprzywilejowanych Azure. Wymagaj zatwierdzenia i uwierzytelniania wieloskładnikowego do aktywacji administracyjnej zgodnie z polityką Twojej organizacji. Aby uzyskać więcej informacji, zobacz Privileged Identity Management.
Uwierzytelnianie oparte na tożsamości dla współdzielonych plików SMB
Dostęp oparty na tożsamości SMB jest dostępny dla klasycznych udostępnień plików. Klucz konta magazynu zapewnia szeroki dostęp do danych we wszystkich udziałach w koncie i nie identyfikuje pojedynczego użytkownika.
Korzystaj ze źródła tożsamości obsługiwanego przez Twoich klientów: Azure Files obsługuje AD DS, Microsoft Entra Domain Services oraz Microsoft Entra Kerberos. Ich wymagania klienta i dotyczące tożsamości różnią się. Obsługiwane scenariusze i poradniki konfiguracyjne znajdziesz w artykule Uwierzytelnianie oparte na tożsamości dla Azure Files.
Używaj zarządzanych tożsamości dla obsługiwanych obciążeń aplikacji: Zarządzane tożsamości mogą zapewnić dostęp do SMB bez rozdzielania kluczy do konta magazynowego. Zweryfikuj wymagania obliczeniowe, dotyczące klienta i uwierzytelniania potrzebne do wdrożenia. Więcej informacji można znaleźć w artykule Uzyskiwanie dostępu do udziałów SMB przy użyciu tożsamości zarządzanych.
Chroń klucze konta, gdy są wymagane: Ogranicz uprawnienia do pobierania lub regenerowania kluczy. Przechowuj wymagane klucze w Azure Key Vault i dokonuj ich rotacji po ujawnieniu lub zgodnie z polityką dotyczącą poświadczeń. Zaplanuj rotację kluczy dla klientów i integracji, które nadal korzystają z tych kluczy. Aby uzyskać więcej informacji, zobacz Zarządzanie kluczami dostępu do konta magazynu.
Uprawnienia na poziomie współdzielenia i NTFS
Te uprawnienia dotyczą klasycznych udostępnień plików SMB.
Przypisz role na poziomie share w wymaganym zakresie: Przyznaj dostęp do odczytu, zapisu lub dostęp administracyjny tylko tym tożsamościom, które go potrzebują. Przydziały ról na poziomie udziału plików pozwalają uniknąć przyznawania dostępu do niepowiązanych udziałów plików w tym samym koncie magazynu. Aby uzyskać więcej informacji, zobacz Przypisywanie uprawnień na poziomie udziału.
Stosuj uprawnienia do katalogów i plików: Używaj list ACL systemu Windows, także w katalogu głównym udostępnienia tam, gdzie jest to potrzebne, aby kontrolować dostęp w ramach udostępnienia. Użyj dziedziczenia, aby zachować kontrolę nad uprawnieniami. Egzekwowane są zarówno uprawnienia na poziomie współdzielenia, jak i ACL Windows. Aby uzyskać więcej informacji, zobacz Konfigurowanie uprawnień na poziomie katalogu i na poziomie pliku.
Ogranicz administrację uprawnieniami: Ogranicz role uprzywilejowane i prawa do modyfikacji list ACL do tożsamości odpowiedzialnych za zarządzanie uprawnieniami. Przeglądaj zarówno przypisania ról, jak i dziedziczone ACL, gdy zmieniają się wymagania dostępu.
Dostęp do FileREST i SAS
Dostęp do danych FileREST jest dostępny dla klasycznych udostępnień. Microsoft. FileShares obecnie nie obsługuje dostępu do danych FileREST.
Użyj OAuth do wspieranego dostępu do danych administracyjnych: tożsamości Microsoft Entra, w tym tożsamości zarządzane, mogą uzyskać dostęp do klasycznych udziałów przez FileREST. Uprzywilejowane role używane przez tę metodę dostępu mogą omijać uprawnienia do plików i katalogów, więc przyznawaj je tylko wtedy, gdy ten dostęp jest wymagany. Więcej informacji znajdziesz w artykule Azure Files OAuth over REST.
Ogranicz uprawnienia SAS i ich czas użytkowania: Gdy obsługiwane narzędzie wymaga podpisu współdostępowego (SAS), ogranicz jego zakres, uprawnienia i okres ważności oraz wymagaj HTTPS. Chroń SAS jako poświadczenie. Tokeny SAS nie są używane do instalowania udziałów przez SMB lub NFS. Więcej informacji można znaleźć w artykule Sygnatury dostępu współdzielonego.
Wymagaj HTTPS dla FileREST: HTTPS chroni żądania REST w trakcie transportu. Szyfrowanie kanałów SMB i tunelowanie NFS TLS są oddzielne od wymagań HTTPS. Kroki konfiguracyjne można znaleźć w artykule Szyfrowanie FileREST podczas przesyłania.
Ochrona danych
Zrozumienie szyfrowania w spoczynku: Obaj dostawcy zasobów domyślnie szyfrują dane plików w spoczynku za pomocą kluczy zarządzanych przez Microsoft. Szyfrowanie w spoczynku chroni przechowywane dane; nie uniemożliwia autoryzowanym klientom odczytywania ani modyfikowania plików.
Używaj kluczy zarządzanych przez klienta, gdy jest to konieczne: Classic shares obsługują klucze zarządzane przez klienta w Azure Key Vault lub Managed HSM. Microsoft. FileShares obecnie nie obsługuje kluczy zarządzanych przez klienta. Chroń magazyn kluczy, planuj rotację kluczy i miej świadomość, że utrata dostępu do klucza może sprawić, że dane staną się niedostępne. Więcej informacji można znaleźć w artykule Klucze zarządzane przez klienta dla Azure Files.
Oceń szyfrowanie infrastruktury pod kątem odpowiednich klasycznych wdrożeń: Klasyczne konta magazynu mogą mieć dodatkową warstwę szyfrowania, gdy wymaga tego polityka zgodności. Ta opcja jest wybierana przy tworzeniu konta i nie można jej później zmienić. Więcej informacji można znaleźć w artykule Szyfrowanie infrastruktury.
Używaj blokad zasobów do ochrony operacji zarządzania: Blokada CanNotDelete na odpowiednim zasobie Azure lub w zakresie nadrzędnym może zapobiec usunięciu przez Azure Resource Manager. Blokady nie uniemożliwiają klientom modyfikowania ani usuwania danych plików. W przypadku klasycznych udostępnień one również nie zapobiegają usuwaniu za pośrednictwem interfejsów API FileREST płaszczyzny danych. Informacje o zachowaniu blokady i skutkach operacyjnych można znaleźć w artykule Blokowanie zasobów platformy Azure.
Kopia zapasowa i przywracanie
Twórz migawki udziałów plików zgodnie z potrzebami odzyskiwania: Obaj dostawcy zasobów obsługują migawki udziałów plików do odzyskiwania wcześniejszych wersji plików. Ustal harmonogram i politykę retencji tak, aby spełniała Twoje cele odzyskiwania. Snapshoty udostępnień pozostają powiązane z udziałem źródłowym, więc nie stanowią niezależnej kopii zapasowej, jeśli ten udział zostanie trwale usunięty. Więcej informacji można znaleźć w artykule Share snapshots for Azure Files.
Włącz soft delete dla klasycznych udziałów: Soft delete zachowuje usunięte udostępnienia przez skonfigurowany czas. Nie odzyskuje pojedynczych plików ani indywidualnie usuniętych migawek. Microsoft.FileShares obecnie nie obsługuje usuwania nietrwałego. Aby uzyskać więcej informacji, zobacz Zapobieganie przypadkowemu usunięciu udostępnień plików Azure.
Wybierz rozwiązanie do backupu obsługiwane przez protokół: Azure Backup obsługuje klasyczne udostępnienia SMB, z opcjami snapshotów i kopii zapasowych w magazynie. Obecnie nie obsługuje on udziałów NFS u żadnego z dostawców zasobów. W przypadku NFS wybierz rozwiązanie do backupu, które obsługuje protokół i spełnia Twoje wymagania dotyczące retencji i izolacji. Aby uzyskać informacje o zakresie obsługi usługi Azure Backup, zobacz obsługa kopii zapasowych udziałów plików platformy Azure.
Oddzielna administracja kopiami zapasowymi i testowe odzyskiwanie: Ogranicz, kto może usuwać punkty odzyskiwania lub zmieniać okres retencji. Testy przywracania plików, uprawnień i pełnych obciążeń roboczych. Sprawdź, czy odzyskiwanie jest możliwe, jeśli dane uwierzytelniające produkcyjne lub źródłowy zasób sieciowy zostaną naruszone.
Planuj na wypadek awarii infrastruktury oddzielnie od odzyskiwania danych: Redundancja zwiększa odporność na awarie infrastruktury, ale także powiela zmiany danych. Nie zastępuje kopii zapasowych na wypadek niechcianych zmian lub usunięcia. Dostępne opcje redundancji różnią się w zależności od warstwy nośnika i dostawcy zasobów. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Files.
Rejestrowanie i monitorowanie
Inspekcja zmian zarządzania dla obu dostawców zasobów: Użyj dziennika aktywności Azure do monitorowania usuwania zasobów, zmian konfiguracji i przypisywania ról. Przejrzyj zmiany w dostępie publicznym, regułach sieci, wymaganiach szyfrowania i kontrolach odzyskiwania. Aby uzyskać więcej informacji, zobacz Dziennik aktywności platformy Azure.
Zbieraj obsługiwane dzienniki dostępu do danych: Dla klasycznego dostępu SMB i FileREST używaj logów zasobów usług plików do przeglądania podmiotów wywołujących, metod autoryzacji, nieudanych żądań oraz działań usuwania. Zbieraj logi wymagane przez politykę retencji w Log Analytics lub innym obsługiwanym miejscu. Nie zakładaj takiego samego zakresu logowania żądań jak NFS czy Microsoft.FileShares. Aby uzyskać informacje o obsługiwanych operacjach i polach, zobacz odniesienie danych monitorowania Azure Files.
Koreluj alerty z logami klienta i tożsamości: Zbadaj nieoczekiwane użycie klucza, nieudane uwierzytelnianie, usuwanie udziałów oraz zmiany w konfiguracji bezpieczeństwa. Używaj dzienników klienta i katalogu, gdy błąd uwierzytelniania wystąpi, zanim żądanie dotrze do Azure Files. Przekazuj alerty zespołowi odpowiedzialnemu za obciążenie.
Oceń Defender for Storage dla klasycznych wdrożeń: Defender for Storage zapewnia wykrywanie zagrożeń dla obsługiwanych kont magazynu. Zweryfikuj pokrycie funkcji i protokołów dla wdrożenia; ochrona konta nie oznacza, że każda operacja pliku jest skanowana pod kątem złośliwego oprogramowania. Więcej informacji można znaleźć w Microsoft Defender for Storage.
Zgodność i ład
Stosuj zasady zgodne z dostawcą zasobów: Korzystaj z Azure Policy do inspekcji lub egzekwowania wymagań Twojej organizacji tam, gdzie obsługiwane są typ zasobu i właściwości. Sprawdź zakres i skutki każdej definicji. Polityka ukierunkowana na konta magazynu Microsoft.Storage nie ocenia automatycznie zasobów Microsoft.FileShares. Aby uzyskać więcej informacji, zobacz definicje zasad usługi Azure.
Wymagania dotyczące własności rekordów i danych: Używaj tagów zasobów do identyfikacji odpowiedzialnego zespołu, środowiska i klasyfikacji danych. W przypadku klasycznych udziałów kontrola na poziomie konta dotyczy wszystkich udziałów na koncie. Rejestruj wyjątki i przeglądaj je, gdy zmienia się właściciel obciążenia.
Zweryfikuj zgodność wdrożenia: Potwierdź, że wybrana usługa, region, protokół i funkcje ochrony spełniają Twoje wymagania. Użyj benchmarku bezpieczeństwa w chmurze Microsoft, aby zorganizować przeglądy kontroli. Informacje o certyfikacji można znaleźć w ofertach dotyczących zgodności usługi Azure Storage.
Azure File Sync
Azure File Sync obsługuje klasyczne udostępnienia SMB. Nie obsługuje NFS ani Microsoft.FileShares. Zabezpiecz zarówno zasób udostępniony w chmurze, jak i punkty końcowe systemu Windows Server.
Używaj zarządzanych tożsamości w obsługiwanych wdrożeniach File Sync: Postępuj zgodnie z konfiguracją zarządzanej tożsamości dla usługi synchronizacji pamięci i zarejestrowanych serwerów, aby usunąć zależność od współdzielonych kluczy. Więcej informacji można znaleźć w artykule Używanie tożsamości zarządzanych z usługą Azure File Sync.
Ogranicz dostęp administracyjny do zasobów synchronizacji i serwerów: Używaj wymaganych ról usługi Storage Sync w odpowiednim zakresie. Chroń lokalne uprawnienia plików i administrację serwera, ponieważ zmiany wprowadzone za pośrednictwem punktu końcowego mogą być synchronizowane z zasobem udostępnionym w chmurze. Więcej informacji można znaleźć w artykule Zaplanuj wdrożenie usługi Azure File Sync.