Omówienie szyfrowania danych w usłudze Azure NetApp Files

Artykuł
02/14/2024

Usługa Azure NetApp Files szyfruje dane za pomocą dwóch różnych metod:

Szyfrowanie magazynowane: dane są szyfrowane w miejscu przy użyciu standardów zgodnych ze standardami FIPS 140-2.
Szyfrowanie podczas przesyłania: dane są szyfrowane podczas przesyłania lub za pośrednictwem komunikacji sieciowej , ponieważ są przesyłane między klientem a serwerem.

Omówienie szyfrowania magazynowanych

Dane magazynowane w usłudze Azure NetApp Files można szyfrować na dwa sposoby:

Pojedyncze szyfrowanie używa szyfrowania programowego dla woluminów usługi Azure NetApp Files.
Podwójne szyfrowanie dodaje szyfrowanie na poziomie sprzętu w warstwie urządzenia magazynu fizycznego.

Usługa Azure NetApp Files używa standardowego modułu CryptoMod do generowania kluczy szyfrowania AES-256. CryptoMod znajduje się na liście zweryfikowanych modułów PROGRAMU CMVP FIPS 140-2. Aby uzyskać więcej informacji, zobacz FIPS 140-2 Cert #4144. Klucze szyfrowania są skojarzone z woluminami i mogą być kluczami zarządzanymi przez platformę firmy Microsoft lub kluczami zarządzanymi przez klienta.

Informacje o szyfrowaniu przesyłanym danych

Oprócz zabezpieczania danych magazynowanych usługa Azure NetApp Files może zabezpieczyć dane podczas ich przesyłania między punktami końcowymi. Użyta metoda szyfrowania zależy od protokołu lub funkcji. System DNS nie jest szyfrowany podczas przesyłania w plikach usługi Azure NetApp. Kontynuuj czytanie, aby dowiedzieć się więcej na temat szyfrowania SMB i NFS, protokołu LDAP i replikacji danych w usłudze Azure NetApp Files.

Szyfrowanie SMB

Klienci SMB systemu Windows korzystający z wersji protokołu SMB3.x natywnie obsługują szyfrowanie SMB. Szyfrowanie SMB jest przeprowadzane kompleksowo i szyfruje całą konwersację SMB przy użyciu zestawów kryptograficznych AES-256-GCM/AES-128-GCM i AES-256-CCM/AES-128-CCM.

Szyfrowanie SMB nie jest wymagane dla woluminów usługi Azure NetApp Files, ale może być używane w celu zapewnienia dodatkowych zabezpieczeń. Szyfrowanie SMB powoduje dodanie obciążenia związanego z wydajnością. Aby dowiedzieć się więcej na temat zagadnień dotyczących wydajności szyfrowania SMB, zobacz Najlepsze rozwiązania dotyczące wydajności protokołu SMB dla usługi Azure NetApp Files.

Wymaganie szyfrowania dla połączeń SMB

Usługa Azure NetApp Files umożliwia wymuszanie szyfrowania na wszystkich połączeniach SMB. Wymuszanie szyfrowania nie zezwala na niezaszyfrowaną komunikację SMB i używa protokołu SMB3 i nowszych dla połączeń SMB. Szyfrowanie odbywa się przy użyciu szyfrowania AES i szyfruje wszystkie pakiety SMB. Aby ta funkcja działała prawidłowo, klienci SMB muszą obsługiwać szyfrowanie SMB. Jeśli klient SMB nie obsługuje szyfrowania i protokołu SMB3, połączenia SMB są niedozwolone. Jeśli ta opcja jest włączona, wszystkie udziały, które mają ten sam adres IP, wymagają szyfrowania, w związku z tym przesłaniają ustawienie właściwości udziału SMB na potrzeby szyfrowania.

Możesz też ustawić szyfrowanie na poziomie pojedynczego udziału woluminu usługi Azure NetApp Files.

Wzmacnianie zabezpieczeń UNC

W 2015 r. firma Microsoft wprowadziła wzmocnienie zabezpieczeń UNC (MS15-011 i MS15-014) w celu rozwiązania luk w zabezpieczeniach ścieżek sieci zdalnej, które mogą umożliwić zdalne wykonywanie kodu w udziałach SMB. Aby uzyskać więcej informacji, zobacz MS15-011 & MS15-014: Wzmacnianie zabezpieczeń zasad grupy.

Wzmocnienie zabezpieczeń UNC zapewnia trzy opcje zabezpieczania ścieżek UNC:

RequireMutualAuthentication — Uwierzytelnianie tożsamości wymagane/nie jest wymagane do blokowania ataków fałszowania.
RequireIntegrity — Sprawdzanie integralności jest wymagane/nie jest wymagane do blokowania ataków polegających na manipulowaniu.
RequirePrivacy — Prywatność (całkowite szyfrowanie pakietów SMB) włączona/wyłączona, aby zapobiec wąchaniu ruchu.

Usługa Azure NetApp Files obsługuje wszystkie trzy formy wzmacniania zabezpieczeń UNC.

NFS Kerberos

Usługa Azure NetApp Files umożliwia również szyfrowanie konwersacji NFSv4.1 za pośrednictwem uwierzytelniania Kerberos przy użyciu pakietów kryptograficznych AES-256-GCM/AES-128-GCM i AES-256-CCM/AES-128-CCM.

W przypadku protokołu Kerberos systemu plików NFS usługa Azure NetApp Files obsługuje trzy różne wersje zabezpieczeń:

Kerberos 5 (krb5) — tylko uwierzytelnianie początkowe; wymaga wymiany biletów protokołu Kerberos/logowania użytkownika w celu uzyskania dostępu do eksportu systemu plików NFS. Pakiety NFS nie są szyfrowane.
Kerberos 5i (krb5i) — wstępne uwierzytelnianie i sprawdzanie integralności; wymaga wymiany biletów Protokołu Kerberos/logowania użytkownika w celu uzyskania dostępu do eksportu systemu plików NFS i dodaje kontrole integralności do każdego pakietu NFS, aby zapobiec atakom typu man-in-the-middle (MITM).
Kerberos 5p (krb5p) — początkowe uwierzytelnianie, sprawdzanie integralności i prywatność; wymaga wymiany biletów Protokołu Kerberos/logowania użytkownika w celu uzyskania dostępu do eksportu systemu plików NFS, przeprowadza kontrole integralności i stosuje otokę GSS do każdego pakietu NFS w celu zaszyfrowania jego zawartości.

Każdy poziom szyfrowania Kerberos ma wpływ na wydajność. W miarę jak typy szyfrowania i smaki zabezpieczeń zawierają bezpieczniejsze metody, efekt wydajności wzrasta. Na przykład krb5 wydajność jest lepsza niż krb5i, krb5i działa lepiej niż krb5p, AES-128 działa lepiej niż AES-256 itd. Aby uzyskać więcej informacji na temat wpływu wydajności protokołu Kerberos systemu plików NFS w usłudze Azure NetApp Files, zobacz Wpływ wydajności protokołu Kerberos na woluminy NFSv4.1 usługi Azure NetApp Files.

Uwaga

Protokół Kerberos systemu plików NFS jest obsługiwany tylko w systemie plików NFSv4.1 w usłudze Azure NetApp Files.

Na poniższej ilustracji jest używany protokół Kerberos 5 (krb5). Szyfrowane jest tylko początkowe żądanie uwierzytelniania (pozyskiwanie logowania/biletu). Cały inny ruch NFS dociera do zwykłego tekstu.

W przypadku korzystania z protokołu Kerberos 5i (krb5i; sprawdzanie integralności) ślad pokazuje, że pakiety NFS nie są szyfrowane, ale istnieje otoka GSS/Kerberos dodana do pakietu wymagającego klienta i serwera zapewnienia integralności danych przesyłanych przy użyciu sumy kontrolnej.

Protokół Kerberos 5p (prywatność; krb5p) zapewnia kompleksowe szyfrowanie całego ruchu NFS, jak pokazano na obrazie śledzenia przy użyciu otoki GSS/Kerberos. Ta metoda tworzy największe obciążenie związane z wydajnością ze względu na konieczność przetwarzania szyfrowania każdego pakietu NFS.

Replikacja danych

