Principy šifrování dat ve službě Azure NetApp Files
Azure NetApp Files šifruje data dvěma různými metodami:
- Šifrování neaktivních uložených dat: Data se šifrují na místě pomocí standardů kompatibilních se standardem FIPS 140-2.
- Šifrování během přenosu: Data se šifrují během přenosu nebo přes přenos mezi klientem a serverem.
Principy šifrování neaktivních uložených dat
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. Další informace najdete 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 povolená, všechny sdílené složky, které mají stejnou IP adresu, vyžadují šifrování, a tím přepsání nastavení vlastnosti sdílené složky SMB pro šifrování.
Šifrování na úrovni sdílené složky SMB
Případně můžete šifrování nastavit na úrovni jednotlivých sdílených složek svazku Azure NetApp Files.
Posílení zabezpečení 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.
Posílení zabezpečení UNC poskytuje tři možnosti zabezpečení cest UNC:
RequireMutualAuthentication– Vyžaduje se ověřování identity nebo nevyžaduje blokování útoků falš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 počáteční ověřování; vyžaduje pro přístup k exportu systému souborů NFS lístek Kerberos nebo přihlášení uživatele. Pakety NFS nejsou šifrované. - Kerberos 5i (
krb5i) – Počáteční ověřování a kontrola integrity; vyžaduje, aby lístek Kerberos pro přístup k exportu systému souborů NFS a přidal kontroly 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; kontrola integrity) trasování ukazuje, že pakety NFS nejsou šifrované, ale do paketu je přidaný obálka GSS/Kerberos, která vyžaduje, aby klient a server zajistily 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íhá přenosy v zabezpečené síťové infrastruktuře Azure, která je omezená na přístup, aby se zabránilo útokům na zašifrování paketů a útoku 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 PROTOKOLU LDAP před zachycením a čtením může provoz LDAP využívat šifrování přes kabel s využitím AES a TLS 1.2 prostřednictvím podepisování ldap a protokolu LDAP přes protokol 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í systém UNIX identit pro uživatele a skupiny. Tato funkce umožňuje ověřování integrity protokolu LDAP pro protokoly LDAP simple Authentication and Security Layer (SASL) na serverech AD, které hostují připojení LDAP. Podepisování nevyžaduje konfiguraci certifikátů zabezpečení, protože používá komunikaci GSS-API se službami služby 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í protokolu LDAP může do provozu PROTOKOLU LDAP přidat určitou režii výkonu, které obvykle nejsou pro koncové uživatele patrné.
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. PROTOKOL LDAP přes PROTOKOL SSL (LDAPS) se nepodporuje a většina dodavatelů serverů LDAP považuje za starší verzi (RFC 1777 byla publikována 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 vazbu protokolu LDAP, metodu handshake StartTLS a následný provoz PROTOKOLU 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.
Připojení zabezpečení služby 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
Poznámka:
Ve službě Azure NetApp Files (například RC4-HMAC a DES) není možné zakázat slabší typy ověřování. Místo toho by se v případě potřeby měly zakázat z řadiče domény, aby se žádosti o ověření nepokoušly použít. Pokud je na řadičích domény zakázaná analýza RC4-HMAC, musí být v Azure NetApp Files povolené šifrování AES, aby bylo možné správně používat.