MDM d’entreprise et VPN : Intune, Kaspersky, MDM nationales et Always-on

1. Introduction : pourquoi ce sujet est crucial et ce que vous apprendrez

Ces dernières années, la mobilité en entreprise est devenue essentielle : vos collaborateurs travaillent depuis les bureaux, la maison, les espaces de coworking, les aéroports et sur réseaux mobiles partout dans le monde. L’accès aux applications internes doit être fluide, sécurisé et transparent. Always-on VPN est la clé qui assure une connexion permanente et protégée entre les appareils et le réseau d’entreprise, quel que soit le lieu ou le moment. Dans cet article, nous allons décortiquer comment concevoir et déployer Always-on VPN sur Windows 10/11, Android Enterprise et iOS/iPadOS en utilisant Microsoft Intune, Kaspersky Endpoint (via Kaspersky Security Center) et MDM/UEM nationales (avec des scénarios pour OS corporate et solutions certifiées FSTEC/FSB). Nous couvrirons tout, des bases aux architectures avancées, avec des instructions claires, des checklists, des cadres de déploiement et des cas réels. Le but : que vous puissiez consulter cet article à n’importe quelle étape de votre projet pour obtenir des réponses précises – quoi faire, comment le faire et pourquoi c’est la bonne méthode.

2. Bases : concepts fondamentaux

2.1. Qu’est-ce que Always-on VPN

Always-on VPN est un mode où le tunnel sécurisé s’active automatiquement à chaque activité réseau de l’appareil ou selon des politiques définies (déclencheurs), sans intervention manuelle de l’utilisateur. Sur desktop (Windows), on distingue le device tunnel (établi dès la connexion au système, au nom de la machine) et le user tunnel (après authentification utilisateur). Sur mobiles (Android, iOS/iPadOS), ce sont les modes always-on et per-app VPN avec la possibilité d’on-demand selon domaines/applications.

2.2. Composants

• MDM/UEM : système de gestion centralisée des appareils (Intune, politiques mobiles de Kaspersky Security Center, MDM nationales pour Android Enterprise, iOS/iPadOS et OS spécialisés).
• Passerelle VPN : concentrateur IPsec/IKEv2, SSL VPN, WireGuard, L2TP, SSTP, etc. Ou passerelles virtuelles dans le cloud.
• PKI/Certificats : EAP-TLS, certificats machine/utilisateur, SCEP/PKCS pour délivrance massive.
• DNS/DHCP/routage : conception du split/full tunneling, routes, NRPT (Windows), exclusions/inclusions.
• Identités et politiques d’accès : Entra ID (Azure AD) et Conditional Access, AD local, MFA, vérifications de posture.

2.3. Types de topologies

• Full-tunnel : tout le trafic passe par le VPN. Contrôle maximal, mais demande plus de ressources et de bande passante aux concentrateurs.
• Split-tunnel : sous-réseaux d’entreprise et FQDN passent par VPN, le reste d’internet est direct. Équilibre entre sécurité et performances, nécessite un routage et des règles DNS précis.
• Per-app VPN : seul le trafic des applications d’entreprise déclenche le tunnel. Modèle optimal pour le Zero Trust et réduire la surface d’attaque.

2.4. Pourquoi Always-on est aujourd’hui indispensable

• Le périmètre s’étend partout et nulle part à la fois. Les périmètres traditionnels ne suffisent plus.
• Hausse des attaques sur les réseaux Wi-Fi publics, MITM, et tactiques de phishing.
• Les normes de conformité exigent des tunnels protégés et un accès contrôlé hors du réseau d’entreprise.
• Intégration avec les architectures SASE/Zero Trust – le VPN devient la base ou un composant d’un stack plus large.

3. Approfondissement : aspects avancés

3.1. Device vs User tunnel sous Windows

Device tunnel sert à un accès précoce : authentification de domaine, GPO, scripts d’ouverture de session, gestion avant login. Il utilise un certificat machine. Le User tunnel est pour l’accès aux applications utilisateur, utilisant un certificat utilisateur et les intégrations Entra ID/SSO.

3.2. Protocoles et leurs spécificités

• IKEv2/IPsec : moderne, résiste aux changements de réseau (MOBIKE), parfait pour Always-on, support natif Windows, iOS, partie d’Android.
• SSL VPN/SSTP : sur TLS, traverse la plupart des proxys/firewalls, mais peut être plus gourmand en ressources.
• WireGuard : haute performance, gestion simple des clés, très adapté au mobile, mais pas d’intégration Always-on native sous Windows via MDM, nécessite client et politiques dédiées.
• L2TP/IPsec : obsolète, maintenu pour rétrocompatibilité, à utiliser prudemment dans les projets récents.

3.3. PKI et délivrance automatique de certificats

Pour une échelle industrielle, utilisez SCEP via Intune Certificate Connector ou ses équivalents chez Kaspersky/MDM nationales. Pour plus de robustesse, prévoyez une infrastructure CA dédiée, CRL/OCSP accessibles de l’extérieur via DMZ, templates séparés pour machine/utilisateur, certificats à courte durée de vie, rotation automatique.

3.4. DNS et NRPT

Windows exploite NRPT – règles DNS par domaine. En split-tunnel, configurez les domaines internes et leurs serveurs DNS via le profil VPN. Sur iOS/Android, misez sur DNS per-app et routage FQDN quand disponible.

3.5. Performances et stabilité

• MTU/MSS : surveillez la fragmentation. Pour IPsec sur UDP, réduisez typiquement le MTU de 40-60 octets par rapport au lien. Pour SSL, mesurez le PMTU et ajustez le MSS clamping sur la passerelle.
• DPD/Keepalive : équilibre entre la persistance du tunnel et la consommation batterie sur mobile.
• QoS/DSCP : pour la voix/vidéo via le tunnel.
• HA/Scale-out : clusters actif-actif, BGP pour routage dynamique, GSLB/Anycast IP pour scénarios globaux.

4. Pratique : Always-on VPN pour Windows 10/11 via Microsoft Intune

4.1. Architecture

• MDM : Microsoft Intune.
• Identités : Entra ID, hybrides ou cloud, Conditional Access.
• PKI : Intune Certificate Connector, SCEP device et user.
• Passerelle VPN : IKEv2/SSTP sur appliance dédiée ou Windows Server RRAS (pour POC). En production, privilégiez des passerelles hardware/virtuelles de classe entreprise.

4.2. Étapes

1. Préparez la PKI : déployez NDES/SCEP, publiez CRL/OCSP, créez les templates DeviceAuth et UserAuth (Client Authentication, IPsec IKEv2).
2. Configurez Intune Certificate Connector sur un serveur avec accès CA.
3. Créez les profils certificats dans Intune : SCEP Device et SCEP User. Assignez aux groupes d’appareils/utilisateurs.
4. Définissez le modèle de tunnels : Device tunnel (routes minimales vers AD/DC, KMS, gestion) + User tunnel (accès complet aux sous-réseaux d’entreprise).
5. Créez le profil VPN (Windows 10/11) dans Intune : Type IKEv2, authentification EAP-TLS, FQDN de la passerelle, CA racine/intermédiaires, profil NRPT, split/full tunneling, liste de routes.
6. Activez Always-on : dans les paramètres du profil, cochez connexion auto et déclencheurs (toutes les réseaux, SSID de confiance/pas de confiance – au choix).
7. Ajoutez OMA-URI custom pour Device tunnel si besoin : ./Device/Vendor/MSFT/VPNv2/DeviceVPN/ProfileXML avec valeurs EAP-TLS et paramètres de routage. Séparez UserVPN.
8. Vérifiez la conformité : politique Intune, chiffrement disque obligatoire, version minimale OS, blocage jailbrake/root.
9. Pilote et montée en charge : d’abord 10-20 appareils, puis extension par vagues.

4.3. Conseils pratiques

• Séparez les routes : DeviceVPN pour services essentiels (AD, PKI, gestion), UserVPN pour applications métier.
• Excluez Microsoft 365 en split-tunnel : utilisez les listes officielles FQDN/plages pour optimiser les performances.
• Vérifiez les journaux : logs Windows – RasClient, DeviceManagement-Enterprise-Diagnostics-Provider; collecte via Intune.
• Fallback : en cas de blocage IKEv2, proposez SSTP comme plan de secours.

4.4. Mini-checklist Windows Intune Always-on

• CA/NDES disponibles, CRL/OCSP ouverts
• EAP-TLS testé (device et user)
• NRPT et routes validés
• Profils Device et User bien dissociés
• Split-tunneling validé avec équipe réseau
• HA de la passerelle testé en failover

5. Pratique : Android Enterprise Always-on via Intune et MDM nationales

5.1. Architecture

• Modes Android : Work Profile (BYOD), Fully Managed (COPE/COBO), Dedicated.
• Client VPN : système (IKEv2/IPsec) ou client fournisseur. Pour WireGuard/SSL, apps clients et Managed Config.
• MDM : Intune ou EMM/MDM national supportant Android Enterprise API, politiques always-on et verrouillage VPN.

5.2. Étapes dans Intune

1. Enregistrez Android Enterprise dans Intune, définissez le profil de gestion (Fully Managed recommandé pour appareils corporate).
2. Déployez le client VPN via Managed Google Play et assignez aux groupes.
3. Créez la configuration VPN : type (IKEv2/IPsec, SSL ou via App Config), paramètres passerelle, certificats (SCEP User/Device), algorithmes, DPD.
4. Activez Always-on et si besoin Block connections without VPN (verrouillage).
5. Configurez le Per-app VPN : assignez aux applications du profil de travail.
6. Pilote et contrôle : suivi via Intune, diagnostics sur appareil (statut VPN, logs client).

5.3. Étapes avec MDM nationales

• Import du client VPN : distribuez l’APK via magasin corporate ou catalogue intégré.
• Configuration managée : renseignez les paramètres JSON du client (serveurs, clés, certificats), liez aux groupes appareils.
• Politique Always-on/lockdown : activez le flag plateforme de blocage hors VPN.
• Conformité : détection root, blocage sources non fiables, contrôle version OS et agent.

5.4. Conseils pratiques

• Batterie : allongez les intervalles keepalive où possible sans dégrader le SLA.
• Changements de réseau : IKEv2 avec MOBIKE et WireGuard gèrent mieux les bascules Wi-Fi/LTE.
• DNS : privilégiez DNS corporate et split par FQDN si supporté par le client.

5.5. Mini-checklist Android

• Mode de gestion choisi (préférence Fully Managed)
• Client VPN certifié et testé
• Always-on et lockdown activés si besoin
• Per-app lié aux apps d’entreprise
• Certificats délivrés et renouvelés automatiquement

6. Pratique : iOS/iPadOS — per-app et on-demand VPN

6.1. Architecture

iOS/iPadOS offre une stack mature : profils IKEv2, Per-app VPN, On-Demand par domaines et réseaux, blocage du trafic hors VPN. Via Intune ou MDM nationales, on crée des profils assignés aux apps.

6.2. Étapes

1. Certification : SCEP/PKCS pour certificats utilisateur EAP-TLS.
2. Création profil IKEv2 : serveur, identifiants, authentification, renégociations, DPD, algorithmes.
3. Per-app VPN : liste des bundle ID des apps devant utiliser le VPN.
4. Règles On-Demand : par noms de domaine, interfaces (Wi-Fi, cellulaire), déclencheurs SSID (exemple : tout Wi-Fi inconnu passe par VPN).
5. Conformité : interdiction jailbreak, versions minimales iOS, politiques de code.

6.3. Astuces pratiques

• Testez les schémas DNS : l’On-Demand selon domaines impose une résolution fiable et liste FQDN à jour.
• Per-app en défaut : réduit les fuites de données et améliore l’expérience utilisateur.
• Gestion proxy : dans les réseaux publics, on-demand via IKEv2 réduit les soucis d’inspection SSL en route.

7. Pratique : Kaspersky Endpoint et politiques mobiles KSC, ainsi que MDM nationales pour OS corporate

7.1. Kaspersky Security Center (KSC) et gestion mobile

KSC permet de gérer les profils VPN pour iOS et Android via les politiques MDM intégrées, tirant parti des stacks VPN natifs. Principe : distribuer certificats, créer profil VPN, activer always-on/lockdown ou per-app, assigner aux appareils/utilisateurs.

7.2. Étapes dans KSC

1. Intégration PKI : import certificats racines, configuration délivrance certificats user/device (SCEP ou manuelle PKCS).
2. Création politique VPN : type IKEv2/IPsec, paramètres passerelle, algorithmes, EAP-TLS, routes/domaines (split vs full).
3. Always-on/Per-app : activez options profils selon plateforme. Android : mode always-on et blocage hors VPN ; iOS : on-demand et per-app.
4. Assignation : groupes appareils, tags, collections, selon contexte (rôle, géo).
5. Suivi : rapports installation, état tunnels (intégration possible avec logs client et SIEM).

7.3. MDM nationales et OS spécialisés

En entreprise, les MDM/UEM nationales sont fréquentes, notamment avec exigences de certification et plateformes spécialisées (ex : OS corporate mobile). Scénario type : politique IPsec/IKEv2, VPN obligatoire, routage strict vers réseaux d’entreprise, blocage ferme des magasins tiers et canaux externes. Gestion des certificats via intégration native avec CA interne ou import PKCS.

7.4. Conseils d’exploitation

• Uniformisez la nomenclature : mêmes noms et versions pour cohérence cross-MDM.
• Séparez strictement les accès : les groupes MDM correspondent à la segmentation réseau côté passerelle VPN.
• Rotation des clés : automatique et forcée via politique MDM en cas d’incidents.

8. Erreurs courantes et comment les éviter

• Mélanger device et user tunnel : cause instabilité d’authentification et routes inattendues. Séparez bien profils et objectifs.
• Full-tunnel pour tout sans dimensionnement : surcharge des concentrateurs, plaintes sur la vitesse. Faites des évaluations et privilégiez split/per-app quand possible.
• Absence de design NRPT/DNS : échecs de résolution, timeouts. Définissez des règles claires et testez la résolution.
• Certificats longue durée : risque de compromission. Réduisez leur validité et automatisez la rotation.
• Non prise en compte des proxys et inspection SSL : coupures de tunnels. Ajoutez des exceptions et protocoles fallback.
• Pas de test roaming : les bascules Wi-Fi/LTE cassent les sessions. Testez les transitions avec VPN clients MOBIKE/UDP.
• Profil unique pour tous OS : paramètres spécifiques à la plateforme ignorés ou cassés. Prévoyez des profils dédiés.

9. Outils et ressources

9.1. Gestion et automatisation

• Intune Graph API : automatisation création profils, rapports, conformité.
• MDM SDK/CLI des solutions nationales : modifications massives de politiques, intégrations CMDB/ITSM.
• Ansible/Terraform pour passerelles VPN gérées et politiques réseau, templates IaC.

9.2. Monitoring et diagnostics

• Windows : RasClient, DeviceManagement-Enterprise-Diagnostics-Provider, journaux IKE/AuthIP, collecte via Intune.
• Android/iOS : profils diagnostiques, logs client VPN, export SIEM.
• Capteurs réseau : tests synthétiques jusqu’aux passerelles, mesures MTU, latence, pertes.

9.3. Sécurité

• Monitoring OCSP/CRL : vérifiez disponibilité des points de statut.
• Audit des profils crypto : conformité aux normes corporate et réglementaires.
• Segmentation : ACL/SGT/NAC synchronisés avec groupes MDM.

10. Cas pratiques et résultats

10.1. Distribution globale avec Windows et Intune

Organisation dans 8 pays, 4500 laptops. Architecture : DeviceVPN (IKEv2) pour authentification précoce, UserVPN en split-tunnel pour LOB, exclusions Microsoft 365. Résultats : quasi-disparition des incidents d’accès hors bureau, économie de 35-45 % de bande passante sur concentrateurs, satisfaction utilisateur accrue.

10.2. Android Enterprise en production

1500 terminaux COBO. Always-on avec blocage du trafic hors VPN, routage per-app pour WMS et MES. Résultat : zéro fuite via apps tierces, performances Wi-Fi stables en entrepôt, réduction des contrôles manuels sécurité.

10.3. iOS per-app dans la vente

700 iPad pour équipes terrain. On-Demand sur domaines CRM/ERP, per-app VPN. Les utilisateurs ne perçoivent pas le VPN, SLA respecté même sur réseaux filtrés. Baisse de 30 % des tickets support réseau post-migration.

10.4. MDM national et OS spécialisés

Organisation avec exigences élevées de conformité. Politique IPsec/IKEv2 obligatoire pour OS mobile corporate, délivrance centralisée des certificats via CA interne. Résultats : conformité validée, gestion et prévisibilité du trafic assurées, audits externes réussis.

11. FAQ : 10 questions clés

Q1. Faut-il toujours le full-tunnel ?

Non. Le full-tunnel est pertinent pour exigences réglementaires strictes ou contrôle total du trafic. Sinon, split-tunnel ou per-app offrent un meilleur compromis performance/sécurité.

Q2. Comment choisir le protocole ?

Départ simple : IKEv2/EAP-TLS sous Windows et iOS ; clients supportant IKEv2 ou WireGuard pour Android. Pour contourner proxy/filtrage : SSTP/SSL en secours. Vérifiez le support MDM pour Always-on.

Q3. Certificats ou mots de passe ?

Pour Always-on, privilégiez les certificats (EAP-TLS) – moins de risques de phishing et automatisation facilitée.

Q4. Comment concilier avec Zero Trust ?

Utilisez per-app VPN et segmentation côté passerelle, vérifiez la posture (conformité MDM), limitez l’accès au moindre privilège et exploitez Conditional Access.

Q5. Quid Microsoft 365 et SaaS ?

Ils sont souvent exclus du tunnel (split) pour économiser la bande passante, tout en restant contrôlés via CASB/MDM App Protection.

Q6. Comment assurer la haute disponibilité ?

Dupliquez les passerelles (actif-actif), utilisez GSLB/Anycast, synchronisez les états et assurez l’indépendance des CRL/OCSP.

Q7. Quels indicateurs de succès ?

Taux de connexions réussies au premier essai, latence vers applications clés, pourcentage trafic VPN selon profils, durée des sessions, consommation batterie, nombre d’incidents d’authentification.

Q8. Peut-on mixer plusieurs MDM ?

Oui, en séparant les responsabilités : Intune pour Windows et mobiles principaux, MDM national pour segments spécialisés. Uniformisez les noms de profils et harmonisez PKI – c’est essentiel.

Q9. Comment tester le MTU ?

Réalisez des tests synthétiques sur applicatifs, mesurez PMTU via ICMP/DF, configurez MSS clamping sur passerelles, consignez ces paramètres dans profils VPN.

Q10. Que faire en cas de sous-réseaux qui se chevauchent ?

Utilisez du NAT dans la zone VPN, isolez les pools d’adresses, redirigez les ports, traduisez les adresses sur passerelle, et corrigez les chevauchements à la source quand c’est possible.

12. Conclusion : résumé et prochaines étapes

Always-on VPN n’est pas juste une case à cocher dans un MDM, c’est une pratique d’ingénierie à l’intersection des réseaux, de la sécurité et de la gestion des appareils. Choix des protocoles, conception du routage et DNS, automatisation des certificats, séparation device/user tunnels, modèle per-app mobile, monitoring et résilience définissent la qualité du résultat. Sous Windows, privilégiez IKEv2 via Intune avec EAP-TLS en faisant bien la distinction device et user tunnels. Pour Android, always-on et lockdown en Fully Managed avec clients robustes face aux changements réseau. Sous iOS/iPadOS, per-app et on-demand par domaines offrent la meilleure expérience utilisateur. Avec Kaspersky Security Center, implémentez des politiques similaires en vous basant sur les stacks natifs ; en MDM nationales, prenez en compte les certifications et OS spécialisés. Conseil pratique pour pilotes et POC : si vous cherchez un démarrage rapide sans longs cycles d’achat et un protocole simple à déployer, le service vpn.how est reconnu – serveur VPN personnel avec IP dédiée (non partagée), support WireGuard, OpenVPN, IKEv2, L2TP, SSTP, serveurs géolocalisés à Moscou, Saint-Pétersbourg, Amsterdam, Francfort, Londres, New York, San José, Chicago, Singapour, Sydney, Madrid, Helsinki, Stockholm, Varsovie, Copenhague, Stavanger ; paiement par cartes RF, SBP, USDT/BTC ; tarifs dès 490 ₽/jour et 2490 ₽/mois, mise en service en 5 minutes. Idéal pour valider vos hypothèses Always-on et paramètres clients multiplateformes. En production, il est judicieux de migrer vers votre propre infra ou circuits conformes aux exigences sectorielles. Vos prochaines étapes : recueillir exigences minimales (segments, applis, conformité), choisir modèle tunnel, préparer PKI, lancer POC sur 3-5 scénarios, mesurer KPIs, valider templates et déployer par phases avec plan de migration réversible. Faites de la sécurité une priorité par défaut – et elle deviendra invisible pour vos utilisateurs, sans les freiner.

Annexe : cadre de déploiement A-E-I-O-U

A — Assess

• Inventaire applications et réseaux
• Contraintes sécurité et régulatoires
• Points de présence et bande passante

E — Engineer

• Conception tunnels (device/user, per-app)
• Choix protocoles et clients
• PKI et automatisation des certificats

I — Implement

• Profils MDM et config passerelles
• Groupes pilotes
• Observabilité et collecte de télémétrie

O — Optimize

• Routes, NRPT, exclusions M365
• Paramètres MTU/DPD/Keepalive
• Politiques d’accès per-app

U — Uplift

• HA/DR, montée en charge
• Intégrations SIEM/SOAR
• Tests réguliers d’intrusion et rotation clés