Data Domain: Domande frequenti sulla crittografia

Riepilogo: Questo articolo della knowledgebase fornisce una raccolta di domande frequenti (FAQ) su Data Domain Data At Rest Encryption (DARE) in una posizione consolidata per facilità di riferimento. ...

Prodotti interessati

Questo articolo si applica a Questo articolo non si applica a Questo articolo non è legato a un prodotto specifico. Non tutte le versioni del prodotto sono identificate in questo articolo.

Scopri le altre risorse

Istruzioni

Configurazione della crittografia

Domanda. Come viene configurato Data At Rest Encryption (DARE) su Data Domain?

Risposta. DARE può essere configurato con la seguente procedura:

Aggiungere una licenza di crittografia.
1. Disporre di un file di licenza con una licenza di crittografia valida.
2. Utilizzare il comando riportato di seguito per aggiornare l'e-license in Data Domain utilizzando il file di licenza disponibile:
```
# elicense update
```
Aggiungere un funzionario di sicurezza e abilitare le relative autorizzazioni.
1. Aggiungere un utente con il ruolo "security" (se non ne esiste già uno) utilizzando il comando:
```
# user add <username> role security
```
2. Abilitare l'autorizzazione del funzionario di sicurezza effettuando l'accesso come funzionario di sicurezza ed eseguendo il comando:
```
> authorization policy set security-officer enabled
```
Tornare a un account amministratore e abilitare DARE eseguendo il comando:
```
# filesys encryption enable
```

Domanda. Quali piattaforme sono supportate da DARE?

Risposta. La funzione DARE è supportata su tutti i sistemi Data Domain, ad eccezione dei sistemi EDP (Encryption Disablement Project).

Domanda. Come è possibile archiviare i dati in testo non crittografato su Data Domain?

Risposta. Gli utenti possono assicurarsi che i dati vengano salvati in testo non crittografato e non crittografati in Data Domain verificando che la crittografia sia disattivata nella configurazione.

La crittografia può essere disabilitata in Data Domain utilizzando il comando:

# filesys encryption disable

Domanda. Quali applicazioni e protocolli di backup sono supportati con DARE?

Risposta. La funzione DARE è indipendente dall'applicazione di backup sottostante o dal protocollo utilizzato da Data Domain.

Domanda. Quali algoritmi di crittografia possono essere utilizzati?

Risposta. Il software di crittografia Data Domain supporta algoritmi 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 ORed (XOR) al 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 si può modificare l'algoritmo di crittografia?

Risposta. Utilizzare il comando riportato di seguito per impostare un algoritmo di crittografia specifico:

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

Domanda. Come posso assicurarmi che la crittografia venga eseguita sui dati preesistenti una volta abilitata?

Risposta. È possibile forzare il file system di Data Domain a crittografare i dati preesistenti utilizzando il seguente comando:

# filesys encryption apply-changes

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

Domanda. Come si disabilita la crittografia?

Risposta. Disabilitare la funzione di crittografia in Data Domain utilizzando il seguente comando:

# filesys encryption disable

In questo modo viene disabilitata solo la crittografia per i dati in ingresso. I dati crittografati esistenti rimangono crittografati fino a quando non vengono decrittografati manualmente utilizzando il comando 'filesys encryption apply-changes'.

Domanda. Quali comandi di crittografia richiedono il riavvio del file system per avere effetto?

Risposta. Per avere effetto, i seguenti comandi di crittografia richiedono il riavvio del file system:

filesys encryption enable|disable - Abilita o disabilita la crittografia su Data Domain.
filesys encryption algorithm set - Consente all'utente di selezionare un algoritmo crittografico.
filesys encryption algorithm reset - Reimposta l'algoritmo di crittografia su AES 256 in modalità CBC (l'impostazione predefinita).

Domanda. Quali comandi di crittografia richiedono la disabilitazione del file system per poterli impostare o utilizzare?

Risposta. Il file system di Data Domain deve essere disabilitato per impostare o utilizzare i seguenti comandi di crittografia:

encryption passphrase change
encryption lock|unlock

Domande generali sulla crittografia

Domanda. DARE è supportato su tutti i sistemi Data Domain?

Risposta. L'opzione software DARE è supportata sui sistemi Data Domain che non fanno parte del progetto EDP (Encryption Disablement Project). Questi sistemi non consentono l'abilitazione della crittografia e sono venduti principalmente nella regione della Russia.

Domanda. Come viene eseguita la crittografia sui sistemi Data Domain?

Risposta. La crittografia viene eseguita utilizzando le librerie OpenSSL e RSA BSafe. RSA BSafe è una libreria di crittografia convalidata FIPS 140-2.

Domanda. Quale versione di BSafe utilizza Data Domain?

Risposta. A partire da DDOS 7.10, le versioni BSafe in uso 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 la riga di comando, l'interfaccia web o le API REST. Il supporto per API REST è stato aggiunto in DDOS versione 8.0.

Domanda. È possibile eseguire la crittografia selettiva dei dati? Ti piace un solo MTree o 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 cloud tier e di 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 utilizza Data Domain?

Risposta. A partire da DDOS 7.10, la versione OpenSSL è "OpenSSL 1.0.2zd-fips".

Domanda. In che modo DARE 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 a Data Domain, ma tutti i dati che risiedono fisicamente su 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.
La crittografia Data Domain è progettata in modo tale che, se un intruso aggira altri controlli di sicurezza della rete e ottiene l'accesso ai dati crittografati, i dati sono illeggibili e inutilizzabili per quella persona senza le chiavi di crittografia appropriate.

Domanda. La crittografia avviene 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 DARE. 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:

Quando sono presenti chiavi di crittografia compromesse
Quando la tabella delle chiavi di crittografia è piena e non è possibile aggiungere altre chiavi al 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 viene modificata

Domanda. Esiste una certificazione di sicurezza per DDOS?

Risposta. I sistemi Data Domain soddisfano la conformità FIPS 140-2.

Domanda. Dove è archiviata la chiave di crittografia?

Risposta. Le chiavi di crittografia vengono archiviate in modo persistente in una partizione di raccolta in DDOS.

Domanda. Se un utente estrae un disco rigido da un Data Domain, può decrittografare i dati da esso?

Risposta. Le chiavi di crittografia vengono crittografate utilizzando la passphrase di sistema, che è memorizzata nell'intestazione del sistema. Anche se le chiavi di crittografia sono archiviate nel disco, le chiavi di crittografia non possono essere decrittografate senza la passphrase di sistema. 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 con il comando di esportazione delle chiavi.

Domanda. In che modo è possibile bloccare il file system prima di spostare il sistema in una posizione diversa?

Risposta. Di seguito è riportata la procedura per bloccare il sistema:

Disabilitare il file system:
```
# filesys disable
```

Bloccare il file system e immettere una nuova passphrase (questa operazione richiede l'autenticazione con un utente di sicurezza):

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

La nuova passphrase NON deve essere persa o dimenticata. Senza questa passphrase, il file system non può essere sbloccato, il che significa che i dati su Data Domain sono inaccessibili.

Per sbloccare il sistema quando raggiunge una posizione remota, utilizzare il comando riportato di seguito:

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

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

Domanda. Il '`storage sanitize`' hanno 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 over-the-wire è supportata per i sistemi EDP?

Risposta. La crittografia DARE e over-the-wire non è supportata per i sistemi EDP.

System Passphrase

Domanda. Che cos è la passphrase di sistema?

Risposta. DDOS è in grado di proteggere le credenziali all'interno del sistema impostando una passphrase a livello di sistema. La passphrase è una chiave leggibile, 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 a fornire l'accesso ai dati senza l'intervento dell'amministratore.

Creazione o modifica della passphrase:

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

Domanda. Quando viene utilizzata la passphrase?

Risposta. La passphrase di sistema viene utilizzata come chiave principale da vari componenti DDOS, tra cui crittografia del file system, accesso cloud, gestione dei certificati, token DD Boost, moduli di configurazione del sistema in ambienti scale-out e informazioni sulle licenze. DDOS fornisce meccanismi per impostare e modificare questa passphrase di sistema. Fornisce inoltre opzioni per controllare se la passphrase di sistema è memorizzata su disco, una condizione particolarmente utilizzata per una maggiore sicurezza durante il trasporto di Data Domain.

Domanda. Come viene utilizzata la passphrase per il trasporto sicuro di Data Domain?

Risposta. Il processo utilizza l'opzione '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' comando.

Il processo è descritto nelle Guide alla configurazione della sicurezza di Data Domain.

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. Di conseguenza, l'accesso ai dati non viene influenzato.

Domanda. Come è possibile verificare se una passphrase è impostata nel sistema?

Risposta. Se sul sistema è impostata una passphrase, l'esecuzione di '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 una passphrase di sistema persa?

Risposta. La passphrase di sistema può essere reimpostata forzatamente solo in determinati scenari con l'aiuto dell'assistenza clienti. Il meccanismo di aggiornamento forzato introdotto in DDOS 7.2 può essere utilizzato a tale scopo solo se sono soddisfatte condizioni specifiche. Maggiori dettagli sono disponibili in questo articolo: Data Domain: Come reimpostare una passphrase di sistema persa in DDOS v7.2 o versione successiva (è necessario accedere al supporto Dell).

Domanda. Esiste un'opzione per evitare di archiviare la passphrase di sistema su Data Domain?

Risposta. Per impostazione predefinita, la passphrase di sistema viene archiviata in una posizione nascosta nel sistema Data Domain. Il comando 'system passphrase option store-on-disk' può essere utilizzato per modificare questa impostazione ed evitare di memorizzare la passphrase su disco.

EKM (Embedded Key Manager)

Comando di primo livello:

# filesys encryption embedded-key-manager <option>

Domanda. La rotazione delle chiavi è supportata con EKM?

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. È incluso nell'opzione di licenza software standard di Data Domain Encryption.

Domanda. È possibile passare dalla gestione delle chiavi locale a una esterna?

Risposta. Sì, i key manager esterni possono essere abilitati in qualsiasi momento. Tuttavia, le chiavi locali utilizzate rimangono nel Data Domain. I key manager esterni non sono in grado di gestire le chiavi locali. I dati esistenti non richiedono la recrittografia. Se i dati di conformità devono essere crittografati nuovamente con chiavi EKM, questa operazione deve essere eseguita manualmente utilizzando "filesys encryption apply-changes' con il nuovo RW . La distruzione delle chiavi EKM dopo uno switch non è obbligatoria.

La modifica dei key manager commuta automaticamente la chiave attiva nella 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. La rotazione delle chiavi è disabilitata per impostazione predefinita. In questo scenario, tutti i dati vengono crittografati con la chiave attiva esistente. Se la rotazione delle chiavi è abilitata, i dati vengono crittografati con la chiave attiva più recente in base alla frequenza di rotazione configurata.

Gestori chiavi esterni

Domanda. Quali gestori di chiavi esterni supporta Data Domain?

Risposta. Data Domain supporta i seguenti key manager 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 l'integrazione di un gestore chiavi esterno con Data Domain.

Domanda. Quanti key manager possono essere utilizzati contemporaneamente?

Risposta. In un Data Domain può essere attivo un solo Key Manager alla volta.

Domanda. Dove è possibile trovare ulteriori informazioni su come configurare i gestori delle chiavi esterne KMIP?

Risposta. KMIP Integration Guide for DDOS contiene informazioni dettagliate sulla configurazione dei diversi key manager esterni supportati da Data Domain.

Domanda. Come vengono gestiti i certificati per i key manager esterni in Data Domain?

Risposta. La configurazione del gestore delle chiavi esterno richiede la generazione di un certificato CA (che può essere autofirmato o firmato da terze parti) e di un certificato host. Una volta eseguita la configurazione sul server di gestione delle chiavi esterne, il certificato CA e il certificato host devono essere importati nel sistema Data Domain. Quindi è possibile configurare e abilitare il gestore delle chiavi esterno.

Domanda. Che cos'è un'autorità di certificazione?

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 dalla CA? Che cos'è un certificato locale firmato da una CA?

Risposta. Un certificato firmato da una CA è un certificato emesso e firmato da un autorità di certificazione (CA) pubblicamente attendibile. Un certificato firmato dalla CA 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 è possibile creare una richiesta di firma di un certificato in un Data Domain?

Risposta. È possibile generare una richiesta di firma del certificato (CSR) Data Domain utilizzando il comando riportato di seguito. In questo modo, la chiave privata non viene mai esposta al gestore delle chiavi esterno.

# adminaccess certificate cert-signing-request

Domanda. È possibile passare da un key manager all'altro?

Risposta. Il passaggio dalla key manager esterna al key manager integrato è consentito e senza problemi. Tuttavia, il passaggio dal Key Manager integrato ai Key Manager esterni richiede l'installazione e la configurazione appropriate dei certificati. Passaggio tra due gestori di chiavi esterni (ad esempio: KMIP-CipherTrust, DSM-CipherTrust, CipherTrust to GKLM). È supportata anche la migrazione delle chiavi (per ulteriori dettagli, consultare la Guida all'integrazione di KMIP ).

Domanda. Cosa succede quando la connettività del gestore delle chiavi esterne si interrompe? I miei dati sono ancora accessibili?

Risposta. Sì, i dati sono ancora accessibili quando non è possibile connettersi al key manager, poiché una copia delle chiavi viene archiviata anche in Data Domain. Non è possibile creare nuove chiavi e gli stati delle chiavi non possono essere sincronizzati in assenza di connettività con il key manager esterno.

Domanda. Esiste un modo per archiviare le chiavi solo nel key manager esterno e non in Data Domain?

Risposta. Una copia delle chiavi viene sempre archiviata nel sistema Data Domain per scopi Data Invulnerability Architecture (DIA). Questa impostazione non può essere modificata.

Domanda. L'integrazione con KMIP influisce sulle prestazioni?

Risposta. No, non vi è alcun impatto sulle prestazioni a causa dell'utilizzo di gestori di chiavi 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 Data Domain. Possono continuare a sfruttare il key manager integrato di Data Domain su alcuni sistemi e la rotazione delle chiavi di crittografia tramite KMIP su altri sistemi 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. È possibile 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 Data Domain e KMIP.

Gestione del ciclo di vita delle chiavi

Domanda. Quali funzionalità di gestione delle chiavi esistono con la crittografia Data Domain?

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 un Key Manager esterno conforme a 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. A partire da DDOS 7.1, questa operazione non richiede il riavvio del file system.

Domanda. Quali sono i diversi stati chiave su Data Domain?

Di seguito sono riportati i diversi stati delle chiavi su Data Domain:

Activated-RW: In questo stato è presente una sola chiave in un Data Domain in un determinato momento e viene utilizzata per la lettura e la scrittura di dati. Questa chiave viene utilizzata anche dal processo di garbage collection per crittografare nuovamente i container.
Pending-Activated: In questo stato è presente una sola chiave in un Data Domain in un determinato momento. In questo modo viene identificata la chiave che diventerà Activated-RW dopo il successivo riavvio del file system. Questo stato è presente solo al momento dell'abilitazione della crittografia. Pending-activated Le chiavi non vengono create in nessun altro momento.
Activated-RO: I key manager esterni possono avere più chiavi attivate. La chiave più recente è in Activated-RWe il resto sono in questo stato. Le chiavi possono passare a questo stato su Data Domain quando non è possibile sincronizzare lo stato con il key manager.
Deactivated: Viene utilizzato per leggere i dati esistenti nel sistema Data Domain.
Compromised: Quando una chiave del key manager esterno viene compromessa, passa a questo stato dopo la successiva sincronizzazione delle chiavi.
Marked-For-Destroyed: Quando un cliente contrassegna una chiave per la distruzione, la chiave cambia in questo stato. Quando viene eseguita la garbage collection, tutti i container crittografati con Marked-For-Destroyed Le chiavi vengono crittografate nuovamente utilizzando il comando Activated-RW .
Destroyed: Una chiave nella Marked-For-Destroyed Lo stato passa a questo stato quando non sono associati dati.
Destroyed-compromised: Una chiave nella Compromised Lo stato 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.

# filesys encryption keys export

Data Domain esporta inoltre 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 in formato crittografato. Questo file può essere copiato da Data Domain e archiviato in una posizione sicura per essere utilizzato in qualsiasi condizione di ripristino di emergenza in un secondo momento.

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

# filesys encryption keys import <filename>

Domanda. La chiave generata da KMIP viene archiviata in Data Domain?

Risposta. Sì, la chiave di crittografia ottenuta da KMIP viene archiviata in modo crittografato in Data Domain.

Domanda. In che modo una modifica dello stato della chiave nell'appliance KMIP viene applicata a Data Domain?

Risposta. La sincronizzazione delle chiavi avviene quotidianamente. Se è disponibile una nuova chiave o se lo stato di una chiave viene modificato, la sincronizzazione aggiorna la tabella delle chiavi locali. Data Domain riceve gli aggiornamenti delle chiavi dal KMIP ogni giorno a mezzanotte.

Domanda. È possibile sincronizzare manualmente gli stati delle chiavi tra Data Domain e KMIP?

Risposta. Sì, è possibile utilizzare la CLI o l'interfaccia utente di Data Domain per sincronizzare manualmente gli stati delle chiavi tra Data Domain e KMIP. Il comando per questo è "filesys encryption keys sync'.

Domanda. È possibile modificare l'ora in cui Data Domain riceve gli aggiornamenti delle chiavi da KMIP?

Risposta. No, non è possibile modificare l'ora in cui Data Domain riceve gli aggiornamenti delle chiavi da KMIP.

Domanda. Esiste un limite al numero di chiavi archiviate in Data Domain?

Risposta. A partire da DDOS 7.8, il sistema Data Domain può avere un massimo di 1.024 chiavi. Nella finestra di dialogo è presente una sola chiave Activated-RW Stato; Tutte le altre chiavi possono essere in qualsiasi altro stato.

Domanda. È possibile utilizzare chiavi diverse per dataset diversi su Data Domain?

Risposta. No, Data Domain supporta una sola chiave attiva alla volta nel sistema. Tutti i dati in ingresso vengono crittografati utilizzando la chiave attiva corrente. Le chiavi non possono essere controllate con una granularità più fine (ad esempio per-mtree).

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 associati a una particolare chiave in Data Domain?

Risposta. Sì, può essere visualizzato su Data Domain, ma non sul server KMIP. La CLI e l'interfaccia utente di Data Domain consentono all'utente di visualizzare la quantità di dati associati a una particolare chiave. Il comando per questo è "filesys encryption keys show summary'.

Domanda. È possibile visualizzare l'età delle chiavi su Data Domain?

Risposta. Sì, è possibile visualizzare le chiavi EKM utilizzando l'interfaccia utente.

Domanda. La vecchia chiave funziona anche se è trascorso il periodo di tempo necessario per rendere effettiva la nuova chiave?

Risposta. Non esiste una data di scadenza per le chiavi di crittografia. Le chiavi precedenti diventano read-only dopo la rotazione delle chiavi e rimangono in DDOS.

Domanda. Le chiavi di crittografia vengono eliminate automaticamente quando non sono associate a dati in 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 Data Domain.

Domanda. È possibile eliminare una chiave anche se sono associati dati in Data Domain?

Risposta. No, se a una chiave sono associati dei dati, non può essere eliminata. I dati devono essere crittografati nuovamente 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 Data Domain.

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. È possibile utilizzare un server KMIP per tutti questi server. Si consiglia di avere una classe di chiave separata per ogni sistema Data Domain quando si utilizza lo stesso server KMIP.

Domanda. Se una chiave è compromessa, esiste 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. Quindi, in Data Domain:

Esegui 'filesys encryption keys sync'.
Esegui 'filesys encryption apply-changes'.
Avviare una pulizia del file system.
1. La pulizia esegue nuovamente la crittografia di tutti i dati crittografati con la chiave compromessa utilizzando una chiave più recente.
2. Al termine della pulizia, lo stato della vecchia chiave passa a Compromised-Destroyed.
Eliminare la chiave precedente.

Crittografia e replica

Domanda. La replica Data Domain è supportata e interoperabile con DARE?

Risposta. Sì, la replica Data Domain può essere utilizzata con DARE. Ciò consente di replicare i dati crittografati utilizzando tutti i diversi tipi di replica. Ogni tipo di replica funziona in modo univoco con la crittografia e offre lo stesso livello di sicurezza.

Domanda. Per utilizzare la crittografia, i sistemi di origine e di destinazione devono eseguire la stessa versione di DDOS?

Risposta. L'origine e la destinazione possono essere su versioni DDOS diverse per utilizzare DARE con la replica se sono compatibili per la replica (consultare la Guida all'amministrazione di Data Domain 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 è la replica mtree (MREPL) o la MFR (Managed File Replication):

DARE può essere concesso in licenza o abilitato sull'origine o sulla destinazione in modo indipendente a seconda di ciò che il cliente vuole ottenere.
Se la crittografia è abilitata sia nell'origine che nella destinazione:
- I dati acquisiti nell'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.
Quando la crittografia è disabilitata per l'origine e per la destinazione:
- I dati acquisiti nell'origine non sono crittografati.
- 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:
- 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 di destinazione.
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 non vengano applicate modifiche e non venga eseguita la pulizia sulla destinazione.

Se la replica configurata è la replica della raccolta (CREPL):

DDOS deve essere nella stessa versione di DDOS sia nei sistemi di origine che in quella di destinazione.
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 di destinazione nel suo stato crittografato.
- La destinazione ha la stessa chiave dell'origine poiché la replica della raccolta riguarda una replica esatta del sistema di origine.
- Nessun dato può essere scritto sulla destinazione al di fuori della replica, poiché la destinazione è un sistema read-only.
Se la crittografia è disabilitata sia nell'origine che nella destinazione:
- I dati acquisiti nel sistema di origine non sono crittografati.
- Durante la replica, l'origine invia i dati in uno stato non crittografato e rimane non crittografato nella destinazione.
- Nessun dato può essere scritto sulla destinazione al di fuori della replica, poiché la destinazione è un sistema read-only.

Domanda. La chiave della destinazione è archiviata a tempo indeterminato nel 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, lo stesso set di chiavi di crittografia è presente sia nell'origine che nella destinazione.

Domanda. È possibile abilitare la crittografia in un sistema di replica della raccolta dopo aver stabilito il contesto di replica?

Risposta. Sì, in questo caso la crittografia deve essere abilitata sia nell'origine che nella destinazione. Il contesto di replica deve essere disabilitato per configurare la crittografia. 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 DARE contemporaneamente alla funzione di crittografia over-the-wire per la replica di Data Domain?

Risposta. Sì, sia la crittografia over-the-wire (OTW) che DARE possono essere abilitate contemporaneamente per raggiungere obiettivi di sicurezza diversi.

Domanda. Cosa succede se la crittografia DARE e OTW sono abilitate contemporaneamente?

Risposta. L'origine crittografa innanzitutto i dati utilizzando la chiave di crittografia di destinazione. Poi, i dati già crittografati vengono crittografati una seconda volta dalla crittografia di OTW durante l'invio di questi dati alla loro destinazione. A destinazione, dopo che la decrittazione di OTW è stata eseguita, i dati vengono archiviati in un formato crittografato che è stato crittografato usando la chiave di crittografia della destinazione.

Domanda. Quando la crittografia è abilitata sia sull'origine che sulla destinazione, devono avere la stessa passphrase?

Risposta. Se la replica configurata è la replica della raccolta, la passphrase deve essere la stessa. Per altri tipi di replica (come MREPL, MFR), i sistemi possono avere passphrase diverse.

Domanda. Con la crittografia abilitata sulla destinazione, 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 sulla destinazione in modo che vengano crittografate solo le directory replicate?

Risposta. No, tutti i dati vengono crittografati nella destinazione, indipendentemente dal punto di ingresso. La crittografia può essere abilitata o disabilitata solo a livello di MTree o di directory. Ciò non è applicabile a CREPL.

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, la destinazione trasmette in modo sicuro all'origine le informazioni sull'algoritmo di crittografia corrente e sulla chiave. 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 Data Domain.

Domanda. Che tipo di algoritmo utilizza la crittografia OTW per crittografare il traffico di replica?

Risposta. Quando la modalità di autenticazione della replica è impostata su "one-way" o "two-way", viene utilizzato DHE (Ephemeral Diffie-Hellman) 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. "Two-way" indica che vengono verificati sia i certificati di origine che di destinazione. L'attendibilità reciproca deve essere stabilita prima di poter utilizzare questa 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 delle chiavi di sessione viene utilizzato Anonymous Diffie-Hellman (ADH). In questo caso, l'origine e la destinazione non si autenticano a vicenda prima dello scambio di chiavi. "Anonymous" viene utilizzato per impostazione predefinita se non è specificata la modalità di autenticazione.

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, ad eccezione della replica di directory (che non è più supportata) e della replica delta (nota anche come ottimizzazione della larghezza di banda bassa o LBO).

Domanda. Come viene protetta la chiave di crittografia della destinazione durante lo scambio di chiavi in assenza di certificati o coppie di chiavi PKI?

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 Data Domain desiderano stabilire un contesto di replica. Viene anche concordato attraverso uno scambio 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. Entrambi i sistemi in una coppia di replica devono utilizzare la stessa soluzione di gestione delle chiavi esterna (ad esempio la gestione delle chiavi KMIP) oppure uno dei sistemi può utilizzare una gestione delle chiavi esterna e l'altro può utilizzare la gestione delle chiavi integrata?

Risposta. A parte la 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. Tuttavia, solo l'origine sincronizza le chiavi con il key manager e anche queste chiavi vengono inviate alla destinazione. Con altri tipi di replica, è possibile utilizzare key manager diversi con l'origine e la destinazione.

Crittografia e migrazione

Domanda. La migrazione dei dati è supportata sui sistemi con DARE abilitato?

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 del tier attivo e del cloud tier è supportata con DARE abilitato?

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 il key manager, la passphrase di sistema e altre configurazioni di crittografia devono essere verificate e abbinate manualmente per una corretta migrazione dei dati. Anche tutti i certificati di gestione delle chiavi esistenti vengono trasferiti al sistema di destinazione. La configurazione del key manager di crittografia deve essere configurata nuovamente sul sistema di destinazione dopo la migrazione.

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, 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 (è richiesto l'accesso al supporto Dell) descrive in dettaglio i passaggi per la migrazione tra sistemi con cloud abilitato. Le stesse impostazioni si applicano anche per la migrazione del tier attivo.

Domanda. È supportata la migrazione tra sistemi EDP?

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 OTW è esplicitamente disabilitata utilizzando il comando MIGRATION_ENCRYPTION parametro di sistema.

Crittografia e Cloud Tier

Domanda. La crittografia è supportata per il Cloud Tier?

Risposta. Sì, la crittografia è supportata per Cloud Tier. Questa opzione è disabilitata per impostazione predefinita. Il 'cloud enable' prompt dei comandi per scegliere se abilitare o meno 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 ai tier attivi che ai cloud tier in Data Domain. Quando è abilitata la crittografia, le chiavi vengono copiate sulla rispettiva unità, tier o partizione di raccolta. Se la crittografia è abilitata su cloud attivo e non su cloud, le chiavi di tier attive non si riflettono su cloud e viceversa. Ciò vale anche per le unità cloud. Ad esempio: se cp1 ha la crittografia abilitata e cp2 Non ha abilitato la crittografia, allora cp1 i tasti non si riflettono su cp2.

Domanda. È possibile eliminare le chiavi dal 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 collection partition (CP)e ogni unità cloud è un CP diverso. Una copia delle chiavi di tutti i CP viene memorizzata nella partizione attiva.

Domanda. Come si ripristinano le chiavi cloud durante il ripristino di emergenza?

Risposta. La colonna cpnameval viene eseguito il mirroring nel cloud come parte del ripristino del CP e le chiavi di crittografia vengono ripristinate in cpnameval. Quindi, il ddr_key_util per recuperare le chiavi.

Nota: Il ripristino di emergenza richiede l'assistenza del Supporto clienti.

Domanda. Lo spostamento dei dati può essere eseguito quando la crittografia è abilitata solo per il Cloud Tier?

Risposta. No, per consentire l'esecuzione dello spostamento dei dati, la crittografia deve essere abilitata sia nel Cloud Tier che nel tier attivo.

Domanda. È possibile utilizzare un gestore di chiavi esterno con Cloud Tier?

Risposta. Sì, il gestore delle chiavi esterno può essere utilizzato con Cloud Tier. Questa funzione è supportata da DDOS 7.8 in poi. Tutte le operazioni (ad eccezione della distruzione o dell'eliminazione di una chiave utilizzata per il tier attivo) sono valide anche per Cloud Tier in termini di gestore di chiavi esterno.

Crittografia e garbage collection

Domanda. Qual è il ruolo del processo di garbage collection (GC) in DARE? Si verifica un impatto sulle prestazioni quando si abilita la crittografia per la prima volta?

Risposta. L'abilitazione di DARE per la prima volta ha un impatto sulle prestazioni di GC. Durante l'esecuzione di GC, legge i dati dai container esistenti su disco e li scrive in nuovi container. Dopo aver abilitato DARE, tali dati potrebbero richiedere la lettura, la decrittografia e la decompressione prima di essere ricompressi, crittografati e scritti nuovamente su disco. Quando la crittografia è abilitata su un Data Domain contenente una quantità significativa di dati preesistenti e l'opzione 'filesys encryption apply-changes', il ciclo GC 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 GC dopo l'esecuzione di "filesys encryption apply-changes' potrebbe richiedere più tempo del normale. Assicurarsi che dispongano di spazio libero sufficiente sul sistema Data Domain per consentire l'esecuzione della pulizia fino al completamento senza che il sistema Data Domain si riempia (in caso contrario i backup non riescono).

Domanda. C'è un impatto sulle prestazioni dei cicli puliti in corso?

Risposta. Sì, si verifica un impatto sulle prestazioni. L'impatto dipende in genere dalla quantità di dati acquisiti e 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. Se un sistema Data Domain con DARE configurato viene sottoposto a un headswap, i dischi sono ancora accessibili con la nuova unità head?

Risposta. La chiave di crittografia non è associata all'intestazione del sistema Data Domain stessa, pertanto i dischi possono essere spostati in un'altra intestazione Data Domain e la chiave è ancora accessibile lì. Il file system è bloccato sul nuovo head e deve essere sbloccato con il comando 'filesys encryption unlock' e la passphrase di sistema.

Domanda. Cosa succede se la passphrase viene persa al momento dell'operazione headswap?

Risposta. Se la passphrase viene persa, collegare la vecchia testina e collaborare con il supporto per ripristinare la passphrase. Quindi riconnettersi alla nuova head head e completare la procedura di headswap.

Crittografia e prestazioni

Domanda. Qual è l'impatto osservato sul consumo di storage quando si utilizza DARE?

Risposta. L'impatto sull'utilizzo dello storage è 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 si usa DARE?

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 in scrittura
Incrementale: ~5% di peggioramento delle prestazioni in scrittura
Ripristina: Riduzione delle prestazioni in lettura dal 5 al 20%

Modalità GCM

Primo pieno: Riduzione delle prestazioni del 10-20% sulle scritture
Incrementale: Riduzione delle prestazioni del 5-10% sulle scritture
Ripristina: Riduzione delle prestazioni in lettura dal 5 al 20%

Questi numeri sono specifici per l'overhead della crittografia dei dati inattivi. La crittografia over-the-wire viene considerata 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. 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 è settimanale. quando KMIP è configurato solo per il tier attivo, la policy di rotazione delle chiavi consigliata è mensile. Tuttavia, questo può essere aumentato o diminuito in base al tasso di ingestione. Se è configurato il key manager integrato, è consigliata 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 lo stesso server KMIP viene utilizzato per molti Data Domain?

Risposta. Si consiglia di avere una classe di chiave separata per ogni Data Domain quando si utilizza lo stesso server KMIP. In questo modo, la rotazione delle chiavi eseguita su un sistema non influisce sullo stato della chiave presente in altri sistemi.

Informazioni aggiuntive

Altra documentazione relativa a Data Domain Encryption (Guida dell'amministratore, Guida di riferimento ai comandi e Guida alla configurazione della sicurezza) è disponibile qui: Documenti principali su PowerProtect e Data Domain

Guardare questo video: