Organiser la restauration
Le résultat est partagé avec le propriétaire métier, qui confirme données, accès et parcours. Les mesures servent à ajuster le RTO, le RPO et la capacité de récupération.
Ajoutez une vérification de sécurité avant la remise en service. Confirmez que les comptes, clés et endpoints restaurés correspondent à l’environnement attendu, puis communiquez le résultat au support.
Le propriétaire métier confirme que les données restaurées répondent au besoin. Le technicien vérifie intégrité, permissions et dépendances. Conservez la durée observée et la perte éventuelle pour réviser le RTO et le RPO.
Vérifier les dépendances
Une restauration doit inclure schéma, certificats, identités, fichiers et paramètres nécessaires. Testez le parcours métier après récupération, puis retirez les ressources temporaires et les accès de secours.
Valider après récupération
Comparez volumes, clés, permissions et parcours métier après restauration. Retirez les ressources temporaires, les identités de test et les accès de secours. Conservez le temps mesuré et les écarts dans le runbook.
Contrôler les accès après exercice
Une restauration peut créer des ressources et des identifiants temporaires. Retirez-les après le test, vérifiez les journaux et confirmez que la copie n’est pas devenue publique. Notez les écarts dans le runbook et attribuez une correction.
Comparez le résultat aux objectifs métier. Une sauvegarde peut être techniquement complète tout en nécessitant trop de temps pour une activité critique. Le propriétaire choisit alors entre meilleure fréquence, capacité de restauration ou réponse dégradée.
Une copie immuable peut répondre à plusieurs scénarios, mais chaque scénario demande une procédure. Pour une suppression accidentelle, restaurez les données dans un espace séparé et comparez volumes, clés et permissions. Pour une compromission, vérifiez aussi images, secrets et comptes avant de rouvrir le trafic.
Séparez les droits de produire une sauvegarde, de la restaurer et de modifier sa protection. Testez l’identité de secours dans un environnement isolé. Notez le temps d’accès à la copie, le temps de reconstruction et les validations métier nécessaires.
La rétention doit tenir compte versions, snapshots, réplications et archives. Une suppression automatique ne doit pas effacer le seul point nécessaire à une enquête. Les coûts doivent être reliés à l’application et au niveau de reprise attendu.
Après chaque test, retirez les accès temporaires et les ressources restaurées. Gardez les preuves, les mesures et les actions restantes dans le ticket d’exercice.
Une sauvegarde immuable ne peut pas être modifiée ou supprimée pendant une période définie. Elle réduit l’effet d’une erreur ou d’un compte compromis, mais elle doit rester restaurable et accessible aux personnes responsables.
Choisir la période
Reliez la durée d’immuabilité aux besoins de reprise et aux règles de conservation. Une période trop courte laisse une fenêtre de risque ; une période trop longue augmente le coût et complique la purge autorisée.
Séparer les accès
Le compte qui produit une sauvegarde ne devrait pas pouvoir supprimer toutes les copies. Séparez écriture, restauration et administration. Protégez la clé de chiffrement et testez l’accès de secours.
Restaurer régulièrement
Une copie protégée peut être inutilisable si son format, sa clé ou ses permissions sont inconnus. Restaurez un échantillon dans un compte isolé. Le RTO/RPO doit s’appuyer sur une durée mesurée.
Sources : AWS S3 Object Lock, NIST backup guidance.
Choisir le niveau d’isolement
Une copie immuable dans le même compte protège contre certaines erreurs, mais un compte compromis peut encore empêcher sa restauration. Une copie dans un compte ou une région séparée ajoute une barrière. Comparez cette protection avec le coût, le délai de récupération et les compétences disponibles.
L’isolement doit couvrir les clés, les rôles et les procédures. Si le même administrateur peut désactiver la protection et supprimer la clé, l’immuabilité ne couvre pas le scénario principal. Utilisez une identité de secours et une validation pour les actions exceptionnelles.
Vérifier la chaîne de sauvegarde
Contrôlez la création, le chiffrement, la réplication, la rétention et la restauration. Une sauvegarde partielle peut être signalée comme réussie si le job ne vérifie pas toutes les tables ou tous les fichiers. Ajoutez un contrôle de volume et d’intégrité adapté à votre application.
Les sauvegardes doivent garder la version du schéma et les paramètres nécessaires. Un fichier seul ne suffit pas si l’application dépend d’une base, d’un certificat ou d’un mapping d’identité. Le runbook de reprise doit citer ces dépendances.
Tester un scénario de compromission
Dans un environnement de test, simulez la perte du compte de production et l’accès limité à la copie. Vérifiez qui peut demander une restauration, qui la valide et où le service est reconstruit. Mesurez le délai entre détection et première donnée disponible.
Après le test, retirez les accès temporaires et vérifiez les journaux. Une sauvegarde immuable protège les données, mais elle ne corrige pas une application vulnérable. Le pipeline, les images et les secrets demandent leurs propres contrôles.