Share via


Comprendre les autorisations de partage NAS dans Azure NetApp Files

Azure NetApp Files offre plusieurs façons de sécuriser vos données NAS. L’un des aspects de cette sécurité est les autorisations. Dans NAS, les autorisations peuvent être réparties en deux catégories :

  • Limite des autorisations d’accès de partage qui peut monter un volume NAS. NFS contrôle les autorisations d’accès de partage via l’adresse IP ou le nom d’hôte. S Mo contrôle cela via des listes de contrôle d’accès d’utilisateur et de groupe (ACL).
  • Les autorisations d’accès aux fichiers limitent ce que les utilisateurs et les groupes peuvent faire une fois qu’un volume NAS est monté. Les autorisations d’accès aux fichiers sont appliquées à des fichiers et dossiers individuels.

Les autorisations Azure NetApp Files s’appuient sur des normes NAS, ce qui simplifie le processus de volumes NAS de sécurité pour les administrateurs et les utilisateurs finaux avec des méthodes familières.

Remarque

Si les autorisations en conflit sont répertoriées sur le partage et les fichiers, l’autorisation la plus restrictive est appliquée. Par exemple, si un utilisateur dispose d’un accès en lecture seule au niveau du partage et d’un contrôle total au niveau du fichier , l’utilisateur reçoit l’accès en lecture à tous les niveaux.

Autorisations d’accès au partage

Le point d’entrée initial à sécuriser dans un environnement NAS est l’accès au partage lui-même. Dans la plupart des cas, l’accès doit être limité uniquement aux utilisateurs et aux groupes qui ont besoin d’accéder au partage. Avec les autorisations d’accès au partage, vous pouvez verrouiller qui peut même monter le partage en premier lieu.

Étant donné que les autorisations les plus restrictives remplacent d’autres autorisations et qu’un partage est le point d’entrée principal du volume (avec les contrôles d’accès les plus rares), les autorisations de partage doivent respecter une logique en entonnoir, où le partage autorise plus d’accès que les fichiers et dossiers sous-jacents. La logique en entonnoir met en œuvre des contrôles plus granulaires et restrictifs.

Diagram of inverted pyramid of file access hierarchy.

Stratégies d’exportation NFS

Les volumes dans Azure NetApp Files sont partagés avec les clients NFS en exportant un chemin d’accès accessible à un client ou à un ensemble de clients. NFSv3 et NFSv4.x utilisent la même méthode pour limiter l’accès à un partage NFS dans Azure NetApp Files : stratégies d’exportation.

Une stratégie d’exportation est un conteneur pour un ensemble de règles d’accès répertoriées dans l’ordre d’accès souhaité. Ces règles contrôlent l’accès aux partages NFS à l’aide d’adresses IP clientes ou de sous-réseaux. Si un client n’est pas répertorié dans une règle de stratégie d’exportation ( autoriser ou refuser explicitement l’accès), ce client ne peut pas monter l’exportation NFS. Étant donné que les règles sont lues dans l’ordre séquentiel, si une règle de stratégie plus restrictive est appliquée à un client (par exemple, par le biais d’un sous-réseau), elle est d’abord lue et appliquée. Les règles de stratégie suivantes qui autorisent davantage d’accès sont ignorées. Ce diagramme montre un client disposant d’une adresse IP de 10.10.10.10 obtenant un accès en lecture seule à un volume, car le sous-réseau 0.0.0.0/0 (chaque client de chaque sous-réseau) est défini en lecture seule et est répertorié en premier dans la stratégie.

Diagram modeling export policy rule hierarchy.

Options de règle d’exportation de stratégie disponibles dans Azure NetApp Files

Lors de la création d’un volume Azure NetApp Files, plusieurs options sont configurables pour contrôler l’accès aux volumes NFS.

  • Index : spécifie l’ordre dans lequel une règle de stratégie d’exportation est évaluée. Si un client se trouve sous plusieurs règles dans la stratégie, la première règle applicable s’applique au client et les règles suivantes sont ignorées.
  • Clients autorisés : spécifie les clients auxquels une règle s’applique. Cette valeur peut être une adresse IP cliente, une liste séparée par des virgules d’adresses IP ou un sous-réseau incluant plusieurs clients. Les valeurs de nom d’hôte et de groupe net ne sont pas prises en charge dans Azure NetApp Files.
  • Accès : spécifie le niveau d’accès autorisé aux utilisateurs non racines. Pour les volumes NFS sans Kerberos activé, les options sont les suivantes : Lecture seule, Lecture et écriture ou Aucun accès. Pour les volumes avec Kerberos activé, les options sont : Kerberos 5, Kerberos 5i ou Kerberos 5p.
  • Accès racine : spécifie la façon dont l’utilisateur racine est traité dans les exportations NFS pour un client donné. Si la valeur est « Activé », la racine est la racine. Si la valeur est définie sur « Désactivé », la racine est squashing affectée à l’ID d’utilisateur anonyme 65534.
  • mode chown : contrôle ce que les utilisateurs peuvent exécuter les commandes de modification de propriété sur l’exportation (chown). Si la valeur est « Restricted », seul l’utilisateur racine peut exécuter chown. Si la valeur est « Illimité », tout utilisateur disposant des autorisations de fichier/dossier appropriées peut exécuter des commandes chown.

Règle de stratégie par défaut dans Azure NetApp Files

Lors de la création d’un volume, une règle de stratégie par défaut est créée. La stratégie par défaut empêche un scénario où un volume est créé sans règles de stratégie, ce qui limite l’accès pour tout client qui tente d’accéder à l’exportation. S’il n’existe aucune règle, il n’y a pas d’accès.

La règle par défaut a les valeurs suivantes :

  • Index = 1
  • Clients autorisés = 0.0.0.0/0 (tous les clients ont autorisé l’accès)
  • Access = Lecture et écriture
  • Accès racine = Activé
  • Mode Chown = Restreint

Ces valeurs peuvent être modifiées lors de la création du volume ou après la création du volume.

Exporter des règles de stratégie avec NFS Kerberos activé dans Azure NetApp Files

NFS Kerberos peut être activé uniquement sur les volumes utilisant NFSv4.1 dans Azure NetApp Files. Kerberos fournit une sécurité ajoutée en offrant différents modes de chiffrement pour les montages NFS, en fonction du type Kerberos en cours d’utilisation.

Lorsque Kerberos est activé, les valeurs des règles de stratégie d’exportation changent pour autoriser la spécification du mode Kerberos à autoriser. Plusieurs modes de sécurité Kerberos peuvent être activés dans la même règle si vous avez besoin d’accéder à plusieurs.

Ces modes de sécurité sont les suivants :

  • Kerberos 5 : seule l’authentification initiale est chiffrée.
  • Kerberos 5i : Authentification utilisateur plus intégrité case activée ing.
  • Kerberos 5p : Authentification des utilisateurs, intégrité case activée et confidentialité. Tous les paquets sont chiffrés.

Seuls les clients Kerberos peuvent accéder aux volumes avec des règles d’exportation spécifiant Kerberos ; aucun accès n’est AUTH_SYS autorisé lorsque Kerberos est activé.

Squashing racine

Il existe certains scénarios où vous souhaitez restreindre l’accès racine à un volume Azure NetApp Files. Étant donné que la racine n’a pas accès à tout ce qui se trouve dans un volume NFS ( même si elle refuse explicitement l’accès à la racine à l’aide de bits ou de listes de contrôle d’accès en mode), la seule façon de limiter l’accès racine consiste à indiquer au serveur NFS que la racine d’un client spécifique n’est plus racine.

Dans les règles de stratégie d’exportation, sélectionnez « Accès racine : désactivé » pour squashing racine vers un ID utilisateur non racine anonyme de 65534. Cela signifie que la racine sur les clients spécifiés est désormais l’ID d’utilisateur 65534 (généralement nfsnobody sur les clients NFS) et a accès aux fichiers et dossiers en fonction des listes de contrôle d’accès/bits en mode spécifiés pour cet utilisateur. Pour les bits de mode, les autorisations d’accès relèvent généralement des droits d’accès « Tout le monde ». En outre, les fichiers écrits en tant que « racine » des clients affectés par les règles de squashing racine créent des fichiers et des dossiers en tant qu’utilisateurnfsnobody:65534. Si vous avez besoin que la racine soit racine, définissez « Accès racine » sur « Activé ».

Pour en savoir plus sur la gestion des stratégies d’exportation, consultez Configurer des stratégies d’exportation pour les volumes NFS ou double protocole.

Exporter l’ordre des règles de stratégie

L’ordre des règles de stratégie d’exportation détermine la façon dont elles sont appliquées. La première règle de la liste qui s’applique à un client NFS est la règle utilisée pour ce client. Lors de l’utilisation de plages/sous-réseaux CIDR pour les règles de stratégie d’exportation, un client NFS dans cette plage peut recevoir un accès indésirable en raison de la plage dans laquelle elle est incluse.

Prenons l’exemple suivant :

Screenshot of two export policy rules.

  • La première règle de l’index inclut tous les clients de tous les sous-réseaux par le biais de la règle de stratégie par défaut à l’aide de 0.0.0.0/0 comme entrée de clients autorisés. Cette règle autorise l’accès en lecture et écriture à tous les clients pour ce volume NFSv3 Azure NetApp Files.
  • La deuxième règle de l’index répertorie explicitement le client NFS 10.10.10.10 et est configurée pour limiter l’accès à « Lecture seule », sans accès racine (la racine est squashing ed).

Comme il se présente, le client 10.10.10.10 reçoit l’accès en raison de la première règle de la liste. La règle suivante n’est jamais évaluée pour les restrictions d’accès. Par conséquent, 10.10.10.10 obtient l’accès en lecture et écriture même si « Lecture seule » est souhaitée. La racine est également racine, au lieu d’être squashing ed.

Pour résoudre ce problème et définir l’accès au niveau souhaité, les règles peuvent être réécrites pour placer la règle d’accès client souhaitée au-dessus des règles CIDR/sous-réseau. Vous pouvez réorganiser les règles de stratégie d’exportation dans le Portail Azure en faisant glisser les règles ou en utilisant les commandes Move dans le ... menu de la ligne pour chaque règle de stratégie d’exportation.

Remarque

Vous pouvez utiliser l’interface CLI Azure NetApp Files ou l’API REST uniquement pour ajouter ou supprimer des règles de stratégie d’exportation.

Partages SMB

Les partages S Mo permettent aux utilisateurs finaux d’accéder aux volumes S Mo ou double protocole dans Azure NetApp Files. Les contrôles d’accès pour les partages S Mo sont limités dans le plan de contrôle Azure NetApp Files à des options de sécurité S Mo telles que l’énumération basée sur l’accès et les fonctionnalités de partage non accessibles. Ces options de sécurité sont configurées lors de la création du volume avec la fonctionnalité Modifier le volume .

Screenshot of share-level permissions.

Les listes de contrôle d’accès d’autorisation au niveau du partage sont gérées via une console MMC Windows plutôt que via Azure NetApp Files.

Azure NetApp Files offre plusieurs propriétés de partage pour améliorer la sécurité pour les administrateurs.

Énumération basée sur l’accès

L’énumération basée sur l’accès est une fonctionnalité de volume Azure NetApp Files S Mo qui limite l’énumération des fichiers et dossiers (c’est-à-dire répertorier le contenu) dans S Mo uniquement aux utilisateurs disposant d’un accès autorisé sur le partage. Par exemple, si un utilisateur n’a pas accès à lire un fichier ou un dossier dans un partage avec l’énumération basée sur l’accès activé, le fichier ou le dossier ne s’affiche pas dans les listes de répertoires. Dans l’exemple suivant, un utilisateur (smbuser) n’a pas accès à lire un dossier nommé « ABE » dans un volume Azure NetApp Files S Mo. Seul contosoadmin l’accès est disponible.

Screenshot of access-based enumeration properties.

Dans l’exemple ci-dessous, l’énumération basée sur l’accès est désactivée. Par conséquent, l’utilisateur a accès au ABE répertoire de SMBVolume.

Screenshot of directory without access-bassed enumeration.

Dans l’exemple suivant, l’énumération basée sur l’accès est activée, de sorte que le ABE répertoire de SMBVolume ne s’affiche pas pour l’utilisateur.

Screenshot of directory with two sub-directories.

Les autorisations s’étendent également aux fichiers individuels. Dans l’exemple ci-dessous, l’énumération basée sur l’accès est désactivée et ABE-file s’affiche à l’utilisateur.

Screenshot of directory with two-files.

Avec l’énumération basée sur l’accès activée, ABE-file l’utilisateur ne s’affiche pas.

Screenshot of directory with one file.

Partages non extensibles

La fonctionnalité de partages non extensibles dans Azure NetApp Files limite les clients à la recherche d’un partage S Mo en masquant le partage à partir de l’affichage dans l’Explorateur Windows ou lors de la liste des partages en mode « net ». Seuls les utilisateurs finaux qui connaissent les chemins absolus du partage sont en mesure de trouver le partage.

Dans l’image suivante, la propriété de partage non extensible n’est pas activée pour SMBVolume, de sorte que le volume s’affiche dans la liste du serveur de fichiers (à l’aide \\servername).

Screenshot of a directory that includes folder SMBVolume.

Avec les partages non extensibles activés SMBVolume dans Azure NetApp Files, la même vue du serveur de fichiers exclut SMBVolume.

Dans l’image suivante, le partage SMBVolume a des partages non extensibles activés dans Azure NetApp Files. Lorsque cela est activé, il s’agit de l’affichage du niveau supérieur du serveur de fichiers.

Screenshot of a directory with two sub-directories.

Même si le volume de la liste ne peut pas être vu, il reste accessible si l’utilisateur connaît le chemin d’accès au fichier.

Screenshot of Windows Explorer with file path highlighted.

Chiffrement S Mo 3

Le chiffrement S Mo 3 est une fonctionnalité de volume Azure NetApp Files S Mo qui applique le chiffrement sur le réseau pour les clients S Mo pour renforcer la sécurité dans les environnements NAS. L’image suivante montre une capture d’écran du trafic réseau lorsque le chiffrement S Mo est désactivé. Les informations sensibles, telles que les noms de fichiers et les handles de fichiers, sont visibles.

Screenshot of packet capture with SMB encryption disabled.

Lorsque le chiffrement S Mo est activé, les paquets sont marqués comme chiffrés et aucune information sensible n’est visible. Au lieu de cela, il s’affiche sous la forme « Données S Mo 3 chiffrées ».

Screenshot of packet capture with SMB encryption enabled.

ACL de partage S Mo

Les partages S Mo peuvent contrôler l’accès aux personnes pouvant monter et accéder à un partage, ainsi que contrôler les niveaux d’accès aux utilisateurs et aux groupes dans un domaine Active Directory. Le premier niveau d’autorisations évalués est les listes de contrôle d’accès de partage (ACL).

Les autorisations de partage S Mo sont plus élémentaires que les autorisations de fichier : elles appliquent uniquement la lecture, la modification ou le contrôle total. Les autorisations de partage peuvent être remplacées par les autorisations de fichier et les autorisations de fichier peuvent être remplacées par des autorisations de partage ; l’autorisation la plus restrictive est celle qui est respectée. Par exemple, si le groupe « Tout le monde » a un contrôle total sur le partage (comportement par défaut) et que des utilisateurs spécifiques ont un accès en lecture seule à un dossier via une liste de contrôle d’accès au niveau du fichier, l’accès en lecture est appliqué à ces utilisateurs. Tous les autres utilisateurs qui ne sont pas répertoriés explicitement dans la liste de contrôle d’accès disposent d’un contrôle total

À l’inverse, si l’autorisation de partage est définie sur « Lecture » pour un utilisateur spécifique, mais que l’autorisation au niveau du fichier est définie sur un contrôle total pour cet utilisateur, l’accès « Lecture » est appliqué.

Dans les environnements NAS à double protocole, S Mo partager des listes de contrôle d’accès s’appliquent uniquement aux utilisateurs S Mo. Les clients NFS tirent parti des stratégies et règles d’exportation pour les règles d’accès de partage. Par conséquent, le contrôle des autorisations au niveau du fichier et du dossier est préféré aux ACL au niveau du partage, en particulier pour les volumes NAS double=protocole.

Pour savoir comment configurer des listes de contrôle d’accès, consultez Gérer les listes de contrôle d’accès (ACL) de partage S Mo dans Azure NetApp Files.

Étapes suivantes