Cas d'utilisation et charges de travail
Suggérer des modifications
PDF
NFS sur TLS convient parfaitement à trois scénarios de déploiement courants : chiffrement sur le réseau sans infrastructure Kerberos, application TLS par client sur une exportation partagée et authentification mutuelle de clients.
Toutes les charges de travail ne bénéficient pas de la même manière ; connaître les modèles qui conviennent et ceux qui ne conviennent pas vous aidera à planifier votre déploiement.
Cas d'utilisation
Chiffrement NFS en transit sans infrastructure Kerberos. Si vous avez besoin de chiffrement des données NFS en transit mais que vous ne souhaitez pas déployer et exploiter un centre de distribution de clés (KDC), distribuer des keytabs aux clients ou étendre un domaine Kerberos pour couvrir vos clients NAS, NFS sur TLS répond directement à ce besoin. Vous installez un certificat serveur par Storage Virtual Machine (SVM), activez NFS sur TLS sur chaque interface logique de données (LIF) devant transporter du NFS chiffré, et les clients négocient TLS 1.3 en ligne sur le port NFS standard. Aucun nouveau service d’authentification n’est requis.
Application du protocole TLS uniquement par client sur un partage NFS. Si vous avez à la fois des clients nécessitant le chiffrement et d'autres qui n'en ont pas besoin, vous devez pouvoir forcer les clients concernés à utiliser le chemin chiffré sans impacter les autres. L'option de règle de stratégie d'exportation -allow-nfs-tls-only true permet précisément cela. Elle bloque les montages non TLS depuis les clients correspondants via TCP, tout en laissant les autres règles de stratégie d'exportation inchangées.
Authentification de clients mutuelle (mTLS) pour la confiance entre le stockage et le client. Si vous appliquez des principes de réseau à zéro confiance ou si vous avez des exigences de renforcement qui imposent que le contrôleur de stockage vérifie l'identité de l'hôte de chaque client se connectant, utilisez l'option TLS mutuelle par LIF. Activez -enforce-host-auth true sur vserver nfs tls interface enable ou vserver nfs tls interface modify. ONTAP valide alors le certificat X.509 de chaque client se connectant par rapport à la chaîne de confiance de l'autorité de certification (CA) installée sur le SVM lors de la poignée de main TLS et rejette les clients ne présentant pas de certificat approuvé. Cela vous offre une application cryptographique du principe « seuls mes hôtes enregistrés peuvent accéder à cette LIF NFS » et fonctionne en complément des filtres d'hôtes de la politique d'exportation existants.
Charges de travail
Le chiffrement a un coût. L'établissement de la liaison TLS a un coût mesurable, et le chiffrement TLS des enregistrements ajoute une surcharge à chaque RPC. L'impact sur les performances varie considérablement en fonction de la charge de travail, de la plateforme et de la disponibilité du déchargement matériel. Pour plus de détails, consultez "Performances".
Modèles de charge de travail
Les partages NFS persistants avec un parc de clients stable sont parfaitement adaptés. L'établissement de la liaison TLS représente un coût par connexion, payé lors du montage et du rétablissement de la session : si vous disposez d'un petit ensemble stable de clients qui effectuent un montage unique et restent connectés pendant des heures ou des jours, vous absorberez ce coût sans difficulté.
Si vous gérez déjà correctement la correspondance entre les LIF et les noms d’hôtes (par exemple, avec des enregistrements DNS sous votre contrôle), la mise en place de NFS sur TLS sera simple. La fonctionnalité est configurée par LIF : vous installez un certificat serveur dont le nom commun (CN) correspond au nom de domaine pleinement qualifié (FQDN) de la LIF et dont la liste des noms alternatifs du sujet (SAN) contient l’adresse IP de la LIF.
NFS sur TLS est l'outil idéal lorsque la confidentialité sur le réseau, l'identité du serveur et, éventuellement, l'identité de l'hôte client sont vos exigences de sécurité—exactement les propriétés que TLS fournit.
Anti-modèles de charge de travail
Une forte instabilité des connexions ou des pics de montage importants sont à proscrire. Chaque nouvelle connexion TLS engendre le coût d'établissement de la liaison TLS 1.3, incluant la cryptographie asymétrique, la validation du certificat et, optionnellement, la validation de la chaîne mTLS. Si de nombreux clients montent un volume, effectuent quelques opérations, le démontent et se reconnectent de manière répétée, vous paierez ce coût d'établissement de liaison à chaque fois au lieu de l'amortir.