Dell EMC Data Domain Encryption: preguntas frecuentes

Configuración de cifrado

Pregunta: ¿Cómo se configura el cifrado (DARE) en DD?
Respuesta: El cifrado DARE se puede configurar en DD mediante los siguientes pasos:

1. Agregar licencia de cifrado

2. Agregar director de seguridad y habilitar autorizaciones del director de seguridad

3. Habilitar cifrado 

1) Agregar licencia de cifrado:
tenga un archivo de licencia con una licencia de cifrado válida agregada.
Utilice el siguiente comando para actualizar la licencia electrónica en DD mediante el archivo de licencia disponible.

Actualización de licencia electrónica

2) Agregue el director de seguridad y habilite las autorizaciones de SO:
a) Agregue un usuario con una función como "security" mediante el comando: 

Seguridad de la función de agregado de secuenciador del usuario

b) Active Security Officer Authorization en la configuración mediante el comando: 

Conjunto de políticas de autorización Director de seguridad habilitado

3. Habilite el cifrado DARE:
Habilite el cifrado DARE mediante el comando:

Habilitación de cifrado de filesys

Pregunta: ¿Qué plataformas son compatibles con la función de cifrado de datos en reposo?
Respuesta: La función de cifrado de datos en reposo se soporta en todos los sistemas Data Domain, excepto en los sistemas de proyecto de deshabilitación del cifrado (EDP).

Pregunta: ¿Cómo puede el usuario almacenar sus datos en texto no cifrado en DD?
Respuesta: El usuario puede asegurarse de que los datos se guarden en texto no cifrado y no se cifren en DD si confirma que la opción Cifrado está desactivada en la configuración.
Los usuarios pueden deshabilitar el cifrado en DD mediante el comando: 

Deshabilitación del cifrado de filesys

Pregunta: ¿Qué aplicaciones/protocolos de respaldo son compatibles con la función de cifrado de datos en reposo?
Respuesta: La función DD DARE es independiente de la aplicación de respaldo subyacente o del protocolo utilizado por DD.

Pregunta: ¿Qué algoritmos de cifrado se pueden seleccionar en el sistema Data Domain?
Respuesta: El software DD Encryption es compatible con el algoritmo AES de 128 o 256 bits mediante el encadenamiento de bloques de cifrado (CBC) o el modo de contador de Galois (GCM). 

GCM es un modo de operación para cifrados de bloques criptográficos de clave simétrica. Es un algoritmo de cifrado autenticado diseñado para proporcionar autenticación y privacidad (confidencialidad). Como su nombre indica, GCM combina el conocido modo de cifrado de contador con el nuevo modo de autenticación de Galois. El aspecto de autenticación de GCM garantiza que los datos cifrados fueron realizados por el sistema Data Domain y no fueron "inyectados" por otros medios. Esto difiere del CBC, donde los datos están cifrados (aspecto de privacidad), pero no se verifica la autenticidad de los datos cifrados.

En el modo CBC, cada bloque de texto sin formato es exclusivo OR con el bloque de texto cifrado anterior antes de ser cifrado. De esta manera, cada bloque de texto cifrado depende de todos los bloques de texto sin formato procesados hasta ese momento. Además, para que cada mensaje sea único, se debe utilizar un vector de inicialización en el primer bloque. CBC solo garantiza la privacidad (confidencialidad) de los datos a través del cifrado. No se realiza ninguna autenticación del algoritmo o proceso de cifrado.

Pregunta: ¿Cómo podemos cambiar el algoritmo de cifrado en DD?

Respuesta: Utilice el siguiente comando si desea establecer un algoritmo de cifrado específico en la configuración.

Conjunto de algoritmos de cifrado de filesys

Ejemplo:

# algoritmo de cifrado filesys establecido {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Pregunta: ¿Cómo nos aseguramos de que el cifrado se realice en los datos preexistentes una vez que se habilita el cifrado?
Respuesta: Podemos forzar a DDFS a cifrar los datos preexistentes mediante el siguiente comando:

# filesys encryption apply-changes

Esto hace que el siguiente ciclo de limpieza sea considerablemente más largo y consuma más recursos de lo normal.

Pregunta: ¿Cómo se desactiva el cifrado en DD?
Respuesta: Deshabilite la característica de cifrado en DD mediante el comando encryption disable: 

Deshabilitación del cifrado de filesys

Esto solo deshabilita el cifrado para las I/O entrantes. Los datos cifrados existentes permanecen cifrados hasta que se descifran manualmente mediante apply-changes.

Pregunta: ¿Qué comandos de cifrado requieren el reinicio del sistema de archivos de DD para surtir efecto?
Respuesta: Los siguientes comandos de cifrado requieren un reinicio del sistema de archivos de DD para que surtan efecto:

Habilitación/deshabilitación del cifrado de filesys: Habilita o deshabilita el cifrado en el sistema Data Domain.

Conjunto de algoritmos de cifrado de filesys - Permite que el usuario seleccione un algoritmo criptográfico.

Restablecimiento del algoritmo de cifrado de filesys - Restablece el algoritmo de cifrado a AES 256 en el modo CBC (el valor predeterminado).

Pregunta: ¿Qué comandos de cifrado requieren que el sistema de archivos de Data Domain esté deshabilitado para configurarlos/utilizarlos?
Respuesta: Los siguientes comandos de cifrado requieren que el sistema de archivos de Data Domain esté deshabilitado para configurarlos o utilizarlos:

Cambio de la frase de contraseña de cifrado

Bloqueo/desbloqueo de cifrado

Preguntas generales sobre el cifrado

Pregunta: ¿DD Encryption es compatible con todos los sistemas DD?
Respuesta: La opción de software DD Encryption se soporta en los sistemas DD si no se trata de un proyecto de deshabilitación del cifrado (EDP), que son los sistemas que no permiten habilitar el cifrado, vendidos principalmente en los sistemas de la región de Rusia.

Pregunta: ¿Cómo se realiza la criptografía en los sistemas DD?
Respuesta: La criptografía se realiza mediante OpenSSL y las bibliotecas RSA BSafe (RSA BSafe es una biblioteca de criptografía validada por FIPS 140-2 utilizada por los sistemas DD para cifrar datos en reposo) en DDOS. 

Pregunta: ¿Qué versión de BSafe se utiliza con el sistema?
Respuesta: A partir de DDOS 7.10, las versiones utilizadas de BSafe son "BSAFE Micro Edition Suite 4.4.0.0" y "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Pregunta: ¿Cuáles son las interfaces de usuario disponibles para configurar el cifrado en DDOS?
Respuesta: El cifrado se puede configurar mediante la CLI, la interfaz de usuario o mediante API REST. API REST soportada agregada en la versión 8.0 de DDOS en adelante.

Pregunta: ¿Es posible el cifrado selectivo de datos? ¿Le gusta solo un MTree o un archivo?
Respuesta: El cifrado selectivo NO es posible. El cifrado solo se puede habilitar o deshabilitar en todo el sistema y no de forma selectiva. En los sistemas compatibles con la nube, el cifrado se puede habilitar o deshabilitar en la granularidad del nivel de nube y de la unidad de nube.  

Pregunta: ¿Las claves criptográficas o las contraseñas de cuenta se transmiten o almacenan en texto no cifrado o bajo cifrados débiles, como cuando una entidad se autentica, en archivos de datos, en programas o en directorios de autenticación?
Respuesta: En absoluto.

Pregunta: ¿Qué versión de OpenSSL se utiliza con el sistema?
Respuesta: A partir de la versión DD OS 7.10, la versión de openssl es "OpenSSL 1.0.2zd-fips"

Pregunta: ¿Cómo protege el cifrado de datos en reposo contra el acceso a datos por parte de los usuarios y las aplicaciones?
Respuesta: 

• El cifrado de datos en reposo consiste en cifrar los datos que residen en el subsistema del disco. El cifrado o descifrado se produce en la capa de compresión. Los usuarios o las aplicaciones envían y reciben datos de texto no cifrado al sistema Data Domain, pero todos los datos que residen físicamente en el sistema Data Domain se cifran.
• Todo el cifrado se produce debajo del sistema de archivos y el espacio de nombres, y es invisible para los usuarios o las aplicaciones. Si un usuario o una aplicación ya tienen acceso autorizado a un archivo o directorio, los datos se pueden leer en su formato nativo, independientemente del cifrado.
• DD Encryption está diseñado de modo que si un intruso elude otros controles de seguridad de red y obtiene acceso a los datos cifrados, sin las claves criptográficas adecuadas, esa persona puede leer y utilizar los datos. 

Pregunta: ¿Se realizará el cifrado después de la desduplicación?
Respuesta: Sí, el cifrado se produce en datos desduplicados. Los datos se cifran antes de almacenarse en el disco. 

Pregunta: ¿Cómo garantiza Data Domain la seguridad de los datos?
Respuesta: Los datos se protegen mediante la función de cifrado de datos en reposo. Además, cuando se elimina el dispositivo (intercambio de cabezal, bloqueo del sistema de archivos), la frase de contraseña se elimina del sistema. Esta frase de contraseña se utiliza para cifrar las claves de cifrado, por lo que los datos se protegen aún más.

Pregunta: ¿Qué alertas se generan con cifrado?
Respuesta: Las alertas se generan en los siguientes casos:

• Cuando hay claves de cifrado comprometidas presentes
• Cuando la tabla de claves de cifrado está llena y no se pueden agregar más claves en el sistema
• Cuando falla la exportación automática de claves
• Cuando falla la rotación de claves automatizada
• Cuando el cifrado está deshabilitado
• Cuando se cambia la frase de contraseña del sistema

Pregunta: ¿Hay alguna certificación de seguridad para DDOS? 
Respuesta: Los sistemas Data Domain cumplen con el cumplimiento de FIPS 140-2. 

Pregunta: ¿Dónde se almacena la clave de cifrado?
Respuesta: Las claves de cifrado se almacenan de forma persistente en una partición de recopilación en el sistema DDOS.

Pregunta: Si alguien extrae un disco duro de un sistema Data Domain, ¿puede descifrar los datos del mismo?
Respuesta: Las claves de cifrado se cifran mediante la frase de contraseña del sistema, la cual se almacena en el cabezal del sistema. A pesar de que las claves de cifrado se almacenan en el disco, sin una frase de contraseña del sistema, las claves de cifrado no se pueden descifrar. Por lo tanto, sin conocer la clave que se utilizó para cifrar los datos, el descifrado no es posible desde un disco duro.  

Pregunta: ¿Qué claves criptográficas y contraseñas se necesitan para la recuperación, especialmente para la recuperación ante desastres?
Respuesta: Las claves se pueden exportar en un archivo seguro y mantener fuera del sistema. La recuperación de este archivo se realiza con la ayuda del equipo de ingeniería. Además, en el momento de la recuperación, el cliente debe conocer la frase de contraseña que utilizó en el momento del comando de exportación de claves.

Pregunta: Cómo bloquear el sistema de archivos antes del tránsito del sistema a una ubicación remota.
Respuesta: A continuación se muestra el procedimiento para ello: 

• Deshabilite el sistema de archivos:

  sysadmin@itrdc-DD630-42# filesys disable

• Bloquee el sistema de archivos e ingrese una nueva frase de contraseña (esto requiere autenticación por parte del usuario de seguridad anterior):

  sysadmin@itrdc-DD630-42# Bloqueo
  de cifrado del sistema de archivos Este comando requiere la autorización de un usuario que tenga una función de "seguridad".
  A continuación, presente las credenciales para dicho usuario.
          Nombre de usuario: secuser
  Contraseña:
  Ingrese la frase de contraseña actual:
  Ingrese una nueva frase de contraseña:
  Vuelva a ingresar la nueva frase de contraseña:
  Frases de contraseña coincidentes.
  El sistema de archivos ahora está bloqueado.

• La nueva frase de contraseña NO se debe perder ni olvidar. Sin esta frase de contraseña, el sistema de archivos no se puede desbloquear, lo que significa que no se puede acceder a los datos en el DDR. Para desbloquear el sistema cuando llega a una ubicación remota, utilice el siguiente comando:

sysadmin@itrdc-DD630-42# desbloqueo
de cifrado filesys Este comando requiere la autorización de un usuario que tenga una función de "seguridad".
Presente las credenciales de dicho usuario a continuación.
        Nombre de usuario: secuser
Contraseña:
Ingrese la frase de contraseña:
La frase de contraseña ha sido verificada. Utilice "filesys enable" para iniciar el sistema de archivos.

• El sistema de archivos ahora se puede habilitar y utilizar de manera normal

Pregunta: ¿El comando storage sanitize tiene alguna relación con el cifrado del sistema de archivos?
Respuesta: No, el cifrado del sistema de archivos y el saneamiento del almacenamiento son dos funciones independientes. 

Pregunta: ¿Es compatible el cifrado por cable en el sistema EDP (proyecto de deshabilitación del cifrado)?
Respuesta: No podemos habilitar el cifrado de datos en reposo (DARE) ni el cifrado por cable (con replicación o con ddboost) en el sistema EDP.

Frase de contraseña del sistema 

Pregunta: ¿Cuál es la frase de contraseña del sistema?
Respuesta: DDOS tiene la disposición de proteger las credenciales dentro del sistema mediante la configuración de una frase de contraseña a nivel del sistema. La frase de contraseña es una clave legible (comprensible) por el ser humano, como una tarjeta inteligente, que se utiliza para generar una clave de cifrado AES 256 utilizable por máquina. 

Proporciona dos beneficios:

• Permite que el administrador cambie la frase de contraseña sin tener que manipular las claves de cifrado. Cambiar la frase de contraseña cambia indirectamente el cifrado de las claves, pero no afecta los datos de usuario. El cambio de la frase de contraseña no cambia la clave de cifrado subyacente del sistema Data Domain. Cambia el cifrado de la clave del sistema Data Domain, pero la clave del sistema permanece igual.
• Permite enviar un sistema Data Domain físico con una clave de cifrado en el sistema, pero sin que la frase de contraseña se almacene en él. De esta manera, si la caja es robada en tránsito, un atacante no puede recuperar fácilmente los datos, ya que el sistema solo tiene claves cifradas y datos cifrados.

La frase de contraseña se almacena internamente en una parte oculta del sistema de almacenamiento de Data Domain. Esto permite que el sistema Data Domain arranque y continúe brindando servicio al acceso a datos sin la intervención del administrador.

Creación o cambio de la frase de contraseña:

• La frase de contraseña del sistema se puede crear mediante la CLI después de que un administrador se autentique en el sistema Data Domain.
• La frase de contraseña del sistema se puede cambiar mediante la CLI después de que un administrador y un usuario con función de seguridad (como un director de seguridad) se autentiquen en el sistema Data Domain (de manera tal que ningún administrador pueda realizar cambios de manera independiente).

Pregunta: ¿Cuándo se utiliza la frase de contraseña?
Respuesta: Varios componentes de DDOS, entre los que se incluyen el cifrado del sistema de archivos, el acceso a la nube, la administración de certificados, los tokens de Boost, los módulos de configuración del sistema en entornos de escalamiento horizontal y la información de licenciamiento utilizan la frase de contraseña del sistema. El software DDOS proporciona mecanismos para establecer y modificar esta frase de contraseña del sistema. También proporciona opciones para controlar si la frase de contraseña del sistema se almacena en el disco, lo que se utiliza especialmente para mejorar la seguridad cuando se transporta el sistema de DD. 

Pregunta: ¿Cómo se utiliza la frase de contraseña para el transporte seguro del sistema de DD?
Respuesta: El proceso utiliza el comando "filesys encryption lock", que permite que el usuario bloquee el sistema de archivos cambiando la frase de contraseña. El usuario ingresa una nueva frase de contraseña que vuelve a cifrar la clave de cifrado, pero la nueva frase de contraseña no se almacena. Las claves de cifrado no se pueden recuperar hasta que el sistema de archivos se desbloquee mediante el comando "filesys encryption unlock".

El proceso se describe en la Guía de configuración de seguridad de Confluence Lab.

Pregunta: ¿Qué sucede si cambia la frase de contraseña? ¿Aún se puede acceder a los datos?
Respuesta: Sí, el cambio de la frase de contraseña no cambia la clave de cifrado del sistema Data Domain subyacente, solo el cifrado de la clave de cifrado. Por lo tanto, el acceso a los datos no se ve afectado.

Pregunta: ¿Cómo podemos consultar si se estableció una frase de contraseña en el sistema?
Respuesta: Si se establece una frase de contraseña en el sistema, la ejecución del comando "system passphrase set" produce un error que indica que la frase de contraseña ya está establecida.

Pregunta: ¿Qué sucede si la frase de contraseña se pierde u olvida?
Respuesta: Si el cliente pierde la frase de contraseña mientras la casilla está bloqueada, pierde sus datos. No hay una puerta trasera o una forma alternativa de acceder a él. Sin un buen proceso para administrar esa frase de contraseña, esto podría suceder accidentalmente y no podrían recuperar la clave o los datos. Sin embargo, la clave cifrada nunca se puede perder ni dañar debido a los mecanismos de protección integrados del sistema.

Pregunta: ¿Hay algún mecanismo para restablecer la frase de contraseña del sistema olvidada?
Respuesta: La frase de contraseña del sistema se puede restablecer forzosamente solo en ciertas situaciones con la ayuda del servicio al cliente. El mecanismo de actualización forzada introducido en DDOS 7.2 se puede utilizar para esto solo si se cumplen condiciones específicas. Encontrará más detalles en el artículo de la base de conocimientos 20983, Data Domain: Cómo restablecer una frase de contraseña de sistema perdida en DDOS v7.2 o posterior (se requiere iniciar sesión en el soporte de Dell para ver el artículo)

Pregunta: ¿Existe alguna opción para evitar el almacenamiento de la frase de contraseña del sistema en el sistema de DD?
Respuesta: De manera predeterminada, la frase de contraseña del sistema se almacena en una ubicación oculta en el sistema Data Domain. La opción del sistema "system passphrase option store-on-disk" se puede utilizar para cambiar esto y evitar el almacenamiento de la frase de contraseña en el disco.

Administrador de claves integrado (EKM)

Comando de nivel superior:

Opción de administrador <de claves integradas de cifrado del sistema de archivos system#>

Pregunta: ¿Es compatible la rotación de claves con el administrador de claves integrado?
Respuesta:  Sí, la rotación de claves por sistema Data Domain es compatible con el administrador de claves integrado. A través de la interfaz de usuario o la CLI, el administrador puede configurar un período de rotación de claves (semanal o mensual).

Pregunta: ¿Se cobra por la funcionalidad de administración de claves integrada?
Respuesta: Esta funcionalidad es gratuita. Esta funcionalidad se incluye como parte de la opción de licencia de software DD Encryption estándar.

Pregunta: ¿Puede el cliente pasar de la administración de claves local a la administración de claves externa (EKM)?
Respuesta

• Sí, los administradores de claves externos se pueden habilitar en cualquier momento. Sin embargo, las claves locales que se utilizan permanecen en el sistema Data Domain. Los administradores de claves externos no pueden administrar las claves de EKM. No es necesario volver a cifrar los datos existentes. Si para un cliente, los datos de cumplimiento se deben volver a cifrar con claves EKM, se debe realizar manualmente mediante apply-changes con la nueva clave RW. La destrucción de claves de EKM después de un switch no es obligatoria.
  • El switch key-manager cambia automáticamente la clave activa a la clave desde KMIP. 
  • Ejemplo de cómo se ve el MUID de clave KMIP cuando se produce un cambio

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

Pregunta: ¿Qué sucede cuando la rotación de claves está habilitada o deshabilitada?
Respuesta: 

• La rotación de claves deshabilitada es la funcionalidad de cifrado predeterminada si no habilita la rotación de claves desde la interfaz de usuario o la CLI. En ese escenario, todos los datos se cifran con la clave activa existente.
• Si la rotación de claves está habilitada, según la frecuencia de rotación, rotamos las claves y los datos se cifran con la clave activa más reciente.

Administradores de claves externos

Pregunta: ¿Cuáles son los administradores de claves externos compatibles con DD?
Respuesta: Apoyamos a los siguientes administradores de claves externos:

• KeySecure de Gemalto (compatibilidad agregada en DDOS versión 7.2)
• Vormetric (compatibilidad agregada en DDOS versión 7.3)
• CipherTrust (compatibilidad agregada en DDOS versión 7.7)
• IBM GKLM (compatibilidad agregada en DDOS versión 7.9)

Pregunta: ¿Se requiere una licencia independiente para habilitar la integración con un administrador de claves externo?
Respuesta: Sí, se necesita una licencia independiente del proveedor respectivo para integrar el administrador de claves externo con DD.

Pregunta: ¿Cuántos gerentes clave admiten a la vez?
Respuesta: Solo un administrador de claves puede estar activo en cualquier momento determinado en un sistema DD.

Pregunta: ¿Dónde puedo encontrar más información sobre cómo configurar el administrador de claves externo de KMIP?
Respuesta: La Guía de integración de KMIP para DDOS contiene información detallada para configurar los diferentes administradores de claves externos compatibles con DD.

Pregunta: ¿Cómo se administran los certificados para los administradores de claves externos en DD?
Respuesta: Durante la configuración del administrador de claves externo, debemos generar un certificado de CA (el certificado de CA podría ser un certificado autofirmado o firmado por un tercero) y un certificado de host. Una vez que la configuración se realiza en el servidor del administrador de claves externo, los usuarios deben importar el certificado de CA y el certificado de host en el sistema de DD. Luego, configuramos y habilitamos el administrador de claves externo. 

Pregunta: ¿Qué es CA?
Respuesta: Una autoridad de certificación (CA) actúa como la entidad compartida de confianza inicial entre pares y emite certificados firmados para que cada parte pueda confiar en la otra. Por lo general, un certificado actúa como la identidad de un servidor o cliente. 

Pregunta: ¿Qué es un certificado firmado por una CA local y qué es un certificado firmado por una CA?
Respuesta: Un certificado firmado por una CA es un certificado emitido y firmado por una autoridad de certificación (CA) de confianza pública. Un certificado firmado por una CA se confía automáticamente. Una CA local puede emitir certificados firmados, ya que la clave de firma privada se almacena en el sistema del administrador de claves. Una CA externa no almacena la clave privada. En su lugar, se utiliza una CA externa como entidad de confianza para varias interfaces y servicios dentro del sistema.

Pregunta: ¿Cómo crear una solicitud de firma de certificado en DD?
Respuesta: En el sistema Data Domain, genere la CSR mediante el siguiente comando de la CLI. De esta manera, la clave privada nunca se expone al administrador de claves externo.

Solicitud de firma de certificado de certificado de adminaccess

Pregunta: ¿Es posible alternar entre administradores de claves?
Respuesta: El cambio entre el administrador de claves externo y el administrador de claves integrado está permitido y es transparente. Sin embargo, el cambio del administrador de claves integrado a los administradores de claves externos requiere la instalación y la configuración adecuadas del certificado. Cambiar entre dos administradores de claves externos (por ejemplo: KMIP-CipherTrust, DSM-CipherTrust, CipherTrust to GKLM) también están permitidos. También se admite la migración de claves del administrador de claves (consulte la guía de integración de KMIP para obtener más detalles).

Pregunta: ¿Qué sucede cuando la conectividad externa del administrador de claves deja de funcionar? Entonces, ¿se puede acceder a mis datos?
Respuesta: Sí, aún se puede acceder a los datos cuando no podemos conectarnos al administrador de claves, ya que también almacenamos copias de las claves en el sistema de DD. No se pueden crear claves nuevas o no se pueden sincronizar los estados de las claves cuando no hay conectividad con el administrador de claves externo.

Pregunta: ¿Hay alguna manera de evitar el almacenamiento de claves en DD y almacenarlas solo en el administrador de claves externo?
Respuesta: Siempre almacenamos una copia de las claves en el sistema de DD para fines de DIA. Esta configuración no se puede cambiar.

Pregunta: ¿Existe algún impacto en el rendimiento debido a la integración con KMIP?
Respuesta: No, no hay impacto en el rendimiento debido al uso de administradores de claves externos.

Pregunta: ¿Es posible aprovechar la solución KMIP para determinados Data Domains dentro del entorno?
Respuesta: Sí, los clientes tienen total flexibilidad para seleccionar la metodología de cifrado adecuada para sus sistemas Data Domain. Pueden continuar aprovechando el administrador de claves integrado de Data Domain en algunos sistemas Data Domain y la rotación de claves de cifrado mediante KMIP en otros sistemas Data Domain dentro de su entorno.

Pregunta: ¿Es segura la comunicación de Data Domain a KMIP?
Respuesta: Sí, Data Domain se comunica a través de sesiones autenticadas mutuamente de certificado X509 con TLS. El usuario puede usar la CLI de Data Domain para importar el certificado X509 correspondiente al sistema Data Domain. Este certificado se utiliza para establecer el canal seguro entre DD y KMIP.

Administración del ciclo de vida clave 

Pregunta: ¿Qué funcionalidades de administración de claves existen con la opción DD Encryption?
Respuesta: Un administrador de claves controla la generación, la distribución y la administración del ciclo de vida de varias claves de cifrado. Un sistema de protección puede utilizar el administrador de claves integrado o el administrador de claves externo compatible con KMIP. Solo puede haber un administrador de claves activado a la vez. Cuando el cifrado está habilitado en un sistema de protección, el administrador de claves integrado está vigente de manera predeterminada. Si se configura un administrador de claves externo, reemplaza al administrador de claves integrado y permanece vigente hasta que se deshabilita manualmente. Cambiar del administrador de claves integrado al administrador de claves externo o viceversa, da como resultado la adición de una nueva clave al sistema y no es necesario reiniciar el sistema de archivos desde la versión 7.1.

Pregunta: ¿Cuáles son los diferentes estados de clave en el sistema Data Domain?
Los diferentes estados de clave en el sistema Data Domain son los siguientes:

• RW activado: Solo hay una clave en este estado en cualquier sistema DD y se utiliza para leer y escribir datos. El proceso de GC también utiliza esta clave para volver a cifrar contenedores.
• Pendiente de activación: Solo hay una clave en este estado en cualquier sistema DD. Esto identificó la clave que se convertirá en Activated-RW después del siguiente reinicio del sistema de archivos. En la actualidad, este estado existe solo en el momento de habilitar el cifrado. No se crea ninguna otra clave activada pendiente de tiempo.  
• RO activado: Los administradores de claves externos pueden tener varias claves activadas. La clave más reciente está en Activated-RW; el resto está en este estado. Las claves pueden entrar en este estado en el sistema de DD cuando no podemos sincronizar el estado con el administrador de claves.
• Desactivado: Se utiliza para leer los datos existentes en el sistema DD.
• Comprometido: Cuando un cliente pone en riesgo una clave de administrador de claves externo, el estado se cambia a ella después de la siguiente sincronización de claves.  
• Marcados para destruidos: Cuando un cliente marca una clave para su destrucción, el estado de la clave se convierte en Marcado para destruir. Cuando se ejecuta GC, todos los contenedores cifrados con claves marcadas como destruidas se vuelven a cifrar con la clave Activated-RW.
• Destruido: Una clave en el estado Marcado para destruido entra en este estado cuando no hay datos asociados a ella.
• Destruidos y comprometidos: Una clave en el estado Compromised entra en este estado cuando no hay datos asociados con ella.

Pregunta: ¿Se pueden exportar las claves de cifrado para la recuperación ante desastres?
Respuesta: Las claves se pueden exportar manualmente mediante el siguiente comando.

"Exportación de claves de cifrado de filesys"

El sistema DD también exporta claves de manera predeterminada cuando se agrega una nueva clave o cuando se elimina cualquier clave del sistema.

Los archivos exportados están presentes en /ddr/var/.security y eso está en un formato cifrado. A continuación, este archivo se debe copiar fuera del DDR y almacenarse en una ubicación segura que se pueda utilizar en cualquier condición de recuperación ante desastres más adelante.

Nota: La importación de claves para la recuperación ante desastres requiere la intervención del servicio al cliente, ya que el proceso de restauración depende del tipo de desastre encontrado. Podemos importar el archivo de clave exportado mediante el siguiente comando.

Claves de cifrado de filesys Importar <nombre de archivo> 

Pregunta: ¿La clave generada por KMIP se almacena en el sistema Data Domain?
Respuesta: Sí, la clave de cifrado obtenida del KMIP se almacena de manera cifrada en el sistema Data Domain.

Pregunta: ¿Cómo se aplica un cambio de estado de clave en el dispositivo KMIP al sistema Data Domain?
Respuesta: La sincronización de claves se realiza diariamente. Si hay una nueva clave disponible o se cambia el estado de la clave, la sincronización actualiza la tabla de claves locales. DD recibe actualizaciones clave de KMIP todos los días a medianoche.

Pregunta: ¿Es posible sincronizar manualmente los estados de clave entre DD y KMIP?
Respuesta: Sí, la interfaz de usuario o la CLI de Data Domain se pueden usar para sincronizar manualmente los estados clave entre DD y KMIP. "filesys encryption keys sync" es el comando utilizado para ello.

Pregunta: ¿Es posible cambiar la hora en que DD recibe actualizaciones clave de KMIP?
Respuesta: No, no es posible cambiar la hora en que DD recibe actualizaciones clave de KMIP.

Pregunta: ¿Existe un límite en la cantidad de claves admitidas por el sistema Data Domain?
Respuesta: A partir de DD OS 7.8, en cualquier momento, el sistema Data Domain puede tener un máximo de 1024 claves en el sistema. Solo hay una clave en Activated-RW y el resto de las claves pueden estar en cualquier otro estado.

Pregunta: ¿Se pueden utilizar diferentes claves para diferentes conjuntos de datos en los sistemas Data Domain? ¿Se puede configurar?
Respuesta: No, solo admitimos una clave activa en el sistema a la vez y todos los datos entrantes se cifran con la clave activa actual. Las claves no se pueden controlar con una granularidad más fina, como los árboles M.

Pregunta: ¿Hay alguna notificación cuando se alcanza el límite máximo de claves?
Respuesta: Sí, se genera una alerta cuando se alcanza el límite máximo de claves de 1024.

Pregunta: ¿Cómo puedo borrar la alerta sobre el límite máximo de claves?
Respuesta: Se debe eliminar una de las claves para borrar la alerta de límite máximo de claves.

Pregunta: ¿Podemos ver la cantidad de datos asociados con una clave específica en el sistema Data Domain?
Respuesta: Sí, esto se puede ver en DD, pero no en el servidor KMIP. El usuario puede usar la interfaz de usuario y la CLI de Data Domain para ver la cantidad de datos asociados con una clave específica.

Pregunta:  ¿Podemos ver la antigüedad de las claves en el sistema DD?
Respuesta: Sí, se puede ver con claves EKM mediante la interfaz de usuario.

Pregunta: ¿Funciona la clave antigua incluso si ha transcurrido el período de tiempo para que la nueva clave entre en vigencia?
Respuesta: No hay fecha de vencimiento para las claves de cifrado. Las claves antiguas se convierten en claves de solo lectura después de la rotación de claves y permanecen en DDOS.

Pregunta: ¿La clave de cifrado se elimina automáticamente cuando no hay datos asociados con ella en el sistema Data Domain?
Respuesta: No, la clave no se elimina automáticamente. El usuario debe eliminar explícitamente la clave mediante la CLI o la interfaz de usuario de DD.

Pregunta: ¿Se puede eliminar una clave incluso si hay datos asociados con ella en el sistema Data Domain?
Respuesta: No, si una clave tiene datos asociados, no se puede eliminar. Es necesario volver a cifrar los datos con alguna otra clave para eliminar una clave que tiene datos asociados.

Pregunta: Si se elimina una clave en KMIP, ¿también se elimina la clave de la lista de claves de Data Domain?
Respuesta: No, el usuario debe eliminar la clave de manera independiente mediante la CLI o la interfaz de usuario de DD.

Pregunta: En un entorno de Data Domain de múltiples sitios, ¿se requiere un KMIP en cada ubicación?
Respuesta: No, no es necesario tener un KMIP en cada sitio con un Data Domain. Podemos apuntar a un servidor KMIP. Se recomienda tener una clase de clave separada para cada sistema DD cuando se utiliza el mismo servidor KMIP.

Pregunta: Si una clave se ve comprometida, ¿tenemos algún proceso para recuperar los datos cifrados con la clave antigua?
Respuesta: En este caso, el cliente debe marcar la clave como comprometida en el servidor KMIP. A continuación, ejecute "filesys encryption keys sync" en el sistema DDOS y, a continuación, ejecute "filesys encryption apply-changes" y, a continuación, ejecute GC (filesys clean). La ejecución de GC vuelve a cifrar todos los datos que se cifraron con la clave comprometida mediante una clave más reciente. Una vez que se realiza la GC, el estado de la clave cambia a compromised-destroyed. Más adelante, pueden eliminar esa clave. 

Cifrado y replicación

Pregunta: ¿DD Replication es compatible e interoperable con la opción de software DD Encryption?
Respuesta: Sí, DD Replication se puede utilizar con la opción DD Encryption, lo que permite que los datos cifrados se repliquen mediante todos los diferentes tipos de replicación. Cada forma de replicación funciona de manera exclusiva con cifrado y ofrece el mismo nivel de seguridad.

Pregunta: ¿Los sistemas de origen y destino tienen que ejecutar la misma versión de DD OS para usar el cifrado?
Respuesta: El origen y el destino pueden estar en diferentes versiones de DDOS para usar DARE con replicación si la matriz de compatibilidad de replicación (consulte la guía de administración para ver la matriz de compatibilidad) está implementada. 

Pregunta: ¿Cómo funciona la replicación con cifrado?
Respuesta: Depende de la forma de replicación que se utilice.

Si la replicación configurada es MREPL o MFR:
Si se utiliza MREPL o MFR, DD Encryption puede obtener una licencia o habilitarse en el origen o el destino de manera independiente, según lo que el cliente desee lograr.

• Cuando el origen y el destino tienen habilitado el cifrado: Cuando se recopilan datos en el sistema de origen, se cifran con la clave de cifrado del sistema de origen. El origen descifra los datos locales, los vuelve a cifrar con la clave de cifrado del sistema de destino y, a continuación, replica los datos cifrados en el destino cuando se replica.
• Cuando el origen tiene el cifrado deshabilitado y el destino lo tiene habilitado: Todos los datos recopilados en el origen no están cifrados (por razones obvias). Sin embargo, cuando se realiza una replicación, el origen cifra los datos mediante la clave de cifrado del sistema de destino y, a continuación, replica los datos cifrados en el sistema de destino. 
• Cuando el origen tiene habilitado el cifrado y el destino lo tiene deshabilitado: Todos los datos que se ingresan al sistema de origen se cifran con la clave de cifrado del sistema de origen. El origen descifra los datos y, a continuación, replica los datos sin cifrar en el sistema Data Domain de destino cuando realiza la replicación.
• Si el cifrado está habilitado en la réplica después de configurar el contexto de replicación, los segmentos nuevos que se están replicando se cifran en el origen de la réplica. Todos los segmentos que residen en la réplica antes de que se habilite el cifrado se dejan en un estado sin cifrar, a menos que se apliquen cambios en el cifrado y se ejecute GC en el destino. 

Si la replicación configurada es CREPL:
Con la replicación de recopilaciones, los sistemas de origen y destino deben ejecutar la misma versión de DDOS. Por lo tanto, el cifrado debe estar habilitado o deshabilitado en ambos. Tampoco puede haber una incompatibilidad en la configuración de cifrado. Las claves de cifrado son las mismas que las del origen y el destino. 

• Cuando el origen y el destino tienen habilitado el cifrado: Todos los datos que se ingresan al sistema de origen se cifran mediante la clave de cifrado del sistema de origen. Cuando se replica, el origen envía datos cifrados al sistema Data Domain de destino en su estado cifrado. El sistema Data Domain de destino tiene la misma clave que el origen, ya que la replicación de recopilaciones se trata de una réplica exacta del sistema Data Domain de origen. No se pueden escribir datos en el sistema Data Domain de destino fuera de la replicación, ya que el destino es un sistema de solo lectura.
• Cuando tanto el origen como el destino tienen el cifrado deshabilitado: Todos los datos recopilados en el sistema de origen no están cifrados (por razones obvias). Cuando se replica, el origen envía (replica) los datos en un estado sin cifrar y permanecen sin cifrar en el sistema Data Domain de destino. No se pueden escribir datos en el sistema Data Domain de destino fuera de la replicación, ya que el destino es un sistema de solo lectura.

Pregunta: ¿La clave del destino se almacena indefinidamente en el sistema Data Domain de origen?
Respuesta: La clave de cifrado del destino nunca se almacena en el sistema Data Domain de origen. Solo se mantiene en la memoria (cifrada) mientras la sesión de replicación está activa. Esto se aplica a todos los tipos de replicación, excepto a la replicación de recopilaciones. En la replicación de recopilaciones (CREPL), el mismo conjunto de claves de cifrado está presente en el origen y el destino.  

Pregunta: ¿Se puede habilitar el cifrado en el sistema CREPL después de establecer el contexto de replicación?
Respuesta: Sí, en este caso, el cifrado debe estar habilitado tanto en el origen como en el destino. El cifrado se puede habilitar en el origen y el destino mediante la deshabilitación del contexto de replicación. Todos los segmentos nuevos replicados se cifran en la réplica. Todos los segmentos que residen en la réplica antes de que se habilitara el cifrado se dejan en un estado sin cifrar.

Pregunta: ¿Se puede habilitar DD Encryption simultáneamente con la función de cifrado por cable en la opción de software DD Replication?
Respuesta: Sí, tanto el cifrado por cable como el D@RE se pueden habilitar simultáneamente para lograr diferentes objetivos de seguridad.

Pregunta: ¿Qué sucede si la opción de software DD Encryption y la función de cifrado por cable en la opción de software DD Replication se habilitan simultáneamente?
Respuesta: El primer origen cifra los datos mediante la clave de cifrado de destino. Luego, los datos ya cifrados se cifran por segunda vez debido al cifrado por cable mientras se envían estos datos a su destino. En el destino, después de que se realiza el descifrado por cable, los datos se almacenarán en un formato cifrado que se cifró con la clave de cifrado del destino.

Pregunta: Cuando el cifrado está habilitado en el origen y el destino, ¿la frase de contraseña debe ser la misma en ambos?
Respuesta: Si la replicación configurada es replicación de recopilación (CREPL), la frase de contraseña debe ser la misma. Para otros tipos de replicación (como MREPL, MFR), la frase de contraseña puede tener un origen y un destino diferentes.

Pregunta: Con el cifrado habilitado en el destino (pregunta no aplicable a CREPL), ¿se cifran tanto los datos replicados como los datos de algún otro punto de acceso (por ejemplo, a través de un respaldo local)? ¿Hay alguna manera de separar los dos en la réplica en la que solo se cifran los directorios replicados y no se cifra otro acceso?
Respuesta: No, todos los datos se cifran en la réplica (destino), independientemente del punto de entrada. El cifrado no solo se puede habilitar o deshabilitar en una granularidad de nivel de directorio o MTree. 

Pregunta: ¿Cómo se realiza el intercambio de claves entre el origen y el destino durante MREPL o MFR?
Respuesta: Durante la fase de asociación de la replicación, el equipo de destino transmite de manera segura su algoritmo de cifrado actual y la información de clave al origen. Los contextos de replicación siempre se autentican con una seña secreta compartida. Ese secreto compartido se utiliza para establecer una clave de "sesión" mediante un protocolo de intercambio de claves Diffie-Hellman. Esa clave de sesión se utiliza para cifrar y descifrar la clave de cifrado del sistema Data Domain.

Pregunta: ¿Qué tipo de algoritmo de cifrado se utiliza para la función de "cifrado por cable" de Data Domain con respecto al cifrado del tráfico de replicación?
Respuesta: Cuando el modo de autenticación de replicación se configura en "one-way" o "two-way", se utiliza DHE (Diffie-Hellman efímero) para el intercambio de claves de sesión. La autenticación del servidor se produce mediante RSA. El cifrado GCM AES de 256 bits se utiliza para encapsular los datos replicados a través del cable. La capa de encapsulación de cifrado se elimina inmediatamente cuando llega al sistema de destino. 

Una vía indica que solo el certificado de destino está certificado. Dos maneras indican que se verifican los certificados de origen y destino. Se debe establecer la confianza mutua antes de poder usar el modo de autenticación y ambos lados de la conexión deben habilitar esta característica para que el cifrado continúe.

Cuando el modo de autenticación de replicación se establece en "anónimo", se utiliza Diffie-Hellman anónimo (ADH) para el intercambio de claves de sesión, pero, en este caso, el origen y el destino no se autentican entre sí antes del intercambio de claves. Además, si no se especifica el modo de autenticación, se utiliza anonymous como valor predeterminado.

Pregunta: ¿La rotación de claves sin reiniciar el sistema de archivos funciona con todos los tipos de replicación?
Respuesta: La rotación de claves sin reiniciar el sistema de archivos funciona con todos los tipos de replicación, excepto DREPL (el soporte de DREPL ya finalizó) y la replicación delta (que también se conoce como LBO)

Pregunta: En ausencia de certificados o pares de claves PKI, ¿cómo se protege la clave de cifrado del destino durante el intercambio de claves?
Respuesta: Hay una seña secreta compartida entre todos los pares de replicación de Data Domain que se utiliza para establecer una clave de sesión compartida mediante un intercambio de claves Diffie-Hellman. Esa clave compartida se utiliza para cifrar la clave de cifrado del destino.

Existe una diferencia entre la seña secreta compartida que se utiliza para la autenticación de replicación y la clave de sesión compartida, que se asigna mediante el protocolo de intercambio de claves Diffie-Hellman. El software Data Domain establece la seña secreta compartida utilizada para la autenticación de replicación la primera vez que dos sistemas Data Domain desean establecer un contexto de replicación. También se acuerda a través de un intercambio Diffie-Hellman utilizando parámetros incrustados en el código. Esto se almacena de manera permanente en los sistemas para autenticar cada sesión de replicación entre los dos sistemas. La clave de sesión de replicación (la clave utilizada para cifrar la clave de cifrado del destino) se establece mediante otro intercambio de Diffie-Hellman con el secreto compartido establecido anteriormente, lo que impulsa el protocolo de intercambio de claves seguro. Esta clave no es persistente y solo está disponible mientras el contexto de replicación está activo.

Pregunta: ¿Es necesario que ambos Data Domain de un par de replicación utilicen la misma solución de administrador de claves externo (como el administrador de claves KMIP) o uno de los sistemas puede usar un administrador de claves externo y otro puede usar un administrador de claves integrado?
Respuesta: A excepción de un par de replicación de recopilaciones, no es necesario que ambos sistemas dentro de un par de replicación utilicen el mismo administrador de claves.

Con la replicación de recopilaciones, ambos sistemas Data Domain deben configurarse con el mismo administrador de claves. Pero también en ese caso, la única fuente es la sincronización de claves con el administrador de claves y esas claves también se envían al destino. Con otros tipos de replicación, se pueden usar diferentes administradores de claves con origen y destino.

Cifrado y migración

Pregunta: ¿Se admite la migración de datos en sistemas con cifrado habilitado?
Respuesta: Sí, la migración de datos es compatible con sistemas con cifrado habilitado. La configuración de cifrado en los sistemas de origen y destino debe coincidir como requisito previo antes de que se inicie la migración de datos. También se recomienda exportar y respaldar las claves de cifrado en el sistema de origen para fines de DIA antes de iniciar la migración.

Pregunta: ¿Se admite la migración de datos para la migración de nivel activo y de nivel de nube para sistemas habilitados para cifrado?
Respuesta: Sí, la migración de datos es compatible con la migración de nivel activo y de nivel de nube para sistemas habilitados para cifrado. La lista de atributos de requisitos previos verificados se aplica según el nivel en el que el cifrado esté habilitado.

Pregunta: ¿Qué configuración de cifrado se conserva como parte de la migración?
Respuesta: Los datos cifrados y las claves de cifrado se migran tal cual, pero los ajustes, como el administrador de claves de cifrado, la frase de contraseña del sistema y otras configuraciones de cifrado, se deben verificar y comparar manualmente para que la migración de datos se realice correctamente. Todos los certificados de administrador de claves existentes también se transfieren al sistema de destino. La configuración del administrador de claves de cifrado se debe volver a establecer en el sistema de destino después de la migración.

Pregunta: ¿Qué comprobaciones de compatibilidad de cifrado se realizan entre el origen y el destino durante la migración?
Respuesta: Frase de contraseña del sistema, detalles de configuración del administrador de claves y estado de cifrado, así como ajustes del modo FIPS del sistema son algunos de los ajustes de cifrado que deben ser idénticos en los sistemas de origen y destino para que la migración se realice correctamente. Este artículo de la base de conocimientos 183040, Data Domain: En Migration Procedure for Cloud Enabled DD Systems (se requiere iniciar sesión en el soporte de Dell para ver el artículo), se detallan los pasos para la migración entre sistemas con la nube habilitada. Los mismos ajustes también se aplican a la migración solo de nivel activo.

Pregunta: ¿Se admite la migración entre sistemas con la configuración Proyecto de deshabilitación del cifrado activada?
Respuesta: La migración de datos es compatible entre dos sistemas si ambos son EDP o no EDP. Se permite la migración de datos desde un sistema EDP a un sistema que no es EDP si el cifrado por cable está explícitamente desactivado. (mediante el MIGRATION_ENCRYPTION sysparam)

Cifrado en Cloud Tier 

Pregunta: ¿Es compatible el cifrado con el nivel de nube?
Respuesta: Sí, el cifrado es compatible con el nivel de nube. De manera predeterminada, el cifrado está deshabilitado en el nivel de nube. "cloud enable", se le solicita que elija si desea habilitar el cifrado en el nivel de nube.

Pregunta: ¿KMIP y los administradores de claves externos son compatibles con el nivel de nube?
Respuesta: Sí, KMIP y los administradores de claves externos son compatibles con el nivel de nube desde DDOS 7.8 en adelante.

Pregunta: ¿Con qué granularidad se puede habilitar el cifrado en la nube?
Respuesta: El cifrado se puede habilitar y deshabilitar en cada unidad de nube y en cada nivel de manera independiente.

Pregunta: ¿Las unidades de nube tienen claves independientes?
Respuesta: No, la administración de claves es común a los niveles activo y de nube en DD. Las claves se copian en la unidad/nivel/cp respectiva cuando el cifrado está habilitado. Si el cifrado está habilitado en la nube activa y no en la nube, las claves de nivel activo no se reflejan en la nube y viceversa. Esto también se aplica a las unidades de nube. (Por ejemplo: el CP1 tiene el cifrado habilitado y el CP2 no tiene el cifrado habilitado, por lo que las claves del CP1 no se reflejan en el CP2).   

Pregunta: ¿Se pueden eliminar las claves en la nube?
Respuesta: No, no se admite la eliminación de claves de la nube.

Pregunta: ¿Dónde se administran las claves de cifrado de datos para las unidades de nube?
Respuesta: Las claves están asociadas con un cp y cada unidad de nube es un cp diferente. Una copia de las claves de todos los cps se almacena en el cp activo.

Pregunta: ¿Cómo recuperamos las claves de nube durante la recuperación ante desastres? 
Respuesta: cpnameval se espejea en la nube como parte de la recuperación de CP; las claves de cifrado se recuperarán en cpnameval. Ahora, debemos ejecutar ddr_key_util herramienta para recuperar las claves.

Nota: La recuperación ante desastres requiere la intervención del servicio al cliente.

Pregunta: ¿Podemos realizar transferencias de datos cuando el cifrado está habilitado solo en el nivel de nube?
Respuesta: No, debemos habilitar el cifrado en los niveles activo y de nube para la transferencia de datos.

Pregunta: ¿Podemos habilitar el administrador de claves externo en el nivel de nube?
Respuesta: Sí, el administrador de claves externo se puede habilitar en el nivel de nube. Esta función se soporta a partir de la versión 7.8. Todas las operaciones, excepto destruir o eliminar claves, que son válidas para el nivel activo también son válidas para el nivel de nube en términos de administrador de claves externo. 

Cifrado y recolección de elementos no utilizados

Pregunta: ¿Qué función desempeña el proceso de limpieza global en el cifrado en reposo? ¿Existe un impacto en el rendimiento cuando se habilita el cifrado por primera vez?
Respuesta: Habilitar el cifrado de datos en reposo por primera vez tiene un impacto en el rendimiento de la limpieza global. Esto se debe a que los datos que deben leerse desde los contenedores existentes en el disco y escribirse en contenedores nuevos pueden requerir ser leídos, descifrados y descomprimidos antes de volver a comprimirse, cifrarse y escribirse nuevamente en el disco. Cuando el cifrado está habilitado en un DD que contiene una cantidad significativa de datos preexistentes y se ejecuta el comando "filesys encryption apply-changes", el ciclo de limpieza global subsiguiente intenta cifrar todos los datos existentes en el sistema. Esto significa que todos los datos deben leerse, descomprimirse, comprimirse, cifrarse y escribirse en el disco. Como resultado, el primer ciclo de limpieza global después de ejecutar "filesys encryption apply-changes" puede tardar más de lo normal. Los clientes deben asegurarse de tener suficiente espacio libre en su sistema DD para permitir que la limpieza finalice sin que el sistema DD se llene (de lo contrario, los respaldos fallarán).

Pregunta: ¿Existe un impacto en el rendimiento debido a los ciclos de limpieza de ingesta/restauración continuos?
Respuesta: Sí, hay un impacto en el rendimiento y este generalmente depende de la cantidad de datos que se ingieren o restauran entre los ciclos de limpieza.

Pregunta: ¿Cuánto tiempo se tarda en cifrar mis datos existentes?
Utilice este artículo de la base de conocimientos para calcular el tiempo, Data Domain: Cálculo del tiempo que tarda en aplicarse el cifrado en reposo.

Cifrado y reimplementación 

Pregunta: ¿Puede el cliente mover el disco a otro sistema Data Domain si falla un cabezal y acceder al disco cuando el cifrado está habilitado?
Respuesta: La clave de cifrado no está vinculada al cabezal del sistema Data Domain, por lo que puede mover los discos a otro cabezal del sistema Data Domain y se puede acceder a la clave desde allí. En un nuevo cabezal de sistema Data Domain, el sistema de archivos está bloqueado, por lo que debe ingresar la frase de contraseña con el comando "filesys encryption unlock". 

Pregunta: ¿Qué sucede si un cliente olvidó la frase de contraseña en el momento de la operación de reimplementación?
Respuesta: Durante ese tiempo, pueden conectar el cabezal antiguo y trabajar con el soporte para restablecer la frase de contraseña y, a continuación, volver a conectarse al nuevo cabezal y finalizar el procedimiento de intercambio. 

Rendimiento del cifrado

Pregunta: ¿Cuál es el impacto observado en el consumo de almacenamiento cuando se utiliza el cifrado?
Respuesta: Es insignificante con aproximadamente un 1 % de sobrecarga asociada con el almacenamiento de algunos parámetros de cifrado con los datos de usuario.

Pregunta: ¿Cuál es el impacto observado en el rendimiento (escrituras y lecturas) cuando se utiliza el cifrado de datos en reposo?
Respuesta: El impacto en el rendimiento de la ingesta cuando se utiliza el cifrado puede variar según el protocolo y la plataforma. En general, los siguientes porcentajes son degradaciones conservadoras del rendimiento en el rendimiento agregado:

Modo
CBC primero completo: ~10 % de degradación del rendimiento en escrituras
Incremental: ~5 % de degradación del rendimiento en ESCRITURAS
Restauraciones: 5 - 20 % de degradación del rendimiento en LECTURAS

Modo
GCM primero completo: Del 10 % al 20 % de degradación del rendimiento en escrituras
Incremental: De 5 a 10 % de degradación del rendimiento en las restauraciones de escritura
: 5: 20 % de degradación del rendimiento en LECTURAS

Estos números son específicos de la sobrecarga del cifrado de datos en reposo (el cifrado por cable se contabiliza por separado)
 

Prácticas recomendadas

Pregunta: ¿Cuáles son las prácticas recomendadas en relación con la política de rotación de claves?
Respuesta: La política de rotación de claves automatizada no está habilitada de manera predeterminada. El cliente lo habilitó. Se recomienda rotar las claves de cifrado con frecuencia. Cuando un sistema está configurado con un administrador de claves KMIP externo, se recomienda rotar las claves con frecuencia para manejar cualquier escenario de riesgo de claves en el futuro. Cuando KMIP está configurado con el nivel de nube, el intervalo de rotación de claves sugerido es de 1 semana y, cuando KMIP está configurado solo en el nivel activo, la política de rotación de claves sugerida es 1 mes. Sin embargo, según la tasa de ingesta, el cliente también puede aumentar o disminuir la frecuencia de rotación de claves. Si el administrador de claves integrado está configurado, se recomienda una política de rotación de claves de entre 1 y 3 meses. 

Pregunta: ¿Cuáles son las prácticas recomendadas con la clase de clave KMIP si un cliente utiliza el mismo servidor KMIP para muchos sistemas DD?
Respuesta: Se recomienda tener una clase de clave separada para cada sistema DD cuando se utiliza el mismo servidor KMIP. De esa manera, la rotación de claves realizada en un sistema DDOS no afecta el estado de la clave presente en otro sistema DDOS.

Para obtener más información, consulte el documento Dispositivos Dell EMC PowerProtect serie DD: Software de cifrado (delltechnologies.com)

Encriptación: Documentación técnica sobre los dispositivos PowerProtect de la serie DD: Software

de encriptaciónPuede encontrar otra documentación relacionada con DD Encryption (Guía del administrador, Guía de referencia de comandos y Guía de configuración de seguridad) en el artículo 126375, en los documentos principales de PowerProtect y Data Domain.

Guía de integración de KMIP y matriz

de compatibilidadVea este video: