Éditorial

Le télétravail généralisé a rendu le périmètre réseau insuffisant, tandis que beaucoup d’organisations ont seulement ajouté un VPN à une architecture inchangée.

~11 min de lecture7 sections

Pourquoi le VPN ne remplace pas le périmètre

Le télétravail a déplacé les utilisateurs, les terminaux et parfois les données hors du réseau supposé maîtrisé. Ajouter un VPN (Virtual Private Network) rétablit un chemin chiffré vers le réseau interne, mais ne restaure ni la confiance du poste, ni la pertinence du réseau comme frontière de sécurité.

→ Lire l’explication complète de la marmotte

Le VPN prolonge le réseau, il ne recrée pas le périmètre

Le modèle périmétrique classique repose sur une hypothèse : le réseau interne est plus fiable que l’extérieur. Le pare-feu filtre l’entrée, les applications internes accordent une confiance implicite aux adresses privées, et l’authentification se concentre à la frontière. Cette hypothèse était déjà fragile avant le télétravail. Elle devient franchement bancale dès qu’un ordinateur personnel, un poste administré partiellement ou un terminal compromis rejoint le réseau interne à travers un tunnel.

Le VPN chiffre le transport entre un client et une passerelle. Il ne vérifie pas qu’une application interne est correctement conçue, ne segmente pas spontanément les flux et ne transforme pas un poste infecté en terminal sain. Une fois connecté, le client obtient souvent une route vers des sous-réseaux entiers, parfois vers les contrôleurs de domaine, les partages de fichiers et les consoles d’administration. C’est une extension de réseau, pas une politique d’accès applicative.

Le compromis central est net : le VPN offre une continuité opérationnelle rapide et compatible avec les applications héritées, au prix d’un domaine de confiance élargi. Une architecture orientée identité réduit fortement ce domaine, mais impose un inventaire des applications, des flux et des dépendances d’authentification. La recommandation est de conserver le VPN uniquement pour les cas où le protocole ne peut pas être publié derrière un point de contrôle applicatif ou segmenté proprement. Le VPN ne doit plus constituer le chemin d’accès par défaut aux services métier.

La version plaquette du Zero Trust Network Access, ou ZTNA, consiste à repeindre un portail VPN en bleu nuit. La version qui résiste à la production commence par nommer les ressources, leurs propriétaires et leurs flux. Curieusement, l’inventaire ne fait toujours pas vibrer les présentations commerciales.

Le déplacement du travail a aussi déplacé les dépendances invisibles : résolution DNS (Domain Name System), impression, découverte réseau, authentification intégrée, synchronisation de fichiers, outils de support et accès aux sauvegardes. Forcer le trafic Internet complet dans le tunnel, pratique dite full tunnel, centralise l’inspection mais surcharge les concentrateurs et crée une dépendance massive au site central. Le split tunneling, qui laisse sortir une partie du trafic directement vers Internet, réduit cette charge mais ouvre des chemins simultanés entre un poste connecté au réseau interne et un réseau local non maîtrisé.

Aucun des deux choix n’est neutre. Le full tunnel convient aux postes administrés, aux politiques de filtrage centralisées et aux besoins d’investigation réseau. Le split tunneling ne devient acceptable que si le terminal est durci, que le filtrage local est imposé, que les services internes sont segmentés et que les flux exclus sont explicitement limités. Exclure « Internet » est une politique. Exclure quelques destinations documentées peut devenir une exception contrôlable.

Pour les fondations de cette segmentation, voir l’architecture cyber et les principes de réseaux.

Identité, appareil et application : remplacer la confiance de réseau

L’accès moderne doit évaluer trois choses distinctes : l’identité qui demande l’accès, l’état du terminal utilisé et la ressource demandée. Les fusionner dans une connexion VPN produit un verdict grossier : connecté ou non connecté. Or un compte compromis sur un poste conforme, un poste compromis avec un compte légitime et un service exposé sans contrôle applicatif sont trois incidents différents, avec des contre-mesures différentes.

L’authentification multifacteur, ou MFA (Multi-Factor Authentication), doit être résistante à l’hameçonnage pour les accès sensibles. Un code à usage unique saisi dans une fausse page reste un code volé. Les mécanismes fondés sur une clé cryptographique liée au site demandé réduisent ce risque, à condition que la récupération de compte ne contourne pas silencieusement cette exigence. Le portail de réinitialisation est souvent le vrai périmètre. Il reçoit rarement les mêmes regards admiratifs que la MFA, ce qui lui laisse le champ libre pour faire des dégâts.

L’état du terminal doit provenir d’une autorité de gestion distincte de la passerelle d’accès : chiffrement de disque activé, correctifs minimaux, agent de protection actif, verrouillage d’écran, certificat machine et conformité de configuration. Cette posture n’est pas une preuve d’absence de compromission. Elle sert à réduire le risque et à bloquer les écarts connus. Un terminal conforme peut exécuter un logiciel malveillant. Une étiquette verte n’est pas une exorcisation.

