Comprendre le style de sécurité et les comportements d’autorisation à double protocole dans Azure NetApp Files
S Mo et NFS utilisent différents modèles d’autorisation pour l’accès utilisateur et groupe. Par conséquent, un volume azure NetApp File doit être configuré pour respecter le modèle d’autorisation souhaité pour l’accès au protocole. Pour les environnements NFS uniquement, la décision est simple : utilisez des styles de sécurité UNIX. Pour les environnements S Mo uniquement, utilisez des styles de sécurité NTFS.
Si NFS et S Mo sur les mêmes jeux de données (double protocole) sont requis, la décision doit être prise en fonction de deux questions :
- Quel protocole les utilisateurs géreront-ils les autorisations les plus ?
- Quel est le point de terminaison de gestion des autorisations souhaité ? En d’autres termes, les utilisateurs ont-ils besoin de la possibilité de gérer les autorisations des clients NFS ou des clients Windows ? Ou les deux ?
Les styles de sécurité des volumes peuvent vraiment être considérés comme des styles d’autorisation, où le style souhaité de gestion de la liste de contrôle d’accès est le facteur de choix.
Remarque
Les styles de sécurité sont choisis lors de la création du volume. Une fois le style de sécurité choisi, il ne peut pas être modifié.
À propos des styles de sécurité des volumes Azure NetApp Files
Il existe deux choix principaux pour les styles de sécurité en volume dans Azure NetApp Files :
UNIX - Le style de sécurité UNIX fournit des autorisations de style UNIX, telles que les bits de mode POSIX de base (Propriétaire/Groupe/Tout le monde accède avec des autorisations standard en lecture/écriture/exécution, telles que 0755) et NFSv4.x ACL. Les listes de contrôle d’accès POSIX ne sont pas prises en charge.
NTFS - Le style de sécurité NTFS fournit des fonctionnalités identiques à celles des autorisations NTFS Windows standard, avec des utilisateurs et des groupes granulaires dans les ACL et des autorisations détaillées de sécurité/audit.
Dans un environnement NAS double protocole, un seul style d’autorisation de sécurité peut être actif. Vous devez évaluer les considérations relatives à chaque style de sécurité avant de en choisir un.
| Style de sécurité | À propos de l’installation |
|---|---|
| UNIX | - Les clients Windows ne peuvent définir que des attributs d’autorisation UNIX via S Mo s qui mappent aux attributs UNIX (en lecture/écriture/exécution uniquement ; aucune autorisation spéciale). - Les listes de contrôle d’accès NFSv4.x n’ont pas de gestion de l’interface graphique utilisateur. La gestion est effectuée uniquement via l’interface CLI à l’aide de nfs4_getfacl et de commandes nfs4_setfacl. - Si un fichier ou un dossier a des ACL NFSv4.x, l’onglet Propriétés de sécurité Windows ne peut pas les afficher. |
| NTFS | - Les clients UNIX ne peuvent pas définir d’attributs via NFS via des commandes telles que chown/chmod. - Les clients NFS n’affichent que les autorisations NTFS approximatives lors de l’utilisation ls de commandes. Par exemple, si un utilisateur dispose d’une autorisation dans une liste de contrôle d’accès NTFS Windows qui ne peut pas être propre traduit en bit en mode POSIX (par exemple, le répertoire de traversée), il est traduit en la valeur de bits en mode POSIX la plus proche (par exemple1, pour l’exécution). |
La sélection du style de sécurité du volume détermine la façon dont le mappage de noms pour un utilisateur est effectué. Cette opération est l’élément principal de la façon dont les volumes double protocole conservent des autorisations prévisibles, quel que soit le protocole en cours d’utilisation.
Utilisez le tableau suivant comme matrice de décision pour sélectionner les styles de sécurité de volume appropriés.
| Style de sécurité | Principalement NFS | Surtout S Mo | Besoin d’une sécurité granulaire |
|---|---|---|---|
| UNIX | X | - | X (utilisation de listes de contrôle d’accès NFSv4.x) |
| NTFS | - | X | X |
Fonctionnement du mappage de noms dans Azure NetApp Files
Dans Azure NetApp Files, seuls les utilisateurs sont authentifiés et mappés. Les groupes ne sont pas mappés. Au lieu de cela, les appartenances aux groupes sont déterminées à l’aide de l’identité de l’utilisateur.
Lorsqu’un utilisateur tente d’accéder à un volume Azure NetApp Files, cette tentative transmet une identité au service. Cette identité inclut un nom d’utilisateur et un identificateur numérique unique (numéro UID pour NFSv3, chaîne de nom pour NFSv4.1, SID pour S Mo). Azure NetApp Files utilise cette identité pour s’authentifier auprès d’un service de noms configuré pour vérifier l’identité de l’utilisateur.
- La recherche LDAP pour les ID numériques est utilisée pour rechercher un nom d’utilisateur dans Active Directory.
- Les chaînes de noms utilisent la recherche LDAP pour rechercher un nom d’utilisateur et le client et le serveur consultent le domaine d’ID configuré pour NFSv4.1 pour garantir la correspondance.
- Les utilisateurs Windows sont interrogés à l’aide d’appels RPC Windows standard vers Active Directory.
- Les appartenances aux groupes sont également interrogées, et tout est ajouté à un cache d’informations d’identification pour accélérer le traitement des demandes suivantes sur le volume.
- Actuellement, les utilisateurs locaux personnalisés ne sont pas pris en charge pour une utilisation avec Azure NetApp Files. Seuls les utilisateurs d’Active Directory peuvent être utilisés avec des protocoles doubles.
- Actuellement, les seuls utilisateurs locaux qui peuvent être utilisés avec des volumes à double protocole sont racines et l’utilisateur
nfsnobody.
Une fois qu’un nom d’utilisateur est authentifié et validé par Azure NetApp Files, l’étape suivante de l’authentification en volume à double protocole est le mappage des noms d’utilisateurs pour l’interopérabilité UNIX et Windows.
Le style de sécurité d’un volume détermine la façon dont un mappage de noms a lieu dans Azure NetApp Files. La sémantique des autorisations Windows et UNIX est différente. Si un mappage de noms ne peut pas être effectué, l’authentification échoue et l’accès à un volume à partir d’un client est refusé. Un scénario courant où cette situation se produit est lorsque l’accès NFSv3 est tenté vers un volume avec le style de sécurité NTFS. La demande d’accès initiale de NFSv3 est fournie à Azure NetApp Files en tant qu’UID numérique. Si un utilisateur nommé user1 avec un ID numérique de tentatives d’accès 1001 au montage NFSv3, la demande d’authentification arrive en tant qu’ID 1001numérique. Azure NetApp Files prend ensuite l’ID 1001 numérique et tente de résoudre 1001 le nom d’utilisateur. Ce nom d’utilisateur est requis pour le mappage à un utilisateur Windows valide, car les autorisations NTFS sur le volume contiennent des noms d’utilisateur Windows au lieu d’un ID numérique. Azure NetApp Files utilise le serveur de service de noms configuré (LDAP) pour rechercher le nom d’utilisateur. Si le nom d’utilisateur est introuvable, l’authentification échoue et l’accès est refusé. Cette opération est par conception afin d’empêcher l’accès indésirable aux fichiers et dossiers.
Mappage de noms basé sur le style de sécurité
La direction dans laquelle le mappage de noms se produit dans Azure NetApp Files (Windows vers UNIX ou UNIX vers Windows) dépend non seulement du protocole utilisé, mais également du style de sécurité d’un volume. Un client Windows nécessite toujours un mappage de noms Windows à UNIX pour autoriser l’accès, mais il n’a pas toujours besoin d’un nom d’utilisateur UNIX correspondant. Si aucun nom d’utilisateur UNIX valide n’existe dans le serveur de service de noms configuré, Azure NetApp Files fournit un utilisateur UNIX par défaut de secours avec l’UID numérique permettant 65534 l’authentification initiale pour les connexions S Mo. Après cela, les autorisations de fichier et de dossier contrôlent l’accès. Étant donné que 65534 correspond généralement à l’utilisateur, l’accès nfsnobody est limité dans la plupart des cas. Inversement, un client NFS doit uniquement utiliser un mappage de noms UNIX vers Windows si le style de sécurité NTFS est utilisé. Il n’existe aucun utilisateur Windows par défaut dans Azure NetApp Files. Par conséquent, si un utilisateur Windows valide qui correspond au nom demandeur est introuvable, l’accès est refusé.
Le tableau suivant décompose les différentes permutations de mappage de noms et leur comportement en fonction du protocole utilisé.
| Protocol | Style de sécurité | Direction du mappage de noms | Autorisations appliquées |
|---|---|---|---|
| PME | UNIX | Windows vers UNIX | UNIX (ACL mode bits ou NFSv4.x) |
| PME | NTFS | Windows vers UNIX | ACL NTFS (basé sur le SID Windows accédant au partage) |
| NFSv3 | UNIX | Aucun | UNIX (ACL mode bits ou NFSv4.x ACL*) |
| NFSv4.x | UNIX | ID numérique au nom d’utilisateur UNIX | UNIX (ACL mode bits ou NFSv4.x) |
| NFS3/4.x | NTFS | UNIX vers Windows | ACL NTFS (basé sur le SID utilisateur Windows mappé) |
Remarque
Les règles de mappage de noms dans Azure NetApp Files peuvent actuellement être contrôlées uniquement à l’aide du protocole LDAP. Il n’existe aucune option permettant de créer des règles de mappage de noms explicites au sein du service.
Services de noms avec des volumes à double protocole
Quel que soit le protocole NAS utilisé, les volumes à double protocole utilisent des concepts de mappage de noms pour gérer correctement les autorisations. Par conséquent, les services de noms jouent un rôle essentiel dans la maintenance des fonctionnalités dans les environnements qui utilisent À la fois S Mo et NFS pour accéder aux volumes.
Les services de noms agissent en tant que sources d’identité pour les utilisateurs et les groupes accédant aux volumes NAS. Cette opération inclut Active Directory, qui peut servir de source pour les utilisateurs et les groupes Windows et UNIX à l’aide des services de domaine standard et des fonctionnalités LDAP.
Les services de noms ne sont pas obligatoires, mais fortement recommandés pour les volumes à double protocole Azure NetApp Files. Il n’existe aucun concept de création d’utilisateurs et de groupes locaux personnalisés au sein du service. Par conséquent, pour disposer d’une authentification appropriée et d’informations précises sur les propriétaires d’utilisateurs et de groupes entre les protocoles, LDAP est une nécessité. Si vous n’avez qu’une poignée d’utilisateurs et que vous n’avez pas besoin de remplir des informations d’identité d’utilisateur et de groupe précises, envisagez d’utiliser l’option Autoriser les utilisateurs NFS locaux avec LDAP pour accéder à une fonctionnalité de volume à double protocole. N’oubliez pas que l’activation de cette fonctionnalité désactive la fonctionnalité de groupe étendue.
Lorsque les clients, les services de noms et le stockage résident dans différentes zones
Dans certains cas, les clients NAS peuvent vivre dans un réseau segmenté avec plusieurs interfaces qui ont des connexions isolées aux services de stockage et de noms.
Par exemple, si votre stockage réside dans Azure NetApp Files, tandis que vos clients NAS et vos services de domaine résident tous localement (par exemple, une architecture hub-spoke dans Azure). Dans ces scénarios, vous devez fournir un accès réseau aux clients NAS et aux services de nom.
La figure suivante montre un exemple de ce type de configuration.
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour