Sauvegardes et plan de reprise d’une application métier : RPO, RTO, 3-2-1

Une application métier est protégée lorsque l’entreprise sait répondre à deux questions : combien de données peut-elle se permettre de perdre (le RPO), et combien de temps peut-elle rester sans l’application (le RTO) ? Une fois ces objectifs fixés par le métier, la stratégie suit des règles éprouvées : la règle 3-2-1 recommandée par l’ANSSI (trois copies, deux supports, une copie hors ligne), des sauvegardes isolées du reste du système, des restaurations testées régulièrement et un plan de reprise écrit. Une sauvegarde jamais restaurée n’est qu’une hypothèse.

RPO et RTO : les deux chiffres qui dimensionnent tout

Le RPO (recovery point objective), que l’ANSSI appelle perte de données maximale admissible (PDMA), est la quantité de données que l’on accepte de perdre, exprimée en durée : avec un RPO de 24 heures, on accepte de ressaisir une journée de travail. Le RTO (recovery time objective), ou durée maximale d’interruption admissible (DMIA), est le délai dans lequel l’application doit être de nouveau utilisable.

Ces deux chiffres ne sont pas des choix techniques : ce sont des décisions de gestion, qui engagent un coût. Plus ils sont courts, plus l’architecture est complexe. Le guide de l’ANSSI rappelle d’ailleurs qu’une sauvegarde classique ne couvre pas un besoin de PDMA inférieur à 24 heures : il faut alors recourir à la réplication.

Faites l’exercice avec les responsables métier, application par application : c’est souvent la première fois qu’ils mettent un chiffre sur l’arrêt d’un outil qu’ils utilisent tous les jours.

Que faut-il sauvegarder dans une application métier ?

Sauvegarder « la base de données » ne suffit pas. Pour remettre une application en service, il faut pouvoir reconstruire l’ensemble :

• La base de données, idéalement avec une restauration à un instant précis (point-in-time recovery), pour revenir à la minute qui précède une erreur.
• Les fichiers déposés par les utilisateurs (pièces jointes, photos, documents), souvent stockés à part, avec un historique des versions.
• Le code source et l’infrastructure décrite sous forme de code, pour redéployer à l’identique dans un autre environnement.
• La configuration et les secrets (paramètres, clés d’API), stockés dans un coffre dédié et sauvegardés séparément.
• Les clés de chiffrement des sauvegardes, conservées hors de l’infrastructure qu’elles protègent : une sauvegarde chiffrée dont on a perdu la clé est perdue.
• Les données détenues par les services tiers (CRM en ligne, outil de facturation) quand l’application en dépend.

L’ANSSI insiste sur un point souvent oublié : sauvegarder aussi les médias d’installation, les configurations des applications métier et l’infrastructure de sauvegarde elle-même (catalogue, procédures d’import, liste du matériel nécessaire).

La règle 3-2-1, appliquée à une application web

Le guide de l’ANSSI « Sauvegarde des systèmes d’information : les fondamentaux » recommande la règle 3-2-1 : trois copies distinctes des données, c’est-à-dire les données de production et deux sauvegardes, stockées sur des supports différents, dont une hors ligne. Il juge indispensable cette copie hors ligne (ou au moins hors site en ligne sous certaines conditions), même si elle est moins fréquente que les sauvegardes locales.

Pour une application hébergée dans le cloud, cela se traduit souvent ainsi :

1. Copie 1 : la base de production et ses sauvegardes automatiques chez l’hébergeur, pour les restaurations rapides du quotidien.
2. Copie 2 : une sauvegarde exportée vers un autre fournisseur ou une autre région, avec des identifiants distincts de ceux de la production.
3. Copie 3 : une copie hors ligne ou immuable, c’est-à-dire verrouillée en écriture pendant sa durée de conservation, que même un administrateur compromis ne peut ni modifier ni supprimer.

La séparation des accès est aussi importante que la séparation physique. Si le même compte peut supprimer la production et toutes ses sauvegardes, un seul mot de passe volé suffit à tout perdre. L’ANSSI recommande des comptes d’administration nominatifs et dédiés à la sauvegarde, et le cloisonnement de l’infrastructure de sauvegarde.

Réplication, sauvegarde, plan de reprise : quelle différence ?

Une réplication recopie les données en continu vers un second serveur ou une seconde région. Elle réduit fortement la perte de données en cas de panne matérielle, mais elle recopie aussi fidèlement les erreurs : une table supprimée par erreur, des données corrompues ou chiffrées par un rançongiciel. Le livre blanc d’AWS sur la reprise après sinistre le souligne : la réplication continue ne protège pas aussi bien contre la corruption ou la suppression malveillante que des sauvegardes datées. Il faut les deux.

Le plan de reprise d’activité (PRA) est le document et le dispositif qui permettent de redémarrer. Le même livre blanc décrit quatre stratégies, de la plus simple à la plus coûteuse :

Quelle que soit la stratégie, les sauvegardes datées restent nécessaires : même un dispositif actif/actif ne protège pas contre une donnée corrompue répliquée partout.

Pourquoi une sauvegarde non testée ne vaut rien

En janvier 2017, une erreur de manipulation a supprimé la base de données de production de GitLab.com. Le compte rendu publié par l’entreprise est devenu un cas d’école : sur cinq techniques de sauvegarde et de réplication en place, aucune ne fonctionnait de façon fiable ou n’était réellement configurée. Six heures de données ont été perdues, et le service a été restauré à partir d’une copie vieille de six heures.

En mars 2021, l’incendie d’un centre de données d’OVHcloud à Strasbourg a rappelé l’importance de l’éloignement géographique. Dans l’un des litiges qui ont suivi, le tribunal de commerce de Lille a jugé, selon IT-Connect, que les sauvegardes d’un client étaient stockées dans le même centre de données que ses serveurs, alors que le contrat prévoyait un emplacement physique différent.

La leçon est la même : on ne sait qu’une sauvegarde fonctionne qu’après l’avoir restaurée. L’ANSSI demande que les sauvegardes soient testées régulièrement et qu’une procédure de restauration soit rédigée et mise en œuvre. En pratique :

• une restauration automatique de la dernière sauvegarde sur un environnement isolé, avec des contrôles (nombre d’enregistrements, dernière date de mise à jour), chaque semaine ou chaque jour ;
• un exercice complet de reprise au moins une fois par an, chronométré, pour mesurer le RTO réel et non le RTO espéré ;
• une alerte quand une sauvegarde échoue, est anormalement petite ou n’a pas tourné.

Et en cas de rançongiciel ?

Le scénario de l’attaque change la nature du plan. Les attaquants cherchent d’abord à atteindre les sauvegardes en ligne, puis chiffrent la production. Le guide de l’ANSSI en tire plusieurs recommandations :

• Prévoir un « bouton rouge » pour isoler immédiatement l’infrastructure de sauvegarde du reste du système dès qu’une attaque est détectée.
• Définir un ordre de restauration qui tient compte des dépendances (annuaire, DNS, base de données, puis applications) et de la criticité de chaque application.
• Se méfier des sauvegardes elles-mêmes : elles peuvent contenir des portes dérobées installées par l’attaquant avant le chiffrement. On réinstalle les systèmes à partir d’images de confiance et l’on restaure les données de façon sélective.

Le site Cybermalveillance.gouv.fr propose des fiches de bonnes pratiques accessibles pour sensibiliser les équipes. Pour les entreprises concernées par NIS2, la gestion des sauvegardes et de la reprise fait partie des mesures attendues, comme nous l’expliquons dans notre article sur NIS2.

Ce que le contrat avec votre prestataire doit préciser

Quand une agence développe et maintient votre application, et qu’un hébergeur l’exploite, la question « qui sauvegarde quoi ? » doit avoir une réponse écrite. Le contrat de maintenance ou d’hébergement précise :

1. les objectifs de RPO et de RTO, application par application ;
2. ce qui est sauvegardé, à quelle fréquence, où (pays, fournisseur, région) et pendant combien de temps ;
3. la copie hors ligne ou immuable, et qui y a accès ;
4. la fréquence des tests de restauration et la remise d’un compte rendu ;
5. la procédure de reprise, tenue à jour, et les contacts d’astreinte ;
6. la restitution des sauvegardes en fin de contrat, un point de réversibilité souvent oublié.

Le choix de l’hébergement lui-même (cloud public, cloud souverain, hébergeur certifié) conditionne une partie de ces réponses ; nous le détaillons dans notre guide de l’hébergement d’une application métier.

La checklist en dix points

1. RPO et RTO fixés par le métier pour chaque application.
2. Inventaire de tout ce qu’il faut pour reconstruire : données, fichiers, code, configuration, secrets, clés.
3. Règle 3-2-1 appliquée, avec une copie hors ligne ou immuable.
4. Comptes d’administration des sauvegardes dédiés et distincts de ceux de la production.
5. Sauvegardes chiffrées, clés conservées à part.
6. Alertes sur les échecs et les anomalies de volume.
7. Restauration automatique testée régulièrement.
8. Exercice complet de reprise au moins une fois par an, chronométré.
9. Procédure de reprise écrite, avec l’ordre de restauration et le « bouton rouge ».
10. Responsabilités et engagements inscrits au contrat.

Toutes les applications que nous développons sont livrées avec une stratégie de sauvegarde et une procédure de reprise documentées et testées. Si vous voulez faire le point sur la protection d’une application existante, contactez-nous.