Istruzioni per la piattaforma dati CISCO HyperFlex HX

Contenuto nascondere

1 Piattaforma dati CISCO HyperFlex HX

2 Informazioni sul prodotto

3 Istruzioni per l'uso del prodotto

4 Domande frequenti sulla crittografia HX Security

5 Documenti di supporto

6 Documenti / Risorse

6.1 Riferimenti

7 Post correlati

Piattaforma dati CISCO HyperFlex HX

Informazioni sul prodotto

Nome del prodotto: Crittografia di sicurezza HX
Versione: HXDP 5.01b

Soluzione di crittografia: Soluzione basata su software che utilizza Intersight Key Manager
Tipo di crittografia: Unità con crittografia automatica (SED)

Tipi di unità supportate: SED HDD e SSD di Micron
Standard di conformità: FIPS 140-2 livello 2 (produttori di unità) e FIPS 140-2 livello 1 (piattaforma)

Crittografia a livello di cluster: La crittografia su HX è implementata nell'hardware per i dati inattivi solo utilizzando SED
Crittografia VM individuale: Gestito da software di terze parti come Hytrust o il client trasparente di Vormetric

Crittografia VM nativa VMware: Supportato da HX per l'utilizzo con la crittografia SED
Gestione delle chiavi: Per ciascun SED vengono utilizzate la chiave di crittografia multimediale (MEK) e la chiave di crittografia chiave (KEK).

Utilizzo della memoria: Le chiavi di crittografia non sono mai presenti nella memoria del nodo
Impatto sulle prestazioni: La crittografia/decrittografia del disco viene gestita nell'hardware dell'unità, le prestazioni complessive del sistema non vengono influenzate

Ulteriori vantaggi dei SED:
- Cancellazione crittografica istantanea per ridurre i costi di ritiro e ridistribuzione delle unità
- Conformità alle normative governative o di settore per la privacy dei dati
- Rischio ridotto di furto del disco e del nodo poiché i dati diventano illeggibili una volta rimosso l'hardware

Istruzioni per l'uso del prodotto

Per utilizzare la crittografia HX Security, seguire queste istruzioni:

Assicurati che il tuo sistema supporti la crittografia basata su hardware o che preferisci la soluzione basata su software utilizzando Intersight Key Manager.

Fare riferimento ai documenti amministrativi o ai white paper per informazioni sulla crittografia basata su software.
Se scegli di utilizzare la crittografia basata su hardware con i SED, assicurati che il tuo cluster HX sia costituito da nodi uniformi (SED o non SED).

Per i SED, tenere presente che esistono due chiavi in uso: Media Encryption Key (MEK) e Key Encryption Key (KEK).
Il MEK controlla la crittografia e la decrittografia dei dati sul disco ed è protetto e gestito tramite hardware.

La KEK protegge la MEK/DEK e viene mantenuta in un archivio chiavi locale o remoto.
Non preoccuparti che le chiavi siano presenti nella memoria del nodo, poiché le chiavi di crittografia non vengono mai archiviate lì.

Tieni presente che la crittografia/decrittografia del disco viene gestita nell'hardware dell'unità, garantendo che le prestazioni complessive del sistema non vengano influenzate.
Se hai requisiti specifici per gli standard di conformità, tieni presente che le unità crittografate HX SED soddisfano gli standard FIPS 140-2 livello 2 dei produttori di unità, mentre la crittografia HX sulla piattaforma soddisfa gli standard FIPS 140-2 livello 1.

Se hai bisogno di crittografare singole VM, prendi in considerazione l'utilizzo di software di terze parti come Hytrust o il client trasparente di Vormetric. In alternativa, è possibile utilizzare la crittografia nativa delle VM di VMware introdotta in vSphere 3.
Tieni presente che l'utilizzo di un client di crittografia VM oltre alla crittografia basata su HX SED comporterà una doppia crittografia dei dati.

Assicurati che il tuo cluster HX sia connesso tramite reti attendibili o tunnel crittografati per una replica sicura, poiché la replica HX non è crittografata.

Domande frequenti sulla crittografia HX Security

A partire da HXDP 5.01b, HyperFlex offre una soluzione basata su software utilizzando Intersight Key Manager per sistemi che non supportano la crittografia basata su hardware o per utenti che desiderano questa funzionalità rispetto a soluzioni hardware. Queste domande frequenti si concentrano solo sulle soluzioni hardware basate su SED per la crittografia HX. Consulta i documenti amministrativi o i whitepaper per informazioni sulla crittografia basata su software.

Dichiarazione di parzialità
Il set di documentazione per questo prodotto si sforza di utilizzare un linguaggio privo di pregiudizi. Ai fini di questo set di documentazione, privo di pregiudizi è definito come linguaggio che non implica discriminazione basata su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, stato socioeconomico e intersezionalità. Possono essere presenti eccezioni nella documentazione a causa del linguaggio hardcoded nelle interfacce utente del software del prodotto, del linguaggio utilizzato in base alla documentazione degli standard o del linguaggio utilizzato da un prodotto di terze parti a cui si fa riferimento.

Perché Cisco per la sicurezza e la crittografia HX

Q 1.1: Quali processi sono in atto per uno sviluppo sicuro?
Un 1.1: I server Cisco aderiscono al Cisco Secure Development Lifecycle (CSDL):
- Cisco fornisce processi, metodologie e framework per sviluppare sicurezza integrata sui server Cisco, non solo un overlay
- Team Cisco dedicato per la modellazione delle minacce/analisi statica sul portafoglio di prodotti UCS
- Cisco Advanced Security Initiative Group (ASIG) esegue test di penetrazione proattivi per comprendere come arrivano le minacce e risolvere i problemi migliorando HW e SW tramite CDETS e ingegneria
- Team Cisco dedicato per testare e gestire la vulnerabilità in uscita e comunicare come consulenti di sicurezza con i clienti
- Tutti i prodotti sottostanti sono sottoposti ai requisiti di base di sicurezza del prodotto (PSB) che regolano gli standard di sicurezza per i prodotti Cisco
- Cisco esegue test di vulnerabilità/robustezza del protocollo su tutte le versioni di UCS
Q 1.2: Perché i SED sono importanti?
Un 1.2: I SED vengono utilizzati per la crittografia dei dati inattivi e sono un requisito per molte, se non tutte, le istituzioni federali, mediche e finanziarie.

Informazioni generali finitaview

Q 2.1: Cosa sono i SED?
Un 2.1: Le unità SED (Self-Encrypting Drives) dispongono di hardware speciale che crittografa i dati in ingresso e decrittografa i dati in uscita in tempo reale.
Q 2.2: Qual è l'ambito della crittografia su HX?
Un 2.2: La crittografia su HX è attualmente implementata nell'hardware per i dati inattivi solo utilizzando unità crittografate (SED). La crittografia HX è a livello di cluster. La crittografia delle singole VM è gestita da software di terze parti come Hytrust o il client trasparente di Vormetric e non rientra nell'ambito delle responsabilità di HX. HX supporta inoltre l'utilizzo della crittografia nativa delle VM di VMware introdotta in vSphere 3. L'uso di un client di crittografia VM sopra la crittografia basata su HX SED comporterà una doppia crittografia dei dati. La replica HX non è crittografata e si basa su reti affidabili o tunnel crittografati distribuiti dall'utente finale.
Q 2.3: Quali standard di conformità sono soddisfatti con la crittografia HX?
Un 2.3: Le unità crittografate HX SED soddisfano gli standard FIPS 140-2 livello 2 dei produttori di unità. La crittografia HX sulla piattaforma soddisfa gli standard FIPS 140-2 livello 1.
Q 2.4: Supportiamo sia HDD che SSD per la crittografia?
Un 2.4: Sì, supportiamo sia i SED HDD che quelli SSD di Micron.
Q 2.5: Un cluster HX può avere unità crittografate e non crittografate allo stesso tempo?
Un 2.5: Tutti i nodi nel cluster devono essere uniformi (SED o non SED)
Q 2.6: Quali chiavi sono in uso per un SED e come vengono utilizzate?
Un 2.6: Sono disponibili due chiavi per ciascun SED. La chiave di crittografia multimediale (MEK), chiamata anche chiave di crittografia del disco (DEK), controlla la crittografia e la decrittografia dei dati sul disco ed è protetta e gestita tramite hardware. La chiave di crittografia della chiave (KEK) protegge la DEK/MEK e viene mantenuta in un archivio di chiavi locale o remoto.

Q 2.7: Le chiavi sono sempre presenti in memoria?
Un 2.7: Le chiavi di crittografia non sono mai presenti nella memoria del nodo
Q 2.8: In che modo le prestazioni vengono influenzate dal processo di crittografia/decrittografia?
Un 2.8: La crittografia/decrittografia del disco viene gestita nell'hardware dell'unità. Le prestazioni complessive del sistema non vengono influenzate e non sono soggette ad attacchi mirati ad altri componenti del sistema
D 2.9: Oltre alla crittografia dei dati inattivi, quali sono gli altri motivi per utilizzare i SED?
Un 2.9: I SED possono ridurre i costi di pensionamento e ridistribuzione attraverso la cancellazione crittografica istantanea. Servono anche per conformarsi alle normative governative o di settore in materia di privacy dei dati. Un altro vantaggiotage è il minor rischio di furto di dischi e di nodi poiché i dati, una volta rimosso l'hardware dall'ecosistema, risultano illeggibili.

Q2.10: Cosa succede con la deduplica e la compressione con i SED? Cosa succede con la crittografia basata su software di terze parti?
A2.10: La deduplicazione e la compressione con i SED su HX vengono mantenute poiché la crittografia dei dati inattivi avviene come ultimo passaggio nel processo di scrittura. La deduplicazione e la compressione sono già state eseguite. Con prodotti di crittografia basati su software di terze parti, le VM gestiscono la propria crittografia e trasmettono scritture crittografate all'hypervisor e successivamente all'HX. Poiché queste scritture sono già crittografate, non vengono deduplicate o compresse. HX Software Based Encryption (nella codeline 3.x) sarà una soluzione di crittografia software implementata nello stack dopo che si sono verificate le ottimizzazioni di scrittura (deduplicazione e compressione), pertanto in tal caso il vantaggio verrà mantenuto.

La figura seguente è un overview dell’implementazione del SED con HX.

Dettagli dell'unità

Q 3.1: Chi produce le unità crittografate utilizzate in HX?
Un 3.1: HX utilizza unità prodotte da Micron: i documenti specifici di Micron sono collegati nella sezione dei documenti di supporto di queste domande frequenti.
Q 3.2: Supportiamo SED che non sono conformi a FIPS?
Un 3.2: Supportiamo anche alcune unità non FIPS, ma che supportano SED (TCGE).
Q 3.3: Cos'è il GCC?
Un 3.3: TCG è il Trusted Computing Group, che crea e gestisce le specifiche standard per l'archiviazione dei dati crittografati

D 3.4: Cosa viene considerato sicurezza di livello aziendale quando si tratta di SSD SAS per data center? Quali caratteristiche specifiche hanno queste unità che garantiscono sicurezza e proteggono dagli attacchi?
Un 3.4: Questo elenco riepiloga le funzionalità di livello aziendale dei SED utilizzati in HX e il modo in cui si collegano allo standard TCG.
1. Le unità con crittografia automatica (SED) forniscono una solida sicurezza per i dati archiviati sul SED, impedendo l'accesso non autorizzato ai dati. Il Trusted Computing Group (TCG) ha sviluppato un elenco delle caratteristiche e dei vantaggi delle unità con crittografia automatica sia per HDD che per SSD. Il TCG fornisce uno standard chiamato TCG Enterprise SSC (Security Subsystem Class) e si concentra sui dati inattivi. Questo è un requisito per tutti i SED. La specifica si applica ai dispositivi di archiviazione dati e ai controller che operano nello spazio di archiviazione aziendale. L'elenco include:
  - Trasparenza: Non sono necessarie modifiche al sistema o all'applicazione; chiave di crittografia generata dall'unità stessa, utilizzando un vero generatore di numeri casuali integrato; l'unità è sempre crittografata.
  - Facilità di gestione: Nessuna chiave di crittografia da gestire; i fornitori di software sfruttano un'interfaccia standardizzata per gestire i SED, inclusa la gestione remota, l'autenticazione pre-avvio e il ripristino della password
  - Costo di smaltimento o riutilizzo: Con un SED, cancella la chiave di crittografia integrata
  - Ricrittografia: Con SED non è necessario crittografare nuovamente i dati
  - Prestazione: Nessun degrado nelle prestazioni del SED; basato sull'hardware
  - Standardizzazione: L'intero settore degli azionamenti si sta adeguando alle specifiche TCG/SED
  - Semplificato: Nessuna interferenza con i processi a monte
2. I SED SSD forniscono la possibilità di cancellare crittograficamente l'unità. Ciò significa che è possibile inviare un semplice comando autenticato all'unità per modificare la chiave di crittografia a 256 bit memorizzata sull'unità. Ciò garantisce che l'unità venga cancellata e che non rimangano dati. Anche il sistema host originale non può leggere i dati, quindi saranno assolutamente illeggibili da qualsiasi altro sistema. L'operazione richiede solo un paio di secondi, a differenza dei molti minuti o addirittura ore necessari per eseguire un'operazione analoga su un HDD non crittografato ed evita il costo di costose apparecchiature o servizi di smagnetizzazione dell'HDD.
3. FIPS (Federal Information Processing Standard) 140-2 è uno standard del governo statunitense che descrive la crittografia e i relativi requisiti di sicurezza che i prodotti IT devono soddisfare per un utilizzo sensibile, ma non classificato. Questo è spesso un requisito anche per le agenzie governative e le aziende dei servizi finanziari e del settore sanitario. Un SSD convalidato FIPS-140-2 utilizza solide pratiche di sicurezza inclusi algoritmi di crittografia approvati. Specifica inoltre come gli individui o altri processi devono essere autorizzati per utilizzare il prodotto e come i moduli o i componenti devono essere progettati per interagire in modo sicuro con altri sistemi. In effetti, uno dei requisiti di un'unità SSD convalidata FIPS-140-2 è che sia un SED. Tieni presente che, sebbene TCG non sia l'unico modo per ottenere un'unità crittografata certificata, le specifiche TCG Opal e Enterprise SSC forniscono un trampolino di lancio verso la convalida FIPS. 4. Un'altra caratteristica essenziale sono i download e la diagnostica sicuri. Questa funzionalità del firmware protegge l'unità dagli attacchi software tramite una firma digitale integrata nel firmware. Quando sono necessari download, la firma digitale impedisce l'accesso non autorizzato all'unità, impedendo il caricamento di firmware contraffatto sull'unità.

Installazione Hyperflex con SED

Q 4.1: In che modo il programma di installazione gestisce una distribuzione SED? Ci sono controlli particolari?
Un 4.1: Il programma di installazione comunica con UCSM e garantisce che il firmware del sistema sia corretto e supportato per l'hardware rilevato. La compatibilità della crittografia viene verificata e applicata (ad esempio, nessuna combinazione di SED e non SED).
Q 4.2: Altrimenti la distribuzione è diversa?
Un 4.2: L'installazione è simile a una normale installazione HX, tuttavia, il flusso di lavoro personalizzato non è supportato per i SED. Questa operazione richiede le credenziali UCSM anche per i SED.
Q 4.3: Come funziona la licenza con la crittografia? C'è qualcosa in più che deve essere a posto?
Un 4.3: L'hardware SED (ordinato dalla fabbrica, non adattato) + HXDP 2.5 + UCSM (3.1(3x)) sono le uniche cose necessarie per abilitare la crittografia con la gestione delle chiavi. Nella versione 2.5 non sono richieste licenze aggiuntive oltre all'abbonamento HXDP di base.

Q 4.4: Cosa succede quando ho un sistema SED con unità che non sono più disponibili? Come posso espandere questo cluster?
Un 4.4: Ogni volta che riceviamo un PID a fine vita dai nostri fornitori, disponiamo di un PID sostitutivo compatibile con il vecchio PID. Questo PID sostitutivo può essere utilizzato per RMA, espansione all'interno di un nodo ed espansione del cluster (con nuovi nodi). Tutti i metodi sono supportati, tuttavia potrebbero richiedere l'aggiornamento a una versione specifica identificata anche nelle note sulla versione di transizione.

Gestione delle chiavi

Q 5.1: Cos'è la gestione delle chiavi?
Un 5.1: La gestione delle chiavi comprende le attività legate alla protezione, all'archiviazione, al backup e all'organizzazione delle chiavi di crittografia. HX lo implementa in una politica incentrata sull'UCSM.

Q 5.2: Quale meccanismo fornisce il supporto per la configurazione delle chiavi?
Un 5.2: UCSM fornisce supporto per configurare le chiavi di sicurezza.
Q 5.3: Che tipo di gestione delle chiavi è disponibile?
Un 5.3: È supportata la gestione locale delle chiavi, insieme alla gestione remota delle chiavi di livello aziendale con server di gestione delle chiavi di terze parti.
Q 5.4: Chi sono i partner per la gestione remota delle chiavi?
Un 5.4: Attualmente supportiamo Vormetric e Gemalto (Safenet) e include l'alta disponibilità (HA). HyTrust è in fase di test.

Q 5.5: Come viene implementata la gestione delle chiavi remote?
Un 5.5: La gestione delle chiavi remote viene gestita tramite KMIP 1.1.
Q 5.6: Come è configurata la gestione locale?
Un 5.6: La chiave di sicurezza (KEK) è configurata in HX Connect, direttamente dall'utente.
Q 5.7: Come è configurata la gestione remota?
Un 5.7: Le informazioni sull'indirizzo del server di gestione delle chiavi remote (KMIP) insieme alle credenziali di accesso vengono configurate in HX Connect dall'utente.

Q 5.8: Quale parte di HX comunica con il server KMIP per la configurazione?
Un 5.8: Il CIMC su ciascun nodo utilizza queste informazioni per connettersi al server KMIP e recuperare da esso la chiave di sicurezza (KEK).
D 5.9: Quali tipi di certificati sono supportati nel processo di generazione/recupero/aggiornamento delle chiavi?
Un 5.9: Sono supportati sia i certificati firmati dalla CA che quelli autofirmati.
Q 5.10: Quali flussi di lavoro sono supportati con il processo di crittografia?
Un 5.10: È supportata la protezione/sprotezione mediante una password personalizzata insieme alla conversione della gestione delle chiavi da locale a remota. Sono supportate le operazioni di re-key. Sono supportate anche le operazioni di cancellazione sicura del disco.

Flusso di lavoro utente: locale

Q 6.1: In HX Connect, dove configuro la gestione delle chiavi locali?
Un 6.1: Nel dashboard di crittografia seleziona il pulsante di configurazione e segui la procedura guidata.
Q 6.2: Cosa devo avere a portata di mano per iniziare?
Un 6.2: Dovrai fornire una passphrase di sicurezza di 32 caratteri.

Q 6.3: Cosa succede se devo inserire un nuovo SED?
Un 6.3: In UCSM sarà necessario modificare la politica di sicurezza locale e impostare la chiave distribuita sulla chiave del nodo esistente.
Domanda 6.4: Cosa succede quando inserisco il nuovo disco?
Un 6.4: Se la chiave di sicurezza sul disco corrisponde a quella del server (nodo), verrà automaticamente sbloccato. Se le chiavi di sicurezza sono diverse, il disco verrà visualizzato come "Bloccato". Puoi cancellare il disco per eliminare tutti i dati o sbloccarlo fornendo la chiave corretta. Questo è un buon momento per coinvolgere il TAC.

Flusso di lavoro utente: remoto

Q 7.1: Quali sono alcune cose a cui devo prestare attenzione durante la configurazione della gestione delle chiavi remote?
Un 7.1: La comunicazione tra il cluster e i server KMIP avviene tramite CIMC su ciascun nodo. Ciò significa che il nome host può essere utilizzato per il server KMIP solo se l'indirizzo IP Inband e il DNS sono configurati nella gestione CIMC
Q 7.2: Cosa succede se devo sostituire o inserire un nuovo SED?
Un 7.2: Il cluster leggerà l'identificatore dal disco e tenterà di sbloccarlo automaticamente. Se lo sblocco automatico fallisce, il disco risulta "bloccato" e l'utente deve sbloccarlo manualmente. Dovrai copiare i certificati sui server KMIP per lo scambio di credenziali.
Q 7.3: Come posso copiare i certificati dal cluster ai server KMIP?
Un 7.3: Ci sono due modi per farlo. È possibile copiare il certificato dal BMC direttamente al server KMIP oppure utilizzare la CSR per ottenere un certificato firmato dalla CA e copiare il certificato firmato dalla CA sul BMC utilizzando i comandi UCSM.

Q 7.4: Quali considerazioni ci sono per l'aggiunta di nodi crittografati a un cluster che utilizza la gestione delle chiavi remote?
Un 7.4: Quando si aggiungono nuovi host ai server KMIP, il nome host utilizzato deve essere il numero di serie del server. Per ottenere il certificato del server KMIP, è possibile utilizzare un browser per ottenere il certificato radice dei server KMIP.

Flusso di lavoro utente: Generale

Q 8.1: Come posso cancellare un disco?
Un 8.1: Nella dashboard di HX Connect, seleziona le informazioni di sistema view. Da lì puoi selezionare singoli dischi per la cancellazione sicura.

Q 8.2: Cosa succede se cancello un disco per sbaglio?
Un 8.2: Quando viene utilizzata la cancellazione sicura, i dati vengono distrutti in modo permanente
Q 8.3: Cosa succede quando voglio disattivare un nodo o dissociare un professionista del serviziofile?
Un 8.3: Nessuna di queste azioni rimuoverà la crittografia sul disco/controller.
Q 8.4: Come viene disabilitata la crittografia?
Un 8.4: L'utente deve disabilitare esplicitamente la crittografia in HX Connect. Se l'utente tenta di eliminare una policy di sicurezza in UCSM quando il server associato è stato protetto, UCSM visualizzerà un errore di configurazione e non consentirà l'azione. La politica di sicurezza deve essere prima disabilitata.

Flusso di lavoro utente: gestione dei certificati

Q 9.1: Come vengono gestiti i certificati durante la configurazione della gestione remota?
Un 9.1: I certificati vengono creati utilizzando HX Connect e i server KMIP remoti. I certificati una volta creati non verranno quasi mai eliminati.
Q 9.2: Che tipo di certificati posso utilizzare?
Un 9.2: È possibile utilizzare certificati autofirmati o certificati CA. Devi scegliere durante la configurazione. Per i certificati firmati dalla CA genererai una serie di richieste di firma del certificato (CSR). I certificati firmati vengono caricati sui server KMIP.

Q 9.3: Quale nome host dovrei utilizzare durante la generazione dei certificati?
Un 9.3: Il nome host utilizzato per generare il certificato dovrebbe essere il numero di serie del server.

Aggiornamenti del firmware

Q 10.1: Esistono restrizioni sull'aggiornamento del firmware del disco?
Un 10.1: Se viene rilevata un'unità con funzionalità di crittografia, qualsiasi modifica al firmware del disco non sarà consentita per quel disco.

Q 10.2: Esistono restrizioni sull'aggiornamento del firmware UCSM?
Un 10.2: Il downgrade di UCSM/CIMC a versione precedente a UCSM 3.1(3x) è limitato se è presente un controller in stato protetto.

Dettagli di cancellazione sicura

Q 11.1: Cos'è la cancellazione sicura?
Un 11.1: La cancellazione sicura è la cancellazione istantanea dei dati sull'unità (cancellazione della chiave di crittografia del disco). Ciò significa che è possibile inviare un semplice comando autenticato all'unità per modificare la chiave di crittografia a 256 bit memorizzata sull'unità. Ciò garantisce che l'unità venga cancellata e che non rimangano dati. Anche il sistema host originale non può leggere i dati, quindi saranno illeggibili da qualsiasi altro sistema. L'operazione richiede solo un paio di secondi, a differenza dei molti minuti o addirittura ore necessari per eseguire un'operazione analoga su un disco non crittografato ed evita il costo di costose apparecchiature o servizi di smagnetizzazione.

Q 11.2: Come viene eseguita la cancellazione sicura?
Un 11.2: Questa è un'operazione GUI che viene eseguita un'unità alla volta.
D 11.3: Quando viene solitamente eseguita la cancellazione sicura?
Un 11.3: La cancellazione sicura di un singolo disco avviata dall'utente è un'operazione rara. Questa operazione viene eseguita principalmente quando si desidera rimuovere fisicamente il disco per la sostituzione, trasferirlo su un altro nodo o evitare guasti nel prossimo futuro.
Q 11.4: Quali restrizioni sono previste per la cancellazione sicura?
Un 11.4: Le operazioni di cancellazione sicura possono essere eseguite solo se il cluster è integro per garantire che la resilienza agli errori del cluster non venga influenzata.

Q 11.5: Cosa succede se devo rimuovere un intero nodo?
Un 11.5: Sono disponibili flussi di lavoro di rimozione e sostituzione dei nodi per supportare la cancellazione sicura di tutte le unità. Consulta la guida dell'amministratore per i dettagli o consulta il TAC Cisco.
Q 11.6: È possibile riutilizzare un disco cancellato in modo sicuro?
Un 11.6: Un disco che è stato cancellato in modo sicuro può essere riutilizzato solo in un cluster diverso. La cancellazione sicura del SED viene eseguita cancellando la chiave di crittografia del disco (DEK). I dati nel disco non possono essere decrittografati senza DEK. Ciò consente di riutilizzare o disattivare il disco senza compromettere i dati.
D 11.7: Cosa succede se il disco che desidero cancellare contiene l'ultima copia primaria dei dati del cluster?
Un 11.7: I dati sul disco dovrebbero avere altre copie nel cluster per evitare la perdita di dati. Tuttavia, se viene richiesta la cancellazione sicura su un disco che è l'ultima copia primaria, l'operazione verrà rifiutata finché non sarà disponibile almeno un'altra copia. Rebalance dovrebbe eseguire questa copia in background.

Q 11.8: Ho davvero bisogno di cancellare in modo sicuro un disco, ma il cluster non è integro. Come posso farlo?
Un 11.8: La riga di comando (STCLI/HXCLI) consentirà la cancellazione sicura quando il cluster non è integro e il disco non contiene l'ultima copia primaria, altrimenti non è consentita.
Domanda 11.9: Come posso cancellare in modo sicuro un intero nodo?
Un 11.9: Questo è uno scenario raro. La cancellazione sicura di tutti i dischi in un nodo viene eseguita quando si desidera eliminare il nodo dal cluster. L'intenzione è quella di distribuire il nodo in un cluster diverso o di smantellare il nodo. Possiamo classificare la rimozione dei nodi in questo scenario in due modi diversi:
1. Cancellazione sicura di tutti i dischi senza disabilitare la crittografia
2. Cancellazione sicura di tutti i dischi seguita dalla disabilitazione della crittografia per quel nodo (e dischi). Contattare il TAC Cisco per assistenza.

Espansione sicura di un cluster

Q 12.1: Con che tipo di nodo posso espandere un cluster crittografato?
Un 12.1: Solo i nodi compatibili con SED possono essere aggiunti a un cluster HX con SED.

D 12.2: Come viene gestita l'espansione con la gestione delle chiavi locali?
Un 12.2: L'espansione della chiave locale è un'operazione senza interruzioni che non richiede alcuna configurazione esterna.
D 12.3: Come viene gestita l'espansione con la gestione remota delle chiavi?
Un 12.3: L'espansione della chiave remota richiede il passo con l'infrastruttura di gestione dei certificati/chiavi:
- I certificati sono necessari per aggiungere un nuovo nodo in modo sicuro
- La distribuzione mostrerà un avviso con i passaggi da procedere, incluso un collegamento per il download del certificato
- L'utente segue i passaggi per caricare i certificati e quindi ritenta la distribuzione