Sauvegardes et récupération dans l'industrie métallurgique et manufacturière : quand avez-vous effectué le dernier test ?
La question qui compte n'est pas de savoir si une sauvegarde existe, mais quand quelqu'un a tenté pour la dernière fois de la restaurer. Une sauvegarde qui est effectuée mais jamais restaurée peut être incomplète, corrompue, ou simplement incompatible avec la machine sur laquelle elle devrait être déployée. Vous ne découvrirez cela pas en consultant un fichier journal, mais en le testant réellement.
Pour l'industrie des métaux et de la fabrication, il ne s'agit pas d'une question théorique. Les commandes CNC, les logiciels MES, les API et les systèmes de planification qui les entourent sont de plus en plus connectés au même réseau que l'informatique de gestion. Si ce réseau tombe en panne à cause d'une défaillance technique ou d'un incident, la question n'est pas seulement de savoir si les données reviennent, mais si la chaîne de production peut redémarrer dans un délai acceptable. C'est de cela que traite l'obligation de diligence énoncée dans la Directive (EU) 2022/2555 : non pas la possession d'une sauvegarde, mais la capacité démontrée à restaurer.
Pourquoi un test de restauration pèse plus que la sauvegarde elle-même
Une stratégie de sauvegarde se compose généralement de trois éléments : ce qui est copié, à quelle fréquence, et où cela est stocké. Ce sont des éléments que les entreprises maîtrisent habituellement bien, souvent depuis longtemps via leur prestataire informatique. Le quatrième élément fait défaut dans de nombreuses PME : un test programmé et répété au cours duquel quelqu'un restaure réellement la sauvegarde sur un environnement de test et vérifie que le résultat fonctionne.
Ce test montre si la sauvegarde et la restauration s'ajustent vraiment l'une à l'autre. Une sauvegarde d'un serveur de base de données sans les fichiers de configuration correspondants de la machine connectée est souvent inutilisable en pratique. Il en va de même pour une sauvegarde qui contient bien le fichier, mais pas la clé de licence ou la liaison avec le système de contrôle qui pilote la chaîne de production. Vous ne découvrez ce genre de lacunes qu'en effectuant la restauration, pas en lisant les paramètres.
Ce que cela signifie pour les systèmes connectés au réseau
Les systèmes de production qui étaient autrefois isolés du réseau de gestion sont, dans de nombreuses entreprises, désormais connectés à celui-ci : pour la maintenance à distance, pour les données de planification, ou parce qu'un prestataire a besoin d'un accès pour les mises à jour. Cette connexion rend l'entreprise plus efficace, mais signifie aussi qu'une panne ou un incident sur le réseau de gestion peut avoir des répercussions sur l'atelier de production.
Lors du test de restauration, il est donc utile de distinguer la sauvegarde des systèmes administratifs de celle des systèmes de production. Chacun a son propre délai de restauration, son propre responsable et ses propres risques en cas de défaillance. Un test qui ne couvre que le serveur de gestion ne dit rien sur la rapidité avec laquelle une machine CNC peut relire un dessin après une panne.
Ce que vous documentez et pourquoi c'est tout aussi important que le test lui-même
Un test de restauration que personne n'a documenté est, pour un régulateur ou un donneur d'ordres, impossible à distinguer d'un test qui n'a jamais eu lieu. La documentation n'a pas besoin d'être compliquée : la date du test, quel système a été restauré, qui l'a effectué, et quel était le résultat. C'est exactement le type de preuve qui réapparaît dans un questionnaire de sécurité d'un donneur d'ordres, et c'est le type de justification qui devient pertinent lors de la notification d'un incident.
Qui souhaite organiser cela par mesure trouvera dans l'aperçu de tous les sujets selon la situation comment la sauvegarde et la restauration se rapportent aux neuf autres mesures de l'obligation de diligence, telles que la gestion des accès et l'enregistrement des incidents. Cela évite que la restauration reste isolée, détachée du reste du dossier.
À quelle fréquence tester est suffisant
Il n'existe pas de délai fixe qui s'applique à toutes les entreprises ; cela dépend de la criticité du système et de la rapidité avec laquelle il doit redémarrer après une panne. Un test annuel peut être insuffisant pour certains systèmes et amplement suffisant pour d'autres. Les autorités de surveillance et la directive elle-même ne prescrivent aucun intervalle ; elles s'attendent à ce qu'une organisation puisse justifier pourquoi la fréquence choisie est appropriée au regard de l'importance du système.
Si vous doutez du fait que votre entreprise soit soumise, en tant qu'entité essentielle ou importante, à l'obligation de diligence, ou si vous êtes seulement confrontée à des questions sur les sauvegardes par l'intermédiaire d'un donneur d'ordre, alors la vérification NIS2 vous en donne une première indication en quelques questions. Les questions fréquemment posées sur ce qui est et n'est pas obligatoire sont rassemblées sur la page des questions fréquemment posées.
Un test de récupération prend du temps, mais moins que la reconstruction d'un système de production sans savoir si la sauvegarde fonctionne. Voulez-vous voir comment cela s'intègre, aux côtés des autres obligations, dans un seul dossier, avec un statut, une preuve et un responsable par mesure ? Commencez par la vérification NIS2 gratuite, ou continuez à lire tranquillement dans la base de connaissances.