Guide de planification de reprise après sinistre

Cet article constitue la première partie d'une série qui traite de la reprise après sinistre (DR) sur Google Cloud Platform (GCP). Il décrit le processus de planification de reprise après sinistre et vous explique comment établir et mettre en œuvre un plan de reprise. Les parties suivantes présentent des cas d'utilisation spécifiques de reprise après sinistre, avec des exemples de mise en œuvre sur GCP.

Voici les différentes parties de cette série :

Présentation

Des événements d'interruption de service peuvent survenir à tout moment. Vous pouvez connaître une panne de réseau, votre dernier déploiement d'application peut entraîner un bug critique ou vous pouvez être victime d'une catastrophe naturelle. En cas de problème, il est important de disposer d'un plan de reprise après sinistre solide, ciblé et bien testé.

Un plan bien conçu vous permet en effet de minimiser l'impact financier qu'une éventuelle catastrophe peut causer à votre entreprise. Quels que soient vos besoins en matière de reprise après sinistre, Google Cloud Platform (GCP) propose une sélection de fonctionnalités et produits puissants, flexibles et économiques grâce auxquels vous pouvez créer ou améliorer la solution qui vous correspond.

Principes de base de la planification de reprise après sinistre

La reprise après sinistre est un sous-ensemble du plan de continuité des activités. Elle commence par une analyse de l'impact commercial qui définit deux métriques clés :

  • Un objectif de temps de récupération (RTO), qui correspond à la durée maximale acceptable pendant laquelle votre application peut être indisponible. Cette valeur est généralement définie dans le cadre d'un contrat de niveau de service plus vaste.
  • Un objectif de point de récupération (RPO), qui correspond à la durée maximale acceptable pendant laquelle votre application peut perdre des données en raison d'un incident majeur. Cette métrique varie en fonction de la manière dont les données sont utilisées. Par exemple, des données utilisateur régulièrement modifiées peuvent avoir un RPO de quelques minutes seulement. En revanche, des données moins critiques et rarement modifiées peuvent avoir un RPO de plusieurs heures. (Cette métrique ne décrit que la durée, elle ne traite pas de la quantité ni de la qualité des données perdues.)

En règle générale, plus les valeurs RTO et RPO sont faibles (c'est-à-dire, plus votre application doit récupérer rapidement d'une interruption), plus les coûts d'exécution de votre application sont élevés. Le graphique suivant décrit le ratio entre les coûts et les valeurs RTO/RPO.

Graphique indiquant que des valeurs RTO/RPO faibles entraînent des coûts élevés.

Comme des valeurs RTO et RPO plus faibles impliquent souvent davantage de complexité, les frais administratifs associés s'en voient également accrus. Une application haute disponibilité peut nécessiter la gestion de la distribution entre deux centres de données séparés physiquement, la gestion de la réplication, etc.

Les valeurs RTO et RPO sont généralement regroupées dans une autre métrique : l'objectif de niveau de service (SLO), qui est un élément mesurable relatif à un contrat de niveau de service (SLA). Les SLA et les SLO sont souvent confondus. Un SLA est un contrat intégral qui spécifie le service à fournir, la manière dont il est géré, ses heures, ses emplacements, ses coûts, ses performances, ses pénalités ainsi que les responsabilités des parties concernées. Les SLO sont quant à eux des caractéristiques spécifiques et mesurables du SLA, telles que la disponibilité, le débit, la fréquence, le temps de réponse ou la qualité. Un SLA peut contenir de nombreux SLO. Les RTO et les RPO sont mesurables et doivent être considérés comme des SLO.

Pour en savoir plus sur les SLO et SLA, consultez le manuel de Google sur l'ingénierie en fiabilité des sites.

Vous planifiez peut-être également une architecture pour la haute disponibilité. Celle-ci n'empiète pas totalement sur la reprise après sinistre, mais il est souvent nécessaire d'en tenir compte lorsque vous réfléchissez aux valeurs RTO et RPO. La haute disponibilité aide à fournir le niveau de performances opérationnelles qui a été convenu (généralement, un temps d'activité) pendant une période supérieure à la normale. Lorsque vous exécutez des charges de travail de production sur GCP, vous pouvez utiliser un système distribué dans le monde entier. Ainsi, en cas de problème dans une région, l'application continue de proposer un service, même lorsqu'elle est moins largement disponible. Fondamentalement, cette application exploite son plan de reprise après sinistre.

Pourquoi utiliser GCP ?

Comparé à une utilisation sur site conforme aux exigences en matière de RTO et RPO, GCP peut réduire considérablement les coûts associés à ces métriques. Par exemple, la planification classique de reprise après sinistre nécessite la prise en compte d'un certain nombre d'exigences, telles que les suivantes :

  • Capacité : mobiliser suffisamment de ressources pour pouvoir s'adapter en fonction des besoins.
  • Sécurité : assurer la sécurité physique pour protéger les ressources.
  • Infrastructure réseau : intégrer des composants logiciels tels que des pare-feu et des équilibreurs de charge.
  • Assistance : mettre à disposition des techniciens qualifiés pour la maintenance et la résolution des problèmes.
  • Bande passante : prévoir une bande passante adaptée aux pics de charge.
  • Installations : garantir une infrastructure physique, dont les équipements et l'énergie.

Grâce à une solution hautement gérée sur une plate-forme de production de pointe, GCP vous aide à contourner la plupart ou la totalité de ces facteurs de difficulté et à éliminer de nombreux coûts d'entreprise. En outre, l'accent mis par GCP sur la simplicité administrative implique également une réduction des coûts de gestion liés aux applications complexes.

GCP propose plusieurs fonctionnalités pertinentes pour la planification de reprise après sinistre, dont les suivantes :

  • Un réseau mondial. Nous possédons l'un des réseaux informatiques les plus étendus et les plus sophistiqués au monde. Le réseau backbone de Google fait appel à une technologie de mise en réseau avancée définie par logiciel et propose des services de mise en cache périphérique pour offrir des performances élevées, constantes et évolutives.
  • Redondance. La multiplicité de nos points de présence à travers le monde permet d'assurer une excellente redondance. Vos données sont automatiquement répliquées sur les appareils de stockage de plusieurs sites.
  • Évolutivité. GCP est conçu pour évoluer comme d'autres produits Google (tels que la recherche et Gmail), même en cas de pic de trafic important. Les services gérés tels que App Engine, les autoscalers Compute Engine et Cloud Datastore assurent le scaling automatique de l'application pour augmenter ou réduire sa capacité selon les besoins.
  • Sécurité. Notre modèle de sécurité est le fruit de plus de quinze ans d'expérience consacrés à protéger nos clients et nos applications telles que Gmail et G Suite. De plus, nos équipes d'ingénieurs chargés de la fiabilité des sites aident à garantir un niveau de disponibilité élevé et à éviter toute utilisation abusive des ressources de la plate-forme.
  • Conformité. Nous nous soumettons régulièrement à des audits tiers indépendants afin de contrôler les dispositifs et les bonnes pratiques en matière de sécurité, de confidentialité et de conformité de GCP. Google Cloud Platform est conforme aux certifications ISO 27001, SOC 2/3 et PCI DSS 3.0.

Modèles de reprise après sinistre

Les modèles de reprise après sinistre peuvent être à froid, à tiède ou à chaud, ce qui indique la facilité avec laquelle un système peut récupérer à la suite d'un problème. Nous pourrions comparer ces modèles à la crevaison d'un pneu de voiture.

Trois photos de scénarios de crevaison : pas de roue de secours, roue de secours et outils, pneu de roulage à plat.

Votre réaction lors d'une crevaison dépend de votre niveau de préparation :

  • À froid : vous n'avez pas de roue de secours. Vous devez donc appeler quelqu'un pour remplacer le pneu crevé. Votre voyage est interrompu jusqu'à ce qu'on vous apporte la roue de secours et qu'on effectue les réparations.
  • À tiède : vous disposez d'une roue de secours et d'un kit de remplacement. Vous pouvez donc reprendre la route grâce au matériel présent dans votre voiture, mais devez toutefois suspendre votre voyage le temps d'effectuer les réparations.
  • À chaud : vous possédez des pneus de roulage à plat. Vous devrez peut-être ralentir légèrement, mais cela n'aura aucun impact immédiat sur votre voyage. Vos pneus sont suffisamment en bon état pour que vous puissiez continuer votre route (mais vous devrez tout de même régler le problème à un moment ou un autre).

Établir un plan détaillé de reprise après sinistre

Cette section fournit des recommandations sur l'élaboration d'un plan de reprise après sinistre.

Établir un plan en fonction de vos objectifs de reprise

Lorsque vous établissez votre plan de reprise après sinistre, vous devez combiner vos techniques de récupération relatives à l'application et aux données et examiner la situation dans son ensemble. La manière classique de procéder consiste à déterminer vos valeurs RTO et RPO et à étudier le modèle de reprise après sinistre que vous pouvez adopter pour les atteindre. Par exemple, dans le cas de données historiques axées sur la conformité, vous n'avez probablement pas besoin d'un accès rapide. Il convient alors mieux d'utiliser une valeur RTO élevée et un modèle de reprise après sinistre à froid. Toutefois, si votre service en ligne subit une interruption, vous voudrez pouvoir retrouver le plus rapidement possible les données et la partie de l'application destinée aux clients. Dans ce cas, un modèle à chaud serait plus approprié. Quant à votre système de notification par e-mail, qui n'est généralement pas critique pour votre entreprise, il est sans doute plus adapté à un modèle à tiède.

Pour découvrir comment traiter des cas de figure courants de reprise après sinistre à l'aide de GCP, consultez les scénarios de reprise d'application. Ils décrivent des stratégies de reprise après sinistre ciblées pour divers cas d'utilisation et proposent des exemples de mise en œuvre sur GCP.

Établir un plan pour une reprise de bout en bout

Il ne suffit pas de créer un plan de sauvegarde ou d'archivage des données. Vous devez également vous assurer que votre plan de reprise après sinistre englobe l'ensemble du processus de récupération, de la sauvegarde à la restauration en passant par le nettoyage. Nous abordons ce point dans les documents connexes sur la reprise après sinistre pour les données.

Créer des tâches spécifiques

Au moment d'exécuter votre plan de reprise après sinistre, vous ne voulez pas avoir à deviner à quoi correspond chaque étape. Assurez-vous donc que chaque tâche de votre plan consiste en une ou plusieurs commandes ou actions claires et concrètes. Par exemple, l'action "Exécuter le script de restauration" est trop générale. En revanche, "Ouvrir Bash et exécuter /home/example/restore.sh" est une commande précise et concrète.

Mettre en place des mesures de contrôle

Ajoutez des contrôles pour éviter toute catastrophe et détecter les problèmes avant qu'ils ne surviennent. Vous pouvez par exemple mettre en place un contrôle de surveillance qui envoie une alerte lorsqu'un flux destructeur de données (tel qu'un pipeline de suppression) présente des pics inattendus ou une autre activité inhabituelle. Ce contrôle de surveillance peut également mettre fin aux processus du pipeline si un certain seuil de suppression est atteint, ce qui permet d'éviter des situations catastrophiques.

Préparer le logiciel

Une étape de la planification de reprise après sinistre consiste à s'assurer que le logiciel utilisé est prêt à traiter un événement de récupération.

Vérifier que vous pouvez installer le logiciel

Vérifiez que votre logiciel d'application peut être installé à partir de la source ou d'une image préconfigurée. Assurez-vous de disposer de la licence appropriée pour tout logiciel que vous allez déployer sur GCP. Consultez le fournisseur du logiciel pour en savoir plus.

Concevoir un déploiement continu pour la reprise

Votre ensemble d'outils de déploiement continu fait partie intégrante du déploiement de vos applications. Dans le cadre de votre plan, vous devez déterminer à quel emplacement vous allez déployer des artefacts au sein de votre environnement de reprise. Planifiez la zone d'hébergement de votre environnement et de vos artefacts de déploiement continu. Ils doivent être disponibles et opérationnels en cas de sinistre.

Mettre en place des contrôles de sécurité et de conformité

Lors de l'établissement d'un plan de reprise après sinistre, la sécurité joue un rôle majeur. Les contrôles de votre environnement de production doivent pouvoir s'appliquer à votre environnement de reprise. Les règles relatives à la conformité s'appliqueront également à celui-ci.

Configurer la sécurité de la même manière pour les environnements de production et de reprise après sinistre

Assurez-vous que vos contrôles réseau fournissent la même séparation et les mêmes blocages que l'environnement de production source. Apprenez à configurer le VPC partagé et les pare-feu GCP pour établir un réseau centralisé et un contrôle de sécurité de votre déploiement, configurer des sous-réseaux, contrôler le trafic entrant et sortant, etc. Découvrez comment exploiter les comptes de service afin de mettre en œuvre le principe du moindre privilège pour les applications qui accèdent aux API GCP. Pensez à utiliser les comptes de service dans les règles de pare-feu.

Assurez-vous d'accorder aux utilisateurs le même accès à l'environnement de reprise après sinistre que celui dont ils disposent dans l'environnement de production source. La liste suivante présente les différentes méthodes de synchronisation des autorisations entre plusieurs environnements :

  • Si vous utilisez l'environnement de production GCP, il est très simple de répliquer des stratégies IAM dans un environnement de reprise après sinistre. Vous pouvez employer des méthodes IaC (Infrastructure as Code) ainsi que des outils tels que Cloud Deployment Manager pour déployer vos stratégies Cloud IAM en production. Ces mêmes outils vous permettent ensuite de lier les stratégies aux ressources correspondantes de l'environnement de reprise après sinistre lorsque vous le mettez en place.

  • Si vous utilisez un environnement de production sur site, vous pouvez mapper les rôles fonctionnels (tels que les rôles d'administrateur réseau et d'auditeur) aux stratégies IAM qui disposent des rôles IAM appropriés. La documentation relative à IAM contient des exemples de configuration de rôles fonctionnels. Vous pouvez par exemple la consulter pour découvrir comment créer des rôles fonctionnels associés à la mise en réseau et aux journaux d'audit.

  • Vous devez configurer les stratégies IAM de façon à accorder les autorisations appropriées aux produits. Par exemple, vous pouvez vouloir limiter l'accès à certains buckets Cloud Storage.

  • Si vous faites appel à un autre fournisseur cloud pour votre environnement de production, mappez les autorisations de son système IAM aux stratégies IAM de GCP. Par exemple, si vous utilisez l'environnement de production AWS, consultez la page Google Cloud Platform pour les utilisateurs professionnels d'AWS : gestion pour en savoir plus.

Vérifier la sécurité de l'environnement de reprise après sinistre

Une fois les autorisations de l'environnement de reprise après sinistre configurées, assurez-vous de toutes les tester. Créez un environnement de test. Employez des méthodes IaC qui exploitent des outils tels que Deployment Manager pour déployer vos stratégies IAM dans l'environnement de test. Vérifiez ensuite que l'accès que vous accordez aux utilisateurs leur confère les mêmes autorisations que celles dont ils disposent sur site.

S'assurer que les utilisateurs peuvent se connecter à l'environnement de reprise après sinistre

Dans la même optique, n'attendez pas qu'une catastrophe se produise pour vérifier que vos utilisateurs peuvent accéder à l'environnement de reprise après sinistre. Assurez-vous que vous avez accordé les droits d'accès appropriés aux utilisateurs, aux développeurs, aux opérateurs, aux data scientists, aux administrateurs de sécurité, aux administrateurs réseau et à tout autre rôle de votre organisation. Si vous utilisez un autre système de gestion de l'authentification, vérifiez que les comptes ont bien été synchronisés avec votre compte Cloud Identity. Comme l'environnement de reprise après sinistre sera votre environnement de production pendant un certain temps, demandez aux utilisateurs devant y accéder de se connecter, puis résolvez les problèmes d'authentification. Tenez compte des utilisateurs qui se connectent à l'environnement de reprise après sinistre lors des tests de reprise réguliers que vous mettez en œuvre.

Pour gérer de manière centralisée les membres qui disposent d'un accès SSH aux machines virtuelles (VM) lancées, activez la fonctionnalité de connexion au système d'exploitation sur les projets GCP qui composent votre environnement de reprise après sinistre.

Former les utilisateurs

Les utilisateurs doivent pouvoir comprendre comment exécuter les tâches qu'ils effectuent habituellement dans leur environnement de production sur GCP, telles que la connexion, l'accès aux VM, etc. À l'aide de l'environnement de test, expliquez-leur comment réaliser ces tâches d'une manière qui protège votre système.

S'assurer que l'environnement de reprise après sinistre répond aux exigences de conformité

Vérifiez que votre environnement de reprise après sinistre n'est accessible qu'aux utilisateurs autorisés. Assurez-vous également que les informations personnelles sont masquées et chiffrées. Si vous effectuez des tests d'intrusion réguliers dans votre environnement de production, il est conseillé d'inclure l'environnement de reprise après sinistre à ce champ d'application et de procéder à des tests fréquents en mettant en place un environnement de reprise après sinistre.

Lorsque l'environnement de reprise après sinistre est en service, assurez-vous que tous les journaux recueillis figurent dans l'archive de journaux de votre environnement de production. De même, dans le cadre de votre environnement de reprise, vérifiez que vous pouvez exporter les journaux d'audit recueillis par Stackdriver vers l'archive de votre récepteur de journaux principal. Utilisez les fonctions du récepteur d'exportations. Pour les journaux d'applications, créez une réplique de votre environnement de journalisation et de surveillance sur site. Si vous faites appel à un autre fournisseur cloud pour votre environnement de production, mappez la journalisation et la surveillance de celui-ci aux services GCP équivalents. Créez un processus afin de mettre en forme les entrées dans votre environnement de production.

Utiliser Cloud Storage pour les opérations de sauvegarde quotidiennes

Stockez les sauvegardes dans Cloud Storage. Assurez-vous que les buckets contenant les sauvegardes disposent des autorisations appropriées.

Gérer les secrets de manière adaptée

Gérez les secrets et les clés au niveau de l'application en exploitant GCP pour héberger le service de gestion de clés et de secrets (KMS). Vous pouvez utiliser Cloud KMS ou une solution tierce comme HashiCorp Vault avec un backend GCP tel que Cloud Spanner ou Cloud Storage.

Traiter les données récupérées comme des données de production

Assurez-vous que les contrôles de sécurité relatifs à vos données de production s'appliquent également à vos données récupérées. Les mêmes exigences en matière d'autorisations, de chiffrement et d'audit doivent également s'appliquer.

Sachez où sont stockées vos sauvegardes et qui est autorisé à restaurer les données. Assurez-vous que votre processus de récupération est auditable. À la suite d'une reprise après sinistre, il doit être possible de vérifier qui a accédé aux données de sauvegarde et qui a effectué la récupération.

Vérifier le fonctionnement du plan de reprise après sinistre

Pour vous assurer que votre planification s'avère payante, vous voudrez vérifier que tout fonctionne correctement en cas de sinistre.

Disposer d'alternatives pour récupérer les données

En cas de sinistre, votre méthode de connexion à GCP peut devenir indisponible. Mettez en œuvre un autre moyen d'accès à GCP pour vous assurer de pouvoir transférer des données vers la plate-forme. Vérifiez fréquemment que le chemin d'accès de sauvegarde est opérationnel.

Tester régulièrement le plan

Une fois votre plan de reprise après sinistre établi, testez-le régulièrement et notez les éventuels problèmes, puis ajustez le plan en conséquence. GCP vous permet de tester des scénarios de reprise à un coût minimal. Pour faciliter le processus de test, il est recommandé de mettre en œuvre les éléments suivants :

  • Automatisez le provisionnement de l'infrastructure avec Deployment Manager. Deployment Manager vous permet d'automatiser le provisionnement des instances de VM et d'autres infrastructures GCP. Si vous exécutez votre environnement de production sur site, vous devez vous assurer de disposer d'un processus de surveillance capable de lancer le processus de reprise après sinistre en cas de détection d'une panne, puis de déclencher les actions de reprise appropriées.
  • Surveillez et déboguez vos tests avec Stackdriver Logging et Stackdriver Monitoring. GCP propose d'excellents outils de journalisation et de surveillance accessibles via des appels d'API. Ils vous permettent d'automatiser le déploiement de scénarios de reprise en réaction aux métriques. Lorsque vous créez des tests, assurez-vous de disposer d'une surveillance et d'alertes adaptées pouvant déclencher les actions de reprise appropriées.
  • Effectuez les tests abordés précédemment :

    • Vérifiez que les autorisations et les accès utilisateurs présentent le même comportement dans l'environnement de reprise après sinistre que dans l'environnement de production.
    • Effectuez des tests d'intrusion dans votre environnement de reprise après sinistre.
    • Procédez à un test au cours duquel votre méthode de connexion habituelle à GCP ne fonctionne pas.

Étapes suivantes