W usłudze Azure NetApp Files można replikować całe woluminy między strefami lub regionami na platformie Azure, aby zapewnić ochronę danych. Ponieważ ruch replikacji znajduje się w chmurze platformy Azure, transfery odbywają się w bezpiecznej infrastrukturze sieci platformy Azure, która jest ograniczona w dostępie, aby zapobiec atakom polegającym na wąchaniu pakietów i atakom typu man-in-the-middle (podsłuchiwanie lub personifikacja między punktami końcowymi komunikacji). Ponadto ruch replikacji jest szyfrowany przy użyciu standardów TLS 1.2 zgodnych ze standardem FIPS 1.2. Aby uzyskać szczegółowe informacje, zobacz Często zadawane pytania dotyczące zabezpieczeń.

Szyfrowanie LDAP

Zwykle wyszukiwanie LDAP i powiązany ruch przechodzi przez sieć w postaci zwykłego tekstu, co oznacza, że każdy, kto ma dostęp do pakietów sieciowych sniff, może uzyskać informacje z serwera LDAP, takich jak nazwy użytkowników, identyfikatory liczbowe, członkostwa w grupach itp. Te informacje mogą następnie służyć do fałszowania użytkowników, wysyłania wiadomości e-mail na potrzeby ataków wyłudzających informacje itp.

Aby chronić komunikację LDAP przed przechwyceniem i odczytem, ruch LDAP może korzystać z szyfrowania za pośrednictwem komunikacji za pośrednictwem protokołu AES i TLS 1.2 za pośrednictwem podpisywania LDAP i protokołu LDAP za pośrednictwem protokołu TLS, odpowiednio. Aby uzyskać szczegółowe informacje na temat konfigurowania tych opcji, zobacz Tworzenie połączeń usługi Active Directory i zarządzanie nimi.

Podpisywanie LDAP

Podpisywanie LDAP jest specyficzne dla połączeń na serwerach usługi Microsoft Active Directory hostujących system UNIX tożsamości dla użytkowników i grup. Ta funkcja umożliwia weryfikację integralności dla protokołu LDAP (Simple Authentication and Security Layer, Simple Authentication and Security Layer) powiązanych z serwerami usługi AD obsługującymi połączenia LDAP. Podpisywanie nie wymaga konfiguracji certyfikatów zabezpieczeń, ponieważ używa komunikacji GSS-API z usługami Kerberos Key Distribution Center (KDC) usługi Active Directory. Podpisywanie LDAP sprawdza tylko integralność pakietu LDAP; nie szyfruje ładunku pakietu.

Podpisywanie LDAP można również skonfigurować po stronie serwera z systemem Windows za pośrednictwem zasad grupy, aby być oportunistyczne z podpisywaniem LDAP (brak — obsługa, jeśli jest to wymagane przez klienta) lub wymuszenie podpisywania LDAP (wymaga). Podpisywanie LDAP może dodać pewne obciążenie związane z wydajnością do ruchu LDAP, który zwykle nie jest zauważalny dla użytkowników końcowych.

Usługa Windows Active Directory umożliwia również używanie podpisywania i uszczelniania LDAP (kompleksowe szyfrowanie pakietów LDAP). Usługa Azure NetApp Files nie obsługuje tej funkcji.

Powiązanie kanału LDAP

Ze względu na lukę w zabezpieczeniach wykrytą na kontrolerach domeny usługi Windows Active Directory domyślne ustawienie zostało zmienione dla serwerów z systemem Windows. Aby uzyskać szczegółowe informacje, zobacz ADV190023 biuletynu zabezpieczeń firmy Microsoft.

Zasadniczo firma Microsoft zaleca administratorom włączenie podpisywania LDAP wraz z powiązaniem kanału. Jeśli klient LDAP obsługuje tokeny powiązania kanału i podpisywanie LDAP, wymagane są powiązania kanału i podpisywanie, a opcje rejestru są ustawiane przez nową poprawkę firmy Microsoft.

Usługa Azure NetApp Files domyślnie obsługuje powiązanie kanału LDAP odpowiednio, co oznacza, że powiązanie kanału LDAP jest używane, gdy klient go obsługuje. Jeśli powiązanie kanału nie jest obsługiwane/wysyłane, komunikacja jest nadal dozwolona, a powiązanie kanału nie jest wymuszane.

Ldap za pośrednictwem protokołu SSL (port 636)

