Data Domain : Questions fréquentes sur le chiffrement

Résumé: Cet article de la base de connaissances contient une série de questions fréquentes (FAQ) sur Data Domain Data At Rest Encryption (DARE) dans un emplacement consolidé pour faciliter la référence. ...

Produits concernés

Cet article concerne Cet article ne concerne pas Cet article n’est associé à aucun produit spécifique. Toutes les versions du produit ne sont pas identifiées dans cet article.

Consulter d’autres ressources

Instructions

Configuration du chiffrement

Question : Comment le chiffrement des données au repos (DARE) est-il configuré sur Data Domain ?

Réponse : DARE peut être configuré en procédant comme suit :

Ajoutez une licence de chiffrement.
1. Disposez d’un fichier de licence avec une licence Encryption valide ajoutée.
2. Utilisez la commande ci-dessous pour mettre à jour la licence électronique dans Data Domain à l’aide du fichier de licence disponible :
```
# elicense update
```
Ajoutez un responsable de la sécurité et activez les autorisations du responsable de la sécurité.
1. Ajoutez un utilisateur avec le rôle « security » (s’il n’en existe pas déjà) à l’aide de la commande :
```
# user add <username> role security
```
2. Activez l’autorisation du responsable de la sécurité en vous connectant en tant que responsable de la sécurité et en exécutant la commande :
```
> authorization policy set security-officer enabled
```
Revenez à un compte administrateur et activez DARE en exécutant la commande :
```
# filesys encryption enable
```

Question : Quelles plates-formes sont prises en charge par DARE ?

Réponse : La fonctionnalité DARE est prise en charge sur tous les systèmes Data Domain, à l’exception des systèmes EDP (Encryption Disablement Project).

Question : Comment stocker des données en texte clair sur le Data Domain ?

Réponse : Les utilisateurs peuvent s’assurer que les données sont enregistrées en texte clair et non chiffrées dans Data Domain en confirmant que le chiffrement est désactivé lors de la configuration.

Le chiffrement peut être désactivé dans Data Domain à l’aide de la commande :

# filesys encryption disable

Question : Quels sont les protocoles et applications de sauvegarde pris en charge par DARE ?

Réponse : La fonctionnalité DARE est indépendante de l’application de sauvegarde sous-jacente ou du protocole utilisé par Data Domain.

Question : Quels algorithmes de chiffrement peuvent être utilisés ?

Réponse : Le logiciel de chiffrement Data Domain prend en charge les algorithmes AES 128 ou 256 bits à l’aide du protocole CBC (Cipher Block Chaining) ou du mode 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 exclusivité OR(XOR) 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 l’algorithme de chiffrement peut-il être modifié ?

Réponse : Utilisez la commande ci-dessous pour définir un algorithme de chiffrement spécifique :

# 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éponse : Nous pouvons forcer le système de fichiers Data Domain à 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 ?

Réponse : Désactivez la fonction de chiffrement dans Data Domain à l’aide de la commande suivante :

# filesys encryption disable

Cela désactive uniquement le chiffrement des données entrantes. Les données chiffrées existantes restent chiffrées jusqu’à ce qu’elles soient déchiffrées manuellement à l’aide de la commande 'filesys encryption apply-changes'.

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

Réponse : Les commandes de chiffrement suivantes nécessitent un redémarrage du système de fichiers pour prendre effet :

filesys encryption enable|disable - Active ou désactive le chiffrement sur le système Data Domain.
filesys encryption algorithm set - Permet à l’utilisateur de sélectionner un algorithme cryptographique.
filesys encryption algorithm reset - Réinitialise l’algorithme de chiffrement à AES 256 en mode CBC (valeur par défaut).

Question : Quelles commandes de chiffrement nécessitent la désactivation du système de fichiers pour pouvoir les définir ou les utiliser ?

Réponse : Le système de fichiers Data Domain doit être désactivé pour pouvoir définir ou utiliser les commandes de chiffrement suivantes :

encryption passphrase change
encryption lock|unlock

Questions générales sur le chiffrement

Question : DARE est-il pris en charge sur tous les systèmes Data Domain ?

