Data Domain: Perguntas frequentes sobre criptografia

Resumo: Este artigo da base de conhecimento fornece um conjunto de perguntas frequentes (FAQ) sobre a criptografia de dados em repouso (DARE) do Data Domain em um local consolidado para facilitar a referência. ...

Produtos afetados

Este artigo aplica-se a Este artigo não se aplica a Este artigo não está vinculado a nenhum produto específico. Nem todas as versões do produto estão identificadas neste artigo.

Confira outros recursos

Instruções

Configuração de criptografia

Pergunta: Como a criptografia de dados em repouso (DARE) é configurada no Data Domain?

Resposta: O DARE pode ser configurado com as seguintes etapas:

Adicione uma licença de criptografia.
1. Tenha um arquivo de licença com uma licença válida de criptografia adicionado a ele.
2. Use o comando abaixo para atualizar a e-license no Data Domain usando o arquivo de licença disponível:
```
# elicense update
```
Adicione um agente de segurança e ative as autorizações do agente de segurança.
1. Adicione um usuário com a função de "segurança" (se ainda não existir) usando o comando:
```
# user add <username> role security
```
2. Ative a autorização do agente de segurança fazendo log-in como o agente de segurança e executando o comando:
```
> authorization policy set security-officer enabled
```
Volte para uma conta de administrador e ative o DARE executando o comando:
```
# filesys encryption enable
```

Pergunta: Quais plataformas são compatíveis com o DARE?

Resposta: O recurso DARE é compatível com todos os sistemas Data Domain, exceto para sistemas EDP (Encryption Disablement Project).

Pergunta: Como posso armazenar dados em texto não criptografado no Data Domain?

Resposta: Os usuários podem garantir que os dados sejam salvos em texto não criptografado no Data Domain confirmando se a criptografia está desativada na configuração.

A criptografia pode ser desativada no Data Domain usando o comando:

# filesys encryption disable

Pergunta: Quais protocolos e aplicativos de backup são compatíveis com o DARE?

Resposta: O recurso DARE é independente do aplicativo de backup subjacente ou do protocolo usado pelo Data Domain.

Pergunta: Quais algoritmos de criptografia podem ser usados?

Resposta: O software de criptografia do Data Domain oferece suporte a algoritmos 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 é exclusivo ORed (XOR) 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 o algoritmo de criptografia pode ser alterado?

Resposta: Use o comando abaixo para definir um algoritmo de criptografia específico:

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

Pergunta: Como posso garantir que a criptografia seja feita em dados preexistentes depois que a criptografia estiver ativada?

Resposta: Podemos forçar o file system do Data Domain 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 faço para desativar a criptografia?

Resposta: Desative o recurso de criptografia no Data Domain usando o seguinte comando:

# filesys encryption disable

Isso só desativa a criptografia dos dados recebidos. Os dados criptografados existentes permanecem criptografados até que sejam descriptografados manualmente usando o comando 'filesys encryption apply-changes'.

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

Resposta: Os seguintes comandos de criptografia exigem uma reinicialização do file system para entrar em vigor:

filesys encryption enable|disable - Ativa ou desativa a criptografia no Data Domain.
filesys encryption algorithm set - Permite que o usuário selecione um algoritmo criptográfico.
filesys encryption algorithm reset - Redefine o algoritmo de criptografia para AES 256 no modo CBC (o padrão).

Pergunta: Quais comandos de criptografia exigem a desativação do file system para defini-los ou usá-los?

Resposta: O file system do Data Domain deve ser desativado para definir ou usar os seguintes comandos de criptografia:

encryption passphrase change
encryption lock|unlock

Perguntas gerais sobre criptografia

Pergunta: O DARE é compatível com todos os sistemas Data Domain?

Resposta: A opção do software DARE é compatível com sistemas Data Domain que não fazem parte do projeto de desativação de criptografia (EDP). Esses sistemas que não permitem que a criptografia seja ativada, e são vendidos principalmente na região da Rússia.

Pergunta: Como a criptografia é realizada nos sistemas Data Domain?

Resposta: A criptografia é feita usando as bibliotecas OpenSSL e RSA BSafe. RSA BSafe é uma biblioteca de criptografia validada por FIPS 140-2.

Pergunta: Qual versão do BSafe o Data Domain usa?

Resposta: A partir do DDOS 7.10, as versões do BSafe em uso 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?

Resposta: A criptografia pode ser configurada usando a linha de comando, a interface Web ou APIs REST. O suporte à API REST foi adicionado na versão 8.0 do DDOS.

Pergunta: A criptografia seletiva de dados é possível? Como apenas um mtree ou arquivo?

Resposta: 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 no nível 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?

Resposta: Absolutamente não.

Pergunta: Qual versão do OpenSSL o Data Domain usa?

Resposta: A partir do DDOS 7.10, a versão do OpenSSL é "OpenSSL 1.0.2zd-fips."

Pergunta: Como o DARE protege contra o acesso aos dados de usuários e aplicativos?

Resposta:

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 Data Domain, mas todos os dados que residem fisicamente no 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.
A criptografia do Data Domain foi projetada de tal forma que, se um invasor contornar outros controles de segurança de rede e obter acesso a dados criptografados, os dados ficarão ilegíveis e inutilizáveis para essa pessoa sem as chaves criptográficas adequadas.

Pergunta: A criptografia acontece após a desduplicação?

Resposta: 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?

Resposta: Os dados são protegidos usando o recurso DARE. 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, de modo que os dados fiquem ainda mais protegidos.

Pergunta: Quais alertas são gerados com a criptografia?

Resposta: Os alertas são gerados nos seguintes casos:

Quando há chaves de criptografia comprometidas presentes
Quando a tabela de chaves de criptografia está cheia e não é possível adicionar mais chaves ao 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 senha do sistema é 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?

Resposta: As chaves de criptografia são armazenadas de forma persistente em uma partição de conjunto no DDOS.

Pergunta: Se alguém retirar um disco rígido de um Data Domain, poderá descriptografar dados dele?

Resposta: 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, elas não podem ser descriptografadas sem a senha do sistema. 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?

Resposta: As chaves podem ser exportadas para 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 foi usada com o comando keys export.

Pergunta: Como o file system pode ser bloqueado antes de mover o sistema para outro local?

Resposta: Veja abaixo o procedimento para bloquear o sistema:

Desative o file system:
```
# filesys disable
```

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

# filesys encryption lock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the current passphrase:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The filesystem is now locked.

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 Data Domain ficam inacessíveis.

Para desbloquear o sistema quando ele chegar a um local remoto, use o comando abaixo:

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

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

Pergunta: O '`storage sanitize`O comando ' tem alguma relação com a criptografia do sistema de arquivos?

Resposta: Não. A criptografia do file system e a limpeza do armazenamento são dois recursos independentes.

Pergunta: A criptografia over-the-wire é compatível com sistemas EDP?

Resposta: A criptografia DARE e over-the-wire não é compatível com sistemas EDP.

Frase secreta do sistema

Pergunta: O que é a frase secreta do sistema?

Resposta: O DDOS é capaz de proteger credenciais no sistema definindo uma frase secreta no nível do sistema. A frase secreta é uma chave legí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. Ele altera a criptografia da chave do sistema 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 fornecendo 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 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 autenticam com o Data Domain. Isso significa que nenhum administrador pode fazer alterações de forma independente.

Pergunta: Quando a frase secreta é usada?

Resposta: A senha do sistema é usada como chave primária por vários componentes do DDOS, inclusive criptografia do file system, acesso à nuvem, gerenciamento de certificados, tokens do DD Boost, módulos de configuração do sistema em ambientes de scale-out e informações de licenciamento. O DDOS fornece 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 Data Domain está sendo transportado.

Pergunta: Como a frase secreta é usada para o transporte seguro do Data Domain?

Resposta: O processo usa o 'filesys encryption lock' comando, que permite ao usuário bloquear o sistema de arquivos alterando a frase secreta. O usuário digita uma nova frase secreta que criptografa novamente a chave de criptografia, mas a nova frase secreta não é armazenada. As chaves de criptografia não são recuperáveis até que o sistema de arquivos seja desbloqueado usando o 'filesys encryption unlock' comando.

O processo é descrito nos Guias de configuração de segurança do Data Domain.

Pergunta: O que acontece se a frase secreta mudar? Os dados ainda podem ser acessados?

Resposta: Sim, alterar a frase secreta não altera a chave de criptografia subjacente do sistema Data Domain, apenas a criptografia da chave de criptografia. Dessa forma, o acesso aos dados não é afetado.

Pergunta: Como posso descobrir se uma frase secreta está definida no sistema?

Resposta: Se uma senha estiver definida no sistema, execute o 'system passphrase set' gera um erro indicando que a frase secreta já está definida.

Pergunta: O que acontece se a senha for perdida ou esquecida?

Resposta: 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 uma frase secreta perdida do sistema?

Resposta: A frase secreta do sistema só pode ser redefinida à força 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 podem ser encontrados neste artigo: Data Domain: Como redefinir uma frase secreta perdida do sistema no DDOS v7.2 ou posterior (requer login no Suporte Dell).

Pergunta: Há alguma opção para evitar o armazenamento da frase secreta do sistema no Data Domain?

Resposta: Por padrão, a frase secreta do sistema é armazenada em um local oculto no sistema Data Domain. O comando 'system passphrase option store-on-disk' pode ser usado para alterar isso e evitar o armazenamento da frase secreta no disco.

Gerenciador de chaves integrado (EKM)

Comando de nível superior:

# filesys encryption embedded-key-manager <option>

Pergunta: O rodízio de chaves é compatível com o EKM?

Resposta: 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?

Resposta: Essa funcionalidade não é cobrada. Ele está incluído como parte da opção de licença padrão do software Data Domain Encryption.

Pergunta: Posso mudar do gerenciamento de chaves local para externo?

Resposta: Sim, os gerenciadores de chaves externos podem ser ativados a qualquer momento. No entanto, as chaves locais que estão sendo usadas permanecem no Data Domain. Os gerenciadores externos de chaves não conseguem gerenciar as chaves locais. Os dados existentes não exigem nova criptografia. Se os dados de conformidade precisarem ser criptografados novamente com chaves EKM, isso deverá ser feito manualmente usando 'filesys encryption apply-changes' com o novo RW . A destruição de chaves EKM após um switch não é obrigatória.

A alteração dos gerenciadores de chaves alterna automaticamente a chave ativa para a chave do KMIP.

Exemplo da aparência da chave KMIP MUID 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?

Resposta: O rodízio de chaves é desativado por padrão. Nesse cenário, todos os dados são criptografados com a chave ativa existente. Se o rodízio de chaves estiver ativado, os dados serão criptografados com a chave ativa mais recente com base na frequência de rodízio configurada.

Gerenciadores externos de chaves

Pergunta: Quais gerenciadores de chaves externas são compatíveis com o Data Domain?

Resposta: O Data Domain é compatível com os 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?

Resposta: Sim, é necessária uma licença separada do respectivo fornecedor para integrar um gerenciador de chaves externo ao Data Domain.

Pergunta: Quantos gerenciadores-chave podem ser usados por vez?

Resposta: Apenas um gerenciador de chaves pode estar ativo a qualquer momento em um Data Domain.

Pergunta: Onde posso encontrar mais informações sobre como configurar os gerenciadores de chaves externas do KMIP?

Resposta: O Guia de integração do KMIP para DDOS contém informações detalhadas sobre como configurar os diferentes gerenciadores de chaves externos compatíveis com o Data Domain.

Pergunta: Como os certificados são gerenciados para gerenciadores de chaves externas no Data Domain?

Resposta: A configuração do gerenciador de chaves externas requer a geração de um certificado de CA (que pode ser autoassinado ou por terceiros) e um certificado de host. Depois que a configuração for feita no servidor gerenciador de chaves externo, o certificado CA e o certificado do host deverão ser importados para o sistema Data Domain. Em seguida, o gerenciador de chaves externo pode ser configurado e ativado.

Pergunta: O que é uma Autoridade de Certificação?

Resposta: 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 por uma CA? O que é um certificado assinado pela CA local?

Resposta: 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 do gerenciador de chaves. 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 em um Data Domain?

Resposta: Uma solicitação de assinatura de certificado (CSR) do Data Domain pode ser gerada usando o comando abaixo. Dessa forma, a chave privada nunca é exposta ao gerenciador de chaves externo.

# adminaccess certificate cert-signing-request

Pergunta: É possível alternar entre gerenciadores de chaves?

Resposta: A alternância do gerenciador de chaves externo para o gerenciador de chaves incorporado é permitida e é perfeita. No entanto, alternar do gerenciador de chaves incorporado para os gerenciadores de chaves externos requer instalação e configuração de certificado apropriadas. Alternar entre dois gerenciadores de chaves externos (por exemplo: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust para GKLM) também são permitidos. A migração de chaves também é compatível (consulte o Guia de integração do KMIP para obter mais detalhes).

Pergunta: O que acontece quando a conectividade do gerenciador de chaves externas fica inativa? Meus dados ainda estão acessíveis?

Resposta: Sim, os dados ainda estarão acessíveis quando não for possível conectar ao gerenciador de chaves, já que uma cópia das chaves também é armazenada no Data Domain. Novas chaves não podem ser criadas, e os estados das chaves não podem ser sincronizados quando não há conectividade com o gerenciador de chaves externo.

Pergunta: Há uma maneira de armazenar as chaves somente no gerenciador de chaves externo, e não no Data Domain?

Resposta: Uma cópia das chaves é sempre armazenada no sistema Data Domain para fins de Data Invulnerability Architecture (DIA). Esta configuração não pode ser alterada.

Pergunta: Há algum impacto sobre o desempenho da integração com o KMIP?

Resposta: 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?

Resposta: Sim, os clientes têm flexibilidade total para selecionar a metodologia de criptografia apropriada para seus Data Domains. Eles podem continuar aproveitando o gerenciador de chaves incorporado do Data Domain em alguns sistemas e o rodízio de chaves de criptografia usando KMIP em outros sistemas em seu ambiente.

Pergunta: A comunicação entre o Data Domain e o KMIP é segura?

Resposta: Sim, o Data Domain se comunica por meio de sessões autenticadas mutuamente pelo certificado X509 com o TLS. A CLI do Data Domain pode ser usada para importar o certificado X509 apropriado para o sistema Data Domain. Esse certificado é usado para estabelecer o canal seguro entre o Data Domain e o KMIP.

Gerenciamento do ciclo de vida principal

Pergunta: Quais recursos de gerenciamento de chaves existem com a criptografia do Data Domain?

Resposta: 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 um gerenciador de chaves externo compatível com 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. A partir do DD OS 7.1, isso não exige uma reinicialização do file system.

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

Os diferentes estados-chave no Data Domain são os seguintes:

Activated-RW: Há apenas uma chave nesse estado em um Data Domain a qualquer momento, e ela é usada para ler e gravar dados. Essa chave também é usada pelo processo de coleta de lixo para criptografar novamente os contêineres.
Pending-Activated: Há apenas uma chave nesse estado em um Data Domain em um dado momento. Isso identifica a chave que se tornará Activated-RW Após a próxima reinicialização do file system. Esse estado existe somente no momento da ativação da criptografia. Pending-activated As chaves não são criadas em nenhum outro momento.
Activated-RO: Os gerenciadores externos de chaves podem ter várias chaves ativadas. A chave mais recente está em Activated-RW, e o resto está neste estado. As chaves podem entrar nesse estado no Data Domain quando não é possível sincronizar o estado com o gerenciador de chaves.
Deactivated: Isso é usado para ler dados existentes no sistema Data Domain.
Compromised: Quando uma chave do gerenciador de chaves externas é comprometida, ela muda para esse estado após a próxima sincronização de chaves.
Marked-For-Destroyed: Quando um cliente marca uma chave para destruição, a chave muda para esse estado. Quando a coleta de lixo é executada, todos os contêineres são criptografados com Marked-For-Destroyed As chaves são criptografadas novamente usando o Activated-RW .
Destroyed: Uma chave na Marked-For-Destroyed O estado entrará nesse estado quando não houver nenhum dado associado a ele.
Destroyed-compromised: Uma chave na Compromised O estado entrará nesse estado quando não houver nenhum dado associado a ele.

Pergunta: As chaves de criptografia podem ser exportadas para recuperação de desastres?

Resposta: As chaves podem ser exportadas manualmente usando o comando abaixo.

# filesys encryption keys export

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

Os arquivos exportados estão presentes no /ddr/var/.security Diretório em um formato criptografado. Esse arquivo pode ser copiado do Data Domain e armazenado em um local seguro para uso posterior em qualquer condição de recuperação de desastres.

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 Data Domain?

Resposta: Sim, a chave de criptografia obtida do KMIP é armazenada de maneira criptografada no Data Domain.

Pergunta: Como uma alteração de estado de chave no equipamento KMIP é aplicada ao Data Domain?

Resposta: A sincronização de chaves acontece diariamente. Se houver uma nova chave disponível ou se o estado de uma chave for alterado, a sincronização atualizará a tabela de chaves local. O Data Domain recebe atualizações importantes do KMIP todos os dias à meia-noite.

Pergunta: É possível sincronizar manualmente os estados de chave entre o Data Domain e o KMIP?

Resposta: Sim, a CLI ou UI do Data Domain pode ser usada para sincronizar manualmente os estados de chave entre o Data Domain e o KMIP. O comando para isso é 'filesys encryption keys sync'.

Pergunta: É possível alterar a hora em que o Data Domain recebe atualizações importantes do KMIP?

Resposta: Não, não é possível alterar a hora em que o Data Domain recebe atualizações de chaves do KMIP.

Pergunta: Há um limite para o número de chaves armazenadas no Data Domain?

Resposta: A partir do DDOS 7.8, o sistema Data Domain pode ter no máximo 1.024 chaves no sistema. Há apenas uma chave no Activated-RW Estado; Todas as outras chaves podem estar em qualquer outro estado.

Pergunta: É possível usar chaves diferentes para conjuntos de dados diferentes no Data Domain?

Resposta: Não, o Data Domain só dá suporte a uma chave ativa no sistema por vez. 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 por mtree).

Pergunta: Há alguma notificação quando o limite máximo de chaves é atingido?

Resposta: Sim, um alerta é emitido quando o limite máximo de chaves de 1024 é atingido.

Pergunta: Como posso remover o alerta sobre o limite máximo de chaves?

Resposta: Uma das chaves deve ser excluída para limpar o alerta de limite máximo de chaves.

Pergunta: Posso ver a quantidade de dados associada a uma chave específica no Data Domain?

Resposta: Sim, isso pode ser visto no Data Domain, mas não pode ser visto no servidor KMIP. A CLI e a interface do usuário do Data Domain permitem que o usuário veja o volume de dados associados a uma chave específica. O comando para isso é 'filesys encryption keys show summary'.

Pergunta: Posso ver a idade das chaves no Data Domain?

Resposta: Sim, ele pode ser visto para chaves EKM usando a interface do usuário.

Pergunta: A chave antiga funciona mesmo que tenha decorrido o prazo para torná-la eficaz?

Resposta: Não há data de expiração para chaves de criptografia. As chaves antigas se tornam somente leitura após o rodízio de chaves e permanecem no DDOS.

Pergunta: As chaves de criptografia são excluídas automaticamente quando não há dados associados a elas no Data Domain?

Resposta: Não, a chave não é excluída automaticamente. O usuário deve excluir explicitamente a chave usando a interface do usuário ou da CLI do Data Domain.

Pergunta: Uma chave pode ser excluída mesmo que haja dados associados a ela no Data Domain?

Resposta: Não, se uma chave tiver quaisquer dados associados a ela, ela não poderá ser excluída. Os dados devem ser criptografados novamente com outra chave para excluir uma chave que tenha dados associados a eles.

Pergunta: Se uma chave for excluída do KMIP, ela também será excluída da lista de chaves do Data Domain?

Resposta: Não, o usuário deve excluir a chave independentemente usando a interface do usuário ou a CLI do Data Domain.

Pergunta: Em um ambiente Data Domain de vários locais, um KMIP é necessário em todos os locais?

Resposta: Não, não é necessário ter um KMIP em todos os locais com um Data Domain. Um servidor KMIP pode ser usado para todos eles. É recomendável ter uma classe de chave separada para cada sistema Data Domain quando eles estiverem usando o mesmo servidor KMIP.

Pergunta: Se uma chave for comprometida, há um processo para recuperar os dados criptografados com a chave antiga?

Resposta: Se isso ocorrer, o cliente deverá marcar a chave como comprometida no servidor KMIP. Em seguida, no Data Domain:

Executar 'filesys encryption keys sync'.
Executar 'filesys encryption apply-changes'.
Inicie uma limpeza do file system.
1. A limpeza criptografa novamente todos os dados que foram criptografados com a chave comprometida usando uma chave mais nova.
2. Quando a limpeza é feita, o estado da chave antiga é alterado para Compromised-Destroyed.
Exclua a chave antiga.

Criptografia e replicação

Pergunta: A replicação do Data Domain é compatível e interoperável com o DARE?

Resposta: Sim, a replicação do Data Domain pode ser usada com o DARE. Isso permite que os dados criptografados sejam replicados usando todos os diferentes tipos de replicação. Cada tipo 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 DDOS para usar a criptografia?

Resposta: A origem e o destino podem estar em diferentes versões do DDOS para usar o DARE com replicação se forem compatíveis para replicação (consulte o Guia de administração do Data Domain para obter a matriz de compatibilidade).

Pergunta: Como a replicação funciona com a criptografia?

Resposta: Depende de qual forma de replicação está sendo usada.

Se a replicação configurada for mtree replication (MREPL) ou Managed File Replication (MFR):

O DARE pode ser licenciado ou ativado na origem ou no destino independentemente, dependendo do que o cliente deseja obter.
Quando a origem e o destino tiverem a criptografia habilitada:
- Os dados incluídos na origem 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.
Quando a origem tiver criptografia desabilitada e o destino tiver criptografia habilitada:
- Os dados ingeridos na origem não são criptografados.
- 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:
- 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 de destino.
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 alterações sejam aplicadas e a limpeza seja executada no destino.

Se a replicação configurada for a replicação de conjunto (CREPL):

Ambos os sistemas de origem e destino devem estar executando a mesma versão do DDOS.
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 de destino em seu estado criptografado.
- O destino tem a mesma chave que a origem, já que a replicação de conjunto se trata de uma réplica exata do sistema de origem.
- Nenhum dado pode ser gravado no destino fora da replicação, já que o destino é um sistema somente leitura.
Quando a origem e o destino tiverem a criptografia desativada:
- Os dados incluídos no sistema de origem não são criptografados.
- Ao replicar, a origem envia os dados em um estado não criptografado e eles permanecem não criptografados no destino.
- Nenhum dado pode ser gravado no destino fora da replicação, já que o destino é um sistema somente leitura.

Pergunta: A chave de destino é armazenada indefinidamente no Data Domain de origem?

Resposta: 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, o mesmo conjunto de chaves de criptografia está presente na origem e no destino.

Pergunta: A criptografia pode ser habilitada em um sistema de replicação de conjunto depois que o contexto de replicação é estabelecido?

Resposta: Sim, nesse caso, a criptografia deve ser habilitada tanto na origem quanto no destino. O contexto de replicação deve ser desativado para configurar a criptografia. 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 DARE pode ser ativado simultaneamente com o recurso de criptografia over-the-wire para replicação do Data Domain?

Resposta: Sim, a criptografia over-the-wire (OTW) e a DARE podem ser ativadas simultaneamente para atingir diferentes objetivos de segurança.

Pergunta: O que acontece se a criptografia DARE e OTW estiver habilitada simultaneamente?

Resposta: A origem primeiro criptografa os dados usando a chave de criptografia de destino. Em seguida, os dados já criptografados são criptografados uma segunda vez por criptografia OTW ao enviar esses dados para seu destino. No destino, depois que a descriptografia OTW é feita, os dados sã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, eles devem ter a mesma frase secreta?

Resposta: Se a replicação configurada for a replicação de conjunto, a frase secreta deverá ser a mesma. Para outros tipos de replicação (como MREPL, MFR), os sistemas podem ter senhas diferentes.

Pergunta: Com a criptografia habilitada no destino, os dados replicados e os dados de algum outro ponto de acesso (como por meio de backup local) são criptografados? Existe uma maneira de separar os dois no destino para que apenas os diretórios replicados sejam criptografados?

Resposta: Não, todos os dados são criptografados no destino, independentemente do ponto inicial. A criptografia não pode ser habilitada ou desabilitada apenas em uma granularidade em nível de mtree ou de diretório. Isso não é aplicável ao CREPL.

Pergunta: Como é feita a troca de chaves entre a origem e o destino durante o MREPL ou MFR?

Resposta: Durante a fase de associação da replicação, o destino transmite com segurança seu algoritmo de criptografia atual e as 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 Data Domain.

Pergunta: Que tipo de algoritmo a criptografia OTW usa para criptografar o tráfego de replicação?

Resposta: Quando o modo de autenticação de replicação é definido como "unidirecional" ou "bidirecional", o DHE (Ephemeral Diffie-Hellman) é 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.

"Unidirecional" indica que somente o certificado de destino é certificado. "Bidirecional" indica que os certificados de origem e destino são verificados. A confiança mútua deve ser estabelecida antes que você possa usar esse 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 troca de chaves de sessão. Nesse caso, a origem e o destino não se autenticam antes da troca de chaves. "Anônimo" é usado por padrão se o modo de autenticação não for especificado.

Pergunta: O rodízio de chaves sem a reinicialização do file system funciona com todos os tipos de replicação?

Resposta: O rodízio de chaves sem uma reinicialização do file system funciona com todos os tipos de replicação, exceto a replicação de diretório (que não é mais compatível) e a replicação delta (também conhecida como otimização de pouca largura de banda ou LBO).

Pergunta: Como a chave de criptografia do destino é protegida durante a troca de chaves na ausência de certificados ou pares de chaves PKI?

Resposta: 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 Data Domains desejam estabelecer um contexto de replicação. Também é acordado através de uma troca Diffie-Hellman 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: Os dois sistemas em um par de replicação precisam usar 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?

Resposta: Além da 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. No entanto, apenas a origem está sincronizando 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 DARE habilitado?

Resposta: 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 do nível ativo e do nível da nuvem é compatível com o DARE habilitado?

Resposta: 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 verificada é aplicada com base em qual nível tem criptografia habilitada.

Pergunta: Quais configurações de criptografia são preservadas como parte da migração?

Resposta: Os dados criptografados e as chaves de criptografia são migrados como estão, mas configurações como o gerenciador de chaves, a frase secreta do sistema e outras configurações de criptografia devem ser verificadas manualmente e combinadas para que a migração de dados seja 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?

Resposta: A frase secreta do sistema, o status de criptografia, 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. Este artigo da KB (é necessário fazer login no Suporte Dell) detalha as etapas da 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 EDP?

Resposta: 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 OTW for explicitamente desativada usando o MIGRATION_ENCRYPTION parâmetro do sistema.

Criptografia e Cloud Tier

Pergunta: A criptografia é compatível com o nível da nuvem?

Resposta: Sim, a criptografia é compatível com o nível da nuvem. Ele é desabilitado por padrão. O 'cloud enableO comando ' solicita que você escolha se deseja ou não habilitar 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?

Resposta: 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?

Resposta: 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?

Resposta: Não, o gerenciamento de chaves é comum aos níveis ativos e de nuvem no Data Domain. As chaves são copiadas para a respectiva partição de unidade, nível ou conjunto 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: Se a solicitação do cp1 tem criptografia habilitada e cp2 não tem a criptografia ativada, então cp1 Teclas não refletem cp2.

Pergunta: As chaves podem ser excluídas da nuvem?

Resposta: 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?

Resposta: As chaves são associadas a um collection partition (CP), e cada unidade de nuvem é um CP diferente. Uma cópia das chaves de todos os CPs é armazenada na partição ativa.

Pergunta: Como recuperar chaves de nuvem durante a recuperação de desastres?

Resposta: A coluna cpnameval é espelhado na nuvem como parte da recuperação do CP, e as chaves de criptografia são recuperadas para cpnameval. Em seguida, o ddr_key_util é usada para recuperar as chaves.

Nota: A recuperação de desastres requer assistência do Suporte ao cliente.

Pergunta: A movimentação de dados pode ser executada quando a criptografia está habilitada apenas para o nível da nuvem?

Resposta: Não, a criptografia deve ser habilitada nos níveis ativo e de nuvem para que a movimentação de dados seja executada.

Pergunta: Um gerenciador de chaves externo pode ser usado com o nível da nuvem?

Resposta: Sim, o gerenciador de chaves externo pode ser usado com o nível da nuvem. Esse recurso é compatível com o DD OS 7.8 em diante. Todas as operações (exceto destruir ou excluir uma chave usada 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 é a função do processo de coleta de lixo (GC) no DARE? Há um impacto sobre o desempenho ao habilitar a criptografia pela primeira vez?

Resposta: Habilitar o DARE pela primeira vez tem um impacto no desempenho da GC. Quando a GC é executada, ele lê os dados dos contêineres existentes no disco e os grava em novos contêineres. Depois que o DARE é habilitado, esses dados podem exigir que sejam lidos, descriptografados e descompactados antes de serem recompactados, criptografados e gravados novamente no disco. Quando a criptografia está habilitada em um Data Domain que detém uma quantidade significativa de dados preexistentes, e o 'filesys encryption apply-changes' é executado, o próximo ciclo de GC 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 GC depois de executar 'filesys encryption apply-changes' pode demorar mais do que o normal. Certifique-se de que eles tenham espaço livre suficiente no sistema Data Domain para permitir que a limpeza seja executada até a conclusão sem que o sistema Data Domain fique cheio (caso contrário, os backups falharão).

Pergunta: Há algum impacto sobre o desempenho dos ciclos de limpeza contínuos?

Resposta: Sim, há um impacto sobre o desempenho. O impacto geralmente depende da quantidade de dados que está sendo ingerida e restaurada entre os ciclos de limpeza.

Pergunta: Quanto tempo leva para criptografar os 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: Se um Data Domain com DARE configurado passar por um headswap, os discos ainda poderão ser acessados com a nova unidade principal?

Resposta: A chave de criptografia não está vinculada ao cabeçalho do sistema Data Domain, portanto, os discos podem ser movidos para outro cabeçalho do Data Domain e a chave ainda pode ser acessada lá. O sistema de arquivos está bloqueado na nova cabeça e deve ser desbloqueado com o 'filesys encryption unlock' e a frase secreta do sistema.

Pergunta: E se a senha for perdida no momento da operação de headswap?

Resposta: Se a senha for perdida, conecte o cabeçote antigo e trabalhe com o suporte para redefini-la. Em seguida, conecte-a novamente ao novo cabeçote e conclua o procedimento de headswap.

Criptografia e desempenho

Pergunta: Qual é o impacto observado no consumo de armazenamento quando o DARE é usado?

Resposta: O impacto sobre o consumo de armazenamento é insignificante, com aproximadamente 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 o DARE é usado?

Resposta: 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

Primeira completa: ~10% de degradação no desempenho nas gravações
Incremental: ~5% de degradação do desempenho nas gravações
Restaura: 5 a 20% de degradação no desempenho em leituras

Modo GCM

Primeira completa: 10 a 20% de degradação no desempenho nas gravações
Incremental: 5 a 10% de degradação do desempenho nas gravações
Restaura: 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?

Resposta: A política de rodízio automatizado de chaves não é habilitada por padrão. É 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 é semanal; quando o KMIP é configurado apenas para o nível ativo, a política de rodízio de chaves sugerida é mensal. No entanto, isso pode ser aumentado ou diminuído com base na taxa de ingestão. Se o gerenciador de chaves incorporado estiver configurado, recomenda-se uma 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 o mesmo servidor KMIP for usado para muitos Data Domains?

Resposta: É recomendável ter uma classe de chave separada para cada Data Domain quando eles estiverem usando o mesmo servidor KMIP. Dessa forma, o rodízio de chaves feito em um sistema não afeta o estado da chave presente em outros sistemas.

Mais informações

Outras documentações relacionadas ao Data Domain Encryption (Guia do administrador, Guia de referência de comandos e Guia de configuração de segurança) podem ser encontradas aqui: Principais documentos do PowerProtect e do Data Domain

Assista a este vídeo: