Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
REL13-BP04 Gérer la dérive de configuration au niveau du site ou de la région de reprise après sinistre
Pour mener à bien une procédure de reprise après sinistre (DR), votre charge de travail doit être en mesure de reprendre son fonctionnement normal en temps opportun, sans aucune perte de fonctionnalité ni de données une fois que l’environnement de reprise après sinistre a été mis en ligne. Pour atteindre cet objectif, il est essentiel de maintenir une infrastructure, des données et des configurations cohérentes entre votre environnement de reprise après sinistre et l’environnement principal.
Résultat escompté : la configuration et les données de votre site de reprise après sinistre sont identiques à celles du site principal, ce qui permet une récupération rapide et complète au moment requis.
Anti-modèles courants :
-
Vous ne mettez pas à jour les emplacements de récupération lorsque des modifications sont apportées aux emplacements principaux, ce qui entraîne une obsolescence des configurations, susceptible d’entraver les efforts de récupération.
-
Vous ne tenez pas compte des limitations potentielles telles que les différences de service entre les emplacements principaux et de récupération, ce qui peut entraîner des échecs inattendus lors du basculement.
-
Vous vous appuyez sur des processus manuels pour mettre à jour et synchroniser l’environnement de reprise après sinistre, ce qui augmente le risque d’erreur humaine et d’incohérence.
-
Vous ne détectez pas une dérive de configuration et avez une fausse impression de l’état de préparation du site de reprise après sinistre avant un incident.
Avantages liés au respect de cette bonne pratique : la cohérence entre l’environnement de reprise après sinistre et l’environnement principal améliore considérablement les chances de réussite de la récupération après un incident et réduit le risque d’échec de la procédure de récupération.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Une approche globale de la gestion de la configuration et de la préparation au basculement peut vous aider à vérifier que le site de reprise après sinistre est régulièrement mis à jour et prêt à prendre le relais en cas de défaillance du site principal.
Pour garantir la cohérence entre votre environnement principal et votre environnement de reprise après sinistre (DR), assurez-vous que vos pipelines de distribution répartissent les applications à la fois sur votre site principal et sur votre site de reprise après sinistre. Déployez les modifications sur les sites de reprise après une période d’évaluation appropriée (on parle alors de déploiements échelonnés) afin de détecter les problèmes sur le site principal et d’arrêter le déploiement avant qu’ils ne se propagent. Mettez en œuvre une surveillance pour détecter les dérives de configuration et suivre les modifications et la conformité dans l’ensemble de vos environnements. Procédez à des corrections automatisées sur le site de reprise après sinistre pour qu’il reste totalement cohérent et prêt à prendre le relais en cas d’incident.
Étapes d’implémentation
-
Vérifiez que la région de reprise après sinistre contient les services et fonctionnalités AWS nécessaires à la bonne exécution de votre plan de reprise après sinistre.
-
Utilisez une infrastructure en tant que code (IaC). Maintenez l’exactitude de vos modèles de configuration de l’infrastructure de production et des applications, et appliquez-les régulièrement à votre environnement de reprise après sinistre. AWS CloudFormation
peut détecter des dérives entre ce que vos modèles CloudFormation spécifient et ce qui est réellement déployé. -
Configurez des pipelines CI/CD pour déployer des applications et des mises à jour d’infrastructure dans tous les environnements, y compris les sites principaux et de reprise après sinistre. Les solutions CI/CD telles qu’AWS CodePipeline
peuvent automatiser le processus de déploiement, ce qui réduit le risque de dérive de la configuration. -
Échelonnez les déploiements entre l’environnement principal et l’environnement de reprise après sinistre. Cette approche permet de déployer et de tester initialement les mises à jour dans l’environnement principal, ce qui permet d’isoler les problèmes sur le site principal avant qu’ils ne soient propagés au site de reprise après sinistre. Cette approche empêche la transmission simultanée des défauts en production et au site de reprise après sinistre et préserve l’intégrité de l’environnement de reprise après sinistre.
-
Surveillez en permanence les configurations des ressources dans l’environnement principal et l’environnement de reprise après sinistre. Des solutions telles qu’AWS Config
peuvent aider à renforcer la conformité des configurations et à détecter les dérives, ce qui permet de maintenir la cohérence des configurations dans tous les environnements. -
Mettez en œuvre des mécanismes d’alerte pour suivre et signaler toute dérive de configuration, ainsi que toute interruption ou tout retard de réplication des données.
-
Automatisez la correction des dérives de configuration détectées.
-
Planifiez des audits et des contrôles de conformité réguliers pour vérifier l’alignement continu entre les configurations principale et de reprise après sinistre. Les examens périodiques vous aident à maintenir la conformité aux règles définies et à identifier les éventuelles anomalies à corriger.
-
Recherchez des disparités au niveau de la capacité provisionnée, des quotas de service, des limitations et des différences de configuration et de version AWS.
Ressources
Bonnes pratiques associées :
Documents connexes :
-
Correction des ressources AWS non conformes par AWS Config Rules
-
AWS CloudFormation : détection de tout écart à l’échelle d’une pile CloudFormation
-
Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)
-
Comment mettre en œuvre une solution de gestion de configuration d’infrastructure sur AWS ?
-
Correction des ressources AWS non conformes par AWS Config Rules
Vidéos connexes :
Exemples connexes :