Une sauvegarde cloud qui existe mais qu’on ne peut pas restaurer en conditions réelles ne protège rien. Le sujet a basculé : la copie distante n’est plus le point d’arrivée d’une politique de protection des données, c’est le maillon que les attaquants ciblent en priorité.
Quand un ransomware chiffre l’environnement de production, la première action de l’opérateur malveillant consiste à localiser et détruire les sauvegardes accessibles depuis le même périmètre d’identité. Les entreprises qui n’ont pas isolé leurs copies découvrent alors que leur filet de sécurité a disparu en même temps que leurs systèmes.
A lire aussi : Les smartphones professionnels nécessitent des solutions de sécurité dédiées
Isolation logique des sauvegardes cloud : le critère que les audits négligent
La majorité des fournisseurs cloud proposent un mécanisme natif de sauvegarde. Le piège est de considérer cette copie comme indépendante de l’infrastructure qu’elle protège. Un compte administrateur compromis donne accès aux snapshots, aux buckets de rétention et aux politiques de cycle de vie. Supprimer ou chiffrer ces copies prend quelques minutes à un attaquant disposant de privilèges élevés.
Une sauvegarde doit survivre à la compromission du compte cloud principal. Cela suppose un cloisonnement réel : compte de stockage distinct, authentification séparée, règles d’accès qui ne dépendent pas de l’annuaire de production. Nous observons encore trop d’architectures où le même jeu de credentials protège à la fois l’environnement actif et ses copies de secours.
A lire également : Comment accéder à webmail edf à distance en respectant les règles de sécurité ?
Le terme « air-gapped » revient souvent dans les guides récents. Appliqué au cloud, il désigne une copie immuable, stockée dans un espace dont les droits d’écriture et de suppression sont verrouillés, y compris pour le propriétaire du compte, pendant une durée définie. Ce verrouillage temporel (object lock, retention policy selon les services) empêche toute altération, même en cas d’accès root.
Règle 3-2-1 et ses variantes : pourquoi la version classique ne suffit plus
La règle 3-2-1 (trois copies, deux supports différents, une copie hors site) reste un socle, mais elle ne dit rien sur la résistance au chiffrement malveillant. Disposer d’une copie hors site sur un NAS accessible via VPN ne change pas grand-chose si le ransomware peut traverser ce lien.
Les retours de pratique récents poussent vers une variante plus exigeante : au moins une copie immutable ou air-gapped par jeu de données critique. Concrètement, cela signifie que la politique de rétention bloque toute modification pendant une fenêtre incompressible. Ni un administrateur, ni un script automatisé, ni un attaquant ayant escaladé ses privilèges ne peut raccourcir ce délai.
Nous recommandons de documenter la variante retenue dans la politique de sauvegarde et de la soumettre à un test contradictoire : un opérateur interne tente de supprimer la copie immutable avec les droits les plus élevés dont il dispose. Si la suppression réussit, le dispositif est insuffisant.
Capacité de restauration : tester le rétablissement, pas seulement la copie
La distinction entre « copie stockée » et « capacité réelle de remise en service » est le point aveugle de nombreuses entreprises. Un fichier compressé déposé chaque nuit sur un bucket distant satisfait l’obligation de sauvegarde sur le papier. En pratique, il faut vérifier :
- Que la restauration complète fonctionne sur un environnement cible propre, sans dépendance à l’infrastructure compromise.
- Que le temps de restauration (RTO) reste compatible avec les engagements métier, surtout quand la bande passante Internet est le seul canal de récupération.
- Que les données restaurées sont cohérentes (intégrité des bases, pas de corruption silencieuse accumulée sur plusieurs cycles de sauvegarde).
Un test de restauration intégré au calendrier opérationnel vaut plus qu’un doublement du volume de copies. Certains référentiels préconisent un test trimestriel. Pour les systèmes critiques (santé, finance, services publics), un rythme mensuel avec un scénario de perte totale est plus réaliste.
Nous constatons que les organisations qui documentent et planifient ces tests détectent des défauts (fichiers manquants, scripts de restauration obsolètes, incompatibilité de version) bien avant un incident réel. Celles qui ne testent jamais découvrent ces problèmes le jour de la crise.
La dépendance au lien réseau, un risque sous-estimé
Une stratégie de sauvegarde entièrement cloud suppose que la récupération transite par Internet. En cas de panne de connectivité locale, les données sont intactes mais inaccessibles. Pour une PME mono-site, cela peut signifier un arrêt complet d’activité même sans cyberattaque.
Prévoir un chemin de restauration alternatif (copie locale chiffrée, lien réseau de secours, livraison physique d’un support par le fournisseur) réduit ce risque. Le coût de cette redondance est marginal comparé à une journée d’indisponibilité opérationnelle.
Responsabilité partagée et gestion des fournisseurs cloud
Le modèle de responsabilité partagée est souvent mal compris. Le fournisseur cloud garantit la disponibilité de l’infrastructure et la durabilité du stockage objet. La protection contre la suppression accidentelle, le chiffrement applicatif et la gestion des accès restent à la charge du client.
En matière de sauvegarde, cela implique que la perte de données due à une mauvaise configuration est la responsabilité de l’entreprise, pas du fournisseur. Les contrats des principaux hyperscalers le stipulent explicitement. Déléguer la sauvegarde à un service managé ne dispense pas de vérifier ce que couvre réellement le SLA :
- Le RPO (point de récupération) garanti par le fournisseur correspond-il aux besoins métier ?
- La rétention minimale est-elle suffisante pour détecter une compromission lente (exfiltration, corruption progressive) ?
- Le fournisseur permet-il l’export des sauvegardes vers un environnement tiers pour éviter le verrouillage technologique ?
- Les données sauvegardées sont-elles soumises à un chiffrement côté client avant transfert, ou uniquement côté serveur ?
Ces questions ne relèvent pas de la paranoïa. Elles font partie de la gestion normale du risque pour toute entreprise dont l’activité dépend de ses systèmes d’information.
Conformité et souveraineté des sauvegardes cloud
Les exigences réglementaires renforcent la pression. Les entreprises opérant dans la santé ou manipulant des données sensibles doivent souvent démontrer que leurs sauvegardes respectent des critères de localisation géographique et de contrôle d’accès. Stocker une copie de secours hors juridiction sans évaluation d’impact est un risque réglementaire direct.
Le choix d’un fournisseur qualifié (type SecNumCloud pour les acteurs français) répond en partie à cette contrainte, mais ne couvre pas tout. La qualification porte sur l’infrastructure, pas sur la manière dont l’entreprise configure ses politiques de sauvegarde, de chiffrement ou de rétention.
L’enjeu de sécurité des sauvegardes cloud ne se résout pas par un choix d’outil. Il se traite par une architecture pensée pour résister à la perte de contrôle du périmètre principal, des tests réguliers de restauration, et une lecture attentive de ce que le fournisseur garantit réellement. Le reste est de la documentation marketing.
