Dell EMC Data Domain Encryption – Často kladené dotazy

Konfigurace šifrování

Otázka: Jak je v systému DD nakonfigurováno šifrování (DARE)?
Odpověď: Nástroj DARE Encryption lze nakonfigurovat v systému DD následovně:

1. Přidat licenci šifrování

2. Přidat bezpečnostního pracovníka a povolit oprávnění bezpečnostního pracovníka

3. Povolit šifrování 

1) Přidejte šifrovací licenci:
Mějte licenční soubor s přidanou platnou šifrovací licencí.
Pomocí níže uvedeného příkazu aktualizujte elicense v systému DD pomocí dostupného licenčního souboru.

Aktualizace eLicense

2) Přidejte bezpečnostního pracovníka a povolte oprávnění SO:
a) Přidejte uživatele s rolí "security" pomocí příkazu: 

Uživatel Přidat zabezpečení role sekundáře

b) Povolte v nastavení oprávnění bezpečnostního pracovníka pomocí příkazu: 

Authorization Policy Set Security-Officer Enabled

3. Povolit šifrování DARE:
Povolte šifrování DARE pomocí příkazu:

Povolení šifrování FileSys

Otázka: Které platformy jsou podporovány funkcí šifrování dat v klidu?
Odpověď: Funkce šifrování dat v klidu je podporována ve všech systémech Data Domain s výjimkou systémů EDP (Encryption Disablement Project).

Otázka: Jak může uživatel ukládat svá data v systému DD jako prostý text?
Odpověď: Uživatel může zajistit, že data budou v systému DD uložena jako prostý text a nebudou šifrována, a to potvrzením, že je v nastavení možnost Šifrování vypnuta.
Uživatelé mohou zakázat šifrování v systému DD pomocí příkazu: 

Zakázání šifrování filesys

Otázka: Které zálohovací aplikace/protokoly jsou podporovány funkcí šifrování dat v klidu?
Odpověď: Funkce DD DARE je nezávislá na základní zálohovací aplikaci nebo protokolu používaném systémem DD.

Otázka: Jaké šifrovací algoritmy lze vybrat v systému Data Domain?
Odpověď: Software DD Encryption podporuje 128bitový nebo 256bitový algoritmus AES pomocí funkce CBC (Cipher Block Chaining) nebo GCM (Galois Counter Mode). 

GCM je provozní režim pro kryptografické blokové šifry se symetrickým klíčem. Jedná se o ověřený šifrovací algoritmus navržený tak, aby poskytoval jak autentizaci, tak soukromí (důvěrnost). Jak název napovídá, GCM kombinuje známý režim šifrování čítače s novým režimem autentizace Galois. Aspekt ověřování GCM zaručuje, že data, která byla zašifrována, byla zašifrována systémem Data Domain a nebyla "vložena" jiným způsobem. To se liší od CBC, kde jsou data šifrována (aspekt ochrany osobních údajů), ale neexistuje žádná kontrola pravosti šifrovaných dat.

V režimu CBC je každý blok prostého textu před šifrováním exkluzivně nebo s předchozím blokem šifrovaného textu. Tímto způsobem je každý blok šifrovaného textu závislý na všech blocích prostého textu, které byly do té doby zpracovány. Aby byla každá zpráva jedinečná, musí být v prvním bloku použit inicializační vektor. CBC zaručuje soukromí (důvěrnost) dat pouze prostřednictvím šifrování. Neprovádí se žádné ověření šifrovacího algoritmu nebo procesu.

Otázka: Jak můžeme změnit šifrovací algoritmus v systému DD?

Odpověď: Pokud chcete v nastavení nastavit konkrétní šifrovací algoritmus, použijte níže uvedený příkaz.

Sada šifrovacích algoritmů FileSys

Příklad:

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

Otázka: Jak zajistíme, aby se šifrování provádělo u již existujících dat, jakmile je šifrování povoleno?
Odpověď: Pomocí následujícího příkazu můžeme vynutit, aby DDFS zašifroval stávající data:

# filesys encryption apply-changes

Díky tomu je další cyklus čištění podstatně delší a náročnější na zdroje než obvykle.

Otázka: Jak deaktivujeme šifrování v DD?
Odpověď: Zakažte funkci šifrování v systému DD pomocí příkazu encryption disable: 

Zakázání šifrování filesys

Tím se zakáže pouze šifrování příchozích vstupně-výstupních operací. Stávající zašifrovaná data zůstanou zašifrovaná, dokud je ručně nedešifrujete pomocí příkazu apply-changes.

Otázka: Které šifrovací příkazy vyžadují restartování systému souborů DD, aby se projevily?
Odpověď: Následující šifrovací příkazy vyžadují restartování systému souborů DD, aby se projevily:

Povolení/zakázání šifrování FileSys – Povolí/zakáže šifrování v systému Data Domain.

Sada šifrovacích algoritmů FileSys – Povolí uživateli vybrat kryptografický algoritmus.

Resetování šifrovacího algoritmu FileSys - Resetuje šifrovací algoritmus na AES 256 v režimu CBC (výchozí).

Otázka: Které šifrovací příkazy vyžadují zakázání systému souborů Data Domain, aby je bylo možné nastavit nebo používat?
Odpověď: Následující šifrovací příkazy vyžadují zakázání systému souborů Data Domain, aby je bylo možné nastavit nebo používat:

Změna šifrovacího přístupového hesla

Šifrovací zámek/odemknutí

Obecné dotazy k šifrování

Otázka: Je šifrování DD podporováno ve všech systémech DD?
Odpověď: Možnost softwaru DD Encryption je podporována v systémech DD, pokud se nejedná o projekt zakázání šifrování (EDP), což jsou systémy, které neumožňují aktivaci šifrování, prodávané hlavně v systémech v regionu Ruska.

Otázka: Jak se provádí kryptografie v systémech DD?
Odpověď: Kryptografie se provádí pomocí knihoven OpenSSL a RSA BSafe (RSA BSafe je kryptografická knihovna ověřená standardem FIPS 140-2, kterou systémy DD používají k šifrování dat v klidu) v systému DDOS. 

Otázka: Jakou verzi BSafe se v systému používá?
Odpověď: Od systému DDOS 7.10 se používají verze BSafe "BSAFE Micro Edition Suite 4.4.0.0" a "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Otázka: Jaká uživatelská rozhraní jsou k dispozici pro konfiguraci šifrování v systému DDOS?
Odpověď: Šifrování lze nakonfigurovat pomocí rozhraní příkazového řádku, uživatelského rozhraní nebo rozhraní REST API. Podpora rozhraní REST API byla přidána od verze DDOS 8.0 a novější.

Otázka: Je možné selektivní šifrování dat? Líbí se vám pouze jeden fond MTree nebo soubor?
Odpověď: Selektivní šifrování NENÍ možné. Šifrování lze povolit nebo zakázat pouze v celém systému, nikoli selektivně. U systémů s podporou cloudu lze šifrování povolit nebo zakázat v rámci granularity vrstvy cloudu a cloudové jednotky.  