Réponse : L’option logicielle DARE est prise en charge sur les systèmes Data Domain qui ne font pas partie du projet de désactivation du chiffrement (EDP). Ces systèmes qui ne permettent pas d’activer le chiffrement sont vendus dans la région Russie.

Question : Comment le chiffrement est-il effectué sur les systèmes Data Domain ?

Réponse : Le chiffrement est effectué à l’aide des bibliothèques OpenSSL et RSA BSafe. RSA BSafe est une bibliothèque de cryptographie validée FIPS 140-2.

Question : Quelle version de BSafe Data Domain utilise-t-il ?

Réponse : À compter de DDOS 7.10, les versions de BSafe utilisées sont les suivantes : «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éponse : Le chiffrement peut être configuré à l’aide de la ligne de commande, de l’interface Web ou à l’aide d’API REST. La prise en charge de l’API REST a été ajoutée dans la version 8.0 de DDOS.

Question : Le chiffrement sélectif des données est-il possible ? Vous n’aimez qu’une seule structure mtree ou un seul fichier ?

Réponse : 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 au niveau de l’unité 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éponse : Non.

Question : Quelle version d’OpenSSL Data Domain utilise-t-il ?

Réponse : À partir de DDOS 7.10, la version d’OpenSSL est «OpenSSL 1.0.2zd-fips. »

Question : Comment DARE se protège-t-il contre l’accès aux données par les utilisateurs et les applications ?

Réponse :

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 vers le 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.
Le chiffrement Data Domain 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, celles-ci deviennent illisibles et inutilisables pour cette personne sans clés cryptographiques appropriées.

Question : Le chiffrement se produit-il après la déduplication ?

Réponse : 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éponse : Les données sont sécurisées à l’aide de la fonction DARE. 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éponse : 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 des clés de chiffrement est saturé et qu’il n’est plus possible d’ajouter d’autres clés au 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 est 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éponse : Les clés de chiffrement sont stockées de manière permanente dans une partition de collecte dans DDOS.

Question : Si quelqu’un retire un disque dur d’un système Data Domain, peut-il en déchiffrer les données ?

Réponse : Les clés de chiffrement sont chiffrées à l’aide de la phrase secrète du système, qui est stockée dans l’en-tête du système. Même si les clés de chiffrement sont stockées sur le disque, elles ne peuvent pas être déchiffrées sans la phrase secrète du système. 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éponse : Les clés peuvent être exportées vers un fichier sécurisé et conservées en externe sur le 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 utilisée avec la commande d’exportation des clés.

Question : Comment le système de fichiers peut-il être verrouillé avant de le déplacer vers un autre emplacement ?

Réponse : Vous trouverez ci-dessous la procédure de verrouillage du système :

Désactivez le système de fichiers :
```
# filesys disable
```
Verrouillez le système de fichiers et saisissez une nouvelle phrase secrète (cela nécessite une authentification auprès d’un utilisateur de sécurité) :
```
# filesys encryption lock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the current passphrase:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The filesystem is now locked.
```
1. 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 sur le système Data Domain sont inaccessibles.

Pour déverrouiller le système lorsqu’il atteint un emplacement distant, utilisez la commande ci-dessous :

# filesys encryption unlock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the passphrase:
The passphrase has been verified. Use 'filesys enable' to start the filesystem.

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

Question : Est-ce que l’option '`storage sanitize`' ont-elles une relation avec le chiffrement du système de fichiers ?

Réponse : Non, le chiffrement du système de fichiers et le nettoyage du stockage sont deux fonctionnalités indépendantes.

Question : Le chiffrement par câble est-il pris en charge pour les systèmes EDP ?

Réponse : DARE et le chiffrement sur le réseau ne sont pas pris en charge pour les systèmes EDP.

Phrase secrète du système

Question : Qu’est-ce que la phrase secrète du système ?

Réponse : DDOS peut 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 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 ne change pas.
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 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 à fournir un 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. Cela signifie qu’aucun administrateur ne peut apporter de modifications de manière indépendante.

Question : Quand la phrase secrète est-elle utilisée ?

Réponse : La phrase secrète du système est utilisée comme clé primaire par différents composants de DDOS, y compris le chiffrement du système de fichiers, l’accès au Cloud, la gestion des certificats, les tokens DD Boost, les modules de configuration système dans les environnements scale-out et les informations de licence. DDOS fournit des mécanismes permettant de définir et de modifier cette phrase secrète du système. Il 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 de Data Domain.

Question : Comment la phrase secrète est-elle utilisée pour le transport sécurisé du système Data Domain ?

Réponse : 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' commandement.

Le processus est décrit dans les guides de configuration de la sécurité de Data Domain.

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éponse : 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 savoir si une phrase secrète est définie sur le système ?

Réponse : 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éponse : 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 de réinitialisation d’une phrase secrète système perdue ?

Réponse : 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. Vous trouverez plus de détails dans cet article : 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).

Question : Existe-t-il une option permettant d’éviter de stocker la phrase secrète du système sur le système Data Domain ?

Réponse : Par défaut, la phrase secrète du système est stockée dans un emplacement masqué sur le système Data Domain. La commande 'system passphrase option store-on-disk' peut être utilisé pour modifier cela et éviter de stocker la phrase secrète sur le disque.

Embedded Key Manager (EKM)

Commande de premier niveau :

# filesys encryption embedded-key-manager <option>

Question : La rotation des clés est-elle prise en charge avec EKM ?

Réponse : 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éponse : Cette fonctionnalité est gratuite. Il est inclus dans l’option de licence logicielle standard Data Domain Encryption.

Question : Pouvez-vous passer de la gestion des clés locale à la gestion des clés externe ?

Réponse : 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 locales. Les données existantes n’ont pas besoin d’être rechiffrées. Si les données de conformité doivent être rechiffrées avec des clés EKM, le processus doit être effectué manuellement à l’aide de la commande «filesys encryption apply-changes' avec le nouveau RW . La destruction des clés EKM après un basculement n’est pas obligatoire.

La modification des gestionnaires 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éponse : La rotation des clés est désactivée par défaut. Dans ce cas, toutes les données sont chiffrées avec la clé active existante. Si la rotation des clés est activée, les données sont chiffrées à l’aide de la dernière clé active en fonction de la fréquence de rotation configurée.

Gestionnaires de clés externes

Question : Quels gestionnaires de clés externes Data Domain prend-il en charge ?

Réponse : Data Domain prend 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éponse : Oui, une licence distincte du fournisseur concerné est nécessaire pour intégrer un gestionnaire de clés externe avec Data Domain.

Question : Combien de gestionnaires de clés peuvent être utilisés à la fois ?

Réponse : Un seul gestionnaire de clés peut être actif à la fois sur un système Data Domain.

Question : Où trouver plus d’informations sur la configuration des gestionnaires de clés externes KMIP ?

Réponse : 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 Data Domain.

Question : Comment les certificats sont-ils gérés pour les gestionnaires de clés externes dans Data Domain ?

Réponse : La configuration du gestionnaire de clés externe nécessite la génération d’un certificat d’autorité de certification (qui peut être auto-signé ou signé par un tiers) et d’un certificat d’hôte. Une fois la configuration effectuée sur le serveur du gestionnaire de clés externe, le certificat CA et le certificat d’hôte doivent être importés dans le système Data Domain. Ensuite, le gestionnaire de clés externe peut être configuré et activé.

Question : Qu’est-ce qu’une autorité de certification ?

Réponse : Une autorité de certification (AC) agit en tant qu’entité partagée de confiance initiale entre 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 ? Qu’est-ce qu’un certificat signé par une autorité de certification locale ?

Réponse : Un certificat signé par une autorité de certification est un certificat qui a été émis et signé par une autorité de certification (AC) de confiance. 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 de gestion de clés. 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 divers services à l’intérieur du système.

Question : Comment créer une demande de signature de certificat sur un système Data Domain ?

Réponse : Une demande de signature de certificat Data Domain (CSR) peut être générée à l’aide de la commande 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 passer d’un gestionnaire de clés à l’autre ?

Réponse : Le passage d’un gestionnaire de clés externe à un gestionnaire de clés intégré est autorisé et transparent. Toutefois, le passage d’un gestionnaire de clés intégré à des gestionnaires de clés externes nécessite l’installation et la configuration appropriées du certificat. Basculement entre deux gestionnaires de clés externes (par exemple : KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM) est également autorisé. La migration des clés 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 toujours accessibles ?

Réponse : Oui, les données restent accessibles lorsque nous ne pouvons pas nous connecter au gestionnaire de clés, car une copie des clés est également stockée dans Data Domain. Les nouvelles clés ne peuvent pas être créées et les états des clés ne peuvent pas être synchronisés en l’absence de connectivité avec le gestionnaire de clés externe.

Question : Existe-t-il un moyen de stocker les clés uniquement dans le gestionnaire de clés externe et non dans Data Domain ?

Réponse : Une copie des clés est toujours stockée dans le système Data Domain à des fins d’architecture DIA (Data Invulnerability Architecture). Ce paramètre ne peut pas être modifié.

Question : L’intégration avec KMIP a-t-elle un impact sur les performances ?

Réponse : 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éponse : Oui, les clients disposent d’une flexibilité totale dans le choix de la méthodologie de chiffrement appropriée pour leurs Data Domain. Ils peuvent continuer à utiliser le gestionnaire de clés intégré Data Domain sur certains systèmes et la rotation des clés de chiffrement à l’aide de KMIP sur d’autres systèmes au sein de leur environnement.

Question : La communication entre Data Domain et KMIP est-elle sécurisée ?

Réponse : Oui, Data Domain communique avec le TLS via des sessions d’authentification mutuelle de certificat X509. La CLI Data Domain peut être utilisée pour importer le certificat X509 approprié dans le système Data Domain. Ce certificat est ensuite utilisé pour établir le canal sécurisé entre Data Domain et KMIP.

Gestion clé du cycle de vie

Question : Quelles sont les fonctionnalités de gestion des clés disponibles avec le chiffrement Data Domain ?

Réponse : 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 un gestionnaire de clés externe compatible 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. À compter de DDOS 7.1, il n’est plus nécessaire de redémarrer le système de fichiers.

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

Les différents états clés sur Data Domain sont les suivants :

Activated-RW: Il n’y a qu’une seule clé dans cet état sur un Data Domain à un moment donné, et elle est utilisée pour la lecture et l’écriture des données. Cette clé est également utilisée par le processus de nettoyage de la mémoire pour chiffrer à nouveau les conteneurs.
Pending-Activated: Il n’y a qu’une seule clé dans cet état sur un système Data Domain à un moment donné. Cela permet d’identifier la clé qui deviendra Activated-RW Après le prochain redémarrage du système de fichiers. Cet état n’existe qu’au moment de l’activation du chiffrement. Pending-activated Aucune clé n’est créée à un autre moment.
Activated-RO: Les gestionnaires de clés externes peuvent avoir plusieurs clés activées. La clé la plus récente se trouve dans Activated-RW, et les autres sont dans cet état. Les clés peuvent passer dans cet état sur le système Data Domain lorsqu’il ne peut pas se synchroniser avec le gestionnaire de clés.
Deactivated: Il est utilisé pour lire les données existantes sur le système Data Domain.
Compromised: Lorsqu’une clé de gestionnaire de clés externe est compromise, elle passe à cet état après la synchronisation suivante des clés.
Marked-For-Destroyed: Lorsqu’un client marque une clé pour destruction, la clé passe à cet état. Lors de l’exécution du nettoyage de la mémoire, tous les conteneurs chiffrés avec Marked-For-Destroyed Les clés sont rechiffrées à l’aide de la commande Activated-RW .
Destroyed: Une clé dans le répertoire Marked-For-Destroyed state passe sur cet état lorsqu’aucune donnée ne lui est associée.
Destroyed-compromised: Une clé dans le répertoire Compromised state passe sur 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éponse : Les clés peuvent être exportées manuellement à l’aide de la commande ci-dessous.

# filesys encryption keys export

Data Domain 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 le dossier /ddr/var/.security dans un format chiffré. Ce fichier peut être copié à partir du Data Domain et stocké dans un emplacement sûr pour être utilisé ultérieurement dans n’importe quelle condition de reprise après sinistre.

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.

# filesys encryption keys import <filename>

Question : La clé générée par KMIP est-elle stockée sur le système Data Domain ?

Réponse : 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 de clé de l’appliance KMIP est-elle appliquée à Data Domain ?

Réponse : La synchronisation des clés a lieu quotidiennement. Si une nouvelle clé est disponible ou si l’état d’une clé est modifié, la synchronisation met à jour la table de clés locales. Data Domain 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 Data Domain et KMIP ?

Réponse : Oui, l’interface CLI ou l’interface utilisateur Data Domain peut être utilisée pour synchroniser manuellement les états de clé entre le système Data Domain et KMIP. La commande pour cela est 'filesys encryption keys sync'.

Question : Est-il possible de modifier l’heure à laquelle le Data Domain reçoit les mises à jour de clé de KMIP ?

Réponse : Non, il n’est pas possible de modifier l’heure à laquelle le Data Domain reçoit les mises à jour de clé de KMIP.

Question : Existe-t-il une limite au nombre de clés stockées sur le système Data Domain ?

Réponse : À partir de DDOS 7.8, le système Data Domain peut contenir un maximum de 1 024 clés. Il n’y a qu’une seule clé dans le Activated-RW État; Toutes les autres clés peuvent se trouver dans n’importe quel autre état.

Question : Est-il possible d’utiliser différentes clés pour différents jeux de données sur Data Domain ?

Réponse : Non, Data Domain ne prend en charge qu’une seule clé active à la fois dans le système. 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 (par exemple, par structure mtree).

Question : Y a-t-il une notification lorsque la limite maximale de clés est atteinte ?

Réponse : Oui, une alerte est déclenchée lorsque la limite maximale de 1 024 clés est atteinte.

Question : Comment effacer l’alerte concernant la limite maximale de clés ?

Réponse : L’une des clés doit être supprimée pour effacer l’alerte de limite maximale de clés.

Question : Pouvez-vous voir la quantité de données associées à une clé particulière sur le système Data Domain ?

Réponse : Oui, il est visible sur Data Domain, mais pas sur le serveur KMIP. La CLI Data Domain et l’interface utilisateur permettent à l’utilisateur de voir la quantité de données associée à une clé particulière. La commande pour cela est 'filesys encryption keys show summary'.

Question : Pouvez-vous voir l’âge des clés sur le Data Domain ?

Réponse : Oui, il est visible pour 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éponse : Il n’existe aucune date d’expiration pour les clés de chiffrement. Les anciennes clés passent en lecture seule après la rotation des clés et restent dans DDOS.

Question : Les clés de chiffrement sont-elles automatiquement supprimées lorsqu’aucune donnée ne leur est associée sur le système Data Domain ?

Réponse : 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 Data Domain.

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éponse : Non, si des données sont associées à une clé, elle ne peut pas être supprimée. Les données doivent être rechiffrées avec une autre clé afin de supprimer une clé qui contient des données associées.

Question : Si une clé est supprimée dans le KMIP, est-elle également supprimée de la liste de clés de Data Domain ?

Réponse : Non, l’utilisateur doit supprimer la clé indépendamment à l’aide de l’interface CLI ou de l’interface utilisateur Data Domain.

Question : Dans un environnement Data Domain multisite, un système KMIP est-il requis sur chaque site ?

Réponse : Non, il n’est pas nécessaire d’avoir un système KMIP sur chaque site disposant d’un système Data Domain. Un seul serveur KMIP peut être utilisé pour tous ces serveurs. Il est recommandé de disposer d’une classe de clés distincte pour chaque système Data Domain lorsqu’ils utilisent le même serveur KMIP.

Question : Si une clé est compromise, existe-t-il un processus pour récupérer les données chiffrées avec l’ancienne clé ?

Réponse : Si cela se produit, le client doit marquer la clé comme compromise sur le serveur KMIP. Ensuite, sur le Data Domain :

Exécuter 'filesys encryption keys sync'.
Exécuter 'filesys encryption apply-changes'.
Démarrer un nettoyage du système de fichiers.
1. Le nettoyage chiffre à nouveau toutes les données chiffrées avec la clé compromise à l’aide d’une clé plus récente.
2. Une fois le nettoyage terminé, l’ancien état de clé est remplacé par Compromised-Destroyed.
Supprimez l’ancienne clé.

Chiffrement et réplication

Question : La réplication Data Domain est-elle prise en charge et interopérable avec DARE ?

Réponse : Oui, la réplication Data Domain peut être utilisée avec DARE. Cela permet de répliquer les données chiffrées à l’aide de différents types de réplication. Chaque type 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 DDOS pour utiliser le chiffrement ?

Réponse : La source et la destination peuvent se trouver sur une version différente de DDOS pour utiliser DARE avec la réplication si elles sont compatibles pour la réplication (reportez-vous au Guide d’administration de Data Domain pour obtenir la matrice de compatibilité).

Question : Comment la réplication fonctionne-t-elle avec le chiffrement ?

Réponse : Cela dépend de la forme de réplication utilisée.

Si la réplication configurée est une réplication de mtree (MREPL) ou une réplication de fichiers gérés (MFR) :

DARE 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 :
- Les données ingérées vers la source 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.
Lorsque le chiffrement est désactivé sur la source et que le chiffrement est activé sur la destination :
- Les données ingérées vers la source ne sont pas chiffrées.
- 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 :
- 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 sur le système de destination.
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 les modifications sont appliquées et que le nettoyage est exécuté sur la destination.

Si la réplication configurée est une réplication de collection (CREPL) :

Les systèmes source et de destination doivent exécuter la même version de DDOS.
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 de destination dans son état chiffré.
- La destination a la même clé que la source, car la réplication de collection concerne une réplique exacte du système source.
- Aucune donnée ne peut être écrite vers la 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 :
- Les données reçues sur le système source ne sont pas chiffrées.
- Lors de la réplication, la source envoie les données dans un état non chiffré et elles restent non chiffrées à la destination.
- Aucune donnée ne peut être écrite vers la 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éponse : 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, le même ensemble de clés de chiffrement est présent sur la source et la destination.

Question : Le chiffrement peut-il être activé sur un système de réplication de collection après l’établissement du contexte de réplication ?

Réponse : Oui, dans ce cas, le chiffrement doit être activé à la fois dans la source et dans la destination. Le contexte de réplication doit être désactivé pour pouvoir configurer le chiffrement. 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 : DARE peut-il être activé en même temps que la fonction de chiffrement sur le réseau pour la réplication Data Domain ?

Réponse : Oui, le chiffrement OTW (over-the-wire) et DARE peuvent être activés simultanément pour atteindre différents objectifs de sécurité.

Question : Que se passe-t-il si les chiffrements DARE et OTW sont activés simultanément ?

Réponse : La source chiffre d’abord les données à l’aide de la clé de chiffrement de destination. Ensuite, les données déjà chiffrées sont chiffrées une seconde fois par le chiffrement OTW lors de l’envoi de ces données à leur destination. À la destination, une fois le déchiffrement OTW effectué, 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é sur la source et la destination, doivent-elles avoir la même phrase secrète ?

Réponse : Si la réplication configurée est une réplication de collection, la phrase secrète doit être identique. Pour les autres types de réplication (comme MREPL, MFR), les systèmes peuvent avoir des phrases secrètes différentes.

Question : Lorsque le chiffrement est activé sur la destination, 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 la destination afin que seuls les répertoires répliqués soient chiffrés ?

Réponse : Non, toutes les données sont chiffrées à la 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. Ceci ne s’applique pas au CREPL.

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éponse : Au cours de la phase d’association de la réplication, la destination 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 Data Domain.

Question : Quel type d’algorithme le chiffrement OTW utilise-t-il pour chiffrer le trafic de réplication ?

Réponse : Lorsque le mode d’authentification de réplication est défini sur « unidirectionnel » ou « bidirectionnel », le protocole 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é. « Two-way » indique que les certificats source et de destination sont vérifiés. La confiance mutuelle doit être établie avant que vous puissiez utiliser ce 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. Dans ce cas, la source et la destination ne s’authentifient pas l’une l’autre avant l’échange de clés. L’option « Anonyme » est utilisée par défaut si le mode d’authentification n’est pas spécifié.

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éponse : 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 de répertoire (qui n’est plus prise en charge) et de la réplication delta (également connue sous le nom d’optimisation de bande passante faible ou LBO).

Question : Comment la clé de chiffrement de la destination est-elle protégée lors de l’échange de clés en l’absence de certificats ou de paires de clés PKI ?

Réponse : 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 la réplication est établi par le logiciel Data Domain la première fois que deux instances 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 : Les deux systèmes d’une paire de réplication doivent-ils utiliser 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 le gestionnaire de clés intégré ?

Réponse : Outre la 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. Toutefois, seule la source synchronise les 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 DARE est activé ?

Réponse : 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 au niveau actif et au niveau du Cloud est-elle prise en charge avec DARE activé ?

Réponse : 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 de conditions préalables 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éponse : Les données chiffrées et les clés de chiffrement sont migrées en l’état, mais les paramètres tels que le gestionnaire de clés, 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éponse : La phrase secrète du système, l’état du chiffrement, les détails de configuration du gestionnaire de clés et 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, Data Domain : La Procédure de migration pour les systèmes DD compatibles avec le Cloud (connexion au support Dell obligatoire) détaille 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.

Question : La migration est-elle prise en charge entre les systèmes EDP ?

Réponse : 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 informatique vers un système non informatique si le chiffrement OTW est explicitement désactivé à l’aide de la commande MIGRATION_ENCRYPTION Paramètre système.

Chiffrement et hiérarchisation sur le Cloud

Question : Le chiffrement est-il pris en charge pour le niveau Cloud ?

Réponse : Oui, le chiffrement est pris en charge pour le niveau Cloud. Elle est désactivée par défaut. L’option 'cloud enable' invite à choisir d’activer ou non 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éponse : 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éponse : 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éponse : Non, la gestion des clés est commune aux niveaux actif et Cloud dans Data Domain. Les clés sont copiées vers l’unité, le niveau ou la partition de collecte respectifs lorsque le chiffrement est activé. Si le chiffrement est activé sur le Cloud et non sur le Cloud, les clés du niveau actif ne sont pas reflétées sur le Cloud, et inversement. Cela s’applique également aux unités de Cloud. Par exemple : si cp1 a le chiffrement activé, et cp2 n’a pas de chiffrement activé, alors cp1 touches ne se reflètent pas sur cp2.

Question : Les clés peuvent-elles être supprimées du cloud ?

Réponse : 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éponse : Les clés sont associées à un attribut collection partition (CP), et chaque unité de Cloud correspond à un CP différent. Une copie des clés de tous les CP est stockée dans la partition active.

Question : Comment récupérer des clés Cloud lors d’une reprise après sinistre ?

Réponse : La commande cpnameval est mise en miroir dans le Cloud dans le cadre de la récupération CP, et les clés de chiffrement sont restaurées sur cpnameval. Ensuite, l’option ddr_key_util permet de récupérer les clés.

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

Question : Le déplacement des données peut-il s’exécuter lorsque le chiffrement est activé uniquement pour le niveau Cloud ?

Réponse : Non, le chiffrement doit être activé à la fois dans le niveau Cloud et dans le niveau actif pour que le déplacement des données s’exécute.

Question : Est-il possible d’utiliser un gestionnaire de clés externe avec Cloud Tier ?

Réponse : Oui, le gestionnaire de clés externe peut être utilisé avec Cloud Tier. Cette fonctionnalité est prise en charge à partir de DDOS 7.8. Toutes les opérations (à l’exception de la destruction ou de la suppression d’une clé utilisée 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 de la mémoire (GC) joue-t-il dans DARE ? Y a-t-il un impact sur les performances lors de l’activation initiale du chiffrement ?

Réponse : L’activation de DARE pour la première fois a une incidence sur le rendement du GC. Lorsque GC s’exécute, il lit les données des conteneurs existants sur le disque et les écrit dans de nouveaux conteneurs. Une fois la fonctionnalité DARE activée, ces données 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 système Data Domain contenant une quantité importante de données préexistantes, et que le message 'filesys encryption apply-changes' est exécutée, le prochain cycle GC 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 GC après l’exécution de 'filesys encryption apply-changes' peut prendre plus de temps que d’habitude. Assurez-vous qu’ils disposent de suffisamment d’espace libre sur le système Data Domain pour permettre l’exécution du nettoyage jusqu’à la fin sans que le système Data Domain ne soit saturé (sinon les sauvegardes échouent).

Question : Y a-t-il un impact sur les performances des cycles de nettoyage en cours ?

Réponse : Oui, il y a un impact sur les performances. L’impact dépend généralement de la quantité de données ingérées et restaurées entre les cycles de nettoyage.

Question : Combien de temps faut-il pour chiffrer les données existantes ?

Utilisez cet article pour estimer la durée : Data Domain : Calcul de la durée d’application du chiffrement au repos.

Chiffrement et headswap

Question : Si un système Data Domain avec DARE configuré subit un headswap, les disques sont-ils toujours accessibles avec la nouvelle unité principale ?

Réponse : La clé de chiffrement n’étant pas liée à la tête du système Data Domain elle-même, les disques peuvent donc être déplacés vers une autre tête Data Domain et la clé reste accessible. Le système de fichiers est verrouillé sur le nouvel en-tête et doit être déverrouillé à l’aide de la commande «filesys encryption unlock' et la phrase secrète du système.

Question : Que se passe-t-il si la phrase secrète est perdue au moment de l’opération de headswap ?

Réponse : Si vous la perdez, connectez l’ancienne tête et travaillez avec le support technique pour réinitialiser la phrase secrète. Ensuite, reconnectez-vous à la nouvelle tête et terminez la procédure de headswap.

Chiffrement et performances

Question : Quel est l’impact observé sur la consommation du stockage lorsque DARE est utilisé ?

Réponse : L’impact sur la consommation de stockage est négligeable, avec environ 1 % de surcharge 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 DARE est utilisé ?

Réponse : 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é :

CBC Mode

Première sauvegarde complète : ~ 10 % de dégradation des performances en écriture
Incrémental: ~5 % de dégradation des performances en écriture
Restaure: Dégradation des performances en lecture de 5 à 20 %

GCM Mode

Première sauvegarde complète : Dégradation des performances en écriture de 10 à 20 %
Incrémental: Dégradation des performances en écriture de 5 à 10 %
Restaure: Dégradation des performances en lecture de 5 à 20 %

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.

Pratiques d’excellence

Question : Quelles sont les pratiques d’excellence concernant la règle de rotation des clés ?

Réponse : La règle de rotation automatisée des clés n’est pas activée par défaut. 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 Cloud Tier, l’intervalle de rotation des clés suggéré est hebdomadaire ; lorsque KMIP est configuré uniquement pour le niveau actif, la règle de rotation des clés suggérée est mensuelle. Cependant, cela peut être augmenté ou diminué en fonction du taux d’ingestion. Si le gestionnaire de clés intégré est configuré, il est recommandé de mettre en place une règle de rotation des clés entre 1 et 3 mois.

Question : Quelles sont les pratiques d’excellence relatives à la classe de clés KMIP si le même serveur KMIP est utilisé pour de nombreux systèmes Data Domain ?

Réponse : Il est recommandé de disposer d’une classe de clés distincte pour chaque système Data Domain lorsqu’ils utilisent le même serveur KMIP. De cette façon, la rotation des clés effectuée sur un système n’a pas d’impact sur l’état de la clé présente dans les autres systèmes.

Informations supplémentaires

D’autres documents relatifs à Data Domain Encryption (Guide d’administration, Guide de référence des commandes et Guide de configuration de la sécurité) sont disponibles ici : Documents de référence sur PowerProtect et Data Domain

Regardez cette vidéo :