Skip to main content
NetApp Solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Chiffrement des données en transit

Contributeurs
PDF

Les données en transit peuvent être chiffrées au niveau de la couche de protocole NAS et le réseau Google Cloud lui-même est chiffré, comme décrit dans les sections suivantes.

Réseau Google Cloud

Google Cloud chiffre le trafic au niveau du réseau comme décrit "Chiffrement en transit" dans la documentation Google. Comme indiqué dans la section « architecture de Google Cloud NetApp volumes », Google Cloud NetApp volumes est livré à partir d'un projet de production PSA contrôlé par NetApp.

Dans le cas de NetApp volumes-SW, le locataire producteur exécute Google VM pour fournir le service. Le trafic entre les machines virtuelles des utilisateurs et les machines virtuelles Google Cloud NetApp volumes est automatiquement chiffré par Google.

Bien que le chemin d'accès aux données de NetApp volumes-Performance ne soit pas entièrement chiffré sur la couche réseau, NetApp et Google utilisent une combinaison "De cryptage IEEE 802.1AE (MACSec)" "encapsulation" (chiffrement des données) et des réseaux à restrictions physiques pour protéger les données en transit entre le type de service Google Cloud NetApp volumes NetApp volumes-Performance et Google Cloud.

Protocoles NAS

Les protocoles NAS NFS et SMB fournissent un chiffrement de transport en option au niveau de la couche de protocoles.

Chiffrement SMB

"Chiffrement SMB" Offre un cryptage de bout en bout des données SMB et protège les données contre les occurrences de réseaux non fiables. Vous pouvez activer le cryptage à la fois pour la connexion de données client/serveur (uniquement disponible pour les clients compatibles SMB3.x) et pour l'authentification du contrôleur serveur/domaine.

Lorsque le cryptage SMB est activé, les clients qui ne prennent pas en charge le cryptage ne peuvent pas accéder au partage.

Google Cloud NetApp volumes prend en charge le chiffrement de sécurité RC4-HMAC, AES-128-CTS-HMAC-SHA1 et AES-256-CTS-HMAC-SHA1 pour le chiffrement SMB. SMB négocie le type de cryptage le plus élevé pris en charge par le serveur.

Kerberos NFSv4.1

Pour NFSv4.1, NetApp volumes-Performance propose l'authentification Kerberos comme décrit dans la section. vous pouvez activer Kerberos sur la "RFC7530" base du volume.

Le type de chiffrement le plus puissant actuellement disponible pour Kerberos est AES-256-CTS-HMAC-SHA1. Google Cloud NetApp volumes prend en charge les normes AES-256-CTS-HMAC-SHA1, AES-128-CTS-HMAC-SHA1, DES3 et DES pour NFS. Il prend également en charge ARCFOUR-HMAC (RC4) pour le trafic CIFS/SMB, mais pas pour NFS.

Kerberos propose trois niveaux de sécurité différents pour les montages NFS qui offrent des options de sécurité Kerberos.

Selon RedHat "Options de montage courantes" documentation :

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.

En règle générale, plus le niveau de sécurité Kerberos est important, plus les performances sont faibles, car le client et le serveur passent du temps à chiffrer et déchiffrer les opérations NFS pour chaque paquet envoyé. De nombreux clients et serveurs NFS prennent en charge le transfert AES-ni vers les processeurs pour une meilleure expérience globale. Cependant, l'impact sur les performances de Kerberos 5p (chiffrement complet de bout en bout) est considérablement plus important que l'impact de Kerberos 5 (authentification utilisateur).

Le tableau ci-dessous présente les différences par rapport à chaque niveau pour la sécurité et les performances.

Niveau de sécurité Sécurité Performance

NFSv3 : sys

  • Moins sécurisé ; texte brut avec ID utilisateur numérique/ID de groupe

  • Possibilité d'afficher les UID, GID, adresses IP client, chemins d'exportation, noms de fichiers, autorisations dans les captures de paquets

  • Idéal pour la plupart des cas

NFSv4.x — sys

  • Plus sûr que NFSv3 (ID client, correspondance de chaîne de nom/chaîne de domaine) mais texte brut

  • Possibilité d'afficher les UID, GID, adresses IP des clients, chaînes de noms, ID de domaine, chemins d'exportation, noms de fichiers, autorisations dans les captures de paquets

  • Adapté aux charges de travail séquentielles (VM, bases de données, fichiers volumineux)

  • Erreurs avec un nombre élevé de fichiers/métadonnées élevées (30 à 50 % en moins)

NFS - krb5

  • Le chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS — enveloppe l'UID/GID des utilisateurs/groupes dans les appels RPC dans l'encapsuleur GSS

  • L'utilisateur qui demande l'accès au montage a besoin d'un ticket Kerberos valide (via nom d'utilisateur/mot de passe ou par échange manuel de clés) ; le ticket expire après une période spécifiée et l'utilisateur doit de nouveau s'authentifier pour l'accès

  • Aucun chiffrement pour les opérations NFS ou les protocoles annexes tels que mount/portmapper/nlm (peut voir les chemins d'exportation, les adresses IP, les pointeurs de fichiers, les autorisations, les noms de fichiers, atime/mtime dans les captures de paquets)

  • Le meilleur dans la plupart des cas pour Kerberos ; pire que AUTH_SYS

NFS - krb5i

  • Le chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS — enveloppe l'UID/GID des utilisateurs/groupes dans les appels RPC dans l'encapsuleur GSS

  • L'utilisateur qui demande l'accès au montage doit disposer d'un ticket Kerberos valide (via nom d'utilisateur/mot de passe ou échange manuel par onglet) ; le ticket expire après une période spécifiée et l'utilisateur doit de nouveau s'authentifier pour l'accès

  • Aucun chiffrement pour les opérations NFS ou les protocoles annexes tels que mount/portmapper/nlm (peut voir les chemins d'exportation, les adresses IP, les pointeurs de fichiers, les autorisations, les noms de fichiers, atime/mtime dans les captures de paquets)

  • La somme de contrôle GSS Kerberos est ajoutée à chaque paquet pour garantir que rien n'intercepte les paquets. Si les checksums correspondent, la conversation est autorisée.

  • Supérieur à krb5p parce que la charge NFS n'est pas chiffrée. Seule la surcharge supplémentaire par rapport à krb5 est la somme de contrôle d'intégrité. Les performances de krb5i ne seront pas beaucoup plus mauvais que krb5, mais il y aura une certaine dégradation.

NFS – krb5p

  • Le chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS — enveloppe l'UID/GID des utilisateurs/groupes dans les appels RPC dans l'encapsuleur GSS

  • L'utilisateur qui demande l'accès au montage doit disposer d'un ticket Kerberos valide (via nom d'utilisateur/mot de passe ou échange manuel de clavier) ; le ticket expire après la période spécifiée et l'utilisateur doit de nouveau s'authentifier pour l'accès

  • Tous les payload de paquets NFS sont cryptés avec l'encapsuleur GSS (ne peut pas voir les descripteurs de fichier, les autorisations, les noms de fichier, atime/mtime dans les captures de paquets).

  • Inclut le contrôle d'intégrité.

  • Le type d'opération NFS est visible (FSINFO, ACCESS, GETATTR, etc.).

  • Les protocoles auxiliaires (montage, portmap, nlm, etc.) ne sont pas cryptés (voir chemins d'exportation, adresses IP)

  • Performances les plus faibles des niveaux de sécurité ; la krb5p doit chiffrer/décrypter plus.

  • Performances supérieures à celles du krb5p avec NFSv4.x pour les workloads avec un nombre élevé de fichiers.

Dans Google Cloud NetApp volumes, un serveur Active Directory configuré est utilisé en tant que serveur Kerberos et serveur LDAP (pour rechercher les identités d'utilisateurs à partir d'un schéma compatible RFC2307). Aucun autre serveur Kerberos ou LDAP n'est pris en charge. NetApp recommande vivement d'utiliser LDAP pour la gestion des identités dans Google Cloud NetApp volumes. Pour plus d'informations sur la manière dont NFS Kerberos est affiché dans les captures de paquets, reportez-vous à la section link:ncvs-gc-cloud-volumes-service-architecture.html#considérations relatives à la capture/trace de paquets[« considérations relatives à la détection/trace de paquets »].