Principy šifrování dat ve službě Azure NetApp Files

Azure NetApp Files šifruje data dvěma různými metodami:

Šifrování dat v klidu: Data se šifrují na místě pomocí standardů kompatibilních s FIPS 140-2.
Šifrování během přenosu: Data jsou šifrována během přenosu nebo při samotném přenosu mezi klientem a serverem.

Principy šifrování dat za klidu

Neaktivní uložená data v Azure NetApp Files je možné zašifrovat dvěma způsoby:

Jedno šifrování používá softwarové šifrování pro svazky Azure NetApp Files.
Dvojité šifrování přidává šifrování na úrovni hardwaru na úrovni fyzického úložiště.

Azure NetApp Files používá k vygenerování šifrovacích klíčů AES-256 standardní CryptoMod. CryptoMod je uveden v seznamu ověřených modulů FIPS 140-2 CMVP; Další informace naleznete v tématu FIPS 140-2 Cert #4144. Šifrovací klíče jsou přidružené ke svazkům a mohou to být klíče spravované platformou Microsoftu nebo klíče spravované zákazníkem.

Principy šifrování přenášených dat

Kromě zabezpečení neaktivních uložených dat může Azure NetApp Files zabezpečit data při přenosu mezi koncovými body. Použitá metoda šifrování závisí na protokolu nebo funkci. DNS se v Azure NetApp files nešifruje během přenosu. Pokračujte ve čtení a seznamte se s šifrováním PROTOKOLU SMB a NFS, protokolem LDAP a replikací dat ve službě Azure NetApp Files.

Šifrování SMB

Klienti SMB systému Windows používající verzi protokolu SMB3.x nativně podporují šifrování SMB. Šifrování SMB se provádí uceleně a šifruje celou konverzaci SMB pomocí kryptografických sad AES-256-GCM/AES-128-GCM a AES-256-CCM/AES-128-CCM.

Pro svazky Azure NetApp Files není vyžadováno šifrování SMB, ale dá se použít k dalšímu zabezpečení. Šifrování SMB přidává režijní náklady na výkon. Další informace o aspektech výkonu při šifrování SMB najdete v osvědčených postupech pro výkon SMB pro Azure NetApp Files.

Vyžadování šifrování pro připojení SMB

Azure NetApp Files nabízí možnost vynutit šifrování u všech připojení SMB. Vynucení šifrování zakáže nešifrovanou komunikaci SMB a pro připojení SMB používá protokol SMB3 a novější. Šifrování se provádí pomocí šifrování AES a šifruje všechny pakety SMB. Aby tato funkce fungovala správně, musí klienti SMB podporovat šifrování SMB. Pokud klient SMB nepodporuje šifrování a SMB3, připojení SMB jsou zakázaná. Pokud je tato možnost povolena, všechny sdílené složky se stejnou IP adresou vyžadují šifrování, a tím přepíše nastavení vlastnosti sdílené složky SMB pro šifrování.

Případně můžete šifrování nastavit na úrovni jednotlivých sdílených složek svazku Azure NetApp Files.

Posílení zabezpečení sítě UNC

V roce 2015 společnost Microsoft zavedla posílení zabezpečení UNC (MS15-011 a MS15-014) za účelem řešení chyb zabezpečení vzdálených síťových cest, které by mohly umožnit vzdálené spuštění kódu napříč sdílenými složkami SMB. Další informace naleznete v tématu MS15-011 & MS15-014: Posílení zásad skupiny.

Zpevnění UNC poskytuje tři možnosti zabezpečení cest UNC:

RequireMutualAuthentication – K blokování útoků typu spoofing je vyžadováno/nevyžadováno ověřování identity.
RequireIntegrity – Kontrola integrity požadovaná/nepožadovaná k blokování útoků na manipulaci.
RequirePrivacy – Ochrana osobních údajů (celkové šifrování paketů SMB) povolená/zakázaná, aby se zabránilo zašifrování provozu.

Azure NetApp Files podporuje všechny tři formy posílení zabezpečení UNC.

NFS Kerberos

Azure NetApp Files také umožňuje šifrovat konverzace NFSv4.1 prostřednictvím ověřování kerberos pomocí kryptografických sad AES-256-GCM/AES-128-GCM a AES-256-CCM/AES-128-CCM.

S protokolem Kerberos NFS podporuje Azure NetApp Files tři různé varianty zabezpečení:

Kerberos 5 (krb5) – Pouze úvodní ověřování; pro přístup k exportu NFS je vyžadována výměna lístků Kerberos nebo přihlášení uživatele. Pakety NFS nejsou šifrované.
Kerberos 5i (krb5i) – Počáteční ověření a kontrola integrity. Vyžaduje výměnu lístků Kerberos a přihlášení uživatele pro přístup k exportu NFS a přidání kontrol integrity ke každému paketu NFS, aby se zabránilo útokům typu man-in-the-middle (MITM).
Kerberos 5p (krb5p) – Počáteční ověřování, kontrola integrity a ochrana osobních údajů; vyžaduje pro přístup k exportu systému souborů NFS lístek Kerberos nebo přihlášení uživatele, provádí kontroly integrity a používá obálku GSS pro každý paket NFS k šifrování jeho obsahu.

Každá úroveň šifrování Kerberos má vliv na výkon. Vzhledem k tomu, že typy šifrování a příchuť zabezpečení zahrnují bezpečnější metody, zvyšuje se účinek výkonu. Například krb5 funguje lépe než , krb5i funguje lépe než krb5ikrb5p, AES-128 funguje lépe než AES-256 atd. Další informace o výkonu protokolu Kerberos systému souborů NFS ve službě Azure NetApp Files najdete v tématu Dopad protokolu Kerberos na svazky Azure NetApp Files NFSv4.1.

Poznámka:

Protokol Kerberos nfs se podporuje jenom s NFSv4.1 ve službě Azure NetApp Files.

Na následujícím obrázku se používá Kerberos 5 (krb5), zašifruje se pouze počáteční žádost o ověření (získání přihlášení nebo lístku). Všechny ostatní přenosy NFS přicházejí ve formátu prostého textu.

Při použití protokolu Kerberos 5i (krb5i; kontrolování integrity) trasování ukazuje, že pakety NFS nejsou šifrované, ale do paketu je přidána obálka GSS/Kerberos, která vyžaduje, aby klient a server zajistili integritu přenášených dat pomocí kontrolního součtu.

Protokol Kerberos 5p (ochrana osobních údajů; krb5p) poskytuje kompletní šifrování veškerého provozu NFS, jak je znázorněno na obrázku trasování pomocí obálky GSS/Kerberos. Tato metoda vytváří největší režii na výkon kvůli nutnosti zpracovávat šifrování každého paketu NFS.

Replikace dat

V Azure NetApp Files můžete replikovat celé svazky napříč zónami nebo oblastmi v Azure, abyste zajistili ochranu dat. Vzhledem k tomu, že se provoz replikace nachází v cloudu Azure, probíhají přenosy v zabezpečené síťové infrastruktuře Azure s omezeným přístupem, aby se zabránilo odposlechu paketů a útokům man-in-the-middle (odposlouchávání nebo zosobnění mezi koncovými body komunikace). Kromě toho se provoz replikace šifruje pomocí standardů PROTOKOLU TLS 1.2 vyhovující standardu FIPS 140-2. Podrobnosti najdete v nejčastějších dotazech k zabezpečení.

Šifrování PROTOKOLU LDAP

Za normálních okolností probíhá prohledávání protokolu LDAP a svázání provozu přes drát v prostém textu, což znamená, že každý, kdo má přístup k síťovým paketům sniff, může získat informace ze serveru LDAP, jako jsou uživatelská jména, číselná ID, členství ve skupinách atd. Tyto informace se pak dají použít k falšování identity uživatelů, odesílání e-mailů za útoky phishing atd.

K ochraně komunikace LDAP před zachycením a čtením může provoz LDAP využívat šifrování během přenosu s využitím AES a TLS 1.2 prostřednictvím podepisování LDAP a LDAP přes TLS. Podrobnosti o konfiguraci těchto možností najdete v tématu Vytvoření a správa připojení služby Active Directory.

Podepisování protokolu LDAP

Podepisování protokolu LDAP je specifické pro připojení na serverech služby Microsoft Active Directory, které hostují identity systému UNIX pro uživatele a skupiny. Tato funkce umožňuje ověřování integrity pro LDAP vazby využívající Simple Authentication and Security Layer (SASL) na serverech Active Directory (AD), které hostují připojení LDAP. Podepisování nevyžaduje konfiguraci certifikátů zabezpečení, protože používá GSS-API komunikaci se službami KDC (Kerberos Key Distribution Center) služby Active Directory. Podepisování PROTOKOLU LDAP kontroluje pouze integritu paketu LDAP; nezašifruje datovou část paketu.

Podepisování PROTOKOLU LDAP je také možné nakonfigurovat na straně serveru Windows prostřednictvím zásad skupiny tak, aby buď byly oportunistické s podepisováním LDAP (žádné – podpora, pokud je požadována klientem), nebo vynucovat podepisování PROTOKOLU LDAP (vyžaduje). Podepisování LDAP může způsobit určitou režijní zátěž v provozu, což obvykle nebývá patrné pro koncové uživatele.

Služba Windows Active Directory také umožňuje používat podepisování a zapečetění protokolu LDAP (kompletní šifrování paketů LDAP). Azure NetApp Files tuto funkci nepodporuje.

Vazba kanálu LDAP

Kvůli ohrožení zabezpečení zjištěnému v řadičích domény služby Windows Active Directory se změnilo výchozí nastavení pro servery s Windows. Podrobnosti najdete v ADV190023 poradce microsoftu pro zabezpečení.

Microsoft v podstatě doporučuje, aby správci povolili podepisování LDAP společně s vazbou kanálu. Pokud klient LDAP podporuje tokeny vazeb kanálu a podepisování protokolu LDAP, vyžadují se vazby kanálů a podepisování a možnosti registru jsou nastaveny novou opravou Microsoftu.

Služba Azure NetApp Files ve výchozím nastavení podporuje oportunisticky vazbu kanálu LDAP, což znamená, že vazba kanálu LDAP se používá, když ji klient podporuje. Pokud nepodporuje nebo neodesílá vazbu kanálu, komunikace je stále povolená a vazba kanálu se nevynucuje.

LDAP přes SSL (port 636)

Provoz LDAP ve službě Azure NetApp Files ve všech případech prochází přes port 389. Tento port nelze změnit. LDAP přes SSL (LDAPS) není podporováno a většina dodavatelů serverů LDAP ho považuje za zastaralé (RFC 1777 byl publikován v roce 1995). Pokud chcete použít šifrování LDAP se službou Azure NetApp Files, použijte protokol LDAP přes protokol TLS.

LDAP přes StartTLS

PROTOKOL LDAP over StartTLS byl zaveden v rfC 2830 v roce 2000 a byl sloučen do standardu LDAPv3 s RFC 4511 v roce 2006. Po vytvoření standardu StartTLS začali dodavatelé LDAP odkazovat na LDAPS jako zastaralé.

Protokol LDAP přes StartTLS používá pro připojení LDAP port 389. Po provedení počátečního připojení LDAP se vymění identifikátor StartTLS a porovná se certifikáty; veškerý provoz PROTOKOLU LDAP se pak šifruje pomocí protokolu TLS. Zachytávání paketů uvedené níže ukazuje navázání protokolu LDAP, handshake pomocí StartTLS a následný provoz LDAP šifrovaný protokolem TLS.

Mezi protokoly LDAPS a StartTLS existují dva hlavní rozdíly:

StartTLS je součástí standardu LDAP; LDAPS není. V důsledku toho se podpora knihovny LDAP na serverech nebo klientech LDAP může lišit a funkce můžou nebo nemusí fungovat ve všech případech.
Pokud šifrování selže, startTLS umožňuje konfiguraci vrátit se do běžného protokolu LDAP. LDAPS ne. V důsledku toho startTLS nabízí určitou flexibilitu a odolnost, ale také představuje bezpečnostní rizika, pokud je chybně nakonfigurovaná.

Důležité informace o zabezpečení protokolu LDAP přes StartTLS

Funkce StartTLS umožňuje správcům vrátit se k běžnému provozu PROTOKOLU LDAP, pokud chtějí. Pro účely zabezpečení ho většina správců LDAP nepovoluje. Následující doporučení pro startTLS můžou pomoct zabezpečit komunikaci PROTOKOLU LDAP:

Ujistěte se, že je povolená služba StartTLS a jestli jsou nakonfigurované certifikáty.
V interních prostředích můžete používat certifikáty podepsané svým držitelem, ale pro externí LDAP použijte certifikační autoritu. Další informace o certifikátech najdete v tématu Rozdíl mezi certifikáty podepsaným svým držitelem a certifikační autoritou.
Zabráníte dotazům a vazbám protokolu LDAP, které nepoužívají hodnotu StartTLS. Ve výchozím nastavení služba Active Directory zakáže anonymní vazby.

Zabezpečené připojení k Active Directory

Připojení služby Active Directory se svazky Azure NetApp Files je možné nakonfigurovat tak, aby nejprve vyzkoušela nejsilnější dostupný typ šifrování Kerberos: AES-256. Pokud je povolené šifrování AES, komunikace řadiče domény (například plánované resetování hesla serveru SMB) používají nejvyšší dostupný typ šifrování podporovaný na řadičích domény. Azure NetApp Files podporuje následující typy šifrování pro komunikaci řadiče domény v pořadí pokusů o ověření: AES-256, AES-128, RC4-HMAC, DES