Zoom
Zoom
Choisir parmi trois technologies de réseaux privés virtuels pour sécuriser les accès distants
Edition du 19/05/2006 - par
Olivier Descamps
Deux normes de réseaux privés virtuels (IPSec et SSL) permettent aujourd'hui d'interconnecter deux sites distants en toute sécurité. Une troisième (MPLS) garantit la qualité de service des flux qui vont être échangés.
Les informations transportées entre deux réseaux locaux d'une même entreprise ou entre le PC portable d'un utilisateur nomade et les applications qu'il utilise au travers d'Internet ne sont pas à l'abri du piratage. Et l'intérêt d'établir des liens sécurisés pour protéger les connexions distantes n'est plus à démontrer. Mais les entreprises en général, et les PME en particulier, ont rarement les moyens de se payer des réseaux privés de type relais de trames pour cette protection. Elles se tournent donc le plus souvent vers des réseaux privés virtuels (RPV ou VPN de l'anglais Virtual Private Network), tunnels sécurisés au-dessus de liaisons partagées par de multiples utilisateurs. Le constat établi, reste la question de la technologie à employer pour créer ces RPV. Il en existe trois principalement : IPSec (Internet Protocol Security), SSL (Secure Socket Layer) et MPLS (MultiProtocol Label Switching).
IPSec sur le déclin
Longtemps promise à un bel avenir, la norme de réseaux privés virtuels IPSec est aujourd'hui mise à mal par ses rivales. Son principe de fonctionnement est pourtant relativement simple : avant le partage de flux IP, un client IPSec va authentifier l'utilisateur ou le réseau distant. Ensuite, un algorithme de chiffrement servira à sécuriser l'ensemble des flux IP échangés. Au niveau IP, on pourra considérer qu'il n'y a plus qu'un réseau, même si une de ses portions traverse Internet et côtoie de multiples flux qui n'ont rien à voir.
Le principal inconvénient d'IPSec, c'est sa gestion. Lorsqu'on veut interconnecter de multiples réseaux, il faut reparamétrer toutes les machines à chaque nouvel entrant. Et mieux vaut disposer d'un parc de passerelles de RPV homogène car la compatibilité IPSec, affichée par tous les constructeurs, a ses limites. Enfin, les flux IPSec ne sont pas totalement transparents pour les équipements réseau qu'ils rencontrent : ils traversent difficilement certains pare-feu, proxys ou produits de translation d'adresse (NAT).
Un avenir plus radieux pour SSL
Au contraire, SSL séduit par sa simplicité. En quelques années, tous les grands constructeurs ont ajouté la technologie à leurs équipements de sécurité. Soit par le biais de développements internes, soit en s'offrant des jeunes pousses spécialisées. Si l'on en croit les experts en sécurité, ce sont les utilisateurs eux-mêmes qui sont à la base de l'explosion de l'offre. Dès la sortie des premiers produits, ils ont d'ailleurs connu un succès considérable. En termes de sécurité, IPSec et SSL sont très semblables, reposant sur les mêmes opérations (authentification puis chiffrement) et les mêmes algorithmes. SSL gagne en revanche nettement dès que l'on parle de mise en place et d'administration. Contrairement à IPSec, aucun logiciel client ne doit être installé sur les postes de travail distants puisque de nombreux logiciels supportent déjà les spécifications de la norme. A l'image des navigateurs web pour l'échange de flux http sécurisé (https).
MPLS complique encore la donne
SSL réussira-t-il pour autant à enterrer son prédécesseur ? Pas sûr, car le protocole est limité à quelques flux applicatifs dont le Web, pour lequel il a été conçu à l'origine par Netscape. Les applications sont certes de plus en plus « internetisées », mais SSL ne donne pas encore accès à tous les fichiers distants de l'entreprise. IPSec et SSL pâtissent en outre du même défaut : une absence totale de qualité de service. On sait qu'un flux traversant Internet sera parfaitement protégé de bout en bout, mais impossible d'utiliser l'un des deux protocoles pour garantir la vitesse de transmission des données. Comme si une autoroute traversant une ville assurait l'absence de piétons et de voitures en sens inverse, mais pas celle de feux rouges et de stop !
Comme remède, les opérateurs proposent désormais la technologie MPLS qui combine l'utilisation d'un coeur de réseau performant et redondant, avec notamment la rapidité de commutation de la couche liaison (niveau 2 du modèle OSI), et l'intelligence de routage des réseaux IP (niveau 3). MPLS accélère donc les flux en même temps qu'il donne la priorité aux applications critiques (voix sur IP, bases de données...). Pour cela, il fait appel à une technologie d'étiquetage des paquets IP et assure un traitement différencié des flux selon leur marquage. A l'origine assez chères par rapport aux réseaux privés virtuels IPSec ou SSL, les liaisons MPLS le sont nettement moins aujourd'hui, notamment pour les interconnexions nationales. En outre, les opérateurs peuvent gérer un nombre illimité de liens.
Bien entendu, comme dit l'adage, personne n'est parfait. Les réseaux privés virtuels MPLS ont donc leur défaut : ils offrent une très bonne qualité de service, mais ne garantissent pas la sécurité des flux. Ils sont transmis sans protection sur les coeurs de réseau des opérateurs. Reste donc une dernière approche : créer des tunnels IPSec sur réseau MPLS. C'est par exemple ce qu'a choisi France Télécom avec son offre de connexion distante pour travailleurs nomades Business Everywhere. Avant d'accéder au réseau de son entreprise (par ADSL, Wi-Fi, GPRS, 3G...), l'utilisateur doit systématiquement s'authentifier auprès d'un serveur de l'opérateur qui crée un tunnel IPSec transitant par son réseau MPLS jusqu'au réseau local de l'entreprise. Et cette fois-ci, c'est l'opérateur qui se charge des déploiements et de l'administration.

Une porte d'entrée sur le réseauSi le réseau privé virtuel garantit l'intégrité des liaisons d'accès, il ne protège pas le réseau local de l'entreprise, bien au contraire. Car un tunnel peut constituer, pour les éventuels pirates, une porte d'entrée grande ouverte sur le réseau principal si le site secondaire ou l'utilisateur distant relié par RPV ne sont pas correctement protégés. Surtout si les flux chiffrés dans le RPV ne sont pas toujours contrôlés par le pare-feu ! Deux solutions se présentent pour pallier à ces inconvénients. Premièrement, déployer des outils d'analyse d'intégrité et de vulnérabilité des équipements qui ouvrent des sessions RPV. On peut par exemple empêcher un PC de se connecter au réseau si son antivirus n'est pas à jour et n'établir la connexion que lorsqu'une analyse complète du système aura été opérée. Deuxièmement, appliquer une politique de détection de codes malicieux dans les flux du tunnel en faisant du déchiffrement/rechiffrement à la volée, soit au niveau du pare-feu, soit au niveau d'un bouclier applicatif.
>> Obtenir des devis gratuitement de prestataires IT