Skip to main content
NetApp Solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Datenverschlüsselung während der Übertragung

Beitragende
PDFs

Die übertragenen Daten können auf der NAS-Protokollebene verschlüsselt und das Google Cloud-Netzwerk selbst verschlüsselt werden, wie in den folgenden Abschnitten beschrieben.

Google Cloud Network

Google Cloud verschlüsselt Datenverkehr auf Netzwerkebene, wie in der Google-Dokumentation beschrieben "Verschlüsselung während der Übertragung". Wie im Abschnitt „Google Cloud NetApp Volumes Architektur“ erwähnt, wird Google Cloud NetApp Volumes aus einem von NetApp kontrollierten PSA-Produzenten-Projekt geliefert.

Im Falle von NetApp Volumes-SW führt der Produzentenmandant Google VMs aus, um den Service bereitzustellen. Der Datenverkehr zwischen Benutzer-VMs und Google Cloud NetApp Volumes VMs wird automatisch von Google verschlüsselt.

Obwohl der Datenpfad für NetApp Volumes Performance auf der Netzwerkebene nicht vollständig verschlüsselt ist, verwenden NetApp und Google eine Kombination "Der IEEE 802.1AE Verschlüsselung (MACsec)", (Datenverschlüsselung) und physisch beschränkte Netzwerke, "Kapselung" um die Daten auf der Übertragungsstrecke zwischen dem Servicetyp Google Cloud NetApp Volumes NetApp und Google Cloud zu schützen.

NAS-Protokolle

Die NAS-Protokolle NFS und SMB bieten optionale Transportverschlüsselung auf Protokollebene.

SMB-Verschlüsselung

"SMB-Verschlüsselung" Bietet End-to-End-Verschlüsselung von SMB-Daten und schützt Daten vor abfallenden Ereignissen in nicht vertrauenswürdigen Netzwerken. Sie können die Verschlüsselung sowohl für die Client-/Server-Datenverbindung (nur für SMB3.x-fähige Clients verfügbar) als auch für die Server/Domain-Controller-Authentifizierung aktivieren.

Wenn die SMB-Verschlüsselung aktiviert ist, können Clients, die keine Verschlüsselung unterstützen, nicht auf die Freigabe zugreifen.

Google Cloud NetApp Volumes unterstützt RC4-HMAC, AES-128-CTS-HMAC-SHA1 und AES-256-CTS-HMAC-SHA1-Sicherheitskiffren für SMB-Verschlüsselung. SMB verhandelt den vom Server am häufigsten unterstützten Verschlüsselungstyp.

Kerberos: NFSv4.1

Für NFSv4.1 bietet NetApp Volumes-Performance Kerberos-Authentifizierung wie in beschrieben "RFC7530". Sie können Kerberos pro Volume aktivieren.

Der derzeit stärkste verfügbare Verschlüsselungstyp für Kerberos ist AES-256-CTS-HMAC-SHA1. Google Cloud NetApp Volumes unterstützt AES-256-CTS-HMAC-SHA1, AES-128-CTS-HMAC-SHA1, DES3 und DES für NFS. Es unterstützt auch ARCFOUR-HMAC (RC4) für CIFS/SMB-Datenverkehr, jedoch nicht für NFS.

Kerberos bietet drei verschiedene Sicherheitsstufen für NFS-Mounts, die Möglichkeiten bieten, wie stark die Kerberos-Sicherheit sein sollte.

As per RedHat "Allgemeine Mount-Optionen" Dokumentation:

sec=krb5 uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.
sec=krb5i uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5p uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also involves the most performance overhead.

Je mehr der Kerberos-Sicherheitslevel zu tun hat, desto schlechter ist die Performance, da Client und Server Zeit damit verbringen, NFS-Vorgänge für jedes gesendete Paket zu verschlüsseln und zu entschlüsseln. Viele Clients und NFS Server unterstützen AES-NI-Entlastung der CPUs, um insgesamt eine bessere Benutzererfahrung zu erzielen. Die Auswirkungen von Kerberos 5p (vollständige End-to-End-Verschlüsselung) sind jedoch deutlich höher als die Auswirkungen von Kerberos 5 (Benutzerauthentifizierung).

Die folgende Tabelle zeigt Unterschiede in den einzelnen Ebenen in Bezug auf Sicherheit und Performance.

Sicherheitsstufe Sicherheit Leistung

NFSv3 – sys

  • Am wenigsten sicher; Klartext mit numerischen Benutzer-IDs/Gruppen-IDs

  • Kann UID, GID, Client-IP-Adressen, Exportpfade, Dateinamen, Berechtigungen in Paketaufnahmen

  • Das Beste für die meisten Fälle

NFSv4.x – sys

  • Sicherer als NFSv3 (Client-IDs, Namenszeichenfolge/Domänenzeichenfolge-Übereinstimmung), aber immer noch Klartext

  • Kann UID, GID, Client-IP-Adressen, Namensstrings, Domänen-IDs, anzeigen Pfade, Dateinamen und Berechtigungen in Paketaufnahmen exportieren

  • Gut für sequenzielle Workloads (z. B. VMs, Datenbanken, große Dateien)

  • Schlecht mit hoher Dateianzahl/hohen Metadaten (30-50% schlechter)

NFS – krb5

  • Kerberos-Verschlüsselung für Anmeldeinformationen in jedem NFS-Paket – schließt UID/GID von Benutzern/Gruppen in RPC-Aufrufen in GSS-Wrapper

  • Benutzer, die Zugriff auf das Mount anfordern, benötigen ein gültiges Kerberos-Ticket (entweder über den Benutzernamen/das Passwort oder den Austausch des manuellen Schlüssels); das Ticket läuft nach einem bestimmten Zeitraum ab und der Benutzer muss sich erneut authentifizieren, um Zugriff zu erhalten

  • Keine Verschlüsselung für NFS-Vorgänge oder Zusatz-Protokolle wie Mount/Portmapper/nlm (kann Exportpfade, IP-Adressen, Dateihandles, Berechtigungen, Dateinamen, Uhrzeit/Mtime in Paketaufnahmen)

  • Am besten in den meisten Fällen für Kerberos; schlechter als AUTH_SYS

NFS – krb5i

  • Kerberos-Verschlüsselung für Anmeldeinformationen in jedem NFS-Paket – schließt UID/GID von Benutzern/Gruppen in RPC-Aufrufen in GSS-Wrapper

  • Benutzer, die Zugriff auf das Mount anfordern, benötigen ein gültiges Kerberos-Ticket (entweder über Benutzernamen/Passwort oder den Austausch des manuellen Schlüssels); das Ticket läuft nach einem bestimmten Zeitraum ab und der Benutzer muss sich erneut authentifizieren, um Zugriff zu erhalten

  • Keine Verschlüsselung für NFS-Vorgänge oder Zusatz-Protokolle wie Mount/Portmapper/nlm (kann Exportpfade, IP-Adressen, Dateihandles, Berechtigungen, Dateinamen, Uhrzeit/Mtime in Paketaufnahmen)

  • Kerberos GSS-Prüfsumme wird zu jedem Paket hinzugefügt, damit die Pakete nicht abgefangen werden. Wenn Prüfsummen übereinstimmen, ist das Gespräch zulässig.

  • Besser als krb5p, da die NFS-Nutzlast nicht verschlüsselt ist; nur der zusätzliche Overhead im Vergleich zu krb5 ist die Integritäts-Prüfsumme. Die Leistung von krb5i wird nicht viel schlechter sein als krb5, aber wird einige Verschlechterung zu sehen.

NFS – krb5p

  • Kerberos-Verschlüsselung für Anmeldeinformationen in jedem NFS-Paket – schließt UID/GID von Benutzern/Gruppen in RPC-Aufrufen in GSS-Wrapper

  • Benutzer, die Zugriff auf das Mount anfordern, benötigen ein gültiges Kerberos-Ticket (entweder über Benutzernamen/Passwort oder den manuellen Schlüsseltab-Austausch); das Ticket läuft nach einem festgelegten Zeitraum ab und der Benutzer muss sich erneut authentifizieren, um Zugriff zu erhalten

  • Alle Payloads des NFS-Pakets sind mit dem GSS-Wrapper verschlüsselt (Dateihandles, Berechtigungen, Dateinamen, atime/mtime in Paketaufnahmen können nicht angezeigt werden).

  • Umfasst die Integritätsprüfung.

  • Der NFS Operationstyp ist sichtbar (FSINFO, ACCESS, GETATTR usw.).

  • Zusatzprotokolle (Mount, Portmap, nlm usw.) sind nicht verschlüsselt - (kann Exportpfade, IP-Adressen sehen)

  • Schlechteste Leistung der Sicherheitsstufen; krb5p muss mehr verschlüsseln/entschlüsseln.

  • Bessere Performance als krb5p mit NFSv4.x für Workloads mit hoher Dateianzahl.

In Google Cloud NetApp-Volumes wird ein konfigurierter Active Directory-Server als Kerberos-Server und LDAP-Server verwendet (um Benutzeridentitäten von einem RFC2307-kompatiblen Schema abzurufen). Es werden keine anderen Kerberos oder LDAP-Server unterstützt. NetApp empfiehlt insbesondere die Verwendung von LDAP für das Identitätsmanagement in Google Cloud NetApp Volumes. Informationen darüber, wie NFS Kerberos in Paketerfassungen dargestellt wird, finden Sie im Abschnitt Link:ncvs-gc-Cloud-Volumes-Service-architecture.HTML#Packet Sniffing/trace thoerings[„Packet Sniffing/trace thoerings.“]