Un VPN d'entreprise n'est pas un abonnement — c'est une décision d'architecture réseau. Cette ressource documente les fondamentaux techniques : protocoles de tunnel, mécanismes d'authentification, gestion des certificats, segmentation, et conformité réglementaire. Sans biais commercial. Pour une évaluation comparative des solutions disponibles : meilleures solutions VPN d'entreprise.
Un VPN d'entreprise opère sur la couche transport. Il chiffre le trafic entre un endpoint et un concentrateur, masque l'adresse IP source et empêche l'interception passive sur les segments réseau intermédiaires. Ce périmètre est précis — et délibérément limité.
Le cycle de patching des équipements VPN doit être traité comme priorité critique. Délai recommandé : moins de 48 heures pour les CVE de score CVSS ≥ 9.0. Un tunnel AES-256 sur un daemon non patché est structurellement moins sécurisé qu'un tunnel AES-128 sur une infrastructure à jour.
Le choix de la topologie conditionne les performances, la résilience et la surface d'attaque. Trois modèles couvrent la quasi-totalité des besoins PME/entreprise.
Tous les clients VPN se connectent à un concentrateur central. Modèle le plus courant pour l'accès distant des collaborateurs. Le concentrateur assure l'authentification, la terminaison du tunnel et le routage vers les ressources internes. Goulot d'étranglement par conception — dimensionner le concentrateur pour le pic de connexions simultanées avec marge.
Tunnels directs entre chaque site sans concentrateur central. Latence optimale pour les communications inter-sites. Complexité de gestion qui croît en O(n²) avec le nombre de sites. WireGuard avec un plan de contrôle comme Headscale simplifie significativement l'administration d'un mesh.
En split tunnel, seul le trafic à destination des plages IP internes entre dans le tunnel. En full tunnel, l'intégralité du trafic transite par le concentrateur VPN. Le split tunnel améliore les performances et réduit la charge infrastructure — au prix d'une exposition du trafic exclu aux risques du réseau local de l'utilisateur.
En split tunnel, les requêtes DNS pour les domaines exclus du tunnel sont résolues localement — visibles par un observateur réseau. Si la confidentialité des requêtes DNS est un prérequis, forcer le DNS dans le tunnel ou déployer DoH/DoT sur le client pour le trafic exclu.
Le VPN traditionnel accorde un accès réseau après authentification initiale. ZTNA accorde un accès applicatif granulaire, évalué en continu sur l'identité, la posture du terminal et le contexte. ZTNA résout structurellement le problème du mouvement latéral — mais ses prérequis sont significatifs : IdP centralisé avec MFA, MDM avec évaluation de posture, inventaire applicatif complet.
Chaque protocole résout le problème du tunnel chiffré avec des compromis différents sur la sécurité, les performances, la surface de code et la compatibilité.
| Protocole | Statut | Chiffrement symétrique | Surface de code | Remarque critique |
|---|---|---|---|---|
| WireGuard | Recommandé | ChaCha20-Poly1305 |
~4 000 lignes | Modèle cryptographique fixe — pas de downgrade attack. Incompatible FIPS. |
| IPsec / IKEv2 | Recommandé ANSSI | AES-256-GCM |
Noyau OS | PFS à activer explicitement. Exclure groupes DH < 2048 bits (groupes 1, 2, 5). |
| OpenVPN | Acceptable | AES-256-GCM |
~400 000 lignes | Espace utilisateur — overhead CPU. TCP/443 utile pour traversée firewall. |
| L2TP / IPsec | Legacy | AES-256 |
Variable | Double encapsulation inutile. Préférer IKEv2 seul. |
| PPTP | Déprécié | MPPE/RC4 |
— | MS-CHAPv2 cassable. Ne déployer en aucun cas. |
Échange de clés : ECDH sur P-256 ou P-384 (NIST). Groupes MODP 1024 bits cassables — exclure explicitement (groupes IKE 1, 2, 5). Perfect Forward Secrecy : garantit que la compromission d'une clé à long terme ne compromet pas les sessions passées. À activer via pfs=yes (StrongSwan). Post-quantique : ML-KEM (FIPS 203) finalisé par le NIST en 2024 — pertinent pour déploiements à horizon 5+ ans.
L'authentification est le maillon le plus souvent attaqué dans un déploiement VPN. Les credentials VPN apparaissent dans les logs de stealers, dans les bases de credential stuffing, et sont ciblés par des campagnes de phishing spécialisées.
CA racine hors ligne : clé privée sur support déconnecté. CA intermédiaires en ligne : émission quotidienne, durées de validité courtes (1 an max), renouvellement automatisé. Révocations : CRL ou OCSP — tester régulièrement que le mécanisme est opérationnel. Un certificat d'un terminal compromis reste valide jusqu'à expiration si la révocation n'est pas fonctionnelle.
La révocation de certificats est systématiquement sous-testée. Révoquer un certificat de test et vérifier qu'une connexion est effectivement rejetée doit faire partie des procédures de recette et de maintenance périodique.
Un déploiement autohébergé (StrongSwan pour IPsec/IKEv2, Headscale pour WireGuard mesh, OpenVPN Access Server) donne un contrôle total. La contrepartie est opérationnelle : veille CVE, patching sous 48h pour les vulnérabilités critiques, renouvellement des certificats, monitoring de disponibilité.
Un service managé délègue l'infrastructure. À vérifier contractuellement : qui détient les clés de chiffrement des tunnels, les logs sont-ils exportables vers votre SIEM, et sous quelle juridiction opère le fournisseur (implications CLOUD Act pour les fournisseurs US).
Redondance active-active avec load balancing ou active-passive avec failover automatique. WireGuard gère le roaming client nativement. IPsec nécessite MOBIKE (RFC 4555) configuré explicitement. Tester le basculement en conditions réelles avant mise en production.
Logs minimaux : authentification (identifiant, timestamp, IP source, succès/échec), session (durée, volume, disconnect reason), erreurs SA. Intégration SIEM pour corrélation et détection d'anomalies — connexion depuis IP inhabituelle, horaires atypiques, volume de données anormal.
Les logs d'accès nominatifs sont des données personnelles au sens du RGPD. Durée de rétention à définir proportionnellement à la finalité. À documenter dans le registre des activités de traitement (article 30).
IKEv2 expose un plan de contrôle UDP/500 et UDP/4500. Les suites cryptographiques faibles acceptées en négociation permettent des attaques par downgrade. Configuration défensive — allow-list explicite, exemple StrongSwan : ike=aes256gcm16-sha384-ecp384! — le ! final refuse toute suite non listée.
Sur un réseau local hostile, un attaquant peut empoisonner la table de routage pour intercepter le trafic censé sortir directement. Les implémentations client qui ne verrouillent pas les règles de routage sont vulnérables. Passer en full tunnel sur les réseaux non maîtrisés.
Les endpoints IKEv2 (UDP/500) et OpenVPN (UDP/1194 ou TCP/443) sont continuellement sondés. Sans MFA, la compromission d'un couple identifiant/mot de passe issu d'une fuite tierce suffit à ouvrir un accès réseau. Mesures : MFA obligatoire, rate limiting, fail2ban, rotation via Have I Been Pwned API.
Entre le démarrage du système et l'établissement du tunnel VPN, le trafic sort non protégé — y compris les requêtes DNS initiales. Sur un réseau hostile, cette fenêtre est exploitable. Kill switch avec démarrage automatique du tunnel (always-on) élimine cette exposition.
Un fournisseur VPN managé est un sous-traitant au sens de l'article 28. DPA obligatoire. Un fournisseur américain est soumis au CLOUD Act (2018) — les CCT 2021 ne neutralisent pas une injonction. Transfer Impact Assessment (TIA) requis depuis Schrems II (CJUE, 2020).
En vigueur depuis octobre 2024. Sur les accès distants : politiques formalisées d'accès, MFA pour les systèmes critiques, inventaire des terminaux. Délais de notification : 24h rapport initial, 72h intermédiaire, 1 mois rapport final à l'ANSSI.
A.8.20 (Sécurité des réseaux), A.8.21 (Sécurité des services réseau), A.8.24 (Politique cryptographique). Documenter les suites cryptographiques, durées de validité des certificats, procédures de révocation dans le Statement of Applicability.
| Référentiel | Périmètre | Exigence clé |
|---|---|---|
| RGPD Art. 28 | Sous-traitant VPN | DPA obligatoire, TIA si fournisseur hors UE |
| NIS2 | Entités essentielles / importantes | MFA obligatoire, notification 24h |
| ISO 27001:2022 | Certification volontaire | A.8.20, A.8.21, A.8.24 |
| SOC 2 Type II | Prestataires de services | CC6 — contrôles d'accès logique, MFA |