Por que é ruim mapear unidades de rede no Windows?

Houve alguma discussão animada em nosso departamento de TI sobre o mapeamento de unidades de rede. Em particular, foi dito que o mapeamento de unidades de rede é uma coisa ruim e que adicionar caminhos DFS ou compartilhamentos de rede aos seus favoritos (Windows Explorer / Bibliotecas) é uma solução muito melhor.

Por que esse é o caso?

Pessoalmente, acho a conveniência de z:\folderser melhor do que \\server\path\folder', particularmente com linha de cmd e scripts (é claro que não estou falando de links codificados, naturalmente!).

Tentei procurar por prós e contras das unidades de rede mapeadas, mas não vi nada além de "se a rede cair, a unidade ficará indisponível". Mas essa é uma limitação de qualquer armazenamento acessado pela rede.

Também me disseram que as unidades de rede mapeadas pesquisam a rede quando o recurso de rede não está disponível, mas não encontrei mais informações sobre isso. As unidades de rede pesquisam a rede mais do que uma biblioteca / favorita do Windows Explorer? Isso ainda não seria um problema com outros mecanismos de acesso à rede (ou seja, Favoritos mapeados) sempre que o Windows tentar enumerar o sistema de arquivos (por exemplo, quando uma caixa de diálogo do seletor de arquivos / pastas for aberta)?

Eu imagino que a razão mais forte para não mapear unidades de rede é que os administradores não querem lidar com as dores de cabeça de manter um índice de um número finito de letras de unidades, além dos caminhos de rede. Por um lado, pode haver muitos compartilhamentos de rede comumente usados ​​para atribuir letras de unidade a todos eles e, em uma organização grande, nem todos terão acesso aos mesmos compartilhamentos. Os nomes de compartilhamento também são mais descritivos e potencialmente menos ambíguos do que as letras de unidade (mais sobre a ambiguidade posteriormente).

Segundo, você pode encontrar colisões de letras de unidade. Se o PC de alguém tiver um leitor de cartão de memória, isso pode devorar quatro ou mais letras de unidade. A e B são normalmente reservados para as unidades de disquete do século passado, e C e D são geralmente reservadas para o disco rígido e a unidade óptica, portanto o leitor de cartões usará E, F, G e H. Se uma de suas unidades de rede geralmente é mapeado para H: por meio de um script de logon, essa pessoa pobre não poderá usar a unidade H: do leitor de cartões ou não poderá montar a unidade de rede.

A menos que alguém dentro da organização seja responsável por alocar letras de unidade para fins específicos, as unidades de rede também podem acabar causando muita confusão. Por exemplo, suponha que você mapeie a unidade S: para o compartilhamento que possui os programas de instalação para todos os softwares licenciados por seu site, e outra pessoa mapeie S: para a unidade compartilhada, onde eles descartam todos os tipos de documentos compartilhados. Ao tentar explicar como instalar algum software, você deve abrir a unidade S: e encontrar o programa de instalação do Microsoft Office, mas tudo o que eles podem encontrar é uma pasta chamada office , que contém um monte de arquivos diversos que alguém largou lá para uma transferência temporária de arquivos. Pode levar 5 ou 10 minutos para resolver a confusão.

Há também alguns problemas de desempenho em potencial se um servidor ficar inativo ou se uma máquina for retirada da rede. Por exemplo, se você mapear unidades de rede em uma máquina e removê-la da rede (talvez seja um laptop), a máquina pode parecer travada no logon enquanto o Windows tenta em vão montar as unidades de rede ausentes.

Por outro lado, nas versões mais antigas do Windows, notei que as transferências de arquivos para ou de uma unidade de rede mapeada costumam ser muito mais rápidas do que se você navegasse para a pasta de rede e executasse a mesma transferência - nesse caso, a maioria as pessoas preferem mapear unidades de rede.

A resposta simples é que não é uma coisa ruim. As unidades de rede são perfeitamente seguras para mapear como unidades.

A superstição vem do fato de que você não deve mapear unidades estrangeiras (por exemplo, Internet) como locais, porque os arquivos abertos a partir de unidades mapeadas são abertos usando a zona "local", que geralmente oferece menos proteção - e se os arquivos estão realmente chegando da Internet, isso é uma redução na segurança.

Se, como eu suspeito é o caso, você está realmente mapear int ra unidades de rede líquidos, em seguida, abrir as pastas como unidades mapeadas é exatamente tão seguro como acessá-los através de seus nomes de caminho de rede. A única diferença é que tê-los mapeados é mais conveniente.

Na minha experiência, ele se concentra principalmente em softwares mal escritos.

Se a pessoa A trabalha em um conjunto de arquivos mapeados para G:e a pessoa B tenta abrir o mesmo conjunto de arquivos com o mesmo caminho mapeado H:, as coisas falham.

Se você usar caminhos UNC, assumindo que os computadores da pessoa A e da pessoa B possam ver o ponto de compartilhamento, tudo funcionará bem.

Certamente, a solução ideal é usar um software que não armazena relacionamentos de arquivos usando caminhos absolutos, mas isso não é algo que você sempre pode controlar.

Muitos softwares nos mercados de CAD / CAM são mal escritos e mal funcionam. Como o mercado é pequeno, há pouca pressão competitiva. Conheço pelo menos um software que teve problemas com caminhos absolutos nos últimos 5 principais lançamentos e eles ainda permanecem sem correção, apesar de relatar os problemas à empresa.

Tivemos sérios problemas com as unidades de rede em que trabalho, porque às vezes o Windows não se conecta a elas e parece não conectar automaticamente uma unidade de rede quando um programa tenta acessá-la.

Pelo menos meia dúzia de vezes que um usuário da contabilidade ligou porque recebe o mesmo erro. É porque ela abriu o programa X, que está usando um arquivo mapeado na unidade de rede Y: e não está conectado por algum motivo insondável.

Duvido que o pessoal de TI esteja preocupado com um usuário mapeando uma unidade de rede, e sim com uma centena de usuários ou mil. Por exemplo, se vários hosts iniciarem a indexação de pesquisa de uma unidade ou unidades em rede ao mesmo tempo, como isso afetará todos os outros que tentam usar a rede? Quando uma unidade em rede é inevitavelmente colocada offline, ela trava centenas de máquinas até que o SO desista e elimine o mapeamento da unidade? Os PCs daqui para frente e depois inicializam mais lentamente ou não conseguem inicializar completamente se as conexões com as unidades mapeadas não puderem ser restabelecidas?

Um problema com a sintaxe \ server \ dir é que as janelas de comando não podem ser copiadas para eles. Se você possui privilégios de administrador e não deseja usar uma letra de unidade, pode usar o comando mklink para montar unidades em um diretório em vez de em uma letra de unidade. O diretório Home não deve existir.

mklink / d "c: \ Drives \ Home" "\ server \ HomeFolder \ user1"

Esta pasta é utilizável por tudo.

A montagem em um leter de unidade pode ser ruim porque é possível mudar para outro ponto de montagem. Então você está lendo e escrevendo para algo que não espera. Se os executáveis ​​de um ponto de montagem forem alterados, eles poderão conter vírus.

Minha solução requer privilégios de administrador; portanto, se você não estiver executando com direitos de administrador, será mais seguro, pois outro programa não poderá alterá-lo sem direitos de administrador.

Aqui está um bom motivo:

O Windows (pelo menos XP) não suporta caminhos de arquivo com mais de 256 caracteres. O mapeamento permite que alguém adicione um arquivo onde outros não seriam possíveis, encurtando o caminho. Então você tem um programa que navega por todos os arquivos e pastas e não está ciente do mapeamento. Sem o mapeamento, o arquivo existente tem um comprimento de caminho acima de 256. O programa falha.

Vários softwares, incluindo várias versões do Microsoft Visual Studio e CMS Bounceback, funcionarão apenas com letras de unidade e não com caminhos absolutos. Dada essa restrição, o uso de qualquer software exige que você defina as letras das unidades - você não tem escolha. Mas o Windows não facilita muito isso, pois parece solicitar um ID e senha de usuário, mas apenas um ID e senha de usuário são permitidos no Windows para todas as conexões com qualquer dispositivo de rede (por exemplo, vários discos e impressoras).

Basta conversar com algumas das centenas de consultores de TI que agora estão tendo que lidar com o recente surto de zero dia do "CryptoLocker" e você logo perceberá que as unidades mapeadas em um computador local infectado podem causar grandes danos aos dados. no servidor, através da unidade mapeada.

Especificamente:

“O CryptoLocker também acessará as unidades de rede mapeadas às quais o usuário atual tem acesso de gravação e as criptografará. Ele não atacará compartilhamentos simples de servidores, apenas unidades mapeadas. ”

Portanto, há claramente preocupações de segurança com o uso de unidades mapeadas nesta era de malware de dia zero sempre presente e recém-descoberto, atingindo os usuários com freqüência.

Eliminamos todas as unidades mapeadas em nossa LAN e usamos "compartilhamentos de rede".

Alguns motivos para não usar unidades mapeadas:

1) Eles ocupam recursos na máquina local com a unidade mapeada e os recursos de rede. Os aplicativos locais podem ficar lentos porque o computador local precisa ler o conteúdo da unidade mapeada quando o aplicativo é iniciado ou quando o sistema é inicializado. Experimente. Mapeie várias unidades e inicie o Excel. Remova o mapeamento das unidades e tente novamente.

2) Mover seu aplicativo para um novo ambiente será tedioso. No caso de recuperação de um desastre, a mudança para uma máquina mais poderosa ou se outro desenvolvedor estiver assumindo o controle do aplicativo. Se o novo ambiente não permitir unidades mapeadas ou as letras das unidades forem mapeadas de maneira diferente, alguém estará gastando tempo reescrevendo o código. O tempo economizado no front-end será mais do que perdido, corrigindo-o.

Eu sei que é um tópico antigo, mas não diria que eles são perfeitamente seguros. Removemos as unidades mapeadas devido aos riscos de segurança. Muitos vírus tentam se espalhar pelas unidades. No entanto, eles não se espalham por atalhos que apontam para compartilhamentos do DFS. Algo a ter em mente ...

Uma razão para limitar o mapeamento de unidades seria vírus de email (arquivos zip ou exe abertos por usuários um tanto "densos"), como o Cryptolocker, que alfabetizará todos os arquivos em unidades locais e mapeadas e os criptografará. (Em particular) não discrimina de acordo com as unidades. Fomos atingidos e conseguimos recuperar usando backups do (s) servidor (es), mas é claro que os arquivos locais eram "brindados".

Certos vírus e malware comuns exploram as unidades mapeadas. Essa é uma boa razão para não usá-las.

As unidades mapeadas são mais rápidas se você estiver manipulando grandes quantidades de arquivos. O Windows autentica seu acesso uma vez com uma unidade mapeada e permite que as interações com arquivos ocorram. Os caminhos UNC são autenticados pelo Windows para cada arquivo acessado. Portanto, o processo de autenticação aconteceria milhares de vezes se você estivesse manipulando milhares de arquivos em um caminho UNC. Unidade mapeada - Autentique uma vez UNC - Autentique sempre que um arquivo for acessado.

Isso pode ter implicações em algo tão simples quanto copiar arquivos. As unidades mapeadas sempre serão mais rápidas; visivelmente com um grande número de arquivos.

Não gosto de usar unidades mapeadas porque uso uma variedade de recursos de rede com pouca frequência e nunca consigo encontrar o endereço completo para outras pessoas usarem. O uso de atalhos também me permite avançar no diretório com facilidade. Se o único motivo para mapear unidades é o limite de 256 caracteres, é uma desculpa para perder todos os detalhes do local do arquivo.

Unidades mapeadas são perigosas! Nos últimos anos, com o aumento do ransomware, removi unidades mapeadas sempre que possível. O ransomware tem como alvo todas as DRIVE LETTERS e não apenas dados locais. Portanto, enquanto você estiver seguro, desde que mantenha backups redundantes, ainda é uma dor de cabeça ter que lidar com essa violação de dados.

Se você estiver em um ambiente de negócios (alvo principal do ransomware) e, se puder, livre-se das unidades mapeadas!

Certos vírus de ransomware, como a família CryptoWall , procuram por qualquer unidade mapeada e infectam essas unidades. No entanto, se o compartilhamento de rede estiver usando UNC e não uma letra de unidade, esses vírus não infectam o compartilhamento.

Em relação às considerações sobre criptografia / ransomware, Locky é um exemplo de ransomware que pode se espalhar por caminhos UNC, bem como letras de unidades mapeadas. Se a sua preocupação com as unidades de rede mapeadas e os caminhos UNC for determinada pelo potencial de ataques de ransomware, entenda que ela só protege contra alguns.

Existem várias maneiras de detectar / prevenir ataques de ransomware - e geralmente é recomendado o uso de vários métodos de proteção: proteger a rede, proteger o terminal e manter um regime de backup robusto. Pessoalmente, uso o Sophos InterceptX como uma solução anti-ransomware no endpoint, um firewall Cisco ASA (com IPS), o ShadowProtect para backup e uso de unidades de rede mapeadas onde faz sentido administrativo fazê-lo.

Disclaimer: Eu sou um arquiteto certificado Sophos. Embora eu não trabalhe na Sophos, acho que a tecnologia deles é pura. Também trabalho para um MSP, e essa é a tecnologia que decidimos após verificar as várias opções disponíveis na Austrália.

Editado conforme solicitado para fornecer mais informações para o segundo parágrafo. Além disso, eu falo australiano, não inglês, a gramática é um pouco diferente e algumas palavras são escritas de maneira diferente (é Cor, não Cor, e nem me permite iniciar no melão).

A unidade de rede é uma boa maneira de compartilhar recursos, mas não concordo com o fato de os diretórios pessoais serem colocados em uma unidade de rede compartilhável. Isso é simplesmente estúpido. A maioria dos aplicativos usa seu diretório pessoal como local para armazenar configurações específicas de aplicativos para os usuários. Se a TI quer mais uma dor de cabeça (como se eles não tivessem o suficiente para lidar com isso), a correção de dependências de aplicativos para usuários dentro da rede pode ser uma dor, pois eles podem adicionar seus problemas. Esses problemas podem ser montados em um ambiente em que muitos aplicativos são usados ​​e suas dependências e requisitos mudam. Por um lado, o trabalho pode ser dificultado para os usuários da rede e a empresa perderem dinheiro e tempo com base em baixos níveis de produtividade. Isso é algo que não pode ser arriscado. Em segundo lugar, algumas organizações mapeiam a unidade doméstica do usuário na rede para monitorar o que ' está lá. O governo faz isso muito como parte de sua exigência. Também aumenta o problema de poder trabalhar em casa. Se sua conectividade via VP tiver problemas com o aplicativo funcionando remotamente por meio de uma sessão VPN, em que você executa o aplicativo que requer uma dependência da unidade doméstica mapeada em rede e o mapeamento da unidade falhar, você estará hospedado.

Pessoalmente, acho que isso só deve ser feito por boas razões, mas não a ponto de dificultar a produtividade e afetar os resultados da empresa.

O motivo número 1 para você não querer fazer isso é que o ransomware não pode acessar um caminho UNC, mas as letras das unidades são justas. Se você deseja compartilhar um compartilhamento de rede com criptografia, continue com o mapeamento da letra da unidade.

Pessoalmente, não vejo a vantagem das letras de unidade e realmente acho os caminhos UNC mais fáceis, pois nunca preciso me preocupar em mapear as letras de unidade, especialmente depois de alterar as senhas de login. Você pode criar atalhos que não se comportam como letras de unidade e pode adicionar esses atalhos ao Windows Explorer.