Omówienie zachowania zabezpieczeń i uprawnień w usłudze Azure NetApp Files przy użyciu dwóch protokołów
Protokół SMB i NFS używają różnych modeli uprawnień dla dostępu użytkowników i grup. W związku z tym wolumin usługi Azure NetApp File musi być skonfigurowany tak, aby był zgodny z żądanym modelem uprawnień na potrzeby dostępu do protokołu. W przypadku środowisk tylko NFS decyzja jest prosta — użyj stylów zabezpieczeń system UNIX. W przypadku środowisk tylko do protokołu SMB należy użyć stylów zabezpieczeń NTFS.
Jeśli wymagany jest system plików NFS i protokół SMB w tych samych zestawach danych (protokół podwójny), należy podjąć decyzję na podstawie dwóch pytań:
- Jaki protokół użytkownicy będą zarządzać uprawnieniami z większości?
- Jaki jest żądany punkt końcowy zarządzania uprawnieniami? Innymi słowy, czy użytkownicy wymagają możliwości zarządzania uprawnieniami z klientów systemu plików NFS lub klientów systemu Windows? Może oba te rozwiązania?
Style zabezpieczeń woluminów można naprawdę uznać za style uprawnień, gdzie żądany styl zarządzania listą ACL jest czynnikiem decydującym.
Uwaga
Style zabezpieczeń są wybierane podczas tworzenia woluminu. Po wybraniu stylu zabezpieczeń nie można go zmienić.
Informacje o stylach zabezpieczeń woluminów usługi Azure NetApp Files
Istnieją dwa główne opcje stylów zabezpieczeń woluminów w usłudze Azure NetApp Files:
system UNIX — styl zabezpieczeń system UNIX zapewnia uprawnienia system UNIX stylu, takie jak podstawowe bity trybu POSIX (właściciel/grupa/wszyscy uzyskują dostęp ze standardowymi uprawnieniami do odczytu/zapisu/wykonywania, takimi jak 0755) i list ACL NFSv4.x. Listy ACL POSIX nie są obsługiwane.
NTFS — styl zabezpieczeń NTFS zapewnia identyczne funkcje jak standardowe uprawnienia systemu Windows NTFS z szczegółowymi uprawnieniami użytkowników i grup w listach ACL oraz szczegółowe uprawnienia zabezpieczeń/inspekcji.
W środowisku NAS z dwoma protokołami tylko jeden styl uprawnień zabezpieczeń może być aktywny. Przed wybraniem należy ocenić zagadnienia dotyczące poszczególnych stylów zabezpieczeń.
| Styl zabezpieczeń | Kwestie wymagające rozważenia |
|---|---|
| UNIX | — Klienci systemu Windows mogą ustawiać tylko atrybuty uprawnień system UNIX za pośrednictwem smB mapujących na atrybuty system UNIX (tylko odczyt/zapis/wykonywanie; bez specjalnych uprawnień). — Listy ACL NFSv4.x nie mają zarządzania graficznym interfejsem użytkownika. Zarządzanie odbywa się tylko za pośrednictwem interfejsu wiersza polecenia przy użyciu poleceń nfs4_getfacl i nfs4_setfacl. — Jeśli plik lub folder ma listy ACL NFSv4.x, karta Właściwości zabezpieczeń systemu Windows nie może ich wyświetlić. |
| NTFS | - system UNIX klienci nie mogą ustawiać atrybutów za pośrednictwem systemu plików NFS za pośrednictwem poleceń, takich jak chown/chmod. - Klienci systemu plików NFS pokazują tylko przybliżone uprawnienia systemu plików NTFS podczas korzystania z ls poleceń. Jeśli na przykład użytkownik ma uprawnienia do listy ACL systemu Windows NTFS, która nie może być czysta przetłumaczona na bit trybu POSIX (na przykład przechodzenie do katalogu), jest tłumaczona na najbliższą wartość bitową trybu POSIX (na przykład 1 do wykonania). |
Wybór stylu zabezpieczeń woluminów określa sposób wykonywania mapowania nazw dla użytkownika. Ta operacja jest podstawowym elementem sposobu, w jaki woluminy z podwójnym protokołem zachowują przewidywalne uprawnienia niezależnie od używanego protokołu.
Poniższa tabela zawiera macierz decyzyjną służącą do wybierania odpowiednich stylów zabezpieczeń woluminów.
| Styl zabezpieczeń | Głównie NFS | Głównie SMB | Potrzeba zapewnienia szczegółowych zabezpieczeń |
|---|---|---|---|
| UNIX | X | - | X (przy użyciu list ACL NFSv4.x) |
| NTFS | - | X | X |
Jak działa mapowanie nazw w usłudze Azure NetApp Files
W usłudze Azure NetApp Files tylko użytkownicy są uwierzytelniani i mapowane. Grupy nie są mapowane. Zamiast tego członkostwo w grupach jest określane przy użyciu tożsamości użytkownika.
Gdy użytkownik próbuje uzyskać dostęp do woluminu usługi Azure NetApp Files, próbuje przejść wzdłuż tożsamości do usługi. Ta tożsamość zawiera nazwę użytkownika i unikatowy identyfikator liczbowy (numer UID dla systemu plików NFSv3, ciąg nazwy dla systemu plików NFSv4.1, identyfikator SID dla protokołu SMB). Usługa Azure NetApp Files używa tej tożsamości do uwierzytelniania w skonfigurowanej usłudze nazw w celu zweryfikowania tożsamości użytkownika.
- Wyszukiwanie LDAP dla identyfikatorów liczbowych służy do wyszukiwania nazwy użytkownika w usłudze Active Directory.
- Ciągi nazw używają wyszukiwania LDAP, aby wyszukać nazwę użytkownika, a klient i serwer skonsultuj się ze skonfigurowaną domeną identyfikatora dla systemu plików NFSv4.1 , aby upewnić się, że są zgodne.
- Użytkownicy systemu Windows są odpytywane przy użyciu standardowych wywołań RPC systemu Windows do usługi Active Directory.
- Zapytania dotyczące członkostwa w grupach są również wysyłane i wszystkie elementy są dodawane do pamięci podręcznej poświadczeń w celu szybszego przetwarzania kolejnych żądań do woluminu.
- Obecnie niestandardowi użytkownicy lokalni nie są obsługiwani do użytku z usługą Azure NetApp Files. Tylko użytkownicy w usłudze Active Directory mogą być używane z podwójnymi protokołami.
- Obecnie jedynymi użytkownikami lokalnymi, których można używać z woluminami z dwoma protokołami, są użytkownicy root i
nfsnobodyużytkownik.
Po uwierzytelnieniu i zweryfikowaniu nazwy użytkownika przez usługę Azure NetApp Files następnym krokiem uwierzytelniania woluminu z dwoma protokołami jest mapowanie nazw użytkowników dla system UNIX i współdziałania systemu Windows.
Styl zabezpieczeń woluminu określa, jak odbywa się mapowanie nazw w usłudze Azure NetApp Files. Semantyka uprawnień systemu Windows i system UNIX są różne. Jeśli nie można wykonać mapowania nazw, uwierzytelnianie zakończy się niepowodzeniem, a dostęp do woluminu z klienta zostanie odrzucony. Typowym scenariuszem, w którym taka sytuacja występuje, jest próba uzyskania dostępu do woluminu z systemem plików NFSv3 ze stylem zabezpieczeń systemu plików NTFS. Początkowe żądanie dostępu z systemu plików NFSv3 jest dostarczane do usługi Azure NetApp Files jako numeryczny identyfikator UID. Jeśli użytkownik o nazwie o user1 identyfikatorze liczbowym 1001 próbuje uzyskać dostęp do instalacji NFSv3, żądanie uwierzytelniania zostanie dostarczone jako identyfikator 1001liczbowy . Następnie usługa Azure NetApp Files przyjmuje identyfikator 1001 liczbowy i próbuje rozpoznać 1001 nazwę użytkownika. Ta nazwa użytkownika jest wymagana do mapowania na prawidłowego użytkownika systemu Windows, ponieważ uprawnienia NTFS na woluminie będą zawierać nazwy użytkowników systemu Windows zamiast identyfikatora liczbowego. Usługa Azure NetApp Files będzie używać skonfigurowanego serwera usługi nazw (LDAP) do wyszukiwania nazwy użytkownika. Jeśli nie można odnaleźć nazwy użytkownika, uwierzytelnianie zakończy się niepowodzeniem i odmowa dostępu. Ta operacja jest wykonywana zgodnie z projektem, aby zapobiec niepożądanemu dostępowi do plików i folderów.
Mapowanie nazw na podstawie stylu zabezpieczeń
Kierunek mapowania nazw w usłudze Azure NetApp Files (system Windows do system UNIX lub system UNIX systemu Windows) zależy nie tylko od używanego protokołu, ale także stylu zabezpieczeń woluminu. Klient systemu Windows zawsze wymaga mapowania nazw systemu Windows na system UNIX, aby zezwolić na dostęp, ale nie zawsze wymaga zgodnej nazwy użytkownika system UNIX. Jeśli w skonfigurowanym serwerze usługi nazw nie istnieje żadna prawidłowa nazwa użytkownika system UNIX, usługa Azure NetApp Files udostępnia rezerwowy domyślny system UNIX użytkownika z numerycznym identyfikatorem UID 65534 umożliwiającym wstępne uwierzytelnianie połączeń SMB. Następnie uprawnienia do plików i folderów będą kontrolować dostęp. Ponieważ 65534 zazwyczaj odpowiada użytkownikowi nfsnobody , dostęp jest ograniczony w większości przypadków. Z drugiej strony klient systemu plików NFS musi używać mapowania nazw systemu plików system UNIX do systemu Windows, jeśli jest używany styl zabezpieczeń NTFS. W usłudze Azure NetApp Files nie ma domyślnego użytkownika systemu Windows. W związku z tym, jeśli nie można odnaleźć prawidłowego użytkownika systemu Windows zgodnego z nazwą żądającą, dostęp zostanie odrzucony.
W poniższej tabeli przedstawiono różne permutacje mapowania nazw i sposób ich działania w zależności od używanego protokołu.
| Protokół | Styl zabezpieczeń | Kierunek mapowania nazw | Zastosowane uprawnienia |
|---|---|---|---|
| SMB | UNIX | Windows to system UNIX | system UNIX (mode-bity lub listy ACL NFSv4.x) |
| SMB | NTFS | Windows to system UNIX | Listy ACL systemu plików NTFS (na podstawie identyfikatora SID systemu Windows uzyskiwania dostępu do udziału) |
| NFSv3 | UNIX | Brak | system UNIX (mode-bits lub NFSv4.x ACL*) |
| NFSv4.x | UNIX | Identyfikator liczbowy do system UNIX nazwy użytkownika | system UNIX (mode-bity lub listy ACL NFSv4.x) |
| NFS3/4.x | NTFS | system UNIX do systemu Windows | Listy ACL systemu plików NTFS (na podstawie mapowanego identyfikatora SID użytkownika systemu Windows) |
Uwaga
Reguły mapowania nazw w usłudze Azure NetApp Files mogą być obecnie kontrolowane tylko przy użyciu protokołu LDAP. Nie ma możliwości tworzenia jawnych reguł mapowania nazw w usłudze.
Usługi nazw z woluminami z dwoma protokołami
Niezależnie od tego, jaki protokół NAS jest używany, woluminy z podwójnym protokołem używają pojęć mapowania nazw w celu prawidłowego obsługi uprawnień. W związku z tym usługi nazw odgrywają kluczową rolę w utrzymywaniu funkcjonalności w środowiskach korzystających zarówno z protokołu SMB, jak i systemu plików NFS na potrzeby dostępu do woluminów.
Usługi nazw działają jako źródła tożsamości dla użytkowników i grup, które uzyskują dostęp do woluminów NAS. Ta operacja obejmuje usługę Active Directory, która może pełnić rolę źródła zarówno dla użytkowników systemu Windows, jak i system UNIX grup przy użyciu zarówno standardowych usług domenowych, jak i funkcji LDAP.
Usługi nazw nie są trudnym wymaganiem, ale zdecydowanie zalecane w przypadku woluminów z podwójnym protokołem usługi Azure NetApp Files. Nie ma pojęcia tworzenia niestandardowych lokalnych użytkowników i grup w usłudze. W związku z tym, aby mieć odpowiednie uwierzytelnianie i dokładne informacje o właścicielu użytkownika i grupy między protokołami, protokół LDAP jest koniecznością. Jeśli masz tylko kilku użytkowników i nie musisz wypełniać dokładnych informacji o tożsamości użytkownika i grupy, rozważ użycie opcji Zezwalaj lokalnym użytkownikom systemu plików NFS z protokołem LDAP na dostęp do funkcji woluminu z podwójnym protokołem. Należy pamiętać, że włączenie tej funkcji powoduje wyłączenie rozszerzonej funkcjonalności grupy.
Gdy klienci, usługi nazw i magazyn znajdują się w różnych obszarach
W niektórych przypadkach klienci NAS mogą mieszkać w sieci podzielonej na segmenty z wieloma interfejsami, które mają izolowane połączenia z usługami magazynu i nazw.
Jednym z takich przykładów jest to, że magazyn znajduje się w usłudze Azure NetApp Files, podczas gdy wszyscy klienci NAS i usługi domenowe znajdują się lokalnie (na przykład architektura piasty i szprych na platformie Azure). W tych scenariuszach należy zapewnić dostęp sieciowy zarówno do klientów NAS, jak i usług nazw.
Na poniższej ilustracji przedstawiono przykład takiej konfiguracji.
