Sécuriser et optimiser l'accès distant à votre ERP

Ouvrir son ERP aux accès distants sans créer une faille béante, c'est le défi que rencontrent la plupart des DSI et responsables IT. Entre le télétravail généralisé, les prestataires externes et les filiales réparties sur plusieurs sites, l'accès hors périmètre à un ERP est devenu la norme. Mais cette ouverture expose des données parmi les plus sensibles de l'entreprise : finances, RH, achats, stocks.

Lors d'une mission d'audit que j'ai menée pour une ETI industrielle sous SAP, j'ai découvert qu'un prestataire de maintenance accédait encore à l'ERP via un compte partagé, sans MFA, sur une connexion VPN configurée en 2018 et jamais révisée. Ce type de situation est bien plus courant qu'on ne le croit.

Dans cet article, je couvre les vrais risques, les architectures solides et les contrôles concrets pour sécuriser chaque accès distant à votre ERP.

Pourquoi l'accès distant à un ERP est une cible prioritaire ?

Un ERP concentre l'intégralité du capital informationnel d'une entreprise : données clients, marges, paie, contrats fournisseurs, plans de production. Pour un attaquant, compromettre un accès distant à cet outil revient à entrer directement dans le coffre-fort. C'est précisément pour ça que les ERP figurent en tête des cibles dans les campagnes de ransomware ciblées contre les ETI et PME.

Les vecteurs d'attaque les plus fréquents sur les accès distants ERP se répartissent en trois catégories. D'abord les identifiants volés ou trop faibles, souvent sans authentification multifacteur. Ensuite les interfaces d'administration exposées sur internet : ports RDP, webservices non filtrés, ou interfaces natives comme SAP GUI Logon, dont les vecteurs d'exposition sont documentés dans le guide architecture sécurisée de SI de l'ANSSI, référence française pour la conception des architectures critiques. Enfin les comptes de prestataires dormants, jamais désactivés après la fin d'une mission.

Les données GSC confirment cet intérêt croissant : la requête "accès distant sécurisé" cumule 270 impressions sur notre domaine avec une position encore très basse. Le sujet monte, mais peu de contenus francophones traitent le fond technique sérieusement.

VPN ou Zero Trust : quelle architecture choisir pour votre ERP ?

Sécuriser l'accès distant à un ERP implique de choisir entre deux paradigmes fondamentaux. Le VPN traditionnel crée un tunnel chiffré vers le réseau interne, tandis que le Zero Trust Network Access (ZTNA), un modèle fondé sur l'architecture Zero Trust appliquée aux systèmes d'information, authentifie chaque requête indépendamment, sans confiance implicite liée à la position réseau. Ces deux approches répondent à des contextes très différents selon la taille de l'organisation et son niveau d'exposition.

Le VPN reste pertinent pour des petites structures avec peu d'utilisateurs distants et un ERP on-premise bien isolé. Il est simple à déployer, mature et maîtrisé par la plupart des équipes IT. Son problème principal : une fois le tunnel ouvert, l'utilisateur accède souvent à l'ensemble du réseau interne, bien au-delà de ce que l'ERP nécessite. Un poste compromis via VPN peut se déplacer latéralement vers d'autres systèmes.

Le Zero Trust corrige précisément ce défaut. Chaque accès est conditionné à l'identité vérifiée, à la conformité du terminal et au contexte de la demande. L'utilisateur n'accède qu'aux ressources ERP spécifiques dont il a besoin. C'est l'architecture que je recommande dès lors que l'ERP est exposé à des utilisateurs nomades, des sous-traitants, ou qu'il tourne sur une infrastructure hybride ou cloud.

Tableau comparatif VPN vs Zero Trust pour un accès ERP

Critère	VPN traditionnel	Zero Trust (ZTNA)
Périmètre d'accès	Réseau entier après connexion	Ressource par ressource, granulaire
Authentification	Login/mot de passe + MFA optionnel	MFA obligatoire + conformité du poste
Mouvement latéral	Possible si poste compromis	Bloqué par défaut
Visibilité des sessions	Limitée (logs tunnel)	Granulaire (chaque requête loguée)
Compatibilité ERP cloud	Complexe (hairpin traffic)	Native (proxy applicatif)
Coût de déploiement	Faible à moyen	Moyen à élevé
Complexité d'administration	Faible	Plus élevée (politiques IAM)
Adapté pour prestataires	Risqué (accès trop larges)	Oui (accès limités et tracés)

En pratique, beaucoup d'entreprises de taille intermédiaire adoptent une approche hybride : VPN IPsec pour les sites fixes et les serveurs, ZTNA pour les utilisateurs nomades et les tiers. Ce choix d'architecture doit s'inscrire dans votre stratégie de cybersécurité globale, pas être traité comme une décision technique isolée. Cette combinaison équilibre maîtrise des coûts et niveau de sécurité réel.

SAP, Odoo, Dynamics : des spécificités à connaître par plateforme

Chaque ERP présente une surface d'attaque et des mécanismes de sécurité propres. Traiter la sécurité de l'accès distant de manière générique, sans tenir compte de la plateforme, c'est laisser les vulnérabilités spécifiques ouvertes.

SAP : une surface d'attaque historiquement sous-estimée

SAP est la cible la plus documentée dans les CVE liés aux ERP. Le port 3200 (SAP GUI), les RFC destinations mal configurées et l'interface ICM (Internet Communication Manager) sont les trois points d'entrée les plus exploités sur les accès distants. La désactivation du service SAP Message Server sur les interfaces publiques est un prérequis si votre SAP est accessible hors réseau local.

Pour l'accès distant SAP, l'approche recommandée combine un reverse proxy applicatif devant SAP Web Dispatcher, une authentification SSO via SAML 2.0 ou OAuth 2.0, et une politique de restriction IP stricte pour les RFC distantes. Le module SAP Identity Management permet, pour les équipes qui gèrent un access distant a SAGE dans un environnement mixte SAP/Sage, de contrôler les provisionnements de comptes avec des droits granulaires selon la mission de chaque intervenant. Cette granularité limite directement le rayon d'action en cas de compromission.

Odoo : la vigilance sur les modules exposés

Odoo est souvent déployé avec une interface web directement exposée sur internet, ce qui simplifie l'accès distant mais élargit la surface d'attaque. J'ai observé sur le terrain que beaucoup d'instances Odoo community en PME tournent avec des mots de passe admin par défaut ou des modules inutilisés activés, le module XMLRPC en tête, qui permet l'exécution de code à distance.

Les mesures prioritaires pour Odoo en accès distant : désactiver le XMLRPC si non utilisé dans la configuration Odoo.conf, activer le 2FA natif disponible depuis la version 14, placer un WAF (Web Application Firewall) devant l'instance, et restreindre l'accès au backend `/web` via liste blanche d'IP pour les administrateurs.

Microsoft Dynamics 365 : les risques liés à l'environnement Microsoft

Dynamics 365 s'appuie sur l'écosystème Azure AD (désormais Entra ID) pour l'authentification. Son principal vecteur de compromission en accès distant passe par le compte Microsoft de l'utilisateur : phishing ciblé, pass-the-hash ou session token theft. L'activation du Conditional Access dans Entra ID est le premier levier à activer, en conditionnant l'accès à Dynamics à un terminal conforme (Intune) et à une authentification MFA résistante au phishing (FIDO2 ou Windows Hello).

Les politiques de Data Loss Prevention (DLP) dans Power Platform permettent aussi de bloquer les exports de données depuis Dynamics vers des services cloud non approuvés. Ces politiques sont d'autant plus critiques que, selon l'étude IDC sur l'ERP cloud menée en partenariat avec SAP, la responsabilité de configuration reste entièrement côté client dans les déploiements SaaS. Elles sont pourtant souvent oubliées lors de la mise en production initiale.

Gérer les accès tiers et prestataires sans perdre le contrôle

Les accès tiers sont, avec les identifiants compromis, le principal vecteur de violation de données sur les ERP. Un intégrateur, un consultant externe ou un prestataire de maintenance a souvent besoin d'un accès temporaire à des modules spécifiques. Sans gouvernance structurée, ces accès persistent bien après la fin de la mission et deviennent des portes dérobées involontaires.

La bonne pratique est d'appliquer le principe du moindre privilège sans exception. Chaque prestataire doit disposer d'un compte nominatif (jamais de compte partagé), limité aux modules strictement nécessaires, avec une date d'expiration automatique, y compris pour les flux gérés via les modules e-procurement intégrés qui mobilisent souvent de nombreux accès fournisseurs. Un tableau de bord de revue des accès actifs, consulté mensuellement par le responsable IT, permet d'identifier rapidement les comptes dormants.

Sur le plan technique, une solution PAM (Privileged Access Management) comme CyberArk, BeyondTrust ou Wallix est le bon choix pour les accès prestataires à un ERP critique. Ces outils enregistrent l'intégralité des sessions, permettent d'injecter les credentials sans les divulguer à l'utilisateur et génèrent des alertes sur les comportements anormaux (accès en dehors des horaires, volumes d'export inhabituels).

Les règles minimales pour les accès tiers ERP

• Compte nominatif unique par prestataire, jamais générique
• Durée de validité limitée, expiration automatique
• Authentification MFA obligatoire même pour les externes
• Accès limité aux modules concernés par la mission
• Enregistrement de session obligatoire via PAM ou Jump Server
• Révocation immédiate à la fin de la mission (procédure documentée)
• Revue mensuelle des comptes actifs par le responsable IT

Comment mettre en place une architecture d'accès distant ERP ?

Une architecture d'accès distant ERP sécurisée repose sur une série de couches de contrôle entre l'utilisateur et les données. Le schéma suivant illustre la chaîne de confiance à mettre en place, de la requête initiale jusqu'au serveur applicatif ERP.

La couche la plus externe est le point d'entrée : soit un ZTNA broker (cas cloud ou hybride), soit un VPN concentrateur bien segmenté (cas on-premise). L'authentification multifacteur intervient à ce niveau, avant toute entrée sur le réseau d'entreprise. Aucune exception, y compris pour les administrateurs.

La DMZ forme la deuxième couche, séparée du réseau interne par un pare-feu filtrant dont les règles ne laissent passer que le trafic HTTPS vers le reverse proxy ERP. Un WAF analyse ce flux pour bloquer les injections SQL et les tentatives de manipulation de session.

Ce déploiement WAF s'inscrit dans les recommandations du guide sécurité données personnelles de la CNIL, qui exige des mesures techniques adaptées pour tout traitement de données personnelles exposé sur internet. Les exploits sur les interfaces ERP sont précisément ce que ces règles doivent bloquer en priorité.

Le segment ERP, en zone interne, est lui-même isolé du reste du SI. Le serveur de base de données n'est accessible que depuis le serveur applicatif ERP, jamais directement depuis les postes clients. Cette micro-segmentation empêche un attaquant ayant compromis un poste utilisateur d'accéder directement aux données brutes.

Les briques techniques à déployer en priorité

• MFA sur l'accès distant (TOTP, FIDO2 ou certificat client)
• Reverse proxy applicatif devant l'interface ERP (Nginx, HAProxy, SAP Web Dispatcher)
• WAF en frontal (ModSecurity, AWS WAF, Cloudflare WAF selon contexte)
• Pare-feu à état avec politique "deny all, allow by exception"
• Segmentation réseau : zone accès distant, DMZ, zone ERP, zone BDD
• Gestion des certificats TLS avec rotation automatique
• Bastion SSH ou Jump Server pour les accès administrateurs

Journalisation et traçabilité : voir ce qui se passe réellement

Une sécurité sans visibilité est une sécurité aveugle. La journalisation des accès distants à un ERP relève souvent d'une obligation réglementaire au sens de la certification ISO 27001, qui en formalise les exigences dans ses contrôles A.8.15 et A.8.17 sur la surveillance des événements et la protection des journaux. Elle conditionne aussi la capacité à détecter une intrusion et à y répondre avant que les dommages ne se propagent.

Les événements à journaliser en priorité : authentifications réussies et échouées, changements de droits d'accès, exports de données volumineux, accès à des modules sensibles (paie, finances, achats), et toutes les actions réalisées par les comptes à privilèges. Ces logs doivent être centralisés dans un SIEM (Security Information and Event Management) externe à l'ERP, pour éviter qu'un attaquant ayant compromis l'ERP puisse les effacer.

J'ai eu l'occasion de travailler sur la mise en place d'un SIEM pour une ETI sous Dynamics 365 : le bénéfice le plus immédiat n'était pas la détection d'une attaque (qui n'a heureusement pas eu lieu pendant notre mission), mais la découverte d'une dizaine de comptes actifs dont les responsables avaient quitté l'entreprise depuis plus d'un an. Les flux documentaires transitant par la gestion électronique de documents, souvent couplée à l'ERP pour les archivages réglementaires, échappent régulièrement au périmètre initial du SIEM. Ils doivent être explicitement inclus dans la politique de journalisation dès la phase de cadrage.

Indicateurs clés à surveiller dans les logs ERP distants

• Tentatives de connexion répétées depuis une même IP (brute force)
• Connexions en dehors des plages horaires habituelles
• Accès depuis des pays ou zones géographiques inhabituels
• Volume d'export ou de requêtes inhabituellement élevé
• Changement de configuration ou de droits sur des comptes à privilèges
• Accès simultanés depuis deux localisations différentes pour un même compte

Tester ses défenses : le pentest ERP en pratique

La seule façon de savoir si une architecture tient vraiment, c'est de l'attaquer. Un pentest ERP ciblé sur les accès distants identifie les failles avant qu'un vrai attaquant ne les trouve. Ce n'est pas un audit de conformité : c'est une simulation d'attaque réelle, menée par des professionnels mandatés.

Un pentest ERP couvre plusieurs angles : la reconnaissance externe (quels ports, quelles interfaces sont visibles depuis internet ?), l'attaque des mécanismes d'authentification (résistance au brute force, bypass MFA, faiblesse des tokens de session), les autorisations (un utilisateur peut-il accéder à des modules hors de son périmètre ?), et les injections applicatives sur les interfaces web et les APIs. Le scope doit aussi intégrer les instances qui ont fait le choix d'héberger votre ERP sur un VPS chez un hébergeur tiers, car la frontière de responsabilité entre client et fournisseur y est souvent floue dans les mandats de test. Définir explicitement le périmètre technique reste la première étape d'un engagement de pentest sérieux.

Côté SAP, les pentesters s'appuient sur des frameworks spécialisés comme Metasploit (modules SAP) ou ERPScan, ainsi que les outils de la communauté OWASP. Sur Odoo, l'API XMLRPC, les endpoints REST et les modules communautaires tiers sont les cibles prioritaires, leur code étant souvent moins audité que le core. Dynamics fait l'objet de tests sur la configuration Azure AD, les Conditional Access policies et les connecteurs Power Automate exposés.

Un pentest annuel est le minimum pour tout ERP exposé à des accès distants. Des tests complémentaires s'imposent à chaque modification structurelle de l'architecture : migration cloud, passage vers une infrastructure bare metal dédiée ou changement de solution VPN. Le rapport de chaque pentest doit alimenter un plan de remédiation précis, avec des délais de correction calés sur la criticité des vulnérabilités identifiées.

Questions fréquentes sur la sécurisation de l'accès ERP

Quelle est la différence entre un VPN et une solution Zero Trust pour sécuriser un ERP ?

Le VPN crée un tunnel chiffré vers l'ensemble du réseau interne, donnant à l'utilisateur connecté un accès large une fois authentifié. Le Zero Trust n'accorde l'accès qu'aux ressources ERP spécifiques nécessaires, en vérifiant l'identité et la conformité du terminal à chaque requête. Pour un ERP avec des données sensibles ou des accès prestataires, le Zero Trust réduit considérablement la surface d'attaque.

Le MFA suffit-il à sécuriser l'accès distant à mon ERP ?

Le MFA est indispensable mais insuffisant seul. Il protège contre le vol de mot de passe, pas contre la compromission d'un terminal déjà connecté, les injections applicatives sur l'interface ERP, ni les abus de droits d'un compte légitime. C'est un filet, pas un mur : il doit être combiné avec une segmentation réseau, un WAF, des politiques d'accès granulaires et une journalisation active.

Comment gérer les accès d'un prestataire externe à l'ERP de façon sécurisée ?

Créer un compte nominatif avec une date d'expiration automatique, limité aux seuls modules nécessaires à la mission. L'accès doit passer par un Jump Server ou une solution PAM qui enregistre la session. Le MFA est obligatoire. Une procédure de révocation immédiate à la fin de la mission doit être documentée et suivie, avec une revue mensuelle des comptes actifs pour détecter les oublis.

Mon ERP est hébergé dans le cloud : les règles de sécurité changent-elles ?

L'hébergement cloud déplace la responsabilité de certaines couches (infrastructure physique, disponibilité réseau) vers le fournisseur, mais ne modifie pas les obligations de sécurité applicative. Les accès distants restent de votre responsabilité : MFA, Conditional Access, politiques IAM, journalisation, gestion des comptes prestataires. La configuration par défaut d'un ERP SaaS est rarement optimisée pour la sécurité.

Quels sont les signes qu'un accès distant à mon ERP a été compromis ?

Les indicateurs les plus fréquents : connexions depuis des localisations inhabituelles ou en dehors des horaires de travail, pic soudain d'exports de données ou de requêtes en base, modifications de configuration non planifiées, nouvelles règles de pare-feu ou de routage non documentées, et alertes de l'antivirus sur le poste d'un utilisateur ayant accès à l'ERP. Un SIEM correctement configuré détecte ces anomalies en temps réel.

À quelle fréquence faire un pentest sur les accès distants de mon ERP ?

Annuellement au minimum. Des tests supplémentaires s'imposent après chaque changement majeur : migration vers le cloud, ajout d'un module, changement de prestataire d'infogérance ou de solution VPN/ZTNA. Chaque rapport doit déboucher sur un plan de remédiation avec des délais précis, qu'on vérifie lors du pentest suivant.

SAP, Odoo ou Dynamics : lequel est le plus difficile à sécuriser en accès distant ?

SAP présente historiquement la surface d'attaque documentée la plus large, avec de nombreux CVE sur ses protocoles legacy (RFC, DIAG). Sa complexité de configuration en fait aussi la plateforme où les erreurs de paramétrage sont les plus courantes. Odoo est plus simple mais souvent déployé avec moins de rigueur en PME. Dynamics bénéficie de l'écosystème Azure AD, mais sa sécurité dépend entièrement de la bonne configuration des politiques Entra ID, que beaucoup d'entreprises laissent en paramètres par défaut.