Dell EMC Data Domain Encryption: domande frequenti

Configurazione della crittografia

Domanda. Come viene configurata la crittografia (DARE) in DD?
Risposta: La crittografia DARE può essere configurata in DD tramite la seguente procedura:

1. Aggiunta di una licenza di crittografia

2. Aggiunta di un funzionario di sicurezza e abilitazione delle autorizzazioni dei funzionari di sicurezza

3. Abilitare la crittografia 

1) Aggiungere una licenza di crittografia:
aggiungere un file di licenza con una licenza di crittografia valida.
Utilizzare il comando riportato di seguito per aggiornare l'eLicense in DD utilizzando il file di licenza disponibile.

Aggiornamento eLicense

2) Aggiungere il Security Officer e abilitare le autorizzazioni SO:
a) Aggiungere un utente con un ruolo come "security" utilizzando il comando: 

Sicurezza del ruolo utente add secuser

b) Abilitare l'autorizzazione del funzionario di sicurezza nell'installazione utilizzando il comando: 

Policy di autorizzazione impostata Security-Officer Enabled.

3. Abilitare la crittografia DARE:
Abilitare la crittografia DARE utilizzando il comando:

Abilitazione crittografia file

Domanda. Quali piattaforme sono supportate con la funzionalità di crittografia dei dati inattivi?
Risposta: La funzionalità di crittografia dei dati inattivi è supportata su tutti i sistemi Data Domain, ad eccezione dei sistemi EDP (Encryption Disablement Project).

Domanda: In che modo l'utente può archiviare i propri dati in testo non crittografato in DD?
Risposta: L'utente può assicurarsi che i dati vengano salvati in testo non crittografato e non crittografati in DD, confermando che la crittografia è disattivata nella configurazione.
Gli utenti possono disabilitare la crittografia in DD utilizzando il comando: 

Disabilitazione crittografia file

Domanda. Quali applicazioni/protocolli di backup sono supportati con la funzionalità di crittografia dei dati inattivi?
Risposta: La funzione DD DARE è indipendente dall'applicazione di backup sottostante o dal protocollo utilizzato da DD.

Domanda: Quali algoritmi di crittografia possono essere selezionati sul sistema Data Domain?
Risposta: Il software DD Encryption supporta l'algoritmo AES a 128 o 256 bit utilizzando Cipher Block Chaining (CBC) o Galois Counter Mode (GCM). 

GCM è una modalità operativa per i cifrari a blocchi crittografici a chiave simmetrica. Si tratta di un algoritmo di crittografia autenticato progettato per fornire sia l'autenticazione che la privacy (riservatezza). Come suggerisce il nome, GCM combina la nota modalità di crittografia del contatore con la nuova modalità di autenticazione Galois. L'aspetto autenticatorio di GCM garantisce che i dati crittografati siano stati crittografati dal sistema Data Domain e non siano stati "inseriti" con altri mezzi. Ciò differisce dal CBC in cui i dati sono crittografati (aspetto della privacy), ma non è possibile verificare l'autenticità dei dati crittografati.

In modalità CBC, ogni blocco di testo normale viene applicato esclusivamente con l'operatore OR con il blocco di testo cifrato precedente prima di essere crittografato. In questo modo, ogni blocco di testo cifrato dipende da tutti i blocchi di testo normale elaborati fino a quel momento. Inoltre, per rendere univoco ogni messaggio, è necessario utilizzare un vettore di inizializzazione nel primo blocco. CBC garantisce la privacy (riservatezza) dei dati solo attraverso la crittografia. Non viene eseguita alcuna autenticazione dell'algoritmo o del processo di crittografia.

Domanda: Come è possibile modificare l'algoritmo di crittografia nel DD?

Risposta. Utilizzare il comando riportato di seguito se si desidera impostare un algoritmo di crittografia specifico nell'installazione.

Impostazione dell'algoritmo di crittografia Filesys

Esempio:

# filesys algoritmo di crittografia impostato {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Domanda. Come possiamo garantire che la crittografia venga eseguita su dati preesistenti una volta abilitata?
Risposta: È possibile forzare DDFS a crittografare i dati preesistenti utilizzando il seguente comando:

# filesys encryption apply-changes

In questo modo, il ciclo di pulizia successivo è considerevolmente più lungo e dispendioso in termini di risorse del normale.

Domanda: Come si disattiva la crittografia in DD?
Risposta: Disabilitare la funzione di crittografia in DD utilizzando il comando encryption disable: 

Disabilitazione crittografia file

In questo modo viene disabilitata solo la crittografia per l'I/O in ingresso. I dati crittografati esistenti rimangono crittografati fino a quando non vengono decrittografati manualmente utilizzando apply-changes.

Domanda: Quali comandi di crittografia richiedono il riavvio del file system DD per avere effetto?
Risposta: Per avere effetto, i seguenti comandi di crittografia richiedono il riavvio del file system DD:

Attivazione/disattivazione crittografia File - Abilita/disabilita la crittografia sul sistema Data Domain.

Set di algoritmi di crittografia Filesys - Consente all'utente di selezionare un algoritmo crittografico.

Ripristino dell'algoritmo di crittografia File Sysys - Reimposta l'algoritmo di crittografia su AES 256 in modalità CBC (impostazione predefinita).

Domanda: Quali comandi di crittografia richiedono la disabilitazione del file system di Data Domain per poterli impostare/utilizzare?
Risposta: I seguenti comandi di crittografia richiedono la disabilitazione del file system di Data Domain per poterli impostare o utilizzare:

Modifica della passphrase di crittografia

Blocco/sblocco crittografia

Domande generali sulla crittografia

Domanda. DD Encryption è supportato su tutti i sistemi
DD?Risposta: L'opzione software DD Encryption è supportata sui sistemi DD se non si tratta di un progetto EDP (Encryption Disablement Project), ovvero se i sistemi non consentono l'abilitazione della crittografia, venduti principalmente nei sistemi della regione della Russia.

Domanda: Come viene eseguita la crittografia nei sistemi DD?
Risposta: La crittografia viene eseguita utilizzando le librerie OpenSSL e RSA BSafe (RSA BSafe è la libreria di crittografia convalidata FIPS 140-2 utilizzata dai sistemi DD per crittografare i dati inattivi) in DDOS. 

Domanda. Quale versione di BSafe viene utilizzata con il sistema?
Risposta: A partire da DDOS 7.10, le versioni BSafe utilizzate sono "BSAFE Micro Edition Suite 4.4.0.0" e "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Domanda: Quali sono le interfacce utente disponibili per configurare la crittografia in DDOS?
Risposta: La crittografia può essere configurata tramite CLI, interfaccia utente o API REST. API REST supportata, aggiunta in DDOS 8.0 e versioni successive.

Domanda: È possibile una crittografia selettiva dei dati? Ti piace un solo MTree o un unico file?
Risposta: La crittografia selettiva NON è possibile. La crittografia può essere abilitata o disabilitata solo a livello di sistema e non in modo selettivo. Per i sistemi con supporto cloud, la crittografia può essere abilitata o disabilitata a livello di granularità a livello di cloud tier e unità cloud.  

Domanda. Le chiavi di crittografia o le password degli account vengono trasmesse o archiviate in testo non crittografato o in modalità crittografiche deboli, ad esempio quando un'entità esegue l'autenticazione, in un file di dati, in programmi o directory di autenticazione?
Risposta: Assolutamente no.

Domanda: Quale versione di OpenSSL viene utilizzata con il sistema?
Risposta: A partire dalla versione DDOS 7.10, la versione openssl è "OpenSSL 1.0.2zd-fips".

In che modo la crittografia dei dati inattivi protegge dall'accesso ai dati da parte di utenti e applicazioni?
Risposta: 

• La crittografia dei dati inattivi consiste nel crittografare i dati che risiedono nel sottosistema del disco. La crittografia o la decrittografia avviene a livello di compressione. Gli utenti o le applicazioni inviano e ricevono dati in testo non crittografato al sistema Data Domain, ma tutti i dati che risiedono fisicamente sul sistema Data Domain sono crittografati.
• Tutta la crittografia viene eseguita al di sotto del file system e del namespace ed è invisibile agli utenti o alle applicazioni. Se un utente o un'applicazione dispone già dell'accesso autorizzato a un file o a una directory, i dati possono essere letti nel loro formato nativo indipendentemente dalla crittografia.
• DD Encryption è progettato in modo tale che, se un intruso elude altri controlli di sicurezza della rete e ottiene l'accesso a dati crittografati, senza le chiavi di crittografia appropriate, i dati sono illeggibili e inutilizzabili per quella persona. 

Domanda. La crittografia verrà eseguita dopo la deduplica?
Risposta: Sì, la crittografia avviene sui dati deduplicati. I dati vengono crittografati prima di essere archiviati sul disco. 

Domanda. In che modo Data Domain garantisce la sicurezza dei dati?
Risposta: I dati sono protetti utilizzando la funzione di crittografia dei dati inattivi. Inoltre, quando il dispositivo viene rimosso (head-swap, blocco del file system), la passphrase viene rimossa dal sistema. Questa passphrase viene utilizzata per crittografare le chiavi di crittografia, in modo che i dati siano ulteriormente protetti.

Domanda: Quali avvisi vengono generati con la crittografia?
Risposta: Gli avvisi vengono generati nei seguenti casi:

• In presenza di chiavi di crittografia compromesse, sono presenti
• Quando la tabella delle chiavi di crittografia è piena e non è possibile aggiungere altre chiavi nel sistema
• Quando l'esportazione automatica delle chiavi non riesce
• Quando la rotazione automatica delle chiavi non riesce
• Quando la crittografia è disabilitata
• Quando la passphrase di sistema è cambiata

Domanda. Esiste una certificazione di sicurezza per DDOS? 
Risposta. I sistemi Data Domain soddisfano la conformità FIPS 140-2. 

Domanda. Dove viene archiviata la chiave di crittografia?
Risposta: Le chiavi di crittografia vengono archiviate in modo persistente in una partizione di raccolta nel sistema DDOS.

Domanda: Se qualcuno estrae un disco rigido da un sistema Data Domain, è possibile decrittografare i dati da esso?
Risposta: Le chiavi di crittografia vengono crittografate utilizzando la passphrase di sistema archiviata nell'intestazione del sistema. Anche se le chiavi di crittografia sono archiviate nel disco, senza passphrase di sistema, le chiavi di crittografia non possono essere decrittografate. Quindi, senza conoscere la chiave utilizzata per crittografare i dati, la decrittografia non è possibile da un disco rigido.  

Domanda. Quali chiavi crittografiche e password sono necessarie per il ripristino, in particolare per il ripristino di emergenza?
Risposta: Le chiavi possono essere esportate in un file protetto e mantenute esterne al sistema. Il recupero di questo file viene eseguito con l'aiuto di un tecnico. Inoltre, al momento del ripristino, il cliente deve conoscere la passphrase utilizzata al momento del comando di esportazione delle chiavi.

Domanda: Come bloccare il file system prima del transito del sistema in una posizione remota.
Risposta: Di seguito è riportata la procedura per questo: 

• Disabilitare il file system:

  sysadmin@itrdc-DD630-42# filesys disabilitato

• Bloccare il file system e immettere una nuova passphrase (ciò richiede l'autenticazione da parte dell'utente di sicurezza di cui sopra):

  sysadmin@itrdc-DD630-42# blocco
  crittografia filesys Questo comando richiede l'autorizzazione da parte di un utente avente un ruolo "security".
  Di seguito è riportata la credenziale di tale utente.
          Nome utente: secuser
  Password:
  Immettere la passphrase corrente:
  Immettere la nuova passphrase:
  Immettere nuovamente la nuova passphrase:
  Passphrase corrispondenti.
  Il file system è ora bloccato.

• La nuova passphrase NON deve essere persa o dimenticata. Senza questa passphrase, il file system non può essere sbloccato, il che significa che non è possibile accedere ai dati sul DDR. Per sbloccare il sistema quando raggiunge una posizione remota, utilizzare il comando seguente:

sysadmin@itrdc-DD630-42# filesys encryption unlock
Questo comando richiede l'autorizzazione da parte di un utente avente un ruolo "security".
Di seguito è riportata la credenziale di tale utente.
        Nome utente: secuser
Password:
Immettere la passphrase:
La passphrase è stata verificata. Utilizzare 'filesys enable' per avviare il file system.

• Il file system può ora essere abilitato e utilizzato normalmente

Domanda. Il comando storage sanitize ha qualche relazione con la crittografia del file system?
Risposta: No, la crittografia del file system e la sanificazione dello storage sono due funzionalità indipendenti. 

Domanda. La crittografia via cavo è supportata nel sistema EDP (Encryption Disablement Project)?
Risposta: Non è possibile abilitare Data at Rest Encryption (DARE) o la crittografia via cavo (con replica o con ddboost) nel sistema EDP.

System Passphrase 

Domanda. Che cos è la passphrase di sistema?
Risposta: DDOS consente di proteggere le credenziali all'interno del sistema impostando una passphrase a livello di sistema. La passphrase è una chiave leggibile dall'uomo (comprensibile), come una smart card, che viene utilizzata per generare una chiave di crittografia AES 256 utilizzabile dal computer. 

Offre due vantaggi:

• Consente all'amministratore di modificare la passphrase senza dover manipolare le chiavi di crittografia. La modifica della passphrase modifica indirettamente la crittografia delle chiavi, ma non influisce sui dati dell'utente. La modifica della passphrase non modifica la chiave di crittografia del sistema Data Domain sottostante. Modifica la crittografia della chiave di sistema Data Domain, ma la chiave di sistema rimane invariata.
• Consente di inviare un sistema Data Domain fisico con una chiave di crittografia sul sistema, ma senza che la passphrase venga memorizzata su di esso. In questo modo, se la scatola viene rubata durante il trasporto, un malintenzionato non può recuperare facilmente i dati poiché il sistema dispone solo di chiavi crittografate e dati crittografati.

La passphrase viene archiviata internamente in una parte nascosta del sistema di storage Data Domain. Ciò consente al sistema Data Domain di avviarsi e continuare la manutenzione dell'accesso ai dati senza l'intervento dell'amministratore.

Creazione o modifica della passphrase:

• La passphrase di sistema può essere creata utilizzando la CLI dopo che un amministratore esegue l'autenticazione con il sistema Data Domain.
• La passphrase di sistema può essere modificata utilizzando la CLI dopo che un amministratore e un utente con ruolo security (ad esempio un funzionario di sicurezza) hanno eseguito l'autenticazione con il sistema Data Domain (in modo che nessun singolo amministratore possa apportare modifiche in modo indipendente).

Domanda. Quando viene utilizzata la passphrase?
Risposta: La passphrase di sistema viene utilizzata come chiave primaria da vari componenti DDOS che includono crittografia del file system, accesso cloud, gestione dei certificati, token Boost, moduli di configurazione del sistema in ambienti scale-out e informazioni sulle licenze. Il software DDOS fornisce meccanismi per impostare e modificare questa passphrase di sistema. Fornisce inoltre opzioni per controllare se la passphrase di sistema è memorizzata su disco, operazione utilizzata in particolare per una maggiore sicurezza durante il trasporto del sistema DD. 

Domanda. Come viene utilizzata la passphrase per il trasporto sicuro del sistema DD?
Risposta: Il processo utilizza il comando "filesys encryption lock", che consente all'utente di bloccare il file system modificando la passphrase. L'utente immette una nuova passphrase che crittografa nuovamente la chiave di crittografia, ma la nuova passphrase non viene archiviata. Le chiavi di crittografia non sono ripristinabili fino a quando il file system non viene sbloccato utilizzando il comando "filesys encryption unlock".

Il processo è descritto nella Guida alla configurazione della sicurezza di Confluence Lab.

Domanda: Cosa succede se la passphrase cambia? È comunque possibile accedere ai dati?
Risposta: Sì, la modifica della passphrase non modifica la chiave di crittografia del sistema Data Domain sottostante, ma solo la crittografia della chiave di crittografia. Pertanto, l'accesso ai dati non è interessato.

Domanda: Come possiamo interrogare se una passphrase è impostata sul sistema?
Risposta: Se nel sistema è impostata una passphrase, il comando "system passphrase set" genera un errore che indica che la passphrase è già impostata.

Domanda: Cosa succede se la passphrase viene persa o dimenticata?
Risposta: Se il cliente perde la passphrase mentre l'apparecchio è bloccato, perde i dati. Non esiste una backdoor o un modo alternativo per accedervi. Senza un buon processo per la gestione della passphrase, ciò potrebbe accadere accidentalmente e gli utenti potrebbero non essere in grado di recuperare la chiave o i dati. Tuttavia, la chiave crittografata non può mai essere persa o danneggiata grazie ai meccanismi di protezione integrati del sistema.

Domanda: Esiste un meccanismo per reimpostare la passphrase di sistema dimenticata?
Risposta: La passphrase di sistema può essere reimpostata forzatamente solo in determinati scenari con l'aiuto del supporto clienti. Il meccanismo di aggiornamento forzato introdotto in DDOS 7.2 può essere utilizzato a tale scopo solo se sono soddisfatte condizioni specifiche. Ulteriori dettagli sono disponibili nell'articolo 20983 della Knowledge Base Data Domain: Come reimpostare una passphrase di sistema persa in DDOS v7.2 o versione successiva (è necessario accedere al supporto Dell per visualizzare l'articolo)

Domanda: Esiste un'opzione per evitare di archiviare la passphrase di sistema sul sistema DD?
Risposta: Per impostazione predefinita, la passphrase di sistema viene archiviata in una posizione nascosta nel sistema Data Domain. L'opzione di sistema "system passphrase option store-on-disk" può essere utilizzata per modificare questa impostazione ed evitare di memorizzare la passphrase su disco.

EKM (Embedded Key Manager)

Comando di primo livello:

Opzione System# filesys encryption embedded-key-manager <>

Domanda. La rotazione delle chiavi è supportata con Embedded Key Manager?
Risposta:  Sì, la rotazione delle chiavi per sistema Data Domain è supportata con Embedded Key Manager. Tramite l'interfaccia utente o la CLI, l'amministratore può impostare un periodo di rotazione delle chiavi (settimanale o mensile).

Domanda: La funzionalità di gestione delle chiavi integrata è a pagamento?
Risposta: Questa funzionalità è gratuita. Questa funzionalità è inclusa nell'opzione di licenza software DD Encryption standard.

Domanda: Il cliente può passare dalla gestione delle chiavi locale alla gestione delle chiavi esterna (EKM)?
Risposta

• Sì, i key manager esterni possono essere abilitati in qualsiasi momento. Tuttavia, le chiavi locali utilizzate rimangono nel sistema Data Domain. I key manager esterni non sono in grado di gestire le chiavi EKM. I dati esistenti non richiedono una nuova crittografia. Se per un cliente i dati di conformità devono essere crittografati nuovamente con chiavi EKM, questa operazione deve essere eseguita manualmente utilizzando apply-changes con la nuova chiave RW. La distruzione delle chiavi EKM dopo uno switch non è obbligatoria.
  • l'interruttore key-manager commuta automaticamente la chiave attiva sulla chiave da KMIP. 
  • Esempio di come appare il MUID della chiave KMIP quando si verifica uno switch

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

Domanda. Cosa succede quando la rotazione delle chiavi è disabilitata o abilitata?
Risposta: 

• Key rotation disabled è la funzionalità di crittografia predefinita se non si abilita la rotazione delle chiavi dall'interfaccia utente o dalla CLI. In questo scenario, tutti i dati vengono crittografati con la chiave attiva esistente.
• Se la rotazione delle chiavi è abilitata, in base alla frequenza di rotazione vengono ruotate le chiavi e i dati vengono crittografati con la chiave attiva più recente.

Gestori chiavi esterni

Domanda. Quali sono i key manager esterni supportati su DD?
Risposta: Supportiamo i seguenti gestori di chiavi esterni:

• Gemalto KeySecure (supporto aggiunto nella versione DDOS 7.2)
• Vormetric (supporto aggiunto in DDOS versione 7.3)
• CipherTrust (supporto aggiunto in DDOS versione 7.7)
• IBM GKLM (supporto aggiunto nella versione DDOS 7.9)

Domanda. È necessaria una licenza separata per abilitare l'integrazione con un gestore di chiavi esterno?
Risposta: Sì, è necessaria una licenza separata del rispettivo fornitore per integrare External Key Manager con DD.

Domanda: Quanti key manager supportano contemporaneamente?
Risposta: In un sistema DD può essere attivo un solo key-manager in un determinato point-in-time.

Domanda: Dove è possibile trovare ulteriori informazioni su come configurare KMIP External Key Manager?
Risposta: La Guida all'integrazione KMIP per DDOS contiene informazioni dettagliate per la configurazione dei diversi gestori di chiavi esterni supportati da DD.

Domanda: Come vengono gestiti i certificati per i gestori delle chiavi esterne in DD?
Risposta: Durante la configurazione del gestore delle chiavi esterno, è necessario generare un certificato CA (il certificato CA potrebbe essere autofirmato o firmato da terze parti) e un certificato host. Una volta eseguita la configurazione sul server External Key Manager, gli utenti devono importare il certificato CA e il certificato host nel sistema DD. Successivamente, configuriamo e abilitiamo il gestore delle chiavi esterno. 

Domanda. Che cos'è CA?
Risposta: Un'autorità di certificazione (CA) funge da entità condivisa inizialmente attendibile tra i peer ed emette certificati firmati per consentire a ciascuna parte di considerare attendibile l'altra. Un certificato funge in genere da identità di un server o di un client. 

Domanda. Che cos'è un certificato firmato da una CA locale e che cos'è un certificato firmato dalla CA?
Risposta: Un certificato firmato dalla CA è un certificato emesso e firmato da un autorità di certificazione (CA) pubblicamente attendibile. Un certificato firmato dall'autorità di certificazione viene considerato attendibile automaticamente. Una CA locale può emettere certificati firmati poiché la chiave di firma privata è archiviata all'interno del sistema di gestione delle chiavi. Una CA esterna non archivia la chiave privata. Al contrario, una CA esterna viene utilizzata come entità attendibile per varie interfacce e servizi all'interno del sistema.

Domanda: Come creare una richiesta di firma del certificato in DD?
Risposta: In Data Domain System, generare la CSR utilizzando il comando CLI riportato di seguito. In questo modo, la chiave privata non viene mai esposta al gestore di chiavi esterno.

adminaccess certificato cert-signing-request

Domanda. È possibile passare da un Key Manager all'altro?
Risposta: Il passaggio da External Key Manager a Embedded Key Manager è consentito e senza problemi. Tuttavia, il passaggio da Embedded Key Manager a External Key Manager richiede l'installazione e la configurazione appropriate dei certificati. Passaggio tra due External Key Manager (ad esempio: Sono consentiti anche KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM). È supportata anche la migrazione delle chiavi di Key Manager (per ulteriori dettagli, consultare la guida all'integrazione di KMIP).

Domanda: Cosa succede quando la connettività del Key Manager esterno si interrompe? I miei dati sono quindi accessibili?
Risposta: Sì, i dati sono ancora accessibili quando non è possibile connettersi al key manager, poiché una copia delle chiavi viene memorizzata anche nel sistema DD. Non è possibile creare nuove chiavi o sincronizzare gli stati delle chiavi in assenza di connettività con il key manager esterno.

Domanda: Esiste un modo per evitare di archiviare le chiavi in DD e archiviarle solo in External Key Manager?
Risposta: Conserviamo sempre una copia delle chiavi nel sistema DD per scopi dia. Questa impostazione non può essere modificata.

Domanda: L'integrazione con KMIP ha un impatto sulle prestazioni?
Risposta: No, non vi è alcun impatto sulle prestazioni a causa dell'utilizzo di Key Manager esterni.

Domanda: È possibile sfruttare la soluzione KMIP per Data Domain selezionati all'interno dell'ambiente?
Risposta: Sì, i clienti hanno la massima flessibilità nella scelta della metodologia di crittografia appropriata per i propri sistemi Data Domain. Possono continuare a sfruttare il key manager integrato di Data Domain su alcuni sistemi Data Domain e la rotazione delle chiavi di crittografia tramite KMIP su altri sistemi Data Domain all'interno del proprio ambiente.

Domanda: La comunicazione tra Data Domain e KMIP è protetta?
Risposta: Sì, Data Domain comunica tramite sessioni di autenticazione reciproca del certificato X509 con TLS. L'utente può utilizzare la CLI di Data Domain per importare il certificato X509 appropriato nel sistema Data Domain. Questo certificato viene quindi utilizzato per stabilire il canale sicuro tra DD e KMIP.

Gestione del ciclo di vita delle chiavi 

Domanda. Quali funzionalità di gestione delle chiavi esistono con l'opzione DD Encryption?
Risposta: Un key manager controlla la generazione, la distribuzione e la gestione del ciclo di vita di più chiavi di crittografia. Un sistema di protezione può utilizzare il Key Manager integrato o il Key Manager esterno conforme per KMIP. Può essere attivo un solo key manager alla volta. Quando la crittografia è abilitata su un sistema di protezione, Embedded Key Manager è attivo per impostazione predefinita. Se viene configurato un Key Manager esterno, sostituisce il Key Manager integrato e rimane attivo fino a quando non viene disabilitato manualmente. Il passaggio da Embedded Key Manager a External Key Manager o viceversa comporta l'aggiunta di una nuova chiave al sistema e non richiede il riavvio del file system dalla versione 7.1.

Domanda: Quali sono i diversi stati chiave sul sistema Data Domain?
Di seguito sono riportati i diversi stati delle chiavi sul sistema Data Domain:

• Activated-RW: In questo stato è presente una sola chiave in qualsiasi sistema DD e viene utilizzata per la lettura e la scrittura dei dati. Questa chiave viene utilizzata anche dal processo GC per crittografare nuovamente i container.
• In sospeso-Attivato: È presente una sola chiave in questo stato su qualsiasi sistema DD. Questo ha identificato la chiave che diventerà Activated-RW dopo il successivo riavvio del file system. Attualmente, questo stato esiste solo al momento dell'abilitazione della crittografia. Non viene creata un'altra chiave attivata in sospeso.  
• RO attivato: I key manager esterni possono avere più chiavi attivate. La chiave più recente è in Activated-RW, le altre sono in questo stato. Le chiavi possono passare a questo stato sul sistema DD quando non è possibile sincronizzare lo stato con il key manager.
• Disattivato: Viene utilizzato per leggere i dati esistenti sul sistema DD.
• Compromessa: Quando un cliente compromette una chiave del key manager esterno, lo stato verrà modificato in tale chiave dopo la sincronizzazione della chiave successiva.  
• Contrassegnato per la distruzione: Quando un cliente contrassegna una chiave per la distruzione, lo stato diventa Marked-For-Destroyed. Quando viene eseguito GC, tutti i container crittografati con chiavi contrassegnate per la distruzione vengono crittografati nuovamente utilizzando la chiave Activated-RW.
• Distrutto: Una chiave nello stato Marked-For-Destroyed passa a questo stato quando non sono associati dati.
• Distruzione compromessa: Una chiave nello stato compromesso passa a questo stato quando non sono associati dati.

Domanda. È possibile esportare le chiavi di crittografia per il ripristino di emergenza?
Risposta: Le chiavi possono essere esportate manualmente utilizzando il comando riportato di seguito.

"Esportazione chiavi di crittografia filesys"

Il sistema DD esporta anche le chiavi per impostazione predefinita quando viene aggiunta una nuova chiave o quando una qualsiasi delle chiavi viene eliminata dal sistema.

I file esportati sono presenti in /ddr/var/.security e sono in formato crittografato. Questo file deve quindi essere copiato dal DDR e archiviato in una posizione sicura che possa essere utilizzata in qualsiasi condizione di ripristino di emergenza in un secondo momento.

Nota: L'importazione delle chiavi per il ripristino di emergenza richiede l'intervento del Supporto clienti in quanto il processo di ripristino dipende dal tipo di guasto irreparabile riscontrato. È possibile importare il file chiave esportato utilizzando il seguente comando.

Nome file importazione chiavi di crittografia <File> 

Domanda. La chiave generata da KMIP viene archiviata nel sistema Data Domain?
Risposta: Sì, la chiave di crittografia ottenuta da KMIP viene archiviata in modo crittografato nel sistema Data Domain.

Domanda: In che modo una modifica dello stato della chiave nell'appliance KMIP viene applicata al sistema Data Domain?
Risposta: La sincronizzazione delle chiavi avviene quotidianamente. Se è disponibile una nuova chiave o se lo stato della chiave viene modificato, la sincronizzazione aggiorna la tabella delle chiavi locali. DD riceve aggiornamenti chiave dal KMIP ogni giorno a mezzanotte.

Domanda: È possibile sincronizzare manualmente gli stati delle chiavi tra DD e KMIP?
Risposta: Sì, è possibile utilizzare l'interfaccia utente o la CLI di Data Domain per sincronizzare manualmente gli stati delle chiavi tra DD e KMIP. "filesys encryption keys sync" è il comando utilizzato.

Domanda: È possibile modificare l'ora in cui DD riceve gli aggiornamenti delle chiavi da KMIP?
Risposta: No, non è possibile modificare l'ora in cui DD riceve gli aggiornamenti delle chiavi da KMIP.

Domanda: Esiste un limite al numero di chiavi supportate dal sistema Data Domain?
Risposta: A partire da DDOS 7.8, in qualsiasi momento, il sistema Data Domain può avere un massimo di 1.024 chiavi. In Activated-RW è presente un solo tasto, mentre le altre possono trovarsi in qualsiasi altro stato.

Domanda: È possibile utilizzare chiavi diverse per dataset diversi sui sistemi Data Domain? È configurabile?
Risposta: No, supportiamo una sola chiave attiva nel sistema alla volta e tutti i dati in entrata vengono crittografati utilizzando la chiave attiva corrente. Le chiavi non possono essere controllate con una granularità più fine come gli alberi M.

Domanda: Viene inviata una notifica quando viene raggiunto il limite massimo di chiavi?
Risposta: Sì, viene generato un avviso quando viene raggiunto il limite massimo di chiavi di 1.024.

Domanda: Come cancellare l'avviso relativo al limite massimo di chiavi?
Risposta: Una delle chiavi deve essere eliminata per cancellare l'avviso relativo al limite massimo di chiavi.

Domanda. È possibile visualizzare la quantità di dati associata a una particolare chiave nel sistema Data Domain?
Risposta: Sì, può essere visualizzato su DD ma non sul server KMIP. L'utente può utilizzare la CLI e l'interfaccia utente di Data Domain per visualizzare la quantità di dati associati a una particolare chiave.

Domanda:  È possibile visualizzare l'età delle chiavi sul sistema DD?
Risposta: Sì, può essere visualizzato con i tasti EKM utilizzando l'interfaccia utente.

Domanda: La vecchia chiave funziona anche se è trascorso il periodo di tempo per rendere effettiva la nuova chiave?
Risposta: Non esiste una data di scadenza per le chiavi di crittografia. Le chiavi precedenti diventano chiavi read-only dopo la rotazione delle chiavi e rimangono in DDOS.

Domanda: La chiave di crittografia viene eliminata automaticamente quando non sono associati dati nel sistema Data Domain?
Risposta: No, la chiave non viene eliminata automaticamente. L'utente deve eliminare esplicitamente la chiave utilizzando la CLI o l'interfaccia utente di DD.

Domanda: È possibile eliminare una chiave anche se nel sistema Data Domain sono associati dati?
Risposta: No, se a una chiave sono associati dei dati, non può essere eliminata. La nuova crittografia dei dati è necessaria con un'altra chiave per eliminare una chiave a cui sono associati dei dati.

Domanda: Se una chiave viene eliminata nel KMIP, viene eliminata anche dall'elenco delle chiavi di Data Domain?
Risposta: No, l'utente deve eliminare autonomamente la chiave utilizzando la CLI o l'interfaccia utente di DD.

Domanda: In un'ambiente Data Domain multisito, è richiesto un KMIP in ogni posizione?
Risposta: No, non è necessario disporre di un KMIP in ogni sito con un Data Domain. Possiamo puntare a un server KMIP. Si consiglia di avere una classe di chiave separata per ogni sistema DD quando utilizzano lo stesso server KMIP.

Domanda: Se una chiave è compromessa, è disponibile un processo per recuperare i dati crittografati con la vecchia chiave?
Risposta: In questo caso, il cliente deve contrassegnare la chiave come compromessa nel server KMIP. Eseguire "filesys encryption keys sync" nel sistema DDOS, quindi eseguire "filesys encryption apply-changes" e GC (filesys clean). L'esecuzione di GC crittografa nuovamente tutti i dati crittografati con la chiave compromessa utilizzando una chiave più recente. Al termine di GC, lo stato della chiave viene modificato in compromised-destroyed. Successivamente, sarà possibile eliminare la chiave. 

Crittografia e replica

Domanda. DD Replication è supportato e interoperabile con l'opzione software DD Encryption?
Risposta: Sì, DD Replication può essere utilizzato con l'opzione DD Encryption, consentendo in tal modo la replica dei dati crittografati utilizzando tutti i diversi tipi di replica. Ogni modulo di replica funziona in modo univoco con la crittografia e offre lo stesso livello di sicurezza.

Domanda: Per utilizzare la crittografia, sia i sistemi di origine che quelli di destinazione devono eseguire la stessa versione di DD OS?
Risposta: L'origine e la destinazione possono essere in versioni DDOS diverse per utilizzare DARE con la replica se è presente la matrice di compatibilità della replica (consultare la guida dell'amministratore per la matrice di compatibilità). 

Domanda. Come funziona la replica con la crittografia?
Risposta: Dipende dalla forma di replica in uso.

Se la replica configurata è MREPL o MFR:
Se si utilizza MREPL o MFR, DD Encryption può essere concesso in licenza o abilitato sull'origine o sulla destinazione in modo indipendente a seconda di ciò che il cliente desidera ottenere.

• Se la crittografia è abilitata sia nell'origine che nella destinazione: Quando i dati vengono acquisiti nel sistema di origine, vengono crittografati con la chiave di crittografia del sistema di origine. L'origine decrittografa i dati locali, li crittografa nuovamente utilizzando la chiave di crittografia del sistema di destinazione e quindi replica i dati crittografati nella destinazione durante la replica.
• Quando la crittografia è disabilitata per l'origine e per la destinazione: Tutti i dati acquisiti nell'origine non vengono crittografati (per ovvie ragioni). Tuttavia, durante la replica, l'origine crittografa i dati utilizzando la chiave di crittografia del sistema di destinazione, quindi replica i dati crittografati nel sistema di destinazione. 
• Quando la crittografia è abilitata nell'origine e nella destinazione la disabilita: Tutti i dati acquisiti nel sistema di origine vengono crittografati con la chiave di crittografia del sistema di origine. L'origine decrittografa i dati, quindi replica i dati non crittografati nel sistema Data Domain di destinazione durante la replica.
• Se la crittografia viene abilitata sulla replica dopo la configurazione del contesto di replica, tutti i nuovi segmenti ora replicati vengono crittografati all'origine per la replica. Tutti i segmenti che risiedono nella replica prima dell'abilitazione della crittografia vengono lasciati in uno stato non crittografato, a meno che la crittografia non applichi le modifiche e GC non venga eseguito sulla destinazione. 

Se la replica configurata è CREPL:
Con la replica della raccolta, sia i sistemi di origine che quelli di destinazione devono eseguire la stessa versione di DDOS. Pertanto, la crittografia deve essere abilitata o disabilitata su entrambi. Non può esserci una mancata corrispondenza anche nella configurazione della crittografia. Le chiavi di crittografia sono le stesse sia con l'origine che con la destinazione. 

• Se la crittografia è abilitata sia nell'origine che nella destinazione: Tutti i dati acquisiti nel sistema di origine vengono crittografati utilizzando la chiave di crittografia del sistema di origine. Durante la replica, l'origine invia i dati crittografati al sistema Data Domain di destinazione nello stato crittografato. Il sistema Data Domain di destinazione ha la stessa chiave dell'origine, poiché la replica della raccolta consiste in una replica esatta del sistema Data Domain di origine. Nessun dato può essere scritto nel sistema Data Domain di destinazione al di fuori della replica, in quanto la destinazione è un sistema read-only.
• Se la crittografia è disabilitata sia nell'origine che nella destinazione: Tutti i dati acquisiti nel sistema di origine non vengono crittografati (per ovvie ragioni). Durante la replica, l'origine invia (replica) i dati in uno stato non crittografato e rimangono non crittografati nel sistema Data Domain di destinazione. Nessun dato può essere scritto nel sistema Data Domain di destinazione al di fuori della replica, in quanto la destinazione è un sistema read-only.

Domanda. La chiave della destinazione è archiviata a tempo indeterminato nel sistema Data Domain di origine?
Risposta: La chiave di crittografia della destinazione non viene mai archiviata nel sistema Data Domain di origine. Viene mantenuta in memoria (crittografata) solo mentre la sessione di replica è attiva. Ciò si applica a tutti i tipi di replica, ad eccezione della replica della raccolta. Nella replica della raccolta (CREPL) lo stesso set di chiavi di crittografia è presente nell'origine e nella destinazione.  

Domanda. È possibile abilitare la crittografia nel sistema CREPL dopo aver stabilito il contesto di replica?
Risposta: Sì, in questo caso la crittografia deve essere abilitata sia nell'origine che nella destinazione. La crittografia può essere abilitata nell'origine e nella destinazione disabilitando il contesto di replica. Tutti i nuovi segmenti replicati vengono crittografati nella replica. Tutti i segmenti che risiedono nella replica prima dell'abilitazione della crittografia vengono lasciati in uno stato non crittografato.

Domanda: È possibile abilitare DD Encryption contemporaneamente alla funzione di crittografia over-the-wire nell'opzione software DD Replication?
Risposta: Sì, sia la crittografia via cavo che la crittografia D@RE possono essere abilitate contemporaneamente per raggiungere obiettivi di sicurezza diversi.

Domanda: Cosa succede se l'opzione software DD Encryption e la funzione di crittografia over-the-wire nell'opzione software DD Replication sono abilitate contemporaneamente?
Risposta: La prima origine crittografa i dati utilizzando la chiave di crittografia di destinazione. I dati già crittografati vengono crittografati una seconda volta a causa della crittografia via cavo durante l'invio di questi dati alla destinazione. Sulla destinazione, dopo aver eseguito la decrittografia via cavo, i dati verranno archiviati in un formato crittografato che è stato crittografato utilizzando la chiave di crittografia della destinazione.

Domanda: Quando la crittografia è abilitata nell'origine e nella destinazione, la passphrase deve essere la stessa su entrambe?
Risposta: Se la replica configurata è di tipo CREPL (replica della raccolta), la passphrase deve essere la stessa. Per altri tipi di replica (come MREPL, MFR), la passphrase può essere diversa nell'origine e nella destinazione.

Domanda: Con la crittografia abilitata sulla destinazione (domanda non applicabile a CREPL), vengono crittografati sia i dati replicati sia i dati provenienti da un altro punto di accesso (ad esempio tramite backup locale)? Esiste un modo per separare i due nella replica in cui solo le directory replicate vengono crittografate mentre gli altri accessi non vengono crittografati?
Risposta: No, tutti i dati vengono crittografati nella replica (destinazione) indipendentemente dal punto di ingresso. La crittografia può essere abilitata o disabilitata solo a livello di MTree o directory. 

Domanda. Come avviene lo scambio di chiavi tra l'origine e la destinazione durante MREPL o MFR?
Risposta: Durante la fase di associazione della replica, il computer di destinazione trasmette in modo sicuro l'algoritmo di crittografia corrente e le informazioni sulle chiavi all'origine. I contesti di replica vengono sempre autenticati con un segreto condiviso. Tale segreto condiviso viene utilizzato per stabilire una chiave di "sessione" utilizzando un protocollo di scambio chiavi Diffie-Hellman. Tale chiave di sessione viene utilizzata per crittografare e decrittografare la chiave di crittografia del sistema Data Domain.

Domanda: Quale tipo di algoritmo di crittografia viene utilizzato per la funzione "crittografia via cavo" di Data Domain relativa alla crittografia del traffico di replica?
Risposta: Quando la modalità di autenticazione della replica è impostata su "one-way" o "two-way", DHE (Ephemeral Diffie-Hellman) viene utilizzato per lo scambio delle chiavi di sessione. L'autenticazione del server avviene tramite RSA. La crittografia GCM AES a 256 bit viene utilizzata per incapsulare i dati replicati via cavo. Il livello di incapsulamento della crittografia viene rimosso immediatamente quando raggiunge il sistema di destinazione. 

One way indica che è certificato solo il certificato di destinazione. Due modi indicano che vengono verificati sia i certificati di origine che di destinazione. L'affidabilità reciproca deve essere stabilita prima di poter utilizzare la modalità di autenticazione ed entrambi i lati della connessione devono abilitare questa funzione affinché la crittografia possa procedere.

Quando la modalità di autenticazione della replica è impostata su "anonymous", per lo scambio di chiavi di sessione viene utilizzato Anonymous Diffie-Hellman (ADH), ma in questo caso l'origine e la destinazione non si autenticano a vicenda prima dello scambio di chiavi. Inoltre, se la modalità di autenticazione non è specificata, anonymous viene utilizzato come impostazione predefinita.

Domanda: La rotazione delle chiavi senza riavvio del file system funziona con tutti i tipi di replica?
Risposta: La rotazione delle chiavi senza riavvio del file system funziona con tutti i tipi di replica tranne DREPL (il supporto DREPL è già terminato) e replica delta (nota anche come LBO)

Domanda: In assenza di certificati o coppie di chiavi PKI, come viene protetta la chiave di crittografia della destinazione durante lo scambio di chiavi?
Risposta: Esiste un segreto condiviso tra tutte le coppie di replica Data Domain utilizzato per stabilire una chiave di sessione condivisa mediante uno scambio di chiavi Diffie-Hellman. Tale chiave condivisa viene utilizzata per crittografare la chiave di crittografia della destinazione.

Esiste una differenza tra il segreto condiviso utilizzato per l'autenticazione della replica e la chiave di sessione condivisa, allocata utilizzando il protocollo di scambio chiavi Diffie-Hellman. Il segreto condiviso utilizzato per l'autenticazione della replica viene stabilito dal software Data Domain la prima volta che due sistemi Data Domain desiderano stabilire un contesto di replica. Viene anche concordato attraverso uno scambio di Diffie-Hellman utilizzando parametri incorporati nel codice. Questo viene archiviato in modo persistente nei sistemi per autenticare ogni sessione di replica tra i due sistemi. La chiave della sessione di replica (la chiave utilizzata per crittografare la chiave di crittografia della destinazione) viene stabilita utilizzando un altro scambio Diffie-Hellman con il segreto condiviso stabilito in precedenza, promuovendo così il protocollo di scambio chiavi sicuro. Questa chiave non è persistente ed è disponibile solo quando il contesto di replica è attivo.

Domanda: È necessario che entrambi i Data Domain di una coppia di replica utilizzino la stessa soluzione di gestione delle chiavi esterna (ad esempio KMIP Key Manager) oppure uno dei sistemi può utilizzare una soluzione di gestione delle chiavi esterna e l'altro può utilizzare una soluzione di gestione delle chiavi integrata?
Risposta: Oltre a una coppia di replica della raccolta, non è necessario che entrambi i sistemi all'interno di una coppia di replica utilizzino lo stesso key manager.

Con la replica della raccolta, entrambi i sistemi Data Domain devono essere configurati con lo stesso key manager. Ma anche in questo caso, l'unica origine è la sincronizzazione delle chiavi con il key manager e anche queste chiavi vengono inviate alla destinazione. Con altri tipi di replica, è possibile utilizzare key manager diversi con origine e destinazione.

Crittografia e migrazione

Domanda. La migrazione dei dati è supportata sui sistemi in cui è abilitata la crittografia?
Risposta: Sì, la migrazione dei dati è supportata sui sistemi con crittografia abilitata. La configurazione della crittografia sui sistemi di origine e di destinazione deve essere rispettata come prerequisito prima di avviare la migrazione dei dati. Si consiglia inoltre di esportare ed eseguire il backup delle chiavi di crittografia sul sistema di origine per scopi DIA prima di avviare la migrazione.

Domanda: La migrazione dei dati è supportata sia per la migrazione tier attivo che per la migrazione cloud tier per i sistemi abilitati per la crittografia?
Risposta: Sì, la migrazione dei dati è supportata sia per Active Tier che per la migrazione Cloud Tier per i sistemi abilitati per la crittografia. L'elenco degli attributi dei prerequisiti controllati viene applicato in base al tier in cui è abilitata la crittografia.

Domanda: Quali impostazioni di crittografia vengono mantenute durante la migrazione?
Risposta: I dati crittografati e le chiavi di crittografia vengono migrati così come sono, ma impostazioni come la gestione delle chiavi di crittografia, la passphrase di sistema e altre configurazioni di crittografia devono essere verificate manualmente e abbinate per una corretta migrazione dei dati. Anche tutti i certificati di gestione delle chiavi esistenti vengono trasferiti al sistema di destinazione. Dopo la migrazione, è necessario configurare nuovamente il key manager di crittografia sul sistema di destinazione.

Domanda: Quali controlli di compatibilità della crittografia vengono eseguiti tra l'origine e la destinazione durante la migrazione?
Risposta: La passphrase di sistema, lo stato della crittografia e i dettagli di configurazione del key manager e le impostazioni della modalità FIPS del sistema sono alcune delle impostazioni di crittografia che devono essere identiche nei sistemi di origine e di destinazione affinché la migrazione venga eseguita correttamente. Questo articolo della Knowledge Base 183040, Data Domain: Procedura di migrazione per sistemi DD abilitati per il cloud (è necessario accedere al supporto Dell per visualizzare l'articolo), descrive in dettaglio i passaggi per la migrazione tra sistemi con cloud abilitato. Le stesse impostazioni si applicano anche per la migrazione solo del tier attivo.

Domanda: È supportata la migrazione tra sistemi con l'impostazione Encryption Disablement Project attivata?
Risposta: La migrazione dei dati è supportata tra due sistemi se entrambi sono EDP o non EDP. La migrazione dei dati è consentita da un sistema EDP a un sistema non EDP se la crittografia on-the-wire è esplicitamente disattivata. (utilizzando il MIGRATION_ENCRYPTION sysparam)

Crittografia nel Cloud Tier 

Domanda. La crittografia è supportata per il Cloud Tier?
Risposta: Sì, la crittografia è supportata nel Cloud Tier. Per impostazione predefinita, la crittografia è disabilitata nel Cloud Tier. Il comando "Cloud Enable" richiede di scegliere se abilitare la crittografia sul Cloud Tier.

Domanda: KMIP e i Key Manager esterni sono supportati con il cloud tier?
Risposta: Sì, KMIP e i Key Manager esterni sono supportati con Cloud Tier da DDOS 7.8 in poi.

Domanda: Con quale granularità può essere abilitata la crittografia nel cloud?
Risposta: La crittografia può essere abilitata e disabilitata in modo indipendente su ogni unità cloud e su ogni tier.

Domanda: Le unità cloud hanno chiavi indipendenti?
Risposta: No, la gestione delle chiavi è comune sia al tier attivo che al cloud tier in DD. Le chiavi vengono copiate sull'unità/tier/CP corrispondente quando la crittografia è abilitata. Se la crittografia è abilitata su Active e non su Cloud, le chiavi di tier Active non si riflettono su Cloud e viceversa. Ciò vale anche per le unità cloud. (Ad esempio: CP1 ha la crittografia abilitata e CP2 non ha la crittografia abilitata, le chiavi CP1 non riflettono su CP2.)   

Domanda. È possibile eliminare le chiavi nel cloud?
Risposta: No, l'eliminazione delle chiavi dal cloud non è supportata.

Domanda: Dove vengono gestite le chiavi di crittografia dei dati per le unità cloud?
Risposta: Le chiavi sono associate a un cp e ogni unità cloud è un cp diverso. Una copia delle chiavi di tutti i cps viene memorizzata nel cp attivo.

Domanda: Come si ripristinano le chiavi cloud durante un ripristino di emergenza? 
Risposta. Il mirroring di cpnameval nel cloud come parte del ripristino del CP, le chiavi di crittografia verranno ripristinate in cpnameval. Ora, dobbiamo eseguire ddr_key_util strumento per recuperare le chiavi.

Nota: Il ripristino di emergenza richiede l'intervento dell'assistenza clienti.

Domanda: È possibile eseguire lo spostamento dei dati quando la crittografia è abilitata solo nel Cloud Tier?
Risposta: No, per lo spostamento dei dati è necessario abilitare la crittografia sia nel cloud tier che nei tier attivi.

Domanda: È possibile abilitare il key manager esterno sul cloud tier?
Risposta: Sì, la gestione delle chiavi esterna può essere abilitata sul Cloud Tier. Questa funzione è supportata da 7.8 e versioni successive. Tutte le operazioni, ad eccezione della distruzione o dell'eliminazione della chiave valide per il tier attivo, sono valide anche per il cloud tier in termini di gestore di chiavi esterne. 

Crittografia e garbage collection

Domanda. Che ruolo svolge il processo di pulizia globale nella crittografia dei dati inattivi e qual è un impatto sulle prestazioni quando si abilita la crittografia per la prima volta?
Risposta: L'abilitazione della crittografia dei dati inattivi per la prima volta ha un impatto sulle prestazioni della pulizia globale. Ciò è dovuto al fatto che i dati che devono essere letti da container esistenti su disco e scritti in nuovi container potrebbero richiedere di essere letti, decrittografati e decompressi prima di essere nuovamente compressi, crittografati e scritti nuovamente su disco. Quando la crittografia è abilitata su un DD che contiene una quantità significativa di dati preesistenti e viene eseguito il comando "filesys encryption apply-changes", il ciclo di pulizia globale successivo tenta di crittografare tutti i dati esistenti nel sistema. Ciò significa che tutti i dati devono essere letti, decompressi, compressi, crittografati e scritti su disco. Di conseguenza, il primo ciclo di pulizia globale dopo l'esecuzione di "filesys encryption apply-changes" potrebbe richiedere più tempo del normale. I clienti devono assicurarsi di disporre di spazio libero sufficiente sul sistema DD per consentire il completamento della pulizia senza che il sistema DD si riempia (in caso contrario i backup hanno esito negativo).

Domanda: C'è un impatto sulle prestazioni dei cicli puliti di acquisizione/ripristino in corso?
Risposta: Sì, vi è un impatto sulle prestazioni e l'impatto in genere dipende dalla quantità di dati acquisiti/ripristinati tra i cicli di pulizia.

Domanda: Quanto tempo è necessario per crittografare i dati esistenti?
Utilizzare questo articolo della Knowledge Base per stimare il tempo, Data Domain: Calcolo del tempo necessario per applicare la crittografia at-rest.

Crittografia e headswap 

Domanda. Il cliente può spostare il disco su un altro sistema Data Domain in caso di guasto di una testina e accedere al disco quando la crittografia è abilitata?
Risposta: La chiave di crittografia non è associata all'intestazione del sistema Data Domain stessa, pertanto è possibile spostare i dischi su un'altra intestazione del sistema Data Domain e la chiave è accessibile lì. Su una nuova head di sistema Data Domain, il file system è bloccato, pertanto è necessario inserire la passphrase con il comando "filesys encryption unlock". 

Domanda. Cosa succede se un cliente ha dimenticato la passphrase al momento dell'operazione headswap?
Risposta: Durante questo periodo, possono collegare la vecchia head e collaborare con il supporto per reimpostare la passphrase, quindi connettersi nuovamente alla nuova head e completare la procedura di headswap. 

Prestazioni di crittografia

Domanda. Qual è l'impatto osservato sull'utilizzo dello storage quando viene utilizzata la crittografia?
Risposta: È trascurabile, con circa l'1% di overhead associato all'archiviazione di alcuni parametri di crittografia con i dati dell'utente.

Domanda: Qual è l'impatto osservato sul throughput (scritture e letture) quando viene utilizzata la crittografia dei dati inattivi?
Risposta: L'impatto sul throughput di acquisizione quando viene utilizzata la crittografia può variare in base al protocollo e alla piattaforma. In generale, le percentuali seguenti sono riduzioni conservative delle prestazioni nel throughput aggregato:

Modalità
CBC Primo pieno: ~10% di peggioramento delle prestazioni su SCRITTURE
incrementali: ~5% di peggioramento delle prestazioni sui ripristini WRITE:
Dal 5 al 20% di riduzione delle prestazioni in lettura Modalità


GCM Primo pieno: Riduzione delle prestazioni dal 10 al 20% su SCRITTURE
incrementali: Riduzione delle prestazioni del 5-10% sui ripristini di
tipo SCRITTURA: Dal 5 al 20% di riduzione delle prestazioni in lettura

Questi numeri sono specifici per l'overhead della crittografia dei dati inattivi (la crittografia over-the-wire viene contabilizzata separatamente)
 

Best practice

Domanda. Quali sono le best practice relative alla policy di rotazione delle chiavi?
Risposta: La policy di rotazione automatica delle chiavi non è abilitata per impostazione predefinita. Il cliente l'ha abilitata. Si consiglia di ruotare frequentemente le chiavi di crittografia. Quando un sistema è configurato con un key manager KMIP esterno, è consigliabile ruotare frequentemente le chiavi per gestire eventuali scenari di compromissione delle chiavi in futuro. Quando KMIP è configurato con Cloud Tier, l'intervallo di rotazione delle chiavi consigliato è di 1 settimana e quando KMIP è configurato solo nel tier attivo, la policy di rotazione delle chiavi consigliata è di 1 mese. Tuttavia, in base al tasso di acquisizione, il cliente può aumentare o diminuire anche la frequenza di rotazione delle chiavi. Se è configurato un key manager integrato, si consiglia una policy di rotazione delle chiavi compresa tra 1 e 3 mesi. 

Domanda. Quali sono le best practice per la classe di chiave KMIP se un cliente utilizza lo stesso server KMIP per molti sistemi DD?
Risposta: Si consiglia di avere una classe di chiave separata per ogni sistema DD quando utilizzano lo stesso server KMIP. In questo modo, la rotazione delle chiavi eseguita in un sistema DDOS non influisce sullo stato della chiave presente in un altro sistema DDOS.

Per ulteriori informazioni, consultare il documento DELL EMC PowerProtect DD Series Appliances: Software di crittografia (delltechnologies.com)

Codifica: White paper tecnico Appliance PowerProtect serie DD: Software

di crittografiaAltre documentazioni relative a DD Encryption (Guida dell'amministratore, Guida di riferimento ai comandi e Guida alla configurazione della sicurezza) sono disponibili nell'articolo 126375, documenti core di PowerProtect e Data Domain.

Guida all'integrazione KMIP e matrice

di compatibilitàGuardare questo video: