Récupérer un fichier ne nécessite pas un VPN réseau complet

Une demande d'accès VPN cache souvent un dossier et un fichier derrière elle. Accorder une route à tout le réseau du bureau répond à la demande et remet bien plus que ce que la tâche exige. Remplacer un partage monté par une page de téléversement peut être tout aussi erroné dans l'autre sens, car cela change la façon dont les gens travaillent. La décision commence par ce qui doit arriver au fichier.

Trois besoins se ressemblent ici et se comportent très différemment : copier un PDF terminé, modifier un document sur place et exécuter une application sur un répertoire partagé.

Partez de la modification, pas du dossier

Si le fichier est terminé et qu'il ne faut que le lire, un compte de transfert suffit. S'il doit être modifié, la question devient qui d'autre le modifie et comment les conflits se règlent, ce qui est une question de flux de travail et non de réseau. Si l'application ouvre les documents directement depuis le répertoire, la latence et le comportement de verrouillage de la couche de stockage comptent. Répondre à cela d'abord évite une solution qui se connecte parfaitement et reste inutilisable.

La modification partagée introduit un problème qu'aucun transfert ne peut résoudre. Un utilisateur télécharge un tableur, le modifie hors ligne et le téléverse après que quelqu'un d'autre a changé l'original, et la connexion chiffrée n'a pas d'avis sur l'écrasement. Un accord sur l'écrasement, le conflit ou le versionnage doit exister avant la méthode d'accès.

SFTP est un protocole de transfert, pas un partage

SFTP déplace des fichiers sur un transport SSH chiffré, ce qui est exactement ce dont une copie a besoin et non ce dont un lecteur monté a besoin. Ce n'est pas FTP, et un produit proposant FTPS propose un autre protocole plutôt que SFTP. Monter un répertoire SFTP via une couche de système de fichiers ne garantit pas le verrouillage, les permissions ou le comportement applicatif du partage d'origine. Vérifiez les exigences de l'application cliente avant de parler de remplacement direct.

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

C'est tout le flux de travail pour un fichier terminé : se connecter, déposer, récupérer. Un compte de transfert seul a aussi besoin d'un service SSH restreint, pas seulement du système de fichiers. Un chroot ou ForceCommand internal-sftp limite ce que la session peut exécuter, et désactiver la redirection TCP et le tunnellisation ferme les chemins qui feraient autrement d'un compte de fichiers un point d'entrée réseau. Restreindre uniquement le répertoire visible ne prouve rien sur ce que le compte peut atteindre.

Si vous avez besoin du partage, ne le publiez pas

Parfois le partage d'origine est réellement l'exigence, et la réponse n'est pas d'exposer SMB à des clients Internet arbitraires. La recommandation de Microsoft est de bloquer le trafic SMB direct à la frontière, et pour une bonne raison : le protocole n'a pas été conçu pour affronter des réseaux non fiables. SMB sur QUIC et des conceptions comparables existent, avec des exigences de plateforme spécifiques aux deux extrémités, et ils ne sont pas un interrupteur universel pour un serveur Samba arbitraire. Si aucun ne s'applique, le travail consiste à fournir un chemin d'accès pris en charge plutôt qu'un port redirigé.

L'option basée sur le navigateur est une troisième réponse légitime lorsque le travail s'y prête. Elle apporte ses propres décisions : comptes, liens de partage, expiration, versions conservées et quelle copie fait autorité. Un lien que n'importe qui peut ouvrir et un espace de travail qui exige une connexion représentent des politiques d'accès différentes, et aucune ne devrait être choisie par accident.

Ce qu'il faut vérifier avant de remettre l'accès

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

Quelle que soit la conception retenue, limitez-la aux données et aux opérations prévues. La première commande devrait réussir et la seconde être refusée ; si les deux réussissent, le compte est plus large que la tâche. Retirez ensuite le compte et répétez la première, qui devrait maintenant échouer. Gardez le propriétaire des fichiers sources identifiable, afin qu'une question ultérieure sur la copie faisant autorité ait une réponse. Le résultat qui mérite d'être consigné est un flux de travail de fichiers utilisable et révocable, pas une icône de connexion manquante.

Notez quel protocole l'application de l'utilisateur nécessite réellement et quels trois tests vous avez exécutés. Ces deux lignes évitent l'essentiel du retravail.