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

Cryptage des données en transit

Contributeurs kevin-hoke
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 crypte le trafic au niveau du réseau comme décrit dans "Cryptage en transit" dans la documentation Google. Comme mentionné dans la section « Architecture de Google Cloud NetApp Volumes », Google Cloud NetApp Volumes est fourni à partir d'un projet producteur PSA contrôlé par NetApp.

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

Bien que le chemin de données pour NetApp Volumes-Performance ne soit pas entièrement chiffré sur la couche réseau, NetApp et Google utilisent une combinaison "du cryptage IEEE 802.1AE (MACSec)" , "encapsulation" (chiffrement des données) et des réseaux physiquement restreints pour protéger les données en transit entre le type de service Google Cloud NetApp Volumes NetApp Volumes et Google Cloud.

Protocoles NAS

Les protocoles NAS NFS et SMB fournissent un cryptage de transport facultatif au niveau de la couche de protocole.

cryptage SMB

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

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

Google Cloud NetApp Volumes prend en charge les chiffrements 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.

NFSv4.1 Kerberos

Pour NFSv4.1, NetApp Volumes-Performance propose l'authentification Kerberos comme décrit dans "RFC7530" Vous pouvez activer Kerberos volume par volume.

Le type de cryptage le plus puissant actuellement disponible pour Kerberos est AES-256-CTS-HMAC-SHA1. Google Cloud NetApp Volumes prend en charge 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 fournit trois niveaux de sécurité différents pour les montages NFS qui offrent des choix quant au niveau 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 doit intervenir, plus les performances sont mauvaises, 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 déchargement AES-NI vers les processeurs pour une meilleure expérience globale, mais l'impact sur les performances de Kerberos 5p (chiffrement de bout en bout complet) est nettement supérieur à l'impact de Kerberos 5 (authentification utilisateur).

Le tableau suivant montre les différences entre ce que chaque niveau fait en matière de sécurité et de performances.

Niveau de sécurité Sécurité Performances

NFSv3—sys

  • Le moins sécurisé ; texte brut avec identifiants d'utilisateur/de groupe numériques

  • Capable d'afficher l'UID, le GID, les adresses IP des clients, les chemins d'exportation, les noms de fichiers et les autorisations dans les captures de paquets

  • Idéal pour la plupart des cas

NFSv4.x—sys

  • Plus sécurisé que NFSv3 (identifiants client, correspondance chaîne de nom/chaîne de domaine) mais toujours en texte brut

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

  • Idéal pour les charges de travail séquentielles (telles que les machines virtuelles, les bases de données, les fichiers volumineux)

  • Mauvais avec un nombre élevé de fichiers/métadonnées élevées (30 à 50 % pire)

NFS—krb5

  • Chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS : encapsule l'UID/GID des utilisateurs/groupes dans les appels RPC dans le wrapper GSS

  • L'utilisateur demandant l'accès au montage a besoin d'un ticket Kerberos valide (soit via un nom d'utilisateur/mot de passe, soit via un échange manuel de clés) ; le ticket expire après une période de temps spécifiée et l'utilisateur doit se réauthentifier pour accéder

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

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

NFS—krb5i

  • Chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS : encapsule l'UID/GID des utilisateurs/groupes dans les appels RPC dans le wrapper GSS

  • L'utilisateur demandant l'accès au montage a besoin d'un ticket Kerberos valide (soit via un nom d'utilisateur/mot de passe, soit via un échange manuel de clés) ; le ticket expire après une période de temps spécifiée et l'utilisateur doit se réauthentifier pour accéder

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

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

  • Mieux que krb5p car la charge utile NFS n'est pas chiffrée ; la seule surcharge supplémentaire par rapport à krb5 est la somme de contrôle d'intégrité. Les performances de krb5i ne seront pas bien pires que celles de krb5 mais connaîtront une certaine dégradation.

NFS – krb5p

  • Chiffrement Kerberos pour les informations d'identification dans chaque paquet NFS : encapsule l'UID/GID des utilisateurs/groupes dans les appels RPC dans le wrapper GSS

  • L'utilisateur demandant l'accès au montage a besoin d'un ticket Kerberos valide (via un nom d'utilisateur/mot de passe ou un échange manuel de keytab) ; le ticket expire après la période spécifiée et l'utilisateur doit se réauthentifier pour accéder

  • Toutes les charges utiles des paquets NFS sont chiffrées avec le wrapper GSS (impossible de voir les descripteurs de fichiers, les autorisations, les noms de fichiers, atime/mtime dans les captures de paquets).

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

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

  • Les protocoles auxiliaires (mount, portmap, nlm, etc.) ne sont pas chiffrés - (peuvent voir les chemins d'exportation, les adresses IP)

  • Pire performance des niveaux de sécurité ; krb5p doit crypter/décrypter davantage.

  • Meilleures performances que krb5p avec NFSv4.x pour les charges de travail à nombre de fichiers élevé.

Dans Google Cloud NetApp Volumes, un serveur Active Directory configuré est utilisé comme serveur Kerberos et serveur LDAP (pour rechercher les identités des utilisateurs à partir d'un schéma compatible RFC2307). Aucun autre serveur Kerberos ou LDAP n'est pris en charge. NetApp vous recommande vivement d'utiliser LDAP pour la gestion des identités dans Google Cloud NetApp Volumes. Pour plus d'informations sur la façon dont NFS Kerberos est affiché dans les captures de paquets, consultez la section link:gcp-gcnv-arch-detail.html#Packet sniffing/trace considerations["Packet sniffing/trace considerations."]