Az Azure NetApp Files adattitkosításának ismertetése

2024-02-14

Az Azure NetApp Files két különböző módszerrel titkosítja az adatokat:

Inaktív titkosítás: Az adatok helyben vannak titkosítva a FIPS 140-2 szabványnak megfelelő szabványokkal.
Átvitel közbeni titkosítás: Az adatok átvitel közben – vagy a vezetéken keresztül – titkosítva lesznek az ügyfél és a kiszolgáló között.

A inaktív titkosítás ismertetése

Az Azure NetApp Files inaktív adatai kétféleképpen titkosíthatók:

Az önálló titkosítás szoftveralapú titkosítást használ az Azure NetApp Files-kötetekhez.
A dupla titkosítás hardverszintű titkosítást ad hozzá a fizikai tárolóeszköz rétegében.

Az Azure NetApp Files standard CryptoMod használatával hoz létre AES-256 titkosítási kulcsokat. A CryptoMod szerepel a CMVP FIPS 140-2 érvényesített modulok listáján; további információ: FIPS 140-2 Tanúsítvány #4144. A titkosítási kulcsok a kötetekhez vannak társítva, és lehetnek Microsoft platform által felügyelt kulcsok vagy ügyfél által felügyelt kulcsok.

Az átvitel közbeni adattitkosítás ismertetése

Az inaktív adatok védelme mellett az Azure NetApp Files biztonságossá teheti az adatokat a végpontok közötti átvitel során is. A használt titkosítási módszer a protokolltól vagy szolgáltatástól függ. A DNS nincs titkosítva átvitel során az Azure NetApp fájlok esetében. További információ az Azure NetApp Files SMB- és NFS-titkosításáról, LDAP-járól és adatreplikálásáról.

SMB-titkosítás

Az SMB3.x protokollverziót használó Windows SMB-ügyfelek natív módon támogatják az SMB-titkosítást. Az SMB-titkosítás teljes körű, és az SMB-beszélgetés teljes egészét titkosítja az AES-256-GCM/AES-128-GCM és az AES-256-CCM/AES-128-CCM titkosítási csomagokkal.

Az SMB-titkosítás nem szükséges az Azure NetApp Files-kötetekhez, de további biztonság érdekében használható. Az SMB-titkosítás teljesítménybeli többletterhelést jelent. Az SMB-titkosítással kapcsolatos teljesítménnyel kapcsolatos szempontokról további információt az Azure NetApp Files SMB-teljesítményével kapcsolatos ajánlott eljárásokban talál.

Titkosítás megkövetelése SMB-kapcsolatokhoz

Az Azure NetApp Files lehetővé teszi a titkosítás kikényszerítését az összes SMB-kapcsolaton. A titkosítás kényszerítése letiltja a titkosítatlan SMB-kommunikációt, és SMB3 és újabb SMB-kapcsolatokat használ. A titkosítás AES-titkosítással történik, és az összes SMB-csomagot titkosítja. A funkció megfelelő működéséhez az SMB-ügyfeleknek támogatniuk kell az SMB-titkosítást. Ha az SMB-ügyfél nem támogatja a titkosítást és az SMB3-t, akkor az SMB-kapcsolatok nem lesznek engedélyezve. Ha ez a beállítás engedélyezve van, az azonos IP-címmel rendelkező összes megosztás titkosítást igényel, ami felülírja az SMB-megosztás tulajdonságbeállítását a titkosításhoz.

Másik lehetőségként a titkosítás az Azure NetApp Files-kötetek egyedi megosztási szintjén is beállítható.

UNC-megkeményítés

2015-ben a Microsoft unc hardeninget (MS15-011 és MS15-014) vezetett be a távoli hálózati útvonal biztonsági réseinek kezelésére, amelyek távoli kódfuttatást tehetnek lehetővé az SMB-megosztások között. További információ: MS15-011 &MS15-014: Hardening Group Policy.

Az UNC-megkeményedés három lehetőséget biztosít az UNC-útvonalak biztonságossá tételéhez:

RequireMutualAuthentication – Identitáshitelesítés szükséges/nem szükséges a hamisítási támadások letiltásához.
RequireIntegrity – Integritás-ellenőrzés szükséges/nem szükséges a illetéktelen módosítási támadások blokkolásához.
RequirePrivacy – Az adatvédelmet (az SMB-csomagok teljes titkosítását) engedélyezték vagy letiltották a forgalomszenvedés megakadályozása érdekében.

Az Azure NetApp Files támogatja az UNC-megerősítés mindhárom formáját.

NFS Kerberos

Az Azure NetApp Files emellett lehetővé teszi az NFSv4.1 beszélgetések titkosítását Kerberos-hitelesítéssel az AES-256-GCM/AES-128-GCM és az AES-256-CCM/AES-128-CCM titkosítási csomagokkal.

Az NFS Kerberos használatával az Azure NetApp Files három különböző biztonsági módot támogat:

Kerberos 5 (krb5) – Csak kezdeti hitelesítés; az NFS-exportálás eléréséhez Kerberos-jegycsere/felhasználói bejelentkezés szükséges. Az NFS-csomagok nincsenek titkosítva.
Kerberos 5i (krb5i) – Kezdeti hitelesítés és integritás-ellenőrzés; Kerberos-jegycsere/felhasználói bejelentkezés szükséges az NFS-exportálás eléréséhez, és minden NFS-csomaghoz integritás-ellenőrzéseket ad hozzá a középen belüli támadások (MITM) megakadályozása érdekében.
Kerberos 5p (krb5p) – Kezdeti hitelesítés, integritás-ellenőrzés és adatvédelem; Kerberos-jegycserét/felhasználói bejelentkezést igényel az NFS-exportálás eléréséhez, integritás-ellenőrzéseket végez, és GSS-burkolót alkalmaz minden NFS-csomagra annak tartalmának titkosításához.

Minden Kerberos-titkosítási szint hatással van a teljesítményre. Mivel a titkosítási típusok és a biztonsági ízek biztonságosabb módszereket tartalmaznak, a teljesítményhatás nő. Például a krb5 jobban teljesít, mint a krb5i, a krb5i jobban teljesít, mint a krb5p, az AES-128 jobban teljesít, mint az AES-256, és így tovább. Az NFS Kerberos Azure NetApp Filesban gyakorolt teljesítményhatásáról további információt a Kerberos teljesítményhatása az Azure NetApp Files NFSv4.1-köteteken című témakörben talál.

Megjegyzés:

Az NFS Kerberos csak az NFSv4.1-et támogatja az Azure NetApp Filesban.

Az alábbi képen a Kerberos 5 (krb5) van használatban; csak a kezdeti hitelesítési kérés (a bejelentkezés/jegyvásárlás) titkosítva van. Minden más NFS-forgalom egyszerű szövegben érkezik.

A Kerberos 5i (krb5i; integritás ellenőrzése) használatakor a nyomkövetés azt mutatja, hogy az NFS-csomagok nincsenek titkosítva, de hozzá van adva egy GSS/Kerberos burkoló a csomaghoz, amely megköveteli az ügyfél és a kiszolgáló számára az ellenőrzőösszeg használatával továbbított adatok integritását.

A Kerberos 5p (adatvédelem; krb5p) az összes NFS-forgalom teljes körű titkosítását biztosítja, ahogyan az a nyomkövetési képen látható egy GSS/Kerberos-burkoló használatával. Ez a metódus hozza létre a legnagyobb teljesítményterhelést, mivel minden NFS-csomag titkosításának feldolgozására van szükség.

Adatreplikáció

Az Azure NetApp Filesban teljes köteteket replikálhat az Azure zónáira vagy régióira az adatvédelem biztosítása érdekében. Mivel a replikációs forgalom az Azure-felhőben található, az átvitelek a biztonságos Azure hálózati infrastruktúrában történnek, amely korlátozott hozzáféréssel rendelkezik a csomagok szippantásának és a köztes támadások (a kommunikációs végpontok közötti lehallgatás vagy megszemélyesítés) megakadályozása érdekében. Emellett a replikációs forgalom a FIPS 140-2 szabványnak megfelelő TLS 1.2 szabványokkal van titkosítva. További részletekért tekintse meg a biztonsági gyakori kérdéseket.

LDAP-titkosítás

Az LDAP-keresési és kötési forgalom általában egyszerű szövegben halad át a vezetéken, ami azt jelenti, hogy bárki, aki hozzáfér a sniff hálózati csomagokhoz, információt szerezhet az LDAP-kiszolgálóról, például felhasználónevekről, numerikus azonosítókról, csoporttagságokról stb. Ezek az információk ezután felhasználhatók a felhasználók meghamisítására, e-mailek küldésére adathalász támadásokra stb.

Az LDAP-kommunikáció elfogásának és elolvasásának megelőzése érdekében az LDAP-forgalom a vonali AES- és TLS 1.2 titkosítást használhatja, LDAP-aláírás és LDAP a TLS felett alkalmazásával. A beállítások konfigurálásával kapcsolatos részletekért lásd: Active Directory-kapcsolatok létrehozása és kezelése.

LDAP-aláírás

Az LDAP-aláírás a felhasználók és csoportok UNIX-identitásait futtató Microsoft Active Directory-kiszolgálók kapcsolataira vonatkozik. Ez a funkció lehetővé teszi az egyszerű hitelesítési és biztonsági réteg (SASL) LDAP-kötéseinek integritás-ellenőrzését az LDAP-kapcsolatokat üzemeltető AD-kiszolgálókhoz. Az aláíráshoz nem szükséges biztonsági tanúsítványok konfigurálása, mert GSS-API kommunikációt használ az Active Directory Kerberos Key Distribution Center (KDC) szolgáltatásaival. Az LDAP-aláírás csak egy LDAP-csomag integritását ellenőrzi; nem titkosítja a csomag hasznos adatait.

Az LDAP-aláírás a Windows-kiszolgáló oldaláról csoportházirenden keresztül is konfigurálható úgy, hogy az LDAP-aláírással opportunista legyen (nincs – az ügyfél által igényelt támogatás), vagy az LDAP-aláírás kényszerítésére (kötelező). Az LDAP-aláírás teljesítménybeli többletterhelést okozhat az LDAP-forgalomban, amely általában nem észlelhető a végfelhasználók számára.

A Windows Active Directory lehetővé teszi az LDAP-aláírás és -zárolás használatát is (ldAP-csomagok végpontok közötti titkosítása). Az Azure NetApp Files nem támogatja ezt a funkciót.

LDAP-csatornakötés

A Windows Active Directory-tartományvezérlőkben felfedezett biztonsági rés miatt a Windows-kiszolgálók alapértelmezett beállítása módosult. További információ: Microsoft Security Advisory ADV190023.

A Microsoft lényegében azt javasolja, hogy a rendszergazdák engedélyezhessék az LDAP-aláírást és a csatornakötést. Ha az LDAP-ügyfél támogatja a csatornakötési jogkivonatokat és az LDAP-aláírást, csatornakötésre és -aláírásra van szükség, és a beállításjegyzék beállításait az új Microsoft-javítás állítja be.

Az Azure NetApp Files alapértelmezés szerint opportunista módon támogatja az LDAP-csatornakötést, ami azt jelenti, hogy az LDAP-csatornakötés akkor használatos, ha az ügyfél támogatja azt. Ha nem támogatja/küldi el a csatornakötést, a kommunikáció továbbra is engedélyezett, és a csatornakötés nincs kényszerítve.

LDAP SSL-en keresztül (636-os port)

Az Azure NetApp Files LDAP-forgalma minden esetben a 389-s porton halad át. Ez a port nem módosítható. Az SSL-en keresztüli LDAP (LDAPS) nem támogatott, és a legtöbb LDAP-kiszolgáló gyártó örököltnek tekinti (az RFC 1777-et 1995-ben tették közzé). Ha LDAP-titkosítást szeretne használni az Azure NetApp Files használatával, használja az LDAP-t a TLS-en keresztül.

LDAP a StartTLS-en keresztül

A StartTLS-en keresztüli LDAP-t 2000-ben vezették be az RFC 2830-mal , és 2006-ban az LDAPv3 szabványba és az RFC 4511-re egyesítették. Miután a StartTLS szabványsá vált, az LDAP-szállítók elavultként kezdték hivatkozni az LDAPS-et.

Az LDAP a StartTLS-en keresztül a 389-ös portot használja az LDAP-kapcsolathoz. A kezdeti LDAP-kapcsolat létrejötte után a rendszer egy StartTLS OID-t cserél, és összehasonlítja a tanúsítványokat; ezután az összes LDAP-forgalom TLS használatával lesz titkosítva. Az alábbi csomagrögzítés az LDAP-kötést, a StartTLS-kézfogást és az azt követő TLS-titkosított LDAP-forgalmat mutatja.

Az LDAPS és a StartTLS között két fő különbség van:

A StartTLS az LDAP szabvány része; Az LDAPS nem. Ennek eredményeképpen az LDAP-tár támogatása az LDAP-kiszolgálókon vagy -ügyfeleken eltérő lehet, és a funkciók minden esetben működhetnek vagy nem működnek.
Ha a titkosítás sikertelen, a StartTLS lehetővé teszi, hogy a konfiguráció visszatérjen a normál LDAP-ra. Az LDAPS nem. Ennek eredményeképpen a StartTLS némi rugalmasságot és rugalmasságot kínál, de biztonsági kockázatokat is jelent, ha helytelenül van konfigurálva.

Biztonsági szempontok a StartTLS-en keresztüli LDAP használatával

A StartTLS lehetővé teszi a rendszergazdák számára, hogy szükség esetén visszatérjenek a normál LDAP-forgalomhoz. Biztonsági okokból a legtöbb LDAP-rendszergazda nem engedélyezi. A StartTLS-hez a következő javaslatok segíthetnek az LDAP-kommunikáció biztonságossá tételében:

Győződjön meg arról, hogy a StartTLS engedélyezve van, és a tanúsítványok konfigurálva vannak.
Belső környezetekben használhat önaláírt tanúsítványokat, de külső LDAP esetén használjon hitelesítésszolgáltatót. A tanúsítványokról további információt az önaláírt SSL és a hitelesítésszolgáltató közötti különbség című témakörben talál.
Megakadályozza a StartTLS-t nem használó LDAP-lekérdezéseket és kötéseket. Alapértelmezés szerint az Active Directory letiltja a névtelen kötéseket.

Active Directory biztonsági kapcsolat

Az Azure NetApp Files-kötetekkel létesített Active Directory-kapcsolatok úgy konfigurálhatók, hogy először a legerősebb Kerberos-titkosítási típust próbálja ki: AES-256. Ha engedélyezve van az AES-titkosítás, a tartományvezérlő kommunikációja (például az ütemezett SMB-kiszolgáló jelszó-alaphelyzetbe állítása) a tartományvezérlők által támogatott legmagasabb rendelkezésre állású titkosítási típust használja. Az Azure NetApp Files a következő titkosítási típusokat támogatja a tartományvezérlői kommunikációhoz a hitelesítés megkísérlése érdekében: AES-256, AES-128, RC4-HMAC, DES