Ruch LDAP w usłudze Azure NetApp Files przechodzi przez port 389 we wszystkich przypadkach. Nie można zmodyfikować tego portu. Protokół LDAP za pośrednictwem protokołu SSL (LDAPS) nie jest obsługiwany i jest uważany za starszy przez większości dostawców serwerów LDAP (RFC 1777 został opublikowany w 1995 roku). Jeśli chcesz użyć szyfrowania LDAP w usłudze Azure NetApp Files, użyj protokołu LDAP za pośrednictwem protokołu TLS.

Protokół LDAP przez usługę StartTLS

Protokół LDAP over StartTLS został wprowadzony z RFC 2830 w 2000 r. i został połączony ze standardem LDAPv3 z RFC 4511 w 2006 roku. Po utworzeniu standardu StartTLS dostawcy LDAP zaczęli odwoływać się do protokołu LDAPS jako przestarzałe.

Protokół LDAP przez usługę StartTLS używa portu 389 dla połączenia LDAP. Po nawiązaniu początkowego połączenia LDAP identyfikator OID startTLS jest wymieniany, a certyfikaty są porównywane; następnie cały ruch LDAP jest szyfrowany przy użyciu protokołu TLS. Przechwytywanie pakietów pokazane poniżej pokazuje powiązanie LDAP, uzgadnianie StartTLS i kolejny ruch LDAP zaszyfrowany za pomocą protokołu TLS.

Istnieją dwie główne różnice między protokołami LDAPS i StartTLS:

StartTLS jest częścią standardu LDAP; Protokół LDAPS nie jest. W związku z tym obsługa bibliotek LDAP na serwerach LDAP lub klientach może się różnić, a funkcjonalność może lub nie działa we wszystkich przypadkach.
Jeśli szyfrowanie nie powiedzie się, system StartTLS umożliwia skonfigurowanie powrotu do zwykłego protokołu LDAP. Protokół LDAPS nie. W związku z tym system StartTLS oferuje pewną elastyczność i odporność, ale również stwarza zagrożenia bezpieczeństwa, jeśli jest on nieprawidłowo skonfigurowany.

Zagadnienia dotyczące zabezpieczeń związane z protokołem LDAP przez usługę StartTLS

Usługa StartTLS umożliwia administratorom powrót do zwykłego ruchu LDAP, jeśli chcą. Dla celów bezpieczeństwa większość administratorów LDAP nie zezwala na to. Następujące zalecenia dotyczące protokołu StartTLS mogą pomóc w zabezpieczaniu komunikacji LDAP:

Upewnij się, że system StartTLS jest włączony i czy certyfikaty są skonfigurowane.
W przypadku środowisk wewnętrznych można użyć certyfikatów z podpisem własnym, ale w przypadku zewnętrznego protokołu LDAP użyj urzędu certyfikacji. Aby uzyskać więcej informacji na temat certyfikatów, zobacz Różnice między własnym podpisem SSL i urzędem certyfikacji.
Zapobiegaj zapytaniom LDAP i powiązaniom, które nie używają funkcji StartTLS. Domyślnie usługa Active Directory wyłącza powiązania anonimowe.

Połączenie zabezpieczeń usługi Active Directory

Połączenia usługi Active Directory z woluminami usługi Azure NetApp Files można skonfigurować tak, aby najpierw wypróbować najsilniejszy dostępny typ szyfrowania Kerberos: AES-256. Po włączeniu szyfrowania AES komunikacja kontrolera domeny (na przykład zaplanowane resetowanie haseł serwera SMB) używa najwyższego dostępnego typu szyfrowania obsługiwanego na kontrolerach domeny. Usługa Azure NetApp Files obsługuje następujące typy szyfrowania dla komunikacji kontrolera domeny w kolejności próby uwierzytelnienia: AES-256, AES-128, RC4-HMAC, DES

Uwaga

Nie można wyłączyć słabszych typów uwierzytelniania w usłudze Azure NetApp Files (takich jak RC4-HMAC i DES). Zamiast tego, jeśli jest to konieczne, należy je wyłączyć z kontrolera domeny, aby żądania uwierzytelniania nie próbowały ich używać. Jeśli rc4-HMAC jest wyłączony na kontrolerach domeny, szyfrowanie AES musi być włączone w usłudze Azure NetApp Files w celu zapewnienia prawidłowej funkcjonalności.

Udostępnij za pośrednictwem

Omówienie szyfrowania danych w usłudze Azure NetApp Files

Omówienie szyfrowania magazynowanych