Grundlegendes zur Datenverschlüsselung in Azure NetApp-Dateien

Azure NetApp Files verschlüsselt Daten über zwei verschiedene Methoden:

Verschlüsselung ruhender Daten: Daten werden auf dem Speicher mithilfe von FIPS 140-2-konformen Standards verschlüsselt.
Verschlüsselung während der Übertragung: Daten werden während der Übertragung verschlüsselt – oder über das Netzwerk – während sie zwischen Client und Server übertragen werden.

Verständnis der Datenverschlüsselung im Ruhezustand

Ruhende Daten in Azure NetApp-Dateien können auf zwei Arten verschlüsselt werden:

Die einzelne Verschlüsselung verwendet softwarebasierte Verschlüsselung für Azure NetApp Files-Volumes.
Die doppelte Verschlüsselung fügt verschlüsselung auf Hardwareebene auf der physischen Speichergeräteebene hinzu.

Azure NetApp Files verwendet standardmäßige CryptoMod zum Generieren von AES-256-Verschlüsselungsschlüsseln. CryptoMod ist in der LISTE der CMVP FIPS 140-2 validierten Module aufgeführt; weitere Informationen finden Sie unter FIPS 140-2 Cert #4144. Verschlüsselungsschlüssel sind den Volumes zugeordnet und können von Microsoft plattformverwaltete Schlüssel oder vom Kunden verwaltete Schlüssel sein.

Verständnis der Verschlüsselung von Daten während der Übertragung

Zusätzlich zum Sichern ruhender Daten können Azure NetApp Files Daten sichern, wenn sie zwischen Endpunkten übertragen werden. Die verwendete Verschlüsselungsmethode hängt vom Protokoll oder Feature ab. DNS wird beim Übertragen in Azure NetApp-Dateien nicht verschlüsselt. Lesen Sie weiter, um mehr über SMB- und NFS-Verschlüsselung, LDAP und Datenreplikation in Azure NetApp Files zu erfahren.

SMB-Verschlüsselung

Windows-SMB-Clients, die die SMB3.x-Protokollversion verwenden, unterstützen systemeigene SMB-Verschlüsselung. SMB-Verschlüsselung wird End-to-End durchgeführt und verschlüsselt die gesamte SMB-Unterhaltung mit kryptografischen AES-256-GCM/AES-128-GCM- und AES-256-CCM/AES-128-CCM-Suites.

SMB-Verschlüsselung ist für Azure NetApp Files-Volumes nicht erforderlich, kann jedoch für zusätzliche Sicherheit verwendet werden. Die SMB-Verschlüsselung führt zu einem Leistungsaufwand. Weitere Informationen zu Leistungsaspekten bei der SMB-Verschlüsselung finden Sie unter bewährte Methoden zur SMB-Leistung für Azure NetApp Files.

Erfordern einer Verschlüsselung für SMB-Verbindungen

Azure NetApp Files bietet eine Option zum Erzwingen der Verschlüsselung für alle SMB-Verbindungen. Das Erzwingen der Verschlüsselung verbietet unverschlüsselte SMB-Kommunikation und verwendet SMB3 und höher für SMB-Verbindungen. Verschlüsselung wird mit der AES-Verschlüsselung durchgeführt und verschlüsselt alle SMB-Pakete. Damit dieses Feature ordnungsgemäß funktioniert, müssen SMB-Clients die SMB-Verschlüsselung unterstützen. Wenn der SMB-Client verschlüsselung und SMB3 nicht unterstützt, sind SMB-Verbindungen unzulässig. Wenn diese Option aktiviert ist, benötigen alle Freigaben, welche dieselbe IP-Adresse haben, eine Verschlüsselung, wodurch die SMB-Freigabeeigenschaftseinstellung für die Verschlüsselung außer Kraft gesetzt wird.

Alternativ kann die Verschlüsselung auf der Ebene von individuellen Freigaben eines Azure NetApp Files-Volumes festgelegt werden.

UNC-Härtung

Im Jahr 2015 hat Microsoft die UNC-Härtung (MS15-011 und MS15-014) eingeführt, um Sicherheitsrisiken für Remotenetzwerkpfade zu beheben, die die Remotecodeausführung über SMB-Freigaben hinweg ermöglichen könnten. Weitere Informationen finden Sie unter MS15-011 & MS15-014: Härtung der Gruppenrichtlinie.

Die UNC-Härtung bietet drei Optionen zum Sichern von UNC-Pfaden:

RequireMutualAuthentication – Die Identitätsauthentifizierung ist erforderlich/nicht erforderlich, um Spoofingangriffe zu blockieren.
RequireIntegrity – Integritätsprüfung erforderlich/nicht erforderlich, um Manipulationsangriffe zu blockieren.
RequirePrivacy – Datenschutz (totale Verschlüsselung von SMB-Paketen) aktiviert/deaktiviert, um das Sniffing des Datenverkehrs zu verhindern.

Azure NetApp Files unterstützt alle drei Formen der UNC-Härtung.

NFS Kerberos

Azure NetApp Files bietet außerdem die Möglichkeit, NFSv4.1-Unterhaltungen über die Kerberos-Authentifizierung mithilfe von AES-256-GCM/AES-128-GCM und AES-256-CCM/AES-128-CCM-Kryptografiesammlungen zu verschlüsseln.

Mit NFS Kerberos unterstützt Azure NetApp Files drei verschiedene Sicherheitsstufen:

Kerberos 5 (krb5) – Nur ursprüngliche Authentifizierung; erfordert eine Kerberos-Ticketaustausch-/Benutzeranmeldung für den Zugriff auf den NFS-Export. NFS-Pakete sind nicht verschlüsselt.
Kerberos 5i (krb5i) – Anfängliche Authentifizierung und Integritätsprüfung; erfordert eine Kerberos-Ticketaustausch-/Benutzeranmeldung für den Zugriff auf den NFS-Export und fügt Integritätsprüfungen zu jedem NFS-Paket hinzu, um Man-in-the-Middle-Angriffe (MITM) zu verhindern.
Kerberos 5p (krb5p) – Anfängliche Authentifizierung, Integritätsprüfung und Datenschutz; erfordert eine Kerberos-Ticketaustausch-/Benutzeranmeldung für den Zugriff auf den NFS-Export, führt Integritätsprüfungen durch und wendet einen GSS-Wrapper auf jedes NFS-Paket an, um seine Inhalte zu verschlüsseln.

Jede Kerberos-Verschlüsselungsebene wirkt sich auf die Leistung aus. Je mehr sichere Methoden in die Verschlüsselungstypen und Sicherheitsvarianten einfließen, desto größer ist die Wirkung auf die Leistung. Beispielsweise zeigt krb5 eine bessere Leistung als krb5i, krb5i funktioniert besser als krb5p, AES-128 funktioniert besser als AES-256, und so weiter. Weitere Informationen zur Leistungsbeeinflussung von NFS Kerberos in Azure NetApp Files finden Sie unter Leistungsauswirkung von Kerberos auf Azure NetApp Files NFSv4.1-Volumes.

Hinweis

NFS Kerberos wird nur mit NFSv4.1 in Azure NetApp Files unterstützt.

In der folgenden Abbildung wird Kerberos 5 (krb5) verwendet. Nur die anfängliche Authentifizierungsanforderung (anmeldung/Ticketerwerb) wird verschlüsselt. Der gesamte restliche NFS-Datenverkehr geht als Nur-Text ein.

Bei Verwendung von Kerberos 5i (krb5i; Integritätsprüfung) zeigt eine Analyse, dass die NFS-Pakete nicht verschlüsselt sind, dem Paket jedoch ein GSS/Kerberos-Wrapper hinzugefügt wird, der von beiden, Client und Server, verlangt, die Integrität der übertragenen Daten mit einer Prüfsumme sicherzustellen.

Kerberos 5p (Datenschutz; krb5p) ermöglicht die End-to-End-Verschlüsselung des gesamten NFS-Datenverkehrs, wie im Verfolgungsbild mit einem GSS/Kerberos-Wrapper dargestellt. Diese Methode erzeugt den leistungsstärksten Aufwand, da die Verschlüsselung jedes NFS-Pakets verarbeitet werden muss.

Datenreplikation

In Azure NetApp Files können Sie ganze Volumes über Zonen oder Regionen in Azure replizieren, um Datenschutz bereitzustellen. Da sich der Replikationsdatenverkehr in der Azure-Cloud befindet, erfolgen die Übertragungen in der sicheren Azure-Netzwerkinfrastruktur, die im Zugriff beschränkt ist, um Paketsuch- und Man-in-the-Middle-Angriffe (Lauschangriffe oder Identitätswechsel zwischen Kommunikationsendpunkten) zu verhindern. Darüber hinaus wird der Replikationsdatenverkehr mit FIPS 140-2-kompatiblen TLS 1.2-Standards verschlüsselt. Ausführliche Informationen finden Sie in den häufig gestellten Fragen zur Sicherheit.

LDAP-Verschlüsselung

Normalerweise erfolgt der LDAP-Such- und Bindungsdatenverkehr über das Netzwerk im Klartext, was bedeutet, dass jeder mit Zugriff auf das Sniffen der Netzwerkpakete Informationen vom LDAP-Server wie Benutzernamen, numerische IDs, Gruppenmitgliedschaften usw. erhalten kann. Diese Informationen können dann verwendet werden, um Benutzer zu täuschen, E-Mails für Phishingangriffe zu senden usw.

Um zu schützen, dass LDAP-Kommunikation abgefangen und gelesen wird, kann LDAP-Datenverkehr die Over-the-Wire-Verschlüsselung nutzen, die AES und TLS 1.2 über LDAP-Signierung bzw. LDAP über TLS nutzt. Ausführliche Informationen zum Konfigurieren dieser Optionen finden Sie unter Erstellen und Verwalten von Active Directory-Verbindungen.

LDAP-Signatur

Die LDAP-Signatur ist spezifisch für Verbindungen auf Microsoft Active Directory-Servern, die UNIX-Identitäten für Benutzer und Gruppen hosten. Diese Funktionalität ermöglicht die Integritätsüberprüfung für SASL-LDAP-Bindungen an AD-Server, die LDAP-Verbindungen hosten. Die Signatur erfordert keine Konfiguration von Sicherheitszertifikaten, da die GSS-API-Kommunikation mit den Kerberos Key Distribution Center (KDC)-Diensten von Active Directory genutzt wird. Die LDAP-Signatur überprüft nur die Integrität eines LDAP-Pakets; die Nutzlast des Pakets wird nicht verschlüsselt.

Die LDAP-Signatur kann auch von der Windows-Serverseite über Gruppenrichtlinien so konfiguriert werden, dass sie entweder opportunistisch mit LDAP-Signierung (keine – Unterstützung, falls vom Client angefordert) oder zum Erzwingen der LDAP-Signatur (erforderlich) konfiguriert werden. Die LDAP-Signatur kann dem LDAP-Datenverkehr, der in der Regel für Endbenutzer nicht erkennbar ist, einen Leistungsaufwand hinzufügen.

Mit Windows Active Directory können Sie auch LDAP-Signatur und -Versiegelung (End-to-End-Verschlüsselung von LDAP-Paketen) verwenden. Azure NetApp Files unterstützt dieses Feature nicht.

LDAP-Kanalbindung

Aufgrund einer in Windows Active Directory-Domänencontrollern entdeckten Sicherheitslücke wurde eine Standardeinstellung für Windows-Server geändert. Ausführliche Informationen finden Sie unter Microsoft Security Advisory ADV190023.

Im Wesentlichen empfiehlt Microsoft Administratoren, die LDAP-Signatur zusammen mit der Kanalbindung zu aktivieren. Wenn der LDAP-Client Kanalbindungstoken und LDAP-Signatur unterstützt, sind Kanalbindung und Signierung erforderlich, und Registrierungsoptionen werden vom neuen Microsoft-Patch festgelegt.

Azure NetApp Files unterstützt standardmäßig die LDAP-Kanalbindung opportunistisch, was bedeutet, dass die LDAP-Kanalbindung verwendet wird, wenn der Client sie unterstützt. Wenn die Kanalbindung nicht unterstützt/gesendet wird, ist die Kommunikation weiterhin zulässig, und die Kanalbindung wird nicht erzwungen.

LDAP über SSL (Port 636)

Der LDAP-Datenverkehr in Azure NetApp Files läuft über Port 389 in allen Fällen. Dieser Port kann nicht geändert werden. LDAP über SSL (LDAPS) wird nicht unterstützt und gilt als Legacyversion der meisten LDAP-Serveranbieter (RFC 1777 wurde 1995 veröffentlicht). Wenn Sie die LDAP-Verschlüsselung mit Azure NetApp Files verwenden möchten, verwenden Sie LDAP über TLS.

LDAP über StartTLS

LDAP over StartTLS wurde 2000 mit RFC 2830 eingeführt und 2006 in den LDAPv3-Standard mit RFC 4511 kombiniert. Nachdem StartTLS als Standard festgelegt wurde, begannen LDAP-Anbieter, auf LDAPS als veraltet zu verweisen.

LDAP über StartTLS verwendet Port 389 für die LDAP-Verbindung. Nachdem die erste LDAP-Verbindung hergestellt wurde, wird ein StartTLS-OID ausgetauscht und Zertifikate verglichen; dann wird der gesamte LDAP-Datenverkehr mithilfe von TLS verschlüsselt. Die unten gezeigte Paketaufnahme zeigt die LDAP-Bindung, den StartTLS-Handshake und nachfolgenden TLS-verschlüsselten LDAP-Datenverkehr.

Es gibt zwei Hauptunterschiede zwischen LDAPS und StartTLS:

StartTLS ist Teil des LDAP-Standards; LDAPS ist nicht vorhanden. Daher kann die LDAP-Bibliotheksunterstützung auf den LDAP-Servern oder Clients variieren, und die Funktionalität kann in manchen Fällen funktionieren oder auch nicht.
Wenn die Verschlüsselung fehlschlägt, ermöglicht StartTLS, dass die Konfiguration auf reguläre LDAP zurückfällt. LDAPS tut dies nicht. Daher bietet StartTLS einige Flexibilität und Resilienz, stellt aber auch Sicherheitsrisiken dar, wenn sie falsch konfiguriert sind.

Sicherheitsüberlegungen bei LDAP über StartTLS

Mit StartTLS können Administratoren bei Bedarf auf regulären LDAP-Datenverkehr zurückgreifen. Aus Sicherheitsgründen lassen die meisten LDAP-Administratoren sie nicht zu. Die folgenden Empfehlungen für StartTLS können zur Sicherung der LDAP-Kommunikation beitragen:

Stellen Sie sicher, dass StartTLS aktiviert ist und dass Zertifikate konfiguriert sind.
Für interne Umgebungen können Sie selbstsignierte Zertifikate verwenden, aber für externes LDAP eine Zertifizierungsstelle verwenden. Weitere Informationen zu Zertifikaten finden Sie im Unterschied zwischen selbstsigniertem SSL und Zertifizierungsstelle.
Verhindern Sie LDAP-Abfragen und -Bindungen, die StartTLS nicht verwenden. Standardmäßig deaktiviert Active Directory anonyme Bindungen.

Active Directory-Sicherheitsverbindung

Active Directory-Verbindungen mit Azure NetApp Files-Volumes können so konfiguriert werden, dass sie zuerst den stärksten verfügbaren Kerberos-Verschlüsselungstyp ausprobieren: AES-256. Wenn die AES-Verschlüsselung aktiviert ist, verwenden Domänencontrollerkommunikation (z. B. geplante SMB-Serverkennwortzurücksetzungen) den höchsten verfügbaren Verschlüsselungstyp, der auf den Domänencontrollern unterstützt wird. Azure NetApp Files unterstützt die folgenden Verschlüsselungstypen für die Domänencontrollerkommunikation in Der Reihenfolge der versuchten Authentifizierung: AES-256, AES-128, RC4-HMAC, DES