Dell EMC Data Domain Encryption - Forum Aux Questions

Configuration du chiffrement

Question : Comment le chiffrement (DARE) est-il configuré dans le DD ?
Répondre: Le chiffrement DARE peut être configuré dans DD en procédant comme suit :

1. Ajouter une licence de chiffrement

2. Ajouter un responsable de la sécurité et activer les autorisations du responsable de la sécurité

3. Activer le chiffrement 

1) Ajouter une licence de cryptage :
ajoutez un fichier de licence avec une licence de cryptage valide.
Utilisez la commande ci-dessous pour mettre à jour la licence électronique dans DD à l’aide du fichier de licence disponible.

Mise à jour de la licence électronique

2) Ajoutez un responsable de la sécurité et activez les autorisations SO :
a) Ajoutez un utilisateur avec un rôle de « sécurité » à l’aide de la commande : 

user add secuser role security

b) Activez l’autorisation du responsable de la sécurité dans la configuration à l’aide de la commande : 

Authorization policy set security-officer activé

3. Activez le chiffrement DARE :
Activez le chiffrement DARE à l’aide de la commande :

Activation du chiffrement du système de fichiers

Question : Quelles plates-formes sont prises en charge avec la fonctionnalité de chiffrement des données au repos ?
Répondre: La fonction de chiffrement des données au repos est prise en charge sur tous les systèmes Data Domain, à l’exception des systèmes EDP (Encryption Disablement Project).

Question: Comment l’utilisateur peut-il stocker ses données en texte clair dans DD ?
Répondre: L’utilisateur peut s’assurer que les données sont enregistrées en texte clair et non chiffrées dans DD, en confirmant que le chiffrement est désactivé lors de la configuration.
Les utilisateurs peuvent désactiver le chiffrement dans DD à l’aide de la commande : 

Désactivation du chiffrement des systèmes de fichiers

Question : Quels protocoles/applications de sauvegarde sont pris en charge avec la fonctionnalité de chiffrement des données au repos ?
Répondre: La fonction DD DARE est indépendante de l’application de sauvegarde sous-jacente ou du protocole utilisé par DD.

Question : Quels algorithmes de chiffrement peuvent être sélectionnés sur le système Data Domain ?
Répondre: Le logiciel DD Encryption prend en charge l’algorithme AES 128 ou 256 bits à l’aide du processus CBC (Cipher Block Chaining) ou GCM (Galois Counter Mode). 

GCM est un mode de fonctionnement pour les chiffrements par blocs cryptographiques à clé symétrique. Il s’agit d’un algorithme de chiffrement authentifié conçu pour assurer à la fois l’authentification et la confidentialité (confidentialité). Comme son nom l’indique, GCM combine le mode de chiffrement compteur bien connu avec le nouveau mode d’authentification Galois. L’aspect authentification de GCM garantit que les données chiffrées l’ont été par le système Data Domain et qu’elles n’ont pas été « injectées » par d’autres moyens. Cela diffère de CBC où les données sont cryptées (aspect de confidentialité), mais il n’y a pas de contrôle de l’authenticité des données cryptées.

En mode CBC, chaque bloc de texte brut est exclusif avec le bloc de texte chiffré précédent avant d’être chiffré. De cette façon, chaque bloc de texte chiffré dépend de tous les blocs de texte brut traités jusqu’à ce point. De plus, pour rendre chaque message unique, un vecteur d’initialisation doit être utilisé dans le premier bloc. CBC ne garantit la confidentialité des données que par le biais d’un cryptage. Aucune authentification de l’algorithme ou du processus de chiffrement n’est effectuée.

Question: Comment pouvons-nous modifier l’algorithme de chiffrement dans DD ?

Réponse : Utilisez la commande ci-dessous si vous souhaitez définir un algorithme de chiffrement spécifique dans la configuration.

Filesys encryption algorithm set

Exemple :

# filesys encryption algorithm set {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Question : Comment s’assurer que le chiffrement est effectué sur les données préexistantes une fois le chiffrement activé ?
Répondre: Nous pouvons forcer DDFS à chiffrer les données préexistantes à l’aide de la commande ci-dessous :

# filesys encryption apply-changes

Cela rend le prochain cycle de nettoyage considérablement plus long et plus gourmand en ressources que la normale.

Question: Comment désactiver le chiffrement dans DD ?
Répondre: Désactivez la fonction de chiffrement dans DD à l’aide de la commande encryption disable : 

Désactivation du chiffrement des systèmes de fichiers

Cela désactive uniquement le chiffrement des E/S entrantes. Les données chiffrées existantes restent chiffrées jusqu’à ce qu’elles soient déchiffrées manuellement à l’aide de apply-changes.

Question: Quelles commandes de chiffrement nécessitent un redémarrage du système de fichiers DD pour prendre effet ?
Répondre: Les commandes de chiffrement suivantes nécessitent un redémarrage du système de fichiers DD pour prendre effet :

Activation/désactivation du chiffrement des systèmes de fichiers : Active/désactive le chiffrement sur le système Data Domain.

filesys encryption algorithm set - Autoriser l’utilisateur à sélectionner un algorithme cryptographique.

Réinitialisation de l’algorithme de chiffrement du système de fichiers - Réinitialise l’algorithme de chiffrement sur AES 256 en mode CBC (valeur par défaut).

Question: Quelles commandes de chiffrement nécessitent que le système de fichiers Data Domain soit désactivé pour pouvoir les définir/utiliser ?
Répondre: Les commandes de chiffrement suivantes nécessitent que le système de fichiers Data Domain soit désactivé afin de les définir ou de les utiliser :

Modification de la phrase secrète de chiffrement

Verrouillage/déverrouillage du chiffrement

Questions générales sur le chiffrement

Question : DD Encryption est-il pris en charge sur tous les systèmes DD ?
Répondre: L’option logicielle DD Encryption est prise en charge sur les systèmes DD s’il ne s’agit pas d’un projet de désactivation du chiffrement (EDP), c’est-à-dire les systèmes qui ne permettent pas d’activer le chiffrement, principalement vendus dans les systèmes de la région Russie.

Question: Comment le chiffrement est-il effectué dans les systèmes DD ?
Répondre: Le chiffrement s’effectue à l’aide des bibliothèques OpenSSL et RSA BSafe (RSA BSafe est une bibliothèque de cryptographie validée FIPS 140-2 utilisée par les systèmes DD pour chiffrer les données inactives) dans DDOS. 

Question : Quelle version de BSafe est utilisée avec le système ?
Répondre: À partir de DDOS 7.10, les versions de BSafe utilisées sont « BSAFE Micro Edition Suite 4.4.0.0 » et « BSAFE Crypto-C Micro Edition : 4.1.4.0"

Question : Quelles sont les interfaces utilisateur disponibles pour configurer le chiffrement dans DDOS ?
Répondre: Le chiffrement peut être configuré à l’aide de la CLI, de l’interface utilisateur ou d’API REST. L’API REST prise en charge a été ajoutée dans DDOS versions 8.0 et ultérieures.

Question: Un chiffrement sélectif des données est-il possible ? Vous n’aimez qu’une seule structure MTree ou un seul fichier ?
Répondre: Le chiffrement sélectif n’est PAS possible. Le chiffrement peut uniquement être activé ou désactivé à l’échelle du système et non de manière sélective. Pour les systèmes avec prise en charge du Cloud, le chiffrement peut être activé ou désactivé au niveau du niveau Cloud et de la granularité de l’unité de Cloud.  

Question : Des clés cryptographiques ou des mots de passe de compte sont-ils transmis ou stockés en texte clair ou avec des chiffrements faibles, par exemple lorsqu’une entité s’authentifie, dans un fichier de données, dans des programmes ou dans des répertoires d’authentification ?
Répondre: Absolument pas.

Question: Quelle version d’OpenSSL est utilisée avec le système ?
Répondre: À partir de la version DDOS 7.10, la version openssl est « OpenSSL 1.0.2zd-fips »

Question : Comment le chiffrement des données au repos protège-t-il l’accès aux données depuis les utilisateurs et les applications ?
Répondre: 

• Le chiffrement des données inactives consiste à chiffrer les données qui résident sur le sous-système de disque. Le chiffrement ou le déchiffrement se produit au niveau de la couche de compression. Les utilisateurs ou les applications envoient et reçoivent des données en texte clair au système Data Domain, mais toutes les données résidant physiquement sur le système Data Domain sont chiffrées.
• Tous les chiffrements se produisent en dessous du système de fichiers et de l’espace de nommage et sont invisibles pour les utilisateurs ou les applications. Si un utilisateur ou une application dispose déjà d’un accès autorisé à un fichier ou à un répertoire, les données peuvent être lues dans leur format natif, quel que soit le chiffrement.
• DD Encryption est conçu de telle sorte que si un intrus contourne d’autres contrôles de sécurité réseau et accède à des données chiffrées, sans clés de chiffrement appropriées, les données deviennent illisibles et inutilisables pour cette personne. 

Question : Le chiffrement sera-t-il effectué après la déduplication ?
Répondre: Oui, le chiffrement s’effectue sur les données dédupliquées. Les données sont chiffrées avant d’être stockées sur le disque. 

Question : Comment le système Data Domain assure-t-il la sécurité des données ?
Répondre: Les données sont sécurisées à l’aide de la fonction de chiffrement des données au repos. En outre, lorsque le périphérique est supprimé (head-swap, verrouillage du système de fichiers), la phrase secrète est supprimée du système. Cette phrase secrète est utilisée pour chiffrer les clés de chiffrement afin de mieux protéger les données.

Question: Quelles alertes sont générées avec le chiffrement ?
Répondre: Les alertes sont générées dans les cas suivants :

• Lorsque des clés de chiffrement sont compromises, elles sont présentes
• Lorsque le tableau de clés de chiffrement est plein et qu’il n’est plus possible d’ajouter d’autres clés dans le système
• En cas d’échec de l’exportation automatique de clé
• En cas d’échec de la rotation automatisée des clés
• Lorsque le chiffrement est désactivé
• Lorsque la phrase secrète du système a été modifiée

Question : Existe-t-il une certification de sécurité pour DDOS ? 
Réponse : Les systèmes Data Domain sont conformes à la norme FIPS 140-2. 

Question : Où la clé de chiffrement est-elle stockée ?
Répondre: Les clés de chiffrement sont stockées de manière permanente dans une partition de collecte du système DDOS.

Question: Si quelqu’un sort un disque dur d’un système Data Domain, pouvez-vous déchiffrer
les données ?Répondre: Les clés de chiffrement sont chiffrées à l’aide de la phrase secrète du système stockée dans l’en-tête du système. Même si les clés de chiffrement sont stockées sur le disque, sans phrase secrète système, les clés de chiffrement ne peuvent pas être déchiffrées. Ainsi, sans connaître la clé utilisée pour chiffrer les données, le déchiffrement n’est pas possible à partir d’un disque dur.  

Question : Quels sont les mots de passe et clés cryptographiques nécessaires à la récupération, en particulier à la reprise après sinistre ?
Répondre: Les clés peuvent être exportées dans un fichier sécurisé et conservées à l’extérieur du système. La récupération de ce fichier s’effectue à l’aide de l’ingénierie. En outre, au moment de la récupération, le client doit connaître la phrase secrète qu’il utilisait au moment de la commande d’exportation des clés.

Question: Comment verrouiller un système de fichiers avant son transfert vers un site distant.
Répondre: Vous trouverez ci-dessous la procédure à suivre : 

• Désactivez le système de fichiers :

  sysadmin@itrdc-DD630-42# filesys disable

• Verrouillez le système de fichiers et saisissez une nouvelle phrase secrète (cela nécessite une authentification par l’utilisateur de sécurité ci-dessus) :

  sysadmin@itrdc-DD630-42# Verrouillage
  du chiffrement du système de fichiers Cette commande nécessite l’autorisation d’un utilisateur ayant un rôle de sécurité.
  Please present credentials for such a user below.
          Username : secuser
  Password :
  Saisissez la phrase secrète actuelle :
  Enter new passphrase :
  Saisissez à nouveau la nouvelle phrase secrète :
  Phrases secrètes correspondantes.
  Le système de fichiers est maintenant verrouillé.

• La nouvelle phrase secrète ne doit PAS être perdue ou oubliée. Sans cette phrase secrète, le système de fichiers ne peut pas être déverrouillé, ce qui signifie que les données de la DDR ne sont pas accessibles. Pour déverrouiller le système lorsqu’il atteint un emplacement distant, utilisez la commande ci-dessous :

sysadmin@itrdc-DD630-42# filesys encryption unlock
Cette commande nécessite l’autorisation d’un utilisateur ayant un rôle de sécurité.
Veuillez présenter les informations d’identification de cet utilisateur ci-dessous.
        Nom d’utilisateur : secuser
Mot de passe :
Entrez la phrase secrète :
La phrase secrète a été vérifiée. Utilisez « filesys enable » pour démarrer le système de fichiers.

• Le système de fichiers peut maintenant être activé et utilisé normalement.

Question : La commande storage sanitize a-t-elle un lien avec le chiffrement du système de fichiers ?
Répondre: Non, le chiffrement du système de fichiers et le nettoyage du stockage sont deux fonctionnalités indépendantes. 

Question : Le chiffrement sur le réseau est-il pris en charge dans le système EDP (Encryption Disablement Project) ?
Répondre: Impossible d’activer le chiffrement des données au repos (DARE) ou le chiffrement sur le réseau (avec réplication ou avec ddboost) dans le système EDP.

Phrase secrète du système 

Question : Qu’est-ce que la phrase secrète du système ?
Répondre: DDOS permet de sécuriser les informations d’identification au sein du système en définissant une phrase secrète au niveau du système. La phrase secrète est une clé lisible (compréhensible) par l’utilisateur, comme une carte à puce, qui est utilisée pour générer une clé de chiffrement AES 256 lisible par une machine. 

Il offre deux avantages :

