Pourquoi est-il mauvais de cartographier les lecteurs réseau dans Windows ?

J'imagine que la raison la plus forte pour ne pas cartographier les lecteurs de réseau est que les administrateurs ne veulent pas avoir à gérer les maux de tête liés au maintien d'un index d'un nombre fini de lettres de lecteur en plus des chemins du réseau. D'une part, il pourrait y avoir trop de partages réseau d'usage courant pour pouvoir attribuer des lettres de lecteur à tous, et dans une grande organisation, tout le monde n'aura pas accès à tous les mêmes partages. Les noms des partages sont également plus descriptifs et potentiellement moins ambigus que les lettres de lecteur (plus d'informations sur l'ambiguïté plus loin).

Deuxièmement, vous pouvez être confronté à des collisions de lettres de lecteur. Si l'ordinateur d'une personne possède un lecteur de carte mémoire, cela peut engloutir quatre lettres de lecteur ou plus. A et B sont généralement réservés aux lecteurs de disquettes du siècle dernier, et C et D sont généralement réservés au disque dur et au lecteur optique, de sorte que le lecteur de carte utilisera E, F, G et H. Si l'un de vos lecteurs réseau est généralement mappé sur H : via un script de connexion, cette pauvre personne ne pourra pas utiliser le lecteur H : du lecteur de carte ou ne pourra pas monter le lecteur réseau.

À moins qu'une personne au sein de l'organisation ne soit responsable de l'attribution des lettres de lecteur à des fins spécifiques, les lecteurs réseau pourraient également finir par causer beaucoup de confusion. Par exemple, supposons que vous affectiez le lecteur S : au partage qui contient les programmes d'installation de tous vos logiciels sous licence de site, et que quelqu'un d'autre affecte le lecteur S : au lecteur partagé où il dépose toutes sortes de documents partagés. Lorsque vous essayez d'expliquer comment installer certains logiciels, vous leur dites d'ouvrir leur lecteur S : et de trouver le programme d'installation pour Microsoft Office, mais tout ce qu'ils trouvent est un dossier nommé office, qui contient un tas de fichiers divers que quelqu'un y a déposé pour un transfert de fichiers temporaire. Cela peut vous prendre 5 ou 10 minutes pour régler la confusion.

Il y a aussi des problèmes potentiels de performance si un serveur tombe en panne ou si une machine est retirée du réseau. Par exemple, si vous mappez les lecteurs réseau sur une machine, puis retirez la machine du réseau (il peut s'agir d'un ordinateur portable), la machine peut sembler suspendue à la connexion alors que Windows essaie en vain de monter les lecteurs réseau manquants.

D'autre part, sur les anciennes versions de Windows, j'ai remarqué que les transferts de fichiers vers ou depuis un lecteur réseau mappé vont souvent beaucoup plus vite que si vous naviguiez vers le dossier réseau et effectuiez le même transfert de fichiers - auquel cas, la plupart des gens préféreraient mapper les lecteurs réseau.

La réponse est simple : ce n'est pas une mauvaise chose. Les lecteurs de réseau sont parfaitement sûrs à cartographier en tant que lecteurs.

La superstition vient du fait que vous ne devriez pas mapper des lecteurs étrangers (c'est-à-dire Internet) en tant que lecteurs locaux parce que les fichiers ouverts à partir de lecteurs mappés sont ouverts en utilisant la zone “locale”, ce qui leur offre généralement une protection moindre - et si les fichiers proviennent en fait d'Internet, c'est une réduction de la sécurité.

Si, comme je le soupçonne, vous mappez en fait des lecteurs réseau int ra net, alors ouvrir les dossiers en tant que lecteurs mappés est exactement aussi sûr que d'y accéder via leur nom de chemin réseau. La seule différence est qu'il est plus pratique de les faire mapper.

D'après mon expérience, il s'agit surtout de logiciels mal écrits.

Si la personne A travaille sur une suite de fichiers qui sont mappés à G:, et que la personne B essaie d'ouvrir le même ensemble de fichiers avec le même chemin mappé à H:, les choses échouent.

Si vous utilisez des chemins UNC, en supposant que les ordinateurs de la personne A et de la personne B puissent voir le point de partage, tout fonctionnera bien.

Bien sûr, la solution idéale est d'utiliser un logiciel qui ne stocke pas les relations entre les fichiers en utilisant des chemins absolus, mais ce n'est pas quelque chose que vous pouvez toujours contrôler.

Beaucoup de logiciels sur les marchés de la CAO/FAO sont mal écrits, et ne fonctionnent pratiquement pas. Comme le marché est plutôt petit, il y a peu de pression concurrentielle. Je connais au moins un logiciel qui a eu des problèmes avec des chemins absolus pour les dernières 5 versions majeures, et ils ne sont toujours pas réglés, malgré le fait qu'ils aient signalé les problèmes à l'entreprise.

Nous avons eu de sérieux problèmes avec les lecteurs réseau sur lesquels je travaille parce que parfois Windows ne s'y connecte pas, et il semble qu'il ne connecte pas automatiquement un lecteur réseau lorsqu'un programme essaie d'y accéder.

Au moins une demi-douzaine de fois un utilisateur de la comptabilité a appelé parce qu'il obtenait la même erreur. C'est parce qu'elle a ouvert le programme X, qui utilise un fichier mappé sur le lecteur réseau Y :, et il n'est pas connecté pour une raison inconnue.

Je doute que les informaticiens s'inquiètent qu'un seul utilisateur cartographie un lecteur réseau, ils s'inquiètent plutôt d'une centaine ou d'un millier d'utilisateurs. Par exemple, si un groupe d'hôtes lance l'indexation d'un ou de plusieurs lecteurs en réseau en même temps, comment cela affectera-t-il tous les autres utilisateurs du réseau ? Lorsqu'un disque en réseau est inévitablement mis hors ligne, bloquera-t-il des centaines de machines jusqu'à ce que le système d'exploitation abandonne et supprime le mappage du disque ? Les PC d'ici et d'ailleurs démarreront-ils plus lentement ou échoueront-ils à démarrer si les connexions aux lecteurs mappés ne peuvent pas être rétablies ?

Un problème avec la syntaxe de \server\dir est que les fenêtres de commande ne peuvent pas cd à eux. Si vous avez des privilèges d'administrateur et que vous ne voulez pas utiliser de lettre de lecteur, vous pouvez utiliser la commande mklink pour monter des lecteurs dans un répertoire au lieu d'une lettre de lecteur. Le répertoire Home ne doit pas exister.

mklink /d “c:\Drives\Home” “\server\HomeFolder\user1”

Ce répertoire est utilisable par tout.

Le montage sur un lecteur peut être mauvais car il est possible de changer de point de montage. Vous lisez et écrivez alors sur quelque chose que vous n'attendez pas. Si les exécutables d'un point de montage changent, ils peuvent contenir des virus.

Ma solution nécessite des droits d'administrateur, donc si vous ne l'utilisez pas avec des droits d'administrateur, elle est plus sûre car un autre programme ne pourrait pas la modifier sur vous sans droits d'administrateur.

Un certain nombre de logiciels, dont différentes versions de Microsoft Visual Studio et de CMS Bounceback, ne fonctionnent qu'avec des lettres de lecteur et non avec des chemins absolus. Compte tenu de cette restriction, l'utilisation de ces logiciels exige que vous définissiez des lettres de lecteur - vous n'avez pas le choix. Mais Windows ne rend pas cela très facile car il semble demander un nom d'utilisateur et un mot de passe, mais un seul nom d'utilisateur et un seul mot de passe sont autorisés dans Windows pour toutes les connexions à un même périphérique réseau (par exemple, plusieurs disques et imprimantes).

Voici une bonne raison :

Windows (au moins XP) ne prend pas en charge les chemins d'accès de plus de 256 caractères. Le mappage permet à quelqu'un d'ajouter un fichier là où il ne serait pas possible de le faire autrement, en raccourcissant le chemin. Vous avez alors un programme qui navigue dans tous les fichiers et dossiers, et qui n'est pas conscient de la cartographie. Sans le mappage, le fichier existant a une longueur de chemin supérieure à 256. Le programme se bloque.

Il suffit de parler à certains des centaines de consultants en informatique qui doivent maintenant faire face à la récente épidémie de “CryptoLocker” et vous vous rendrez vite compte que les disques durs mappés d'un ordinateur local qui est infecté peuvent causer des dommages massifs aux données sur le serveur, via le disque mappé.

Plus précisément :

“CryptoLocker accédera également aux lecteurs réseau mappés auxquels l'utilisateur actuel a accès en écriture et les cryptera. Il n'attaquera pas les simples partages de serveur, mais seulement les lecteurs mappés”.

Ainsi, l'utilisation de lecteurs mappés pose clairement des problèmes de sécurité en cette ère de malware “zero-day” omniprésent et nouvellement découvert qui frappe fréquemment les utilisateurs.

Nous avons éliminé tous les lecteurs mappés sur notre réseau local et utilisons à la place des “partages réseau”.

Quelques raisons de ne pas utiliser les lecteurs cartographiés :

1) Ils consomment des ressources à la fois sur la machine locale avec le disque mappé et sur les ressources réseau. Les applications locales peuvent devenir lentes parce que votre ordinateur local doit lire le contenu du lecteur mappé lorsque l'application est lancée ou lorsque le système est démarré. Essayez-le. Mappez un ensemble de lecteurs et lancez Excel. Démappez les lecteurs et essayez à nouveau.

2) Déplacer votre application vers un nouvel environnement sera fastidieux. En cas de reprise après sinistre, de déplacement vers une machine plus puissante, ou si un autre développeur reprend votre application. Si le nouvel environnement ne permet pas de mapper les lecteurs ou si les lettres des lecteurs sont mappées différemment, alors quelqu'un passe du temps à réécrire le code. Le temps gagné sur le front sera plus que perdu à le réparer.

Les lecteurs mappés sont plus rapides si vous manipulez de grandes quantités de fichiers. Windows authentifie votre accès une fois avec un lecteur mappé, puis permet aux interactions de fichiers d'avoir lieu. Les chemins d'accès UNC sont authentifiés par Windows pour chaque fichier consulté. Le processus d'authentification se produirait donc des milliers de fois si vous manipuliez des milliers de fichiers sous un chemin UNC. Lecteur mappé - Authentifier une fois UNC - Authentifier chaque fois qu'un fichier est consulté.

Cela peut avoir des conséquences sur quelque chose d'aussi simple que la copie de fichiers. Les lecteurs mappés seront toujours plus rapides, surtout avec un grand nombre de fichiers.

Certains virus et logiciels malveillants très répandus exploitent les lecteurs cartographiés. C'est une raison aussi valable que les autres pour ne pas les utiliser.

Une des raisons pour limiter le mappage des lecteurs serait les virus de courrier électronique (fichiers zip ou exe ouverts par des utilisateurs quelque peu “denses”) tels que Cryptolocker qui va classer par ordre alphabétique tous les fichiers sur les lecteurs locaux et mappés et les crypter. Il ne fait (notamment) pas de discrimination en fonction des lecteurs. Nous avons été touchés, et avons pu récupérer en utilisant des sauvegardes du ou des serveurs, mais bien sûr les fichiers locaux étaient “grillés”.

Je sais que c'est un vieux fil, mais je ne dirais pas qu'ils sont parfaitement sûrs. Nous avons retiré les lecteurs mappés en raison des risques de sécurité. De nombreux virus tentent de se propager sur les disques. Ils ne se propagent cependant pas par des raccourcis pointant vers les actions DFS. Quelque chose à garder à l'esprit…

En ce qui concerne la cryptographie et les demandes de rançon, Locky est un exemple de demande de rançon qui peut se propager via des chemins UNC ainsi que des lettres de lecteur mappées. Si votre préoccupation concernant les lecteurs réseau mappés et les chemins UNC est déterminée par le risque d'attaques de rançon, sachez qu'elle ne protège que contre certaines d'entre elles.

Il existe plusieurs façons de détecter/prévenir les attaques de logiciels rançonnés - et il est généralement recommandé d'utiliser plusieurs méthodes de protection : protéger le réseau, protéger le point final et maintenir un solide régime de sauvegarde. Personnellement, j'utilise Sophos InterceptX comme solution anti-ransomware sur le point d'accès, un pare-feu Cisco ASA (avec IPS), ShadowProtect pour la sauvegarde et j'utilise des lecteurs réseau mappés là où cela a un sens administratif.

Avertissement : Je suis un architecte certifié Sophos. Bien que je ne travaille pas pour Sophos, je pense que leur technologie est soignée. Je travaille également pour un MSP, et c'est la technologie que nous avons choisie après avoir examiné les différentes options disponibles en Australie.

Rédigé comme demandé pour donner plus d'informations pour le deuxième paragraphe. De plus, je parle australien, pas anglais, la grammaire est légèrement différente et certains mots sont orthographiés différemment (c'est Colour, pas Color, et ne me parlez même pas de cantaloup).

Je n'aime pas utiliser des lecteurs cartographiés parce que j'utilise peu souvent diverses ressources réseau et que je ne trouve jamais l'adresse complète pour que d'autres puissent l'utiliser. L'utilisation de raccourcis me permet également d'avancer facilement dans le répertoire. Si la seule raison de mapper les lecteurs est la limite de 256 caractères, c'est une piètre excuse pour perdre tous ces détails sur l'emplacement des fichiers.

Les lecteurs cartographiés sont dangereux ! Ces dernières années, avec l'augmentation des demandes de rançon, j'ai supprimé les disques durs mappés partout où cela était possible. Les rançons visent toutes les LETTRES DE LIVRES et pas seulement les données locales. Ainsi, si vous êtes en sécurité tant que vous conservez des sauvegardes redondantes, c'est toujours un casse-tête de devoir faire face à une telle violation de données.

Si vous êtes dans un environnement professionnel (cible principale du ransomware), et si vous le pouvez, débarrassez-vous des lecteurs mappés !

Certains virus à rançon, comme la famille CryptoWall , recherchent tout lecteur mappé et infectent ces lecteurs. Cependant, si le partage réseau utilise UNC et non une lettre de lecteur, ces virus n'infectent pas le partage.

La raison numéro 1 pour laquelle vous ne voudriez pas faire cela est que le logiciel de rançon ne peut pas accéder à un chemin UNC, mais les lettres de lecteur sont une bonne affaire. Si vous voulez que votre réseau soit verrouillé par cryptage, vous pouvez continuer à utiliser le mappage des lettres de lecteur.

Personnellement, je ne vois pas l'avantage des lettres de lecteur et je trouve vraiment que les chemins UNC sont plus faciles car je n'ai jamais à me soucier du mappage des lettres de lecteur, surtout après avoir changé de mot de passe de connexion. Vous pouvez créer des raccourcis qui ne se comportent pas différemment des lettres de lecteur et vous pouvez ajouter ces raccourcis à Windows Explorer.

Le lecteur réseau est un bon moyen de partager les ressources, mais je ne suis pas d'accord avec le fait que les répertoires personnels soient placés sur un lecteur réseau partageable. C'est carrément stupide. La plupart des applications utilisent votre répertoire personnel comme lieu de stockage des paramètres spécifiques des applications pour les utilisateurs. Si l'informatique veut un mal de tête de plus (comme si elle n'en avait pas assez à gérer), alors réparer les dépendances des applications pour les utilisateurs au sein du réseau peut être une douleur qu'ils peuvent ajouter à leur sac de problèmes. Ces problèmes peuvent surgir dans un environnement où de nombreuses applications de ce type sont utilisées et où leurs dépendances et leurs exigences changent. D'une part, le travail peut être ralenti pour les utilisateurs du réseau et l'entreprise peut perdre de l'argent et du temps en raison des faibles niveaux de productivité. C'est quelque chose qui ne peut pas être risqué. Deuxièmement, certaines organisations cartographient le disque dur de l'utilisateur sur le réseau pour surveiller ce qui s'y trouve. Le gouvernement le fait souvent dans le cadre de ses exigences. Cela ajoute également au problème de la possibilité de travailler à domicile. Si votre connectivité par VP pose des problèmes pour que votre application fonctionne à distance par le biais d'une session VPN, où vous exécutez votre application qui nécessite une dépendance de votre lecteur domestique cartographié sur le réseau et que la cartographie du lecteur échoue, alors vous êtes hébergé.

Personnellement, je pense que cela ne devrait être fait que pour de bonnes raisons, mais pas au point d'entraver la productivité et d'affecter les résultats de l'entreprise.