Le ZTNA publie une application ou un service précis après authentification et contrôle de contexte. Il évite de rendre le réseau entier joignable. Pour les applications web, un proxy inverse applique l’authentification, des règles d’autorisation et des en-têtes de sécurité avant le serveur. Pour les protocoles non web, un connecteur applicatif ou un bastion limite la portée de la session. L’accès d’administration doit passer par des chemins séparés, journalisés et à durée limitée, jamais par le même accès large que la messagerie ou les outils bureautiques.

La décision d’autorisation doit relier une identité à une ressource et à une action : lire un dossier, administrer une machine, accéder à une console, lancer une extraction. Un groupe « VPN-Users » ne porte aucune information métier. Il dit seulement que quelqu’un possède un tunnel, ce qui est une façon très chère de ne rien savoir.

Les applications qui ne supportent que l’authentification réseau ou les protocoles anciens demandent un traitement explicite. Soit les encapsuler derrière un bastion et une segmentation stricte, soit planifier leur remplacement. Les exposer via un VPN global revient à transférer leur dette technique dans les salons, les trains et les réseaux Wi-Fi douteux. La dette voyage léger.

Surface d’attaque du télétravail et contre-mesures vérifiables

La première attaque vise les identifiants. Hameçonnage, vol de cookies de session, fatigue MFA et réinitialisation frauduleuse permettent d’obtenir un accès distant sans exploiter une faille réseau. Réduire cette surface exige une MFA résistante à l’hameçonnage, des sessions courtes pour les actions à privilèges, une détection des connexions anormales et un processus de récupération soumis à une validation forte.

La deuxième attaque vise le terminal. Un logiciel malveillant présent avant la connexion utilise le VPN comme un câble réseau virtuel. Il explore les ports ouverts, tente des identifiants récupérés localement, exploite les protocoles d’administration et chiffre les partages accessibles. La segmentation doit donc s’appliquer après la connexion : listes de flux minimales, isolation des postes entre eux, interdiction des protocoles d’administration depuis les segments utilisateurs, et accès aux serveurs par relais dédiés.

La troisième attaque vise les équipements d’accès eux-mêmes. Une passerelle VPN ou un concentrateur ZTNA exposé sur Internet reçoit les scans, les tentatives par mot de passe et les exploits avant tout le reste. Les correctifs de ces composants sont prioritaires, pas « à la prochaine fenêtre trimestrielle ». L’interface d’administration doit être séparée du plan d’accès utilisateur, protégée par MFA, accessible depuis un réseau d’administration dédié et journalisée. Un équipement de bordure sans journal exploitable devient une boîte noire connectée à Internet. L’industrie en fabrique déjà suffisamment.

La quatrième attaque exploite les services hérités. Le protocole NTLM (NT LAN Manager) autorise des scénarios de relais et de capture qui restent dangereux lorsque les postes accèdent librement aux ressources internes. Désactiver les mécanismes en clair et anonymes, limiter les flux SMB (Server Message Block), imposer la signature quand elle est compatible et réduire les chemins d’authentification intégrée font partie du travail. Les détails de durcissement figurent dans l’analyse de NTLM et dans le guide sur LDAP sans bind anonyme ni clair.

Ce modèle ne garantit pas la sécurité d’une application vulnérable, la confidentialité des données téléchargées sur un terminal compromis, ni la légitimité d’une action effectuée avec une session volée. Il faut compléter par le durcissement applicatif, la classification des données, le contrôle des exports, la journalisation métier et la détection côté poste. L’identité n’annule pas le besoin de corriger une injection SQL. Même avec un très beau portail.

Exemple : réduire un tunnel VPN à des flux nommés

La migration ne commence pas par couper le VPN un vendredi soir, sport pratiqué par les amateurs de procédures post-mortem. Elle commence par observer les flux réellement nécessaires, puis par remplacer les routes globales par des règles explicites. L’exemple suivant illustre un pare-feu Linux avec nftables, pour un pool VPN limité à un relais d’administration et à un service HTTPS interne.

#!/usr/sbin/nft -f
# Exemple reproductible : filtrage des flux depuis 10.42.0.0/24, pool VPN.
# Les adresses sont documentaires et doivent être remplacées.

table inet filter {
  chain forward {
    type filter hook forward priority filter;
    policy drop;

    # Autoriser uniquement HTTPS vers le portail applicatif.
    ip saddr 10.42.0.0/24 ip daddr 10.20.10.15 tcp dport 443 accept

    # Autoriser SSH seulement vers le bastion, jamais vers tous les serveurs.
    ip saddr 10.42.0.0/24 ip daddr 10.20.20.10 tcp dport 22 accept

    # Laisser passer les réponses aux connexions autorisées.
    ct state established,related accept

    # Journaliser les refus pour vérifier les dépendances oubliées.
    ip saddr 10.42.0.0/24 log prefix "VPN_DENY " drop
  }
}

Cette règle ne remplace pas l’autorisation applicative. Elle empêche seulement le mouvement latéral réseau depuis le pool distant. Les journaux VPN_DENY doivent être corrélés avec l’identité de session, le terminal et la ressource visée. Sans cette corrélation, une alerte indique qu’une adresse a tenté un flux. C’est mieux que rien, ce qui est une barre assez basse.

Exploitation : certificats, révocation, supervision et reprise

Les secrets d’accès distant incluent les clés privées des passerelles, les certificats de service, les secrets des connecteurs, les clés de signature de jetons et les comptes de secours. Les stocker dans un coffre de secrets avec contrôle d’accès, audit et rotation est le minimum. Une clé privée de passerelle exportée dans un partage d’administration annule élégamment le reste de l’architecture.

Les certificats doivent avoir un propriétaire, une date de renouvellement connue et une procédure de remplacement testée. La révocation d’un certificat ne coupe pas automatiquement les sessions déjà établies : les durées de session, la fréquence de réévaluation de posture et les mécanismes de déconnexion forcée déterminent le délai réel. Il faut le mesurer, pas le supposer.

La supervision doit suivre au minimum : échecs MFA, créations de sessions, changements de posture, refus de politiques, élévations de privilèges, flux refusés, versions des passerelles et expiration des certificats. Conserver les événements d’identité sans les événements réseau, ou l’inverse, rend l’enquête incomplète. L’horodatage doit être synchronisé partout, faute de quoi l’incident devient une frise chronologique dessinée par un chat.

Le plan de reprise doit traiter la dépendance à l’identité. Si le fournisseur d’identité, l’autorité de certification ou le service de conformité des terminaux tombe, quels accès restent possibles, pour qui et pendant combien de temps ? Prévoir des comptes de secours protégés par des facteurs matériels, hors des flux d’administration ordinaires, et vérifier périodiquement leur usage contrôlé. Un compte de secours non testé n’est pas un secours, c’est un artefact archéologique.

🐝 Ce qui arrive si on s’en passe

Sans dépasser le VPN comme frontière, un tunnel chiffré rétablit un chemin vers le réseau interne sans rien dire de la santé du poste qui l’emprunte. Un terminal compromis obtient alors, via une clé qui ouvre la porte principale, un accès étendu à des ressources internes qui font confiance au réseau plutôt qu’à l’identité et à l’état de la machine. L’emplacement réseau redevient un laissez-passer : une fois dans le tunnel, l’attaquant se déplace vers des services qui n’auraient jamais dû être atteignables depuis un poste non vérifié. Le chiffrement du transport protège le trajet, pas la légitimité de ce qui circule. Sans contrôle granulaire décidant quelles ressources restent réellement accessibles et à quelles conditions, le VPN étend le périmètre au salon de chaque télétravailleur au lieu de le remplacer par une vraie vérification.

🦫 Explication de la marmotte 🍫

Avant le télétravail, beaucoup d’entreprises protégeaient surtout leur réseau interne. Une fois qu’un ordinateur était relié à ce réseau, les services lui accordaient souvent davantage de confiance. Le travail à distance change ce point : l’ordinateur se connecte depuis un lieu extérieur, avec une connexion Internet et parfois un niveau de protection différent.

Un réseau privé virtuel crée un trajet chiffré entre l’ordinateur et l’entreprise. Il empêche surtout la lecture du trafic pendant le transport. Après la connexion, il peut aussi donner accès à de nombreux serveurs internes. Si le compte ou l’ordinateur est compromis, l’attaquant peut alors utiliser ce même trajet.

Une architecture mieux conçue vérifie séparément la personne, l’état de l’ordinateur et le service demandé. Une personne doit prouver son identité avec plusieurs preuves. L’ordinateur doit respecter des règles, comme être mis à jour et chiffré. Ensuite, l’accès est donné à une application précise ou à un serveur précis, pas à tout le réseau.

Quand une vérification échoue, l’accès doit être refusé ou réduit. Quand un ordinateur devient suspect, ses sessions doivent pouvoir être coupées. Les accès, les refus et les changements doivent être enregistrés pour comprendre un incident. Les clés et certificats utilisés pour protéger ces connexions doivent aussi être renouvelés et sauvegardés, sinon une panne ou une fuite bloque tout le système.

Pages voisines

La citent

Pourquoi le VPN ne remplace pas le périmètre

Elle cite

Pourquoi le VPN ne remplace pas le périmètre

Pourquoi le VPN ne remplace pas le périmètre

Le VPN prolonge le réseau, il ne recrée pas le périmètre

Identité, appareil et application : remplacer la confiance de réseau

Surface d’attaque du télétravail et contre-mesures vérifiables

Exemple : réduire un tunnel VPN à des flux nommés

Exploitation : certificats, révocation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines