Flux de récupération d’un jeu de données chiffré : clés, montages, instantanés et tests de restauration

L’approche sûre consiste à traiter un processus de récupération qui protège le matériel cryptographique, importe les données en toute sécurité, charge la racine de chiffrement correcte et prouve la réussite d’une restauration distincte comme une suite de contrôles observables, et non comme une seule commande.

Sur un jeu de données ZFS chiffré sur un NAS domestique, le risque concret est qu’un jeu de données chiffré ne soit pas monté ou que ses instantanés ne puissent pas encore être considérés comme des données récupérables. Notez l’identité actuelle et le point de récupération, commencez par le discriminateur le moins invasif, interprétez les résultats positifs et négatifs avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le processus ci-dessous ne s’achève qu’une fois que la charge de travail d’origine fonctionne ou que les éléments disponibles atteignent une limite nécessitant une escalade.

Protéger les clés et consigner l’état de l’échec

Arrêtez les importations automatisées, la réplication, les opérations de scrubbing et les écritures des applications jusqu’à ce que l’échec soit compris. Notez le pool, la hiérarchie des jeux de données, la racine de chiffrement, le format et l’emplacement de la clé, le dernier point de montage connu, l’erreur exacte et indiquez si la clé a déjà été testée sur un autre hôte de récupération.

Le chiffrement natif de ZFS sépare le chargement de la clé du montage du jeu de données. Le fonctionnement des racines de chiffrement et des clés ZFS décrit les racines de chiffrement et les clés héritées. C’est pourquoi fournir une clé valide au mauvais enfant ou supposer que chaque jeu de données chiffré possède une clé indépendante peut conduire à des tentatives de récupération trompeuses.

Créez des copies protégées des fichiers de clés et des notes de récupération sans afficher de secrets dans l’historique du terminal ou les journaux d’assistance. Arrêtez-vous immédiatement si aucune clé vérifiée ni sauvegarde n’existe, si les périphériques du pool sont instables ou si une commande propose une réparation destructive.

Importer le pool sans exposer les chemins de production

Sur l’hôte de récupération, confirmez l’identité des périphériques et importez le pool avec une racine alternative ou sans monter les jeux de données sur des chemins actifs. Inspectez l’état du pool et les propriétés des jeux de données avant de charger les clés. La réussite de l’importation du pool prouve uniquement que les métadonnées du pool sont lisibles, et non que le contenu chiffré peut être déchiffré.

Vérifiez récursivement encryptionroot, keystatus, keylocation, canmount et mountpoint. Chargez la clé uniquement pour la racine de chiffrement prévue, puis vérifiez que son état passe à disponible avant de tenter un montage contrôlé sous un chemin isolé.

Si le chargement de la clé échoue, faites la distinction entre un matériel cryptographique incorrect, un emplacement de clé inaccessible et des métadonnées chiffrées endommagées, plutôt qu’un simple conflit de point de montage. Conservez l’erreur exacte et ne réessayez qu’après avoir modifié une seule cause connue ; les suppositions répétées peuvent empêcher les opérateurs d’obtenir des éléments fiables.

Inspecter les instantanés sans modifier la source

Répertoriez les instantanés et confirmez que le point de récupération attendu existe. Si le pool source est suffisamment sain, clonez l’instantané sélectionné ou répliquez-le vers un stockage distinct au lieu de monter le jeu de données de production en lecture-écriture. Conservez l’instantané d’origine immuable pendant l’analyse.

La réplication chiffrée brute peut préserver le texte chiffré et les propriétés de chiffrement, mais le côté destinataire a toujours besoin de la hiérarchie de clés correspondante. Une réplication ZFS chiffrée brute indépendante illustre la différence entre un envoi chiffré brut et un flux normal. Choisissez donc délibérément au lieu de supposer que chaque jeu de données reçu se déverrouillera de la même manière.

Utilisez le processus ZimaSpace voisin pour restaurer un instantané sur un système de fichiers plus petit lorsque la capacité cible diffère de celle de la source. Ici, le contrôle est plus simple : l’instantané choisi doit être accessible, la clé doit se charger et la copie de test ne doit pas remplacer un point de montage existant.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaurer vers une cible isolée et prouver la lisibilité

Restaurez ou clonez le point sélectionné vers un jeu de données distinct doté d’un point de montage temporaire. Comparez les hachages de fichiers représentatifs, les ACL, les attributs étendus, les propriétaires, les fichiers clairsemés et les données des applications. Pour une base de données, restaurez sa sauvegarde native ou démarrez une instance copiée sur des ports isolés au lieu d’ouvrir directement les fichiers de production.

Redémarrez l’environnement de récupération, ou exportez-le puis réimportez-le, rechargez la clé depuis l’emplacement documenté et répétez le montage. Cela prouve que la réussite ne dépendait pas d’une clé mise en cache, d’un état ponctuel du shell ou d’un montage accidentel hérité de la production.

La récupération est terminée uniquement lorsqu’un autre opérateur peut suivre la procédure relative à la clé, monter le jeu de données prévu et restaurer des données vérifiées sans l’hôte d’origine. Procédez à une escalade lorsque les clés sont indisponibles, que le déchiffrement échoue sur chaque copie protégée ou que des erreurs de périphérique apparaissent ; aucune réparation du système de fichiers ne peut reconstituer des clés de chiffrement manquantes.