Porque é mau mapear unidades de rede no Windows?

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 unidade, para além dos caminhos da rede. Para um, pode haver demasiadas partilhas de rede comummente utilizadas para atribuir letras de unidade a todos eles, e numa grande organização, nem todos terão acesso a todas as mesmas partilhas. Os nomes das acções são também mais descritivos e potencialmente menos ambíguos do que as letras de unidade (mais sobre a ambiguidade mais tarde).

Segundo, pode deparar-se com colisões de letras de unidade. Se o PC de alguém tiver um leitor de cartões de memória, isso pode devorar quatro ou mais letras de unidade. A e B são normalmente reservadas para as unidades de disquetes do século passado, e C e D são normalmente reservadas para o disco rígido e unidade óptica, pelo que o leitor de cartões utilizará E, F, G, e H. Se uma das suas unidades de rede for normalmente mapeada para H: através de um script de logon, esta pobre pessoa ou não será capaz de utilizar a unidade H: do leitor de cartões ou não será capaz de montar a unidade de rede.

A menos que alguém dentro da organização seja responsável pela atribuição de unidades de leitura de cartões para fins específicos, as unidades de rede podem também acabar por causar muita confusão. Por exemplo, suponha que mapeia a drive S: para a partilha que tem os programas de configuração para todo o seu software licenciado pelo site, e alguém mapeia S: para a drive partilhada onde deixam cair todo o tipo de documentos partilhados. Quando tenta explicar como instalar algum software, diz-lhes para abrirem a drive S: e encontrarem o programa de instalação para o Microsoft Office, mas tudo o que conseguem encontrar é uma pasta chamada office, que contém um monte de ficheiros diversos que alguém lá deixou para uma transferência temporária de ficheiros. Pode demorar 5 ou 10 minutos a resolver a confusão.

Há também alguns problemas potenciais de desempenho se um servidor for desligado ou se uma máquina for retirada da rede. Por exemplo, se mapear unidades de rede numa máquina, depois remover a máquina da rede (talvez seja um portátil), a máquina pode parecer pendurada no início de sessão enquanto o Windows tenta em vão montar as unidades de rede em falta.

Por outro lado, em versões mais antigas do Windows, reparei que as transferências de ficheiros de ou para uma unidade de rede mapeada muitas vezes vão muito mais depressa do que se navegasse para a pasta de rede e realizasse a mesma transferência de ficheiros - nesse caso, a maioria das pessoas preferiria mapear unidades de rede.

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

A superstição vem do facto de não se dever mapear unidades foreign (isto é, Internet) como locais porque os ficheiros abertos a partir de unidades mapeadas são abertos utilizando a zona “local”, o que geralmente lhes proporciona menos protecção - e se os ficheiros forem realmente provenientes da Internet isto é uma redução na segurança.

Se, como suspeito ser o caso, estiver de facto a mapear unidades de rede int ra, então abrir as pastas como unidades mapeadas é exactamente tão seguro como aceder a elas através dos nomes dos seus caminhos de rede. A única diferença é que tê-las mapeadas é mais conveniente.

Na minha experiência, centra-se sobretudo em software mal escrito.

Se a pessoa A trabalha num conjunto de ficheiros que são mapeados para G:, e depois a pessoa B tenta abrir o mesmo conjunto de ficheiros com o mesmo caminho mapeado para H:, as coisas falham.

Se usar caminhos UNC, então assumindo que os computadores da pessoa A e da pessoa B podem ambos ver o ponto de partilha, tudo funcionará bem.

Claro, a solução ideal é usar software que não armazene relações de ficheiros usando caminhos absolutos, mas isso não é algo que se possa sempre controlar.

& Muito software nos mercados CAD/CAM está mal escrito, e mal funciona de todo. Uma vez que o mercado é bastante pequeno, há pouca pressão competitiva. Conheço pelo menos um software que teve problemas com caminhos absolutos para os last 5 grandes lançamentos, e que ainda não foram resolvidos, apesar de relatar os problemas à empresa.

Tivemos sérios problemas com unidades de rede onde eu trabalho porque por vezes o Windows não se liga a elas, e parece não ligar automaticamente uma unidade de rede quando um programa tenta aceder a ela.

Pelo menos meia dúzia de vezes um utilizador da contabilidade ligou porque recebe o mesmo erro. É porque ela abriu o programa X, que está a utilizar um ficheiro mapeado na unidade de rede Y:, e não está ligado por alguma razão insondável.

Duvido que os tipos das TI estejam preocupados com um utilizador que mapeia uma unidade de rede, em vez disso, estão preocupados com uma centena ou mil utilizadores. Por exemplo, se um bando de anfitriões inicia a indexação da pesquisa de uma unidade de rede ou unidades ao mesmo tempo, como é que isso irá afectar todos os outros que tentam utilizar a rede? Quando uma unidade em rede é inevitavelmente desligada, irá bloquear centenas de máquinas até o SO desistir e largar o mapeamento da unidade? Será que os PCs vão arrancar mais lentamente ou não arrancar completamente se as ligações às unidades mapeadas não puderem ser restabelecidas?

Um problema com a sintaxe do \server é que as janelas de comando não podem cd para eles. Se tiver privilégios de administrador e não quiser usar uma letra de unidade, pode usar o comando mklink para montar unidades num directório em vez de uma letra de unidade. O directório Home não deve existir.

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

Esta pasta é utilizável por tudo.

Montar num leitor de drive pode ser mau porque é possível que mude para outro ponto de montagem. Então está a ler e a escrever para algo que não espera. Se os executáveis de uma mudança de ponto de montagem, podem conter vírus.

A minha solução requer privilégios de administrador, por isso se não estiver a correr com direitos de administrador, é mais seguro uma vez que outro programa não poderia alterá-lo em si sem direitos de administrador.

Uma série de peças de software, incluindo várias versões do Microsoft Visual Studio e CMS Bounceback, só funcionarão com letras de unidade e não com caminhos absolutos. Dada esta restrição, a utilização de tal software requer que se defina as letras de unidade - não tem escolha. Mas o Windows não torna isto muito fácil, pois parece pedir um ID de utilizador e senha, mas apenas um ID de utilizador e senha é permitido no Windows para todas as ligações a qualquer dispositivo de rede (por exemplo, vários discos e impressoras).

Aqui está uma boa razão:

Windows (pelo menos XP) não suporta caminhos de ficheiros com mais de 256 caracteres. O mapeamento permite a alguém adicionar um ficheiro onde outro não seria possível, encurtando o caminho. Depois tem um programa que navega por todos os ficheiros e pastas, e não está ciente do mapeamento. Sem o mapeamento, o ficheiro existente tem um comprimento de caminho superior a 256 caracteres. O programa trava.

Basta falar com algumas das centenas de consultores de TI que agora têm de lidar com o recente surto de “CryptoLocker” de dia zero e em breve se aperceberá de que a condução de dados mapeados num computador local que é infectado pode causar danos maciços nos dados do servidor, através da unidade mapeada.

Especificamente:

“CryptoLocker também terá acesso às unidades de rede mapeadas a que o utilizador actual tem acesso por escrito e encripta-as. Não irá atacar simples partilhas de servidor, apenas unidades mapeadas”.

Assim, existem claramente preocupações de segurança com a utilização de unidades mapeadas nesta era de malware de dia zero sempre presente e recentemente descoberto que atinge os utilizadores frequentemente.

Eliminámos todas as unidades mapeadas através da nossa LAN e utilizamos “partilhas de rede” em vez disso.

Algumas razões para não utilizar unidades mapeadas:

1) Absorvem recursos tanto na máquina local com a unidade cartografada como nos recursos da rede. As aplicações locais podem tornar-se lentas porque o seu computador local tem de ler o conteúdo da unidade mapeada quando a aplicação é lançada ou quando o sistema é inicializado. Experimente-o. Mapear um monte de unidades e lançar o Excel. Desmarque as unidades e volte a experimentá-lo.

2) Mudar a sua aplicação para um novo ambiente será enfadonho. No caso de um desastre recuperar, mudar para uma máquina mais potente, ou se outro programador estiver a assumir a sua aplicação. Se o novo ambiente não permitir unidades mapeadas ou se as letras das unidades forem mapeadas de forma diferente, então alguém está a perder tempo a reescrever o código. O tempo poupado na parte da frente será mais do que perdido a consertá-lo.

As unidades mapeadas são mais rápidas se estiver a manipular grandes quantidades de ficheiros. O Windows autentica o seu acesso uma vez com uma unidade mapeada, e depois permite que as interacções de ficheiros se realizem. Os caminhos UNC são autenticados pelo Windows para cada ficheiro acedido. Assim, o processo de autenticação aconteceria milhares de vezes se estivesse a manipular milhares de ficheiros sob um caminho UNC. Unidade mapeada - Autenticar uma vez UNC - Autenticar cada vez que um ficheiro é acedido.

Isto pode ter implicações com algo tão simples como a cópia de ficheiros. As unidades mapeadas serão sempre mais rápidas; notavelmente com um grande número de ficheiros.

Certos vírus e malware generalizados irão explorar unidades mapeadas. Isso é uma razão tão boa como qualquer outra para não as utilizar.

Uma razão para limitar o mapeamento de unidades seria os vírus de e-mail (ficheiros zip ou exe abertos por utilizadores algo “densos”) como o Cryptolocker que irá alfabetizar todos os ficheiros em unidades locais e cartografadas e encriptá-los. (em particular) não discrimina de acordo com as unidades. Fomos atingidos, e conseguimos recuperar utilizando backups do(s) servidor(es), mas é claro que os ficheiros locais foram “brindados”.

Sei que é um fio antigo, mas não diria que são perfeitamente seguros. Removemos as unidades mapeadas por causa dos riscos de segurança. Muitos vírus tentam propagar-se através das unidades. No entanto, não se propagam através de atalhos que apontam para acções da DFS. Algo a ter em mente…

Em relação às considerações sobre criptografia/ransomware, Locky é um exemplo de resgate que se pode espalhar através de caminhos UNC, bem como cartas de condução mapeadas. Se a sua preocupação re: unidades de rede mapeadas versus caminhos UNC é determinada pelo potencial de ataques de resgate, compreenda que apenas protege contra alguns.

Há várias formas de detectar/prevenir ataques de resgate - e recomenda-se geralmente a utilização de múltiplos métodos de protecção: proteger a rede, proteger o ponto final, e manter um regime de backup robusto. Utilizo pessoalmente o Sophos InterceptX como solução anti-ransomware no endpoint, uma firewall Cisco ASA (com IPS), ShadowProtect para backup e utilizo unidades de rede mapeadas onde faz sentido, do ponto de vista administrativo, fazê-lo.

Exoneração de responsabilidade: Sou um Arquitecto Certificado Sophos. Embora eu não trabalhe para a Sophos, penso que a sua tecnologia é pura. Também trabalho para um MSP, e essa é a tecnologia que decidimos depois de verificar as várias opções disponíveis na Austrália.

Editado conforme solicitado para dar mais informações para o segundo parágrafo. Além disso, falo australiano, não inglês, a gramática é ligeiramente diferente e algumas palavras são soletradas de forma diferente (é Cor, não Cor, e nem sequer me ponha a falar de melão).

Não gosto de utilizar unidades mapeadas porque utilizo uma variedade de recursos de rede com pouca frequência e nunca consigo encontrar o endereço completo para que outros o utilizem. A utilização de atalhos também me permite subir no directório com facilidade. Se a única razão para mapear unidades é o limite de 256 caracteres, isso é uma desculpa lamentável para perder todo aquele detalhe de localização do ficheiro.

As unidades mapeadas são perigosas! Nos últimos anos, com a vaga de resgates, tenho vindo a remover as unidades mapeadas sempre que possível. O Ransomware tem como alvo todas as CARTAS DE RANOMO e não apenas os dados locais. Assim, enquanto se mantiverem backups redundantes, continua a ser uma dor de cabeça ter de lidar com uma tal quebra de dados.

Se estiver num ambiente empresarial (alvo principal do resgate de dados), e se puder, livre-se de unidades mapeadas!!

Certos vírus de resgate, tais como a família CryptoWall , procuram qualquer unidade mapeada e infectam essas unidades. No entanto, se a partilha de rede estiver a usar UNC e não uma letra de unidade, então estes vírus não infectam a partilha.

O número 1* razão pela qual não quereria fazer isto é que o serviço de resgate não pode aceder a um caminho UNC, mas as cartas de condução são um jogo justo. Se gostaria de partilhar em rede o cryptolocked então, por todos os meios, continue com o mapeamento de cartas de condução.

Eu pessoalmente não vejo a vantagem das letras de unidade e acho que os caminhos UNC são mais fáceis porque nunca tenho de me preocupar com o mapeamento de letras de unidade, especialmente depois de mudar as palavras-passe de início de sessão. Pode criar atalhos que não se comportam de forma diferente das letras de unidade e pode adicionar esses atalhos ao Windows Explorer.

A unidade de rede é uma boa forma de partilhar recursos, mas não concordo com o facto de que os directórios domésticos sejam colocados numa unidade de rede partilhável. Isso é simplesmente uma estupidez flagrante. A maioria das aplicações utiliza o seu directório home como local para armazenar definições de aplicações específicas para os utilizadores. Se as TI querem mais uma dor de cabeça (como se não tivessem o suficiente para lidar com ela), então corrigir as dependências das aplicações para os utilizadores dentro da rede pode ser uma dor que eles podem acrescentar o seu saco de problemas. Estes problemas podem ser montados num ambiente onde muitas destas aplicações são utilizadas e as suas dependências e requisitos mudam. Por um lado, o trabalho pode ser dificultado para os utilizadores da rede e a empresa perde dinheiro e tempo com base em baixos níveis de produtividade. Isto é algo que não pode ser arriscado. Em segundo lugar, algumas organizações mapeiam a drive de casa do utilizador na rede para monitorizar o que lá se encontra. O governo faz isso muitas vezes como parte das suas exigências. Também acrescenta ao problema de poder trabalhar a partir de casa. Se a sua conectividade via VP tiver problemas com a sua aplicação a funcionar remotamente através de uma sessão VPN, onde executa a sua aplicação que requer uma dependência da sua unidade doméstica mapeada de rede e o mapeamento da unidade falhar, então é hostilizado.

Pessoalmente, penso que só deve ser feito por boas razões, mas não ao ponto de impedir a produtividade e afectar o resultado final da empresa.