Otázka: Jsou kryptografické klíče nebo hesla účtů přenášena nebo ukládána ve formátu prostého textu nebo pod slabými šiframi, například při ověřování entity, v datovém souboru, v programech nebo v adresářích ověřování?
Odpověď: Rozhodně ne.

Otázka: Jakou verzi OpenSSL se v systému používá?
Odpověď: Od vydání DDOS 7.10 je verze openssl "OpenSSL 1.0.2zd-fips"

Otázka: Jak šifrování dat v klidu chrání před přístupem uživatelů a aplikací k datům?
Odpověď: 

• Šifrování dat v klidu spočívá v šifrování dat, která jsou uložena v podsystému disku. Šifrování nebo dešifrování probíhá v kompresní vrstvě. Uživatelé nebo aplikace odesílají a přijímají data ve formátu prostého textu do systému Data Domain, ale veškerá data fyzicky uložená v systému Data Domain jsou šifrována.
• Veškeré šifrování probíhá pod systémem souborů a oborem názvů a je pro uživatele nebo aplikace neviditelné. Pokud uživatel nebo aplikace již má autorizovaný přístup k souboru nebo adresáři, lze data číst v nativním formátu bez ohledu na šifrování.
• DD Encryption je navrženo tak, že pokud narušitel obejde jiné kontroly zabezpečení sítě a získá přístup k šifrovaným datům bez správných kryptografických klíčů, data jsou pro tuto osobu nečitelná a nepoužitelná. 

Otázka: Bude šifrování probíhat i po deduplikaci?
Odpověď: Ano, šifrování probíhá u deduplikovaných dat. Data jsou před uložením na disk zašifrována. 

Otázka: Jak systém Data Domain zajišťuje zabezpečení dat?
Odpověď: Data jsou zabezpečena pomocí funkce šifrování dat v klidu. Kromě toho je při odebrání zařízení (výměna hlavy, zámek souborového systému) ze systému odstraněno heslo. Toto heslo se používá k šifrování šifrovacích klíčů, takže data jsou dále chráněna.

Otázka: Jaké výstrahy se generují šifrováním?
Odpověď: Výstrahy se generují v následujících případech:

• Pokud jsou přítomny ohrožené šifrovací klíče
• Když je tabulka šifrovacích klíčů plná a do systému nelze přidat žádné další klíče.
• Když se automatický export klíčů nezdaří
• Když automatická výměna klíčů selže
• Když je šifrování zakázáno
• Při změně systémového přístupového hesla

Otázka: Existuje pro systém DDOS nějaká certifikace zabezpečení? 
Odpověď: Systémy Data Domain splňují normu FIPS 140-2. 

Otázka: Kde je uložen šifrovací klíč?
Odpověď: Šifrovací klíče jsou trvale uloženy v oddílu kolekce v systému DDOS.

Otázka: Pokud někdo vytáhne pevný disk ze systému Data Domain, můžete z něj dešifrovat data?
Odpověď: Šifrovací klíče jsou šifrovány pomocí systémového přístupového hesla, které je uloženo v hlavě systému. I když jsou šifrovací klíče uloženy na disku, bez systémového přístupového hesla nelze šifrovací klíče dešifrovat. Bez znalosti klíče, který byl použit k šifrování dat, tedy není dešifrování z pevného disku možné.  

Otázka: Jaké kryptografické klíče a hesla jsou potřeba pro obnovení, zejména pro zotavení po havárii?
Odpověď: Klíče lze exportovat v zabezpečeném souboru a uchovávat mimo systém. Obnova tohoto souboru se provádí pomocí technického oddělení. Také v době obnovení musí zákazník znát přístupové heslo, které použil při zadání příkazu k exportu klíčů.

Otázka: Jak uzamknout systém souborů před přenosem systému do vzdáleného umístění.
Odpověď: Níže je uveden postup: 

• Zakažte systém souborů:

  sysadmin@itrdc-DD630-42# filesys zakázání

• Uzamkněte systém souborů a zadejte novou přístupovou frázi (vyžaduje ověření výše uvedeným bezpečnostním uživatelem):

  sysadmin@itrdc-DD630-42# filesys encryption lock
  Tento příkaz vyžaduje autorizaci uživatelem s rolí "security".
  Níže předložte přihlašovací údaje takového uživatele.
          Uživatelské jméno: secuser
  Heslo:
  Zadejte aktuální heslo:
  Zadejte nové heslo:
  Znovu zadejte nové heslo:
  Přístupová hesla se shodují.
  Systém souborů je nyní uzamknutý.

• Nové heslo NESMÍ být ztraceno nebo zapomenuto. Bez tohoto přístupového hesla nelze systém souborů odemknout, což znamená, že k datům v zařízení DDR nelze přistupovat. Chcete-li systém odemknout, když se dostane na vzdálené místo, použijte níže uvedené příkazy:

sysadmin@itrdc-DD630-42# filesys šifrování odemknout
Tento příkaz vyžaduje autorizaci uživatelem, který má roli "security".
Níže předložte přihlašovací údaje takového uživatele.
        Uživatelské jméno: secuser
Heslo:
Zadejte heslo:
Heslo bylo ověřeno. Použijte 'filesys enable' pro spuštění souborového systému.

• Systém souborů lze nyní povolit a používat jako obvykle.

Otázka: Má příkaz storage sanitize nějakou souvislost se šifrováním systému souborů?
Odpověď: Ne, šifrování systému souborů a vymazání úložiště jsou dvě nezávislé funkce. 

Otázka: Je v systému EDP (Encryption Disablement Project) podporováno šifrování po drátě?
Odpověď: V systému EDP nelze povolit šifrování dat v klidu (DARE) nebo šifrování po drátě (s replikací nebo pomocí ddboost).

Systémové heslové heslo 

Otázka: Co je systémové přístupové heslo?
Odpověď: Systém DDOS má možnost zabezpečit přihlašovací údaje v systému nastavením přístupového hesla na úrovni systému. Přístupové heslo je člověkem čitelný (srozumitelný) klíč, jako je čipová karta, který se používá k vygenerování strojově použitelného šifrovacího klíče AES 256. 

Poskytuje dvě výhody:

• Umožňuje správci změnit přístupové heslo, aniž by musel manipulovat se šifrovacími klíči. Změna přístupového hesla nepřímo změní šifrování klíčů, ale neovlivní uživatelská data. Změna přístupového hesla nezmění základní šifrovací klíč systému Data Domain. Změní šifrování systémového klíče Data Domain, ale systémový klíč zůstane stejný.
• Umožňuje dodávat fyzický systém Data Domain se šifrovacím klíčem, ale bez uložení přístupového hesla. Tímto způsobem, pokud je box odcizen během přepravy, útočník nemůže snadno obnovit data, protože systém má pouze šifrované klíče a šifrovaná data.

Heslo je interně uloženo ve skryté části úložného systému Data Domain. To umožňuje systému Data Domain spustit se a pokračovat v přístupu k datům bez zásahu správce.

Vytvoření nebo změna přístupového hesla:

• Přístupové heslo k systému lze vytvořit pomocí rozhraní příkazového řádku poté, co se správce ověří v systému Data Domain.
• Přístupové heslo k systému lze změnit pomocí rozhraní příkazového řádku poté, co se správce a uživatel s bezpečnostní rolí (např. bezpečnostní pracovník) ověří v systému Data Domain (takže žádný správce nemůže provádět změny nezávisle).

Otázka: Kdy se heslo používá?
Odpověď: Systémové přístupové heslo je používáno jako primární klíč různými komponentami DDOS, mezi které patří šifrování systému souborů, přístup ke cloudu, správa certifikátů, tokeny Boost, moduly konfigurace systému ve škálovaných prostředích a informace o licencích. Software DDOS poskytuje mechanismy pro nastavení a úpravu tohoto systémového hesla. Poskytuje také možnosti ovládání, zda bude systémové heslo uloženo na disku, což se používá zejména pro zvýšení zabezpečení při přenosu systému DD. 

Otázka: Jak se používá přístupové heslo pro zabezpečený přenos systému DD?
Odpověď: Proces používá příkaz "filesys encryption lock", který uživateli umožňuje uzamknout systém souborů změnou přístupového hesla. Uživatel zadá nové heslo, které znovu zašifruje šifrovací klíč, ale nové heslo se neuloží. Šifrovací klíče nelze obnovit, dokud systém souborů neodemknete pomocí příkazu

"filesys encryption unlock".Proces je popsán v příručce Confluence Lab Security Configuration Guide.

Otázka: Co se stane, když se heslo změní? Lze stále přistupovat k datům?
Odpověď: Ano, změna přístupového hesla nezmění základní šifrovací klíč systému Data Domain, ale pouze šifrování šifrovacího klíče. Proto není ovlivněn přístup k datům.

Otázka: Jak se můžeme dotázat, zda je v systému nastaveno přístupové heslo?
Odpověď: Je-li v systému nastaveno přístupové heslo, spuštění příkazu "system passphrase set" vyvolá chybu informující, že přístupové heslo je již nastaveno.

Otázka: Co se stane, když heslo ztratíte nebo zapomenete?
Odpověď: Pokud zákazník ztratí přístupové heslo v době, kdy je box uzamčen, ztratí svá data. Neexistují žádná zadní vrátka ani alternativní způsob, jak se k němu dostat. Bez dobrého procesu pro správu tohoto přístupového hesla by k tomu mohlo dojít omylem a uživatelé by nemohli obnovit klíč nebo data. Šifrovaný klíč však nemůže být nikdy ztracen nebo poškozen kvůli integrovaným ochranným mechanismům systému.

Otázka: Existuje nějaký mechanismus pro resetování zapomenuté systémové přístupové fráze?
Odpověď: Přístupové heslo k systému lze vynuceně resetovat pouze v určitých situacích s pomocí zákaznické podpory. Mechanismus vynucené aktualizace zavedený v systému DDOS 7.2 lze k tomuto účelu použít pouze v případě, že jsou splněny specifické podmínky. Další podrobnosti najdete v článku znalostní databáze 20983 Data Domain: Jak resetovat ztracené systémové heslo v systému DDOS v7.2 nebo novějším (pro zobrazení článku je vyžadováno přihlášení k podpoře společnosti Dell)

Otázka: Existuje možnost, jak se vyhnout ukládání systémového přístupového hesla v systému DD?
Odpověď: Systémové heslo je ve výchozím nastavení uloženo na skrytém místě v systému Data Domain. Systémová možnost "system passphrase option store-on-disk" může být použita ke změně nastavení, aby se vyhnula ukládání přístupového hesla na disk.

Správce vestavěných klíčů (EKM)

Příkaz nejvyšší úrovně:

Možnost system# filesys encryption embedded-key-manager <>

Otázka: Je v nástroji Embedded Key Manager podporována obměna klíčů?
Odpověď:  Ano, obměna klíčů podle systému Data Domain je podporována nástrojem Embedded Key Manager. Prostřednictvím uživatelského rozhraní nebo rozhraní příkazového řádku může správce nastavit období střídání klíčů (týdenní nebo měsíční).

Otázka: Platí se za integrovanou správu klíčů nějaký poplatek?
Odpověď: Tato funkce není zpoplatněna. Tato funkce je součástí standardní licence softwaru DD Encryption.

Otázka: Může zákazník přejít z lokální správy klíčů na externí správu klíčů (EKM)?
Odpověď

• Ano, externí správce klíčů lze povolit kdykoli. Aktuálně používané lokální klíče však v systému Data Domain zůstanou. Externí správci klíčů nemohou spravovat klíče EKM. Existující data nevyžadují opětovné šifrování. Pokud u zákazníka musí být data o kompatibilitě znovu zašifrována pomocí klíčů EKM, je to nutné provést ručně pomocí příkazu apply-changes s novým klíčem RW. Zničení klíčů EKM po přepnutí není povinné.
  • Přepínač key-manager automaticky přepne aktivní klíč na klíč z KMIP. 
  • Příklad toho, jak vypadá identifikátor MUID klíče KMIP při přepnutí

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

Otázka: Co se stane, když je střídání klíčů zakázáno nebo povoleno?
Odpověď: 

• Pokud nepovolíte střídání klíčů v uživatelském rozhraní nebo rozhraní příkazového řádku, je tato funkce šifrování zakázána. V takovém scénáři se všechna data šifrují pomocí stávajícího aktivního klíče.
• Pokud je povolená obměna klíčů, na základě frekvence rotace klíče obměňujeme a data jsou šifrována nejnovějším aktivním klíčem.

Správci externích klíčů

Otázka: Jaké nástroje External Key Manager podporuje systém DD?
Odpověď: Podporujeme níže uvedené externí klíčové manažery:

• Gemalto KeySecure (podpora přidána ve verzi DDOS 7.2)
• Vormetric (podpora přidána v DDOS verze 7.3)
• CipherTrust (podpora přidána ve verzi DDOS 7.7)
• IBM GKLM (podpora přidána ve verzi DDOS 7.9)

Otázka: Je pro integraci s externím nástrojem Key Manager vyžadována samostatná licence?
Odpověď: Ano, k integraci External Key Manageru do systému DD je potřeba samostatná licence od příslušného dodavatele.

Otázka: Kolik klíčových manažerů podporuje najednou?
Odpověď: V systému DD může být v daném okamžiku aktivní pouze jeden správce kláves.

Otázka: Kde najdu další informace o konfiguraci nástroje KMIP External Key Manager?
Odpověď: Průvodce integrací protokolu KMIP pro systém DDOS obsahuje podrobné informace o konfiguraci různých externích správců klíčů podporovaných systémem DD.

Otázka: Jak se spravují certifikáty pro správce externích klíčů v systému DD?
Odpověď: Při konfiguraci External key manager je třeba vygenerovat certifikát CA (certifikát CA může být podepsaný držitelem nebo podepsaný třetí stranou) a hostitelský certifikát. Po dokončení konfigurace na serveru External Key Manager musí uživatelé importovat certifikát certifikační autority a hostitelský certifikát do systému DD. Poté nakonfigurujeme a povolíme externího správce klíčů. 

Otázka: Co je certifikační autorita?
Odpověď: Certifikační autorita (CA) funguje jako původně důvěryhodná sdílená entita mezi partnery a vydává podepsané certifikáty, aby obě strany mohly důvěřovat druhé straně. Certifikát obecně funguje jako identita serveru nebo klienta. 

Otázka: Co je certifikát podepsaný místní certifikační autoritou, co je certifikát podepsaný certifikační autoritou?
Odpověď: Certifikát podepsaný certifikační autoritou je certifikát, který byl vydán a podepsán veřejně důvěryhodnou certifikační autoritou (CA). Certifikát podepsaný certifikační autoritou je automaticky důvěryhodný. Místní certifikační autorita může vydávat podepsané certifikáty, protože soukromý podpisový klíč je uložen v systému Key Manager. Externí certifikační autorita neukládá soukromý klíč. Místo toho se externí certifikační autorita používá jako důvěryhodná entita pro různá rozhraní a služby uvnitř systému.

Otázka: Jak vytvořit žádost o podpis certifikátu v systému DD?
Odpověď: V systému Data Domain vygenerujte CSR pomocí níže uvedeného příkazu CLI. Tímto způsobem není soukromý klíč nikdy vystaven externímu správci klíčů.

Žádost o podepisování certifikátu AdminAccess

Otázka: Je možné přepínat mezi Key Managery?
Odpověď: Přepínání mezi External Key Managerem a Embedded Key Manager je povoleno a je bezproblémové. Přechod z integrovaného správce klíčů na externí správce klíčů však vyžaduje instalaci a konfiguraci příslušného certifikátu. Přepínání mezi dvěma správci externích klíčů (například: Povoleny jsou také KMIP-CipherTrust, DSM-CipherTrust, CipherTrust až GKLM). Podporována je také migrace klíčů správce klíčů (další podrobnosti naleznete v průvodci integrací protokolu KMIP).

Otázka: Co se stane, když dojde k výpadku připojení externího Key Manageru? Jsou tedy moje data přístupná?
Odpověď: Ano, data jsou stále přístupná, i když se nemůžeme připojit ke správci klíčů, protože kopie klíčů ukládáme také do systému DD. Pokud není k dispozici připojení k externímu nástroji Key Manager, nelze vytvářet nové klíče nebo synchronizovat stavy klíčů.

Otázka: Existuje způsob, jak se vyhnout ukládání klíčů v DD a ukládat pouze v External Key Manager?
Odpověď: V systému DD vždy ukládáme kopii klíčů pro účely DIA. Toto nastavení nelze změnit.

Otázka: Má integrace s protokolem KMIP nějaký dopad na výkon?
Odpověď: Ne, použití externích správců klíčů nemá žádný vliv na výkon.

Otázka: Je možné využít řešení KMIP pro vybrané datové domény v rámci prostředí?
Odpověď: Ano, zákazníci mají naprostou flexibilitu při výběru vhodné metody šifrování pro své systémy Data Domain. V některých systémech Data Domain mohou nadále využívat integrovaného správce klíčů Data Domain a v jiných systémech Data Domain v rámci svého prostředí výměnu šifrovacích klíčů pomocí protokolu KMIP.

Otázka: Je komunikace mezi Data Domain a KMIP bezpečná?
Odpověď: Ano, systém Data Domain komunikuje prostřednictvím vzájemně ověřených relací certifikátu X509 s protokolem TLS. Uživatel může pomocí rozhraní příkazového řádku Data Domain importovat příslušný certifikát X509 do systému Data Domain. Tento certifikát se pak použije k vytvoření zabezpečeného kanálu mezi DD a KMIP.

Správa životního cyklu klíčů 

Otázka: Jaké možnosti správy klíčů jsou k dispozici u možnosti DD Encryption?
Odpověď: Správce klíčů řídí generování, distribuci a správu životního cyklu více šifrovacích klíčů. Systém ochrany může používat buď integrovaného správce klíčů, nebo správce externích klíčů KMIP. V jednom okamžiku může být v platnosti pouze jeden správce klíčů. Pokud je v systému ochrany povoleno šifrování, je ve výchozím nastavení aktivní Správce integrovaných klíčů. Pokud je nakonfigurován nástroj External Key Manager, nahrazuje integrovaného správce klíčů a zůstává v platnosti, dokud jej ručně nezakážete. Přepnutím z režimu Embedded Key Manager na External Key Manager nebo naopak bude do systému přidán nový klíč, který od verze 7.1 nevyžaduje restart systému souborů.

Otázka: Jaké jsou různé stavy klíčů v systému Data Domain?
Různé stavy klíčů v systému Data Domain jsou následující:

• Aktivované – RW: V každém systému DD je v tomto stavu pouze jeden klíč, který se používá pro čtení a zápis dat. Tento klíč také používá proces uvolňování paměti k opětovnému šifrování kontejnerů.
• Čeká na aktivaci: V tomto stavu je v každém systému DD pouze jeden klíč. Tento klíč identifikoval klíč, který se po příštím restartu systému souborů změní na Activated-RW. Dnes tento stav existuje pouze v době povolení šifrování. Žádný jiný klíč nečekající na aktivaci se nevytvoří.  
• Aktivováno – RO: Externí správci klíčů mohou mít více aktivovaných klíčů. Nejnovější klíč je v režimu Activated – RW, ostatní jsou v tomto stavu. Klíče mohou v systému DD přejít do tohoto stavu, když nelze synchronizovat stav se správcem klíčů.
• Deaktivoval: Slouží ke čtení existujících dat v systému DD.
• Udělal kompromis: Když zákazník ohrožuje externí klíč správce klíčů, stav se změní na tento klíč po další synchronizaci klíčů.  
• Označeno za zničené: Když zákazník označí klíč ke zničení, stav klíče se změní na označený za zničený. Po spuštění uvolňování paměti se všechny kontejnery šifrované pomocí klíčů s označením Marked-For-Destroyed znovu zašifrují pomocí klíče Activated-RW.
• Zničený: Klíč ve stavu Marked-For-Destroyed přejde do tohoto stavu, pokud k němu nejsou přidružena žádná data.
• Zničené a ohrožené: Klíč v ohroženém stavu přejde do tohoto stavu, když k němu nejsou přidružená žádná data.

Otázka: Je možné exportovat šifrovací klíče pro zotavení po havárii?
Odpověď: Klíče lze exportovat ručně pomocí níže uvedeného příkazu.

"filesys encryption keys export"

Systém DD také ve výchozím nastavení exportuje klíče, když je přidán nový klíč nebo když je jakýkoli klíč ze systému odstraněn.

Exportované soubory se nacházejí ve složce /ddr/var/.security a ta je v šifrovaném formátu. Tento soubor by měl být zkopírován z zařízení DDR a uložen na bezpečném místě, které lze později použít při jakémkoli zotavení po havárii.

Poznámka: Import klíčů pro zotavení po havárii vyžaduje zásah zákaznické podpory, protože proces obnovení závisí na typu havárie, ke které došlo. Exportovaný soubor klíče můžeme importovat pomocí následujícího příkazu.

filesys encryption keys import <názevsouboru> 

Otázka: Je klíč vygenerovaný protokolem KMIP uložen v systému Data Domain?
Odpověď: Ano, šifrovací klíč získaný z protokolu KMIP je v systému Data Domain uložen šifrovaným způsobem.

Otázka: Jak se změna stavu klíče v zařízení KMIP aplikuje na systém Data Domain?
Odpověď: Synchronizace klíčů probíhá denně. Pokud je k dispozici nový klíč nebo se změní stav klíče, synchronizace aktualizuje místní tabulku klíčů. Systém DD dostává důležité aktualizace z KMIP každý den o půlnoci.

Otázka: Je možné ručně synchronizovat stavy klíčů mezi DD a KMIP?
Odpověď: Ano, rozhraní příkazového řádku nebo uživatelské rozhraní Data Domain lze použít k ruční synchronizaci stavů klíčů mezi DD a KMIP. Používá se k tomu příkaz "filesys encryption keys sync".

Otázka: Je možné změnit čas, kdy systém DD obdrží aktualizace klíčů z protokolu KMIP?
Odpověď: Ne, není možné změnit čas, kdy systém DD obdrží aktualizace klíčů z protokolu KMIP.

Otázka: Existuje nějaké omezení počtu klíčů podporovaných systémem Data Domain?
Odpověď: Od verze DDOS 7.8 může mít systém Data Domain v systému maximálně 1024 klíčů. V aktivovaném RW je pouze jeden klíč a zbývající klávesy mohou být v jakémkoli jiném stavu.

Otázka: Lze v systémech Data Domain použít různé klíče pro různé datové sady? Je to konfigurovatelné?
Odpověď: Ne, v systému podporujeme vždy pouze jeden aktivní klíč a všechna příchozí data jsou šifrována pomocí aktuálního aktivního klíče. Klíče nelze ovládat s jemnější členitostí jako M-stromy.

Otázka: Přijde nějaké oznámení, když je dosaženo maximálního počtu klíčů?
Odpověď: Ano, při dosažení maximálního limitu klíčů 1024 se zobrazí výstraha.

Otázka: Jak mohu vymazat výstrahu ohledně maximálního počtu klíčů?
Odpověď: Aby bylo možné vymazat výstrahu maximálního limitu klíčů, je nutné odstranit jeden z klíčů.

Otázka: Je možné zobrazit množství dat spojené s konkrétním klíčem v systému Data Domain?
Odpověď: Ano, tento problém se projevuje v systému DD, ale není zobrazen na serveru KMIP. Uživatel může pomocí rozhraní příkazového řádku a uživatelského rozhraní systému Data Domain zobrazit množství dat spojených s konkrétním klíčem.

Otázka:  Je stáří klíčů v systému DD?
Odpověď: Ano, je to vidět u klíčů EKM pomocí uživatelského rozhraní.

Otázka: Funguje starý klíč i v případě, že uplynula lhůta, během níž byl nový klíč účinný?
Odpověď: U šifrovacích klíčů není stanoveno žádné datum vypršení platnosti. Staré klíče se po obměně klíčů změní na klíče pouze pro čtení a zůstanou v systému DDOS.

Otázka: Odstraní se šifrovací klíč automaticky, když k němu v systému Data Domain nejsou žádná data?
Odpověď: Ne, klíč se automaticky neodstraní. Uživatel musí klíč explicitně odstranit pomocí rozhraní příkazového řádku nebo uživatelského rozhraní DD.

Otázka: Lze klíč odstranit, i když jsou s ním data spojena v systému Data Domain?
Odpověď: Ne, pokud jsou s klíčem spojena nějaká data, nelze jej odstranit. K odstranění klíče, ke kterému jsou data přidružena, je nutné znovu zašifrovat data pomocí jiného klíče.

Otázka: Pokud je klíč odstraněn z protokolu KMIP, je tento klíč odstraněn také ze seznamu klíčů systému Data Domain?
Odpověď: Ne, uživatel musí klíč odstranit nezávisle pomocí rozhraní příkazového řádku nebo uživatelského rozhraní

DD.Otázka: Je v prostředí Data Domain s více pracovišti vyžadován protokol KMIP na každém místě?
Odpověď: Ne, protokol KMIP není nutné mít na každém pracovišti se systémem Data Domain. Můžeme odkázat na jeden server KMIP. Pokud používají stejný server KMIP, doporučuje se mít pro každý systém DD samostatnou třídu klíčů.

Otázka: Pokud dojde k ohrožení zabezpečení klíče, máme proces pro načtení dat zašifrovaných pomocí starého klíče?
Odpověď: V takovém případě musí zákazník označit klíč na serveru KMIP jako kompromitovaný. Poté v systému DDOS proveďte "filesys encryption keys sync" a poté spusťte příkaz "filesys encryption apply-changes" a poté spusťte GC (filesys clean). Spuštění uvolňování paměti znovu zašifruje všechna data, která byla zašifrována pomocí napadeného klíče pomocí novějšího klíče. Po dokončení uvolňování paměti se stav klíče změní na ohrožení-zničení. Později mohou tento klíč odstranit. 

Šifrování a replikace

Otázka: Je replikace DD podporována a interoperabilní s možností softwaru DD Encryption?
Odpověď: Ano, replikaci DD lze použít s možností DD Encryption, což umožňuje replikaci šifrovaných dat pomocí všech různých druhů replikace. Každý formulář replikace funguje jedinečně se šifrováním a nabízí stejnou úroveň zabezpečení.

Otázka: Musí být ve zdrojovém i cílovém systému spuštěna stejná verze systému DD OS, aby bylo možné použít šifrování?
Odpověď: Zdroj a cíl mohou být v různé verzi systému DDOS, aby bylo možné použít DARE s replikací, pokud je zavedena matice kompatibility replikace (viz příručka správce pro matici kompatibility). 

Otázka: Jak funguje replikace se šifrováním?
Odpověď: Záleží na tom, jaká forma replikace se používá.

Pokud je nakonfigurovaná replikace MREPL nebo MFR:
Pokud se používá MREPL nebo MFR, může být šifrování DD licencováno nebo povoleno na zdroji nebo cíli nezávisle na tom, čeho chce zákazník dosáhnout.

• Pokud je šifrování povolené u zdroje i cíle: Když se data ingestují do zdrojového systému, šifrují se pomocí šifrovacího klíče zdrojového systému. Zdroj dešifruje místní data, znovu je zašifruje pomocí cílového systémového šifrovacího klíče a poté při replikaci replikuje zašifrovaná data do cíle.
• Pokud má zdroj zakázané šifrování a cíl má povolené šifrování: Všechna data ingestovaná do zdroje nejsou šifrována (ze zřejmého důvodu). Při replikaci však zdroj zašifruje data pomocí šifrovacího klíče cílového systému a poté replikuje zašifrovaná data do cílového systému. 
• Pokud má zdroj povolené šifrování a cíl má zakázané šifrování: Všechna data ingestovaná do zdrojového systému se šifrují pomocí šifrovacího klíče zdrojového systému. Zdroj data dešifruje a poté při replikaci replikuje nezašifrovaná data do cílového systému Data Domain.
• Pokud je šifrování na replice povolené po nastavení kontextu replikace, všechny nové segmenty, které se teď replikují, se zašifrují ve zdroji repliky. Všechny segmenty, které se nacházejí v replice před povolením šifrování, jsou ponechány v nezašifrovaném stavu, pokud šifrování nepoužije změny a uvolňování paměti se nespustí v cíli. 

Pokud je nakonfigurovaná replikace CREPL:
Při replikaci sběru musí ve zdrojovém i cílovém systému běžet stejná verze systému DDOS. Proto musí být šifrování povoleno nebo zakázáno na obou. Neshoda nemůže být ani v konfiguraci šifrování. Šifrovací klíče jsou stejné se zdrojem i cílem. 

• Pokud je šifrování povolené u zdroje i cíle: Všechna data ingestovaná do zdrojového systému se šifrují pomocí šifrovacího klíče zdrojového systému. Při replikaci zdroj odesílá šifrovaná data do cílového systému Data Domain v zašifrovaném stavu. Cílový systém Data Domain má stejný klíč jako zdroj, protože replikace sběru představuje přesnou repliku zdrojového systému Data Domain. Do cílového systému Data Domain nelze zapisovat žádná data mimo replikaci, protože cílem je systém pouze pro čtení.
• Pokud je šifrování zakázané u zdroje i cíle: Všechna data přijímaná do zdrojového systému nejsou šifrována (ze zjevného důvodu). Při replikaci zdroj odesílá (replikuje) data v nezašifrovaném stavu a zůstávají nezašifrovaná v cílovém systému Data Domain. Do cílového systému Data Domain nelze zapisovat žádná data mimo replikaci, protože cílem je systém pouze pro čtení.

Otázka: Je cílový klíč uložen ve zdrojovém systému Data Domain po neomezenou dobu?
Odpověď: Šifrovací klíč cíle není nikdy uložen ve zdrojovém systému Data Domain. Je uchováván v paměti (zašifrován) pouze v době, kdy je aktivní relace replikace. To platí pro všechny druhy replikace s výjimkou replikace kolekcí. Při replikaci sběru (CREPL) se stejná sada šifrovacích klíčů nachází ve zdroji i cíli.  

Otázka: Lze povolit šifrování v systému CREPL po vytvoření kontextu replikace?
Odpověď: Ano, v tomto případě musí být šifrování povoleno ve zdroji i cíli. Šifrování lze povolit ve zdroji i cíli zakázáním kontextu replikace. Všechny nové replikované segmenty se šifrují v replice. Všechny segmenty, které se nacházejí v replice před povolením šifrování, zůstanou v nezašifrovaném stavu.

Otázka: Lze šifrování DD povolit souběžně s funkcí šifrování over-the-wire v softwaru DD Replication?
Odpověď: Ano, pro dosažení různých bezpečnostních cílů lze současně povolit šifrování přes přenos i D@RE.

Otázka: Co se stane, pokud jsou současně povoleny možnosti Software DD Encryption a Over-the-Wire Encryption v softwaru DD Replication?
Odpověď: První zdroj šifruje data pomocí cílového šifrovacího klíče. Poté jsou již zašifrovaná data zašifrována podruhé kvůli šifrování po drátě při odesílání těchto dat do cíle. V cíli budou data po provedení dešifrování po drátě uložena v šifrovaném formátu, který byl zašifrován pomocí šifrovacího klíče cíle.

Otázka: Pokud je povoleno šifrování ve zdroji i cíli, musí být přístupové heslo v obou stejné?
Odpověď: Pokud je nakonfigurovaná replikace replikace sběru (CREPL), musí být přístupové heslo stejné. U jiných typů replikace (například MREPL, MFR) se přístupové heslo může lišit ve zdroji a cíli.

Otázka: Pokud je šifrování v cíli povoleno (otázka se nevztahuje na CREPL), jsou replikovaná data i data z jiného přístupového bodu (například prostřednictvím místní zálohy) šifrována? Existuje způsob, jak je oddělit na replice, kde jsou šifrovány pouze replikované adresáře, zatímco ostatní přístup není šifrován?
Odpověď: Ne, všechna data se šifrují v replice (cíli) bez ohledu na vstupní bod. Šifrování nelze povolit nebo zakázat pouze na úrovni fondu MTree nebo adresáře. 

Otázka: Jak probíhá výměna klíčů mezi zdrojem a cílem během MREPL nebo MFR?
Odpověď: Během fáze přidružení replikace cílový počítač bezpečně přenese svůj aktuální šifrovací algoritmus a informace o klíči do zdroje. Kontexty replikace jsou vždy ověřovány pomocí sdíleného tajného klíče. Tento sdílený tajný klíč se používá k vytvoření klíče relace pomocí protokolu výměny klíčů Diffie-Hellman. Tento klíč relace se používá k šifrování a dešifrování šifrovacího klíče systému Data Domain.

Otázka: Jaký typ šifrovacího algoritmu se používá pro funkci "Encryption over the wire" v systému Data Domain ohledně šifrování dat replikace?
Odpověď: Pokud je režim ověřování replikace nastaven na jednosměrný nebo obousměrný, je pro výměnu klíčů relace použit protokol DHE (Ephemeral Diffie-Hellman). Ověření serveru probíhá pomocí RSA. 256bitová šifra AES GCM se používá k zapouzdření replikovaných dat po drátě. Šifrovací zapouzdřecí vrstva se odebere okamžitě, když se dostane do cílového systému. 

Jeden způsob znamená, že je certifikován pouze cílový certifikát. Dva způsoby označují, že je ověřen zdrojový i cílový certifikát. Před použitím režimu ověřování musí být navázána vzájemná důvěra a obě strany připojení musí tuto funkci povolit, aby šifrování pokračovalo.

Pokud je režim ověřování replikace nastaven na hodnotu Anonymous, je pro výměnu klíčů relace použit parametr ADH (Anonymous Diffie-Hellman), ale v tomto případě se zdroj a cíl před výměnou klíčů vzájemně neověřují. Pokud není zadán režim ověřování, použije se jako výchozí anonymní režim.

Otázka: Funguje střídání klíčů bez restartování systému souborů se všemi druhy replikace?
Odpověď: Střídání klíčů bez restartování systému souborů funguje se všemi druhy replikace s výjimkou DREPL (podpora DREPL již skončila) a rozdílové replikace (známé také jako LBO)

Otázka: Jak je v případě nepřítomnosti certifikátů nebo párů klíčů PKI chráněn šifrovací klíč cíle během výměny klíčů?
Odpověď: Mezi všemi páry replikace Data Domain existuje sdílený tajný klíč, který se používá k vytvoření sdíleného klíče relace pomocí výměny klíčů pomocí algoritmu Diffie-Hellman. Tento sdílený klíč se používá k šifrování šifrovacího klíče cíle.

Existuje rozdíl mezi sdíleným tajným klíčem, který se používá k ověřování replikace, a sdíleným klíčem relace, který je přidělován pomocí protokolu výměny klíčů Diffie-Hellman. Sdílený tajný klíč používaný k ověření replikace je vytvořen softwarem Data Domain při prvním pokusu dvou systémů Data Domain o vytvoření kontextu replikace. To je také dohodnuto prostřednictvím Diffie-Hellmana vyměňovaného pomocí parametrů vložených do kódu. To je trvale uloženo v systémech za účelem ověření každé relace replikace mezi těmito dvěma systémy. Klíč relace replikace (klíč používaný k zašifrování šifrovacího klíče cíle) je vytvořen pomocí jiné výměny Diffie-Hellman s dříve vytvořeným sdíleným tajným klíčem, čímž je řízen protokol pro výměnu zabezpečených klíčů. Tento klíč není trvalý a je k dispozici pouze v době, kdy je aktivní kontext replikace.

Otázka: Je nutné, aby obě systémy Data Domain páru replikace používaly stejné řešení externího správce klíčů (například správce klíčů KMIP), nebo může jeden ze systémů používat externího správce klíčů a jiný vestavěný správce klíčů?
Odpověď: Kromě páru replikace sběru není nutné, aby oba systémy v rámci páru replikace používaly stejného správce klíčů.

Při replikaci sběru musí být oba systémy Data Domain nakonfigurovány se stejným správcem klíčů. Ale i v takovém případě je jediným zdrojem synchronizace klíčů se správcem klíčů a tyto klíče se také odesílají do cíle. U jiných typů replikace lze použít různé správce klíčů se zdrojem a cílem.

Šifrování a migrace

Otázka: Je migrace dat podporována v systémech s povoleným šifrováním?
Odpověď: Ano, migrace dat je podporována na systémech s povoleným šifrováním. Před zahájením migrace dat musí být jako předpoklad nutné porovnat konfiguraci šifrování ve zdrojovém a cílovém systému. Před zahájením migrace se také doporučuje exportovat a zálohovat šifrovací klíče ve zdrojovém systému pro účely DIA.

Otázka: Je migrace dat podporována pro aktivní vrstvu i migraci cloudové vrstvy pro systémy s povoleným šifrováním?
Odpověď: Ano, migrace dat je podporována pro aktivní vrstvu i migraci cloudové vrstvy pro systémy s povoleným šifrováním. Seznam zaškrtnutých předběžných atributů se použije na základě toho, která vrstva má povolené šifrování.

Otázka: Která nastavení šifrování se v rámci migrace zachovají?
Odpověď: Šifrovaná data a šifrovací klíče se migrují tak, jak jsou, ale pro úspěšnou migraci dat je nutné ručně ověřit a porovnat nastavení, jako je správce šifrovacích klíčů, systémové heslo a další konfigurace šifrování. Do cílového systému se přenesou také všechny stávající certifikáty správce klíčů. Po migraci je nutné v cílovém systému znovu nastavit konfiguraci správce šifrovacích klíčů.

Otázka: Jaké kontroly kompatibility šifrování se provádějí mezi zdrojem a cílem během migrace?
Odpověď: Systémové heslo, stav šifrování a podrobnosti o konfiguraci správce klíčů a nastavení systémového režimu FIPS patří mezi nastavení šifrování, která musí být stejná ve zdrojovém i cílovém systému, aby migrace proběhla úspěšně. Tento článek znalostní databáze 183040 Data Domain: Postup migrace u systémů DD s podporou cloudu (pro přečtení článku je vyžadováno přihlášení k webu podpory Dell) podrobně popisuje postup migrace mezi systémy s povoleným cloudem. Stejná nastavení platí i pro migraci pouze aktivní vrstvy.

Otázka: Je podporována migrace mezi systémy se zapnutým projektem zakázání šifrování?
Odpověď: Migrace dat je podporována mezi dvěma systémy, pokud jsou oba systémy EDP nebo nejsou EDP. Migrace dat ze systému EDP do jiného systému než EDP je povolena, pokud je explicitně vypnuto šifrování on-the-wire. (pomocí MIGRATION_ENCRYPTION sysparam)

Šifrování v cloudové vrstvě 

Otázka: Podporuje se šifrování pro vrstvu Cloud Tier?
Odpověď: Ano, šifrování je podporováno v cloudové vrstvě. Ve výchozím nastavení je šifrování v cloudové vrstvě zakázané. Příkazové řádky "Cloud Enable" zvolte, jestli chceme povolit šifrování ve vrstvě Cloud Tier.

Otázka: Podporuje vrstva Cloud Tier nástroj KMIP a správce externích klíčů?
Odpověď: Ano, protokoly KMIP a External Key Manager jsou podporovány u vrstvy Cloud Tier od verze DDOS 7.8 výše.

Otázka: S jakou členitostí lze povolit šifrování v cloudu?
Odpověď: Šifrování lze povolit a zakázat na každé cloudové jednotce a každé vrstvě nezávisle.

Otázka: Mají cloudové jednotky nezávislé klíče?
Odpověď: Ne, správa klíčů je společná pro aktivní i cloudové vrstvy v systému DD. Klíče se zkopírují do příslušné jednotky, vrstvy nebo cp, když je povoleno šifrování. Pokud je šifrování povolené v aktivním režimu, a ne v cloudu, aktivní klíče vrstvy se neprojeví v cloudu a naopak. To platí i pro cloudové jednotky. (Například: CP1 má povolené šifrování a CP2 nemá povoleno šifrování, pak se klíče CP1 na CP2 neprojeví.)   

Otázka: Dají se klíče v cloudu odstranit?
Odpověď: Ne, odstranění klíčů z cloudu není podporováno.

Otázka: Kde se spravují šifrovací klíče dat pro cloudové jednotky?
Odpověď: Klíče jsou přidruženy ke cp a každá cloudová jednotka je jiný cp. Kopie klíčů ze všech cps je uložena v aktivním cp.

Otázka: Jak obnovujeme cloudové klíče během zotavení po havárii? 
Odpověď: V rámci obnovení CP se cpnameval zrcadlí do cloudu, šifrovací klíče se obnoví do cpnameval. Nyní musíme spustit nástroj ddr_key_util obnovení klíčů.

Poznámka: Zotavení po havárii vyžaduje zásah zákaznické podpory.

Otázka: Můžeme provádět přesun dat, když je šifrování povolené jenom v cloudové vrstvě?
Odpověď: Ne, pro přesun dat je nutné povolit šifrování v cloudové i aktivní vrstvě.

Otázka: Můžeme povolit externího správce klíčů v cloudové vrstvě?
Odpověď: Ano, nástroj External Key Manager je možné povolit ve vrstvě Cloud Tier. Tato funkce je podporována od verze 7.8 a novější. Všechny operace s výjimkou klíče destroy nebo delete, který je platný pro aktivní vrstvu, platí také pro vrstvu cloudu z hlediska externího správce klíčů. 

Šifrování a uvolňování paměti

Otázka: Jakou roli hraje proces globálního čištění v šifrování neaktivních uložených dat a má nějaký vliv na výkon při prvním povolení šifrování?
Odpověď: První povolení šifrování dat v klidu má vliv na výkon globálního čištění. Je to proto, že data, která musí být přečtena z existujících kontejnerů na disku a zapsána do nových kontejnerů, mohou vyžadovat přečtení, dešifrování a rozbalení před opětovnou komprimací, šifrováním a zpětným zápisem na disk. Pokud je v systému DD s velkým množstvím existujících dat povoleno šifrování a je spuštěn příkaz 'filesys encryption apply-changes', následný globální cyklus čištění se pokusí zašifrovat všechna stávající data v systému. To znamená, že všechna data musí být přečtena, dekomprimována, komprimována, šifrována a zapsána na disk. V důsledku toho může první globální cyklus čištění po spuštění příkazu "filesys encryption apply-changes" trvat déle než obvykle. Zákazníci by měli zajistit dostatek volného místa v systému DD, aby bylo možné provést čištění bez zaplnění systému DD (jinak zálohování selže).

Otázka: Má to vliv na výkon probíhajících čistých cyklů ingestování/obnovy?
Odpověď: Ano, má to vliv na výkon a dopad obecně závisí na množství dat, která se ingestují nebo obnovují mezi čistými cykly.

Otázka: Jak dlouho trvá šifrování mých stávajících dat?
K odhadu času použijte tento článek znalostní databáze, Data Domain: Výpočet, jak dlouho trvá použití šifrování v klidovém stavu.

Šifrování a výměna hlavy 

Otázka: Může zákazník přesunout disk do jiného systému Data Domain, pokud selže hlava, a získat přístup k disku, když je povoleno šifrování?
Odpověď: Šifrovací klíč není vázán na samotnou hlavičku systému Data Domain, takže disky můžete přesunout do jiné systémové hlavy Data Domain a klíč je přístupný tam. V nové hlavě systému Data Domain je systém souborů uzamknutý, takže je nutné zadat přístupové heslo pomocí příkazu "filesys encryption unlock". 

Otázka: Co když zákazník zapomene heslo v době výměny hlavy?
Odpověď: Během této doby mohou připojit starou hlavu a spolupracovat s podporou na resetování přístupové fráze a poté se připojit zpět k nové hlavě a dokončit proceduru výměny hlavy. 

Výkon šifrování

Otázka: Jaký je pozorovaný dopad na spotřebu úložiště při použití šifrování?
Odpověď: Je zanedbatelný se zhruba 1procentní režií spojenou s ukládáním některých šifrovacích parametrů s uživatelskými daty.

Otázka: Jaký je pozorovaný dopad na propustnost (zápisy a čtení) při použití šifrování neaktivních uložených dat?
Odpověď: Dopad na propustnost ingestování při použití šifrování se může lišit v závislosti na protokolu a platformě. Obecně platí, že následující procentuální hodnoty představují konzervativní snížení výkonu v souhrnné propustnosti:

Režim
CBC je nejprve úplný: ~10% snížení výkonu při zápisech
Přírůstkové: ~5% snížení výkonu při zápisech
Obnoví: 5–20% snížení výkonu při čtení

Režim
GCM je nejprve plný: 10–20% snížení výkonu při zápisech
Inkrementální: 5–10% snížení výkonu při zápisech
Obnovuje: 5–20% snížení výkonu při čtení

Tato čísla jsou specifická pro režii šifrování neaktivních uložených dat (drátové šifrování se počítá samostatně)
 

Vzorové postupy

Otázka: Jaké jsou vzorové postupy týkající se zásad obměně klíčů?
Odpověď: Zásada automatické výměny klíčů není ve výchozím nastavení povolena. Zákazník tuto funkci povolil. Šifrovací klíče doporučujeme často střídat. Pokud je systém nakonfigurován s externím správcem klíčů KMIP, doporučujeme klíče často střídat, aby bylo možné v budoucnu vyřešit případné scénáře ohrožení klíčů. Pokud je protokol KMIP nakonfigurován s cloudovou vrstvou, navrhovaný interval výměny klíčů je 1 týden, a pokud je protokol KMIP nakonfigurován pouze v aktivní vrstvě, navrhovaná zásada výměny klíčů je 1 měsíc. Na základě rychlosti příjmu dat ale může zákazník také zvýšit nebo snížit frekvenci střídání klíčů. Pokud je nakonfigurován integrovaný správce klíčů, doporučuje se zásada výměny klíčů v rozmezí 1 až 3 měsíce. 

Otázka: Jaké jsou vzorové postupy pro třídu klíčů KMIP, pokud zákazník používá stejný server KMIP pro mnoho systémů DD?
Odpověď: Pokud používají stejný server KMIP, doporučuje se mít pro každý systém DD samostatnou třídu klíčů. To znamená, že střídání klíčů v jednom systému DDOS nebude mít vliv na stav klíče v jiném systému DDOS.

Další informace naleznete v dokumentu Zařízení DELL EMC PowerProtect řady DD: Šifrovací software (delltechnologies.com)

Šifrování: Technický dokument whitepaper Zařízení PowerProtect řady DD: Šifrovací software

Další dokumentaci týkající se šifrování DD (příručka správce, referenční příručka příkazů a průvodce konfigurací zabezpečení) naleznete v článku 126375 Hlavní dokumenty k systému PowerProtect a Data Domain.

Průvodce integrací protokolu KMIP a matice

kompatibilityPodívejte se na video: