Points clés
Pour un responsable IT/OT, une GMAO est un système de plus à intégrer, sécuriser et maintenir en fonctionnement. Les fonctionnalités de maintenance comptent moins que la façon dont le logiciel se comporte au sein du parc technologique plus large. Si on se trompe sur ce point, un outil utile devient une charge à long terme.
Une GMAO vit rarement isolée. Elle doit échanger des données avec l'ERP, les systèmes d'historisation et parfois les machines elles-mêmes. Le responsable IT/OT recherche des API propres et des intégrations standard, car des connecteurs personnalisés lourds sont fragiles, coûteux et constituent un obstacle aux futures mises à niveau.
Connecter un logiciel de maintenance à la technologie opérationnelle soulève de vraies questions : qui peut accéder à quoi, où les données sont stockées et comment la liaison avec les machines est sécurisée. Un contrôle d'accès strict, une auditabilité et une localisation claire des données ne sont pas des options pour ce rôle ; ce sont des exigences déterminantes.
Cloud ou sur site, authentification unique, manière dont les mises à jour sont gérées, tout cela détermine la charge continue que le système crée pour l'informatique. Une plateforme qui s'intègre aux outils d'identité et de sécurité existants et qui se met à jour sans intervention manuelle génère une charge bien moindre qu'une solution nécessitant un accompagnement constant.
Un responsable IT/OT évalue deux options de GMAO. L'une propose des API standard, une authentification unique et une documentation de sécurité claire; l'autre nécessite des travaux d'intégration sur mesure et une connexion distincte.
La première s'intègre à la pile et au modèle de sécurité avec peu de surcharge; la seconde ajoute une île à gérer et une nouvelle surface d'attaque. Les fonctionnalités de maintenance étaient similaires; c'est l'architecture qui a tranché.
Connecter la maintenance aux données de production en temps réel, y compris l' OEE , multiplie la valeur d'une GMAO, mais multiplie aussi le travail d'intégration et de sécurité. Un responsable IT/OT souhaite que cette connexion se fasse via des interfaces propres et sécurisées plutôt que par des liens personnalisés fragiles.
Réservez une démo de Fabrico pour voir comment la maintenance connectée et les données d'OEE peuvent s'adapter à une architecture existante. Voir aussi CMMS cloud vs sur site .
Une intégration propre aux systèmes existants, un contrôle d'accès strict et une gouvernance des données, une connectivité sécurisée à la technologie opérationnelle, et une compatibilité avec les outils d'identité et de mise à jour existants pour maintenir la charge informatique faible.
Cela peut l'être, c'est pourquoi la liaison doit être sécurisée délibérément, avec contrôle d'accès, audit et limites claires. Bien fait, les données de production qu'elle permet d'obtenir valent largement le risque géré.
Les responsables informatiques doivent valider: la posture de sécurité du cloud (certification SOC 2 Type II minimum, ISO 27001 préférée), la localisation des données et la documentation de conformité au RGPD/CCPA, l'intégration du SSO et de la gestion des identités (Active Directory
Azure AD, Okta), l'architecture de sécurité réseau pour la connectivité OT, et les engagements SLA concernant la disponibilité et les temps de réponse du support.
Les responsables OT doivent valider: la méthode de connexion des automates programmables (PLC) et des systèmes SCADA (API directe, OPC-UA, Modbus ou connecteur propriétaire), la conformité de la segmentation réseau (la GMAO cloud ne devrait pas nécessiter de règles de pare-feu directes du réseau OT vers l'Internet public)
l'architecture de passerelle edge pour collecter les données machine sans exposer les systèmes OT, et l'expérience du fournisseur avec la norme de cybersécurité industrielle ISA/IEC 62443.
Le processus d'achat de la GMAO implique fréquemment que l'informatique approuve la sécurité sans la participation de l'OT, ou que l'OT spécifie des exigences de connectivité sans l'examen de sécurité par l'IT, ces deux schémas créent des problèmes d'implémentation post-contrat coûteux.
La question centrale de sécurité réseau pour les CMMS cloud dans l'industrie manufacturière est de savoir comment les données machine circulent du réseau OT vers la plateforme cloud. Trois architectures existent, avec des profils de sécurité différents.
Architecture 1: connexion directe PLC-cloud, le logiciel du fournisseur de CMMS se connecte directement aux automates programmables (PLC) via le réseau de l'usine, avec des connexions HTTPS sortantes uniquement vers le cloud.
C'est simple mais cela nécessite des règles de pare-feu autorisant le trafic sortant depuis le réseau OT, ce que de nombreuses normes de sécurité OT interdisent.
Architecture 2: passerelle en périphérie, un dispositif de périphérie dédié (PC industriel ou matériel de passerelle) se trouve dans la DMZ entre les réseaux OT et IT, collecte les données des automates et les transfère vers le cloud.
Cela maintient l'isolation du réseau OT et c'est l'architecture recommandée par la norme ISA/IEC 62443 et par les lignes directrices du NIST. Architecture 3: intermédiaire MES, le CMMS récupère les données d'un MES existant ou d'un système historien déjà présent sur le réseau IT, préservant l'isolation OT sans nécessiter de nouveau matériel de périphérie.
Lors de l'évaluation des fournisseurs de CMMS, demandez un schéma d'architecture réseau montrant exactement où se produit la connectivité et quelle architecture ils prennent en charge. Les fournisseurs qui ne peuvent pas fournir ce schéma n'ont pas envisagé les implications en matière de sécurité OT de leur approche d'intégration.
Pour les responsables IT/OT effectuant un examen de sécurité d'un fournisseur de GMAO (CMMS), utilisez cette liste de contrôle comme référence. Résidence des données : confirmez que la région d'hébergement cloud correspond aux exigences de résidence des données de votre organisation et obtenez une confirmation écrite de l'endroit où les données sont traitées et stockées.
Certifications de sécurité: exigez le rapport SOC 2 Type II (datant des 12 derniers mois) et examinez spécifiquement la section 7 (Disponibilité) et la section 9 (Confidentialité). Tests d'intrusion: demandez un résumé du test d'intrusion le plus récent réalisé par un tiers et l'état de remédiation des constatations.
Sécurité des API: confirmez que l'API REST utilise OAuth 2.0 avec expiration des jetons et limitation du débit, pas d'authentification par clé API sans expiration.
Normes d'intégration : exigez la prise en charge d'OPC-UA pour la connectivité des automates modernes et confirmez la prise en charge de Modbus TCP pour les équipements hérités. Export de données : confirmez la capacité d'exporter en masse les données dans des formats ouverts (CSV, JSON) sans intervention du fournisseur, ceci protège votre droit de sortie.
Sauvegarde et récupération : exigez un RPO (Recovery Point Objective) inférieur à 1 heure et un RTO (Recovery Time Objective) inférieur à 4 heures pour les environnements de production. Accès fournisseur : exigez un journal d'accès fournisseur montrant tous les accès du fournisseur à votre environnement, accessible à votre équipe sur demande.
Ces exigences sont raisonnables pour tout fournisseur de GMAO d'entreprise et ne devraient pas créer d'obstacles à l'évaluation avec des plateformes établies.
Un TRS capté directement depuis vos machines, sans saisie manuelle ?
Voir en direct
Connexion
Blog
