La sauvegarde qui doit être là quand vous en avez besoin.
ISO 27001:2022 A.8.13 (sauvegarde de l'information) est le contrôle pour la récupérabilité : pouvoir restaurer les informations, logiciels et systèmes après une perte, une corruption ou une modification erronée. En pratique, cela revient à déterminer ce qui doit être sauvegardé, à maintenir des sauvegardes, à protéger ces copies et à tester effectivement une restauration pour s'assurer que la récupération fonctionne. La récupérabilité est de plus en plus provisionnée dans le code : une durée de conservation sur une base de données gérée, une planification de snapshots, une politique de cycle de vie. Ce qui signifie que c'est une décision prise dans une pull request, et qu'elle peut être désactivée en une seule ligne.
The shapes the same control failure takes.
A.8.13 ne se brise rarement parce que quelqu'un supprime les sauvegardes. Il se brise lorsqu'un changement supprime discrètement la capacité de récupération. Les formes récurrentes :
Les sauvegardes automatiques sont désactivées
Une période de conservation est définie à zéro, ou une tâche de snapshot ou de sauvegarde planifiée est supprimée, de sorte qu'un stockage qui était auparavant récupérable n'a plus de point de restauration récent.
La durée de conservation est inférieure à la fenêtre de récupération
La durée de conservation d'une sauvegarde est réduite (trente jours devient un jour) au point qu'elle ne couvre plus la durée pendant laquelle un incident peut passer inaperçu avant de nécessiter une restauration.
Un nouveau stockage est déployé sans sauvegarde
Une base de données, un bucket ou un volume contenant des données réelles est provisionné sans aucune sauvegarde configurée, de sorte qu'il n'y a rien à restaurer en cas de perte.
La restauration n'est jamais vérifiée
Une étape qui testait ou vérifiait une restauration est supprimée, de sorte que les sauvegardes continuent d'être écrites, mais personne ne sait si elles peuvent effectivement être récupérées, ce que A.8.13 attend que vous testiez.
Une sauvegarde est laissée non protégée
Un snapshot ou une sauvegarde est rendu public, non chiffré ou partagé trop largement, de sorte que la copie de sauvegarde elle-même devient l'exposition qu'elle était censée protéger.
Sauvegardes automatiques désactivées sur la base de données principale.
Une équipe souhaite arrêter de payer pour le stockage des sauvegardes automatiques sur une base Postgres gérée en pré-lancement, donc une modification définit la période de conservation à zéro. L'instance n'a désormais plus de sauvegardes automatiques ni de récupération à un instant donné à partir de celles-ci. Si des données sont perdues ou corrompues, la récupération dépend de ce qui existe par ailleurs (un snapshot manuel, un outil de sauvegarde séparé), et souvent il n'y a rien d'autre.
resource "aws_db_instance" "primary" { engine = "postgres"- backup_retention_period = 7+ backup_retention_period = 0 # disables automated backups}Définir la période de conservation à zéro désactive les sauvegardes automatiques et la récupération à un instant donné sur la base de données principale, de sorte qu'une perte ou une corruption n'aurait aucun point de restauration automatique récent. A.8.13 (sauvegarde de l'information) concerne la capacité de récupération, et il attend que les sauvegardes soient conservées et testées. Maintenez une période de conservation qui couvre vos besoins de récupération (ou déplacez les sauvegardes vers un outil dédié), plutôt que de les désactiver pour économiser du stockage.
La sauvegarde est vérifiée par rapport à la capacité réelle de restauration.
Un auditeur ne prend pas pour argent comptant l'affirmation 'nous avons des sauvegardes' ; il vérifie si des sauvegardes existent pour les systèmes importants, sont conservées pendant la durée indiquée dans votre politique, sont protégées, et, surtout, ont été testées par une restauration effective. Un stockage avec des sauvegardes désactivées, une durée de conservation réduite en dessous de la fenêtre de récupération, ou une nouvelle base de données déployée sans sauvegarde est le type de lacune qui devient un constat, et il est généralement arrivé dans une seule modification de la configuration de l'infrastructure. Le diff est l'endroit le moins coûteux pour le détecter.
Une revue, pas votre système de sauvegarde.
heygrc signale les modifications qui concernent A.8.13 et cite le contrôle afin que la correction ait lieu dans la pull request. Il n'exécute pas vos sauvegardes ni ne teste vos restaurations. Il détecte le moment où une modification supprime ou affaiblit la capacité d'un stockage à être récupéré, au niveau du diff.