Förstå datakryptering i Azure NetApp Files
Azure NetApp Files krypterar data via två olika metoder:
- Kryptering i vila: Data krypteras på plats med FIPS 140-2-kompatibla standarder.
- Kryptering under överföring: Data krypteras under överföring – eller via kabeln – eftersom de överförs mellan klient och server.
Förstå kryptering i vila
Vilande data i Azure NetApp Files kan krypteras på två sätt:
- Enkel kryptering använder programvarubaserad kryptering för Azure NetApp Files-volymer.
- Dubbel kryptering lägger till kryptering på maskinvarunivå på det fysiska lagringsenhetsskiktet.
Azure NetApp Files använder Standard CryptoMod för att generera AES-256-krypteringsnycklar. CryptoMod finns med i listan med CMVP FIPS 140-2-verifierade moduler. Mer information finns i FIPS 140-2 Cert #4144. Krypteringsnycklar är associerade med volymerna och kan vara Microsofts plattformshanterade nycklar eller kundhanterade nycklar.
Förstå datakryptering under överföring
Förutom att skydda vilande data kan Azure NetApp Files skydda data när de överförs mellan slutpunkter. Vilken krypteringsmetod som används beror på protokollet eller funktionen. DNS krypteras inte under överföring i Azure NetApp-filer. Fortsätt läsa för att lära dig mer om SMB- och NFS-kryptering, LDAP och datareplikering i Azure NetApp Files.
SMB-kryptering
Windows SMB-klienter som använder SMB3.x-protokollversionen har inbyggt stöd för SMB-kryptering. SMB-kryptering utförs från slutpunkt till slutpunkt och krypterar hela SMB-konversationen med hjälp av krypteringssviterna AES-256-GCM/AES-128-GCM och AES-256-CCM/AES-128-CCM.
SMB-kryptering krävs inte för Azure NetApp Files-volymer, men kan användas för extra säkerhet. SMB-kryptering lägger till prestandakostnader. Mer information om prestandaöverväganden med SMB-kryptering finns i metodtips för SMB-prestanda för Azure NetApp Files.
Kräver kryptering för SMB-anslutningar
Azure NetApp Files tillhandahåller ett alternativ för att framtvinga kryptering på alla SMB-anslutningar. Framtvinga kryptering tillåter inte okrypterad SMB-kommunikation och använder SMB3 och senare för SMB-anslutningar. Kryptering utförs med hjälp av AES-kryptering och krypterar alla SMB-paket. För att den här funktionen ska fungera korrekt måste SMB-klienterna ha stöd för SMB-kryptering. Om SMB-klienten inte stöder kryptering och SMB3 tillåts inte SMB-anslutningar. Om det här alternativet är aktiverat kräver alla resurser som har samma IP-adress kryptering, vilket åsidosätter inställningen för SMB-resursegenskap för kryptering.
SMB-kryptering på resursnivå
Alternativt kan kryptering ställas in på nivån för enskilda delar av en Azure NetApp Files-volym.
UNC-härdning
2015 introducerade Microsoft UNC-härdning (MS15-011 och MS15-014) för att hantera sårbarheter för fjärrnätverkssökväg som kan tillåta fjärrkörning av kod mellan SMB-resurser. Mer information finns i MS15-011 & MS15-014: Härdning av grupprincip.
UNC-härdning innehåller tre alternativ för att skydda UNC-sökvägar:
RequireMutualAuthentication– Identitetsautentisering krävs/krävs inte för att blockera förfalskningsattacker.RequireIntegrity– Integritetskontroll krävs/krävs inte för att blockera manipuleringsattacker.RequirePrivacy– Sekretess (total kryptering av SMB-paket) aktiverat/inaktiverat för att förhindra trafiksniffning.
Azure NetApp Files stöder alla tre formerna av UNC-härdning.
NFS Kerberos
Azure NetApp Files ger också möjlighet att kryptera NFSv4.1-konversationer via Kerberos-autentisering med hjälp av krypteringssviterna AES-256-GCM/AES-128-GCM och AES-256-CCM/AES-128-CCM.
Med NFS Kerberos stöder Azure NetApp Files tre olika säkerhetssmaker:
- Kerberos 5 (
krb5) – Endast inledande autentisering. Kräver ett Kerberos-biljettutbyte/användarinloggning för att få åtkomst till NFS-exporten. NFS-paket krypteras inte. - Kerberos 5i (
krb5i) – Inledande autentisering och integritetskontroll. Kräver ett Kerberos-biljettutbyte/användarinloggning för att få åtkomst till NFS-exporten och lägger till integritetskontroller i varje NFS-paket för att förhindra man-in-the-middle-attacker (MITM). - Kerberos 5p (
krb5p) – Inledande autentisering, integritetskontroll och sekretess. Kräver ett Kerberos-biljettutbyte/användarinloggning för att få åtkomst till NFS-exporten, utför integritetskontroller och tillämpar en GSS-omslutning på varje NFS-paket för att kryptera innehållet.
Varje Kerberos-krypteringsnivå påverkar prestandan. Eftersom krypteringstyperna och säkerhetssmakerna innehåller säkrare metoder ökar prestandaeffekten. Presterar till exempel krb5 bättre än krb5i, krb5i presterar bättre än krb5p, AES-128 presterar bättre än AES-256 och så vidare. Mer information om prestandaeffekten för NFS Kerberos i Azure NetApp Files finns i Prestandapåverkan av Kerberos på Azure NetApp Files NFSv4.1-volymer.
Kommentar
NFS Kerberos stöds endast med NFSv4.1 i Azure NetApp Files.
I följande bild används Kerberos 5 (krb5) och endast den första autentiseringsbegäran (inloggningen/biljettförvärvet) krypteras. All annan NFS-trafik kommer i oformaterad text.
När du använder Kerberos 5i (krb5i; integritetskontroll) visar en spårning att NFS-paketen inte är krypterade, men det finns en GSS/Kerberos-omslutning som läggs till i paketet som kräver att klienten och servern säkerställer integriteten för de data som överförs med hjälp av en kontrollsumma.
Kerberos 5p (sekretess; krb5p) tillhandahåller kryptering från slutpunkt till slutpunkt för all NFS-trafik som visas i spårningsbilden med hjälp av en GSS/Kerberos-omslutning. Den här metoden skapar mest prestandakostnader på grund av behovet av att bearbeta varje NFS-pakets kryptering.
Datareplikering
I Azure NetApp Files kan du replikera hela volymer mellan zoner eller regioner i Azure för att tillhandahålla dataskydd. Eftersom replikeringstrafiken finns i Azure-molnet sker överföringarna i den säkra Azure-nätverksinfrastrukturen, som är begränsad i åtkomst för att förhindra paketsniffning och man-in-the-middle-attacker (avlyssning eller personifiering mellan kommunikationsslutpunkter). Dessutom krypteras replikeringstrafiken med FIPS 140-2-kompatibla TLS 1.2-standarder. Mer information finns i Vanliga frågor och svar om säkerhet.
LDAP-kryptering
Normalt passerar LDAP-sökning och bindningstrafik över kabeln i oformaterad text, vilket innebär att alla som har åtkomst till sniffning av nätverkspaket kan få information från LDAP-servern, till exempel användarnamn, numeriska ID:n, gruppmedlemskap osv. Den här informationen kan sedan användas för att förfalska användare, skicka e-postmeddelanden för nätfiskeattacker osv.
För att skydda LDAP-kommunikation från att fångas upp och läsas kan LDAP-trafik utnyttja kryptering över kabel med hjälp av AES och TLS 1.2 via LDAP-signering respektive LDAP över TLS. Mer information om hur du konfigurerar dessa alternativ finns i Skapa och hantera Active Directory-anslutningar.
LDAP-signering
LDAP-signering är specifikt för anslutningar på Microsoft Active Directory-servrar som är värdar för UNIX-identiteter för användare och grupper. Den här funktionen möjliggör integritetsverifiering för SASL(Simple Authentication and Security Layer) LDAP-bindningar till AD-servrar som är värdar för LDAP-anslutningar. Signering kräver inte konfiguration av säkerhetscertifikat eftersom det använder GSS-API-kommunikation med Active Directorys Kerberos Key Distribution Center-tjänster (KDC). LDAP-signering kontrollerar endast integriteten för ett LDAP-paket. det krypterar inte nyttolasten för paketet.
LDAP-signering kan också konfigureras från Windows-serversidan via grupprincip för att antingen vara opportunistisk med LDAP-signering (ingen – stöd om det begärs av klienten) eller för att framtvinga LDAP-signering (kräv). LDAP-signering kan lägga till prestandakostnader för LDAP-trafik som vanligtvis inte är märkbar för slutanvändarna.
Med Windows Active Directory kan du också använda LDAP-signering och -tätning (kryptering från slutpunkt till slutpunkt för LDAP-paket). Azure NetApp Files stöder inte den här funktionen.
LDAP-kanalbindning
På grund av en säkerhetsrisk som upptäckts i Windows Active Directory-domänkontrollanter ändrades en standardinställning för Windows-servrar. Mer information finns i Microsoft Security Advisory ADV190023.
I princip rekommenderar Microsoft att administratörer aktiverar LDAP-signering tillsammans med kanalbindning. Om LDAP-klienten stöder kanalbindningstoken och LDAP-signering krävs kanalbindning och signering, och registeralternativ anges av den nya Microsoft-korrigeringen.
Azure NetApp Files stöder som standard LDAP-kanalbindning opportunistiskt, vilket innebär att LDAP-kanalbindning används när klienten stöder den. Om den inte stöder/skickar kanalbindning tillåts fortfarande kommunikation och kanalbindningen tillämpas inte.
LDAP över SSL (port 636)
LDAP-trafik i Azure NetApp Files passerar i samtliga fall port 389. Det går inte att ändra den här porten. LDAP över SSL (LDAPS) stöds inte och anses vara äldre av de flesta LDAP-serverleverantörer (RFC 1777 publicerades 1995). Om du vill använda LDAP-kryptering med Azure NetApp Files använder du LDAP via TLS.
LDAP över StartTLS
LDAP över StartTLS introducerades med RFC 2830 2000 och kombinerades till LDAPv3-standarden med RFC 4511 2006. När StartTLS blev en standard började LDAP-leverantörer referera till LDAPS som inaktuella.
LDAP över StartTLS använder port 389 för LDAP-anslutningen. När den första LDAP-anslutningen har upprättats utbyts en StartTLS-OID och certifikat jämförs. sedan krypteras all LDAP-trafik med hjälp av TLS. Paketinsamlingen som visas nedan visar LDAP-bindningen, StartTLS-handskakningen och efterföljande TLS-krypterad LDAP-trafik.
Det finns två huvudsakliga skillnader mellan LDAPS och StartTLS:
- StartTLS är en del av LDAP-standarden. LDAPS är det inte. Därför kan LDAP-bibliotekssupporten på LDAP-servrarna eller klienterna variera, och funktionaliteten kanske inte fungerar i alla fall.
- Om krypteringen misslyckas tillåter StartTLS att konfigurationen återgår till vanlig LDAP. LDAPS gör det inte. Därför erbjuder StartTLS viss flexibilitet och återhämtning, men det medför även säkerhetsrisker om det är felkonfigurerat.
Säkerhetsöverväganden med LDAP över StartTLS
StartTLS gör det möjligt för administratörer att återgå till vanlig LDAP-trafik om de vill. Av säkerhetsskäl tillåter de flesta LDAP-administratörer inte det. Följande rekommendationer för StartTLS kan hjälpa till att skydda LDAP-kommunikation:
- Kontrollera att StartTLS är aktiverat och att certifikat har konfigurerats.
- För interna miljöer kan du använda självsignerade certifikat, men för extern LDAP använder du en certifikatutfärdare. Mer information om certifikat finns i Skillnaden mellan självsignerad SSL och certifikatutfärdare.
- Förhindra LDAP-frågor och bindningar som inte använder StartTLS. Som standard inaktiverar Active Directory anonyma bindningar.
Active Directory-säkerhetsanslutning
Active Directory-anslutningar med Azure NetApp Files-volymer kan konfigureras för att prova den starkaste tillgängliga Kerberos-krypteringstypen först: AES-256. När AES-kryptering är aktiverat använder domänkontrollantkommunikation (till exempel schemalagda SMB-serverlösenordåterställningar) den högsta tillgängliga krypteringstypen som stöds på domänkontrollanterna. Azure NetApp Files stöder följande krypteringstyper för domänkontrollantkommunikation i autentiseringsordning: AES-256, AES-128, RC4-HMAC, DES
Kommentar
Det går inte att inaktivera svagare autentiseringstyper i Azure NetApp Files (till exempel RC4-HMAC och DES). Om så önskas bör dessa inaktiveras från domänkontrollanten så att autentiseringsbegäranden inte försöker använda dem. Om RC4-HMAC är inaktiverat på domänkontrollanterna måste AES-kryptering aktiveras i Azure NetApp Files för att få rätt funktioner.