Autohébergé vs service managé : ce que le choix implique réellement
Un VPN d'entreprise peut reposer sur une infrastructure entièrement sous contrôle de l'organisation, ou sur un service managé par un tiers. Ce choix détermine la répartition des responsabilités opérationnelles, juridiques et de conformité.
Autohébergé : outils et charge réelle
Les principales solutions autohébergées en production en 2026 :
StrongSwan — implémentation IPsec/IKEv2 open source, mature, disponible sur toutes les distributions Linux. Documentation technique solide. Configuration via swanctl.conf (format moderne, VICI API) ou l'ancien ipsec.conf. Référence pour les déploiements on-premise IPsec.
WireGuard + Headscale — Headscale est une implémentation open source du plan de contrôle de Tailscale, autohébergeable. Il gère la distribution des clés publiques, le DNS, les ACL et les routes pour un réseau WireGuard. Pertinent pour les organisations qui veulent le modèle mesh de WireGuard sans dépendre d'un service tiers.
OpenVPN Access Server — version commerciale d'OpenVPN avec interface d'administration web, gestion des utilisateurs et authentification LDAP/RADIUS intégrée. Licence par nombre de connexions simultanées.
La charge opérationnelle réelle d'un déploiement autohébergé inclut : gestion des mises à jour du daemon VPN (critique — voir les CVE récentes), renouvellement des certificats, monitoring des tunnels, sauvegarde des clés privées, et escalade en cas d'incident en dehors des heures ouvrées.
Service managé : ce qu'on délègue et ce qu'on doit vérifier
Un fournisseur de VPN d'entreprise managé prend en charge l'infrastructure, les mises à jour et souvent le provisionnement des clients. Avant de déléguer, vérifier précisément : qui détient les clés de chiffrement des tunnels — si c'est le fournisseur, il peut techniquement déchiffrer votre trafic. Les logs d'accès sont-ils accessibles à votre organisation — pour votre propre SIEM ou en cas d'incident. Sous quelle juridiction opère le fournisseur — voir la page sur la conformité pour les implications CLOUD Act et Schrems II.
PKI et gestion des certificats
Pour un VPN avec authentification par certificat (recommandée sur le mot de passe seul), une PKI interne est nécessaire. Son architecture conditionne la sécurité de l'ensemble du déploiement.
Architecture recommandée
Une CA racine hors ligne, stockée sur un support chiffré déconnecté du réseau. Des CA intermédiaires pour l'émission quotidienne — elles sont en ligne mais leur compromission n'invalide pas la CA racine si la structure est correcte. Des durées de validité courtes : 1 an pour les certificats terminaux (contre 3-5 ans dans les configurations héritées), avec renouvellement automatisé via ACME ou scripts internes. Des profils de certificats distincts pour les terminaux, les serveurs VPN et les administrateurs.
La gestion des révocations (CRL — Certificate Revocation List, ou OCSP) est systématiquement sous-configurée dans les déploiements VPN de taille moyenne. Si le mécanisme de révocation n'est pas opérationnel et testé régulièrement, un certificat d'un terminal compromis ou d'un collaborateur parti reste valide jusqu'à son expiration naturelle. Tester la révocation signifie révoquer un certificat de test et vérifier qu'une connexion avec ce certificat est effectivement rejetée.
Authentification : MFA, SSO, et intégration IdP
L'authentification par identifiant/mot de passe seul est insuffisante. Les credentials VPN sont une cible de premier choix pour les attaquants — ils apparaissent dans les logs de stealers, dans les bases de credential stuffing, et dans les phishing ciblés. Le MFA est la mesure technique qui réduit le plus drastiquement ce vecteur.
Méthodes MFA adaptées au VPN
TOTP (Time-based One-Time Password, RFC 6238) — généré par une application d'authentification (Aegis, Google Authenticator, Authy). Compatible avec IKEv2 via EAP-TTLS ou RADIUS. Simple à déployer, bien supporté par les clients VPN modernes.
Certificat sur token matériel (YubiKey, FIDO2) — la clé privée ne quitte jamais le token. Résistant au phishing et au vol de credentials. Coût matériel par utilisateur (~40-80€/token), mais niveau de sécurité supérieur. Recommandé pour les accès administrateurs et les données sensibles.
Push MFA via IdP (Okta Verify, Microsoft Authenticator) — intégration SAML/OIDC entre le client VPN et l'IdP. L'utilisateur reçoit une notification push à valider. Dépend de la disponibilité du service IdP tiers.
Le SMS comme second facteur est à éviter. SIM swapping — transfert frauduleux de numéro de téléphone — est documenté comme vecteur d'attaque sur des cibles à haute valeur. L'interception SS7 des SMS est techniquement accessible à des acteurs étatiques. Ces risques ne sont pas théoriques pour une organisation avec des données sensibles.
Intégration IdP centralisé
L'intégration du VPN avec un fournisseur d'identité centralisé (Active Directory / RADIUS, ou IdP cloud via SAML/OIDC) centralise la gestion des accès. Un collaborateur qui quitte l'organisation est désactivé dans l'IdP — son accès VPN est révoqué sans action séparée sur chaque système. C'est un prérequis raisonnable dès 20 utilisateurs, et un impératif au-delà de 50.
Protocoles d'intégration : RADIUS (Remote Authentication Dial-In User Service) pour les déploiements IKEv2/StrongSwan legacy. LDAP/Active Directory directement, pour les environnements Windows. SAML 2.0 ou OIDC pour les IdP cloud modernes (Okta, Entra ID, Google Workspace).
Split tunneling : décisions de routage
Le split tunneling détermine quels flux transitent par le tunnel VPN et lesquels sortent directement. C'est l'un des paramètres de déploiement les plus impactants sur la sécurité réelle — et l'un des moins documentés par les fournisseurs.
- Full tunnel : tout le trafic transite par le VPN, y compris les services cloud. Protection maximale des métadonnées réseau. Charge sur l'infrastructure proportionnelle au trafic total — peut nécessiter une infrastructure significative pour 200+ utilisateurs simultanés avec du trafic vidéo (Teams, Zoom).
- Split tunnel par destination : seul le trafic à destination des plages IP internes définies passe par le tunnel. Les services cloud sortent directement. Configuration la plus courante. Nécessite la maintenance des plages IP internes dans la configuration.
- Split tunnel inversé : tout transite par le tunnel sauf une liste d'exclusions explicites. Plus sécurisé que le split classique en termes de surface exposée, mais nécessite une maintenance active des exclusions à mesure que de nouveaux services sont adoptés.
- Split DNS : les requêtes DNS pour les domaines internes sont résolues par les serveurs DNS internes via le tunnel ; les domaines publics sont résolus localement. Réduit la charge sur l'infrastructure DNS interne tout en maintenant la résolution correcte des noms internes.
En configuration split tunnel standard, les requêtes DNS pour les domaines exclus du tunnel sont résolues par les serveurs DNS locaux du terminal — visibles par un observateur réseau. Si un collaborateur accède à des services sensibles depuis un réseau non maîtrisé, les domaines consultés peuvent être inférés même si le contenu des requêtes est chiffré. Solution : forcer toutes les requêtes DNS dans le tunnel (DNS over VPN), ou utiliser DoH/DoT avec un resolver de confiance pour le trafic exclu.
Haute disponibilité et résilience
Pour une organisation dont le télétravail est opérationnellement critique, un single point of failure sur le concentrateur VPN est inacceptable. Les options de haute disponibilité :
Actif-passif (failover) — deux instances, l'une active, l'autre en veille. Le basculement est automatique sur panne de l'instance principale. Temps de reprise entre 30 secondes et quelques minutes selon l'implémentation. Convient aux organisations avec une tolérance aux interruptions brèves.
Actif-actif (load balancing) — plusieurs instances répartissent les connexions. Pas de coupure en cas de panne d'une instance. Nécessite de gérer l'état des sessions (sessions stickiness ou synchronisation d'état entre instances). Plus complexe à opérer.
Répartition géographique — points de sortie VPN dans plusieurs régions ou datacenters. Réduit la latence pour les utilisateurs distants et la dépendance à un site unique. Chaque point de sortie est un asset à maintenir (certificats, mises à jour, monitoring).
Note sur WireGuard et le roaming : WireGuard gère nativement le changement d'adresse IP du client sans renégociation du tunnel, grâce à sa conception stateless. IPsec avec MOBIKE offre une capacité comparable mais doit être explicitement configuré. OpenVPN nécessite une reconnexion complète sur changement d'IP.
Monitoring, logs d'accès et intégration SIEM
Un déploiement VPN en production doit produire des logs exploitables pour la détection d'anomalies et la conformité réglementaire. Les catégories de logs minimales :
Logs d'authentification : identifiant utilisateur, timestamp, IP source, succès/échec, méthode d'authentification. Logs de session : timestamp de connexion/déconnexion, durée, volume transféré, IP source. Logs d'erreur : échecs de négociation SA, erreurs de certificat, rejets de connexion.
L'intégration avec un SIEM (Splunk, Elastic Security, Microsoft Sentinel, Wazuh pour les open source) permet la corrélation avec d'autres événements de sécurité — un utilisateur VPN qui se connecte depuis une IP inhabituelle à 3h du matin peut déclencher une alerte, là où le log VPN seul passerait inaperçu.
La politique de rétention des logs doit être définie en amont : le RGPD impose une proportionnalité entre durée de conservation et finalité. Les logs d'accès nominatifs d'un VPN (qui se connecte, quand, depuis où) sont des données personnelles — ils doivent figurer dans le registre des traitements de l'organisation. La page sur la conformité couvre les exigences NIS2 et RGPD sur la traçabilité des accès.