2 Qu’est-ce qu’un plan de reprise d’activité dans le cloud ? Un plan de reprise d’activité (PRA) dans le cloud est un processus documenté pour restaurer les applications, l’infrastructure et les données à l’aide de ressources cloud après une panne ou un autre événement perturbateur. Selon l’architecture, le cloud peut servir de : Environnement de production principal, avec reprise dans une autre région ou un autre cloud Environnement de reprise après sinistre pour une infrastructure sur site Site secondaire pour des applications et données répliquées Destination de sauvegarde pour les données nécessaires à la reprise Composante d’une architecture de reprise après sinistre hybride La conception appropriée dépend largement des exigences métier, des dépendances applicatives et de deux objectifs de reprise importants : l’objectif de délai de reprise (RTO) et l’objectif de point de reprise (RPO). Le RTO définit la durée maximale acceptable pour restaurer un service après une interruption. Le RPO définit la perte de données maximale acceptable, exprimée en durée. Par exemple, une application dont le RTO est de quatre heures doit être opérationnelle dans les quatre heures suivant la déclaration d’un sinistre. Un RPO de 15 minutes signifie que la stratégie de reprise doit limiter la perte de données potentielle à environ 15 minutes. Ces objectifs influent sur tout, de la fréquence des sauvegardes et de la réplication aux coûts d’infrastructure et à l’automatisation. Exemple de plan de reprise d’activité dans le cloud Prenons une entreprise fictive qui exploite une application destinée aux clients en combinant infrastructure sur site et services cloud. Son environnement comprend : Des applications web destinées aux clients Des serveurs d’applications Des bases de données de production Des données fichier et objet Des services d’identité et d’accès Des services DNS et réseau Une infrastructure de sauvegarde Des ressources de calcul et de stockage cloud L’organisation veut conserver l’accès à ses services les plus importants si son infrastructure principale devient indisponible. Son plan de reprise d’activité pourrait ressembler à ce qui suit. 1. Définir le périmètre Objectif du plan : restaurer les services clients critiques et les données associées après une panne majeure d’infrastructure, une cyberattaque ou une interruption de service régionale. Systèmes couverts : SystèmePrioritéRTORPOIdentité et authentificationCritique30 minutes15 minutesApplication clientCritique1 heure15 minutesBase de données de productionCritique1 heure15 minutesDonnées objet et fichierCritique2 heures1 heureReporting interneMoyenne8 heures4 heuresSystèmes de développementFaible24 heures24 heures Ces chiffres sont des exemples et non des recommandations universelles. Les organisations doivent déterminer leurs exigences de RTO et de RPO au moyen d’une analyse d’impact sur l’activité et d’échanges avec les responsables d’applications. 2. Identifier les dépendances Les applications se rétablissent rarement de manière indépendante. Dans cet exemple, l’application client dépend : De la connectivité réseau Du DNS Des services d’identité Des services de base de données Du stockage objet ou fichier Des ressources de calcul applicatives Des contrôles de sécurité De la supervision Le plan de reprise doit documenter ces relations afin que les équipes ne tentent pas de restaurer une application avant que les services dont elle a besoin soient disponibles. Une cartographie des dépendances peut aussi révéler des points de défaillance uniques qui resteraient autrement invisibles en fonctionnement normal. 3. Définir l’architecture de reprise après sinistre L’entreprise maintient des ressources de reprise dans une région cloud secondaire. Les données critiques sont protégées par une combinaison de réplication et de sauvegardes. Les configurations d’infrastructure sont maintenues sous forme de modèles d’infrastructure as code, afin que les ressources cloud nécessaires puissent être recréées de manière cohérente. L’environnement de reprise comprend : Une capacité de calcul secondaire Des bases de données répliquées Des données objet et fichier protégées Des copies de sauvegarde isolées de la production Des configurations réseau et de sécurité Des capacités de bascule DNS Des modèles de déploiement d’infrastructure La supervision et la journalisation Toutes les ressources n’ont pas besoin de fonctionner en permanence. Les organisations peuvent choisir différentes approches de reprise selon l’importance de chaque charge de travail. Sauvegarde et restauration Les applications et les données sont restaurées à partir des sauvegardes après un sinistre. Cette approche peut réduire les coûts d’infrastructure de secours, mais exige généralement plus de temps de reprise. Pilot light Les services essentiels et les données restent disponibles dans l’environnement de reprise, tandis que l’infrastructure supplémentaire est démarrée lorsque la reprise est nécessaire. Warm standby Une version à capacité réduite de l’environnement de production fonctionne en permanence et peut monter en charge lors de la bascule. Actif-actif Les applications fonctionnent simultanément sur plusieurs sites, ce qui permet de déplacer le trafic d’un environnement à l’autre en cas de panne. Des objectifs de RTO et de RPO plus bas exigent généralement davantage d’investissement d’infrastructure, d’automatisation et de complexité opérationnelle. 4. Protéger les données de reprise Un plan de reprise d’activité dans le cloud dépend de la disponibilité de données de reprise exploitables. Les copies de sauvegarde doivent donc être protégées séparément des systèmes de production chaque fois que possible. Si un attaquant peut modifier ou supprimer les données de production et leurs sauvegardes avec les mêmes identifiants ou le même chemin d’administration, l’organisation risque de disposer de peu d’options de reprise. L’organisation de l’exemple utilise plusieurs couches de protection : Des sauvegardes régulières Une séparation géographique L’immuabilité des objets Un accès d’administration restreint Des identifiants et domaines de sécurité séparés lorsque c’est pertinent Le chiffrement La supervision des sauvegardes Des tests de restauration périodiques Le stockage immuable peut être particulièrement important pour la cyber-résilience, car les objets protégés ne peuvent être ni modifiés ni supprimés pendant la période de conservation configurée. Cela offre une option de reprise supplémentaire lorsque les données de production ont été chiffrées, corrompues ou supprimées intentionnellement. 5. Fixer les critères de déclaration d’un sinistre Les équipes doivent savoir à quel moment un incident devient un événement de reprise après sinistre. Les critères d’activation pourraient par exemple inclure : L’infrastructure principale devrait rester indisponible au-delà du RTO Une région cloud subit une panne importante Les données de production ont été corrompues Un ransomware touche des systèmes critiques L’infrastructure de sauvegarde ou de stockage a été compromise Une panne réseau majeure empêche l’accès aux services de production L’infrastructure physique est indisponible à la suite d’un incident sur site Le plan doit désigner qui a autorité pour déclarer un sinistre et lancer la bascule. Dans cet exemple, le responsable de l’incident évalue la situation avec les équipes infrastructure, applications et sécurité avant d’activer le processus de reprise. 6. Attribuer les rôles de reprise après sinistre Un plan de reprise doit attribuer les responsabilités avant qu’un incident ne survienne. RôleResponsabilitéResponsable de l’incidentCoordonne la reprise et prend les décisions d’activationResponsable infrastructureRestaure le calcul, le réseau et l’infrastructure cloudResponsable stockage/sauvegardeValide et restaure les données protégéesResponsable d’applicationVérifie le bon fonctionnement de l’applicationResponsable sécuritéDétermine si les systèmes et données restaurés sont sûrsResponsable communicationCoordonne les communications internes et externesSponsor exécutifPrend les décisions au niveau métier et assure l’escalade Des suppléants doivent aussi être désignés pour les rôles critiques. Un sinistre peut survenir en dehors des heures ouvrées, pendant les vacances ou lorsque certains membres de l’équipe sont indisponibles. 7. Suivre la séquence de reprise Une fois le sinistre déclaré, l’organisation lance son runbook de reprise documenté. Étape 1 : évaluer l’incident Déterminez : Quels systèmes sont touchés ? Le problème est-il opérationnel ou lié à la sécurité ? Les données de production sont-elles fiables ? Les systèmes de sauvegarde sont-ils touchés ? L’environnement principal peut-il être rétabli dans le RTO requis ? En cas d’incident cyber, les équipes peuvent devoir isoler les systèmes compromis avant de commencer la reprise. Étape 2 : choisir un point de reprise Identifiez le point de reprise vérifié le plus récent qui respecte le RPO requis. Pour une panne d’infrastructure classique, il peut s’agir simplement de la dernière copie synchronisée. Après un ransomware ou une corruption de données, l’organisation peut choisir délibérément un point de reprise antérieur à la compromission. Étape 3 : activer l’infrastructure de reprise Provisionnez ou faites monter en charge l’environnement cloud secondaire. L’automatisation peut accélérer cette étape en créant des ressources prédéfinies de calcul, de réseau, de stockage et de sécurité, plutôt que d’obliger les administrateurs à les configurer manuellement pendant un incident. Étape 4 : restaurer les données Restaurez ou connectez les bases de données, le stockage objet, les systèmes de fichiers et les données applicatives nécessaires. Validez : L’intégrité des données Le nombre attendu d’objets ou de fichiers La cohérence des bases de données Les autorisations Le chiffrement L’accès des applications Étape 5 : restaurer les applications Les applications doivent être restaurées selon leurs dépendances documentées et leur priorité de reprise. Les services fondamentaux comme le réseau, le DNS, l’identité et le stockage peuvent devoir être opérationnels avant que les applications destinées aux clients puissent fonctionner correctement. Étape 6 : valider l’environnement restauré Avant de rediriger les utilisateurs, testez l’environnement. La validation peut inclure : L’authentification La connectivité aux bases de données Les opérations de lecture et d’écriture Les API applicatives L’accès au stockage Les contrôles de sécurité La supervision La journalisation Les performances La reprise ne doit être considérée comme terminée que lorsque le service fonctionne et que les données restaurées ont été validées. Étape 7 : rediriger le trafic de production Mettez à jour le DNS, les répartiteurs de charge ou les politiques de routage pour envoyer le trafic de production vers l’environnement de reprise. Continuez à superviser l’environnement à mesure que le trafic revient. Étape 8 : communiquer l’état de la reprise Informez les parties prenantes sur : Les services touchés L’état actuel de la reprise La disponibilité prévue L’impact potentiel sur les données Les considérations de sécurité La prochaine mise à jour Les procédures de communication doivent être documentées à l’avance plutôt qu’improvisées pendant un incident. 8. Prévoir le retour à la normale (failback) La reprise après sinistre ne s’arrête pas lorsque l’environnement secondaire devient opérationnel. À terme, l’organisation peut vouloir ramener les charges de travail dans l’environnement d’origine ou établir un nouvel environnement principal. Le processus de failback doit inclure : La reconstruction ou la validation de l’environnement principal La mise en place de la réplication depuis l’environnement de reprise La synchronisation des données modifiées Le test de l’environnement principal La planification de la transition La redirection du trafic La vérification des services de production Le rétablissement des processus normaux de sauvegarde et de réplication Le failback doit être traité comme une migration contrôlée plutôt que comme une inversion automatique du processus de bascule. Modèle de plan de reprise d’activité dans le cloud Les organisations peuvent utiliser la structure suivante comme point de départ de leur propre plan. Informations sur le plan Responsable du plan :Dernière revue :Prochaine revue :Périmètre :Environnement principal :Environnement de reprise : Objectifs de reprise Service critique :Responsable métier :RTO :RPO :Priorité de reprise : Dépendances Dépendances applicatives :Dépendances de stockage :Dépendances réseau :Dépendances d’identité :Services tiers : Protection des données Fréquence des sauvegardes :Emplacement des sauvegardes :Méthode de réplication :Durée de conservation :Configuration de l’immuabilité :Chiffrement :Dernier test de restauration réussi : Activation en cas de sinistre Critères d’activation :Personne habilitée à déclarer un sinistre :Responsable de l’incident :Contacts d’escalade : Procédure de reprise Évaluer les systèmes touchés. Isoler l’infrastructure compromise si nécessaire. Déterminer le point de reprise approprié. Activer l’infrastructure de reprise. Restaurer ou connecter les données protégées. Restaurer les applications selon l’ordre des dépendances. Valider la sécurité et l’intégrité des données. Tester le fonctionnement des applications. Rediriger le trafic de production. Superviser l’environnement restauré. Communiquer l’état de la reprise. Documenter les actions et les résultats. Procédure de failback Validation de l’environnement principal :Processus de synchronisation des données :Responsable du failback :Procédure de migration du trafic :Validation après failback : Tests Fréquence des tests :Scénario de test :RTO attendu :Durée de reprise réelle :RPO attendu :Point de reprise réel :Problèmes détectés :Responsable de la correction : À quelle fréquence tester un plan de reprise d’activité dans le cloud ? Un PRA doit être testé régulièrement et chaque fois que des changements importants touchent l’environnement. Les tests peuvent se faire à plusieurs niveaux. Un exercice sur table fait dérouler un incident simulé aux équipes sans modifier l’infrastructure de production. Un test de restauration vérifie que les données protégées peuvent réellement être restaurées. Un test de bascule active l’infrastructure de reprise et confirme que les applications fonctionnent dans l’environnement secondaire. Un exercice complet de reprise après sinistre teste le processus dans son ensemble, y compris la reprise technique, les communications, la prise de décision et le failback. Les tests doivent mesurer les performances de reprise réelles par rapport aux exigences de RTO et de RPO documentées. Si une application a un RTO de deux heures mais nécessite six heures pour se rétablir lors des tests, soit l’architecture de reprise doit changer, soit l’entreprise doit revoir l’objectif annoncé. Les erreurs courantes de planification de la reprise après sinistre dans le cloud Considérer la sauvegarde comme l’ensemble du PRA Les sauvegardes fournissent les données de reprise. Elles ne définissent ni les dépendances applicatives, ni l’ordre de reprise, ni le provisionnement de l’infrastructure, ni les responsabilités, ni les communications, ni les procédures de bascule. Fixer le même RTO et le même RPO pour toutes les charges de travail Les systèmes n’ont pas tous le même impact sur l’activité. Hiérarchiser les charges de travail permet aux organisations de concentrer leurs investissements de reprise sur les services qui en ont le plus besoin. Ignorer les dépendances Une application peut être techniquement restaurée mais inutilisable, parce que le DNS, l’authentification, le réseau ou un autre service reste indisponible. Laisser les données de reprise accessibles avec les identifiants de production Les cyberattaques peuvent cibler l’infrastructure de sauvegarde pour empêcher la reprise. Séparer les données de reprise des chemins d’accès de la production peut réduire ce risque. Croire que la réplication remplace la sauvegarde La réplication peut reproduire rapidement les modifications d’un environnement à l’autre, y compris les modifications indésirables. Une corruption ou une suppression malveillante peut donc se propager à la réplique. Conserver des points de reprise indépendants offre une autre option lorsque la copie la plus récente n’est pas fiable. Ne pas tester les restaurations Une tâche de sauvegarde réussie confirme que les données ont été écrites. Les tests de reprise déterminent si l’organisation peut réellement restaurer les données et les utiliser dans le délai requis. Intégrer la cyber-résilience à la reprise après sinistre dans le cloud La planification classique de la reprise après sinistre se concentrait souvent sur les pannes d’infrastructure. Les plans actuels doivent aussi envisager des situations où l’infrastructure reste opérationnelle mais où les données elles-mêmes sont devenues indisponibles ou non fiables. Les ransomwares en sont un bon exemple. Basculer simplement vers un autre environnement peut ne pas résoudre le problème si des données chiffrées ou corrompues y ont déjà été répliquées. Une stratégie de reprise cyber-résiliente doit donc associer la disponibilité à des contrôles de protection des données comme le stockage immuable, la séparation des accès, plusieurs points de reprise et des procédures de restauration testées. Pour les données objet en particulier, l’immuabilité peut préserver des points de reprise connus en empêchant la modification ou la suppression des objets protégés pendant leur période de conservation. Scality ARTESCA fournit un stockage objet conçu pour les cas d’usage de sauvegarde et de cyber-résilience, avec des capacités d’immuabilité des données qui peuvent aider les organisations à constituer des référentiels de reprise protégés. La couche de stockage peut s’inscrire dans une architecture de reprise après sinistre plus large, aux côtés du logiciel de sauvegarde, de l’infrastructure cloud et de processus de reprise documentés. De l’exemple de plan de reprise d’activité à la capacité opérationnelle Un plan de reprise d’activité dans le cloud doit en définitive répondre à un ensemble de questions concrètes : quels systèmes doivent être rétablis en premier, en combien de temps, quelle perte de données est acceptable, où sont stockées les données de reprise fiables et comment, exactement, les équipes vont restaurer les services. L’exemple ci-dessus fournit un cadre de départ, mais le plan final doit refléter les applications, les dépendances, les exigences de sécurité et les priorités métier de chaque organisation. Ce sont les tests réguliers qui transforment ces procédures documentées en capacité de reprise mesurable. En comparant les résultats de reprise réels aux objectifs de RTO et de RPO, les organisations peuvent identifier les lacunes et ajuster au fil du temps leur infrastructure, leur stratégie de protection des données et leurs processus de reprise.
