Version : 1.0
Date de rédaction : [JJ/MM/AAAA]
Propriétaire du document : [Nom, Fonction]
Classification : Confidentiel — Interne uniquement
- Décrire l'objectif du PRA : garantir la restauration technique des systèmes d'information et la reprise des services SaaS après un incident majeur rendant tout ou partie de l'infrastructure inopérante
- Cyberattaque (ransomware, wiper, compromission de la chaîne d'approvisionnement)
- Panne infrastructure critique (défaillance cloud provider, perte d'une région entière)
- Catastrophe naturelle affectant les datacenters (incendie, inondation, séisme)
- Erreur humaine à impact majeur (suppression massive de données, corruption de configuration)
- Défaillance d'un composant tiers critique (base de données managée, service d'authentification, CDN)
- Détailler le périmètre technique couvert par le plan :
- Applications et microservices (API, frontends, workers, jobs batch)
- Plateformes cloud et comptes associés (AWS, GCP, Azure — production, staging, DR)
- Bases de données et datastores (relationnelles, NoSQL, caches, files de messages)
- Pipelines CI/CD et outillage de déploiement
- Réseaux et connectivité (VPC, peering, VPN, DNS)
- Services tiers intégrés (CDN, provider d'authentification, passerelle de paiement, monitoring)
- Secrets et credentials (clés API, certificats TLS, tokens de service)
- Définir les limites d'exclusion :
- La continuité organisationnelle (processus métiers manuels, RH, communication de crise) est couverte par le PCA
- Les mesures préventives de sécurité sont couvertes par le PAS (Plan d'Assurance Sécurité)
- La gestion de la relation client en mode dégradé relève du PCA
- Préciser l'articulation avec les autres plans de résilience :
- PCA (Plan de Continuité d'Activité) : le PCA orchestre la réponse organisationnelle globale et active le mode dégradé ; le PRA constitue le volet technique de restauration des systèmes. Le PCA définit les priorités métier que le PRA traduit en séquence de restauration technique
- PAS (Plan d'Assurance Sécurité) : le PAS définit les exigences de sécurité que le PRA doit respecter lors de la reprise (chiffrement, contrôle d'accès, intégrité). Le PRA ne doit jamais compromettre la posture de sécurité pour accélérer la reprise
- PSSI (Politique de Sécurité des Systèmes d'Information) : les procédures du PRA respectent les principes de la PSSI, y compris en situation d'urgence
- Définir la structure de la cellule de crise technique et sa composition :
- Incident Commander (IC) : pilote opérationnel de la reprise technique, responsable de la coordination et de la prise de décision technique
- Technical Lead DR : responsable de l'exécution des procédures de basculement et de restauration
- Database Lead : responsable de la restauration et de la vérification d'intégrité des données
- Network / Infrastructure Lead : responsable de la connectivité, du DNS et du routage du trafic
- Security Lead : garant du maintien de la posture de sécurité pendant la reprise (pas de raccourcis de sécurité)
- Responsable communication technique : interface avec la cellule de crise PCA, rédaction des bulletins techniques
- Référent prestataires cloud : interlocuteur du support enterprise du fournisseur cloud (gestion des tickets prioritaires)
- Pour chaque rôle, indiquer :
- Le titulaire principal et le remplaçant désigné (au minimum 2 personnes qualifiées par rôle)
- Les coordonnées d'urgence accessibles hors SI (téléphone personnel, email alternatif, messagerie chiffrée)
- Les autorisations spécifiques requises (ex : accès root au compte DR, validation budget basculement multi-région, autorisation de coupure du trafic production)
- Le périmètre de décision autonome (ex : l'IC peut déclencher un basculement DR sans validation direction si le RTO est menacé)
- Préciser les règles de fonctionnement de la cellule technique :
- Critères d'activation de la cellule (seuils de déclenchement, cf. chapitre 5)
- Canal de communication de crise technique (bridge téléphonique permanent, salon dédié sur messagerie de secours)
- Fréquence des points de situation pendant la reprise (toutes les 30 min en phase critique, toutes les 2h en phase de stabilisation)
- Journalisation systématique des actions effectuées, des décisions prises et de leur justification (war room log)
- Modalités de prise de décision (consensus technique, décision unilatérale de l'IC si urgence)
- Préciser les horaires de couverture (24/7 ou business hours) et le dispositif d'astreinte
- Documenter l'analyse Business Impact Analysis sous l'angle technique, en cohérence avec le BIA organisationnel du PCA
- Cartographier chaque service et composant technique par niveau de criticité :
- Tier 1 — Critique : services sans lesquels la plateforme SaaS est totalement inutilisable (ex : API cœur, base de données principale, service d'authentification, gateway API)
- Tier 2 — Important : services dont l'interruption cause un préjudice significatif sous 4h (ex : service de facturation, moteur de notifications, tableau de bord analytics, pipeline de données)
- Tier 3 — Secondaire : services dégradables temporairement sans impact métier majeur (ex : reporting avancé, fonctionnalités secondaires, environnements de staging)
- Tier 4 — Non-critique : services suspendables sans impact immédiat (ex : outils internes, jobs de maintenance, environnements de développement)
- Pour chaque service classé, documenter :
- Les dépendances techniques ascendantes et descendantes (graphe de dépendances)
- L'impact par tranche horaire d'indisponibilité : financier (perte de revenus, pénalités SLA), réglementaire (violation d'obligations), réputationnel (perte de confiance client)
- Le MTPD (Maximum Tolerable Period of Disruption) : durée maximale d'interruption avant dommage irréversible pour le métier
- Le volume de données généré par heure (détermine le RPO minimal)
- Les ressources techniques nécessaires à la reprise (compute, storage, network bandwidth)
- Établir la matrice de dépendances croisées entre services techniques et processus métiers (alimentation directe du PCA)
- Identifier les SPOF (Single Points of Failure) et les composants sans redondance
- Définir pour chaque service classé par tier :
- Recovery Time Objective (RTO) : délai maximal acceptable entre la déclaration du sinistre et la restauration du service à un niveau opérationnel
- Recovery Point Objective (RPO) : perte de données maximale admissible, exprimée en durée (ex : RPO 15 min = on accepte de perdre au maximum les 15 dernières minutes de données)
- Établir les valeurs cibles par tier, justifiées par le BIA :
- Tier 1 : RTO < 1h, RPO < 15 min — exige une architecture hot standby ou warm standby avec réplication synchrone ou quasi-synchrone
- Tier 2 : RTO ≤ 4h, RPO ≤ 1h — compatible avec une architecture pilot light et réplication asynchrone fréquente
- Tier 3 : RTO ≤ 24h, RPO ≤ 24h — compatible avec une stratégie backup & restore depuis des snapshots
- Tier 4 : RTO ≤ 72h, RPO ≤ 48h — reconstruction complète depuis l'IaC et les backups longue rétention
- Documenter les contraintes et compromis pour chaque niveau :
- Coût de l'infrastructure de secours vs impact financier de l'indisponibilité
- Complexité opérationnelle de la réplication vs niveau de perte de données acceptable
- Latence de réplication inter-région vs consistance des données
- Obtenir la validation formelle des parties prenantes :
- Direction générale (engagement budgétaire)
- Responsables métiers (acceptation du niveau de perte)
- Clients clés (alignement avec les SLA contractuels)
- Ces objectifs pilotent directement les choix architecturaux de redondance (chapitre 6) et les procédures de basculement (chapitre 7)
- Définir les métriques de mesure en conditions réelles :
- RTA (Recovery Time Actual) : temps de reprise réellement constaté lors des tests
- RPA (Recovery Point Actual) : perte de données réellement constatée lors des tests
- Écart acceptable entre objectif et réel (RTA ≤ 80% du RTO pour conserver une marge de sécurité)
- Identifier et classer par probabilité/impact les scénarios de sinistre technique (complémentaire à l'analyse organisationnelle du PCA) :
- Ransomware sur bases de données : chiffrement des données de production, demande de rançon, corruption potentielle des sauvegardes récentes
- Panne multi-AZ du fournisseur cloud : indisponibilité simultanée de plusieurs zones de disponibilité dans une même région
- Perte complète d'une région cloud : événement catastrophique rendant une région entière inaccessible (précédent : incendie OVH Strasbourg 2021)
- Erreur humaine en production : suppression massive de données, application d'une migration destructive, erreur de configuration réseau
- Attaque DDoS volumétrique : saturation de la bande passante et des ressources, rendant le service inaccessible
- Compromission de la chaîne CI/CD : injection de code malveillant via un pipeline de déploiement compromis (supply chain attack)
- Fuite ou destruction de secrets : exposition de clés API, certificats, credentials base de données nécessitant une rotation d'urgence
- Défaillance d'un service tiers critique : panne prolongée du CDN, du provider d'authentification (ex : Auth0, Okta), du DNS managé ou de la passerelle de paiement
- Corruption silencieuse des données : altération non détectée des données sur une période prolongée (bit rot, bug applicatif)
- Perte d'accès au compte cloud : compromission des credentials root, blocage du compte par le fournisseur
- Pour chaque scénario, documenter :
- Les précurseurs et signaux faibles détectables (alertes monitoring, anomalies de performance, indicateurs de compromission)
- Les seuils d'activation du PRA (critères objectifs : durée d'indisponibilité, nombre d'utilisateurs impactés, volume de données compromises)
- L'enchaînement attendu des impacts techniques (cascade de défaillances)
- La stratégie de reprise applicable (référence au chapitre 6)
- Le temps estimé de détection, de diagnostic et de reprise pour chaque scénario
- Maintenir une matrice de risques avec réévaluation semestrielle :
- Probabilité (rare / peu probable / possible / probable)
- Impact (mineur / modéré / majeur / critique)
- Niveau de préparation actuel (non couvert / partiellement couvert / couvert / testé)
- Décrire la stratégie DR retenue pour chaque tier, avec justification technique et financière :
¶ Tier 4 — Backup & Restore (Cold Standby)
- Principe : aucune infrastructure de secours permanente ; reconstruction depuis les sauvegardes et l'IaC
- Architecture : sauvegardes stockées dans une région distincte, code IaC versionné et testé
- Avantage : coût quasi nul en régime nominal
- Limite : temps de reprise long (reconstruction complète de l'infrastructure)
- Principe : les composants essentiels (bases de données, secrets) sont maintenus en réplication dans la région DR, mais les couches applicatives ne sont pas déployées
- Architecture : réplication asynchrone des datastores, AMI/images conteneur prêtes au déploiement, IaC validée pour le provisionnement rapide
- Avantage : compromis coût/temps de reprise
- Limite : temps de déploiement des couches applicatives (~1-4h)
¶ Tier 2 — Warm Standby
- Principe : une version réduite de l'environnement de production tourne en permanence dans la région DR (capacité réduite, scaling à la demande lors du basculement)
- Architecture : instances applicatives minimales actives, bases de données en réplication continue, auto-scaling configuré
- Avantage : basculement rapide avec montée en charge progressive
- Limite : coût permanent de l'infrastructure réduite (~20-30% du coût production)
¶ Tier 1 — Hot Standby / Active-Active
- Principe : l'environnement DR est une réplique complète de la production, capable d'absorber 100% du trafic instantanément
- Architecture : déploiement multi-région actif-actif, réplication synchrone ou quasi-synchrone des données, routage DNS géo-aware avec health checks
- Avantage : basculement quasi-instantané (failover < 5 min), RPO minimal
- Limite : coût élevé (~80-100% du coût production), complexité de la gestion de la consistance des données
- L'architecture technique détaillée (diagramme d'infrastructure)
- Le type de réplication des données : synchrone (RPO ~ 0), asynchrone (RPO = intervalle de réplication), snapshot périodique (RPO = fréquence des snapshots)
- La configuration réseau : Multi-AZ obligatoire pour tous les tiers, Multi-région pour Tier 1 et 2 (si exigé contractuellement)
- Les outils et services cloud utilisés :
- Compute : EKS/GKE multi-cluster, EC2 Auto Scaling Groups, Lambda avec réplication
- Données : RDS Multi-AZ + Cross-Region Read Replica, DynamoDB Global Tables, S3 Cross-Region Replication, ElastiCache Global Datastore
- Réseau : Route 53 health checks + failover routing, CloudFront multi-origin, Global Accelerator
- Orchestration : Terraform/OpenTofu avec workspaces multi-région, ArgoCD multi-cluster
- Le compromis coût/robustesse chiffré (coût mensuel estimé de l'infrastructure DR par rapport à la production)
- Les métriques de vérification de l'état de la réplique (replication lag, data drift)
- Rédiger les procédures opérationnelles étape par étape, sous forme de runbooks exécutables, pour chaque scénario identifié au chapitre 5 :
- Réception de l'alerte (monitoring, alerte client, notification fournisseur)
- Qualification initiale de l'incident par l'ingénieur d'astreinte : vérification multi-source (dashboard monitoring, health checks, tests manuels)
- Évaluation de la gravité selon la grille :
- Sev1 : service totalement indisponible pour tous les clients → activation immédiate du PRA
- Sev2 : service partiellement indisponible ou dégradé significativement → activation si non résolu sous 30 min
- Sev3 : composant non critique impacté → surveillance renforcée, pas d'activation PRA
- Documentation de l'heure de détection (T0) dans le journal d'incident
- L'Incident Commander est alerté et prend le commandement de l'incident
- Décision formelle d'activation du PRA (go/no-go documenté avec justification)
- Notification à la cellule de crise PCA pour activation parallèle du volet organisationnel
- Ouverture du canal de communication de crise (bridge téléphonique, salon dédié)
- Documentation de l'heure d'activation (T1) et démarrage du chronomètre RTO
- Convocation de la cellule technique selon la matrice d'astreinte
- Briefing initial (< 10 min) : nature de l'incident, périmètre impacté, stratégie DR applicable
- Attribution des responsabilités par domaine (database, infra, réseau, sécurité)
- Vérification de l'accès au site DR et aux outils de gestion (consoles cloud, Terraform, kubectl)
- Vérification de l'état du site DR (réplication à jour, services opérationnels, capacité suffisante)
- Si Warm/Hot Standby : scaling de l'infrastructure DR à la capacité production
- Si Pilot Light : déploiement des couches applicatives via IaC (Terraform apply, ArgoCD sync)
- Si Backup & Restore : provisionnement de l'infrastructure et restauration des données depuis les sauvegardes
- Point de contrôle obligatoire (GO/NO-GO) : vérification que l'environnement DR est opérationnel avant la redirection du trafic
- Vérification des checksums et de la consistance des bases de données restaurées
- Exécution des tests de smoke automatisés (health checks applicatifs, requêtes de validation métier)
- Vérification du replication lag et identification de la perte de données effective (RPA)
- Comparaison du RPA avec le RPO contractuel — si dépassement, notification immédiate au PCA
- Point de contrôle obligatoire (GO/NO-GO) : validation de l'intégrité avant ouverture du trafic client
- Mise à jour des enregistrements DNS (failover Route 53, modification des CNAME, réduction du TTL préalable si non déjà fait)
- Basculement du load balancer / reverse proxy vers le site DR
- Vérification de la propagation DNS et du routage effectif du trafic
- Monitoring renforcé des métriques de performance et d'erreur sur le site DR
- Confirmation que les clients accèdent effectivement au service restauré
- Documentation de l'heure de reprise effective (T2) et calcul du RTA (T2 - T1)
- Surveillance intensive pendant les 4 premières heures post-basculement
- Monitoring des indicateurs clés : taux d'erreur, latence, throughput, saturation des ressources
- Traitement des anomalies et ajustements (scaling, configuration, cache warming)
- Points de situation réguliers à la cellule de crise PCA
- Évaluation de l'état du site primaire (infrastructure réparée, sécurisée, opérationnelle)
- Resynchronisation des données du site DR vers le site primaire
- Vérification d'intégrité post-resynchronisation
- Basculement du trafic en retour vers le site primaire (progressive ou big-bang selon la criticité)
- Vérification du fonctionnement nominal
- Désactivation du mode DR et retour aux astreintes normales
- Point de contrôle obligatoire (GO/NO-GO) : validation formelle de la fin de l'incident
- Inclure pour chaque procédure :
- Les scripts et commandes automatisés associés (runbooks Ansible, scripts Terraform, commandes kubectl)
- Les liens vers les dashboards de monitoring à consulter
- Les durées estimées pour chaque étape
- Les critères de rollback si une étape échoue
- Détailler l'architecture technique du site de reprise :
- Région cloud secondaire (justification du choix : proximité géographique, conformité réglementaire, isolation des risques)
- Comptes cloud dédiés (séparation du compte DR du compte production pour limiter le blast radius)
- Quotas et limites de service vérifiés et pré-approuvés dans la région DR
- Configuration VPC miroir de la production (mêmes CIDR, mêmes security groups, mêmes NACLs)
- Connectivité inter-régions (VPC peering, Transit Gateway, VPN site-to-site si nécessaire)
- DNS failover configuré et testé (Route 53 health checks, TTL optimisé pour basculement rapide)
- Certificats TLS provisionnés et renouvelés automatiquement dans la région DR
- Orchestrateurs conteneurisés multi-cluster (EKS, GKE) avec configurations synchronisées
- Images de conteneurs répliquées dans un registry DR (ECR Cross-Region Replication, Artifact Registry)
- Configurations d'auto-scaling pré-paramétrées pour absorber la charge production
- Bases de données en mode réplication continue (RDS Cross-Region Read Replica, Aurora Global Database, DynamoDB Global Tables)
- Stockage objet répliqué (S3 Cross-Region Replication avec vérification d'intégrité)
- File systems répliqués si applicable (EFS Cross-Region Replication)
- Caches pré-chauffés ou reconstructibles rapidement (ElastiCache Global Datastore, Redis Sentinel)
- Secrets répliqués dans la région DR (AWS Secrets Manager cross-region, HashiCorp Vault avec réplication)
- Clés de chiffrement (KMS) créées et gérées dans la région DR (ou utilisation de clés multi-région)
- Procédures de rotation d'urgence des secrets si compromission suspectée
- Documenter les configurations IaC (Terraform/OpenTofu, Pulumi, CloudFormation) utilisées pour le déploiement automatique du site DR
- Versionner le code IaC dans un dépôt Git avec pipeline de validation (plan, drift detection)
- Maintenir la parité de configuration entre production et DR via des tests automatisés (drift detection périodique)
- Stocker les state files de manière résiliente (S3 + DynamoDB lock dans une troisième région ou backend managé)
- Indiquer les coûts mensuels estimés du maintien opérationnel de l'infrastructure de secours par stratégie DR :
- Hot Standby : ~80-100% du coût production
- Warm Standby : ~20-30% du coût production
- Pilot Light : ~5-10% du coût production
- Cold (Backup & Restore) : coût de stockage uniquement (~1-3% du coût production)
- Comparer au coût potentiel d'une interruption non couverte (SLA credits, perte de revenus, pénalités contractuelles)
- Décrire la stratégie de backup complète et multi-niveaux :
- Bases de données relationnelles :
- Snapshots automatiques : fréquence (ex : toutes les 6h), rétention (ex : 30 jours)
- Point-in-Time Recovery (PITR) : rétention du WAL/binlog (ex : 7 jours de PITR)
- Export logique périodique (pg_dump, mysqldump) pour portabilité
- Bases de données NoSQL :
- Snapshots natifs (DynamoDB on-demand backup, MongoDB Atlas backup)
- Export vers stockage objet pour archivage longue durée
- Stockage objet (S3, GCS) :
- Versioning activé sur tous les buckets critiques
- Cross-Region Replication pour les données Tier 1 et 2
- Lifecycle policies pour l'archivage (Glacier, Coldline)
- Volumes bloc (EBS, Persistent Volumes) :
- Snapshots automatisés via AWS Backup ou Velero (pour Kubernetes)
- Copie cross-region des snapshots critiques
- Configurations et secrets :
- Sauvegarde des configurations Kubernetes (etcd snapshots, Velero)
- Export des secrets et credentials dans un coffre-fort séparé
- Chiffrement au repos (AES-256 ou équivalent) avec clés gérées dans un KMS dédié
- Chiffrement en transit (TLS 1.2+ pour toute réplication)
- Immutabilité des sauvegardes critiques :
- S3 Object Lock en mode Compliance (WORM — Write Once Read Many)
- Rétention légale configurable
- Protection contre la suppression, même par un administrateur compromis
- Séparation des comptes : les sauvegardes sont stockées dans un compte cloud distinct du compte de production (protection contre le ransomware qui compromettrait le compte principal)
- Préciser la localisation de chaque copie de sauvegarde (région primaire, région DR, troisième région ou stockage hors-cloud)
- Vérifier la conformité avec les exigences de souveraineté des données (RGPD, exigences contractuelles de localisation)
- Documenter le processus de restauration testée régulièrement pour chaque type de données :
- Procédure pas à pas (runbook)
- Temps estimé de restauration par volume de données
- Ressources nécessaires (compute temporaire, bande passante)
- Définir les seuils de vérification d'intégrité post-restauration :
- Checksums et hash de validation
- Tests de lecture exhaustifs
- Requêtes de validation fonctionnelle (comptage de lignes, vérification de données échantillonnées)
- Comparaison avec les métriques de la dernière sauvegarde connue saine
- Conformité RGPD : droit à l'effacement applicable aux sauvegardes (processus de purge documenté), durées de rétention conformes au registre des traitements
- Conformité sectorielle : rétention légale si applicable (santé, finance)
- Traçabilité : journalisation de tous les accès aux sauvegardes
- Décrire le dispositif de surveillance permettant la détection rapide des incidents déclencheurs du PRA :
- Health checks sur tous les composants critiques (endpoints HTTP, ports TCP, requêtes de validation)
- Métriques système (CPU, mémoire, disque, réseau) avec seuils d'alerte définis
- Monitoring du replication lag entre la production et le site DR (alerte si lag > seuil acceptable pour le RPO)
- Vérification périodique de l'état du site DR (infrastructure opérationnelle, réplication active)
- APM (Application Performance Monitoring) sur les services critiques
- Taux d'erreur par endpoint et par service (seuils d'alerte sur les 5xx)
- Latence P50/P95/P99 avec détection d'anomalie
- Métriques métier (nombre de transactions, nombre d'utilisateurs actifs, volume de données traitées)
- Définir la chaîne d'alerting :
- Niveau 1 : notification automatique à l'ingénieur d'astreinte (PagerDuty, OpsGenie)
- Niveau 2 : escalade au Technical Lead si non acquittée sous 15 min
- Niveau 3 : escalade à l'Incident Commander si incident Sev1 confirmé
- Canaux d'alerte multiples pour résilience (SMS, appel téléphonique, email, push mobile)
- Tests réguliers du système d'alerting (vérification mensuelle que les notifications arrivent)
- Préparer des dashboards dédiés à la gestion de crise DR :
- Vue d'ensemble de la santé du site primaire et du site DR
- État de la réplication des données en temps réel
- Progression du basculement (étapes complétées, en cours, restantes)
- Métriques RTO/RPO en temps réel pendant un exercice ou un sinistre réel
- Garantir que les procédures de reprise n'introduisent pas de vulnérabilités de sécurité :
- Pas de raccourcis de sécurité : aucune procédure de reprise ne doit désactiver les contrôles de sécurité (chiffrement, authentification, journalisation) pour gagner du temps
- Moindre privilège maintenu : les accès d'urgence (break glass) sont tracés, limités dans le temps et révoqués dès la fin de l'incident
- Vérification d'intégrité : tout composant restauré est vérifié avant d'être exposé au trafic (scan de vulnérabilités, vérification des signatures)
- Isolation de l'environnement compromis avant toute tentative de restauration
- Analyse forensique si nécessaire (préservation des preuves avant nettoyage)
- Restauration depuis des sauvegardes antérieures à la compromission (identification du "dernier état sain")
- Rotation de tous les secrets et credentials avant la remise en service
- Scan complet de l'environnement restauré avant ouverture du trafic
- Documenter les procédures d'accès d'urgence si les systèmes d'authentification habituels sont indisponibles :
- Comptes break glass pré-provisionnés avec MFA hardware dédié
- Enveloppes scellées contenant les credentials de secours (stockées hors site, en coffre-fort physique)
- Procédure d'activation et de journalisation de l'utilisation des accès d'urgence
- Révocation et renouvellement systématiques après chaque utilisation
- Préparer les modèles de communication technique prêts à l'emploi :
- Notification interne à l'équipe technique : description de l'incident, périmètre impacté, actions en cours, prochains jalons
- Bulletin d'information vers la cellule de crise PCA : situation technique synthétique, estimation du temps de reprise, données perdues le cas échéant
- Message client technique (status page) :
- Investigating : incident détecté, diagnostic en cours
- Identified : cause identifiée, reprise en cours
- Monitoring : service restauré, surveillance renforcée
- Resolved : incident résolu, post-mortem à venir
- Déclaration publique : communication presse/réseaux sociaux (en coordination avec le PCA)
- Information aux autorités : CNIL sous 72h en cas de fuite de données (en coordination avec le DPO et le référent juridique)
- Définir les canaux alternatifs si le SI est compromis :
- Messagerie chiffrée de secours (Signal, WhatsApp Business)
- Bridge téléphonique permanent
- Site web statique de status page hébergé indépendamment (ex : Atlassian Statuspage, hébergement statique sur un CDN distinct)
- Préciser la chaîne de validation des communications :
- Messages techniques internes : validation par l'Incident Commander
- Messages clients : validation par le Responsable communication + PCA
- Messages aux autorités : validation par le référent juridique
- Maintenir un journal de communication horodaté pendant toute la durée de l'incident
- Documenter l'alignement du PRA avec les cadres de conformité applicables :
- SOC 2 :
- A1.2 — Recovery Planning : existence d'un plan de reprise documenté et validé
- A1.3 — Recovery Testing : tests réguliers du plan avec résultats documentés
- ISO 27001 :
- A.5.29 — Sécurité de l'information pendant une perturbation
- A.5.30 — Préparation des TIC pour la continuité d'activité
- A.8.13 — Sauvegarde des informations
- A.8.14 — Redondance des moyens de traitement de l'information
- ISO 22301 (Continuité d'activité) :
- Clause 8.4 — Établissement et mise en œuvre de procédures de continuité d'activité
- Clause 8.5 — Exercices et tests
- RGPD :
- Article 32 — Sécurité du traitement (capacité à restaurer la disponibilité des données à caractère personnel en temps utile)
- Article 33 — Notification d'une violation de données à l'autorité de contrôle (sous 72h)
- Article 34 — Communication d'une violation à la personne concernée
- NIS2 :
- Obligations de gestion des risques cyber et de notification d'incident
- Exigence de continuité des services essentiels
- DORA (si secteur financier) :
- Tests de résilience opérationnelle numérique
- Reporting aux régulateurs financiers
- Lister les preuves d'audit à produire et maintenir :
- Rapports de tests DR datés et signés (chronologie, RTA/RPA mesurés, écarts constatés)
- Journaux de restauration horodatés
- Matrices RTO/RPO signées par la direction et les responsables métiers
- Inventaire des sauvegardes avec preuves d'intégrité (checksums, résultats de tests de restauration)
- Registre des incidents ayant activé le PRA (chronologie, décisions, résultats)
- Preuves de formation des équipes techniques aux procédures DR
- Indiquer la fréquence des audits internes (au moins annuel) et la date du prochain audit externe planifié
- Prévoir un dossier d'audit permanent, maintenu à jour en continu
- Définir le calendrier de test du PRA avec une montée en complexité progressive :
- Objectif : valider le processus décisionnel, la chaîne d'escalade et la coordination avec le PCA
- Format : simulation sur table d'un scénario de crise (pas de manipulation technique réelle)
- Participants : cellule de crise technique + liaison PCA
- Durée : 2 à 3 heures
- Critères de succès : activation de la cellule < 15 min, identification de la stratégie DR < 30 min, estimation du RTA cohérente
- Objectif : vérifier le fonctionnement d'un composant DR spécifique (restauration d'une base, déploiement IaC en DR, basculement DNS)
- Format : exécution réelle sur l'infrastructure DR (sans impact sur la production)
- Participants : équipe technique concernée
- Durée : 2 à 4 heures
- Critères de succès : composant restauré/basculé dans les délais du RTO, intégrité des données vérifiée
- Objectif : valider la capacité à basculer l'ensemble du trafic vers le site DR
- Format : basculement effectif de tout ou partie du trafic production vers le site DR (pendant une fenêtre de maintenance planifiée)
- Participants : cellule technique complète + monitoring renforcé
- Durée : 4 à 8 heures (incluant le failback)
- Critères de succès : RTA ≤ RTO contractuel, RPA ≤ RPO contractuel, aucun impact utilisateur visible (ou impact maîtrisé et communiqué)
- Objectif : tester le PRA de bout en bout en conditions réalistes, en coordination avec le PCA
- Format : scénario de crise complet incluant détection, qualification, activation PRA + PCA, basculement, communication client (simulée ou réelle), failback
- Participants : toutes les parties prenantes (technique, direction, communication, support client)
- Durée : 1 journée complète
- Critères de succès : respect de tous les objectifs RTO/RPO, communication client conforme aux modèles, coordination PCA/PRA fluide
- Documenter les résultats dans un rapport standardisé :
- Chronologie détaillée des actions
- RTA et RPA mesurés vs objectifs
- Écarts constatés et causes racines
- Recommandations et actions correctives avec owners et deadlines
- Intégrer les résultats dans le processus d'amélioration continue (chapitre 15)
¶ 15. Maintenance et amélioration continue
- Décrire le processus de mise à jour du PRA :
- Révision trimestrielle planifiée :
- Vérification de l'annuaire d'urgence (contacts à jour)
- Vérification de la parité de configuration entre production et DR (drift detection)
- Revue des résultats du dernier exercice
- Mise à jour immédiate après :
- Tout changement significatif d'architecture (nouveau service, migration cloud, nouveau provider tiers)
- Toute modification des objectifs RTO/RPO (évolution contractuelle, nouveau client critique)
- Tout incident ayant activé le PRA (intégration du retour d'expérience)
- Tout exercice révélant des écarts significatifs
- Revue annuelle complète avec validation par la direction technique et la direction générale
- Indiquer le responsable de la maintenance du document (propriétaire unique identifié)
- Formaliser le processus de validation des modifications :
- Revue technique par l'équipe infrastructure
- Validation par le RSSI (volet sécurité)
- Approbation par le sponsor exécutif (volet budgétaire et engagement)
- Intégrer un processus d'amélioration continue basé sur :
- Les résultats des exercices (chapitre 14) et le suivi des actions correctives
- Les retours d'incidents réels (post-mortem)
- Les évolutions des bonnes pratiques et standards (ISO 22301, ISO 27001)
- Les audits internes et externes
- La veille technologique (nouvelles fonctionnalités DR des cloud providers)
- Prévoir un registre des versions avec historique des changements :
- Date de modification
- Auteur
- Nature du changement
- Version précédente archivée
- Documenter le niveau d'automatisation des procédures DR et les objectifs de progression :
- Inventorier les procédures automatisées vs manuelles pour chaque étape du basculement
- Identifier les goulots d'étranglement manuels (étapes nécessitant une intervention humaine)
- Détection : alerting automatisé avec corrélation d'événements (réduction du temps de détection)
- Basculement : scripts ou pipelines d'activation du site DR exécutables en une commande (Terraform apply, ArgoCD sync, scripts Ansible)
- Vérification : suites de tests automatisés post-basculement (smoke tests, tests d'intégrité, tests de charge)
- Failback : automatisation de la resynchronisation et du retour à la production
- Intégrer des pratiques de chaos engineering pour tester la résilience en continu :
- Injection de pannes contrôlées (kill d'instances, simulation de latence réseau, corruption de données test)
- Outils : Chaos Monkey (Netflix), Litmus (Kubernetes), AWS Fault Injection Simulator
- Cadence : mensuelle sur les composants non critiques, trimestrielle sur les composants critiques (en fenêtre de maintenance)
- Documenter les enseignements tirés et les améliorations apportées suite à chaque exercice de chaos
- Mettre en place des contrôles automatisés pour détecter la dérive de configuration entre production et DR :
- Drift detection Terraform/OpenTofu planifiée (quotidienne)
- Comparaison des configurations Kubernetes (namespace, deployments, configmaps, secrets)
- Alertes si une divergence est détectée
- Processus de remédiation : correction automatique ou manuelle selon la nature de la dérive
- Lister tous les contacts critiques pour la gestion de la reprise technique :
- Cellule technique de crise : nom, rôle, téléphone personnel, email alternatif, handle messagerie chiffrée
- Remplaçants désignés pour chaque rôle technique
- Support cloud enterprise : numéro de support premium, account manager, procédure d'ouverture de ticket P1 (AWS Enterprise Support, GCP Premium Support, Azure Unified Support)
- Fournisseurs tiers critiques : CDN (Cloudflare, CloudFront), DNS (Route 53, Cloudflare), provider d'authentification (Auth0, Okta), provider de paiement (Stripe), provider de monitoring (Datadog, New Relic)
- Prestataires de sécurité : SOC externe, cabinet d'analyse forensique, CERT
- Autorités de régulation : CNIL (notification de violation de données), ANSSI (signalement d'incident de sécurité)
- Assureurs cyber : numéro de déclaration de sinistre, conditions d'activation
- Préciser pour chaque prestataire :
- Le numéro d'incident 24/7
- Le SLA de réponse contractuel (temps de première réponse, temps de résolution)
- Le niveau de support souscrit
- Le numéro de contrat ou identifiant client
- Stocker une version imprimée et une version numérique hors SI :
- Copie papier en coffre-fort physique (accès restreint)
- Clé USB chiffrée conservée par l'Incident Commander et son remplaçant
- Copie dans un outil indépendant du SI principal (ex : Google Doc restreint sur un compte dédié)
- Mettre à jour cet annuaire à chaque révision trimestrielle du PRA
- Fournir une fiche réflexe synthétique (1 à 2 pages) pour chaque scénario technique majeur :
- Actions immédiates : isolation réseau des systèmes compromis, coupure des réplications (pour protéger le site DR), préservation des preuves forensiques
- Évaluation : identification du périmètre de compromission, vérification de l'intégrité des sauvegardes et du site DR
- Reprise : restauration depuis la dernière sauvegarde saine (antérieure à la compromission), rotation de tous les secrets et credentials
- Vérification : scan complet de l'environnement restauré, tests d'intégrité, surveillance renforcée post-reprise
- Communication : notification CNIL si fuite de données, information clients
- Actions immédiates : vérification du diagnostic auprès du fournisseur (status page, support P1), évaluation de l'ETA de résolution
- Décision : activation du basculement DR si ETA > seuil acceptable ou si ETA inconnu
- Basculement : exécution du runbook de basculement (scaling DR, redirection DNS, vérification d'intégrité)
- Stabilisation : monitoring du site DR, traitement des anomalies
- Failback : resynchronisation et retour au site primaire une fois la région restaurée
¶ Scénario 3 — Erreur humaine majeure (suppression / corruption de données)
- Actions immédiates : arrêt des opérations d'écriture sur les données concernées, identification précise du périmètre de perte
- Évaluation : identification du point de restauration optimal (snapshot, PITR)
- Restauration : restauration ciblée des données perdues (restauration partielle si possible, pour minimiser l'impact)
- Vérification : réconciliation des données restaurées, tests fonctionnels
- Post-incident : analyse root cause, mise en place de garde-fous (confirmation de suppression, soft delete, PITR systématique)
- Actions immédiates : activation des protections DDoS (AWS Shield Advanced, Cloudflare Under Attack Mode), analyse du type d'attaque (volumétrique, applicatif)
- Mitigation : mise en place de rules WAF spécifiques, rate limiting, geo-blocking si pertinent
- Escalade : contact du support cloud / CDN pour mitigation avancée si nécessaire
- Monitoring : surveillance de l'efficacité des mesures, ajustement en temps réel
- Post-incident : renforcement des protections permanentes, debriefing
- Actions immédiates : vérification du diagnostic (status page du fournisseur, test manuel), évaluation de l'impact sur le service SaaS
- Activation du fallback : bascule vers le service alternatif pré-configuré (si disponible) ou activation du mode dégradé
- Communication : notification aux clients impactés, mise à jour de la status page
- Suivi : monitoring de la résolution chez le fournisseur, préparation du retour à la configuration nominale
- Post-incident : évaluation de la pertinence du fournisseur, renforcement des alternatives
- Chaque fiche doit être utilisable de manière autonome par l'Incident Commander, même sans accès au document complet
- Liste séquentielle des actions à effectuer après la reprise :
- Vérification complète de l'intégrité des données (checksums, tests fonctionnels, réconciliation des transactions)
- Vérification de la posture de sécurité de l'environnement restauré :
- Scan de vulnérabilités
- Recherche d'indicateurs de compromission (IoC)
- Vérification des droits d'accès et des credentials
- Calcul des métriques de reprise réelles :
- RTA (Recovery Time Actual) vs RTO
- RPA (Recovery Point Actual) vs RPO
- Volume de données perdues le cas échéant
- Notification formelle de la fin de l'incident :
- Cellule de crise PCA
- Clients impactés
- Autorités si notification initiale effectuée
- Réconciliation financière :
- Calcul des pénalités SLA éventuelles (SLA credits)
- Évaluation des coûts directs de l'incident (infrastructure DR, heures supplémentaires, prestataires)
- Déclaration assurance cyber si applicable
- Analyse post-mortem formelle (root cause analysis) :
- Chronologie complète de l'incident (timeline)
- Identification de la cause racine
- Évaluation de l'efficacité des procédures PRA activées
- Identification des écarts entre le plan et la réalité
- Mise à jour du PRA avec les enseignements tirés (lessons learned)
- Planification des actions correctives avec responsables (owners) et échéances (deadlines)
- Révocation des accès d'urgence (break glass) utilisés pendant l'incident
- Archivage du dossier d'incident complet (journal d'incident, journal de communication, décisions, métriques)
- Définir tous les termes techniques et métier utilisés dans le document :
- AZ (Availability Zone) : zone de disponibilité — datacenter isolé au sein d'une région cloud
- BIA (Business Impact Analysis) : analyse d'impact métier — évaluation des conséquences d'une interruption de service
- Break glass : procédure d'accès d'urgence contournant les mécanismes d'authentification habituels
- Chaos engineering : discipline consistant à injecter des pannes contrôlées pour tester la résilience
- Cold standby : stratégie DR sans infrastructure de secours permanente (reconstruction depuis les sauvegardes)
- Configuration drift : dérive de configuration entre deux environnements censés être identiques
- DORA (Digital Operational Resilience Act) : règlement européen sur la résilience opérationnelle numérique (secteur financier)
- DRP (Disaster Recovery Plan) : plan de reprise après sinistre (équivalent anglais du PRA)
- Failback : retour du trafic et des services vers le site primaire après un basculement DR
- Failover : basculement du trafic et des services vers le site de secours
- Hot standby : stratégie DR avec un environnement de secours réplique complète de la production
- IaC (Infrastructure as Code) : gestion de l'infrastructure par du code versionné
- IC (Incident Commander) : responsable de la coordination technique de l'incident
- IoC (Indicator of Compromise) : indicateur de compromission — signe technique d'une intrusion
- ISO 22301 : norme internationale pour les systèmes de management de la continuité d'activité
- ISO 27001 : norme internationale pour les systèmes de management de la sécurité de l'information
- KMS (Key Management Service) : service de gestion des clés de chiffrement
- MTPD (Maximum Tolerable Period of Disruption) : durée maximale tolérable d'interruption avant dommage irréversible
- Multi-région : déploiement sur plusieurs régions géographiques d'un cloud provider
- NIS2 : directive européenne sur la sécurité des réseaux et des systèmes d'information (v2)
- PAS (Plan d'Assurance Sécurité) : document formalisant les engagements et mesures de sécurité
- PCA (Plan de Continuité d'Activité) : plan organisationnel de maintien des activités pendant un incident
- Pilot light : stratégie DR avec les composants essentiels (données) répliqués mais les couches applicatives non déployées
- PITR (Point-in-Time Recovery) : restauration d'une base de données à un instant précis dans le passé
- PRA (Plan de Reprise d'Activité) : plan technique de restauration des systèmes d'information
- RGPD : Règlement Général sur la Protection des Données
- RPA (Recovery Point Actual) : perte de données réellement constatée lors d'un test ou d'un sinistre
- RPO (Recovery Point Objective) : perte de données maximale admissible, exprimée en durée
- RTA (Recovery Time Actual) : temps de reprise réellement constaté lors d'un test ou d'un sinistre
- RTO (Recovery Time Objective) : délai maximal acceptable entre le sinistre et la restauration du service
- Runbook : procédure opérationnelle pas à pas pour réaliser une tâche technique
- SOC 2 : framework d'audit de sécurité pour les fournisseurs de services (Trust Services Criteria)
- SPOF (Single Point of Failure) : point de défaillance unique — composant dont la panne entraîne l'arrêt du service
- WAL (Write-Ahead Log) : journal de transactions d'une base de données, utilisé pour le PITR
- Warm standby : stratégie DR avec un environnement de secours réduit, capable de monter en charge lors du basculement
- WORM (Write Once Read Many) : stockage immuable empêchant la modification ou suppression des données
- Ajouter les noms internes des services, environnements et outils utilisés dans l'architecture spécifique de la solution SaaS