Conformité à l'article 12 de la directive DORA : guide de sauvegarde et de restauration à l'intention des entités financières

Bienvenue > Solutions de sauvegarde de données d’entreprise > Prise en charge de l’article 12 de la directive DORA avec Bacula Enterprise

La DORA est une loi européenne entrée en vigueur en janvier 2025, conçue pour garantir la continuité des activités des banques, des assureurs, des entreprises d’investissement et d’autres sociétés financières en cas de défaillance ou de compromission de leurs systèmes informatiques. Conformément à l’article 12 de la DORA, qui traite des sauvegardes et de la reprise après sinistre, vous êtes tenu de documenter les données que vous sauvegardez et la fréquence de ces sauvegardes, d’enregistrer la manière dont vous les restaurez, de tester régulièrement ces procédures et de restaurer les données sur des systèmes physiquement et logiquement séparés de l’environnement de production.

Bacula Enterprise est une plateforme de sauvegarde et de restauration cyber-résiliente qui facilite la mise en conformité avec l’article 12 de la directive DORA en fournissant les contrôles techniques requis. Ceux-ci comprennent des plannings de sauvegarde basés sur des politiques, des copies de sauvegarde chiffrées et immuables, des contrôles d’intégrité, ainsi que la restauration à partir de bandes isolées ou de supports de stockage déconnectés.

Exigences de l’article 12 de la loi DORA

L’article 12 de la loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act) porte sur les politiques de sauvegarde, les procédures de restauration ainsi que les méthodes de reprise. Ses exigences permettent aux entités financières de restaurer leurs systèmes informatiques et leurs données en minimisant les temps d’arrêt, les perturbations et les pertes de données à la suite d’une panne ou d’une cyberattaque.

Article 12, paragraphe 1, point a) : Portée et fréquence minimale des sauvegardes

En vertu de l’article 12, paragraphe 1, point a), les entités financières doivent établir et maintenir une politique de sauvegarde précisant quelles données elles sauvegardent et à quelle fréquence minimale chaque catégorie de données doit être sauvegardée. Elles doivent déterminer la portée et la fréquence de ces sauvegardes en fonction du niveau de criticité ou de confidentialité des données.

Les données présentant des niveaux de risque variables, cette règle garantit que vos données les plus importantes bénéficient d’une protection plus fréquente. Pour vous conformer à cette disposition, classez vos données par niveau de criticité ; par exemple, considérez les dossiers des comptes clients comme critiques, les fichiers RH comme importants et les anciens documents de projet comme peu prioritaires. Définissez ensuite une fréquence minimale pour chaque catégorie et consignez votre raisonnement dans la politique. Un registre des paiements peut nécessiter des sauvegardes toutes les heures, tandis qu’une archive de fichiers marketing peut être sauvegardée une fois par semaine.

Article 12, paragraphe 1, point b) : Procédures documentées de restauration et de reprise d’activité

Outre la politique de sauvegarde visée au point a), l’article 12, paragraphe 1, point b) porte sur l’aspect « reprise d’activité » de la protection des données. Il impose aux entités financières de disposer de procédures écrites de restauration et de reprise d’activité indiquant au personnel quelle sauvegarde utiliser, où la restaurer et dans quel ordre les systèmes doivent être remis en service. Le personnel ne pouvant se permettre d’improviser en cas de crise, un plan écrit l’aide à rétablir rapidement les services et réduit le délai de reprise. Veillez à ce que ces documents restent accessibles même lorsque vos systèmes principaux sont hors service.

Article 12, paragraphe 2 : Activation sécurisée des systèmes de sauvegarde

Une restauration effectuée sans précaution peut réintroduire des logiciels malveillants dans l’environnement de production ou laisser les données des clients sur un serveur non protégé. L’article 12, paragraphe 2 permet de se prémunir contre ce risque en imposant deux conditions à vos systèmes de sauvegarde. Premièrement, vous devez être en mesure de les activer conformément à votre politique de sauvegarde. Deuxièmement, leur mise en service ne doit pas compromettre la sécurité de votre réseau ni exposer vos données à un risque de perte, d’altération, de falsification ou de divulgation. Pour vous conformer à cet article, cryptez vos sauvegardes, limitez les personnes autorisées à effectuer des restaurations ainsi que les emplacements où les données restaurées peuvent être stockées, et analysez les données restaurées à la recherche de logiciels malveillants avant leur réintégration dans l’environnement de production.

Article 12(2) : Tests périodiques de sauvegarde et de restauration

L’article 12(2) exige également de tester périodiquement vos procédures de sauvegarde, de restauration et de reprise. Les sauvegardes non testées échouent souvent au pire moment possible, et la seule preuve que la restauration fonctionne consiste à restaurer les données sur un système de test distinct et à vérifier que l’application démarre, que les données sont complètes et que la restauration s’achève dans les délais fixés par votre objectif de temps de reprise. Utilisez un logiciel de sauvegarde et de reprise après sinistre cyber-résilient pour restaurer régulièrement des données réelles dans un environnement de test, et vérifiez que les systèmes fonctionnent. N’oubliez pas de consigner les résultats ainsi que les problèmes que vous résolvez, car les normes techniques de la DORA exigent que les résultats des tests soient documentés.

Article 12, paragraphe 3 : Systèmes de restauration séparés physiquement et logiquement

Lorsque les entités financières restaurent des sauvegardes sur leurs propres systèmes, l’article 12, paragraphe 3, les oblige à utiliser des systèmes séparés physiquement et logiquement de l’environnement de production et protégés contre tout accès non autorisé. Cette règle empêche un attaquant, même s’il a déjà pénétré dans l’environnement de production, d’atteindre votre environnement de restauration. L’EIOPA l’interprète comme désignant des systèmes sous votre contrôle total qui ne sont pas directement connectés au système principal. Pour vous conformer à cette exigence, mettez en place votre environnement de restauration sur une infrastructure distincte, dotée de sa propre séparation réseau et de ses propres contrôles d’accès. Votre logiciel de sauvegarde doit alors effectuer la restauration à partir de copies isolées, et Bacula Enterprise permet de restaurer des systèmes critiques à partir de bandes hors ligne ou d’un stockage déconnecté sur une infrastructure que vous contrôlez.

Articles 12, paragraphes 6 et 7 : Objectifs de reprise et contrôles d’intégrité

L’article 12, paragraphe 6 impose des objectifs de délai de reprise (RTO) et de point de reprise (RPO) pour chaque fonction, tandis que l’article 12, paragraphe 7 prévoit des contrôles d’intégrité et des rapprochements après la reprise suite à un incident. Ces règles définissent la rapidité avec laquelle vous devez effectuer la reprise, la quantité de données que vous pouvez vous permettre de perdre et la manière dont vous vérifiez l’exactitude des données restaurées. Afin de vous conformer aux articles 12, paragraphes 6 et 7, définissez un RTO et un RPO pour chaque fonction critique ou importante, et planifiez des sauvegardes au moins aussi fréquemment que le permet chaque RPO.

Un RPO d’une heure nécessite au moins des sauvegardes horaires, tandis qu’un RPO de 24 heures peut se contenter d’une sauvegarde nocturne. Avant la mise en service, effectuez un rapprochement des données restaurées avec celles de vos autres systèmes. Le reste de l’article 12 prévoit une capacité TIC redondante pour toutes les entreprises, à l’exception des plus petites, ainsi que des règles supplémentaires pour les dépositaires centraux de titres, les contreparties centrales et les prestataires de services de déclaration de données.

Autres règles DORA relatives à la sauvegarde et à la restauration (au-delà de l’article 12)

Il existe quelques règles supplémentaires en matière de sauvegarde et de restauration qui ne relèvent pas de l’article 12, mais auxquelles vous devez également vous conformer ; les auditeurs les citeront par leur numéro. Il est recommandé de les distinguer de l’article 12 afin de pouvoir associer plus facilement chaque élément de preuve à la disposition correspondante.

Articles 11, paragraphes 6 et 8 : Tests annuels de reprise d’activité et registres d’activité

L’article 11, paragraphe 6 traite d’une exigence relative à la fréquence des tests qui n’était pas mentionnée à l’article 12. Les entités financières doivent tester leurs plans de continuité des activités informatiques ainsi que leurs plans d’intervention et de reprise d’activité informatiques au moins une fois par an, et chaque fois qu’elles apportent une modification majeure aux systèmes prenant en charge des fonctions critiques ou importantes.

À moins que vous ne soyez une micro-entreprise (moins de 10 salariés et un chiffre d’affaires ou un total du bilan ne dépassant pas 2 millions d’euros), ces tests doivent s’appuyer sur un scénario de cyberattaque et impliquer un basculement effectif vers vos sauvegardes. En termes simples, l’article 11 vous impose de démontrer, une fois par an, que vous pouvez vous appuyer sur ces plans en cas de violation de sécurité ou de panne. Et lorsque vous activez ces plans, l’article 11, paragraphe 8, exige que vous disposiez de registres facilement accessibles détaillant les actions menées par votre équipe avant et pendant la perturbation.

Règlement délégué 2024/1774 : tests de basculement, accès aux plans et gestion des clés

Conformément aux normes techniques de la DORA (règlement délégué (UE) 2024/1774), article 25, un test de basculement n’est considéré comme réussi que si vos fonctions critiques ou importantes continuent de fonctionner pendant une période suffisante et que les opérations normales reprennent par la suite. Consignez les résultats et enregistrez tout problème survenant. Corrigez ensuite ces problèmes et signalez-les à votre conseil d’administration ou à la direction compétente.

Un autre article mérite d’être souligné : l’article 26, qui exige que votre personnel soit dûment habilité à suivre vos plans de reprise, les plans documentés devant être mis à la disposition du personnel chargé de leur exécution et facilement accessibles en cas d’urgence.

Il y a ensuite l’article 7, qui vous oblige à prévoir la sauvegarde et le remplacement de vos clés de chiffrement, car vous ne pouvez pas restaurer de sauvegardes chiffrées sans elles.

Article 16 de la directive DORA : cadre simplifié pour les petites entités

Conformément à l’article 16 de la directive DORA, certaines petites entreprises ne sont pas tenues de se conformer à l’article 12. Ce groupe comprend les petites entreprises d’investissement, les établissements de paiement et de monnaie électronique bénéficiant d’une dérogation, ainsi que les petits fonds de pension. Cela dit, ces entreprises doivent tout de même effectuer des sauvegardes de leurs données et tester leur restauration. En effet, les règles relatives aux tests sont plus précises en matière de fréquence.

En vertu de l’article 40 du règlement délégué, elles doivent tester leurs sauvegardes et leurs procédures de restauration au moins une fois par an, ou chaque fois qu’elles apportent une modification majeure à leur plan de continuité. L’article 12, en revanche, se contente d’indiquer « périodiquement ».

Comment Bacula facilite la mise en conformité avec l’article 12 de la loi DORA

Bacula Enterprise est une plateforme de sauvegarde et de restauration cyber-résiliente, à laquelle font confiance la NASA, l’armée de l’air américaine et la marine américaine. Elle vous fournit tous les outils nécessaires pour répondre aux exigences de l’article 12 de la loi DORA. Voici comment elle peut vous aider à vous conformer à cette disposition.

Article DORA	Exigence	Fonctionnalité Bacula	Votre tâche
12(1)(a)	Portée et fréquence des sauvegardes	Tâches, ensembles de fichiers, planifications	Classification des données
12(1)(b)	Procédures de restauration écrites	Catalogue, démarrage d’urgence, restauration complète	Rédaction du guide d’exploitation
12(2)	Activation sécurisée	Chiffrement, authentification multifactorielle (MFA), contrôle d’accès	Protection des clés
12(2)	Copies de sauvegarde protégées	Stockage immuable	Aligner la durée de conservation
12(2), 11(6)	Tests réguliers	Tâches de restauration, test d’indépendance de la restauration	Définir les critères de réussite
12(3)	Systèmes de restauration séparés	Récupération indépendante de Bacula	Mise en place du site de récupération
12(7)	Contrôles d’intégrité	Vérification des tâches	Rapprochement des données

Article 12(1)(a) : Tâches, ensembles de fichiers et plannings pour la politique de sauvegarde

L’article 12(1)(a) vous impose de rédiger une politique de sauvegarde qui précise quelles données vous sauvegardez et à quelle fréquence, en fonction de leur importance. Bacula vous permet de saisir ces deux paramètres directement dans le logiciel.

Vous pouvez répertorier les serveurs, bases de données et dossiers à sauvegarder dans un paramètre appelé ensemble de fichiers, et définir la fréquence de sauvegarde dans un paramètre appelé planification, par exemple toutes les heures pour les registres de paiement et une fois par jour pour les e-mails. Bacula exécute ensuite automatiquement chaque sauvegarde selon cette planification et consigne chaque exécution dans un rapport de tâche, ce qui vous fournit une preuve écrite que vos sauvegardes effectives respectent votre politique.

Article 12(1)(b) : Procédures de restauration à l’aide du catalogue, des fichiers de démarrage et de la restauration « bare-metal »

L’article 12(1)(b) exige la mise en place de procédures écrites détaillées, étape par étape, pour la restauration de vos systèmes et de vos données après une panne. Bacula met à votre disposition trois outils pour mettre en œuvre ces procédures : le catalogue, les fichiers de démarrage et la restauration « bare-metal ».

Tout d’abord, le catalogue est une base de données qui répertorie les éléments sauvegardés et l’emplacement de chaque copie ; Bacula recommande de le sauvegarder quotidiennement.
Le deuxième outil est constitué des fichiers de démarrage, qui indiquent précisément à Bacula où se trouve chaque sauvegarde et vous permettent de reconstruire le catalogue en cas de perte du serveur de sauvegarde lui-même.
Enfin, vous disposez de la restauration « bare-metal » pour Linux et Windows, qui permet de reconstruire de zéro un serveur défaillant, y compris son système d’exploitation, ses paramètres et ses données.

Article 12(2) : Chiffrement et contrôle d’accès pour des restaurations sécurisées

L’article 12(2) exige que l’activation de vos sauvegardes ne mette pas vos systèmes en danger et n’expose, ne modifie ni ne corrompe vos données. Pour vous aider à vous conformer à cette clause, Bacula chiffre les données de sauvegarde en transit et au repos, les rendant illisibles pour toute personne ne disposant pas de vos clés de chiffrement.

Il contrôle également qui peut effectuer une restauration et où les données restaurées peuvent être stockées, en utilisant vos comptes Active Directory ou LDAP existants, l’authentification à deux facteurs et des autorisations basées sur les rôles. Pendant la sauvegarde et la restauration, Bacula peut vérifier les fichiers par rapport à des signatures de logiciels malveillants connues, ce qui contribue à empêcher qu’un fichier infecté ne retourne en production. Cela dit, la sauvegarde et la protection des clés de chiffrement restent de votre responsabilité en vertu de l’article 7 du règlement délégué.

Article 12(2) : Stockage immuable pour les copies de sauvegarde

L’article 12(2) exige également que vos données de sauvegarde restent disponibles et inaltérées lorsque vous devez les restaurer. Bacula peut enregistrer les sauvegardes sur un stockage immuable, où vos sauvegardes ne peuvent être ni modifiées ni supprimées (jusqu’à l’expiration de la période de protection que vous avez définie).

Bacula prend en charge le stockage immuable sur des volumes de disque Linux, sur des systèmes NAS tels que NetApp SnapLock et Data Domain Retention Lock, sur des bandes WORM, ainsi que dans le cloud via Amazon S3 Object Lock et le stockage immuable Azure Blob. Le stockage immuable peut toutefois rester connecté à votre réseau et ne remplace pas les systèmes de restauration distincts exigés par l’article 12, paragraphe 3.

Articles 12, paragraphe 2, et 11, paragraphe 6 : Test d’indépendance de la restauration pour les essais de restauration

Les articles 12, paragraphe 2, et 11, paragraphe 6, exigent tous deux la réalisation de véritables tests de restauration, et la documentation de Bacula considère ces tests comme faisant partie intégrante du plan de restauration. Dans le cadre de la restauration indépendante, le test d’indépendance de la restauration vérifie que les systèmes critiques définis peuvent être restaurés en utilisant uniquement votre propre infrastructure, votre personnel, vos identifiants et vos sauvegardes isolées, sans aucune aide de la part de Bacula. C’est vous qui définissez le périmètre et les critères de réussite. Les résultats, les durées et les corrections apportées constituent alors les éléments que l’article 25 du règlement délégué vous demande de consigner.

Article 12, paragraphe 3 : Restauration indépendante Bacula pour une restauration isolée

Lorsque vous effectuez une restauration sur vos propres systèmes, l’article 12, paragraphe 3, exige que ces systèmes soient physiquement et logiquement séparés de l’environnement de production et protégés contre tout accès non autorisé. Bacula Independent Recovery restaure les systèmes critiques à partir de copies hors ligne stockées sur bande, sur des supports amovibles ou sur un périphérique de stockage déconnecté. Il peut fonctionner entièrement sur votre propre infrastructure, sans aucune connexion à Bacula ni à aucun service fournisseur, ce qui correspond à l’interprétation de la règle par l’EIOPA. De plus, vous recevez un kit de restauration autonome scellé contenant le logiciel, les paramètres, les clés de chiffrement et les instructions nécessaires pour tout reconstruire à partir de zéro.

Article 12(7) : Tâches de vérification de l’intégrité

L’article 12(7) vous impose de vérifier que vos données sont complètes et correctes après la reprise suite à un incident, notamment en les recoupant avec vos autres systèmes. Une tâche de vérification Bacula lit les données de sauvegarde à partir du stockage et confirme qu’elles sont intactes et qu’elles correspondent aux enregistrements de Bacula concernant ce qui a été sauvegardé.

Elle peut également comparer les fichiers d’un serveur à une sauvegarde antérieure et signaler ceux qui ont été modifiés de manière inattendue ; ces rapports sont particulièrement utiles lors des audits. Par ailleurs, veuillez noter qu’une tâche de vérification ne garantit pas le bon fonctionnement d’une application ni la concordance des soldes, et que vos équipes doivent toujours effectuer ces vérifications elles-mêmes.

FAQ sur l’article 12 de la loi DORA

Qu’est-ce que l’article 12 de la loi DORA ?

L’article 12 de la loi DORA est la section consacrée à la sauvegarde et à la restauration de la loi européenne sur la résilience opérationnelle numérique (Digital Operational Resilience Act). Il définit les modalités selon lesquelles les banques, les assureurs, les entreprises d’investissement et autres entités financières doivent sauvegarder leurs données, les restaurer et prouver que la restauration fonctionne. Il est en vigueur depuis le 17 janvier 2025.

Quelles sont les exigences en matière de sauvegarde fixées par l’article 12 de la DORA ?

L’article 12 définit cinq exigences fondamentales. Les entités financières doivent disposer d’une politique de sauvegarde écrite qui définit l’étendue des données et la fréquence minimale en fonction de leur criticité, documenter les procédures de restauration, activer les sauvegardes sans compromettre la sécurité, tester ces procédures périodiquement et effectuer la restauration sur des systèmes distincts de l’environnement de production. Les paragraphes 12(6) et 12(7) ajoutent des objectifs de délai et de point de restauration, ainsi que des contrôles d’intégrité après un incident.

La DORA exige-t-elle un système de restauration physiquement et logiquement isolé ?

Oui, lorsque vous restaurez des données de sauvegarde sur vos propres systèmes. L’article 12, paragraphe 3, exige que ces systèmes soient physiquement et logiquement séparés du système source et protégés contre tout accès non autorisé. L’EIOPA interprète cette disposition comme désignant des systèmes sous votre contrôle total qui ne sont pas directement connectés à l’environnement de production.

La DORA exige-t-elle que toutes les sauvegardes soient isolées physiquement (« air-gapped ») ?

Non. Ni le règlement DORA ni ses normes techniques n’utilisent le terme « isolation physique ». L’article 12, paragraphe 3, exige des systèmes de restauration distincts, et l’interprétation de l’EIOPA exclut uniquement une connexion directe à l’environnement de production. De nombreuses entreprises conservent encore des copies sur des bandes hors ligne ou des supports amovibles, car un pirate informatique ne peut pas y accéder, mais il s’agit d’un choix de conception et non d’une exigence légale.

À quelle fréquence les sauvegardes et les procédures de reprise doivent-elles être testées ?

Cela dépend de votre entreprise et de la réglementation applicable. L’article 12 se contente d’indiquer « périodiquement », mais l’article 11, paragraphe 6, exige de tester les plans de reprise au moins une fois par an et après toute modification majeure du système, y compris le basculement vers les sauvegardes, sauf pour les micro-entreprises. Les petites entreprises relevant du cadre simplifié doivent tester leurs sauvegardes et leurs procédures de restauration au moins une fois par an, conformément à l’article 40 du règlement délégué 2024/1774.

Bacula permet-il à une organisation d’être conforme à la directive DORA ?

Non. La directive DORA impose une obligation légale à l’entité financière, et la conformité dépend de vos propres politiques, tests et registres. Bacula Enterprise fournit les contrôles techniques sous-jacents à plusieurs exigences de l’article 12, allant des sauvegardes programmées et du chiffrement au stockage immuable, en passant par la vérification des tâches et la restauration à partir de copies isolées.

Vous pouvez également être intéressé par :

system de sauvegarde

solution de sauvegarde

sauvegarde cloud