Freigeben über

Informationen zur Datenverschlüsselung in Azure NetApp Files

  • Artikel

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

  • Verschlüsselung ruhender Daten: Daten werden mithilfe von FIPS 140-2-konformen Standards verschlüsselt.
  • Verschlüsselung während der Übertragung: Daten werden während der Übertragung zwischen Client und Server verschlüsselt.

Verstehen der Verschlüsselung ruhender Daten

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

  • Die einfache Verschlüsselung verwendet eine softwarebasierte Verschlüsselung für Azure NetApp Files-Volumes.
  • Doppelte Verschlüsselung fügt auf der Ebene der physischen Speichergeräte Verschlüsselung auf Hardwareebene hinzu.

Azure NetApp Files verwendet Standard-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 plattformverwaltete Schlüssel von Microsoft oder vom Kunden verwaltete Schlüssel sein.

Grundlegendes zur Verschlüsselung von Daten während der Übertragung

Zusätzlich zum Sichern ruhender Daten kann Azure NetApp Files Daten sichern, wenn sie zwischen Endpunkten übertragen werden. Die verwendete Verschlüsselungsmethode hängt vom Protokoll oder Feature ab. DNS wird in Azure NetApp-Dateien nicht während der Übertragung 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 nativ die 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.

Die 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 höheren Leistungsbedarf. Weitere Informationen zu Leistungsaspekten bei der SMB-Verschlüsselung finden Sie in den bewährten Methoden für die 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. Hierbei wird eine AES-Verschlüsselung verwendet, und es werden alle SMB-Pakete verschlüsselt. Damit dieses Feature ordnungsgemäß funktioniert, müssen SMB-Clients die SMB-Verschlüsselung unterstützen. Wenn der SMB-Client die Verschlüsselung und SMB3 nicht unterstützt, sind SMB-Verbindungen unzulässig. Wenn diese Option aktiviert ist, benötigen alle Freigaben, die dieselbe IP-Adresse haben, eine Verschlüsselung, wodurch die SMB-Freigabeeigenschaftseinstellung für die Verschlüsselung außer Kraft gesetzt wird.

SMB-Verschlüsselung auf Freigabenebene

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

UNC-Härtung

2015 führte Microsoft die UNC-Härtung (MS15-011 und MS15-014) ein, 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: Hardening Group Policy.

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

  • RequireMutualAuthentication – Identitätsauthentifizierung erforderlich/nicht erforderlich, um Spoofingangriffe zu blockieren.
  • RequireIntegrity – Integritätsprüfung erforderlich/nicht erforderlich, um Manipulationsangriffe zu blockieren.
  • RequirePrivacy – Datenschutz (vollständige 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 auch die Möglichkeit, NFSv4.1-Unterhaltungen über Kerberos-Authentifizierung zu verschlüsseln. Hierzu werden kryptografische AES-256-GCM/AES-128-GCM- und AES-256-CCM/AES-128-CCM-Suites verwendet.

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

  • Kerberos 5 (krb5) – Nur Erstauthentifizierung; erfordert Kerberos-Ticketaustausch/Benutzeranmeldung für den Zugriff auf den NFS-Export. NFS-Pakete werden nicht verschlüsselt.
  • Kerberos 5i (krb5i) – Anfängliche Authentifizierung und Integritätsprüfung; erfordert 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 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 den Inhalt zu verschlüsseln.

Jede Kerberos-Verschlüsselungsebene wirkt sich auf die Leistung aus. Wenn die Verschlüsselungstypen und Sicherheitsvarianten sicherere Methoden enthalten, erhöht sich der Effekt auf die Leistung. Beispielsweise ist die Leistung von krb5 besser als krb5i, krb5i hat eine besserer Leistung besser als krb5p, AES-128 hat eine bessere Leistung als AES-256 usw. Weitere Informationen zum Leistungseffekt von NFS Kerberos in Azure NetApp Files finden Sie unter Auswirkungen von Kerberos auf die Leistung von 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 erste Authentifizierungsanforderung (Anmeldung/Ticketerwerb) wird verschlüsselt. Der gesamte restliche NFS-Datenverkehr geht als Nur-Text ein.

Screenshot of NFS packet with krb5.

Bei Verwendung von Kerberos 5i (krb5i; Integritätsprüfung) zeigt eine Ablaufverfolgung an, dass die NFS-Pakete nicht verschlüsselt sind. Dem Paket wird aber ein GSS/Kerberos-Wrapper hinzugefügt, der erfordert, dass der Client und der Server die Integrität der übertragenen Daten mit einer Prüfsumme sicherstellen.

Screenshot of NFS packet with krb5i enabled.

Kerberos 5p (Datenschutz; krb5p) stellt die End-to-End-Verschlüsselung des gesamten NFS-Datenverkehr bereit, wie im Ablaufverfolgungsimage mit einem GSS/Kerberos-Wrapper dargestellt. Diese Methode führt zum höchsten Leistungsbedarf, da jede NFS-Paketverschlüsselung verarbeitet werden muss.

Screenshot of NFS packet with krb5p enabled.

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, in der der Zugriff beschränkt ist, um Paket-Sniffiing und Man-in-the-Middle-Angriffe zu verhindern (Lauschangriffe oder Identitätswechsel zwischen Kommunikationsendpunkten). Darüber hinaus wird der Replikationsdatenverkehr mit FIPS 140-2-kompatiblen TLS 1.2-Standards verschlüsselt. Ausführliche Informationen zu diesem Thema finden Sie in den häufig gestellten Fragen zur Sicherheit.

LDAP-Verschlüsselung

Normalerweise wird der LDAP-Such- und Bindungsdatenverkehr in Nur-Text übertragen, was bedeutet, dass jeder mit Zugriff zum Sniffing von Paketen Informationen vom LDAP-Server erhalten kann, z. B. Benutzernamen, numerische IDs, Gruppenmitgliedschaften usw. Diese Informationen können dann verwendet werden, um Benutzer zu spoofen, E-Mails für Phishingangriffe zu senden usw.

Um zu verhindern, dass die LDAP-Kommunikation abgefangen und gelesen wird, kann der LDAP-Datenverkehr die Verschlüsselung während der Übertragung nutzen, die AES und TLS 1.2 über LDAP-Signierung bzw. LDAP über TLS verwendet. 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 (Simple Authentication and Security Layer) an AD-Server, die LDAP-Verbindungen hosten. Die Signierung erfordert keine Konfiguration von Sicherheitszertifikaten, da sie die GSS-API-Kommunikation mit den KDC-Diensten (Kerberos Key Distribution Center) von Active Directory verwendet. Die LDAP-Signierung überprüft nur die Integrität eines LDAP-Pakets; die Nutzlast des Pakets wird nicht verschlüsselt.

Screenshot of NFS packet with LDAP signing.

Die LDAP-Signierung kann auch von der Windows-Serverseite über Gruppenrichtlinien konfiguriert werden, um entweder opportunistisch mit LDAP-Signierung zu sein (keine – Unterstützung, falls vom Client angefordert) oder um LDAP-Signierung zu erzwingen (erforderlich). Die LDAP-Signatur kann einen höheren Leistungsbedarf für den LDAP-Datenverkehr bedeuten, der in der Regel für Endbenutzer nicht erkennbar ist.

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. Weitere Informationen finden Sie in der Microsoft-Sicherheitsempfehlung 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 erfolgt in allen Fällen über Port 389. Dieser Port kann nicht geändert werden. LDAP über SSL (LDAPS) wird nicht unterstützt und gilt bei den meisten LDAP-Serveranbietern als Legacyversion (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 über StartTLS wurde 2000 mit RFC 2830 eingeführt und 2006 mit RFC 4511 zum LDAPv3-Standard 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 es werden Zertifikate verglichen; dann wird der gesamte LDAP-Datenverkehr mithilfe von TLS verschlüsselt. Die unten gezeigte Paketerfassung zeigt die LDAP-Bindung, den StartTLS-Handshake und nachfolgenden TLS-verschlüsselten LDAP-Datenverkehr.

Screenshot of packet capture with StartTLS.

Es gibt zwei Hauptunterschiede zwischen LDAPS und StartTLS:

  • StartTLS ist Teil des LDAP-Standards, LDAPS hingegen nicht. Daher kann die LDAP-Bibliotheksunterstützung auf LDAP-Servern oder Clients variieren, und die Funktionalität ist möglicherweise nicht in allen Fällen gewährleistet.
  • Wenn die Verschlüsselung fehlschlägt, ermöglicht StartTLS, dass die Konfiguration auf das reguläre LDAP zurückfällt. Dies ist bei LDAPS nicht der Fall. Daher bietet StartTLS einige Flexibilität und Resilienz, stellt aber bei falscher Konfiguration auch Sicherheitsrisiken dar.

Sicherheitsüberlegungen bei LDAP über StartTLS

Mit StartTLS können Administratoren bei Bedarf ein Fallback auf regulären LDAP-Datenverkehr ausführen. Aus Sicherheitsgründen lassen die meisten LDAP-Administratoren dies 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. Verwenden Sie für externes LDAP eine Zertifizierungsstelle. Weitere Informationen zu Zertifikaten finden Sie im Artikel zum Unterschied zwischen selbstsigniertem SSL & 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 versuchen: AES-256. Wenn die AES-Verschlüsselung aktiviert ist, verwendet 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

Hinweis

Es ist nicht möglich, schwächere Authentifizierungstypen in Azure NetApp Files zu deaktivieren (z. B. RC4-HMAC und DES). Stattdessen sollten diese bei Bedarf vom Domänencontroller deaktiviert werden, damit Authentifizierungsanforderungen nicht versuchen, sie zu verwenden. Wenn RC4-HMAC auf den Domänencontrollern deaktiviert ist, muss die AES-Verschlüsselung in Azure NetApp Files für die ordnungsgemäße Funktionalität aktiviert werden.

Nächste Schritte