Inzicht in gegevensversleuteling in Azure NetApp Files
Azure NetApp Files versleutelt gegevens via twee verschillende methoden:
- Versleuteling at-rest: gegevens worden ter plaatse versleuteld met behulp van FIPS 140-2-compatibele standaarden.
- Versleuteling tijdens overdracht: gegevens worden versleuteld tijdens overdracht of via de kabel, omdat deze worden overgedragen tussen de client en de server.
Versleuteling-at-rest begrijpen
Data-at-rest in Azure NetApp Files kan op twee manieren worden versleuteld:
- Eén versleuteling maakt gebruik van softwaregebaseerde versleuteling voor Azure NetApp Files-volumes.
- Dubbele versleuteling voegt versleuteling op hardwareniveau toe aan de fysieke opslagapparaatlaag.
Azure NetApp Files maakt gebruik van standaard CryptoMod om AES-256-versleutelingssleutels te genereren. CryptoMod wordt vermeld in de lijst met gevalideerde MODULES van CMVP FIPS 140-2. Zie FIPS 140-2Cert #4144 voor meer informatie. Versleutelingssleutels zijn gekoppeld aan de volumes en kunnen door het Microsoft-platform beheerde sleutels of door de klant beheerde sleutels zijn.
Informatie over versleuteling van gegevens in transit
Naast het beveiligen van data-at-rest, kan Azure NetApp Files gegevens beveiligen wanneer deze tussen eindpunten worden verzonden. De gebruikte versleutelingsmethode is afhankelijk van het protocol of de functie. DNS wordt niet versleuteld tijdens overdracht in Azure NetApp-bestanden. Lees verder voor meer informatie over SMB- en NFS-versleuteling, LDAP en gegevensreplicatie in Azure NetApp Files.
SMB-versleuteling
Windows SMB-clients die de SMB3.x-protocolversie gebruiken, bieden systeemeigen ondersteuning voor SMB-versleuteling. SMB-versleuteling wordt end-to-end uitgevoerd en versleutelt het volledige SMB-gesprek met behulp van cryptografische suites AES-256-GCM/AES-128-GCM en AES-256-CCM/AES-128-CCM.
SMB-versleuteling is niet vereist voor Azure NetApp Files-volumes, maar kan worden gebruikt voor extra beveiliging. SMB-versleuteling voegt wel een prestatieoverhead toe. Zie best practices voor SMB-prestaties voor Azure NetApp Files voor meer informatie over prestatieoverwegingen met SMB-versleuteling.
Versleuteling vereisen voor SMB-verbindingen
Azure NetApp Files biedt een optie om versleuteling af te dwingen voor alle SMB-verbindingen. Het afdwingen van versleuteling staat niet toe dat niet-versleutelde SMB-communicatie en maakt gebruik van SMB3 en hoger voor SMB-verbindingen. Versleuteling wordt uitgevoerd met behulp van AES-versleuteling en versleutelt alle SMB-pakketten. Voor een goede werking van deze functie moeten SMB-clients SMB-versleuteling ondersteunen. Als de SMB-client geen ondersteuning biedt voor versleuteling en SMB3, zijn SMB-verbindingen niet toegestaan. Als deze optie is ingeschakeld, vereisen alle shares met hetzelfde IP-adres versleuteling, waardoor de instelling voor de SMB-shareeigenschap voor versleuteling wordt overschreven.
Versleuteling op SMB-shareniveau
U kunt versleuteling ook instellen op het niveau van een afzonderlijke share van een Azure NetApp Files-volume.
UNC-beveiliging
In 2015 heeft Microsoft UNC-beveiliging (MS15-011 en MS15-014) geïntroduceerd om beveiligingsproblemen in het externe netwerkpad aan te pakken die het uitvoeren van externe code in SMB-shares mogelijk maken. Zie MS15-011 & MS15-014: Groepsbeleid beperken voor meer informatie.
UNC-beveiliging biedt drie opties voor het beveiligen van UNC-paden:
RequireMutualAuthentication– Identiteitsverificatie vereist/niet vereist om adresvervalsingsaanvallen te blokkeren.RequireIntegrity– Integriteitscontrole vereist/niet vereist om manipulatieaanvallen te blokkeren.RequirePrivacy– Privacy (totale versleuteling van SMB-pakketten) ingeschakeld/uitgeschakeld om verkeer sniffing te voorkomen.
Azure NetApp Files ondersteunt alle drie de vormen van UNC-beveiliging.
NFS Kerberos
Azure NetApp Files biedt ook de mogelijkheid om NFSv4.1-gesprekken te versleutelen via Kerberos-verificatie met AES-256-GCM/AES-128-GCM en AES-256-CCM/AES-128-CCM cryptografische suites.
Met NFS Kerberos ondersteunt Azure NetApp Files drie verschillende beveiligingssmaak:
- Kerberos 5 (
krb5) - Alleen initiële verificatie; vereist een Kerberos-ticketuitwisseling/gebruikersaanmelding voor toegang tot de NFS-export. NFS-pakketten worden niet versleuteld. - Kerberos 5i (
krb5i) - Eerste verificatie- en integriteitscontrole; vereist een Kerberos-ticketuitwisseling/gebruikersaanmelding voor toegang tot de NFS-export en voegt integriteitscontroles toe aan elk NFS-pakket om man-in-the-middle-aanvallen (MITM) te voorkomen. - Kerberos 5p (
krb5p) - Initiële verificatie, integriteitscontrole en privacy; vereist een Kerberos-ticketuitwisseling/gebruikersaanmelding voor toegang tot de NFS-export, voert integriteitscontroles uit en past een GSS-wrapper toe op elk NFS-pakket om de inhoud ervan te versleutelen.
Elk Kerberos-versleutelingsniveau heeft invloed op de prestaties. Naarmate de versleutelingstypen en beveiligingssmaak veiligere methoden bevatten, neemt het prestatie-effect toe. Presteert bijvoorbeeld krb5 beter dan krb5i, krb5i presteert beter dan krb5p, AES-128 presteren beter dan AES-256, enzovoort. Zie Prestatie-impact van Kerberos op Azure NetAppOs op Azure NetApp Files op Azure NetApp Files NFSv4.1-volumes voor meer informatie over het prestatie-effect van NFSv4.1.
Notitie
NFS Kerberos wordt alleen ondersteund met NFSv4.1 in Azure NetApp Files.
In de volgende afbeelding wordt Kerberos 5 (krb5) gebruikt. Alleen de initiële verificatieaanvraag (de aanmelding/ticketverwerving) wordt versleuteld. Alle andere NFS-verkeer komt binnen in tekst zonder opmaak.
Wanneer u Kerberos 5i (krb5i; integriteitscontrole) gebruikt, geeft een tracering aan dat de NFS-pakketten niet zijn versleuteld, maar er is een GSS-/Kerberos-wrapper toegevoegd aan het pakket waarvoor de client en server de integriteit van de gegevens moeten garanderen die worden overgedragen met behulp van een controlesom.
Kerberos 5p (privacy; krb5p) biedt end-to-end-versleuteling van alle NFS-verkeer, zoals wordt weergegeven in de traceringsafbeelding met behulp van een GSS/Kerberos-wrapper. Met deze methode wordt de meeste prestatieoverhead gemaakt vanwege de noodzaak om de versleuteling van elk NFS-pakket te verwerken.
Gegevensreplicatie
In Azure NetApp Files kunt u hele volumes repliceren tussen zones of regio's in Azure om gegevensbeveiliging te bieden. Omdat het replicatieverkeer zich in de Azure-cloud bevindt, vinden de overdrachten plaats in de beveiligde Azure-netwerkinfrastructuur, die beperkt is in de toegang om pakketsniffing en man-in-the-middle-aanvallen te voorkomen (afluisteren of imiteren tussen communicatie-eindpunten). Daarnaast wordt het replicatieverkeer versleuteld met FIPS 140-2-compatibele TLS 1.2-standaarden. Zie Veelgestelde vragen over beveiliging voor meer informatie.
LDAP-versleuteling
Normaal gesproken passeert LDAP-zoek- en bindverkeer via de kabel in tekst zonder opmaak, wat betekent dat iedereen met toegang tot sniff-netwerkpakketten informatie kan krijgen van de LDAP-server, zoals gebruikersnamen, numerieke id's, groepslidmaatschappen, enzovoort. Deze informatie kan vervolgens worden gebruikt om gebruikers te spoofen, e-mailberichten te verzenden voor phishingaanvallen, enzovoort.
Om LDAP-communicatie te beschermen tegen onderscheppen en lezen, kan LDAP-verkeer gebruikmaken van versleuteling via AES en TLS 1.2 via LDAP-ondertekening en LDAP via TLS. Zie Active Directory-verbindingen maken en beheren voor meer informatie over het configureren van deze opties.
LDAP-ondertekening
LDAP-ondertekening is specifiek voor verbindingen op Microsoft Active Directory-servers die UNIX-identiteiten hosten voor gebruikers en groepen. Met deze functionaliteit kan integriteitsverificatie voor SASL (Simple Authentication and Security Layer) LDAP worden gekoppeld aan AD-servers die LDAP-verbindingen hosten. Ondertekening vereist geen configuratie van beveiligingscertificaten omdat deze gebruikmaakt van GSS-API-communicatie met KDC-services (Kerberos Key Distribution Center) van Active Directory. LDAP-ondertekening controleert alleen de integriteit van een LDAP-pakket; de nettolading van het pakket wordt niet versleuteld.
LDAP-ondertekening kan ook worden geconfigureerd vanaf de Windows-serverzijde via groepsbeleid om opportunistisch te zijn met LDAP-ondertekening (geen: ondersteuning indien aangevraagd door de client) of om LDAP-ondertekening af te dwingen (vereist). LDAP-ondertekening kan enige overhead voor prestaties toevoegen aan LDAP-verkeer dat meestal niet merkbaar is voor eindgebruikers.
Met Windows Active Directory kunt u ook LDAP-ondertekening en -verzegeling gebruiken (end-to-end-versleuteling van LDAP-pakketten). Azure NetApp Files biedt geen ondersteuning voor deze functie.
LDAP-kanaalbinding
Vanwege een beveiligingsprobleem dat is gedetecteerd in Windows Active Directory-domeincontrollers, is er een standaardinstelling gewijzigd voor Windows-servers. Zie Microsoft Security Advisory ADV190023 voor meer informatie.
In wezen raadt Microsoft beheerders aan LDAP-ondertekening in te schakelen samen met kanaalbinding. Als de LDAP-client ondersteuning biedt voor kanaalbindingstokens en LDAP-ondertekening, zijn kanaalbinding en -ondertekening vereist en worden registeropties ingesteld door de nieuwe Microsoft-patch.
Azure NetApp Files biedt standaard ondersteuning voor LDAP-kanaalbinding opportunistisch, wat betekent dat LDAP-kanaalbinding wordt gebruikt wanneer de client dit ondersteunt. Als deze geen ondersteuning biedt voor/verzenden van kanaalbinding, is communicatie nog steeds toegestaan en wordt kanaalbinding niet afgedwongen.
LDAP via SSL (poort 636)
LDAP-verkeer in Azure NetApp Files passeert in alle gevallen poort 389. Deze poort kan niet worden gewijzigd. LDAP via SSL (LDAPS) wordt niet ondersteund en wordt beschouwd als verouderd door de meeste LDAP-serverleveranciers (RFC 1777 is gepubliceerd in 1995). Als u LDAP-versleuteling wilt gebruiken met Azure NetApp Files, gebruikt u LDAP via TLS.
LDAP via StartTLS
LDAP via StartTLS werd in 2000 geïntroduceerd met RFC 2830 en werd gecombineerd in de LDAPv3-standaard met RFC 4511 in 2006. Nadat StartTLS een standaard is gemaakt, begonnen LDAP-leveranciers te verwijzen naar LDAPS als afgeschaft.
LDAP via StartTLS maakt gebruik van poort 389 voor de LDAP-verbinding. Nadat de eerste LDAP-verbinding is gemaakt, wordt er een StartTLS OID uitgewisseld en worden certificaten vergeleken; vervolgens wordt al het LDAP-verkeer versleuteld met behulp van TLS. In de onderstaande pakketopname ziet u de LDAP-binding, de StartTLS-handshake en het daaropvolgende TLS-versleutelde LDAP-verkeer.
Er zijn twee belangrijke verschillen tussen LDAPS en StartTLS:
- StartTLS maakt deel uit van de LDAP-standaard; LDAPS is dat niet. Als gevolg hiervan kan de ondersteuning van LDAP-bibliotheken op de LDAP-servers of -clients variëren en werkt functionaliteit in alle gevallen mogelijk niet.
- Als versleuteling mislukt, kan met StartTLS de configuratie terugvallen op normale LDAP. LDAPS niet. Hierdoor biedt StartTLS enige flexibiliteit en tolerantie, maar ook beveiligingsrisico's als deze onjuist is geconfigureerd.
Beveiligingsoverwegingen met LDAP via StartTLS
Met StartTLS kunnen beheerders desgewenst terugvallen op gewoon LDAP-verkeer. Voor beveiligingsdoeleinden staan de meeste LDAP-beheerders dit niet toe. Met de volgende aanbevelingen voor StartTLS kunt u LDAP-communicatie beveiligen:
- Zorg ervoor dat StartTLS is ingeschakeld en dat certificaten zijn geconfigureerd.
- Voor interne omgevingen kunt u zelfondertekende certificaten gebruiken, maar voor externe LDAP een certificeringsinstantie gebruiken. Zie het verschil tussen zelfondertekende SSL en certificeringsinstantie voor meer informatie over certificaten.
- Voorkom LDAP-query's en bindingen die geen StartTLS gebruiken. Active Directory schakelt standaard anonieme bindingen uit.
Active Directory-beveiligingsverbinding
Active Directory-verbindingen met Azure NetApp Files-volumes kunnen worden geconfigureerd om eerst het sterkste beschikbare Kerberos-versleutelingstype te proberen: AES-256. Wanneer AES-versleuteling is ingeschakeld, wordt de communicatie van domeincontrollers (zoals geplande wachtwoordherstel van de SMB-server) gebruikt het maximaal beschikbare versleutelingstype dat wordt ondersteund op de domeincontrollers. Azure NetApp Files ondersteunt de volgende versleutelingstypen voor communicatie met domeincontrollers, in volgorde van poging tot verificatie: AES-256, AES-128, RC4-HMAC, DES
Notitie
Het is niet mogelijk om zwakkere verificatietypen uit te schakelen in Azure NetApp Files (zoals RC4-HMAC en DES). In plaats daarvan, indien gewenst, moeten deze worden uitgeschakeld vanaf de domeincontroller, zodat verificatieaanvragen deze niet proberen te gebruiken. Als RC4-HMAC is uitgeschakeld op de domeincontrollers, moet AES-versleuteling zijn ingeschakeld in Azure NetApp Files voor de juiste functionaliteit.