Liste de contrôle d’audit des ACL d’un NAS domestique pour les accès SMB, NFS et aux conteneurs

L’approche sûre consiste à traiter un audit ACL fondé sur les preuves, qui recense les identités, les permissions effectives et l’héritage sur chaque chemin d’accès, comme une séquence de contrôles observables, et non comme une seule commande.

Sur un NAS domestique qui exporte des données partagées via SMB, NFS et des conteneurs, le risque concret est que le même chemin NAS accorde des accès effectifs différents via SMB, NFS et les montages bind des conteneurs. Notez l’identité actuelle et le point de restauration, commencez par le discriminant le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable serait exposée. Le flux de travail ci-dessous ne se termine qu’une fois la charge de travail d’origine exécutée avec succès ou lorsque les preuves atteignent un seuil nécessitant une escalade.

Figer l’état des permissions et recenser chaque identité

Choisissez un partage représentatif et notez son jeu de données ou système de fichiers, les noms d’exportation, la définition du partage SMB, l’exportation NFS, les montages bind des conteneurs et les propriétaires actuels. Relevez les valeurs numériques des UID et GID sur le NAS et dans chaque conteneur ; des noms d’utilisateur identiques ne prouvent pas que les identités sous-jacentes correspondent.

Les ACL POSIX ajoutent des utilisateurs nommés, des groupes nommés, des entrées par défaut et un masque pouvant limiter leurs droits effectifs. Le fonctionnement du masque des ACL POSIX explique pourquoi le masque affiché par getfacl peut rendre une entrée apparemment généreuse beaucoup plus restrictive, ce qui est essentiel pour comparer une vue en ligne de commande au comportement de SMB ou NFS.

N’exécutez pas de chmod, chown ou remplacement récursif des ACL pendant l’inventaire. Enregistrez d’abord la sortie de getfacl -p et la configuration des services ; la base de référence est validée lorsque chaque identité cliente peut être associée à une identité numérique côté serveur ou explicitement marquée comme non mappée.

Tester l’accès effectif via chaque protocole

Créez un utilisateur d’audit dédié et un répertoire temporaire sous le partage. Depuis Windows ou macOS via SMB, depuis un client Linux NFS et depuis le conteneur cible, testez séparément l’énumération, la lecture, la création, le renommage et la suppression. Après chaque opération, notez le propriétaire, le groupe, le mode, l’ACL et le protocole utilisé.

Ne confondez pas l’authentification et l’autorisation du système de fichiers. Une connexion SMB peut réussir alors que l’identité Unix mappée ne dispose pas des permissions d’écriture ; un client NFS peut présenter un identifiant numérique accepté par le serveur, mais correspondant au mauvais propriétaire local. Ne modifiez qu’une seule variable d’identité ou d’ACL entre les tests.

Un chemin n’est validé que lorsque les droits observés correspondent à la matrice d’accès prévue et que les fichiers nouvellement créés reçoivent le propriétaire, le groupe et l’ACL par défaut attendus. Si un protocole se comporte différemment, interrompez les modifications générales et examinez sa couche de mappage avant de toucher au système de fichiers partagé.

Examiner l’héritage, les masques et les mappages des conteneurs

Comparez l’ACL par défaut du parent à l’ACL d’accès des fichiers et répertoires nouvellement créés. Vérifiez le masque ACL après les changements de groupe, confirmez si le service SMB applique des masques de création ou de répertoire et identifiez les applications qui remplacent les fichiers de manière atomique, car ce remplacement peut produire un héritage différent de celui des modifications sur place.

Pour les conteneurs, examinez l’utilisateur d’exécution, les groupes supplémentaires, le remappage des espaces de noms utilisateurs et le chemin hôte monté avec bind. Le guide ZimaSpace associé sur l’accès aux bases de données sur un volume Docker monté via le réseau est utile lorsque le mappage des noms NFSv4 constitue la couche défaillante ; cet audit reste axé sur la démonstration des droits de bout en bout sur les trois chemins.

Ne résolvez pas un problème de mappage en exécutant l’application en tant que root. Si le conteneur ne peut pas créer le fichier temporaire, alignez son UID, son GID ou son groupe supplémentaire pris en charge sur la politique du NAS, puis répétez le même test avant de modifier une arborescence de production.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Appliquer la correction la plus ciblée et préserver les preuves

Corrigez une seule couche à la fois : d’abord le mappage des identités, ensuite l’appartenance aux groupes, puis les valeurs par défaut héritées et enfin les ACL exceptionnelles des fichiers. Appliquez les changements au répertoire temporaire, vérifiez à nouveau toutes les opérations, puis préparez seulement une modification ciblée pour le sous-arbre de production avec une ACL de restauration enregistrée.

Après le déploiement, redémarrez ou reconnectez les clients qui mettent les identifiants en cache, remontez NFS si nécessaire et redémarrez uniquement les conteneurs dont la liste de groupes est fixée au démarrage du processus. Répétez la même matrice de tests et vérifiez que les fichiers existants comme les nouveaux se comportent comme prévu.

L’audit est terminé lorsque chaque action autorisée ou refusée correspond à la matrice écrite, que les nouveaux objets héritent correctement et que l’ACL enregistrée peut restaurer l’état précédent. Préférez une escalade plutôt qu’une récursion aveugle lorsque la propriété est volontairement mixte, que les instantanés ou les liens physiques compliquent la restauration, ou que le stockage du NAS signale des erreurs.