Sauvegarde et reprise après sinistre pour les charges de travail cloud classifiées : RTO, RPO et continuité cryptographique

Les charges de travail cloud militaires classifiées ne sont pas des actifs abstraits. Elles font tourner les pipelines de ciblage, le tissu de communications et les couches de fusion du renseignement qui déterminent si une unité maintient une conscience situationnelle sous le feu. Lorsque ces charges de travail tombent en panne — et le matériel tombe en panne, les installations perdent leur alimentation, les adversaires sondent chaque surface accessible — l'organisation a besoin d'un plan de reprise testé et exécutable qui les restaure dans le délai que la mission peut tolérer. La sauvegarde et la reprise après sinistre pour les systèmes classifiés n'est pas une version allégée du DR commercial ; il s'agit d'une discipline d'ingénierie distincte, façonnée par les contraintes d'accréditation, les dépendances cryptographiques des clés et la réalité opérationnelle que les systèmes les plus urgents à restaurer sont ceux qui sont les plus difficiles à remettre en service sous pression.

Cet article examine l'ensemble de la pile de reprise pour les charges de travail cloud classifiées : comment dériver les objectifs RTO et RPO à partir des niveaux de criticité de la mission, comment concevoir une architecture de sauvegarde qui respecte les périmètres de classification, comment gérer les clés de chiffrement pour qu'elles survivent à une défaillance du site principal, comment sauvegarder les bases de données et les clusters Kubernetes, comment tester la reprise dans des environnements qui restreignent l'accès physique, et comment rétablir la continuité cryptographique une fois les systèmes restaurés. Le traitement est technique et opérationnel — les décisions ici appartiennent aux ingénieurs de plateforme, aux officiers de sécurité des systèmes d'information (ISSO) et aux architectes de programme qui travaillent ensemble.

Exigences RTO et RPO pour les systèmes militaires C2 et ISR

L'objectif de délai de reprise (RTO) et l'objectif de point de reprise (RPO) ne sont pas des accords de niveau de service informatique importés d'un modèle commercial. Pour les systèmes de défense classifiés, ils sont dérivés du tempo opérationnel — le rythme auquel les commandants ont besoin de données actuelles pour prendre des décisions — et de la criticité de la mission, qui détermine combien de temps une capacité peut être absente avant que la mission ne se dégrade à un niveau inacceptable.

Un cadre de criticité pratique répartit les systèmes en trois niveaux :

• Niveau 1 — C2 mission-essentiel et ISR en temps réel. Plateformes de commandement et de contrôle, fusion de capteurs en temps réel et systèmes de ciblage actif. RTO : inférieur à quatre heures. RPO : inférieur à 15 minutes. Un système C2 indisponible plus de quatre heures lors d'une opération active compromet la capacité du commandant à émettre, suivre et réviser les ordres. Un RPO supérieur à 15 minutes implique une perte potentielle de données de ciblage ou de situation récentes qui ne peuvent pas être reconstituées.
• Niveau 2 — Analyse ISR et systèmes d'appui à la mission. Postes de travail d'analyse du renseignement, enregistrement des communications et gestion logistique. RTO : 8 à 24 heures. RPO : une à quatre heures. Ces systèmes soutiennent la planification et l'évaluation de la mission plutôt que l'exécution en temps réel ; leur absence dégrade l'efficacité mais n'arrête pas immédiatement les opérations.
• Niveau 3 — Systèmes administratifs et d'archivage. Systèmes du personnel, stockage d'archives et applications administratives. RTO : 48 à 72 heures. RPO : 24 heures. Une indisponibilité prolongée est opérationnellement tolérable ; une perte de données allant jusqu'à un jour ouvrable est acceptable.

L'implication de conception critique de l'attribution au niveau est que les objectifs RTO de niveau 1 — restauration en moins de quatre heures — ne sont réalisables qu'avec des architectures de secours chaud ou tiède. La sauvegarde à froid (sauvegarde sur bande ou disque sans serveur de secours en fonctionnement) introduit des étapes de reprise qui, prises ensemble, ne peuvent pas être achevées en quatre heures : récupération des supports, provisionnement de l'infrastructure, restauration du système d'exploitation, restauration de la couche applicative, vérification des contrôles de sécurité et approbation de l'ISSO. Un programme qui croit disposer d'un RTO de quatre heures grâce à la sauvegarde à froid seule n'a pas modélisé la procédure de reprise réelle.

Le budget RTO doit être décomposé par phase et additionné avant d'être adopté comme objectif :

Phase de reprise	Secours chaud	Secours tiède	Sauvegarde froide
Décision de basculement et autorisation	5–15 min	15–30 min	30–60 min
Récupération des supports / des clés	N/A (réplique en direct)	15–30 min	60–180 min
Restauration de l'infrastructure et du système d'exploitation	0–15 min	30–60 min	60–120 min
Restauration des applications et des données	0–5 min	20–60 min	60–240 min
Vérification des contrôles de sécurité + approbation ISSO	30–60 min	60–90 min	60–120 min

L'étape de vérification des contrôles de sécurité — confirmant que les marquages de classification, la journalisation d'audit, les contrôles d'accès et les liaisons cryptographiques fonctionnent correctement sur le système restauré — est fréquemment omise des modèles RTO commerciaux. Pour les systèmes classifiés, elle est obligatoire avant le retour aux opérations. Un objectif RTO précis en tient compte.

Architecture de sauvegarde pour les charges de travail classifiées

L'architecture de sauvegarde des charges de travail classifiées part de deux contraintes non négociables : l'isolation du périmètre de classification et la continuité de l'accréditation. Chaque enclave de classification nécessite une infrastructure de sauvegarde physiquement séparée — nœuds de stockage séparés, supports séparés, instances logicielles de sauvegarde séparées si le logiciel utilise un plan de gestion partagé. Une infrastructure de sauvegarde consolidée qui couvre plusieurs enclaves constitue une violation de conformité, qu'elles que soient les données de sauvegarde chiffrées, car le plan de gestion partagé crée un canal caché potentiel et une surface d'attaque étendue.

La continuité de l'accréditation signifie que l'environnement de restauration — l'infrastructure sur laquelle les données classifiées sont restaurées lors d'un sinistre — doit disposer d'une autorisation de fonctionnement (ATO) en cours de validité avant le sinistre, et pas seulement après. L'échec DR classifié le plus fréquent dans les rapports post-incident n'est pas une sauvegarde manquante ; c'est une sauvegarde qui existe mais qui ne peut pas légalement être restaurée dans le délai requis parce que l'ATO de l'environnement de restauration a expiré.

Le stockage de sauvegarde immuable est un contrôle obligatoire pour les charges de travail classifiées de niveau 1 et de niveau 2. L'immuabilité — appliquée au niveau matériel ou firmware via des supports en écriture unique ou le verrouillage d'objets en mode conformité — garantit qu'un acteur de ransomware ou un initié malveillant qui compromet l'infrastructure de sauvegarde ne peut pas supprimer ou modifier les jeux de sauvegarde. Un WORM appliqué par logiciel pouvant être contourné par un compte privilégié ne satisfait pas à cette exigence. Pour le stockage classifié sur site, une bande WORM matérielle (LTO avec cartouches WORM) ou un appareil de disque avec immuabilité au niveau firmware est le choix approprié. Pour les déploiements cloud classifiés souverains, le stockage d'objets avec verrouillage d'objets compatible S3 en mode conformité offre une protection équivalente.

Une architecture à trois couches satisfait l'ensemble des scénarios de reprise :

• Couche 1 — Sauvegarde immuable locale. Sauvegardes incrémentielles continues ou horaires vers un stockage WORM local dans l'installation accréditée. Protège contre les erreurs opérationnelles : suppression accidentelle, corruption de base de données, ransomware. Chemin de restauration le plus rapide pour les pannes non catastrophiques.
• Couche 2 — Réplication synchrone vers un secours tiède. Pour les systèmes de niveau 1, les journaux de transactions de base de données et les états critiques sont répliqués vers un nœud secondaire dans la même installation accréditée ou une installation co-localisée. Cette couche prend en charge un RTO inférieur à quatre heures. La réplication se situe dans le périmètre d'accréditation — le nœud secondaire fait partie du même environnement accrédité.
• Couche 3 — Copie hors site périodique vers l'installation DR. Copies de sauvegarde chiffrées hebdomadaires ou mensuelles transférées vers une installation accréditée physiquement séparée. Cette couche protège contre la perte catastrophique du site principal. Pour le cloud de bord tactique en mode déconnecté, ce transfert est physique — supports chiffrés transportés par un coursier autorisé — et le temps de transit du coursier doit être inclus dans le calcul du RTO pour le scénario DR qu'il couvre.

Les sites DR à espace d'air introduisent un défi de conception spécifique : la copie hors site est toujours en retard sur le système principal de l'intervalle entre les transferts physiques. Un programme qui transfère des supports de sauvegarde vers son site DR chaque semaine présente une fenêtre de perte de données potentielle pouvant aller jusqu'à sept jours pour le scénario où le site principal est détruit. Cet écart doit être documenté, accepté par l'autorité de mission et reflété dans le plan de contingence du système — et non dissimulé dans l'architecture.

Chiffrement des données de sauvegarde : gestion des clés jusqu'à la reprise

Chaque jeu de sauvegarde pour une charge de travail classifiée doit être chiffré au repos avec AES-256 (ou l'équivalent national approuvé pour le niveau de classification du système). Le problème le plus difficile n'est pas le chiffrement lui-même — c'est de s'assurer que les clés de déchiffrement survivent à une défaillance du site principal et sont accessibles sur le site DR dans le délai budgété pour la reprise.

La hiérarchie de clés recommandée pour le chiffrement des sauvegardes classifiées comporte trois niveaux :

• Clé de chiffrement de clé (KEK). Une clé maîtresse détenue dans un module de sécurité matérielle (HSM) au sein de l'installation accréditée. La KEK ne quitte jamais le HSM en clair. L'accès à la KEK nécessite une autorisation multi-parties — au minimum deux personnes autorisées avec des identifiants d'authentification HSM séparés (un schéma de quorum m-de-n, généralement 2-de-3 ou 3-de-5).
• Clé de chiffrement des données (DEK). Une clé AES-256 unique générée par tâche de sauvegarde. La DEK chiffre les données de sauvegarde. Une fois la tâche de sauvegarde terminée, la DEK est chiffrée (enveloppée) par la KEK à l'intérieur du HSM et la DEK enveloppée est stockée avec les métadonnées de sauvegarde. La DEK en clair n'est jamais écrite sur disque.
• Séquestre de clé sur le site DR. La KEK est synchronisée avec un HSM secondaire sur le site DR, soit par réplication continue en cluster HSM, soit par une procédure de sauvegarde périodique des clés. Le HSM secondaire détient la KEK dans un environnement de sécurité équivalente et la libère aux opérateurs de restauration autorisés lors d'un sinistre déclaré, permettant le déballage des DEK sur site et le déchiffrement des sauvegardes.

La fréquence de synchronisation du séquestre détermine l'obsolescence maximale de la KEK du site DR. Pour les KEK en rotation (annuelle ou plus fréquente), la mise à jour du séquestre doit intervenir dans un délai d'une période de rotation. La procédure de séquestre — y compris les étapes d'authentification et d'autorisation requises pour que le HSM du site DR accepte la clé mise à jour — doit être documentée, et la documentation doit être stockée sur le site DR (et pas seulement sur le site principal).

Pour un contexte plus approfondi sur la sélection des HSM et les architectures de gestion des clés HSM post-quantiques qui offrent une résistance à long terme aux attaques quantiques sur le texte chiffré stocké, consultez le traitement lié. La hiérarchie de clés ci-dessus est compatible avec les algorithmes KEK post-quantiques (CRYSTALS-Kyber ou ML-KEM aux niveaux CNSA 2.0) sans modifier la relation structurelle entre les couches.

Un manuel DR qui n'a jamais été exercé de bout en bout — y compris l'authentification du HSM du site DR et le déballage des DEK — n'a pas validé son étape la plus sujette aux défaillances. La récupération des clés doit être exercée comme une étape nommée dans chaque répétition complète de restauration, et non laissée comme une capacité supposée acquise.

Stratégies de sauvegarde des bases de données pour les systèmes C2 opérationnels

Les systèmes C2 opérationnels persistent généralement leur état dans des bases de données relationnelles : PostgreSQL est le choix open-source dominant pour les déploiements cloud de défense accrédités. La sauvegarde commerciale standard d'une « vidange complète quotidienne plus des différentiels nocturnes » ne répond pas aux exigences RPO des systèmes de niveau 1 — un RPO de 15 minutes nécessite un mécanisme de sauvegarde continue qui capture chaque transaction validée.

Le journal des transactions (WAL) de PostgreSQL fournit ce mécanisme. Chaque modification validée de la base de données est écrite dans un segment WAL avant d'être appliquée aux fichiers de données. En archivant continuellement les segments WAL vers un stockage de sauvegarde accrédité immédiatement après leur écriture, vous accumulez un journal de modifications complet qui peut être rejoué depuis n'importe quelle sauvegarde de base jusqu'à n'importe quel point dans le temps — jusqu'au dernier segment archivé avant une panne. C'est la récupération à un point dans le temps (PITR).

Configuration dans postgresql.conf pour l'archivage WAL continu avec chiffrement :

wal_level = replica
archive_mode = on
archive_command = '/opt/backup/encrypt-wal.sh %p %f'
archive_timeout = 60        # forcer le changement de segment toutes les 60 secondes maximum
restore_command = '/opt/backup/decrypt-wal.sh %f %p'
recovery_target_time = '2026-06-25 14:30:00 UTC'  # défini dans recovery.conf

Le script encrypt-wal.sh doit chiffrer le segment WAL à l'aide de la DEK adossée au HSM avant d'écrire à l'emplacement d'archivage. Le paramètre archive_timeout de 60 secondes garantit que même lors des périodes de faible écriture, les segments WAL sont archivés au moins toutes les minutes, limitant le RPO à environ une minute dans des conditions normales.

Pour les systèmes C2 composés de plusieurs microservices partageant un état distribué — un modèle courant où les données de ciblage circulent entre un service de fusion de capteurs, un service d'aide à la décision et une passerelle de communications — la cohérence de la sauvegarde exige que les instantanés de toutes les bases de données des services soient pris au même point logique dans le temps. Un jeu de sauvegarde dans lequel la mise à jour de ciblage existe dans la base de données de contrôle de tir mais pas encore dans la base de données de fusion ISR produit un état de restauration logiquement incohérent. Des instantanés cohérents entre les microservices sont obtenus grâce à :

• Un coordinateur d'instantanés distribué qui émet un signal de mise en veille à tous les services, attend la fin des transactions en cours, déclenche des instantanés sur toutes les bases de données simultanément, puis libère la mise en veille.
• Des hooks pré-sauvegarde dans l'orchestrateur de conteneurs qui appellent l'API de mise en veille de chaque service avant le déclenchement de l'instantané de volume.
• Un numéro de séquence ou un identifiant de transaction global estampillé dans chaque jeu d'instantanés, permettant aux procédures de restauration de vérifier que tous les composants d'un jeu de restauration partagent le même horodatage logique avant de procéder à la restauration.

Sauvegarde des charges de travail Kubernetes

Velero est l'outil open-source standard pour la sauvegarde des charges de travail Kubernetes, tant dans les contextes commerciaux que de défense. Dans un cluster classifié à espace d'air, le déploiement de Velero nécessite des adaptations spécifiques : toutes les images de conteneurs Velero, les images de plugins (notamment le plugin CSI et tout plugin de fournisseur de stockage d'objets) et le binaire CLI Velero doivent être pré-stockés dans le registre d'images local du cluster avant un sinistre, car le cluster ne peut pas extraire des registres externes pendant la reprise.

Velero sauvegarde les objets de l'API Kubernetes — Deployments, DaemonSets, Services, ConfigMaps, Secrets, PersistentVolumeClaims, NetworkPolicies, objets RBAC et ressources personnalisées — et déclenche des instantanés de volumes CSI pour les données persistantes. Un calendrier de sauvegarde Velero pour un cluster classifié :

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: classified-cluster-hourly
  namespace: velero
spec:
  schedule: "0 * * * *"          # toutes les heures
  template:
    storageLocation: classified-backup-location
    volumeSnapshotLocations:
      - classified-csi-snapshots
    includedNamespaces:
      - c2-platform
      - isr-fusion
      - comms-gateway
    hooks:
      resources:
        - name: db-quiesce
          includedNamespaces:
            - c2-platform
          labelSelector:
            matchLabels:
              app: postgres
          pre:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_start_backup('velero', true);"
                timeout: 60s
          post:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_stop_backup();"
                timeout: 60s
    ttl: 720h                    # rétention de 30 jours

Ce que Velero ne sauvegarde pas : l'état etcd (Velero lit depuis le serveur API, pas directement depuis etcd), la configuration du système d'exploitation au niveau des nœuds, les binaires du plan de contrôle et les données écrites dans le stockage local des nœuds en dehors des volumes persistants. etcd doit être sauvegardé séparément. Pour un plan de contrôle à trois nœuds, exécutez ce qui suit sur chaque nœud du plan de contrôle et chiffrez le résultat :

ETCDCTL_API=3 etcdctl snapshot save \
  /tmp/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Chiffrer l'instantané avant archivage
gpg --symmetric --cipher-algo AES256 \
  --batch --passphrase-file /etc/backup/etcd-key.txt \
  /tmp/etcd-snapshot-*.db

# Vérifier l'intégrité de l'instantané
etcdctl snapshot status /tmp/etcd-snapshot-*.db

Les instantanés etcd doivent être planifiés toutes les heures sur tous les nœuds du plan de contrôle, les instantanés chiffrés étant écrits dans le même stockage de sauvegarde accrédité utilisé pour les sauvegardes Velero. Une stratégie DR Kubernetes complète nécessite à la fois Velero (pour l'état de la couche de charge de travail) et les instantanés etcd (pour l'état de la couche du cluster). La restauration d'un seul produit un cluster irrécupérable — les objets API dans etcd et les données persistantes dans les volumes doivent être cohérents l'un avec l'autre.

Les stratégies d'instantané de PersistentVolumeClaim dépendent de la classe de stockage utilisée. Pour le stockage adossé à CSI dans les environnements classifiés, le pilote de stockage doit implémenter l'interface d'instantané CSI et les instantanés doivent être stockés dans un stockage accrédité. Pour le stockage NFS ou hérité qui ne prend pas en charge les instantanés CSI, le mode de sauvegarde de système de fichiers de Velero (basé sur Kopia) peut sauvegarder les données PVC en copiant directement les fichiers depuis les volumes montés — plus lent que les instantanés CSI mais applicable à tout type de stockage.

Test de reprise dans les environnements classifiés

Le test de reprise dans les environnements classifiés est plus contraint que dans les contextes commerciaux : vous ne pouvez pas démarrer un environnement cloud public arbitraire comme cible de restauration, vous ne pouvez pas tester avec des données de production en dehors du périmètre d'accréditation, et vous ne pouvez pas exécuter des répétitions de restauration pendant les heures opérationnelles sans autorisation préalable et un plan de retour arrière testé.

Le calendrier d'exercices DR pour un programme classifié doit suivre une cadence à trois niveaux :

• Exercice sur table — trimestriel. L'équipe de restauration parcourt verbalement le manuel, identifiant les étapes peu claires, les rôles non pourvus ou les dépendances non documentées. Aucun système n'est touché. Résultat : un manuel mis à jour et une liste de lacunes à combler.
• Exercice fonctionnel — semestriel. Un sous-ensemble de la procédure de restauration est exécuté dans un environnement réel : par exemple, restaurer une seule base de données depuis la sauvegarde et vérifier l'intégrité des données, ou restaurer une sauvegarde Velero d'un espace de noms et confirmer que l'application démarre. Couverture partielle à moindre coût et risque qu'une répétition complète.
• Répétition complète de restauration — minimum annuelle, semestrielle pour le niveau 1. Une restauration complète de bout en bout depuis la sauvegarde vers un environnement de restauration en quarantaine. Toutes les phases de restauration sont exécutées, y compris la récupération des clés, la vérification des contrôles de sécurité et l'approbation de l'ISSO. Le RTO et le RPO réels sont mesurés et comparés aux objectifs.

La vérification de l'intégrité des données après restauration nécessite plus que la confirmation que la base de données démarre. Pour les bases de données relationnelles, la vérification de l'intégrité comprend :

# Vérifications d'intégrité post-restauration PostgreSQL
# 1. Vérifier que le nombre de lignes correspond aux valeurs attendues du journal d'audit pré-sauvegarde
psql -c "SELECT schemaname, tablename, n_live_tup
         FROM pg_stat_user_tables ORDER BY schemaname, tablename;"

# 2. Vérifier les violations de contraintes après restauration
psql -c "SELECT conname, conrelid::regclass
         FROM pg_constraint WHERE NOT convalidated;"

# 3. Vérifier que la rejouée WAL a atteint l'heure de reprise cible
psql -c "SELECT pg_last_xact_replay_timestamp();"

# 4. Exécuter le contrôle de santé au niveau applicatif
curl -sf https://c2-platform.internal/health/deep | jq '.checks'

La méthodologie de mesure du RTO doit être précise : le chronomètre commence lorsqu'un sinistre est formellement déclaré (pas lorsque la défaillance est détectée pour la première fois — la détection d'incident et la déclaration peuvent prendre 15 à 30 minutes et doivent être soustraites du budget restant). Le chronomètre s'arrête lorsque l'ISSO approuve formellement la disponibilité du système restauré pour les opérations classifiées — pas lorsque l'application renvoie son premier contrôle de santé réussi. La différence entre ces deux interprétations peut être de 60 à 90 minutes, ce qui peut déterminer si un programme respecte son engagement RTO contractuel ou réglementaire.

Continuité cryptographique après la reprise

Un système qui a été restauré depuis une sauvegarde n'est pas cryptographiquement identique au système qui a été sauvegardé. Selon le moment où la sauvegarde a été prise par rapport à la dernière rotation des clés, à l'émission du certificat ou à l'établissement de session, le système restauré peut fonctionner avec des éléments cryptographiques obsolètes qui sont expirés, révoqués ou incohérents avec l'état actuel des systèmes connectés. La continuité cryptographique est l'ensemble des procédures qui alignent l'état cryptographique du système restauré avec l'environnement opérationnel après la reprise.

Re-codage après basculement HSM. Lorsque le HSM principal tombe en panne et que le HSM secondaire du site DR prend le relais, la première étape consiste à vérifier que l'inventaire des clés du HSM secondaire est à jour. Pour les HSM qui utilisent la réplication continue en cluster, le secondaire doit être à jour à partir de la dernière pulsation de réplication — généralement en quelques secondes. Pour les HSM qui utilisent la sauvegarde périodique des clés, le secondaire peut avoir du retard de l'intervalle de sauvegarde. Toutes les clés créées ou pivotées depuis la dernière sauvegarde ne sont pas présentes dans le secondaire et doivent être redérivées ou réémises avant que les systèmes qui en dépendent puissent fonctionner. Un audit d'inventaire des clés — comparant la liste des clés du HSM secondaire avec le dernier journal d'audit du principal — est la première action cryptographique après le basculement HSM.

État des certificats après restauration. Les certificats de cluster Kubernetes et les certificats TLS d'application ont des dates d'expiration qui avancent indépendamment du fait que le système fonctionne. Un cluster restauré depuis une sauvegarde vieille de 30 jours est restauré dans un état où 30 jours ont été consommés sur la validité restante de chaque certificat. Si un certificat se trouvait à 30 jours de l'expiration au moment de la sauvegarde, il est expiré dans le cluster restauré. La procédure d'audit des certificats :

# Auditer l'expiration de tous les certificats du plan de contrôle Kubernetes
kubeadm certs check-expiration

# Renouveler les certificats du plan de contrôle expirés ou proches de l'expiration
kubeadm certs renew all

# Pour les certificats d'application cert-manager : forcer la réémission
# en supprimant les ressources Certificate et en laissant cert-manager les réémettre
kubectl get certificates -A -o json | \
  jq -r '.items[] | select(.status.notAfter < now | todate) |
         "\(.metadata.namespace)/\(.metadata.name)"' | \
  xargs -I{} kubectl delete certificate -n $(echo {} | cut -d/ -f1) \
                                           $(echo {} | cut -d/ -f2)

# Vérifier que cert-manager émet de nouveaux certificats
kubectl get certificaterequests -A --watch

Rétablissement des clés de session. Les clés de session — les clés symétriques éphémères négociées lors des poignées de main TLS et des établissements de canaux chiffrés — ne sont jamais stockées dans le HSM et ne sont jamais sauvegardées. Elles n'existent que dans la mémoire des processus communicants. Après une reprise qui restaure un système depuis une sauvegarde, toutes les sessions actives de l'instantané de sauvegarde ont disparu ; le système restauré n'a pas d'état de session. Les systèmes connectés — autres nœuds du cluster, capteurs distants, homologues C2 — tenteront de rétablir les sessions en utilisant les identifiants à long terme du système restauré (certificats et clés adossées au HSM). Si ces identifiants sont actuels et valides, le rétablissement de session est automatique et transparent. S'ils sont obsolètes ou expirés, le rétablissement de session échoue et chaque connexion doit être manuellement réinitialisée après la résolution du problème d'identifiants.

Procédures de re-codage post-reprise. Pour les systèmes où l'événement de reprise lui-même est traité comme un indicateur potentiel de compromission des clés — en particulier si la défaillance a été causée par un incident de sécurité plutôt que par une panne matérielle ou électrique — l'ISSO peut exiger un cycle complet de re-codage avant que le système ne reprenne les opérations classifiées. Le re-codage implique la génération de nouvelles KEK dans le HSM restauré, le re-chiffrement de toutes les DEK de données sous la nouvelle KEK et la distribution de nouveaux certificats à tous les systèmes connectés. Il s'agit d'un processus long qui doit être budgété dans le calendrier de reprise s'il y a une possibilité qu'il soit requis. Les documents de planification doivent traiter explicitement la décision re-codage versus reprise sur les clés existantes et définir les critères pour chaque chemin.

L'intersection de l'ingénierie de sauvegarde, de la gestion des clés et des opérations Kubernetes que nécessite le DR cloud classifié n'est servie par aucun outil ou framework unique. Elle est construite à partir d'une combinaison d'outils de sauvegarde au niveau plateforme (Velero, etcdctl, pg_basebackup), de gestion des clés intégrée aux HSM et de procédures opérationnelles qui ont été répétées dans des conditions qui se rapprochent de vrais sinistres. Les programmes qui investissent dans la cadence de répétition — et dans les rapports post-action honnêtes qui suivent — surpassent constamment ceux qui traitent le DR comme un exercice de documentation.