Instruções da plataforma de dados CISCO HyperFlex HX

Conteúdo esconder

1 Plataforma de dados CISCO HyperFlex HX

2 Informações do produto

3 Instruções de uso do produto

4 Perguntas frequentes sobre criptografia de segurança HX

5 Documentos de suporte

6 Documentos / Recursos

6.1 Referências

7 Postagens relacionadas

Plataforma de dados CISCO HyperFlex HX

Informações do produto

Nome do produto: Criptografia de segurança HX
Versão: HXDP5.01b
Solução de criptografia: Solução baseada em software usando Intersight Key Manager
Tipo de encriptação: Unidades com criptografia automática (SEDs)
Tipos de unidades suportadas: SEDs HDD e SSD da Micron
Padrões de Conformidade: FIPS 140-2 nível 2 (fabricantes de unidades) e FIPS 140-2 nível 1 (plataforma)

Criptografia em todo o cluster: A criptografia em HX é implementada em hardware para dados em repouso apenas usando SEDs
Criptografia de VM individual: Gerenciado por software de terceiros, como Hytrust ou cliente transparente da Vormetric

Criptografia de VM nativa VMware: Suportado pela HX para uso com criptografia SED
Gerenciamento de chave: A chave de criptografia de mídia (MEK) e a chave de criptografia de chave (KEK) são usadas para cada SED

Uso de memória: As chaves de criptografia nunca estão presentes na memória do nó
Impacto no desempenho: A criptografia/descriptografia do disco é feita no hardware da unidade, o desempenho geral do sistema não é afetado

Benefícios adicionais dos SEDs:
- Apagamento criptográfico instantâneo para redução dos custos de desativação e reimplantação da unidade
- Conformidade com regulamentações governamentais ou do setor para privacidade de dados
- Risco reduzido de roubo de disco e de nós, pois os dados se tornam ilegíveis quando o hardware é removido

Instruções de uso do produto

Para usar a criptografia de segurança HX, siga estas instruções:

Certifique-se de que seu sistema suporte criptografia baseada em hardware ou que você prefira a solução baseada em software usando o Intersight Key Manager.

Consulte os documentos de administração ou whitepaper(s) para obter informações sobre criptografia baseada em software.
Se você optar por usar criptografia baseada em hardware com SEDs, certifique-se de que seu cluster HX consista em nós uniformes (SEDs ou não SEDs).

Para SEDs, entenda que existem duas chaves em uso: a Media Encryption Key (MEK) e a Key Encryption Key (KEK).
O MEK controla a criptografia e descriptografia dos dados no disco e é protegido e gerenciado por hardware.

A KEK protege a MEK/DEK e é mantida em um keystore local ou remoto.
Não se preocupe com a presença das chaves na memória do nó, pois as chaves de criptografia nunca são armazenadas lá.

Observe que a criptografia/descriptografia do disco é realizada no hardware da unidade, garantindo que o desempenho geral do sistema não seja afetado.
Se você tiver requisitos específicos para padrões de conformidade, esteja ciente de que as unidades criptografadas HX SED atendem aos padrões FIPS 140-2 nível 2 dos fabricantes de unidades, enquanto a criptografia HX na plataforma atende aos padrões FIPS 140-2 nível 1.

Se você precisar criptografar VMs individuais, considere usar software de terceiros, como Hytrust ou cliente transparente da Vormetric. Como alternativa, você pode utilizar a criptografia nativa de VM do VMware introduzida no vSphere 3.
Lembre-se de que usar um cliente de criptografia de VM além da criptografia baseada em HX SED resultará em criptografia dupla dos dados.

Certifique-se de que seu cluster HX esteja conectado por meio de redes confiáveis ou túneis criptografados para replicação segura, pois a replicação HX não é criptografada.

Perguntas frequentes sobre criptografia de segurança HX

A partir do HXDP 5.01b, o HyperFlex oferece uma solução baseada em software usando o Intersight Key Manager para sistemas que não suportam criptografia baseada em hardware ou para usuários que desejam essa funcionalidade em vez de soluções de hardware. Esta FAQ concentra-se apenas em soluções de hardware baseadas em SED para criptografia HX. Consulte os documentos de administração ou whitepaper(s) para obter informações sobre criptografia baseada em software.

Declaração de preconceito
O conjunto de documentação para este produto se esforça para usar linguagem livre de preconceitos. Para fins deste conjunto de documentação, livre de preconceitos é definido como linguagem que não implica discriminação com base em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Exceções podem estar presentes na documentação devido à linguagem que é codificada nas interfaces do usuário do software do produto, linguagem usada com base na documentação de padrões ou linguagem que é usada por um produto de terceiros referenciado.

Por que Cisco para segurança e criptografia HX

P 1.1: Quais processos existem para um desenvolvimento seguro?
A 1.1: Os servidores Cisco aderem ao Cisco Secure Development Lifecycle (CSDL):
- A Cisco fornece processos, metodologias e estruturas para desenvolver segurança incorporada em servidores Cisco, não apenas uma sobreposição
- Equipe dedicada da Cisco para modelagem de ameaças/análise estática no portfólio de produtos UCS
- O Cisco Advanced Security Initiative Group (ASIG) realiza testes de penetração proativos para entender como as ameaças chegam e corrigir problemas, aprimorando HW e SW por meio de CDETS e engenharia
- Equipe dedicada da Cisco para testar e lidar com vulnerabilidades de saída e se comunicar como consultores de segurança com os clientes
- Todos os produtos subjacentes passam pelos requisitos básicos de segurança do produto (PSB), que regem os padrões de segurança dos produtos Cisco
- Cisco realiza testes de robustez de vulnerabilidade/protocolo em todas as versões UCS
Q 1.2: Por que os SEDs são importantes?
A 1.2: SEDs são usados para criptografia de dados em repouso e são um requisito para muitas, senão todas, instituições federais, médicas e financeiras.

Informações gerais sobreview

Q 2.1: O que são SEDs?
A 2.1: SED (unidades com criptografia automática) possuem hardware especial que criptografa os dados de entrada e descriptografa os dados de saída em tempo real.
Q 2.2: Qual é o escopo da criptografia no HX?
A 2.2: A criptografia em HX é atualmente implementada em hardware para dados em repouso usando apenas unidades criptografadas (SEDs). A criptografia HX abrange todo o cluster. A criptografia de VM individual é gerenciada por software de terceiros, como Hytrust ou cliente transparente da Vormetric, e está fora do escopo das responsabilidades de HX. O HX também oferece suporte ao uso da criptografia nativa de VM do VMware introduzida no vSphere 3. O uso de um cliente de criptografia de VM além da criptografia baseada em HX SED resultará em criptografia dupla dos dados. A replicação HX não é criptografada e depende de redes confiáveis ou túneis criptografados implantados pelo usuário final.
Q 2.3: Quais padrões de conformidade são atendidos com a criptografia HX?
A 2.3: As unidades criptografadas HX SED atendem aos padrões FIPS 140-2 nível 2 dos fabricantes de unidades. A criptografia HX na plataforma atende aos padrões FIPS 140-2 nível 1.
Q 2.4: Oferecemos suporte a HDD e SSD para criptografia?
A 2.4: Sim, oferecemos suporte a SEDs HDD e SSD da Micron.
Q 2.5: Um cluster HX pode ter unidades criptografadas e não criptografadas ao mesmo tempo?
A 2.5: Todos os nós no cluster devem ser uniformes (SEDs ou não-SEDs)
Q 2.6: Quais chaves são usadas para um SED e como são usadas?
A 2.6: Existem duas chaves em uso para cada SED. A chave de criptografia de mídia (MEK), também chamada de chave de criptografia de disco (DEK), controla a criptografia e descriptografia dos dados no disco e é protegida e gerenciada em hardware. A chave de criptografia de chave (KEK) protege o DEK/MEK e é mantida em um armazenamento de chaves local ou remoto.
Q 2.7: As chaves estão sempre presentes na memória?
A 2.7: As chaves de criptografia nunca estão presentes na memória do nó
Q 2.8: Como o desempenho é afetado pelo processo de criptografia/descriptografia?
A 2.8: A criptografia/descriptografia do disco é feita no hardware da unidade. O desempenho geral do sistema não é afetado e não está sujeito a ataques direcionados a outros componentes do sistema
Q 2.9: Além da criptografia em repouso, quais são os outros motivos para usar SEDs?
A 2.9: Os SEDs podem reduzir os custos de desativação e reimplantação de unidades por meio do apagamento criptográfico instantâneo. Eles também servem para cumprir as regulamentações governamentais ou do setor relativas à privacidade de dados. Outra vantagemtage é o risco reduzido de roubo de disco e roubo de nós, uma vez que os dados, uma vez removido o hardware do ecossistema, ficam ilegíveis.
Q2.10: O que acontece com a desduplicação e compactação com SEDs? O que acontece com a criptografia baseada em software de terceiros?
A2.10: A desduplicação e a compactação com SEDs no HX são mantidas, pois a criptografia dos dados em repouso ocorre como última etapa do processo de gravação. A desduplicação e a compactação já ocorreram. Com produtos de criptografia baseados em software de terceiros, as VMs gerenciam sua criptografia e passam gravações criptografadas para o hipervisor e, posteriormente, para o HX. Como essas gravações já estão criptografadas, elas não são desduplicadas ou compactadas. A criptografia baseada em software HX (na linha de código 3.x) será uma solução de criptografia de software implementada na pilha após a ocorrência de otimizações de gravação (desduplicação e compactação), de modo que o benefício será mantido nesse caso.

A figura abaixo é um resumoview da implementação do SED com HX.

Detalhes da unidade

Q 3.1: Quem fabrica as unidades criptografadas usadas no HX?
A 3.1: HX usa unidades fabricadas pela Micron: Documentos específicos da Micron estão vinculados na seção de documentos de suporte desta FAQ.
Q 3.2: Oferecemos suporte a algum SED que não seja compatível com FIPS?
A 3.2: Também oferecemos suporte a algumas unidades que não são FIPS, mas oferecem suporte a SED (TCGE).
Q 3.3: O que é o TCG?
A 3.3: TCG é o Trusted Computing Group, que cria e gerencia o padrão de especificações para armazenamento de dados criptografados
P 3.4: O que é considerado segurança de classe empresarial quando se trata de SSDs SAS para data center? Quais recursos específicos essas unidades possuem para garantir a segurança e proteger contra ataques?
A 3.4: Esta lista resume os recursos de classe empresarial dos SEDs usados no HX e como eles se relacionam com o padrão TCG.
1. Unidades com criptografia automática (SEDs) fornecem forte segurança para dados inativos em seu SED, evitando o acesso não autorizado aos dados. O Trusted Computing Group (TCG) desenvolveu uma lista de recursos e benefícios de unidades com criptografia automática para HDDs e SSDs. O TCG fornece um padrão chamado TCG Enterprise SSC (Security Subsystem Class) e é focado em dados em repouso. Este é um requisito para todos os SEDs. A especificação se aplica a dispositivos e controladores de armazenamento de dados que operam em armazenamento corporativo. A lista inclui:
  - Transparência: Não são necessárias modificações no sistema ou no aplicativo; chave de criptografia gerada pelo próprio drive, usando um gerador de números aleatórios verdadeiros integrado; a unidade está sempre criptografando.
  - Facilidade de gerenciamento: Nenhuma chave de criptografia para gerenciar; fornecedores de software exploram interface padronizada para gerenciar SEDs, incluindo gerenciamento remoto, autenticação pré-inicialização e recuperação de senha
  - Custo de descarte ou reaproveitamento: Com um SED, apague a chave de criptografia integrada
  - Recriptografia: Com o SED, não há necessidade de criptografar novamente os dados
  - Desempenho: Nenhuma degradação no desempenho do SED; baseado em hardware
  - Padronização: Toda a indústria de drives está construindo de acordo com as especificações TCG/SED
  - Simplificado: Sem interferência com processos upstream
2. Os SSDs SEDs oferecem a capacidade de apagar criptograficamente a unidade. Isso significa que um comando simples autenticado pode ser enviado à unidade para alterar a chave de criptografia de 256 bits armazenada na unidade. Isso garante que a unidade seja limpa e que não haja dados restantes. Mesmo o sistema host original não pode ler os dados, portanto eles serão absolutamente ilegíveis por qualquer outro sistema. A operação leva apenas alguns segundos, em oposição aos muitos minutos ou mesmo horas que leva para executar uma operação análoga em um HDD não criptografado e evita o custo de equipamentos ou serviços caros de desmagnetização do HDD.
3. FIPS (Federal Information Processing Standard) 140-2 é um padrão do governo dos EUA que descreve a criptografia e os requisitos de segurança relacionados que os produtos de TI devem atender para uso confidencial, mas não classificado. Muitas vezes, isso é um requisito para agências governamentais e empresas dos setores de serviços financeiros e de saúde. Um SSD validado pelo FIPS-140-2 usa práticas de segurança rigorosas, incluindo algoritmos de criptografia aprovados. Também especifica como indivíduos ou outros processos devem ser autorizados para utilizar o produto e como os módulos ou componentes devem ser projetados para interagir de forma segura com outros sistemas. Na verdade, um dos requisitos de uma unidade SSD validada pelo FIPS-140-2 é que ela seja um SED. Tenha em mente que embora o TCG não seja a única maneira de obter uma unidade criptografada certificada, as especificações TCG Opal e Enterprise SSC nos fornecem um trampolim para a validação FIPS. 4. Outro recurso essencial são downloads e diagnósticos seguros. Esse recurso de firmware protege a unidade contra ataques de software por meio de uma assinatura digital incorporada ao firmware. Quando são necessários downloads, a assinatura digital impede o acesso não autorizado à unidade, evitando que firmware falsificado seja carregado na unidade.

Instalação Hyperflex com SEDs

Q 4.1: Como o instalador lida com uma implantação de SED? Existem verificações especiais?
A 4.1: O instalador se comunica com o UCSM e garante que o firmware do sistema esteja correto e seja compatível com o hardware detectado. A compatibilidade da criptografia é verificada e aplicada (por exemplo, nenhuma mistura de SED e não-SED).
Q 4.2: Caso contrário, a implantação é diferente?
A 4.2: A instalação é semelhante a uma instalação normal do HX, no entanto, o fluxo de trabalho personalizado não é compatível com SEDs. Esta operação também requer credenciais UCSM para os SEDs.
Q 4.3: Como funciona o licenciamento com criptografia? Há algo extra que precisa ser implementado?
A 4.3: Hardware SED (encomendado de fábrica, não adaptado) + HXDP 2.5 + UCSM (3.1(3x)) são os únicos itens necessários para ativar a criptografia com gerenciamento de chaves. Não há licenciamento adicional fora da assinatura básica do HXDP exigida na versão 2.5.

P 4.4: O que acontece quando tenho um sistema SED com unidades que não estão mais disponíveis? Como posso expandir este cluster?
A 4.4: Sempre que temos algum PID em fim de vida dos nossos fornecedores, temos um PID substituto que é compatível com o PID antigo. Este PID de substituição pode ser usado para RMA, expansão dentro de um nó e expansão de cluster (com novos nós). Todos os métodos são suportados, no entanto, podem exigir atualização para uma versão específica que também é identificada nas notas de versão de transição.

Gerenciamento de chaves

Q 5.1: O que é gerenciamento de chaves?
A 5.1: O gerenciamento de chaves são as tarefas envolvidas na proteção, armazenamento, backup e organização de chaves de criptografia. A HX implementa isso em uma política centrada em UCSM.
Q 5.2: Qual mecanismo fornece suporte para configuração de chave?
A 5.2: O UCSM fornece suporte para configurar chaves de segurança.

Q 5.3: Que tipo de gerenciamento de chaves está disponível?
A 5.3: O gerenciamento local de chaves é suportado, juntamente com o gerenciamento remoto de chaves de classe empresarial com servidores de gerenciamento de chaves de terceiros.
Q 5.4: Quem são os parceiros de gerenciamento remoto de chaves?
A 5.4: Atualmente oferecemos suporte a Vormetric e Gemalto (Safenet) e inclui alta disponibilidade (HA). HyTrust está em testes.
Q 5.5: Como o gerenciamento remoto de chaves é implementado?
A 5.5: O gerenciamento remoto de chaves é feito via KMIP 1.1.

Q 5.6: Como é configurado o gerenciamento local?
A 5.6: A chave de segurança (KEK) é configurada no HX Connect, diretamente pelo usuário.
Q 5.7: Como o gerenciamento remoto é configurado?
A 5.7: As informações de endereço do servidor de gerenciamento remoto de chaves (KMIP), juntamente com as credenciais de login, são configuradas no HX Connect pelo usuário.
Q 5.8: Qual parte do HX se comunica com o servidor KMIP para configuração?
A 5.8: O CIMC em cada nó usa essas informações para se conectar ao servidor KMIP e recuperar a chave de segurança (KEK) dele.

Q 5.9: Que tipos de certificados são suportados no processo de geração/recuperação/atualização de chaves?
A 5.9: Certificados assinados por CA e autoassinados são suportados.
Q 5.10: Quais fluxos de trabalho são suportados pelo processo de criptografia?
A 5.10: Proteger/desproteger usando uma senha personalizada é suportado junto com a conversão de gerenciamento de chave local para remoto. As operações de rechaveamento são suportadas. A operação segura de apagamento de disco também é suportada.

Fluxo de trabalho do usuário: local

Q 6.1: No HX Connect, onde configuro o gerenciamento de chaves locais?
A 6.1: No painel de criptografia, selecione o botão configurar e siga o assistente.

Q 6.2: O que preciso ter pronto para começar?
A 6.2: Você precisará fornecer uma senha de segurança de 32 caracteres.
P 6.3: O que acontece se eu precisar inserir um novo SED?
Um 6.3: No UCSM você precisará editar a política de segurança local e definir a chave implantada para a chave do nó existente.
Pergunta 6.4: O que acontece quando insiro o novo disco?
A 6.4: Se a chave de segurança no disco corresponder à do servidor (nó), ela será desbloqueada automaticamente. Se as chaves de segurança forem diferentes, o disco aparecerá como “Bloqueado”. Você pode limpar o disco para excluir todos os dados ou desbloqueá-lo fornecendo a chave correta. Este é um bom momento para envolver o TAC.

Fluxo de trabalho do usuário: remoto

P 7.1: Quais são algumas coisas que preciso observar na configuração do gerenciamento remoto de chaves?
A 7.1: A comunicação entre o cluster e o(s) servidor(es) KMIP acontece através do CIMC em cada nó. Isso significa que o nome do host pode ser usado para o servidor KMIP somente se o endereço IP Inband e o DNS estiverem configurados no gerenciamento CIMC
P 7.2: O que acontece se eu precisar substituir ou inserir um novo SED?
A 7.2: O cluster lerá o identificador do disco e tentará desbloqueá-lo automaticamente. Se o desbloqueio automático falhar, o disco aparecerá como “bloqueado” e o usuário deverá desbloquear o disco manualmente. Você terá que copiar os certificados para o(s) servidor(es) KMIP para troca de credenciais.
Q 7.3: Como copio certificados do cluster para o(s) servidor(es) KMIP?
A 7.3: Existem duas maneiras de fazer isso. Você pode copiar o certificado do BMC para o servidor KMIP diretamente ou pode usar o CSR para obter um certificado assinado pela CA e copiar o certificado assinado pela CA para o BMC usando comandos UCSM.

Q 7.4: Quais são as considerações para adicionar nós criptografados a um cluster que usa gerenciamento remoto de chaves?
A 7.4: Ao adicionar novos hosts ao(s) servidor(es) KMIP, o nome do host usado deve ser o número de série do servidor. Para obter o certificado do servidor KMIP, você pode usar um navegador para obter o certificado raiz do(s) servidor(es) KMIP.

Fluxo de trabalho do usuário: geral

Q 8.1: Como apago um disco?
A 8.1: No painel do HX Connect, selecione as informações do sistema view. A partir daí você pode selecionar discos individuais para apagamento seguro.
Q 8.2: E se eu apagar um disco acidentalmente?
A 8.2: Quando o apagamento seguro é usado, os dados são destruídos permanentemente

Q 8.3: O que acontece quando desejo descomissionar um nó ou dissociar um profissional de serviçofile?
A 8.3: Nenhuma dessas ações removerá a criptografia do disco/controlador.
Q 8.4: Como a criptografia é desativada?
A 8.4: O usuário deve desabilitar explicitamente a criptografia no HX Connect. Se o usuário tentar excluir uma política de segurança no UCSM quando o servidor associado tiver sido protegido, o UCSM exibirá uma falha de configuração e não permitirá a ação. A política de segurança deve ser desativada primeiro.

Fluxo de trabalho do usuário: gerenciamento de certificados

P 9.1: Como os certificados são tratados durante a configuração do gerenciamento remoto?
A 9.1: Os certificados são criados usando o HX Connect e os servidores KMIP remotos. Os certificados, uma vez criados, quase nunca serão excluídos.

Q 9.2: Que tipo de certificados posso usar?
A 9.2: Você pode usar certificados autoassinados ou certificados CA. Você deve escolher durante a configuração. Para certificados assinados por CA, você gerará um conjunto de Solicitações de Assinatura de Certificado (CSRs). Os certificados assinados são carregados no(s) servidor(es) KMIP.
Q 9.3: Qual nome de host devo usar ao gerar os certificados?
A 9.3: O nome do host usado para gerar o certificado deve ser o número de série do servidor.

Atualizações de Firmware

Q 10.1: Há alguma restrição na atualização do firmware do disco?
A 10.1: Se uma unidade com capacidade de criptografia for detectada, quaisquer alterações no firmware do disco não serão permitidas para esse disco.

Q 10.2: Há alguma restrição à atualização do firmware do UCSM?
A 10.2: O downgrade do UCSM/CIMC para o pré-UCSM 3.1(3x) será restrito se houver um controlador que esteja em estado seguro.

Detalhes de apagamento seguro

Q 11.1: O que é apagamento seguro?
A 11.1: O apagamento seguro é o apagamento instantâneo dos dados na unidade (limpeza da chave de criptografia do disco). Isso significa que um comando simples autenticado pode ser enviado à unidade para alterar a chave de criptografia de 256 bits armazenada na unidade. Isso garante que a unidade seja limpa e que não haja dados restantes. Mesmo o sistema host original não pode ler os dados, portanto eles serão ilegíveis por qualquer outro sistema. A operação leva apenas alguns segundos, em oposição aos muitos minutos ou mesmo horas que leva para executar uma operação análoga em um disco não criptografado e evita o custo de equipamentos ou serviços de desmagnetização caros.
Q 11.2: Como é realizado o apagamento seguro?
A 11.2: Esta é uma operação GUI executada em uma unidade por vez.

Q 11.3: Quando geralmente é realizado o apagamento seguro?
A 11.3: O apagamento seguro de um único disco iniciado pelo usuário é uma operação rara. Isso é feito principalmente quando você deseja remover fisicamente o disco para substituição, transferi-lo para outro nó ou evitar falhas futuras.
Q 11.4: Quais restrições existem ao apagamento seguro?
A 11.4: As operações de apagamento seguro só poderão ser executadas se o cluster estiver íntegro para garantir que a resiliência a falhas do cluster não seja afetada.
Q 11.5: O que acontece se eu precisar remover um nó inteiro?
A 11.5: Existem fluxos de trabalho de remoção e substituição de nós para oferecer suporte ao apagamento seguro de todas as unidades. Consulte o guia do administrador para obter detalhes ou consulte o Cisco TAC.

Q 11.6: Um disco apagado com segurança pode ser reutilizado?
A 11.6: Um disco que foi apagado com segurança só pode ser reutilizado em um cluster diferente. O apagamento seguro do SED é feito limpando a chave de criptografia de disco (DEK). Os dados no disco não podem ser descriptografados sem DEK. Isso permite reutilizar ou desativar o disco sem comprometer os dados.
Q 11.7: O que acontece se o disco que desejo apagar contiver a última cópia primária dos dados do cluster?
A 11.7: Os dados no disco devem ter outras cópias no cluster para evitar perda de dados. Entretanto, se o apagamento seguro for solicitado em um disco que seja a última cópia primária, esta operação será rejeitada até que haja pelo menos mais uma cópia disponível. O Rebalance deve fazer esta cópia em segundo plano.
Q 11.8: Eu realmente preciso apagar um disco com segurança, mas o cluster não está íntegro. Como eu posso fazer isso?
A 11.8: A linha de comando (STCLI/HXCLI) permitirá o apagamento seguro quando o cluster não estiver íntegro e o disco não contiver a última cópia primária, caso contrário, não será permitido.

Pergunta 11.9: Como posso apagar com segurança um nó inteiro?
A 11.9: Este é um cenário raro. O apagamento seguro de todos os discos em um nó é feito quando se deseja retirar o nó do cluster. A intenção é implantar o nó em um cluster diferente ou descomissioná-lo. Podemos classificar a remoção de nós neste cenário de duas maneiras diferentes:
1. Apague com segurança todos os discos sem desativar a criptografia
2. Apague com segurança todos os discos e desative a criptografia para esse nó (e discos). Entre em contato com o Cisco TAC para obter assistência.

Expansão segura de um cluster

Q 12.1: Com que tipo de nó posso expandir um cluster criptografado?
A 12.1: Somente nós compatíveis com SED podem ser adicionados a um cluster HX com SEDs.

Q 12.2: Como é tratada a expansão com gerenciamento de chaves locais?
A 12.2: A expansão de chave local é uma operação contínua, sem necessidade de configuração externa.
Q 12.3: Como é tratada a expansão com gerenciamento remoto de chaves?
A 12.3: A expansão remota de chaves requer integração com infraestrutura de gerenciamento de certificados/chaves:
- Certificados são necessários para adicionar novo nó com segurança
- A implantação mostrará um aviso com as etapas para prosseguir, incluindo um link para download do certificado
- O usuário segue as etapas para fazer upload de certificados e, em seguida, tenta novamente a implantação

Documentos de suporte

Mícron:

FIPS

Lista de algoritmos criptográficos aprovados para FIPS 140-2: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf

CDETS:

Projeto: CSC.nuova Produto: ucs-blade-server Componente: ucsm

Especificação funcional SED:

EDC: 1574090

Especificação SED CIMC:

http://wwwin-eng.cisco.com/Eng/SAVBU/Projects/Rackmount/Freel_Peak/SW_Specs/Remote_Key_Mgmt_sw_design_spec.doc

Listas de discussão:

Documentos / Recursos

Plataforma de dados CISCO HyperFlex HX [pdf] Instruções
Plataforma de dados HyperFlex HX, HyperFlex, plataforma de dados HX, plataforma de dados, plataforma

Referências

Manual do usuário