Plataforma de datos CISCO HyperFlex HX

Información do produto

• Nome do produto: Cifrado de seguridade HX
• Versión: HXDP 5.01b
• Solución de cifrado: Solución baseada en software usando Intersight Key Manager
• Tipo de cifrado: Unidades de autocifrado (SED)
• Tipos de unidades compatibles: Discos duros e SSD SED de Micron
• Normas de cumprimento: FIPS 140-2 nivel 2 (fabricantes de unidades) e FIPS 140-2 nivel 1 (plataforma)
• Cifrado en todo o clúster: O cifrado en HX está implementado no hardware para os datos en reposo só usando SED
• Cifrado de VM individual: Manexado por software de terceiros como Hytrust ou o cliente transparente de Vormetric
• Cifrado de máquina virtual nativa de VMware: Compatible con HX para usar con cifrado SED
• Xestión de claves: A clave de cifrado multimedia (MEK) e a clave de cifrado de clave (KEK) úsanse para cada SED
• Uso da memoria: As claves de cifrado nunca están presentes na memoria do nodo
• Impacto no rendemento: O cifrado/descifrado do disco xestionase no hardware da unidade, o rendemento xeral do sistema non se ve afectado
• Beneficios adicionais dos SED:
  • Borrado criptográfico instantáneo para reducir os custos de retirada e redistribución de unidades
  • Cumprimento das normativas gobernamentais ou do sector para a privacidade dos datos
  • Redución do risco de roubo de disco e roubo de nodos xa que os datos non se poden lexir unha vez que se elimina o hardware

Instrucións de uso do produto

Para usar HX Security Encryption, siga estas instrucións:

1. Asegúrese de que o seu sistema admite o cifrado baseado en hardware ou de que prefire a solución baseada en software mediante Intersight Key Manager.
2. Consulte os documentos de administración ou os documentos brancos para obter información sobre o cifrado baseado en software.
3. Se decides usar o cifrado baseado en hardware con SED, asegúrate de que o teu clúster HX estea composto por nodos uniformes (SED ou non SED).
4. Para os SED, entende que hai dúas claves en uso: a clave de cifrado multimedia (MEK) e a clave de cifrado de claves (KEK).
5. O MEK controla o cifrado e descifrado dos datos no disco e está protexido e xestionado por hardware.
6. O KEK protexe o MEK/DEK e mantense nun almacén de claves local ou remoto.
7. Non te preocupes porque as claves estean presentes na memoria do nodo, xa que as claves de cifrado nunca se almacenan alí.
8. Teña en conta que o cifrado/descifrado do disco xestione o hardware da unidade, garantindo que o rendemento xeral do sistema non se vexa afectado.
9. Se tes requisitos específicos para os estándares de cumprimento, ten en conta que as unidades cifradas HX SED cumpren os estándares FIPS 140-2 de nivel 2 dos fabricantes de unidades, mentres que o cifrado HX da plataforma cumpre os estándares de FIPS 140-2 de nivel 1.
10. Se precisa cifrar máquinas virtuales individuais, considere usar software de terceiros como Hytrust ou o cliente transparente de Vormetric. Como alternativa, pode utilizar o cifrado nativo de VM de VMware introducido en vSphere 3.
11. Teña en conta que usar un cliente de cifrado de VM ademais do cifrado baseado en HX SED producirá o dobre cifrado dos datos.
12. Asegúrate de que o teu clúster HX estea conectado a través de redes de confianza ou túneles cifrados para a replicación segura, xa que a replicación HX non está cifrada.

Preguntas frecuentes sobre o cifrado de seguridade de HX

A partir de HXDP 5.01b, HyperFlex ofrece unha solución baseada en software que utiliza Intersight Key Manager para sistemas que non admiten o cifrado baseado en hardware ou para usuarios que desexan esta funcionalidade fronte a solucións de hardware. Esta FAQ céntrase só en solucións de hardware baseadas en SED para o cifrado HX. Consulte os documentos de administración ou os documentos brancos para obter información sobre o cifrado baseado en software.

Declaración de parcialidade
O conxunto de documentación para este produto esfórzase por utilizar unha linguaxe sen prexuízos. Para os efectos deste conxunto de documentación, defínese sen prexuízos como unha linguaxe que non implica discriminación por razón de idade, discapacidade, xénero, identidade racial, identidade étnica, orientación sexual, status socioeconómico e interseccionalidade. É posible que existan excepcións na documentación debido á linguaxe codificada nas interfaces de usuario do software do produto, á linguaxe utilizada en función da documentación de estándares ou á lingua que utiliza un produto de terceiros referenciado.

Por que Cisco for Security e HX Encryption 

• P 1.1: Que procesos existen para o desenvolvemento seguro?
  A 1.1: Os servidores de Cisco adhírense ao ciclo de vida de desenvolvemento seguro de Cisco (CSDL):
  • Cisco ofrece procesos, metodoloxías e marcos para desenvolver seguridade integrada nos servidores de Cisco, non só unha superposición
  • Equipo dedicado de Cisco para modelado de ameazas/análise estática na carteira de produtos UCS
  • Cisco Advanced Security Initiative Group (ASIG) realiza probas de penetración proactivas para comprender como chegan as ameazas e solucionar problemas mellorando HW e SW mediante CDETS e enxeñaría.
  • Equipo de Cisco dedicado para probar e xestionar a vulnerabilidade de saída e comunicarse como asesores de seguridade aos clientes
  • Todos os produtos subxacentes pasan polos requisitos básicos de seguridade do produto (PSB) que rexen os estándares de seguridade dos produtos Cisco
  • Cisco realiza probas de robustez de vulnerabilidade/protocolo en todas as versións de UCS
• P 1.2: Por que son importantes os SED?
  A 1.2: Os SED úsanse para o cifrado de datos en reposo e son un requisito para moitas, se non todas, institucións federais, médicas e financeiras.

Información xeral rematadaview

• P 2.1: Que son os SED?
  A 2.1: As unidades SED (Self-Encrypting Drives) teñen hardware especial que cifra os datos entrantes e descifra os datos saíntes en tempo real.
• P 2.2: Cal é o alcance do cifrado en HX?
  A 2.2: O cifrado en HX está implementado actualmente no hardware para os datos en reposo só usando unidades cifradas (SED). O cifrado HX é de todo o clúster. O cifrado de VM individual é xestionado por software de terceiros como Hytrust ou o cliente transparente de Vormetric e está fóra do ámbito das responsabilidades de HX. HX tamén admite o uso do cifrado nativo de VM de VMware introducido en vSphere 3. O uso dun cliente de cifrado de VM ademais do cifrado baseado en HX SED producirá o dobre cifrado dos datos. A replicación HX non está cifrada e depende de redes de confianza ou túneles cifrados despregados polo usuario final.
• P 2.3: Que estándares de cumprimento se cumpren co cifrado HX?
  A 2.3: As unidades cifradas HX SED cumpren os estándares FIPS 140-2 de nivel 2 dos fabricantes de unidades. O cifrado HX na plataforma cumpre os estándares FIPS 140-2 de nivel 1.
• P 2.4: admitimos tanto HDD como SSD para o cifrado?
  A 2.4: Si, admitimos tanto os discos duros como os SSD SED de Micron.
• P 2.5: Pode un clúster HX ter unidades cifradas e non cifradas ao mesmo tempo?
  A 2.5: Todos os nodos do clúster deben ser uniformes (SED ou non SED)
• P 2.6: Que chaves se usan para un SED e como se usan?
  A 2.6: Hai dúas claves en uso para cada SED. A clave de cifrado multimedia (MEK) tamén chamada clave de cifrado de disco (DEK), controla o cifrado e descifrado dos datos no disco e está protexido e xestionado no hardware. A clave de cifrado de claves (KEK) protexe o DEK/MEK e mantense nun almacén de claves local ou remoto.
• P 2.7: As chaves están sempre presentes na memoria?
  A 2.7: As claves de cifrado nunca están presentes na memoria do nodo
• P 2.8: Como afecta o rendemento o proceso de cifrado/descifrado?
  A 2.8: O cifrado/descifrado do disco xestionase no hardware da unidade. O rendemento global do sistema non se ve afectado e non está suxeito a ataques dirixidos a outros compoñentes do sistema
• P 2.9: Ademais do cifrado en reposo, cales son outros motivos para usar SED?
  A 2.9: Os SED poden reducir os custos de xubilación e redistribución das unidades mediante o borrado criptográfico instantáneo. Tamén serven para cumprir coas normativas gobernamentais ou do sector para a privacidade dos datos. Outro avancetage é o risco reducido de roubo de disco e roubo de nodos xa que os datos, unha vez que se elimina o hardware do ecosistema, son ilexíbeis.
• P2.10: Que ocorre coa deduplicación e compresión con SED? Que ocorre co cifrado baseado en software de terceiros?
  A2.10: A deduplicación e compresión con SED en HX mantense xa que o cifrado de datos en reposo ten lugar como último paso do proceso de escritura. A deduplicación e a compresión xa se produciron. Con produtos de cifrado baseados en software de terceiros, as máquinas virtuales xestionan o seu cifrado e pasan as escrituras cifradas ao hipervisor e, posteriormente, a HX. Dado que estas escrituras xa están cifradas, non se deduplican nin se comprimen. O cifrado baseado en software HX (na liña de código 3.x) será unha solución de cifrado de software que se implementa na pila despois de que se produzan optimizacións de escritura (desduplicación e compresión), polo que o beneficio conservarase nese caso.

A figura de abaixo é unha superaciónview da implantación de SED con HX.

Detalles da unidade 

• P 3.1: Quen fabrica as unidades cifradas que se usan en HX?
  A 3.1: HX usa unidades fabricadas por Micron: Os documentos específicos de Micron están ligados na sección de documentos de apoio destas preguntas frecuentes.
• P 3.2: Admitimos algún SED que non sexa compatible con FIPS?
  A 3.2: Tamén admitimos algunhas unidades que non son FIPS, pero admiten SED (TCGE).
• P 3.3: Que é o TCG?
  A 3.3: TCG é o Trusted Computing Group, que crea e xestiona o estándar de especificacións para o almacenamento de datos cifrados
• P 3.4: Que se considera seguridade de clase empresarial cando se trata de SSD SAS para o centro de datos? Que características específicas teñen estas unidades que garanten a seguridade e protexen contra ataques?
  A 3.4: Esta lista resume as características de clase empresarial dos SED utilizados en HX e como se relacionan co estándar TCG.
  1. As unidades de autocifrado (SED) proporcionan unha forte seguridade para os datos en reposo no teu SED, evitando o acceso a datos non autorizados. O Trusted Computing Group (TCG) desenvolveu unha lista das características e beneficios das unidades de autocifrado tanto para HDD como SSD. O TCG ofrece un estándar que se chama TCG Enterprise SSC (Security Subsystem Class) e céntrase nos datos en reposo. Este é un requisito para todos os SED. A especificación aplícase aos dispositivos e controladores de almacenamento de datos que funcionan no almacenamento empresarial. A lista inclúe:
     • Transparencia: Non se precisan modificacións do sistema ou da aplicación; chave de cifrado xerada pola propia unidade, utilizando un xerador de números aleatorios verdadeiros incorporado; a unidade está sempre cifrando.
     • Facilidade de xestión: Sen chave de cifrado para xestionar; Os provedores de software aproveitan unha interface estandarizada para xestionar SED, incluíndo xestión remota, autenticación previa ao arranque e recuperación de contrasinal
     • Custo de eliminación ou reutilización: Cun SED, borra a clave de cifrado integrada
     • Re-cifrado: Con SED, non hai necesidade de volver cifrar os datos
     • Rendemento: Sen degradación no rendemento SED; baseado en hardware
     • Normalización: Toda a industria de impulsión está construíndo as especificacións TCG/SED
     • Simplificado: Sen interferencias cos procesos ascendentes
  2. Os SSD SED proporcionan a capacidade de borrar criptograficamente a unidade. Isto significa que se pode enviar un simple comando autenticado á unidade para cambiar a clave de cifrado de 256 bits almacenada na unidade. Isto garante que a unidade estea limpa e que non queden datos. Incluso o sistema host orixinal non pode ler os datos, polo que ningún outro sistema o pode leer. A operación só leva un par de segundos, ao contrario dos moitos minutos ou incluso horas que leva realizar unha operación análoga nun disco duro sen cifrar e evita o custo dos custosos equipos ou servizos de desgasificación do disco duro.
  3. FIPS (Federal Information Processing Standard) 140-2 é un estándar do goberno dos Estados Unidos que describe os requisitos de cifrado e de seguranza relacionados que deben cumprir os produtos de TI para un uso sensible, pero non clasificado. Este é a miúdo un requisito para as axencias gobernamentais e as empresas do sector dos servizos financeiros e da saúde. Un SSD validado por FIPS-140-2 utiliza prácticas de seguranza sólidas, incluíndo algoritmos de cifrado aprobados. Tamén especifica como se deben autorizar os individuos ou outros procesos para utilizar o produto e como se deben deseñar módulos ou compoñentes para interactuar de forma segura con outros sistemas. De feito, un dos requisitos dunha unidade SSD validada por FIPS-140-2 é que sexa un SED. Teña en conta que aínda que TCG non é a única forma de obter unha unidade cifrada certificada, as especificacións TCG Opal e Enterprise SSC ofrécennos un trampolín para a validación FIPS. 4. Outra característica esencial son Descargas e diagnóstico seguros. Esta función de firmware protexe a unidade de ataques de software mediante unha sinatura dixital integrada no firmware. Cando se necesitan descargas, a sinatura dixital impide o acceso non autorizado á unidade, evitando que se cargue firmware falsificado na unidade.

Instalación de Hyperflex con SED

• P 4.1: Como xestiona o instalador unha implantación SED? Existen controis especiais?
  A 4.1: O instalador comunícase con UCSM e garante que o firmware do sistema é correcto e compatible co hardware detectado. Compróbase e aplícase a compatibilidade do cifrado (por exemplo, sen mestura de SED e non SED).
• P 4.2: o despregamento é diferente doutro xeito?
  A 4.2: A instalación é semellante a unha instalación HX normal, con todo, o fluxo de traballo personalizado non é compatible con SED. Esta operación tamén require credenciais UCSM para os SED.
• P 4.3: Como funciona a licenza co cifrado? Hai algo extra que deba estar no seu lugar?
  A 4.3: Hardware SED (pedido de fábrica, non adaptado) + HXDP 2.5 + UCSM (3.1(3x)) son os únicos necesarios para habilitar o cifrado coa xestión de claves. Non se require ningunha licenza adicional fóra da subscrición base HXDP na versión 2.5.
• P 4.4: Que ocorre cando teño un sistema SED que ten unidades que xa non están dispoñibles? Como podo ampliar este clúster?
  A 4.4: Sempre que teñamos algún PID que estea ao final da súa vida útil dos nosos provedores, temos un PID de substitución compatible co PID antigo. Este PID de substitución pódese usar para RMA, expansión dentro dun nodo e expansión do clúster (con novos nodos). Todos os métodos son compatibles, non obstante, poden requirir a actualización a unha versión específica que tamén se identifica nas notas da versión de transición.

Xestión de claves

• P 5.1: Que é a xestión de claves?
  A 5.1: A xestión de claves son as tarefas implicadas na protección, almacenamento, copia de seguranza e organización das claves de cifrado. HX implementa isto nunha política centrada en UCSM.
• P 5.2: Que mecanismo ofrece soporte para a configuración de chaves?
  A 5.2: UCSM ofrece soporte para configurar chaves de seguranza.
• P 5.3: Que tipo de xestión de chaves está dispoñible?
  A 5.3: Admítese a xestión local de claves, xunto coa xestión remota de chaves de clase empresarial con servidores de xestión de chaves de terceiros.
• P 5.4: Quen son os socios de xestión de chaves remotas?
  A 5.4: Actualmente admitimos Vormetric e Gemalto (Safenet) e inclúe alta dispoñibilidade (HA). HyTrust está en proba.
• P 5.5: Como se implementa a xestión remota de chaves?
  A 5.5: A xestión remota de claves faise a través de KMIP 1.1.
• P 5.6: Como se configura a xestión local?
  A 5.6: A clave de seguranza (KEK) está configurada en HX Connect, directamente polo usuario.
• P 5.7: Como se configura a xestión remota?
  A 5.7: O usuario configura a información do enderezo do servidor de xestión de claves remotas (KMIP) xunto coas credenciais de inicio de sesión en HX Connect.
• P 5.8: Que parte de HX se comunica co servidor KMIP para a configuración?
  A 5.8: O CIMC de cada nodo usa esta información para conectarse ao servidor KMIP e recuperar a chave de seguranza (KEK) del.
  
• P 5.9: Que tipos de certificados son compatibles no proceso de xeración/recuperación/actualización de claves?
  A 5.9: Admítense os certificados asinados pola CA e os autoasinados.
  
• P 5.10: Que fluxos de traballo son compatibles co proceso de cifrado?
  A 5.10: Admítese a protección/desprotección mediante un contrasinal personalizado xunto coa conversión de xestión de clave local a remota. Admítense operacións de cambio de teclas. Tamén se admite a operación segura de borrado do disco.
  

Fluxo de traballo do usuario: local

• P 6.1: En HX Connect, onde configuro a xestión local de chaves?
  A 6.1: No panel de cifrado, seleccione o botón de configuración e siga o asistente.
• P 6.2: Que teño que ter preparado para comezar?
  A 6.2: Deberá proporcionar unha frase de seguridade de 32 caracteres.
• P 6.3: Que pasa se teño que inserir un novo SED?
  A 6.3: En UCSM terá que editar a política de seguranza local e establecer a clave despregada na clave de nodo existente.
• Q 6.4: Que ocorre cando inserir o novo disco?
  A 6.4: Se a chave de seguranza do disco coincide coa do servidor (nodo), desbloquearase automaticamente. Se as chaves de seguranza son diferentes, o disco mostrarase como "Bloqueado". Podes borrar o disco para eliminar todos os datos ou desbloquealo proporcionando a clave correcta. Este é un bo momento para involucrar a TAC.

Fluxo de traballo do usuario: remoto

• P 7.1: Cales son algunhas das cousas que teño que ter en conta coa configuración da xestión remota de chaves?
  A 7.1: A comunicación entre o clúster e os servidores KMIP realízase a través do CIMC en cada nodo. Isto significa que o nome de host só se pode usar para o servidor KMIP se o enderezo IP Inband e o DNS están configurados na xestión do CIMC.
• P 7.2: Que pasa se teño que substituír ou inserir un novo SED?
  A 7.2: O clúster lerá o identificador do disco e tentará desbloquealo automaticamente. Se o desbloqueo automático falla, o disco aparece como "bloqueado" e o usuario ten que desbloquear o disco manualmente. Terás que copiar os certificados no servidor(es) KMIP para o intercambio de credenciais.
• P 7.3: Como copio certificados do clúster ao servidor KMIP?
  A 7.3: Hai dúas formas de facelo. Pode copiar o certificado do BMC ao servidor KMIP directamente ou pode usar o CSR para obter un certificado asinado pola CA e copiar o certificado asinado pola CA no BMC mediante comandos UCSM.
• P 7.4: Que consideracións hai para engadir nós cifrados a un clúster que utiliza a xestión remota de claves?
  A 7.4: Ao engadir novos hosts ao servidor KMIP, o nome de host usado debe ser o número de serie do servidor. Para obter o certificado do servidor KMIP, pode usar un navegador para obter o certificado raíz do servidor KMIP.

Fluxo de traballo do usuario: xeral

• P 8.1: Como borro un disco?
  A 8.1: No panel de control de HX Connect, seleccione a información do sistema view. Desde alí pode seleccionar discos individuais para o borrado seguro.
• P 8.2: E se borrei un disco por accidente?
  A 8.2: Cando se utiliza o borrado seguro, os datos destrúense permanentemente
• P 8.3: Que pasa cando quero desactivar un nodo ou desvincular un profesional do servizofile?
  A 8.3: Ningunha destas accións eliminará o cifrado do disco/controlador.
• P 8.4: Como se desactiva o cifrado?
  A 8.4: O usuario ten que desactivar explícitamente o cifrado en HX Connect. Se o usuario tenta eliminar unha política de seguranza en UCSM cando o servidor asociado está protexido, UCSM mostrará un fallo de configuración e non permitirá a acción. Primeiro hai que desactivar a política de seguridade.

Fluxo de traballo do usuario: xestión de certificados

• P 9.1: Como se manexan os certificados durante a configuración da xestión remota?
  A 9.1: Os certificados créanse mediante HX Connect e os servidores remotos KMIP. Os certificados unha vez creados case nunca se eliminarán.
• P 9.2: Que tipo de certificados podo usar?
  A 9.2: Podes usar certificados autoasinados ou certificados de CA. Ten que escoller durante a configuración. Para os certificados asinados por CA xerará un conxunto de solicitudes de sinatura de certificados (CSR). Os certificados asinados cárganse nos servidores KMIP.
• P 9.3: Que nome de host debo usar ao xerar os certificados?
  A 9.3: O nome de host usado para xerar o certificado debe ser o número de serie do servidor.

Actualizacións de firmware

• P 10.1: Hai algunha restrición para actualizar o firmware do disco?
  A 10.1: Se se detecta unha unidade con capacidade de cifrado, non se permitirá ningún cambio de firmware do disco para ese disco.
• P 10.2: Hai algunha restrición para actualizar o firmware UCSM?
  A 10.2: A degradación de UCSM/CIMC á versión anterior a UCSM 3.1(3x) está restrinxida se hai un controlador que está en estado protexido.

Detalles de borrado seguro

• P 11.1: Que é Secure Erase?
  A 11.1: O borrado seguro é o borrado instantáneo dos datos da unidade (borrar a clave de cifrado do disco). Isto significa que se pode enviar un simple comando autenticado á unidade para cambiar a clave de cifrado de 256 bits almacenada na unidade. Isto garante que a unidade estea limpa e que non queden datos. Incluso o sistema anfitrión orixinal non pode ler os datos polo que calquera outro sistema os poderá ler. A operación só leva un par de segundos, ao contrario dos moitos minutos ou incluso horas que leva realizar unha operación análoga nun disco sen cifrar e evita o custo dos custosos equipos ou servizos de desmagnetización.
• P 11.2: Como se realiza o borrado seguro?
  A 11.2: Esta é unha operación GUI que se realiza unha unidade á vez.
• P 11.3: Cando se adoita realizar o borrado seguro?
  A 11.3: O borrado seguro iniciado polo usuario dun único disco é unha operación rara. Isto faise principalmente cando quere eliminar fisicamente o disco para substituílo, transferilo a outro nodo ou evitar fallos nun futuro próximo.
• P 11.4: Que restricións hai no borrado seguro?
  A 11.4: As operacións de borrado seguro só se poden realizar se o clúster é saudable para garantir que non se vexa afectada a resistencia aos fallos do clúster.
• P 11.5: Que pasa se teño que eliminar un nodo completo?
  A 11.5: Hai fluxos de traballo de eliminación de nodos e substitución de nodos para admitir o borrado seguro de todas as unidades. Consulte a guía do administrador para obter máis información ou consulte a TAC de Cisco.
• P 11.6: Pódese reutilizar un disco borrado de forma segura?
  A 11.6: Un disco que foi borrado de forma segura só se pode reutilizar nun clúster diferente. O borrado seguro do SED realízase borrando a clave de cifrado do disco (DEK). Os datos do disco non se poden descifrar sen DEK. Isto permítelle reutilizar ou desactivar o disco sen comprometer os datos.
• P 11.7: Que ocorre se o disco que quero borrar contén a última copia principal dos datos do clúster?
  A 11.7: Os datos do disco deberían ter outras copias no clúster para evitar a perda de datos. Non obstante, se se solicita un borrado seguro nun disco que é a última copia principal, entón rexeitarase esta operación ata que haxa polo menos unha copia máis dispoñible. O reequilibrio debería facer esta copia en segundo plano.
• P 11.8: Realmente necesito borrar un disco de forma segura, pero o clúster non é saudable. Como podo facelo?
  A 11.8: A liña de comandos (STCLI/HXCLI) permitirá o borrado seguro cando o clúster non estea saudable e o disco non conteña a última copia principal, se non, non está permitido.
• Q 11.9: Como podo borrar de forma segura un nodo enteiro?
  A 11.9: Este é un escenario raro. O borrado seguro de todos os discos dun nodo faise cando se quere sacar o nodo do clúster. A intención é implantar o nodo nun clúster diferente ou desactivar o nodo. Podemos clasificar a eliminación de nodos neste escenario de dúas formas diferentes:
  1. Borra todos os discos sen desactivar o cifrado
  2. Borrar de forma segura todos os discos seguido de desactivar o cifrado para ese nodo (e discos). Póñase en contacto con Cisco TAC para obter asistencia.

Expansión segura dun clúster

• P 12.1: Con que tipo de nodo podo expandir un clúster cifrado?
  A 12.1: Só se poden engadir nodos capaces de SED a un clúster HX con SED.
• P 12.2: Como se xestiona a expansión coa xestión local de chaves?
  A 12.2: A expansión da chave local é unha operación sen problemas sen necesidade de configuración externa.
• P 12.3: Como se xestiona a expansión coa xestión remota de claves?
  A 12.3: A expansión da clave remota require un paso de bloqueo con certificados/infraestrutura de xestión de claves:
  • Os certificados son necesarios para engadir un novo nodo de forma segura
  • A implementación mostrará unha advertencia cos pasos para continuar, incluíndo unha ligazón para descargar o certificado
  • O usuario segue os pasos para cargar certificados e despois tenta de novo a implantación

Documentos de apoio

Micra:

• https://www.micron.com/about/blogs/2016/may/selfencrypting-drives-understanding-the-strategy-of-security
• https://www.micron.com/~/media/documents/products/technical-marketing-brief/5100_sed_tcg-e_tech_brief.pdf
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2667.pdf
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2382.pdf

FIPS

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

CDETS:

• Proxecto: CSC.nuova Produto: ucs-blade-server Compoñente: ucsm

Especificación funcional SED:

• EDCS: 1574090

Especificación de SED CIMC:

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

Listas de correo:

• ucsm-dev@cisco.com
• ask-hci-tme@cisco.com
• ask-hci-pm@cisco.com

Documentos/Recursos

Plataforma de datos CISCO HyperFlex HX [pdfInstrucións Plataforma de datos HyperFlex HX, HyperFlex, Plataforma de datos HX, Plataforma de datos, Plataforma

Referencias

• Manual de usuario