Personnellement, je préfère infiniment ramener tout le trafic chez moi.
On a ainsi un contrôle effectif de ce qui sort du poste. J'ai une sainte
horreur du split-tunneling qui me parait être un bon moyen de se
constituer un joli pont entre son SI (ou celui du client) et l'internet.
C'est encore plus vrai quand les postes ne sont pas bien maîtrisés.
D'une manière général, j'ai du mal à comprendre que les choses soient
différentes quand on est en télétravail et en présentiel: que son flux
de sortie soit contrôlé par le firewall en présentiel, et pas en
distanciel par exemple.
Sinon, oui on peut faire ce genre de choses avec des socks, ou même avec
du ssh tunneling. Ou du guacamol, si on ne veut faire que du RDP et du
SSH, ou encore avec un portail sur un forti. Ou router le réseau client
dans le tunnel (c'est hyper sale et errorogène).
Mais faut vraiment aimer se faire mal, surtout pour les socks et autre
ssh tunneling.
Le 29/03/2023 à 16:43, DUVERGIER Claude a écrit :
Au vu des réponses, je comprends que j'ai mélangé différents points
sans être totalement clair alors je reprends avec plus de contexte.
Dans le cadre de nos prestations des collègues sont amenés à
travailler (pendant quelques jours, semaines ou mois) sur les sites
des clients (production ou préproduction) et notamment se connecter au
backoffice web, ou serveur de stockage FTP.
A. Parfois c'est un accès direct sans filtrage d'adresse IP.
B. Parfois c'est un accès direct mais uniquement autorisé depuis des
adresses IP préalablement déclarées.
C. Parfois c'est via un serveur bastion du client (j'ai eu les cas
d'un accès SSH et d'autres via RDP) dont l'accès et uniquement
autorisé depuis des adresses IP préalablement déclarées.
Pour le cas A : aucun problème (sauf à la limite quand notre staff
télétravaille depuis des pays "exotiques" que le client aurait par
défaut bloqué de son côté : mais c'est rare).
Pour les cas B et C : on communique au client les adresses IP
publiques qu'utilisent nos agences pour accéder à Internet, le client
les autorise et tout fonctionne (généralement pas du premier coup il
est vrai :P).
Mais quand le collègue est en télétravail il surfe via sa connexion
Internet personnelle et donc via une IP que le client ne connaît pas.
Il pourrait communiquer son IP personnelle au client qui n'aurait qu'à
la rajouter : mais ça prends généralement du temps (le client doit
contacter son prestataire, etc.) et parfois le collègue n'a carrément
pas d'adresse IP fixe (certains FAI, ou les clients nomades en
connexion cellulaire).
Alors, ce qu'on a fait dans un premier temps c'est mettre en place un
serveur proxy HTTP (Squid) dont l'accès à Internet passe par une des
adresses IP communiquées au client (le serveur est hébergé en local
dans nos locaux). Ça fonctionne pour l'HTTP, pas pour le FTP, SSH, RDP
qui sont des protocoles d'accès que certains clients nous demandent
d'utiliser.
Pour éviter d'ouvrir à tout vent ce serveur proxy, il n'est pas
accessible sur Internet : pour le contacter alors qu'on est en
télétravail/nomade on doit passer par notre service de VPN.
Ce service VPN existait déjà avant ces problématique d'accès aux BO
des clients et réponds à un tout autre besoin : permettre aux
télétravailleurs/nomades d'accéder à certaines ressources locales
(auto hébergées) du SI de notre société. Et il est configuré pour que
seul le trafic destiné au LAN y arrive (avec l'exemple d'une vidéo
YouTube consultée pendant le télétravail qui ne passerait donc pas via
le VPN).
Mes solutions envisagées :
* Trouver un outil qui "sache" proxyfier de l'HTTP, FTP, SSH, RDP, etc.
Un proxy en SOCKS5 peut faire tout ça ?
* Mettre en place, en interne, un bastion sous la forme d'un bureau
virtuel où l'utilisateur aurait navigateur web, client FTP/SSH/RDP
* Capter tout le trafic réseau via le tunnel VPN : ainsi les
collaborateurs apparaissent comme étant tout le temps "au bureau".
Vu le nombre de prestation et la durée de celle-ci, je préfère avoir
une solution qui ne me demande pas de configuration dédiée à chaque
besoin.
Il existe évidemment plein de solutions techniques que le client
auraient pu mettre en place pour simplifier le tout (dans le style de
Boundary de HashiCorp, Envoy Proxy de Lyft, etc.) mais je dois
généralement composer avec ce qu'ils ont.
Je me dis que je ne dois pas être le seul à avoir ces problématiques
d'accès filtrés aux ressources des clients ? Si ?
--
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/