Dell EMC Data Domain Encryption - Perguntas frequentes

Configuração de criptografia

Pergunta: Como a criptografia (DARE) é configurada no DD?
Responder: A criptografia DARE pode ser configurada no DD pelas seguintes etapas:

1. Adicionar licença de criptografia

2. Adicionar um agente de segurança e ativar as autorizações do agente de segurança

3. Ativar criptografia 

1) Adicionar licença de criptografia:
Tenha um arquivo de licença com uma licença de criptografia válida adicionado a ele.
Use o comando abaixo para atualizar o elicense no DD usando o arquivo de licença disponível.

Atualização do eLicense

2) Adicione um agente de segurança e ative as autorizações de SO:
a) Adicione um usuário com uma função de "segurança" usando o comando: 

Segurança da função de adição de secuser do usuário

b) Habilitar a Autorização do Agente de Segurança na configuração usando o comando: 

Conjunto de políticas de autorização Agente de segurança ativado

3. Ative a criptografia DARE:
Ative a criptografia DARE usando o comando:

Ativação da criptografia filesys

Pergunta: Quais plataformas são compatíveis com o recurso de criptografia de dados em repouso?
Responder: O recurso de criptografia de dados em repouso é compatível com todos os sistemas Data Domain, exceto em sistemas EDP (Encryption Disablement Project).

Pergunta: Como o usuário pode armazenar seus dados em texto não criptografado no DD?
Responder: O usuário pode garantir que os dados sejam salvos em texto não criptografado e não criptografados no DD, confirmando se a criptografia está desativada na configuração.
Os usuários podem desativar a criptografia no DD usando o comando: 

Desativação da criptografia filesys

Pergunta: Quais aplicativos/protocolos de backup são compatíveis com o recurso de criptografia de dados em repouso?
Responder: O recurso DARE do DD é independente do aplicativo de backup subjacente ou do protocolo usado pelo DD.

Question: Quais algoritmos de criptografia podem ser selecionados no sistema Data Domain?
Responder: O software DD Encryption é compatível com o algoritmo AES de 128 ou 256 bits usando o CBC (Cipher Block Chaining) ou o GCM (Galois Counter Mode). 

GCM é um modo de operação para cifras de bloco criptográfico de chave simétrica. É um algoritmo de criptografia autenticada projetado para fornecer autenticação e privacidade (confidencialidade). Como o nome sugere, o GCM combina o conhecido modo de contador de criptografia com o novo modo Galois de autenticação. O aspecto de autenticação do GCM garante que os dados que foram criptografados foram feitos pelo sistema Data Domain e não foram "injetados" por outros meios. Isso difere do CBC, onde os dados são criptografados (aspecto de privacidade), mas não há verificação da autenticidade dos dados criptografados.

No modo CBC, cada bloco de texto sem formatação é ORed exclusivo com o bloco de texto cifrado anterior antes de ser criptografado. Dessa forma, cada bloco de texto cifrado depende de todos os blocos de texto sem formatação processados até aquele ponto. Além disso, para tornar cada mensagem única, um vetor de inicialização deve ser usado no primeiro bloco. A CBC apenas garante a privacidade (confidencialidade) dos dados através de criptografia. Nenhuma autenticação do algoritmo ou processo de criptografia é feita.

Pergunta: Como podemos alterar o algoritmo de criptografia no DD?

Resposta: Use o comando abaixo se quiser definir um algoritmo de criptografia específico na configuração.

Conjunto de algoritmos de criptografia filesys

Exemplo:

# filesys algoritmo de criptografia definido {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Pergunta: Como garantimos que a criptografia seja feita em dados preexistentes depois que a criptografia é ativada?
Responder: Podemos forçar o DDFS a criptografar os dados preexistentes usando o comando abaixo:

# filesys encryption apply-changes

Isso torna o próximo ciclo de limpeza consideravelmente mais longo e mais intensivo em recursos do que o normal.

Pergunta: Como desabilitamos a criptografia no DD?
Responder: Desative o recurso de criptografia no DD usando o comando encryption disable: 

Desativação da criptografia filesys

Isso só desativa a criptografia para E/S de entrada. Os dados criptografados existentes permanecem criptografados até que sejam descriptografados manualmente usando apply-changes.

Pergunta: Quais comandos de criptografia exigem a reinicialização do file system do DD para entrar em vigor?
Responder: Os seguintes comandos de criptografia exigem uma reinicialização do file system do DD para entrar em vigor:

Ativar/desativar criptografia filesys - Ativa/desativa a criptografia no sistema Data Domain.

Conjunto de algoritmos de criptografia filesys - Permitir que o usuário selecione um algoritmo criptográfico.

Redefinição do algoritmo de criptografia filesys - Redefine o algoritmo de criptografia para AES 256 no modo CBC (o padrão).

Pergunta: Quais comandos de criptografia exigem que o file system do Data Domain seja desativado para defini-los/usá-los?
Responder: Os seguintes comandos de criptografia exigem que o file system do Data Domain seja desativado para defini-los ou usá-los:

Alteração da senha de criptografia

Bloqueio/desbloqueio de criptografia

Perguntas gerais sobre criptografia

Pergunta: O DD Encryption é compatível com todos os sistemas DD?
Responder: A opção de software DD Encryption é compatível com sistemas DD se não for um projeto de desativação de criptografia (EDP), que são os sistemas que não permitem que a criptografia seja habilitada, vendidos principalmente nos sistemas da região Rússia.

Pergunta: Como a criptografia é realizada em sistemas DD?
Responder: A criptografia é feita usando bibliotecas OpenSSL e RSA BSafe (RSA BSafe é biblioteca de criptografia validada FIPS 140-2 usada por sistemas DD para criptografar dados em repouso) no DDOS. 

Pergunta: Qual versão do BSafe é usada com o sistema?
Responder: A partir do DDOS 7.10, as versões usadas do BSafe são "BSAFE Micro Edition Suite 4.4.0.0" e "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Pergunta: Quais são as interfaces de usuário disponíveis para configurar a criptografia no DDOS?
Responder: A criptografia pode ser configurada usando CLI, IU ou usando APIs REST. API REST compatível adicionada no DDOS versão 8.0 e posterior.

Pergunta: A criptografia seletiva de dados é possível? Como apenas um MTree ou arquivo?
Responder: A criptografia seletiva NÃO é possível. A criptografia só pode ser ativada ou desativada em todo o sistema e não seletivamente. Para sistemas com suporte à nuvem, a criptografia pode ser ativada ou desativada no nível da nuvem e na granularidade da unidade de nuvem.  

Pergunta: Quaisquer chaves criptográficas ou senhas de conta são transmitidas ou armazenadas em texto não criptografado ou sob cifras fracas, como quando uma entidade se autentica, em arquivos de dados, em programas ou em diretórios de autenticação?
Responder: Absolutamente não.

Pergunta: Qual versão do OpenSSL é usada com o sistema?
Responder: A partir da versão 7.10 do DDOS, a versão do openssl é "OpenSSL 1.0.2zd-fips"

Pergunta: Como a criptografia de dados em repouso protege contra o acesso aos dados de usuários e aplicativos?
Responder: 

• A criptografia de dados em repouso se refere à criptografia dos dados que residem no subsistema de disco. A criptografia ou descriptografia acontece na camada de compactação. Usuários ou aplicativos enviam e recebem dados de texto não criptografado para o sistema Data Domain, mas todos os dados que residem fisicamente no sistema Data Domain são criptografados.
• Toda criptografia ocorre abaixo do file system e namespace e é invisível para os usuários ou aplicativos. Se um usuário ou aplicativo já tiver acesso autorizado a um arquivo ou diretório, os dados poderão ser lidos em seu formato nativo, independentemente da criptografia.
• O DD Encryption foi projetado de modo que, se um invasor contornar outros controles de segurança de rede e obter acesso a dados criptografados sem as chaves criptográficas adequadas, os dados ficarão ilegíveis e inutilizáveis para essa pessoa. 

Pergunta: A criptografia acontecerá após a desduplicação?
Responder: Sim, a criptografia acontece em dados desduplicados. Os dados são criptografados antes de serem armazenados no disco. 

Pergunta: Como o Data Domain garante a segurança dos dados?
Responder: Os dados são protegidos usando o recurso de criptografia de dados em repouso. Além disso, quando o dispositivo é removido (head-swap, file system lock), a frase secreta é removida do sistema. Essa frase secreta é usada para criptografar chaves de criptografia para que os dados fiquem ainda mais protegidos.

Pergunta: Quais alertas são gerados com a criptografia?
Responder: Os alertas são gerados nos seguintes casos:

• Quando há comprometimento as chaves de criptografia estão presentes
• Quando a tabela de chaves de criptografia está cheia e não é possível adicionar mais chaves no sistema
• Quando a exportação automática de chaves falha
• Quando o rodízio automatizado de chaves falha
• Quando a criptografia está desativada
• Quando a frase secreta do sistema foi alterada

Pergunta: Existe alguma certificação de segurança para o DDOS? 
Resposta: Os sistemas Data Domain atendem à conformidade com FIPS 140-2. 

Pergunta: Onde a chave de criptografia é armazenada?
Responder: As chaves de criptografia são armazenadas de maneira persistente em uma partição de coleta no sistema DDOS.

Pergunta: Se alguém retirar um disco rígido de um sistema Data Domain, você poderá descriptografar dados dele?
Responder: As chaves de criptografia são criptografadas usando a frase secreta do sistema, que é armazenada no cabeçalho do sistema. Embora as chaves de criptografia sejam armazenadas no disco, sem a frase secreta do sistema, as chaves de criptografia não podem ser descriptografadas. Portanto, sem saber a chave usada para criptografar os dados, a descriptografia não é possível a partir de um disco rígido.  

Pergunta: Quais chaves criptográficas e senhas são necessárias para recuperação, especialmente para recuperação de desastres?
Responder: As chaves podem ser exportadas em um arquivo seguro e mantidas externas ao sistema. A recuperação desse arquivo é feita com a ajuda da engenharia. Além disso, no momento da recuperação, o cliente deve saber a frase secreta que usou no momento do comando keys export.

Pergunta: Como bloquear o file system antes do trânsito do sistema para um local remoto.
Responder: Veja abaixo o procedimento para isso: 

• Desative o file system:

  sysadmin@itrdc-DD630-42# filesys desativar

• Bloqueie o file system e digite uma nova frase secreta (isso requer autenticação pelo usuário de segurança acima):

  Bloqueio
  de criptografia filesys sysadmin@itrdc-DD630-42# Esse comando requer autorização de um usuário que tenha uma função de "segurança".
  Please present credentials for such a user below.
          Nome de usuário: secuser
  Senha:
  Digite a senha atual:
  Digite uma nova frase secreta:
  Digite novamente a nova frase secreta:
  Frases secretas correspondidas.
  O file system agora está bloqueado.

• A nova frase secreta NÃO deve ser perdida ou esquecida. Sem essa senha, o file system não pode ser desbloqueado, o que significa que os dados no DDR não podem ser acessados. Para desbloquear o sistema quando ele chegar a um local remoto, use o comando abaixo:

sysadmin@itrdc-DD630-42# filesys encryption unlock
Esse comando requer autorização de um usuário que tenha uma função de "segurança".
Apresente abaixo as credenciais desse usuário.
        Nome de usuário: secuser
Senha:
Digite a frase secreta:
A frase secreta foi verificada. Use 'filesys enable' para iniciar o filesystem.

• Agora, o file system pode ser ativado e usado normalmente

Pergunta: O comando de limpeza de armazenamento tem alguma relação com a criptografia do sistema de arquivos?
Responder: Não. A criptografia do file system e a limpeza do armazenamento são dois recursos independentes. 

Pergunta: A criptografia over the wire é suportada no sistema EDP (projeto de desativação de criptografia)?
Responder: Não é possível ativar a criptografia de dados em repouso (DARE) ou a criptografia por fio (com replicação ou com ddboost) no sistema EDP.

Frase secreta do sistema 

Pergunta: O que é a frase secreta do sistema?
Responder: O DDOS tem a provisão para proteger credenciais no sistema definindo uma frase secreta no nível do sistema. A frase secreta é uma chave legível (compreensível), como um smart card, que é usada para gerar uma chave de criptografia AES 256 utilizável por máquina. 

Ele oferece dois benefícios:

• Ele permite que o administrador altere a frase secreta sem ter que manipular as chaves de criptografia. Alterar a frase secreta indiretamente altera a criptografia das chaves, mas não afeta os dados do usuário. Alterar a senha não altera a chave de criptografia subjacente do sistema Data Domain. Ela altera a criptografia da chave do sistema do Data Domain, mas a chave do sistema permanece a mesma.
• Ele permite que um sistema Data Domain físico seja enviado com uma chave de criptografia no sistema, mas sem que a frase secreta seja armazenada nele. Dessa forma, se a caixa for roubada em trânsito, um invasor não poderá recuperar facilmente os dados, pois o sistema só tem chaves criptografadas e dados criptografados.

A frase secreta é armazenada internamente em uma parte oculta do sistema de armazenamento do Data Domain. Isso permite que o sistema Data Domain inicialize e continue atendendo ao acesso aos dados sem intervenção do administrador.

Criando ou alterando a frase secreta:

• A frase secreta do sistema pode ser criada usando a CLI depois que um administrador se autentica com o sistema Data Domain.
• A frase secreta do sistema pode ser alterada usando a CLI depois que um administrador e um usuário com função de segurança (como um agente de segurança) se autenticarem no sistema Data Domain (de modo que nenhum administrador possa fazer alterações de modo independente).

Pergunta: Quando a frase secreta é usada?
Responder: A senha do sistema é usada como chave primária por vários componentes do DDOS, que incluem criptografia do file system, acesso à nuvem, gerenciamento de certificados, tokens Boost, módulos de configuração do sistema em ambientes de scale-out e informações de licenciamento. O software DDOS oferece mecanismos para definir e modificar essa frase secreta do sistema. Ele também fornece opções para controlar se a frase secreta do sistema é armazenada no disco, que é usado especialmente para segurança aprimorada quando o sistema DD está sendo transportado. 

Pergunta: Como a frase secreta é usada para o transporte seguro do sistema DD?
Responder: O processo usa o comando "filesys encryption lock", que permite que o usuário bloqueie o file system alterando a frase secreta. O usuário digita uma nova frase secreta que criptografa novamente a chave de criptografia, mas a nova senha não é armazenada. As chaves de criptografia não são recuperáveis até que o file system seja desbloqueado usando o comando "filesys encryption unlock".

O processo é descrito no Guia de configuração de segurança do Confluence Lab.

Pergunta: O que acontece se a frase secreta mudar? Os dados ainda podem ser acessados?
Responder: Sim, alterar a frase secreta não altera a chave de criptografia subjacente do sistema Data Domain, apenas a criptografia da chave de criptografia. Portanto, o acesso aos dados não é afetado.

Pergunta: Como podemos consultar se uma frase secreta está definida no sistema?
Responder: Se uma frase secreta estiver definida no sistema, a execução do comando "system passphrase set" gerará um erro indicando que a frase secreta já está definida.

Pergunta: O que acontece se a senha for perdida ou esquecida?
Responder: Se o cliente perder a senha enquanto a caixa estiver trancada, ele perderá seus dados. Não há back-door ou forma alternativa de ter acesso a ele. Sem um bom processo para gerenciar essa frase secreta, isso poderia acontecer acidentalmente e eles não seriam capazes de recuperar a chave ou os dados. No entanto, a chave criptografada nunca pode ser perdida ou corrompida devido aos mecanismos de proteção integrados do sistema.

Pergunta: Existe algum mecanismo para redefinir a frase secreta esquecida do sistema?
Responder: A frase secreta do sistema pode ser redefinida à força apenas em determinados cenários com a ajuda do atendimento ao cliente. O mecanismo de atualização forçada introduzido no DDOS 7.2 só poderá ser usado para isso se condições específicas forem atendidas. Mais detalhes estão no artigo da base de conhecimento 20983, Data Domain: Como redefinir uma frase secreta perdida do sistema no DDOS v7.2 ou posterior (é necessário fazer login no Suporte Dell para visualizar o artigo)

Pergunta: Há uma opção para evitar o armazenamento de frases secretas no sistema DD?
Responder: Por padrão, a frase secreta do sistema é armazenada em um local oculto no sistema Data Domain. A opção do sistema "system passphrase option store-on-disk" pode ser usada para alterar isso e evitar o armazenamento de frase secreta no disco.

Gerenciador de chaves integrado (EKM)

Comando de nível superior:

Opção System# Filesys Encryption Embedded-Key-Manager <>

Pergunta: Há suporte para rodízio de chaves com o Embedded Key Manager?
Responder:  Sim, o rodízio de chaves por sistema Data Domain é compatível com o Embedded Key Manager. Por meio da interface do usuário ou da CLI, o administrador pode configurar um período de rodízio de chaves (semanal ou mensal).

Pergunta: Há cobrança pela funcionalidade de gerenciamento de chaves incorporado?
Responder: Essa funcionalidade não é cobrada. Essa funcionalidade está incluída como parte da opção de licença padrão do software DD Encryption.

Pergunta: O cliente pode mudar do gerenciamento local de chaves para o gerenciamento externo de chaves (EKM)?
Responder

• Sim, os gerenciadores de chaves externos podem ser ativados a qualquer momento. No entanto, as chaves locais que estão sendo usadas permanecem no sistema Data Domain. Os gerenciadores externos de chaves não conseguem gerenciar as chaves do EKM. Os dados existentes não exigem nova criptografia. Se, para um cliente, os dados de conformidade precisarem ser criptografados novamente com chaves EKM, isso deverá ser feito manualmente usando apply-changes com a nova chave RW. A destruição de chaves EKM após um switch não é obrigatória.
  • A chave do gerenciador de chaves alterna automaticamente a chave ativa para a chave do KMIP. 
  • Exemplo da aparência do MUID da chave KMIP quando ocorre uma troca

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

Pergunta: O que acontece quando o rodízio de chaves é desativado ou ativado?
Responder: 

• O rodízio de chaves desabilitado será a funcionalidade de criptografia padrão se você não habilitar o rodízio de chaves na interface do usuário ou na CLI. Nesse cenário, todos os dados são criptografados com a chave ativa existente.
• Se o rodízio de chaves estiver ativado, com base na frequência de rodízio, giraremos as chaves e os dados serão criptografados com a chave ativa mais recente.

Gerenciadores externos de chaves

Pergunta: Quais são os gerenciadores de chaves externos compatíveis com o DD?
Responder: Estamos dando suporte aos gerenciadores de chaves externos abaixo:

• Gemalto KeySecure (suporte adicionado na versão 7.2 do DDOS)
• Vométrica (suporte adicionado na versão 7.3 do DDOS)
• CipherTrust (suporte adicionado na versão 7.7 do DDOS)
• IBM GKLM (suporte adicionado na versão 7.9 do DDOS)

Pergunta: É necessária uma licença separada para habilitar a integração com um gerenciador de chaves externo?
Responder: Sim, é necessária uma licença separada do respectivo fornecedor para integrar o Gerenciador externo de chaves ao DD.

Pergunta: Quantos gerentes-chave oferecem suporte por vez?
Responder: Apenas um gerenciador de chaves pode estar ativo em um determinado point-in-time em um sistema DD.

Pergunta: Onde posso encontrar mais informações sobre como configurar o KMIP External Key Manager?
Responder: O Guia de integração do KMIP para DDOS tem informações detalhadas sobre como configurar os diferentes gerenciadores de chaves externos compatíveis com o DD.

Pergunta: Como os certificados são gerenciados para os gerenciadores de chaves externas no DD?
Responder: Ao configurar o Gerenciador externo de chaves, precisamos gerar um certificado de CA (o certificado de CA pode ser um certificado autoassinado ou assinado por terceiros) e um certificado de host. Depois que a configuração for feita no servidor do gerenciador de chaves externas, os usuários precisarão importar o certificado da CA e o certificado do host no sistema DD. Em seguida, configuramos e ativamos o gerenciador de chaves externo. 

Pergunta: O que é CA?
Responder: Uma autoridade de certificação (CA) atua como a entidade compartilhada inicialmente confiável entre pares e emite certificados assinados para possibilitar que cada parte confie na outra. Um certificado geralmente atua como a identidade de um servidor ou client. 

Pergunta: O que é um certificado assinado pela CA local?
Responder: Um certificado assinado pela CA é um certificado emitido e assinado por uma autoridade de certificação (CA) publicamente confiável. Um certificado assinado pela CA é confiável automaticamente. Uma CA local pode emitir certificados assinados, uma vez que a chave de assinatura privada é armazenada dentro do sistema Key Manager. Uma CA externa não armazena a chave privada. Em vez disso, uma CA externa é usada como uma entidade confiável para várias interfaces e serviços dentro do sistema.

Pergunta: Como criar uma solicitação de assinatura de certificado no DD?
Responder: No sistema Data Domain, gere a CSR usando o comando da CLI abaixo. Dessa forma, a chave privada nunca é exposta ao gerenciador de chaves externo.

adminaccess certificado cert-signing-request

Pergunta: É possível alternar entre os Key Managers?
Responder: A alternância entre o Gerenciador de chaves externas e o Gerenciador de chaves integrado é permitida e perfeita. No entanto, alternar do Embedded Key Manager para o External Key Manager requer a instalação e a configuração adequadas do certificado. Alternar entre dois gerenciadores de chaves externas (por exemplo: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust para GKLM) também são permitidos. A migração de chaves do Key Manager também é compatível (consulte o guia de integração do KMIP para obter mais detalhes).

Pergunta: O que acontece quando a conectividade do Key Manager externo fica inativa? Meus dados estão acessíveis então?
Responder: Sim, os dados ainda estarão acessíveis quando não for possível conectar ao gerenciador de chaves, pois também armazenaremos uma cópia das chaves no sistema DD. Novas chaves não podem ser criadas ou os estados da chave não podem ser sincronizados quando não há conectividade com o gerenciador de chaves externo.

Pergunta: Existe uma maneira de evitar o armazenamento de chaves no DD e armazenar apenas no Gerenciador externo de chaves?
Responder: Sempre armazenamos uma cópia das chaves no sistema DD para fins de DIA. Esta configuração não pode ser alterada.

Pergunta: Há algum impacto sobre o desempenho devido à integração com o KMIP?
Responder: Não, não há impacto sobre o desempenho devido ao uso de gerenciadores de chaves externos.

Pergunta: É possível aproveitar a solução KMIP para domínios de dados selecionados no ambiente?
Responder: Sim, os clientes têm flexibilidade total para selecionar a metodologia de criptografia apropriada para seus sistemas Data Domain. Eles podem continuar aproveitando o gerenciador de chaves incorporado do Data Domain em alguns sistemas Data Domain e o rodízio de chaves de criptografia usando KMIP em outros sistemas Data Domain em seu ambiente.

Pergunta: A comunicação entre Data Domain e KMIP é segura?
Responder: Sim, o Data Domain se comunica por meio de sessões autenticadas mutuamente pelo certificado X509 com o TLS. O usuário pode usar a CLI do Data Domain para importar o certificado X509 apropriado para o sistema Data Domain. Esse certificado é usado para estabelecer o canal seguro entre o DD e o KMIP.

Gerenciamento do ciclo de vida principal 

Pergunta: Quais recursos de gerenciamento de chaves existem com a opção DD Encryption?
Responder: Um gerenciador de chaves controla a geração, a distribuição e o gerenciamento do ciclo de vida de várias chaves de criptografia. Um sistema de proteção pode usar o gerenciador de chaves incorporado ou o gerenciador de chaves externo com reclamação KMIP. Apenas um gerenciador de chaves pode estar em vigor por vez. Quando a criptografia está habilitada em um sistema de proteção, o Embedded Key Manager está em vigor por padrão. Se um gerenciador de chaves externo estiver configurado, ele substituirá o gerenciador de chaves incorporado e permanecerá em vigor até que seja desativado manualmente. Alternar do Embedded Key Manager para o External Key Manager ou vice-versa resulta na adição de uma nova chave ao sistema e não exige uma reinicialização do file system a partir da versão 7.1.

Pergunta: Quais são os diferentes estados-chave no sistema Data Domain?
Os diferentes estados-chave no sistema Data Domain são os seguintes:

• Ativo-RW: Há apenas uma chave nesse estado em qualquer sistema DD que é usada para ler e gravar dados. Essa chave também é usada pelo processo de GC para criptografar novamente os contêineres.
• Pendente-Ativado: Há apenas uma chave nesse estado em qualquer sistema DD. Isso identificou a chave que se tornará Activated-RW após a próxima reinicialização do file system. Hoje, esse estado existe somente no momento da ativação da criptografia. Nenhuma outra chave ativada por tempo pendente é criada.  
• Ativo-RO: Os gerenciadores externos de chaves podem ter várias chaves ativadas. A chave mais recente está em Activated-RW, o restante está nesse estado. As chaves podem entrar nesse estado no sistema DD quando não é possível sincronizar o estado com o gerenciador de chaves.
• Desativado: Isso é usado para ler dados existentes no sistema DD.
• Comprometida: Quando um cliente compromete uma chave do gerenciador de chaves externo, o estado será alterado para ela após a próxima sincronização de chave.  
• Marcado para Destruído: Quando um cliente marca uma chave para destruição, o estado da chave torna-se marcado para ser destruído. Quando a GC é executada, todos os contêineres criptografados com chaves marcadas para destruição são criptografados novamente usando a chave Activated-RW.
• Destruído: Uma chave no estado marcado para destruir entra nesse estado quando não há dados associados a ela.
• Destruído-comprometido: Uma chave no estado Comprometido entra nesse estado quando não há dados associados a ela.

Pergunta: As chaves de criptografia podem ser exportadas para recuperação de desastres?
Responder: As chaves podem ser exportadas manualmente usando o comando abaixo.

"filesys encryption keys export"

O sistema DD também exporta chaves por padrão quando uma nova chave é adicionada ou quando alguma chave é excluída do sistema.

Os arquivos exportados estão presentes em /ddr/var/.security e estão em um formato criptografado. Esse arquivo deve ser copiado do DDR e armazenado em um local seguro que possa ser usado em qualquer condição de recuperação de desastres posteriormente.

Nota: A importação de chaves para recuperação de desastres requer intervenção do Atendimento ao cliente, pois o processo de restauração depende do tipo de desastre encontrado. Podemos importar o arquivo de chave exportado usando o comando a seguir.

filesys encryption keys import <filename> 

Pergunta: A chave gerada pelo KMIP é armazenada no sistema Data Domain?
Responder: Sim, a chave de criptografia obtida do KMIP é armazenada de maneira criptografada no sistema Data Domain.

Pergunta: Como uma alteração de estado de chave no equipamento KMIP é aplicada ao sistema Data Domain?
Responder: A sincronização de chaves acontece diariamente. Se houver uma nova chave disponível ou o estado da chave for alterado, a sincronização atualizará a tabela de chaves local. O DD recebe atualizações importantes do KMIP todos os dias à meia-noite.

Pergunta: É possível sincronizar manualmente os estados de chave entre o DD e o KMIP?
Responder: Sim, a CLI ou UI do Data Domain podem ser usadas para sincronizar manualmente os estados de chave entre o DD e o KMIP. "filesys encryption keys sync" é o comando usado para isso.

Pergunta: É possível alterar a hora em que o DD recebe atualizações importantes do KMIP?
Responder: Não, não é possível alterar a hora em que o DD recebe atualizações importantes do KMIP.

Pergunta: Há um limite para o número de chaves compatíveis com o sistema Data Domain?
Responder: A partir do DD OS 7.8, a qualquer momento, o sistema Data Domain pode ter no máximo 1.024 chaves no sistema. Há apenas uma chave no Activated-RW e o restante das chaves pode estar em qualquer outro estado.

Pergunta: Chaves diferentes podem ser usadas para conjuntos de dados diferentes em sistemas Data Domain? Isso é configurável?
Responder: Não, oferecemos suporte a apenas uma chave ativa no sistema por vez, e todos os dados recebidos são criptografados usando a chave ativa atual. As chaves não podem ser controladas em uma granularidade mais fina, como as árvores M.

Pergunta: Há alguma notificação quando o limite máximo de chaves é atingido?
Responder: Sim, um alerta é emitido quando o limite máximo de chaves de 1024 é atingido.

Pergunta: Como posso limpar o alerta sobre o limite máximo de chaves?
Responder: Uma das chaves deve ser excluída para limpar o alerta de limite máximo de chaves.

Pergunta: Podemos ver a quantidade de dados associada a uma chave específica no sistema Data Domain?
Responder: Sim, isso pode ser visto no DD, mas não pode ser visto no servidor KMIP. O usuário pode usar a CLI e a interface do usuário do Data Domain para ver a quantidade de dados associados a uma chave específica.

Pergunta:  Podemos ver a idade das chaves no sistema DD?
Responder: Sim, ele pode ser visto ativado com chaves EKM usando a interface do usuário.

Pergunta: A chave antiga funciona mesmo que o período de tempo tenha decorrido para torná-la efetiva?
Responder: Não há data de validade para as chaves de criptografia. As chaves antigas se tornam chaves somente leitura após o rodízio de chaves e permanecem no DDOS.

Pergunta: A chave de criptografia é excluída automaticamente quando não há dados associados a ela no sistema Data Domain?
Responder: Não, a chave não é excluída automaticamente. O usuário deve excluir explicitamente a chave usando a CLI ou a interface do usuário do DD.

Pergunta: Uma chave pode ser excluída mesmo que haja dados associados a ela no sistema Data Domain?
Responder: Não, se uma chave tiver quaisquer dados associados a ela, ela não poderá ser excluída. É necessária uma nova criptografia dos dados com alguma outra chave para excluir uma chave que tenha dados associados a ela.

Pergunta: Se uma chave for excluída do KMIP, ela também será excluída da lista de chaves do Data Domain?
Responder: Não, o usuário precisa excluir a chave independentemente usando a CLI ou a interface do usuário do DD.

Pergunta: Em um ambiente Data Domain de vários locais, um KMIP é necessário em todos os locais?
Responder: Não, não é necessário ter um KMIP em todos os locais com um Data Domain. Podemos apontar para um servidor KMIP. É recomendável ter uma classe de chave separada para cada sistema DD quando eles estiverem usando o mesmo servidor KMIP.

Pergunta: Se uma chave for comprometida, temos um processo para recuperar os dados criptografados com a chave antiga?
Responder: Nesse caso, o cliente precisa marcar a chave como comprometida no servidor KMIP. Em seguida, execute "filesys encryption keys sync" no sistema DDOS e execute "filesys encryption apply-changes" e, em seguida, execute GC (filesys clean). A execução da GC criptografa novamente todos os dados que foram criptografados com a chave comprometida usando uma chave mais nova. Quando a GC é concluída, o estado da chave é alterado para comprometido-destruído. Mais tarde, eles podem excluir essa chave. 

Criptografia e replicação

Pergunta: A replicação do DD é compatível e interoperável com a opção de software DD Encryption?
Responder: Sim, a replicação do DD pode ser usada com a opção DD Encryption, permitindo que os dados criptografados sejam replicados usando todos os tipos diferentes de replicação. Cada forma de replicação funciona exclusivamente com criptografia e oferece o mesmo nível de segurança.

Pergunta: Os sistemas de origem e destino precisam estar executando a mesma versão do DD OS para usar criptografia?
Responder: A origem e o destino podem estar em versões diferentes do DDOS para usar o DARE com replicação se a matriz de compatibilidade de replicação (consulte o guia do administrador para obter a matriz de compatibilidade) estiver em vigor. 

Pergunta: Como a replicação funciona com a criptografia?
Responder: Depende de qual forma de replicação está sendo usada.

Se a replicação configurada for MREPL ou MFR:
Se o MREPL ou MFR for usado, o DD Encryption poderá ser licenciado ou habilitado na origem ou no destino independentemente, dependendo do que o cliente deseja alcançar.

• Quando a origem e o destino tiverem a criptografia habilitada: Quando os dados são incluídos no sistema de origem, eles são criptografados com a chave de criptografia do sistema de origem. A origem descriptografa os dados locais, criptografa-os novamente usando a chave de criptografia do sistema de destino e, em seguida, replica os dados criptografados para o destino ao replicar.
• Quando a origem tiver criptografia desabilitada e o destino tiver criptografia habilitada: Todos os dados incluídos na origem não são criptografados (por motivo óbvio). Mas, ao replicar, a origem criptografa os dados usando a chave de criptografia do sistema de destino e, em seguida, replica os dados criptografados para o sistema de destino. 
• Quando a origem tiver criptografia habilitada e o destino tiver criptografia desabilitada: Todos os dados incluídos no sistema de origem são criptografados com a chave de criptografia do sistema de origem. A origem descriptografa os dados e, em seguida, replica os dados não criptografados para o sistema Data Domain de destino durante a replicação.
• Se a criptografia estiver habilitada na réplica depois que o contexto de replicação for configurado, todos os novos segmentos que estão sendo replicados serão criptografados na origem da réplica. Todos os segmentos que residem na réplica antes da criptografia ser habilitada são deixados em um estado não criptografado, a menos que a criptografia aplique alterações e a GC seja executada no destino. 

Se a replicação configurada for CREPL:
Com a replicação de conjunto, os sistemas de origem e destino devem estar executando a mesma versão do DDOS. Portanto, a criptografia deve ser habilitada ou desabilitada em ambos. Também não pode haver uma disparidade na configuração de criptografia. As chaves de criptografia são as mesmas na origem e no destino. 

• Quando a origem e o destino tiverem a criptografia habilitada: Todos os dados incluídos no sistema de origem são criptografados usando a chave de criptografia do sistema de origem. Ao replicar, a origem envia dados criptografados para o sistema Data Domain de destino em seu estado criptografado. O sistema Data Domain de destino tem a mesma chave que a origem, pois a replicação de conjunto se trata de uma réplica exata do sistema Data Domain de origem. Nenhum dado pode ser gravado no sistema Data Domain de destino fora da replicação, pois o destino é um sistema somente leitura.
• Quando a origem e o destino tiverem a criptografia desativada: Todos os dados incluídos no sistema de origem não são criptografados (por motivo óbvio). Durante a replicação, a origem envia (replica) os dados em um estado não criptografado e eles permanecem não criptografados no sistema Data Domain de destino. Nenhum dado pode ser gravado no sistema Data Domain de destino fora da replicação, pois o destino é um sistema somente leitura.

Pergunta: A chave de destino é armazenada indefinidamente no sistema Data Domain de origem?
Responder: A chave de criptografia do destino nunca é armazenada no sistema Data Domain de origem. Ele só é mantido na memória (criptografado) enquanto a sessão de replicação está ativa. Isso se aplica a todos os tipos de replicação, exceto replicação de conjunto. Na replicação de conjunto (CREPL), o mesmo conjunto de chaves de criptografia está presente na origem e no destino.  

Pergunta: A criptografia pode ser habilitada no sistema CREPL depois que o contexto de replicação é estabelecido?
Responder: Sim, nesse caso, a criptografia deve ser habilitada tanto na origem quanto no destino. A criptografia pode ser habilitada na origem e no destino desabilitando o contexto de replicação. Todos os novos segmentos replicados são criptografados na réplica. Todos os segmentos que residem na réplica antes da criptografia ser habilitada são deixados em um estado não criptografado.

Pergunta: O DD Encryption pode ser ativado simultaneamente com o recurso de criptografia over-the-wire na opção do software DD Replication?
Responder: Sim, tanto a criptografia por fio quanto o D@RE podem ser ativados simultaneamente para atingir diferentes objetivos de segurança.

Pergunta: O que acontecerá se a opção do software DD Encryption e o recurso de criptografia over-the-wire da opção do software DD Replication forem ativados simultaneamente?
Responder: A primeira origem criptografa os dados usando a chave de criptografia de destino. Em seguida, os dados já criptografados são criptografados uma segunda vez por causa da criptografia over the wire ao enviar esses dados para seu destino. No destino, depois que a descriptografia por fio for concluída, os dados serão armazenados em um formato criptografado que foi criptografado usando a chave de criptografia do destino.

Pergunta: Quando a criptografia está habilitada na origem e no destino, a frase secreta deve ser a mesma em ambos?
Responder: Se a replicação configurada for a replicação de conjunto (CREPL), a frase secreta deverá ser a mesma. Para outros tipos de replicação (como MREPL, MFR), a frase secreta pode ser diferente na origem e no destino.

Pergunta: Com a criptografia habilitada no destino (pergunta não aplicável ao CREPL), os dados replicados e os dados de algum outro ponto de acesso (por exemplo, por meio de backup local) são criptografados? Existe uma maneira de separar os dois na réplica em que apenas os diretórios replicados são criptografados enquanto outro acesso não é criptografado?
Responder: Não, todos os dados são criptografados na réplica (destino), independentemente do ponto inicial. A criptografia não pode ser habilitada ou desabilitada apenas em uma granularidade em nível de MTree ou diretório. 

Pergunta: Como é feita a troca de chaves entre a origem e o destino durante o MREPL ou MFR?
Responder: Durante a fase de associação da replicação, a máquina de destino transmite com segurança seu algoritmo de criptografia atual e informações de chave para a origem. Os contextos de replicação são sempre autenticados com um segredo compartilhado. Esse segredo compartilhado é usado para estabelecer uma chave de "sessão" usando um protocolo de troca de chaves Diffie-Hellman. Essa chave de sessão é usada para criptografar e descriptografar a chave de criptografia do sistema Data Domain.

Pergunta: Que tipo de algoritmo de criptografia é usado para o recurso "encryption over the wire" do Data Domain em relação à criptografia do tráfego de replicação?
Responder: Quando o modo de autenticação de replicação é definido como "unidirecional" ou "bidirecional", o DHE (Diffie-Hellman efêmero) é usado para troca de chaves de sessão. A autenticação do servidor acontece usando RSA. A codificação GCM AES de 256 bits é usada para encapsular os dados replicados pela conexão. A camada de encapsulamento de criptografia é removida imediatamente quando chega ao sistema de destino. 

Uma via indica que somente o certificado de destino é certificado. Duas maneiras indicam que os certificados de origem e destino são verificados. A confiança mútua deve ser estabelecida antes que você possa usar o modo de autenticação, e ambos os lados da conexão devem habilitar esse recurso para que a criptografia prossiga.

Quando o modo de autenticação de replicação é definido como "anônimo", o Diffie-Hellman (ADH) anônimo é usado para a troca de chaves de sessão, mas, nesse caso, a origem e o destino não se autenticam antes da troca de chaves. Além disso, se o modo de autenticação não for especificado, o anônimo será usado como padrão.

Pergunta: O rodízio de chaves sem a reinicialização do file system funciona com todos os tipos de replicação?
Responder: O rodízio de chaves sem reinicialização do file system funciona com todos os tipos de replicação, exceto DREPL (suporte a DREPL já encerrado) e replicação delta (que também é conhecida como LBO)

Pergunta: Na ausência de certificados ou pares de chaves PKI, como a chave de criptografia do destino é protegida durante a troca de chaves?
Responder: Há um segredo compartilhado entre todos os pares de replicação do Data Domain que é usado para estabelecer uma chave de sessão compartilhada usando uma troca de chaves Diffie-Hellman. Essa chave compartilhada é usada para criptografar a chave de criptografia do destino.

Há uma diferença entre o segredo compartilhado usado para autenticação de replicação e a chave de sessão compartilhada, que é alocada usando o protocolo de troca de chaves Diffie-Hellman. O segredo compartilhado usado para autenticação de replicação é estabelecido pelo software Data Domain na primeira vez que dois sistemas Data Domain desejam estabelecer um contexto de replicação. Também é acordado através de um Diffie-Hellman trocado usando parâmetros embutidos no código. Isso é armazenado de forma persistente nos sistemas para autenticar cada sessão de replicação entre os dois sistemas. A chave da sessão de replicação (a chave usada para criptografar a chave de criptografia do destino) é estabelecida usando outra troca Diffie-Hellman com o segredo compartilhado estabelecido anteriormente, conduzindo assim o protocolo de troca segura de chaves. Essa chave não é persistente e só existe enquanto o contexto de replicação está ativo.

Pergunta: É necessário que ambos os Data Domains de um par de replicação usem a mesma solução de gerenciador de chaves externo (como gerenciador de chaves KMIP) ou um dos sistemas pode usar o gerenciador de chaves externo e o outro pode usar o gerenciador de chaves incorporado?
Responder: Além de um par de replicação de conjunto, não é necessário que ambos os sistemas em um par de replicação usem o mesmo gerenciador de chaves.

Com a replicação de conjunto, ambos os sistemas Data Domain devem ser configurados com o mesmo gerenciador de chaves. Mas, nesse caso, a única origem é a sincronização de chaves com o gerenciador de chaves e essas chaves também são enviadas para o destino. Com outros tipos de replicação, diferentes gerenciadores de chaves podem ser usados com a origem e o destino.

Criptografia e migração

Pergunta: A migração de dados é compatível com sistemas com criptografia habilitada?
Responder: Sim, a migração de dados é compatível com sistemas com criptografia ativada. A configuração de criptografia nos sistemas de origem e destino deve ser correspondida como pré-requisito antes que a migração de dados seja iniciada. Também é recomendável exportar e fazer backup de chaves de criptografia no sistema de origem para fins de DIA antes que a migração seja iniciada.

Pergunta: A migração de dados é compatível com a migração de nível ativo e de nível da nuvem para sistemas habilitados para criptografia?
Responder: Sim, a migração de dados é compatível com a migração de nível ativo e nível de nuvem para sistemas habilitados para criptografia. A lista de atributos de pré-requisito verificados é aplicada com base em qual nível tem a criptografia habilitada.

Pergunta: Quais configurações de criptografia são preservadas como parte da migração?
Responder: Os dados criptografados e as chaves de criptografia são migrados como estão, mas configurações como gerenciador de chaves de criptografia, frase secreta do sistema e outras configurações de criptografia devem ser verificadas e combinadas manualmente para uma migração de dados bem-sucedida. Todos os certificados existentes do gerenciador de chaves também são transferidos para o sistema de destino. A configuração do gerenciador de chaves de criptografia deve ser redefinida no sistema de destino após a migração.

Pergunta: Quais verificações de compatibilidade de criptografia são feitas entre a origem e o destino durante a migração?
Responder: A frase secreta do sistema, o status de criptografia e os detalhes de configuração do gerenciador de chaves e as configurações do modo FIPS do sistema são algumas das configurações de criptografia que devem ser idênticas nos sistemas de origem e destino para que a migração seja bem-sucedida. Artigo 183040 da Base de Conhecimento, Data Domain: O Procedimento de migração para sistemas DD habilitados para a nuvem (é necessário fazer login no Suporte Dell para visualizar o artigo) detalha as etapas de migração entre sistemas com a nuvem habilitada. As mesmas configurações também se aplicam à migração de nível ativo.

Pergunta: Há suporte para migração entre sistemas com a configuração Encryption Disablement Project ativada?
Responder: A migração de dados é compatível entre dois sistemas se ambos forem EDP ou se ambos não forem EDP. A migração de dados é permitida de um sistema EDP para um sistema não EDP se a criptografia on-the-wire estiver explicitamente desativada. (usando o MIGRATION_ENCRYPTION sysparam)

Criptografia no Cloud Tier 

Pergunta: A criptografia é compatível com o nível da nuvem?
Responder: Sim, a criptografia é compatível com o nível da nuvem. Por padrão, a criptografia é desativada no nível da nuvem. O comando "Cloud Enable" solicita que você escolha se deseja ativar ou não a criptografia no nível da nuvem.

Pergunta: O KMIP e os gerenciadores externos de chaves são compatíveis com o nível da nuvem?
Responder: Sim, o KMIP e os gerenciadores externos de chaves são compatíveis com o nível da nuvem a partir do DDOS 7.8.

Pergunta: Em que granularidade a criptografia pode ser habilitada na nuvem?
Responder: A criptografia pode ser ativada e desativada em cada unidade de nuvem e em cada nível independentemente.

Pergunta: As unidades de nuvem têm chaves independentes?
Responder: Não, o gerenciamento de chaves é comum aos níveis ativos e de nuvem no DD. As chaves são copiadas para a respectiva unidade/nível/cp quando a criptografia está ativada. Se a criptografia estiver ativada na nuvem ativa e não na nuvem, as chaves do nível ativo não serão refletidas na nuvem e vice-versa. Isso também se aplica às unidades de nuvem. (Por exemplo: o CP1 tem a criptografia ativada e o CP2 não tem criptografia ativada, então as chaves CP1 não refletem no CP2.)   

Pergunta: As chaves podem ser excluídas na nuvem?
Responder: Não, a exclusão de chaves da nuvem não é compatível.

Pergunta: Onde as chaves de criptografia de dados são gerenciadas para unidades de nuvem?
Responder: As chaves estão associadas a um cp e cada unidade de nuvem é um cp diferente. Uma cópia das chaves de todos os cps é armazenada no cp ativo.

Pergunta: Como recuperar chaves de nuvem durante a recuperação de desastres? 
Resposta: O cpnameval é espelhado na nuvem como parte da recuperação do CP. As chaves de criptografia serão recuperadas no cpnameval. Agora, devemos executar ddr_key_util ferramenta para recuperar as chaves.

Nota: A recuperação de desastres exige intervenção do atendimento ao cliente.

Pergunta: Podemos fazer a movimentação de dados quando a criptografia está habilitada apenas no nível da nuvem?
Responder: Não, devemos habilitar a criptografia nos níveis ativo e de nuvem para a movimentação de dados.

Pergunta: Podemos ativar o gerenciador externo de chaves no nível da nuvem?
Responder: Sim, o gerenciador de chaves externo pode ser ativado no nível da nuvem. Esse recurso é compatível com a versão 7.8 ou posterior. Todas as operações, exceto destruir ou excluir chaves válidas para o nível ativo, também são válidas para o nível da nuvem em termos de gerenciador de chaves externo. 

Criptografia e coleta de lixo

Pergunta: Qual função o processo de limpeza global desempenha na criptografia em repouso; e há um impacto no desempenho ao habilitar a criptografia pela primeira vez?
Responder: Habilitar a criptografia de dados em repouso pela primeira vez tem um impacto no desempenho da limpeza global. Isso ocorre porque os dados que devem ser lidos dos contêineres existentes no disco e gravados em novos contêineres podem exigir que sejam lidos, descriptografados e descompactados antes de serem recompactados, criptografados e gravados novamente no disco. Quando a criptografia é ativada em um DD que mantém uma quantidade significativa de dados preexistentes e o comando "filesys encryption apply-changes" é executado, o ciclo de limpeza global subsequente tenta criptografar todos os dados existentes no sistema. Isso significa que todos os dados devem ser lidos, descompactados, compactados, criptografados e gravados no disco. Como resultado, o primeiro ciclo de limpeza global após executar "filesys encryption apply-changes" pode levar mais tempo do que o normal. Os clientes devem garantir que tenham espaço livre suficiente no sistema DD para permitir que a limpeza seja concluída sem que o sistema DD fique cheio (caso contrário, os backups falharão).

Pergunta: Há algum impacto sobre o desempenho dos ciclos contínuos de ingestão/restauração?
Responder: Sim, há impacto sobre o desempenho, e o impacto geralmente depende do volume de dados que está sendo ingerido/restaurado entre os ciclos de limpeza.

Pergunta: Quanto tempo leva para criptografar meus dados existentes?
Use este artigo da KB para estimar o tempo, Data Domain: Como calcular quanto tempo a criptografia em repouso leva para ser aplicada.

Criptografia e headswap 

Pergunta: O cliente pode mover o disco para outro sistema Data Domain se um cabeçote falhar e acessar o disco quando a criptografia estiver ativada?
Responder: A chave de criptografia não está vinculada ao cabeçalho do sistema Data Domain, portanto, você pode mover os discos para outro cabeçalho do sistema Data Domain e a chave fica acessível lá. Em um novo cabeçalho do sistema Data Domain, o file system está bloqueado, portanto, você precisa digitar a frase secreta com o comando "filesys encryption unlock". 

Pergunta: E se um cliente esquecer a frase secreta no momento da operação de headswap?
Responder: Durante esse tempo, eles podem conectar o cabeçote antigo e trabalhar com o suporte para redefinir a frase secreta e, em seguida, conectar-se novamente ao novo cabeçote e concluir o procedimento de headswap. 

Desempenho da criptografia

Pergunta: Qual é o impacto observado no consumo de armazenamento quando a criptografia é usada?
Responder: É insignificante, com cerca de 1% de sobrecarga associada ao armazenamento de alguns parâmetros de criptografia com dados do usuário.

Pergunta: Qual é o impacto observado no throughput (gravações e leituras) quando a criptografia de dados em repouso é usada?
Responder: O impacto sobre o throughput de ingestão quando a criptografia é usada pode variar de acordo com o protocolo e a plataforma. Em geral, as seguintes porcentagens são degradações conservadoras de desempenho no throughput agregado:

Modo CBC
Primeiro cheio: ~10% de degradação do desempenho em GRAVAÇÕES
Incremental: ~5% de degradação do desempenho em restaurações de gravações
: 5 a 20% de degradação do desempenho em leituras

Modo GCM Primeiro
completo: 10 a 20% de degradação do desempenho em gravações
Incremental: 5 -10% de degradação do desempenho em restaurações de
gravações: 5 a 20% de degradação no desempenho em leituras

Esses números são específicos para a sobrecarga da criptografia de dados em repouso (a criptografia por fio é contabilizada separadamente)
 

Práticas recomendadas

Pergunta: Quais são as práticas recomendadas relativas à política de rodízio de chaves?
Responder: A política de rodízio automatizado de chaves não é habilitada por padrão. O cliente o habilitou. É recomendável girar chaves de criptografia com frequência. Quando um sistema é configurado com um gerenciador de chaves KMIP externo, é aconselhável girar as chaves com frequência para lidar com quaisquer cenários de comprometimento de chave no futuro. Quando o KMIP é configurado com o nível da nuvem, o intervalo sugerido de rodízio de chaves é de 1 semana e, quando o KMIP é configurado apenas no nível ativo, a política sugerida de rodízio de chaves é de 1 mês. No entanto, com base na taxa de ingestão, o cliente pode aumentar ou diminuir a frequência de rotação de chaves também. Se o gerenciador de chaves incorporado estiver configurado, recomenda-se a política de rodízio de chaves entre 1 e 3 meses. 

Pergunta: Quais são as práticas recomendadas com a classe de chave KMIP se um cliente estiver usando o mesmo servidor KMIP para muitos sistemas DD?
Responder: É recomendável ter uma classe de chave separada para cada sistema DD quando eles estiverem usando o mesmo servidor KMIP. Dessa forma, o rodízio de chaves feito em um sistema DDOS não afeta o estado da chave presente em outro sistema DDOS.

Para obter mais informações, consulte o documento Equipamentos da série DELL EMC PowerProtect DD: Software de criptografia (delltechnologies.com)

Encriptação: White paper técnico Equipamentos PowerProtect série DD: Software

de criptografiaOutras documentações relacionadas ao DD Encryption (Guia do administrador, Guia de referência de comandos e Guia de configuração de segurança) podem ser encontradas no artigo 126375, Principais documentos do PowerProtect e do Data Domain.

Guia de integração do KMIP e matriz de

compatibilidadeAssista a este vídeo: