Dans les architectures VPN traditionnelles, le tunnel est le plus souvent géré séparément de la politique d'identité. D'un côté l'annuaire d'entreprise, de l'autre le système d'authentification VPN, plus un service MFA, un autre outil pour la confiance des appareils et une ligne de logs distincte pour l'audit. Cette structure fragmentée rend l'accès distant plus fragile opérationnellement que réellement sécurisé.
Que l'utilisateur connaisse le bon mot de passe ne suffit pas à lui seul. L'appareil est-il géré, le chiffrement de disque est-il actif, le logiciel de sécurité est-il à jour, l'utilisateur est-il dans le bon groupe, l'IP source ou la plage horaire présentent-elles un risque ? Si ces questions ne reçoivent pas de réponse avant l'ouverture du tunnel, le VPN devient une porte incontrôlée qui étend le réseau d'entreprise.
Le split tunneling, le tunnel complet et l'accès par segment ne sont pas non plus de simples questions de route réseau. Un utilisateur de la finance et un prestataire ne doivent pas accéder au même réseau ; un appareil d'entreprise géré et un appareil personnel ne doivent pas avoir les mêmes droits. Lorsque la politique de tunnel n'est pas conçue avec l'identité, le groupe et la confiance d'appareil, la portée d'accès reste plus large que nécessaire.
Côté exploitation, le problème s'aggrave aussi. Si SSL VPN, IKEv2, MFA, politique de groupe, enregistrement de session et transfert vers le SIEM sont gérés séparément, l'équipe sécurité ne peut pas voir le tableau complet au moment d'un incident. Qui s'est connecté, avec quel appareil, à quels segments il a accédé et pourquoi la connexion a été coupée doivent apparaître dans une seule piste d'audit.
L'approche de TR7 AAM traite l'accès VPN non pas comme un service réseau distinct, mais comme une couche d'accès distant contrôlée où convergent les décisions d'identité, de MFA, de posture d'appareil, d'accès conditionnel et d'audit.
TR7 AAM évalue l'accès distant avec client comme une décision d'identité, de confiance des appareils et de portée d'accès — avant le choix du protocole.
L'utilisateur peut être authentifié via LDAP/AD, RADIUS, OIDC, SAML ou une source d'utilisateurs locale. La même décision d'identité constitue une base de politique commune pour les options d'accès avec client telles que SSL VPN ou IKEv2.
Le score de confiance de l'appareil est pris en compte dans la décision d'accès conditionnel. Un modèle peut être appliqué : accès large aux appareils gérés, accès restreint aux appareils personnels, refus d'accès aux appareils non sécurisés.
L'approche SSL VPN basée sur TLS fonctionne via le port 443, ce qui facilite le passage dans les environnements de pare-feu et de proxy d'entreprise. La décision de split tunneling ou de tunnel complet peut être rattachée au modèle de politique.
IKEv2/IPsec offre un modèle d'accès distant compatible avec les clients VPN natifs des systèmes d'exploitation tels que Windows, macOS, iOS et Android. Pour la continuité du tunnel lors des changements de réseau mobile, l'approche IKEv2 offre un avantage pratique.
TR7 SSL VPN et IKEv2 placent au centre, plus que le protocole de tunnel, la décision d'identité, de MFA, de posture et de portée d'accès d'AAM.
Le SSL VPN se positionne pour l'accès aux ressources d'entreprise depuis des réseaux restreints grâce à une approche de tunnel basée sur HTTPS/TLS. L'usage du port 443 facilite l'accès dans de nombreux environnements d'entreprise, d'hôtel, d'aéroport ou de réseau externe. Ce modèle est particulièrement précieux lorsque les clients supplémentaires ou les ports UDP dédiés sont restreints.
IKEv2/IPsec convient à un modèle d'accès distant d'entreprise compatible avec les clients VPN natifs des systèmes d'exploitation. Il peut réduire la complexité supplémentaire d'expérience utilisateur sur des plateformes telles que Windows, macOS, iOS et Android. Dans les scénarios où les utilisateurs mobiles changent de réseau, l'architecture IKEv2 est avantageuse pour la reconnexion.
La connexion VPN peut être évaluée conjointement avec la politique d'accès conditionnel d'AAM. L'identité de l'utilisateur, l'appartenance aux groupes, l'IP source, la fenêtre horaire, la confiance d'appareil et les signaux de risque sont intégrés au processus de décision avant l'ouverture du tunnel. Cette approche fait sortir le VPN de son statut de porte ouverte au niveau réseau. La décision d'accès est restreinte au contexte de l'utilisateur et de l'appareil.
L'approche MFA de TR7 AAM peut être utilisée comme facteur de confiance commun appliqué également à la décision d'accès VPN. Des méthodes comme TOTP, SMS OTP ou e-mail OTP renforcent la vérification de l'utilisateur. Avec un modèle d'appareil de confiance ou de vérification basée sur le risque, l'expérience utilisateur et la sécurité peuvent être équilibrées. Ainsi, le besoin d'exploiter une infrastructure MFA distincte pour le VPN est réduit.
AAM dispose d'un modèle de fournisseur d'identité capable de fonctionner avec LDAP/AD, RADIUS, OIDC, SAML et des sources d'utilisateurs locales. L'accès VPN n'est pas traité comme une base d'utilisateurs distincte ou un îlot d'identité séparé. Quelle que soit l'identité sous laquelle l'utilisateur est déjà géré dans l'organisation, la décision d'ouverture du tunnel est rattachée au même contexte d'identité. Cette structure simplifie la gestion du cycle de vie des utilisateurs.
Les segments réseau auxquels un utilisateur peut accéder peuvent être associés à l'appartenance à un groupe ou à la politique utilisateur AAM. L'équipe finance peut être dirigée uniquement vers les systèmes financiers, le prestataire uniquement vers les services projet, l'équipe DevOps uniquement vers l'environnement de développement. Ce modèle réduit l'erreur consistant à accorder l'accès à tout le réseau une fois le VPN ouvert. L'accès au tunnel devient un contrôle de segment basé sur l'identité.
Les signaux de posture d'appareil ETM peuvent servir à distinguer les appareils gérés des appareils non gérés dans l'accès au tunnel. Le chiffrement de disque, le logiciel de sécurité, l'état des correctifs ou les signaux de gestion d'entreprise peuvent influencer le niveau d'accès. Un appareil de confiance peut être dirigé vers le réseau complet, un appareil à faible confiance uniquement vers des backends limités. Cette approche rend visible le risque lié aux appareils dans l'accès distant.
Les sessions VPN peuvent être rattachées à la piste d'audit avec des champs tels que l'identité de l'utilisateur, l'IP source, l'heure de session, la durée de connexion et le résultat de la politique. Ces journaux peuvent être transférés vers le flux SIEM pour être corrélés aux événements de sécurité. L'équipe d'exploitation peut voir non seulement que la connexion a été établie, mais aussi avec quelles décisions de confiance elle l'a été. Cette visibilité est essentielle pour la conformité et l'investigation d'incidents.
Le split tunneling permet de ne faire passer par le tunnel que les plages IP de l'organisation ou des services spécifiques. Le tunnel complet transporte tout le trafic client vers le point de passage d'entreprise. Le modèle à appliquer peut être déterminé selon le groupe d'utilisateurs, la confiance d'appareil, la localisation ou le niveau de risque.
Si la posture de l'appareil se dégrade pendant la connexion, si le score de risque change ou si la politique utilisateur est violée, la session doit être interrompue ou une nouvelle authentification demandée. L'architecture TR7 AAM associe cette décision au modèle d'accès conditionnel et d'audit. Cette approche fait sortir l'accès VPN de son statut de canal permanent oublié une fois ouvert. L'accès doit rester observable et révocable pendant toute la durée de la session.
Dans l'architecture SSL VPN et IKEv2, les capacités d'identité AAM éprouvées doivent être considérées conjointement avec les exigences d'exploitation du tunnel.
Les fournisseurs d'identité, le MFA, l'accès conditionnel et le concept de posture d'appareil ETM constituent la base fiable de cette page. Le message principal de la page est le rattachement du VPN à ce moteur d'accès. Le protocole de tunnel se positionne comme le canal par lequel la décision d'identité et de politique est appliquée.
L'approche SSL VPN se positionne sur TLS 1.2+ et le port 443. Cela offre un avantage pour l'accès depuis des réseaux restreints. La facilité de passage dans les environnements de pare-feu et de proxy d'entreprise est l'avantage pratique qui le distingue par rapport à IKEv2.
Dans le modèle IKEv2/IPsec, les ports UDP 500 (IKE) et UDP 4500 (NAT-T), le comportement NAT-T et les autorisations de pare-feu deviennent critiques. Par rapport au SSL VPN, la probabilité de blocage dans certains réseaux restreints est plus élevée. C'est pourquoi SSL VPN et IKEv2 sont des options complémentaires pour différentes conditions d'accès.
Dans une architecture VPN, le pool d'IP de tunnel à attribuer à chaque session doit être planifié. En cas d'épuisement du pool, les nouvelles connexions peuvent être refusées ou mises en attente. La taille du pool et le modèle de gestion doivent être configurés selon les exigences de déploiement.
Dans l'accès VPN, il peut être nécessaire que les domaines de l'organisation passent par le DNS interne et les autres domaines par la résolution externe. Le split DNS est le complément naturel de la conception du split tunneling. Ce comportement dépend de l'architecture de déploiement et de la configuration de la politique.
Les protocoles de tunnel génèrent un coût d'en-tête supplémentaire. Le réglage MTU/MSS est important, en particulier pour les performances des tunnels IPsec ESP et TLS. De mauvais réglages peuvent produire de la fragmentation, un faible débit ou des problèmes de connexion sur certaines applications.
Lorsque la gateway AAM fonctionne en paire, le comportement de failover des sessions VPN dépend de la technologie de tunnel. Du côté IKEv2, l'architecture de reconnexion mobile peut être avantageuse ; du côté SSL VPN, la conception de la VIP et de la continuité de session doit être traitée séparément.
L'utilisateur travaillant depuis son domicile ou en déplacement est authentifié via AAM avec son identité d'entreprise et le MFA. Si la confiance d'appareil ETM est suffisante, l'accès aux services intranet est accordé via SSL VPN ; sur les appareils personnels, l'accès est limité à des segments plus étroits.
Le technicien sur le terrain peut se connecter au réseau d'entreprise avec le client IKEv2 natif de son appareil mobile. Si l'appareil possède un profil géré et un score de confiance ETM élevé, un accès plus large est accordé ; lors des changements de réseau, l'approche IKEv2 est plus adaptée à l'usage mobile.
Un compte utilisateur valable uniquement pendant la durée du projet et un groupe restreint sont attribués au prestataire tiers. L'accès VPN n'est ouvert qu'au segment où se trouvent les backends du projet, et toutes les sessions sont rattachées à la piste d'audit.
L'ingénieur d'automatisation industrielle reçoit une politique VPN configurée pour n'accéder qu'au segment OT. L'accès conditionnel restreint la décision selon les heures ouvrées, le groupe d'utilisateurs, l'IP source et la confiance d'appareil ; aucun accès large au réseau d'entreprise général n'est accordé.
Découvrez l'architecture qui réunit le tunnel SSL VPN et IKEv2 avec le moteur d'identité AAM, le MFA et la posture d'appareil ETM. Nous vous guidons dans une installation en direct sur votre propre environnement.