• Elle permet à l’administrateur de modifier la phrase secrète sans avoir à manipuler les clés de chiffrement. La modification de la phrase secrète modifie indirectement le chiffrement des clés, mais n’affecte pas les données utilisateur. La modification de la phrase secrète ne modifie pas la clé de chiffrement du système Data Domain sous-jacent. Cela modifie le chiffrement de la clé système Data Domain, mais la clé système reste identique.
• Elle permet d’expédier un système Data Domain physique avec une clé de chiffrement sur le système, mais sans que la phrase secrète ne soit stockée dessus. De cette façon, si la boîte est volée en transit, un attaquant ne peut pas facilement récupérer les données puisque le système ne dispose que de clés chiffrées et de données chiffrées.

La phrase secrète est stockée en interne sur une partie cachée du système de stockage Data Domain. Cela permet au système Data Domain de démarrer et de continuer à assurer l’accès aux données sans intervention de l’administrateur.

Création ou modification de la phrase secrète :

• La phrase secrète du système peut être créée à l’aide de la CLI après qu’un administrateur se soit authentifié auprès du système Data Domain.
• La phrase secrète du système peut être modifiée à l’aide de la CLI après qu’un administrateur et un utilisateur doté d’un rôle de sécurité (comme un responsable de la sécurité) se sont authentifiés auprès du système Data Domain (de sorte qu’aucun administrateur ne puisse apporter de modifications de manière indépendante).

Question : Quand la phrase secrète est-elle utilisée ?
Répondre: La phrase secrète du système est utilisée comme clé primaire par divers composants de DDOS, notamment le chiffrement du système de fichiers, l’accès au Cloud, la gestion des certificats, les tokens Boost, les modules de configuration système dans les environnements scale-out et les informations de licence. Le logiciel DDOS fournit des mécanismes permettant de définir et de modifier cette phrase secrète système. Elle fournit également des options permettant de contrôler si la phrase secrète du système est stockée sur le disque, ce qui est particulièrement utilisé pour renforcer la sécurité lors du transport du système DD. 

Question : Comment la phrase secrète est-elle utilisée pour un transport sécurisé du système DD ?
Répondre: Le processus utilise la commande « filesys encryption lock », qui permet à l’utilisateur de verrouiller le système de fichiers en modifiant la phrase secrète. L’utilisateur saisit une nouvelle phrase secrète qui chiffre à nouveau la clé de chiffrement, mais la nouvelle phrase secrète n’est pas stockée. Les clés de chiffrement ne sont pas récupérables tant que le système de fichiers n’est pas déverrouillé à l’aide de la commande « filesys encryption unlock ».

Le processus est décrit dans le Guide de configuration de la sécurité de Confluence Lab.

Question: Que se passe-t-il si la phrase secrète est modifiée ? Est-il toujours possible d’accéder aux données ?
Répondre: Oui, la modification de la phrase secrète ne modifie pas la clé de chiffrement du système Data Domain sous-jacent, mais seulement le chiffrement de la clé de chiffrement. Par conséquent, l’accès aux données n’est pas affecté.

Question: Comment pouvons-nous demander si une phrase secrète est définie sur le système ?
Répondre: Si une phrase secrète est définie sur le système, l’exécution de la commande « system passphrase set » génère une erreur indiquant que la phrase secrète est déjà définie.

Question: Que se passe-t-il si la phrase secrète est perdue ou oubliée ?
Répondre: Si le client perd la phrase secrète alors que la boîte est verrouillée, il perd ses données. Il n’y a pas de porte dérobée ou d’autre moyen d’y accéder. Sans un processus efficace de gestion de cette phrase secrète, cela peut se produire accidentellement et ils ne peuvent pas récupérer la clé ou les données. Toutefois, la clé chiffrée ne peut jamais être perdue ou corrompue en raison des mécanismes de protection intégrés du système.

Question: Existe-t-il un mécanisme pour réinitialiser la phrase secrète du système oubliée ?
Répondre: La phrase secrète du système peut être réinitialisée de force uniquement dans certains scénarios, avec l’aide du support client. Le mécanisme de mise à jour forcée introduit dans DDOS 7.2 ne peut être utilisé à cet effet que si des conditions spécifiques sont remplies. Pour plus d’informations, reportez-vous à l’article 20983 de la base de connaissances, Data Domain : Réinitialisation d’une phrase secrète système perdue dans DDOS v7.2 ou version ultérieure (connexion au support Dell requise pour afficher l’article)

Question : Existe-t-il une option permettant d’éviter de stocker la phrase secrète du système sur le système DD ?
Répondre: Par défaut, la phrase secrète du système est stockée dans un emplacement masqué sur le système Data Domain. L’option système « system passphrase option store-on-disk » peut être utilisée pour modifier cela et éviter de stocker la phrase secrète sur le disque.

Embedded Key Manager (EKM)

Commande de premier niveau :

system# filesys encryption embedded-key-manager <option>

Question : La rotation des clés est-elle prise en charge avec Embedded Key Manager ?
Répondre:  Oui, la rotation des clés par système Data Domain est prise en charge avec Embedded Key Manager. Via l’interface utilisateur ou l’interface de ligne de commande, l’administrateur peut configurer une période de rotation des clés (hebdomadaire ou mensuelle).

Question: La fonctionnalité de gestion des clés intégrée est-elle payante ?
Répondre: Cette fonctionnalité est gratuite. Cette fonctionnalité est incluse dans l’option de licence logicielle standard de DD Encryption.

Question: Le client peut-il passer de la gestion des clés locale à la gestion des clés externe (EKM) ?
Répondre

• Oui, les gestionnaires de clés externes peuvent être activés à tout moment. Toutefois, les clés locales utilisées restent sur le système Data Domain. Les gestionnaires de clés externes ne sont pas en mesure de gérer les clés EKM. Il n’est pas nécessaire de chiffrer à nouveau les données existantes. Si, pour un client, les données de conformité doivent être chiffrées à nouveau avec des clés EKM, cela doit être fait manuellement à l’aide de apply-changes avec la nouvelle clé RW. La destruction des clés EKM après un basculement n’est pas obligatoire.
  • Le commutateur de gestionnaire de clés bascule automatiquement la clé active vers la clé à partir de KMIP. 
  • Exemple d’apparence de l’interface MUID de clé KMIP lors d’un basculement

    Key-ID     Key MUID                                                                    State                     Key Manger Type
    1               be1                                                                    Deactivated               DataDomain
    
    2               49664EE855DF71CB7DC08309414C2B4C76ECB112C8D10368C37966E4E2E38A68       Activated-RW              KeySecure

Question : Que se passe-t-il lorsque la rotation des clés est désactivée ou activée ?
Répondre: 

• L’option Key rotation disabled est la fonctionnalité de chiffrement par défaut si vous ne l’activez pas à partir de l’interface utilisateur ou de l’interface de ligne de commande. Dans ce cas, toutes les données sont chiffrées avec la clé active existante.
• Si la rotation des clés est activée, en fonction de la fréquence de rotation, nous faisons pivoter les clés et les données sont chiffrées avec la dernière clé active.

Gestionnaires de clés externes

Question : Quels sont les gestionnaires de clés externes pris en charge sur DD ?
Répondre: Nous prenons en charge les gestionnaires de clés externes ci-dessous :

• Gemalto KeySecure (prise en charge ajoutée dans la version 7.2 de DDOS)
• Vormetric (prise en charge ajoutée dans la version 7.3 de DDOS)
• CipherTrust (prise en charge ajoutée dans la version 7.7 de DDOS)
• IBM GKLM (prise en charge ajoutée dans la version 7.9 de DDOS)

Question : Une licence distincte est-elle requise pour permettre l’intégration avec un gestionnaire de clés externe ?
Répondre: Oui, une licence distincte du fournisseur concerné est nécessaire pour intégrer External Key Manager avec DD.

Question: Combien y a-t-il de gestionnaires clés qui apportent leur soutien à la fois ?
Répondre: Un seul gestionnaire de clés peut être actif à un moment donné sur un système DD.

Question: Où puis-je trouver plus d’informations sur la configuration du gestionnaire de clés externe KMIP ?
Répondre: Le Guide d’intégration KMIP pour DDOS contient des informations détaillées sur la configuration des différents gestionnaires de clés externes pris en charge par DD.

Question: Comment les certificats sont-ils gérés pour les gestionnaires de clés externes dans DD ?
Répondre: Lors de la configuration du gestionnaire de clés externe, nous devons générer un certificat d’autorité de certification (le certificat d’autorité de certification peut être un certificat auto-signé ou signé par un tiers) et un certificat d’hôte. Une fois la configuration effectuée sur le serveur gestionnaire de clés externe, les utilisateurs doivent importer le certificat d’autorité de certification et le certificat d’hôte sur le système DD. Ensuite, nous configurons et activons le gestionnaire de clés externe. 

Question : Qu’est-ce que l’AC ?
Répondre: Une autorité de certification (AC) agit en tant qu’entité partagée de confiance initiale entre les homologues et émet des certificats signés pour permettre à chaque partie de faire confiance à l’autre. Un certificat sert généralement d’identité à un serveur ou à un client. 

Question : Qu’est-ce qu’un certificat signé par une autorité de certification locale, qu’est-ce qu’un certificat signé par une autorité de certification ?
Répondre: Un certificat signé par une autorité de certification est un certificat qui a été émis et signé par une autorité de certification (CA) de confiance publique. Un certificat signé par une autorité de certification est approuvé automatiquement. Une autorité de certification locale peut émettre des certificats signés, car la clé de signature privée est stockée dans le système Key Manager. Une autorité de certification externe ne stocke pas la clé privée. Au lieu de cela, une autorité de certification externe est utilisée en tant qu’entité de confiance pour diverses interfaces et services à l’intérieur du système.

Question: Comment créer une demande de signature de certificat dans DD ?
Répondre: Sur le système Data Domain, générez la CSR à l’aide de la commande CLI ci-dessous. De cette façon, la clé privée n’est jamais exposée au gestionnaire de clés externe.

adminaccess certificate cert-signing-request

Question : Est-il possible de basculer entre les gestionnaires de clés ?
Répondre: Le basculement entre le gestionnaire de clés externe et le gestionnaire de clés intégré est autorisé et est transparent. Toutefois, le passage d’Embedded Key Manager à External Key Managers nécessite l’installation et la configuration appropriées des certificats. Basculement entre deux gestionnaires de clés externes (par exemple : KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM) sont également autorisés. La migration des clés Key Manager est également prise en charge (voir le guide d’intégration KMIP pour plus de détails).

Question: Que se passe-t-il en cas de panne de la connectivité du gestionnaire de clés externe ? Mes données sont-elles alors accessibles ?
Répondre: Oui, les données restent accessibles lorsque nous ne pouvons pas nous connecter au gestionnaire de clés, car nous stockons également une copie des clés dans le système DD. Les nouvelles clés ne peuvent pas être créées ou les états de clé ne peuvent pas être synchronisés en l’absence de connectivité avec le gestionnaire de clés externe.

Question: Existe-t-il un moyen d’éviter de stocker les clés dans DD et de les stocker uniquement dans le gestionnaire de clés externe ?
Répondre: Nous stockons toujours une copie des clés dans le système DD à des fins de DIA. Ce paramètre ne peut pas être modifié.

Question: L’intégration avec KMIP a-t-elle un impact sur les performances ?
Répondre: Non, il n’y a aucun impact sur les performances en raison de l’utilisation de gestionnaires de clés externes.

Question: Est-il possible de tirer parti de la solution KMIP pour certains domaines de données au sein de l’environnement ?
Répondre: Oui, les clients disposent d’une flexibilité totale dans le choix de la méthodologie de chiffrement appropriée pour leurs systèmes Data Domain. Ils peuvent continuer à utiliser le gestionnaire de clés intégré de Data Domain sur certains systèmes Data Domain, ainsi que la rotation des clés de chiffrement à l’aide de KMIP sur d’autres systèmes Data Domain au sein de leur environnement.

Question: La communication entre Data Domain et KMIP est-elle sécurisée ?
Répondre: Oui, Data Domain communique avec le TLS via des sessions d’authentification mutuelle de certificat X509. L’utilisateur peut utiliser l’interface de ligne de commande de Data Domain pour importer le certificat X509 approprié dans le système Data Domain. Ce certificat est ensuite utilisé pour établir le canal sécurisé entre DD et KMIP.

Gestion clé du cycle de vie 

Question : Quelles sont les fonctionnalités de gestion des clés disponibles avec l’option DD Encryption ?
Répondre: Un gestionnaire de clés contrôle la génération, la distribution et la gestion du cycle de vie de plusieurs clés de chiffrement. Un système de protection peut utiliser le gestionnaire de clés intégré ou le gestionnaire de clés externe conforme KMIP. Un seul gestionnaire de clés peut être actif à la fois. Lorsque le chiffrement est activé sur un système de protection, Embedded Key Manager est activé par défaut. Si un gestionnaire de clés externe est configuré, il remplace le gestionnaire de clés intégré et reste en vigueur jusqu’à ce qu’il soit désactivé manuellement. Le passage d’Embedded Key Manager à External Key Manager ou inversement, entraîne l’ajout d’une nouvelle clé au système et ne nécessite pas de redémarrage du système de fichiers à partir de la version 7.1.

Question: Quels sont les différents états clés sur le système Data Domain ?
Les différents états clés sur le système Data Domain sont les suivants :

• RW activé : Il n’existe qu’une seule clé dans cet état sur un système DD, utilisée pour la lecture et l’écriture des données. Cette clé est également utilisée par le processus GC pour chiffrer de nouveau les conteneurs.
• Activé en attente : Il n’y a qu’une seule clé dans cet état sur un système DD. Cela a permis d’identifier la clé qui deviendra Activated-RW après le redémarrage suivant du système de fichiers. Aujourd’hui, cet état n’existe qu’au moment de l’activation du chiffrement. Aucune autre clé activée par le temps en attente n’est créée.  
• Activated-RO : Les gestionnaires de clés externes peuvent avoir plusieurs clés activées. La clé la plus récente est à l’état Activated-RW ; les autres sont dans cet état. Les clés peuvent passer dans cet état sur le système DD lorsque nous ne pouvons pas synchroniser l’état avec le gestionnaire de clés.
• Désactivé: Il est utilisé pour lire les données existantes sur le système DD.
• Compromis: Lorsqu’un client compromet une clé de gestionnaire de clés externe, l’état est remplacé par celle-ci après la prochaine synchronisation de la clé.  
• Marked-For-Destroyed : Lorsqu’un client marque une clé à détruire, l’état de la clé devient Marked-For-Destroy. Lorsque GC est exécuté, tous les conteneurs chiffrés avec des clés marquées pour la destruction sont chiffrés à nouveau à l’aide de la clé de lecture/écriture activée.
• Détruit: Une clé à l’état Marked-For-Destroyed passe dans cet état lorsqu’aucune donnée ne lui est associée.
• Destroyed-compromised : Une clé à l’état Compromised passe dans cet état lorsqu’aucune donnée ne lui est associée.

Question : Les clés de chiffrement peuvent-elles être exportées pour la reprise après sinistre ?
Répondre: Les clés peuvent être exportées manuellement à l’aide de la commande ci-dessous.

« filesys encryption keys export »

Le système DD exporte également les clés par défaut lorsqu’une nouvelle clé est ajoutée ou lorsqu’une clé est supprimée du système.

Les fichiers exportés sont présents dans /ddr/var/.security dans un format chiffré. Ce fichier doit ensuite être copié à partir de la DDR et stocké dans un emplacement sûr qui peut être utilisé dans n’importe quelle condition de reprise après sinistre ultérieurement.

Remarque : L’importation de clés pour la reprise après sinistre nécessite l’intervention du support technique, car le processus de restauration dépend du type de sinistre rencontré. Nous pouvons importer le fichier de clé exporté à l’aide de la commande suivante.

Nom du fichier d’importation <des clés de chiffrement du système de fichiers> 

Question : La clé générée par KMIP est-elle stockée sur le système Data Domain ?
Répondre: Oui, la clé de chiffrement obtenue à partir de KMIP est stockée de manière chiffrée sur le système Data Domain.

Question: Comment une modification de l’état clé de l’appliance KMIP est-elle appliquée au système Data Domain ?
Répondre: La synchronisation des clés a lieu quotidiennement. Si une nouvelle clé est disponible ou si l’état de la clé est modifié, la synchronisation met à jour la table des clés locales. DD reçoit des mises à jour clés du KMIP tous les jours à minuit.

Question: Est-il possible de synchroniser manuellement les états de clé entre le DD et KMIP ?
Répondre: Oui, l’interface CLI ou l’interface utilisateur Data Domain peut être utilisée pour synchroniser manuellement les états de clé entre DD et KMIP. La commande « filesys encryption keys sync » est utilisée pour cela.

Question: Est-il possible de modifier l’heure à laquelle le DD reçoit les mises à jour clés de KMIP ?
Répondre: Non, il n’est pas possible de modifier l’heure à laquelle le DD reçoit les mises à jour de clé de KMIP.

Question: Le nombre de clés prises en charge par le système Data Domain est-il limité ?
Répondre: À partir de DDOS 7.8, le système Data Domain peut à tout moment posséder un maximum de 1 024 clés. Il n’y a qu’une seule clé dans Activated-RW et les autres clés peuvent être dans n’importe quel autre état.

Question: Des clés différentes peuvent-elles être utilisées pour différents jeux de données sur les systèmes Data Domain ? Est-ce configurable ?
Répondre: Non, nous ne prenons en charge qu’une seule clé active à la fois dans le système et toutes les données entrantes sont chiffrées à l’aide de la clé active actuelle. Les clés ne peuvent pas être contrôlées avec une granularité plus fine que les M-arbres.

Question: Y a-t-il une notification lorsque la limite maximale de clés est atteinte ?
Répondre: Oui, une alerte est déclenchée lorsque la limite maximale de 1 024 clés est atteinte.

Question: Comment puis-je effacer l’alerte concernant la limite maximale de clé ?
Répondre: L’une des clés doit être supprimée pour effacer l’alerte de limite maximale de clés.

Question : Est-il possible de voir la quantité de données associées à une clé particulière sur le système Data Domain ?
Répondre: Oui, il est visible sur DD, mais pas sur le serveur KMIP. L’utilisateur peut utiliser l’interface de ligne de commande Data Domain et l’interface utilisateur pour afficher la quantité de données associée à une clé particulière.

Question:  Est-il possible de voir l’âge des clés sur le système DD ?
Répondre: Oui, il est visible avec les clés EKM à l’aide de l’interface utilisateur.

Question: L’ancienne clé fonctionne-t-elle même si le délai de mise en œuvre de la nouvelle clé est écoulé ?
Répondre: Aucune date d’expiration n’existe pour les clés de chiffrement. Les anciennes clés deviennent des clés en lecture seule après la rotation des clés et restent dans DDOS.

Question: La clé de chiffrement est-elle automatiquement supprimée lorsqu’aucune donnée ne lui est associée sur le système Data Domain ?
Répondre: Non, la clé n’est pas automatiquement supprimée. L’utilisateur doit supprimer explicitement la clé à l’aide de l’interface de ligne de commande ou de l’interface utilisateur DD.

Question: Une clé peut-elle être supprimée même si des données lui sont associées sur le système Data Domain ?
Répondre: Non, si des données sont associées à une clé, elle ne peut pas être supprimée. Le rechiffrement des données est nécessaire avec une autre clé pour supprimer une clé qui comporte des données associées.

Question: Si une clé est supprimée dans le KMIP, la clé est-elle également supprimée de la liste des clés de Data Domain ?
Répondre: Non, l’utilisateur doit supprimer la clé indépendamment à l’aide de l’interface de ligne de commande ou de l’interface utilisateur DD.

Question: Dans un environnement Data Domain multisite, un système KMIP est-il requis sur chaque site ?
Répondre: Non, il n’est pas nécessaire d’avoir un système KMIP sur chaque site disposant d’un système Data Domain. Nous pouvons pointer vers un serveur KMIP. Il est recommandé de disposer d’une classe de clés distincte pour chaque système DD lorsqu’ils utilisent le même serveur KMIP.

Question: Si une clé est compromise, disposons-nous d’un processus pour récupérer les données chiffrées avec l’ancienne clé ?
Répondre: Dans ce cas, le client doit marquer la clé comme compromise sur le serveur KMIP. Ensuite, faites « filesys encryption keys sync » dans le système DDOS, puis exécutez « filesys encryption apply-changes », puis exécutez GC (filesys clean). L’exécution du GC chiffre à nouveau toutes les données qui ont été chiffrées avec la clé compromise à l’aide d’une clé plus récente. Une fois le GC terminé, l’état de la clé passe à compromis-détruit. Plus tard, ils pourront supprimer cette clé. 

Chiffrement et réplication

Question : La solution DD Replication est-elle prise en charge et interopérable avec l’option logicielle DD Encryption ?
Répondre: Oui, DD Replication peut être utilisé avec l’option DD Encryption, ce qui permet de répliquer les données chiffrées à l’aide de différents types de réplication. Chaque forme de réplication fonctionne de manière unique avec le chiffrement et offre le même niveau de sécurité.

Question: Les systèmes source et de destination doivent-ils exécuter la même version de DD OS pour utiliser le chiffrement ?
Répondre: La source et la destination peuvent être dans différentes versions de DDOS pour utiliser DARE avec la réplication si la matrice de compatibilité de réplication (voir le guide d’administration de la matrice de compatibilité) est en place. 

Question : Comment la réplication fonctionne-t-elle avec le chiffrement ?
Répondre: Cela dépend de la forme de réplication utilisée.

Si la réplication configurée est MREPL ou MFR :
Si MREPL ou MFR est utilisé, DD Encryption peut être mis sous licence ou activé sur la source ou la destination indépendamment, en fonction des attentes du client.

• Lorsque le chiffrement est activé pour la source et la destination : Lorsque les données sont acquises sur le système source, elles sont chiffrées à l’aide de la clé de chiffrement du système source. La source déchiffre les données locales, les chiffre à nouveau à l’aide de la clé de chiffrement du système de destination, puis réplique les données chiffrées vers la destination lors de la réplication.
• Lorsque le chiffrement est désactivé sur la source et que le chiffrement est activé sur la destination : Toutes les données ingérées vers la source ne sont pas chiffrées (pour des raisons évidentes). Toutefois, lors de la réplication, la source chiffre les données à l’aide de la clé de chiffrement du système de destination, puis réplique les données chiffrées sur le système de destination. 
• Lorsque le chiffrement est activé sur la source et que le chiffrement est désactivé sur la destination : Toutes les données ingérées sur le système source sont chiffrées à l’aide de la clé de chiffrement du système source. La source déchiffre les données, puis réplique les données non chiffrées vers le système Data Domain de destination lors de la réplication.
• Si le chiffrement est activé sur le réplica après la configuration du contexte de réplication, tous les nouveaux segments en cours de réplication sont chiffrés à la source du réplica. Tous les segments résidant sur le réplica avant l’activation du chiffrement sont laissés dans un état non chiffré, sauf si le chiffrement applique les modifications et que le GC s’exécute sur la destination. 

Si la réplication configurée est CREPL :
Avec la réplication de collection, les systèmes source et de destination doivent exécuter la même version DDOS. Par conséquent, le chiffrement doit être activé ou désactivé sur les deux. Il ne peut pas non plus y avoir de non-correspondance dans la configuration du chiffrement. Les clés de chiffrement sont les mêmes pour la source et la destination. 

• Lorsque le chiffrement est activé pour la source et la destination : Toutes les données ingérées sur le système source sont chiffrées à l’aide de la clé de chiffrement du système source. Lors de la réplication, la source envoie des données chiffrées au système Data Domain de destination dans son état chiffré. Le système Data Domain de destination possède la même clé que la source, car la réplication de collection concerne une réplique exacte du système Data Domain source. Aucune donnée ne peut être écrite sur le système Data Domain de destination en dehors de la réplication, car la destination est un système en lecture seule.
• Lorsque le chiffrement est désactivé pour la source et la destination : Toutes les données ingérées sur le système source ne sont pas chiffrées (pour des raisons évidentes). Lors de la réplication, la source envoie (réplique) les données dans un état non chiffré et elles restent non chiffrées sur le système Data Domain de destination. Aucune donnée ne peut être écrite sur le système Data Domain de destination en dehors de la réplication, car la destination est un système en lecture seule.

Question : La clé de la destination est-elle stockée indéfiniment sur le système Data Domain source ?
Répondre: La clé de chiffrement de la destination n’est jamais stockée sur le système Data Domain source. Il est uniquement conservé en mémoire (chiffré) tant que la session de réplication est active. Cela s’applique à tous les types de réplication, à l’exception de la réplication de collection. Dans la réplication de collection (CREPL), le même jeu de clés de chiffrement est présent dans la source et la destination.  

Question : Le chiffrement peut-il être activé dans le système CREPL après l’établissement du contexte de réplication ?
Répondre: Oui, dans ce cas, le chiffrement doit être activé à la fois dans la source et dans la destination. Le chiffrement peut être activé dans la source et la destination en désactivant le contexte de réplication. Tous les nouveaux segments répliqués sont chiffrés sur le réplica. Tous les segments résidant sur le réplica avant l’activation du chiffrement sont laissés dans un état non chiffré.

Question: DD Encryption peut-il être activé en même temps que la fonction de chiffrement sur le réseau dans l’option logicielle DD Replication ?
Répondre: Oui, le chiffrement sur le réseau et le chiffrement D@RE peuvent être activés simultanément pour atteindre différents objectifs de sécurité.

Question: Que se passe-t-il si l’option logicielle DD Encryption et la fonction de chiffrement sur le réseau de l’option logicielle DD Replication sont activées simultanément ?
Répondre: La première source chiffre les données à l’aide de la clé de chiffrement de destination. Ensuite, les données déjà cryptées sont chiffrées une deuxième fois en raison du cryptage sur le réseau lors de l’envoi de ces données à leur destination. À la destination, une fois le déchiffrement sur le réseau terminé, les données sont stockées dans un format chiffré qui a été chiffré à l’aide de la clé de chiffrement de la destination.

Question: Lorsque le chiffrement est activé dans la source et la destination, la phrase secrète doit-elle être la même sur les deux ?
Répondre: Si la réplication configurée est une réplication de collection (CREPL), la phrase secrète doit être identique. Pour d’autres types de réplication (comme MREPL, MFR), la phrase secrète peut être différente dans la source et la destination.

Question: Lorsque le chiffrement est activé sur la destination (question non applicable à CREPL), les données répliquées et les données provenant d’un autre point d’accès (par exemple, via une sauvegarde locale) sont-elles chiffrées ? Existe-t-il un moyen de séparer les deux sur le réplica où seuls les répertoires répliqués sont chiffrés tandis que les autres accès ne sont pas chiffrés ?
Répondre: Non, toutes les données sont chiffrées sur le réplica (destination) quel que soit le point d’entrée. Le chiffrement ne peut pas être activé ou désactivé uniquement avec une granularité au niveau d’une structure MTree ou d’un répertoire. 

Question : Comment s’effectue l’échange de clés entre la source et la destination au cours d’une opération MREPL ou MFR ?
Répondre: Au cours de la phase d’association de la réplication, la machine cible transmet en toute sécurité son algorithme de chiffrement actuel et les informations de clé à la source. Les contextes de réplication sont toujours authentifiés auprès d’un code secret partagé. Ce code secret partagé est utilisé pour établir une clé de « session » à l’aide d’un protocole d’échange de clés Diffie-Hellman. Cette clé de session est utilisée pour chiffrer et déchiffrer la clé de chiffrement du système Data Domain.

Question: Quel type d’algorithme de chiffrement est utilisé pour la fonctionnalité de « chiffrement sur le réseau » de Data Domain, concernant le chiffrement du trafic de réplication ?
Répondre: Lorsque le mode d’authentification de réplication est défini sur « one-way » ou « two-way », le DHE (Ephemeral Diffie-Hellman) est utilisé pour l’échange de clés de session. L’authentification du serveur s’effectue à l’aide de RSA. Le chiffrement GCM AES 256 bits est utilisé pour encapsuler les données répliquées sur le réseau. La couche d’encapsulation de chiffrement est immédiatement supprimée lorsqu’elle arrive sur le système de destination. 

Unidirectionnel indique que seul le certificat de destination est certifié. Deux méthodes indiquent que les certificats source et de destination sont vérifiés. La confiance mutuelle doit être établie avant que vous puissiez utiliser le mode d’authentification et les deux côtés de la connexion doivent activer cette fonctionnalité pour que le chiffrement se poursuive.

Lorsque le mode d’authentification de réplication est défini sur « anonymous », Diffie-Hellman anonyme (ADH) est utilisé pour l’échange de clés de session, mais dans ce cas, la source et la destination ne s’authentifient pas mutuellement avant l’échange de clés. En outre, si le mode d’authentification n’est pas spécifié, anonymous est utilisé par défaut.

Question: La rotation des clés sans redémarrage du système de fichiers fonctionne-t-elle avec tous les types de réplication ?
Répondre: La rotation des clés sans redémarrage du système de fichiers fonctionne avec tous les types de réplication, à l’exception de la réplication DREPL (la prise en charge de DREPL est déjà terminée) et de la réplication delta (également connue sous le nom de LBO)

Question : En l’absence de certificats ou de paires de clés PKI, comment la clé de chiffrement de la destination est-elle protégée lors de l’échange de clés ?
Répondre: Il existe un code secret partagé entre toutes les paires de réplication Data Domain qui est utilisé pour établir une clé de session partagée à l’aide d’un échange de clés Diffie-Hellman. Cette clé partagée est utilisée pour chiffrer la clé de chiffrement de la destination.

Il existe une différence entre le code secret partagé utilisé pour l’authentification de réplication et la clé de session partagée, qui est allouée à l’aide du protocole d’échange de clés Diffie-Hellman. Le code secret partagé utilisé pour l’authentification de réplication est établi par le logiciel Data Domain la première fois que deux systèmes Data Domain souhaitent établir un contexte de réplication. Il est également convenu par le biais d’un échange Diffie-Hellman à l’aide de paramètres intégrés dans le code. Elle est stockée de manière permanente dans les systèmes pour authentifier chaque session de réplication entre les deux systèmes. La clé de session de réplication (la clé utilisée pour chiffrer la clé de chiffrement de la destination) est établie à l’aide d’un autre échange Diffie-Hellman avec le secret partagé précédemment établi, ce qui favorise le protocole d’échange de clés sécurisé. Cette clé n’est pas persistante et n’existe que lorsque le contexte de réplication est actif.

Question: Est-il nécessaire que les deux Data Domains d’une paire de réplication utilisent la même solution de gestionnaire de clés externe (comme le gestionnaire de clés KMIP) ou l’un des systèmes peut-il utiliser le gestionnaire de clés externe et l’autre peut utiliser le gestionnaire de clés intégré ?
Répondre: À l’exception d’une paire de réplication de collection, il n’est pas nécessaire que les deux systèmes d’une paire de réplication utilisent le même gestionnaire de clés.

Avec la réplication de collection, les deux systèmes Data Domain doivent être configurés avec le même gestionnaire de clés. Mais dans ce cas également, la seule source est la synchronisation des clés avec le gestionnaire de clés et ces clés sont également envoyées à la destination. Avec d’autres types de réplication, différents gestionnaires de clés peuvent être utilisés avec la source et la destination.

Chiffrement et migration

Question : La migration des données est-elle prise en charge sur les systèmes sur lesquels le chiffrement est activé ?
Répondre: Oui, la migration des données est prise en charge sur les systèmes sur lesquels le chiffrement est activé. La configuration du chiffrement sur les systèmes source et de destination doit être mise en correspondance comme condition préalable avant le lancement de la migration des données. Il est également recommandé d’exporter et de sauvegarder les clés de chiffrement sur le système source à des fins de DIA avant de lancer la migration.

Question: La migration des données est-elle prise en charge à la fois pour la migration du niveau actif et celle du niveau Cloud pour les systèmes avec chiffrement activé ?
Répondre: Oui, la migration des données est prise en charge à la fois pour la migration de niveau actif et de niveau Cloud pour les systèmes prenant en charge le chiffrement. La liste des attributs prérequis vérifiés est appliquée en fonction du niveau sur lequel le chiffrement est activé.

Question: Quels paramètres de chiffrement sont conservés dans le cadre de la migration ?
Répondre: Les données chiffrées et les clés de chiffrement sont migrées telles quelles, mais les paramètres tels que le gestionnaire de clés de chiffrement, la phrase secrète du système et d’autres configurations de chiffrement doivent être vérifiés manuellement et mis en correspondance pour une migration réussie des données. Tous les certificats de gestionnaire de clés existants sont également transférés vers le système de destination. La configuration du gestionnaire de clés de chiffrement doit être redéfinie sur le système de destination après la migration.

Question: Quelles vérifications de compatibilité de chiffrement sont effectuées entre la source et la destination lors de la migration ?
Répondre: La phrase secrète du système, l’état du chiffrement et les détails de configuration du gestionnaire de clés, ainsi que les paramètres du mode FIPS du système sont quelques-uns des paramètres de chiffrement qui doivent être identiques sur les systèmes source et de destination pour que la migration réussisse. Cet article de la base de connaissances 183040, Data Domain : Migration Procedure for Cloud Enabled DD Systems (vous devez vous connecter au support Dell pour afficher l’article), décrit les étapes de migration entre les systèmes avec le Cloud activé. Les mêmes paramètres s’appliquent également à la migration du niveau actif uniquement.

Question: La migration entre les systèmes est-elle prise en charge avec le paramètre Projet de désactivation du chiffrement activé ?
Répondre: La migration des données est prise en charge entre deux systèmes si les deux sont tous deux des systèmes EDP ou non-EDP. La migration des données est autorisée à partir d’un système EDP vers un système non EDP si le chiffrement sur le réseau est explicitement désactivé. (à l’aide du MIGRATION_ENCRYPTION sysparam)

Chiffrement au niveau Cloud 

Question : Le chiffrement est-il pris en charge pour le niveau Cloud ?
Répondre: Oui, le chiffrement est pris en charge sur le niveau Cloud. Par défaut, le chiffrement est désactivé dans le niveau Cloud. La commande « cloud enable » vous invite à choisir si vous souhaitez activer le chiffrement sur le niveau Cloud.

Question: KMIP et les gestionnaires de clés externes sont-ils pris en charge avec le niveau Cloud ?
Répondre: Oui, KMIP et les gestionnaires de clés externes sont pris en charge avec la hiérarchisation sur le Cloud à partir de DDOS 7.8.

Question: À quel niveau de granularité le chiffrement peut-il être activé dans le Cloud ?
Répondre: Le chiffrement peut être activé et désactivé indépendamment sur chaque unité de cloud et chaque niveau.

Question: Les unités de Cloud ont-elles des clés indépendantes ?
Répondre: Non, la gestion des clés est commune aux niveaux actif et Cloud dans DD. Les clés sont copiées vers l’unité/niveau/cp respectif lorsque le chiffrement est activé. Si le chiffrement est activé sur le Cloud et non sur le Cloud, les clés Active Tier ne sont pas reflétées sur le Cloud et inversement. Cela s’applique également aux unités de Cloud. (Par exemple : le chiffrement est activé sur CP1 et aucun chiffrement n’est activé sur CP2, alors les clés CP1 ne sont pas reflétées sur CP2.)   

Question : Les clés peuvent-elles être supprimées dans le cloud ?
Répondre: Non, la suppression de clés du Cloud n’est pas prise en charge.

Question: Où les clés de chiffrement des données sont-elles gérées pour les unités de Cloud ?
Répondre: Les clés sont associées à un CP et chaque unité de Cloud correspond à un CP différent. Une copie des clés de tous les cps est stockée dans le cp actif.

Question: Comment restaurer les clés Cloud lors d’une reprise après sinistre ? 
Réponse : Le cpnameval est mis en miroir dans le Cloud dans le cadre de la récupération CP. Les clés de chiffrement vont être restaurées sur cpnameval. Maintenant, nous devons exécuter ddr_key_util outil pour récupérer les clés.

Remarque : La reprise après sinistre nécessite l’intervention du support client.

Question: Puis-je procéder au déplacement des données lorsque le chiffrement est activé uniquement au niveau Cloud ?
Répondre: Non, nous devons activer le chiffrement à la fois dans le niveau Cloud et actif pour le déplacement des données.

Question: Pouvons-nous activer le gestionnaire de clés externe sur Cloud Tier ?
Répondre: Oui, le gestionnaire de clés externe peut être activé sur le niveau Cloud. Cette fonctionnalité est prise en charge à partir de la version 7.8. Toutes les opérations, à l’exception de la destruction ou de la suppression de clé valide pour le niveau actif, sont également valides pour le niveau Cloud en termes de gestionnaire de clés externe. 

Chiffrement et nettoyage de la mémoire

Question : Quel rôle le processus de nettoyage global joue-t-il dans le chiffrement au repos et y a-t-il un impact sur les performances lors de l’activation du chiffrement pour la première fois ?
Répondre: L’activation pour la première fois du chiffrement des données au repos a un impact sur les performances du nettoyage global. En effet, les données qui doivent être lues à partir de conteneurs existants sur le disque et écrites dans de nouveaux conteneurs peuvent nécessiter d’être lues, déchiffrées et décompressées avant d’être recompressées, chiffrées et réécrites sur le disque. Lorsque le chiffrement est activé sur un DD contenant une quantité importante de données préexistantes et que la commande « filesys encryption apply-changes » est exécutée, le cycle de nettoyage global suivant tente de chiffrer toutes les données existantes sur le système. Cela signifie que toutes les données doivent être lues, décompressées, compressées, chiffrées et écrites sur le disque. Par conséquent, le premier cycle de nettoyage global après l’exécution de « filesys encryption apply-changes » peut prendre plus longtemps que d’habitude. Les clients doivent s’assurer qu’ils disposent de suffisamment d’espace libre sur leur système DD pour permettre l’exécution du nettoyage jusqu’à la fin sans que le système DD ne soit saturé (sinon les sauvegardes échouent).

Question: Y a-t-il un impact sur les performances des cycles de nettoyage d’acquisition/restauration en cours ?
Répondre: Oui, il y a un impact sur les performances et cela dépend généralement de la quantité de données ingérées/restaurées entre les cycles de nettoyage.

Question: Combien de temps faut-il pour chiffrer mes données existantes ?
Utilisez cet article de la base de connaissances pour estimer la durée, Data Domain : Calcul de la durée d’application du chiffrement au repos.

Chiffrement et headswap 

Question : Le client peut-il déplacer le disque vers un autre système Data Domain en cas de défaillance d’une tête et accéder au disque lorsque le chiffrement est activé ?
Répondre: La clé de chiffrement n’étant pas liée à la tête du système Data Domain elle-même, vous pouvez déplacer les disques vers une autre tête de système Data Domain afin que la clé y soit accessible. Sur une nouvelle tête de système Data Domain, le système de fichiers est verrouillé. Vous devez donc saisir la phrase secrète avec la commande « filesys encryption unlock ». 

Question : Que se passe-t-il si un client a oublié la phrase secrète au moment de l’opération de headswap ?
Répondre: Pendant ce temps, il peut connecter l’ancienne tête et travailler avec le support pour réinitialiser la phrase secrète, puis se reconnecter à la nouvelle tête et terminer la procédure de headswap. 

Performances de chiffrement

Question : Quel est l’impact observé sur la consommation du stockage lorsque le chiffrement est utilisé ?
Répondre: Il est négligeable avec une surcharge d’environ 1 % associée au stockage de certains paramètres de chiffrement avec les données utilisateur.

Question: Quel est l’impact observé sur le débit (écritures et lectures) lorsque le chiffrement des données au repos est utilisé ?
Répondre: L’impact sur le débit d’acquisition lors de l’utilisation du chiffrement peut varier en fonction du protocole et de la plate-forme. En règle générale, les pourcentages suivants sont des dégradations de performances conservatrices dans le débit agrégé :

Mode CBC
Premier sachet : ~ 10 % de dégradation des performances sur les écritures
incrémentielles : ~ 5 % de dégradation des performances sur les restaurations d’écriture
: 5 à 20 % de dégradation des performances sur les

lectures Mode GCM
première sauvegarde complète : 10 à 20 % de dégradation des performances sur les écritures
incrémentielles : Dégradation des performances de 5 à 10 % sur les restaurations
d’écriture : 5 à 20 % de dégradation des performances sur les lectures

Ces chiffres sont spécifiques à la surcharge du chiffrement des données au repos (le chiffrement sur le réseau est comptabilisé séparément)
 

Bonnes pratiques

Question : Quelles sont les pratiques d’excellence concernant la règle de rotation des clés ?
Répondre: La règle de rotation automatisée des clés n’est pas activée par défaut. Le client l’a activé. Il est recommandé d’effectuer une rotation fréquente des clés de chiffrement. Lorsqu’un système est configuré avec un gestionnaire de clés KMIP externe, il est recommandé de faire tourner fréquemment les clés pour gérer tout scénario de violation de clé à l’avenir. Lorsque KMIP est configuré avec le niveau Cloud, l’intervalle de rotation des clés suggéré est de 1 semaine et lorsque KMIP est configuré dans le niveau actif uniquement, la règle de rotation des clés suggérée est de 1 mois. Toutefois, en fonction du taux d’acquisition, le client peut également augmenter ou diminuer la fréquence de rotation des clés. Si le gestionnaire de clés intégré est configuré, il est recommandé d’appliquer une règle de rotation des clés comprise entre 1 et 3 mois. 

Question : Quelles sont les pratiques d’excellence relatives à la classe de clés KMIP si un client utilise le même serveur KMIP pour de nombreux systèmes DD ?
Répondre: Il est recommandé de disposer d’une classe de clés distincte pour chaque système DD lorsqu’ils utilisent le même serveur KMIP. De cette façon, la rotation des clés effectuée dans un système DDOS n’a pas d’impact sur l’état de la clé présente dans un autre système DDOS.

Pour plus d’informations, reportez-vous au document Appliances DELL EMC PowerProtect DD : Logiciel de chiffrement (delltechnologies.com)

Chiffrement: Livre blanc technique Appliances PowerProtect série DD : Logiciel

de chiffrementVous trouverez d’autres documents relatifs à DD Encryption (Guide d’administration, Guide de référence des commandes et Guide de configuration de la sécurité) dans l’article 126375, Documents de base PowerProtect et Data Domain.

Guide d’intégration KMIP et matrice

de compatibilitéRegardez cette vidéo :