3 Récupération des données

La récupération après sinistre désigne le processus, les stratégies et les procédures liées à la préparation de la reprise ou de la continuité d'informations essentielles pour les activités d'une organisation après un sinistre naturel ou provoqué par un individu. Elle comprend les éléments suivants :

• Objectif de point de récupération (RPO, Recovery Point Objective) : moment de la récupération des données tel que défini dans un plan de continuité des activités. Il correspond généralement à la définition de ce que l'entreprise considère comme une "perte acceptable" en cas de sinistre. Il peut ainsi s'agir d'heures, de jours ou même de semaines.

• Objectif de délai de récupération (RTO, Recovery Time Objective) : délai durant lequel un processus métier doit être "restauré" après un sinistre (ou une interruption) afin d'éviter des conséquences inacceptables associées à une rupture de la continuité des activités. Il peut s'agir de quelques minutes si vous utilisez un réseau de service combiné. Voir la Figure 3-2.

OKM peut couvrir plusieurs sites éloignés géographiquement. Le risque de voir un sinistre détruire l'ensemble du cluster s'en trouve considérablement réduit. La mise en cluster des KMA permet la réplication des entrées de base de données et l'équilibrage des charges de travail. Même s'il est peut probable qu'un cluster entier doive être recréé, la plupart des données de clés peuvent être récupérées en recréant l'environnement OKM à partir d'une sauvegarde récente de la base de données.

Lors de l'élaboration d'une stratégie de chiffrement/d'archivage, il est important de s'assurer que les données essentielles générées sur les sites sont répliquées et archivées de façon sécurisée sur un site de récupération.

En cas de perte d'un site, ces données de sauvegarde peuvent être transférées vers un autre site opérationnel. Les unités de données et les clés associées aux volumes de bande sont alors connues des KMA sur le site frère et les données chiffrées requises pour poursuivre les opérations métier sont disponibles.

La partie endommagée du cluster peut être facilement restaurée au même emplacement ou à un emplacement différent après la reprise des opérations du site.

De nombreuses entreprises font appel aux services d'un site de récupération après sinistre tiers afin de pouvoir redémarrer leurs activités aussi rapidement que possible. Des tests de récupération après sinistre périodiques non annoncés montrent le degré de préparation de l'entreprise à la récupération après un sinistre, naturel ou provoqué par l'homme. Un certain nombre de scénarios possibles existent, dont certains sont traités ici.

Ressources partagées	Fournir des éléments rentables pour la récupération après sinistre
Réplication	Restauration par réplication à partir de KMA intacts
Scénario 1	Prépositionnement des KMA
Scénario 2	Partage des KMA
Scénario 3	Transferts de clés
Scénario 4	Restauration à partir de la sauvegarde
Méthodologie de sauvegarde	Des instructions utiles

Considérations sur la sauvegarde et le partage de clés

Les sauvegardes OKM et le partage de clés (importation/exportation) consomment de nombreuses ressources de la base de données et réduisent le temps de réponse sur le KMA durant la sauvegarde ou le transfert de clés.

Si possible, réduisez les charges de travail du lecteur de bande pendant la fenêtre de sauvegarde et de transfert OKM.

Si cela n'est pas possible, envisagez les options suivantes :

• Les sauvegardes et les transferts de clés OKM peuvent se produire sur tout KMA, mais il est préférable d'utiliser le même KMA à chaque fois. Il est fort probable que les tâches cron qui invoquent l'utilitaire de sauvegarde OKM soient de toute façon configurées de cette manière.

• Si le cluster est suffisamment grand, un KMA d'administration dédié peut être défini.

  • Ce KMA ne doit pas avoir de connexion au réseau de service pour ne pas avoir à gérer des demandes de clés de la part des lecteurs de bande, en particulier au moment des sauvegardes ou des transferts de clés.

  • Ce KMA peut également être utilisé pour les sessions de l'interface utilisateur graphique OKM, afin de décharger les autres KMA de la prise en charge des demandes liées à la gestion.

• Plus la connectivité du réseau de gestion du KMA de sauvegarde et de transfert de clés est rapide, plus il est capable de gérer la charge supplémentaire au moment des sauvegardes et des transferts de clés.

  Cela est vrai pour tous les KMA, mais particulièrement pour le KMA effectuant les sauvegardes, car il prend du retard sur le traitement des demandes de réplication lors des sauvegardes. Une connexion réseau rapide aide à minimiser le retard de réplication, dû par exemple à la latence.

• Placez le KMA de sauvegarde et de transfert de clés sur un site qui n'est pas utilisé par les lecteurs de bande. Les lecteurs de bande préfèrent alors d'autres KMA au sein du site auquel ils ont été affectés et évitent d'utiliser le KMA de sauvegarde et de transfert de clés.

• Ajoutez davantage de KMA aux sites contenant les lecteurs de bande de manière à ce que la charge des demandes de clés soit répartie sur un plus grand nombre de KMA. Vous réduisez ainsi le nombre de demandes de clés que le KMA de sauvegarde et de transfert de clés doit gérer.

Détermination de la taille d'un pool de clés

Les administrateurs OKM doivent connaître le nombre de clés créées par unité de temps dans le pire des cas et la durée des fenêtres de sauvegarde OKM et des fenêtres de transfert de clés.

Pour cette description, nous considérerons qu'un taux horaire de consommation de clés a été calculé.

Remarque:

Les KMA prégénèrent les clés, si bien qu'une demande de création de clés de la part d'un agent n'entraîne la création effective d'une clé sur le KMA qu'à partir du moment où le programme de maintenance du pool de clés s'exécute au sein du serveur. Lorsque le serveur est occupé, les opérations du programme de maintenance du pool de clés peuvent être retardées.

Le pool de clés du cluster doit être suffisamment grand pour que les KMA puissent distribuer les clés prégénérées depuis leur pool de clés durant les fenêtres de sauvegarde.

Lorsque la taille du pool de clés est trop petite, les KMA sont susceptibles d'épuiser leurs clés prégénérées et renvoyer des erreurs indiquant qu'aucune clé n'est prête. Dans ce cas, les lecteurs de bande basculent sur d'autres KMA, ce qui ajoute des perturbations supplémentaires aux performances de la fenêtre de sauvegarde/de transfert de clés.

La taille par défaut du pool de clés, qui s'élève à 1 000 clés, devrait être suffisante pour la plupart des clients, à moins que le taux de création de clés estimé dans le pire des cas pour les fenêtres de sauvegarde soit supérieur.

La fenêtre de sauvegarde OKM doit être surveillée périodiquement car elle va s'accroître progressivement en même temps que la base de données. Il peut s'avérer nécessaire de modifier la taille du pool de clés lorsque la fenêtre de sauvegarde dépasse un seuil. La taille du pool de clés doit également être modifiée si le taux de consommation de clés s'accroît en raison de changements dans la charge de travail globale des bandes.

Ressources partagées

Les ressources partagées peuvent fournir des éléments rentables pour la récupération après sinistre.

Les entreprises spécialisées dans la gestion d'enregistrements, la destruction de données et la continuité et récupération des données achètent des équipements que plusieurs clients peuvent utiliser à des fins diverses, notamment la sauvegarde et l'archivage.

Pour la récupération après sinistre, le client peut utiliser des lecteurs de bande, des bibliothèques et d'autres ressources d'un site de ressources partagées pendant des périodes de temps limitées, ce afin d'effectuer un test de récupération après sinistre ou une vraie récupération après un sinistre.

Il existe deux approches pour la récupération après sinistre et la gestion de clés.

• Le client peut placer des KMA sur le site de récupération après sinistre et les configurer dans leur cluster de production à l'aide d'une connexion WAN. Ces KMA sont dédiés au client concerné et permettent aux clés du client de toujours se trouver sur le site de récupération après sinistre et d'être prêtes pour l'utilisation.

  Avec cette approche, une récupération peut démarrer une fois que le client inscrit les lecteurs de bande dans les KMA sur le site des ressources partagées et rejoint le cluster OKM.

  Cela peut être fait en connectant l'interface utilisateur graphique OKM aux KMA du site de récupération après sinistre. En cas de réelle récupération après sinistre, ils sont susceptibles d'être les seuls KMA restants du cluster du client.

  L'inscription des lecteurs se fait en quelques minutes. Une fois l'inscription terminée et les lecteurs configurés, la production de bandes peut démarrer.

• Une autre méthode consiste à restaurer les sauvegardes de l'OKM de production du client dans des KMA fournis par le site de ressources partagées. Cela permet d'éviter le besoin d'un lien WAN et des KMA dédiés sur site, mais nécessite du temps supplémentaire pour restaurer la base de données.

  Avec cette approche, l'opération de restauration nécessite des fichiers de sauvegarde OKM normaux et une sauvegarde de la sécurité principale. Cette approche de restauration nécessite un quorum des membres des références de scission de clés pour la sauvegarde de la sécurité principale.

  Les opérations de restauration nécessitent environ 20 minutes pour 100 000 clés.

  Une fois la restauration terminée, les lecteurs doivent être inscrits et configurés.

  Trois fichiers doivent être placés sur un site de récupération après sinistre :

  • Fichier de la sauvegarde de sécurité principale

  • Fichier de sauvegarde .xml

  • Fichier de sauvegarde .dat

  Ces fichiers sont créés par un agent de sauvegarde.

Réplication à partir d'un autre site

La Figure 3-1 et la Figure 3-2 présentent des exemples de deux sites séparés géographiquement, un cluster OKM comportant quatre KMA, avec deux KMA sur chaque site.

Au cours de l'installation initiale, une fois le premier KMA configuré, tout KMA supplémentaire (neuf ou de remplacement) est auto-répliqué à partir des autres KMA du cluster.

La récupération d'un KMA unique peut être effectuée sans impact sur le reste du cluster à condition qu'au moins un KMA reste opérationnel.

La Figure 3-1 est un exemple d'objectif de point de récupération. Dans cet exemple, la récupération de la continuité des activités d'un site entier à partir d'un instant donné peut prendre des mois.

• Si le site 1 a été détruit et le site 2 est toujours intact :

  Le client doit remplacer tout l'équipement détruit pour l'infrastructure, y compris les KMA du cluster et les lecteurs de bande.

  Une fois le site restauré et opérationnel :

  • Installez et créez les nouveaux KMA (nécessite un responsable de la sécurité et un quorum).

  • Rejoignez le cluster existant pour les nouveaux KMA, un à la fois.

  • Installez et activez les nouveaux lecteurs de bande.

  • Inscrivez les nouveaux lecteurs de bande, désormais appelés Agents.

  Le site 1 est alors auto-répliqué à partir des KMA survivants du site 2 intact.

La Figure 3-2 est un exemple d'objectif de délai de récupération. Dans cet exemple, le temps de récupération de la continuité des activités est de l'ordre de quelques minutes.

• Si les KMA du site 1 ont été détruits et que l'infrastructure du site 2 est toujours intacte :

  Un réseau "de service" étendu qui connecte les lecteurs de bande entre les deux sites permet aux KMA intacts du site 2 de poursuivre les opérations de bande entre les deux sites.

  Une fois les KMA remplacés sur le site 1, ils sont auto-répliqués à partir des KMA survivants du site 2 intact de la même manière que la description ci-dessus.

  Au cours du programme QuickStart, le client sélectionne :

  (2) Join Existing Cluster (Rejoindre le cluster existant)

  pour chacun des nouveaux KMA, un à la fois.

Figure 3-1 Réplication à partir d'un autre site - Objectif de point de récupération

Figure 3-2 Continuation du réseau de service - Objectif de délai de récupération

Scénario 1 : KMA prépositionnés

Dans ce scénario, le client dispose d'un grand environnement avec plusieurs sites. Chaque site utilise :

• Une paire de KMA et l'infrastructure pour prendre en charge le chiffrement de bandes automatisé

• Un cluster unique où tous les KMA partagent des clés.

En plus des multiples sites, ce client gère et utilise un équipement sur un site de récupération après sinistre qui fait partie du cluster OKM du client.

Reportez-vous à la Figure 3-3 pour ce scénario.

Ce client utilise un schéma de sauvegarde simple qui se compose de :

• Sauvegardes incrémentielles quotidiennes

• Sauvegardes différentielles hebdomadaires

• Sauvegardes complètes mensuelles.

Les sauvegardes mensuelles sont dupliquées sur le site de récupération après sinistre et envoyées dans une infrastructure de stockage hors site pendant 90 jours. Après la période de conservation de 90 jours, les bandes sont recyclées.

Le client étant propriétaire de l'équipement du site de récupération après sinistre, ce site constitue juste une extension du client qui gère strictement les processus de sauvegarde et d'archivage.

Figure 3-3 Equipement prépositionné

Scénario 2 : KMA partagés

Ce scénario est très similaire au Scénario 1 : KMA prépositionnés. Toutefois, le site de récupération après sinistre possède l'équipement et partage les ressources avec plusieurs autres clients.

Reportez-vous à la Figure 3-4 pour ce scénario.

Ce site de récupération après sinistre prend en charge d'autres clients de récupération après sinistre, vous ne pouvez donc pas supposer que le site est toujours configuré pour des processus aptes au chiffrement.

Remarque:

Les KMA doivent être réinitialisés sur les paramètres d'usine avant la création d'une configuration pour un autre client.

Sur le site de récupération après sinistre,

• Le client sélectionne l'équipement approprié dans l'inventaire du site de récupération après sinistre.

• Le site de récupération après sinistre configure l'équipement et l'infrastructure en conséquence.

Important:

Le client doit fournir les trois fichiers de sauvegarde OKM au site de récupération après sinistre :

• Fichier de la sauvegarde de sécurité principale

• Fichier de sauvegarde .xml

• Fichier de sauvegarde .dat

Sur les sites de récupération après sinistre, le client

• Configure un KMA initial à l'aide de l'assistant QuickStart

• Restaure le KMA à partir des fichiers de sauvegarde OKM

• Active ou bascule les lecteurs pour autoriser le chiffrement (représentant de la récupération après sinistre)

• Inscrit les lecteurs de bande dans le cluster KMA du site de récupération après sinistre

Une fois le travail terminé, le site de récupération après sinistre doit :

• Désactiver le chiffrement des agents

• Retirer les lecteurs de bande du cluster et réinitialiser la phrase de passe des lecteurs

• Réinitialiser les KMA sur les paramètres d'usine par défaut.

Déconnecter l'infrastructure et le réseau.

Figure 3-4 KMA partagés

Scénario 3 : partenaires de transfert de clés

Le transfert de clés est également appelé partage de clés. Le transfert permet d'échanger en toute sécurité les clés et les unités de données associées entre les partenaires et les clusters indépendants. Il est obligatoire si vous souhaitez échanger des médias chiffrés.

Remarque:

Un site de récupération après sinistre peut également être configuré comme partenaire de transfert de clés.

Ce processus exige de la part des deux parties impliquées dans le transfert d'établir une paire de clés publique/privée. Une fois la configuration initiale terminée :

• L'expéditeur utilise la fonction d'exportation de clés pour générer un fichier de transfert.

• Le destinataire utilise ensuite la fonction d'importation de clés pour recevoir les clés et les données associées.

D'une manière générale, il n'est pas recommandé d'utiliser les partenaires de transfert de clés pour la récupération après sinistre. Toutefois, si ou lorsque les sites de récupération après sinistre créent des clés lors du processus de sauvegarde, la réalisation d'un transfert de clés peut permettre d'ajouter de manière incrémentielle les clés des sites de récupération après sinistre à la base de données existantes

Le processus de transfert de clés nécessite que chaque utilisateur configure un partenaire de transfert pour chaque cluster OKM.

• Un partenaire de transfert exporte les clés depuis son cluster OKM.

• L'autre partenaire de transfert importe les clés dans son cluster OKM.

Lors de la configuration des partenaires de transfert de clés, les administrateurs doivent effectuer des tâches dans un ordre spécifique qui nécessitent plusieurs rôles, notamment :

• Rôle de responsable de la sécurité

• Rôle d'agent de conformité

• Rôle d'opérateur.

Pour configurer les partenaires de transfert de clés, reportez-vous au guide d'administration d'OKM et :

1. Configurez un partenaire de transfert de clés pour les deux clusters OKM participant à l'échange de clés.

2. Etablissez un échange de clés publique/privée pour communiquer avec les clusters OKM. Par exemple, dans le cas de l'envoi d'un message électronique, deux sites peuvent utiliser une méthode de connexion établie pour sécuriser un échange de messages électroniques et authentifier sa source et son destinataire.

   Des mécanismes, tels que les empreintes, existent pour empêcher la modification de ces informations durant le transfert.

3. Rassemblez un quorum pour approuver la création du nouveau partenaire de transfert.

4. Assignez le partenaire de transfert à un ou plusieurs groupes de clés.

5. Exportez les clés d'un cluster OKM et importez-les dans un autre. Cette opération peut être effectuée à de nombreuses reprises.

Figure 3-5 Partenaires de transfert de clés

Scénario 4 : restauration à partir de la sauvegarde

Le terme "sauvegarde" fait référence à la création de copies de données pouvant être utilisées pour restaurer l'original après un sinistre ou un événement durant lequel les données ont été perdues.

Ces copies sont généralement appelées "sauvegardes" et permettent de :

• Restaurer un site suite à un sinistre (récupération après sinistre)

• Restaurer des fichiers après qu'ils ont été supprimés par inadvertance ou endommagés

Il est important de reconnaître et d'utiliser un schéma de sauvegarde qui fonctionne pour chaque département, groupe, organisation ou entreprise. Il est également important de ne pas douter que le processus de sauvegarde fonctionne comme prévu.

Pour OKM, les éléments suivants sont disponibles pour aider à créer et, si nécessaire, restaurer OKM.

• Sauvegarde

  Fichier créé au cours du processus de sauvegarde qui contient toutes les informations nécessaires pour restaurer un KMA. Ce fichier est chiffré à l'aide d'une clé générée spécifiquement pour la sauvegarde. Cette clé se trouve dans le fichier de clé de sauvegarde correspondant.

• Fichier de clé de sauvegarde

  Fichier généré au cours du processus de sauvegarde qui contient une clé utilisée pour chiffrer le fichier de sauvegarde. Ce fichier est chiffré à l'aide d'une "clé principale" du système. La clé principale est extraite du fichier de sauvegarde de la sécurité principale à l'aide d'un quorum des références de scission de clés.

• Opérateur de sauvegarde

  Rôle utilisateur responsable de la sécurité et du stockage des données et des clés.

Remarque:

Reportez-vous à la section "Méthodologie de sauvegarde" pour plus d'informations.

Emplacements de sauvegarde :

Gardez à l'esprit que l'emplacement de sauvegarde OKM doit se trouver sur un site situé à une distance appropriée, pour éviter qu'un seul incendie ne détruise l'ensemble de données. La distance doit également prendre en compte les désastres naturels.

Par exemple, si tous les sites de sauvegarde se trouvent dans des bâtiments à la Nouvelle-Orléans, la destruction des données est inévitable lors d'un désastre tel que l'ouragan Katrina.

Restauration :

Une restauration à partir d'une sauvegarde est uniquement requise si tous les KMA d'un cluster sont défaillants, par exemple si le site a été détruit par un incendie.

Remarque:

La restauration d'OKM à partir d'une sauvegarde nécessite un quorum. L'opérateur de sauvegarde crée et gère les sauvegardes et le responsable de la sécurité les restaure. Assurez-vous que le nombre requis d'utilisateurs du quorum est disponible.

Pour restaurer le système à partir d'une sauvegarde, reportez-vous au manuel Guide d'administration d'OKM et :

1. Sélectionnez Secure Information Management > Backup List. Cette fonction vous permet d'afficher l'historique et les détails des fichiers de sauvegarde.

2. Dans l'écran Backup List, mettez en surbrillance la sauvegarde que vous souhaitez restaurer et cliquez deux fois sur l'entrée de sauvegarde. La boîte de dialogue Backup Details s'affiche.

3. Cliquez sur le bouton Restore. La boîte de dialogue Restore Backup s'affiche.

   Figure 3-6 Restauration à partir de la sauvegarde

   
   

4. Cliquez sur le bouton Start.

   Une fois le téléchargement terminé, la boîte de dialogue Key Split Quorum Authentication s'affiche.

   Les membres du quorum de sauvegarde de la sécurité principale doivent saisir leurs noms d'utilisateur et phrases de passe afin d'authentifier l'opération.

5. Cliquez sur le bouton OK. La progression de la restauration s'affiche.

Méthodologie de sauvegarde

N'oubliez pas, chaque client et chaque situation sont différents. Voici quelques instructions utiles :

Fréquence de sauvegarde. Il existe deux types de sauvegardes gérés différemment :

• La sauvegarde de la sécurité principale, qui doit être sécurisée à l'aide de tactiques spéciales.

• La sauvegarde de la base de données des données de clés, qui doit être protégée.

Sauvegarde de la sécurité principale

La sauvegarde principale contient un composant principal pour OKM, les données de clé racine. Il s'agit des données de clé générées au moment de l'initialisation du cluster. Les données de clé racine protègent la clé principale, une clé symétrique destinée à protéger les clés d'unités de données stockées sur le KMA.

La sauvegarde de la sécurité principale est protégée au moyen d'un modèle de scission de clé nécessitant un quorum d'utilisateurs défini dans les références de scission de clé. Les utilisateurs de ce quorum doivent fournir leurs noms d'utilisateurs et leurs phrases de passe afin de déchiffrer les données de clé racine.

Méthodologie :

La sauvegarde principale doit précéder la première sauvegarde de la base de données et doit uniquement être répétée lors d'une modification des membres de la scission de clé (quorum). Il s'agit d'un élément de sécurité particulièrement géré et protégé. Il est requis pour restaurer toute sauvegarde d'OKM.

Il est recommandé de conserver deux copies de cette sauvegarde dans deux emplacements sécurisés sur un média portable choisi par le client, tel que des CD, des clés USB ou des disques durs externes.

Lorsqu'une nouvelle sauvegarde principale est créée et sécurisée, les anciennes doivent être détruites.

Sauvegarde de base de données

Remarque:

Les opérateurs de sauvegarde sont responsables de la sécurité et du stockage des données et de leurs clés.

Une sauvegarde de base de données se compose de deux fichiers : un fichier de sauvegarde et un fichier de clés de sauvegarde. Ces noms de fichiers sont générés automatiquement, mais vous pouvez les modifier.

Chaque KMA crée 1 000 clés (par défaut) lors de sa création. Ce chiffre peut varier au cours de l'installation. Chaque KMA contrôle et affecte ses propres clés. Après l'émission de 10 clés, le KMA crée 10 clés pour les remplir à nouveau.

Les clés sont ensuite répliquées sur tous les KMA d'OKM.

Les sauvegardes de base de données sont chiffrées avec AES-256 et, par conséquent, sécurisées.

Méthodologie :

Exemple un : sauvegarde de base de données - Plusieurs sites dans le cluster OKM

• Des clés protègent les clés des risques d'endommagement.

• Les clés sont protégées par réplication.

Le client ne devrait jamais avoir besoin d'une récupération après sinistre intégrale du cluster en raison de l'éloignement géographique des centres de données. La création de sauvegardes pour ce client n'est pas aussi essentielle que dans l'exemple deux. Toutefois, créez une sauvegarde de la sécurité principale, puis des sauvegardes de la base de données avant que toutes les clés générées à partir d'un KMA unique soient émises pour les unités de données.

Exemple deux : sauvegarde de base de données - Un site physique dans un cluster OKM

• Un sinistre localisé peut détruire OKM en totalité.

• Les sauvegardes de base de données constituent la seule protection pour les clés.

Conservez des copies hors site des sauvegardes de la sécurité principale et de la base de données. Pour une protection minimale :

Tableau 3-1 Calculs de la sauvegarde de base de données

1.	Calculez le nombre de bandes qui seront initialement chiffrées à l'aide d'une clé par bande.
2.	Combien d'heures, jours ou semaines seront nécessaires pour émettre les clés initialement créées ? Remarque : chaque KMA crée 1 000 clés (par défaut) lors de sa création.
3.	Calculez le nombre de bandes montées qui auront une période de chiffrement de clés expirée.
4.	Additionnez ces deux calculs.
5.	Supposez qu'un seul KMA émette toutes les clés et sauvegardez la base de données avant que toutes les clés initiales soient émises. Vous affectez ainsi un facteur de sécurité de 50 % au calcul.
6.	Répétez ce calcul en fonction de l'afflux de nouvelles bandes et réutilisez l'expiration de la période de chiffrement.

Eléments à prendre en considération :

• Archivez les copies ou ne les archivez pas.

• N'oubliez pas que les anciennes sauvegardes contiennent des utilisateurs, des mots de passe et d'autres données sensibles que vous ne souhaitez peut-être pas conserver.

• Créez et archivez deux sauvegardes actuelles de la base de données en cas de défaillance du média de sauvegarde.

• Dans la mesure où vous avez calculé un facteur de sécurité de 50 % en considérant qu'un seul KMA émet les clés, les deux sauvegardes contiennent toutes les clés actives.

• N'archivez jamais les anciennes copies de la base de données.

• Si vous supprimez régulièrement des clés à des fins de conformité ou dans le cadre de stratégies, les clés supprimées peuvent être récupérées à partir de sauvegardes antérieures.

• Conservez des copies redondantes. Ne créez pas deux sauvegardes.

• Créez deux copies identiques pour vous protéger contre les défaillances des médias de sauvegarde. Ce schéma permet également de garantir qu'aucune autre clé n'a été émise durant la sauvegarde, ce qui rendrait les deux copies différentes.