Points clés
- Les applications métiers (ERP, CRM, SIRH, outils de BI) présentent des patterns de vulnérabilités récurrents liés à leur conception historique et à leurs cycles de mise à jour lents.
- Les intégrations entre applications métiers créent des surfaces d'attaque spécifiques : flux de données non chiffrés, credentials partagés, APIs sans authentification robuste.
- Les personnalisations et développements sur mesure dans les applications métiers standards (modules SAP, workflows Salesforce) accumulent une dette de sécurité hors du périmètre de support de l'éditeur.
- Les comptes de service utilisés pour les intégrations inter-applicatives sont souvent suréquipés en droits et rarement monitorés.
Les vulnérabilités structurelles des applications métiers
Les applications métiers — ERP (SAP, Oracle, Microsoft Dynamics), CRM (Salesforce, HubSpot), SIRH, outils de BI — présentent des patterns de vulnérabilités qui leur sont spécifiques. Elles ont souvent été conçues dans une logique périmétrique (supposant un accès uniquement depuis le réseau interne sécurisé), avec des mécanismes d'authentification qui ne supportent pas facilement le MFA ou les standards modernes (SAML, OIDC). Leurs cycles de mise à jour sont souvent plus lents que les applications web modernes, en raison de leur complexité, de leurs dépendances à des configurations client spécifiques, et des coûts de validation des mises à jour.
La exposition croissante de ces applications via des portails web, des APIs partenaires, et des accès distants (télétravail, accès mobile) crée une surface d'attaque pour des applications dont l'architecture de sécurité n'était pas conçue pour ce modèle d'accès.
Les intégrations inter-applicatives comme surface d'attaque
Dans le système d'information d'une organisation de taille significative, des dizaines ou centaines d'intégrations relient les applications entre elles : synchronisation ERP-CRM, flux de données entre SIRH et système de paie, intégrations avec des prestataires via EDI ou APIs. Chaque intégration est une surface d'attaque potentielle. Les flux de données non chiffrés entre applications peuvent être interceptés. Les credentials utilisés pour les comptes de service d'intégration sont souvent statiques (non rotés), partagés entre plusieurs intégrations, et dotés de droits excessifs.
La cartographie des intégrations inter-applicatives — un inventaire de qui communique avec qui, via quel protocole, avec quel niveau de chiffrement, et avec quels droits — est un prérequis de la sécurisation de ce périmètre. Dans la plupart des organisations, cette cartographie n'existe pas de manière exhaustive, créant des angles morts structurels.
Les personnalisations hors du périmètre éditeur
Les organisations qui personnalisent significativement leurs applications métiers standards (développements ABAP dans SAP, modules Apex dans Salesforce, scripts personnalisés dans les workflows) produisent du code qui sort du périmètre de support et de patch de l'éditeur. Ce code personnalisé présente souvent les mêmes vulnérabilités que les applications internes (injections, contrôles d'accès insuffisants, secrets en dur) mais bénéficie rarement de la même attention sécurité — les équipes de support fonctionnel n'ont pas toujours les compétences pour réaliser des revues de sécurité sur ces développements.
La gouvernance de la sécurité des personnalisations doit être explicitement définie : processus de revue de code, tests de sécurité, documentation des choix, et processus de gestion des vulnérabilités distincts des mises à jour de l'éditeur standard.
Les comptes de service comme vecteur d'attaque privilégié
Les comptes de service utilisés pour les intégrations inter-applicatives sont des cibles privilégiées pour les attaquants qui ont obtenu un accès initial au réseau. Ces comptes présentent systématiquement les mêmes caractéristiques vulnérables : mots de passe statiques rarement rotés, droits souvent excessifs (un compte de service créé pour "accéder à la base de données" peut avoir des droits d'administrateur base de données), absence de MFA (car les systèmes d'intégration ne supportent pas facilement l'authentification interactive), et absence de surveillance comportementale (leurs patterns d'accès inhabituels passent inaperçus faute d'alertes configurées).
La remédiation passe par un inventaire des comptes de service, une revue des droits accordés (principe du moindre privilège), une rotation régulière des credentials (idéalement automatisée via un gestionnaire de secrets), et la mise en place d'alertes sur les comportements anormaux de ces comptes.