Baixar um arquivo não exige uma VPN de rede completa
Uma pasta e um arquivo raramente justificam uma rota para toda a LAN do escritório. Compare as opções de transferência, compartilhamento e navegador conforme o trabalho que o usuário precisa fazer.
Um pedido de acesso VPN muitas vezes esconde uma pasta e um arquivo por trás. Conceder uma rota para toda a rede do escritório responde ao pedido e entrega muito mais do que a tarefa exige. Substituir um compartilhamento mapeado por uma página de upload pode ser igualmente errado na direção oposta, porque muda como as pessoas trabalham. A decisão começa pelo que precisa acontecer com o arquivo.
Três requisitos parecem iguais aqui e se comportam de forma muito diferente: copiar um PDF pronto, editar um documento no lugar e executar um aplicativo contra um diretório compartilhado.
Comece pela edição, não pela pasta
Se o arquivo está pronto e só precisa ser lido, uma conta de transferência basta. Se ele for editado, a pergunta passa a ser quem mais o edita e como os conflitos são resolvidos, o que é uma questão de fluxo de trabalho e não de rede. Se o aplicativo abre documentos diretamente do diretório, importam a latência e o comportamento de bloqueio da camada de armazenamento. Responder isso primeiro evita uma solução que conecta perfeitamente e ainda assim não pode ser usada.
A edição compartilhada introduz um problema que nenhuma transferência consegue resolver. Um usuário baixa uma planilha, edita offline e a envia depois que outra pessoa alterou o original, e a conexão criptografada não tem opinião sobre a sobrescrita. O acordo sobre sobrescrita, conflito ou versionamento precisa existir antes do método de acesso.
SFTP é um protocolo de transferência, não um compartilhamento
O SFTP move arquivos por um transporte SSH criptografado, que é exatamente o que uma cópia precisa e não o que uma unidade mapeada precisa. Não é FTP, e um produto que oferece FTPS oferece outro protocolo em vez de SFTP. Montar um diretório SFTP por uma camada de sistema de arquivos não promete o bloqueio, as permissões ou o comportamento de aplicações do compartilhamento original. Verifique os requisitos do aplicativo cliente antes de chamá-lo de substituto direto.
sftp [email protected] put report.pdf /upload/report.pdf get /shared/template.docx
Esse é todo o fluxo de trabalho para um arquivo pronto: conectar, colocar, obter. Uma conta apenas de transferência também precisa do serviço SSH restrito, não só do sistema de arquivos. Um chroot ou ForceCommand internal-sftp limita o que a sessão pode executar, e desativar o encaminhamento TCP e o túnel fecha os caminhos que de outra forma transformariam uma conta de arquivos em um ponto de entrada de rede. Restringir apenas o diretório visível não prova nada sobre o que a conta pode alcançar.
Se você precisa do compartilhamento, não o publique
Às vezes o compartilhamento original é de fato o requisito, e a resposta não é expor o SMB a clientes de internet arbitrários. A orientação da Microsoft é bloquear o tráfego SMB direto na fronteira, e por um bom motivo: o protocolo não foi construído para enfrentar redes não confiáveis. Existem SMB sobre QUIC e projetos comparáveis, com requisitos específicos de plataforma nas duas pontas, e eles não são um interruptor universal para um servidor Samba arbitrário. Se nenhum se aplica, o trabalho é fornecer um caminho de acesso suportado em vez de uma porta encaminhada.
A opção baseada em navegador é uma terceira resposta legítima quando o trabalho se encaixa. Ela traz suas próprias decisões: contas, links de compartilhamento, expiração, versões mantidas e qual cópia é a autoritativa. Um link que qualquer um pode abrir e um espaço de trabalho que exige login representam políticas de acesso diferentes, e nenhuma delas deve ser escolhida por acidente.
O que verificar antes de entregar o acesso
sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx" ssh [email protected] "cat /etc/passwd"
Seja qual for o projeto escolhido, limite-o aos dados e às operações previstos. O primeiro comando deve funcionar e o segundo ser recusado; se ambos funcionarem, a conta é mais ampla do que a tarefa. Em seguida, remova a conta e repita o primeiro, que agora deve falhar. Mantenha o proprietário dos arquivos de origem identificável, para que uma pergunta posterior sobre a cópia autoritativa tenha resposta. O resultado que vale registrar é um fluxo de trabalho de arquivos utilizável e revogável, não um ícone de conexão ausente.
Anote qual protocolo o aplicativo do usuário realmente precisa e quais três testes você executou. Essas duas linhas evitam a maior parte do retrabalho.