Dell EMC Data Domain Encryption – vanliga frågor och svar

Krypteringskonfiguration

Fråga: Hur konfigureras kryptering (DARE) i DD?
Svar: DARE-kryptering kan konfigureras i DD genom följande steg:

1. Lägg till krypteringslicens

2. Lägga till och aktivera auktorisering som säkerhetsansvarig

3. Aktivera kryptering 

1) Lägg till krypteringslicens:
Ha en licensfil med en giltig krypteringslicens tillagd.
Använd kommandot nedan för att uppdatera e-licensen i DD med hjälp av den tillgängliga licensfilen.

Uppdatering av e-licens

2) Lägg till säkerhetsansvarig och aktivera SO-behörigheter:
a) a) Lägg till en användare med en roll som "säkerhet" med kommandot: 

Användare lägger till säkerhet för säkerhetsroll

b) Aktivera Security Officer Authorization i inställningarna med kommandot: 

Säkerhetsansvarig för inställning av auktoriseringsprincip aktiverad

3. Aktivera DARE-kryptering:
Aktivera DARE-kryptering med kommandot:

FilesSys-kryptering aktivera

Fråga: Vilka plattformar stöds med krypteringsfunktionen för inaktiva data?
Svar: Krypteringsfunktionen för inaktiva data stöds på alla Data Domain-system, förutom på EDP-system (Encryption Disablement Project).

Fråga: Hur kan användaren lagra sina data i klartext i DD?
Svar: Användaren kan se till att data sparas i klartext och inte krypteras i DD genom att bekräfta att kryptering är avstängt i inställningarna.
Användare kan inaktivera kryptering i DD med kommandot: 

FilesSYS-kryptering inaktiverad

Fråga: Vilka säkerhetskopieringsprogram/protokoll stöds med krypteringsfunktionen för data vid vila?
Svar: DD DARE-funktionen är oberoende av det underliggande säkerhetskopieringsprogrammet eller det protokoll som används av DD.

Fråga: Vilka krypteringsalgoritmer kan väljas i Data Domain-systemet?
Svar: DD Encryption-programvaran stöder AES 128 eller 256-bitars algoritm med Cipher Block Chaining (CBC) eller Galois Counter Mode (GCM). 

GCM är ett driftsätt för kryptografiska blockchiffer med symmetrisk nyckel. Det är en autentiserad krypteringsalgoritm som är utformad för att tillhandahålla både autentisering och sekretess (konfidentialitet). Som namnet antyder kombinerar GCM det välkända krypteringsläget med det nya autentiseringsläget Galois. Autentiseringsaspekten av GCM garanterar att de data som krypterades gjordes av Data Domain-systemet och inte "injicerades" på något annat sätt. Detta skiljer sig från CBC där data krypteras (integritetsaspekt), men det finns ingen kontroll av äktheten av den krypterade datan.

I CBC-läge är varje block med oformaterad text exklusivt ORed med det föregående chiffertextblocket innan det krypteras. På så sätt är varje chiffertextblock beroende av alla oformaterade textblock som bearbetats fram till den punkten. För att göra varje meddelande unikt måste en initieringsvektor användas i det första blocket. CBC garanterar endast integriteten (konfidentialiteten) för uppgifterna genom kryptering. Ingen autentisering av krypteringsalgoritmen eller -processen utförs.

Fråga: Hur kan vi ändra krypteringsalgoritmen i DD?

Svar: Använd kommandot nedan om du vill ange en specifik krypteringsalgoritm i konfigurationen.

Uppsättning av FilesYs-krypteringsalgoritm

Exempel:

# filesys krypteringsalgoritm set {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Fråga: Hur ser vi till att kryptering sker på befintliga data när kryptering har aktiverats?
Svar: Vi kan tvinga DDFS att kryptera befintliga data med kommandot nedan:

# filesys kryptering tillämpa-ändringar

Detta gör nästa rengöringscykel betydligt längre och mer resurskrävande än normalt.

Fråga: Hur inaktiverar vi kryptering i DD?
Svar: Avaktivera krypteringsfunktionen i DD med hjälp av krypteringsinaktiveringskommandot: 

FilesSYS-kryptering inaktiverad

Detta inaktiverar endast kryptering för inkommande I/O. Befintliga krypterade data förblir krypterade tills de dekrypteras manuellt med hjälp av apply-changes.

Fråga: Vilka krypteringskommandon kräver en omstart av DD-filsystemet för att börja gälla?
Svar: Följande krypteringskommandon kräver en omstart av DD-filsystemet för att börja gälla:

Aktivera/inaktivera Filesys-kryptering – Aktiverar/inaktiverar kryptering i Data Domain-systemet.

Uppsättning av FilesSys-krypteringsalgoritm – Tillåt användaren att välja en kryptografisk algoritm.

Återställning av Filesys krypteringsalgoritm – Återställer krypteringsalgoritmen till AES 256 i CBC-läge (standard).

Fråga: Vilka krypteringskommandon kräver att Data Domain-filsystemet inaktiveras för att de ska kunna ställas in/användas?
Svar: Följande krypteringskommandon kräver att Data Domain-filsystemet inaktiveras för att de ska kunna ställas in eller användas:

Ändring av lösenfras för kryptering

Kryptering lås/upplåsning

Allmänna frågor om kryptering

Fråga: Stöds DD Encryption på alla DD-system?
Svar: Programvarualternativet DD Encryption stöds på DD-system om det inte är ett krypteringsinaktiveringsprojekt (EDP), vilket är de system som inte tillåter att kryptering aktiveras, främst säljs i systemen i regionen Ryssland.

Fråga: Hur utförs kryptografin i DD-system?
Svar: Kryptografi görs med hjälp av OpenSSL- och RSA BSafe-bibliotek (RSA BSafe är ett FIPS 140-2-validerat kryptografibibliotek som används av DD-system för att kryptera vilande data) i DDOS. 

Fråga: Vilken version av BSafe används med systemet?
Svar: Från och med DDOS 7.10 används BSafe-versioner "BSAFE Micro Edition Suite 4.4.0.0" och "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Fråga: Vilka är de tillgängliga användargränssnitten för att konfigurera kryptering i DDOS?
Svar: Kryptering kan konfigureras med hjälp av CLI, användargränssnitt eller med hjälp av REST-API:er. Stöd för REST API har lagts till i DDOS version 8.0 och senare.

Fråga: Selektiv kryptering av data är möjlig? Gillar du bara ett MTree eller en fil?
Svar: Selektiv kryptering är INTE möjlig. Kryptering kan endast aktiveras eller inaktiveras i hela systemet och inte selektivt. För system med molnstöd kan kryptering aktiveras eller avaktiveras på molnnivå- och molnenhetsgranulariteten.  

Fråga: Överförs eller lagras några kryptografiska nycklar eller kontolösenord i klartext eller under svaga chiffer, till exempel när en entitet autentiseras, i datafil, i program eller i autentiseringskataloger?
Svar: Absolut inte.

Fråga: Vilken version av OpenSSL används med systemet?
Svar: Från och med DDOS 7.10-versionen är openssl-versionen "OpenSSL 1.0.2zd-fips"

Fråga: Hur skyddar kryptering av inaktiva data mot dataåtkomst från användare och program?
Svar: 

• Kryptering av vilande data handlar om att kryptera data som finns på diskundersystemet. Kryptering eller dekryptering sker i komprimeringsskiktet. Användare eller program skickar och tar emot klartextdata till Data Domain-systemet, men alla data som fysiskt finns på Data Domain-systemet krypteras.
• All kryptering sker under filsystemet och namnområdet och är osynlig för användarna eller programmen. Om en användare eller ett program redan har auktoriserad åtkomst till en fil eller katalog kan data läsas i sitt ursprungliga format oavsett kryptering.
• DD-kryptering är utformad så att om en inkräktare kringgår andra nätverkssäkerhetskontroller och får tillgång till krypterade data, utan rätt kryptografiska nycklar, är data oläsliga och oanvändbara för den personen. 

Fråga: Kommer kryptering att ske efter dedupliceringen?
Svar: Ja, kryptering sker på deduplicerade data. Data krypteras innan de lagras på disken. 

Fråga: Hur säkerställer Data Domain datasäkerheten?
Svar: Data skyddas med hjälp av funktionen för kryptering av data vid vila. När enheten tas bort (head-swap, filsystemlås) tas dessutom lösenfrasen bort från systemet. Den här lösenfrasen används för att kryptera krypteringsnycklar, så att data skyddas ytterligare.

Fråga: Vilka varningar genereras med kryptering?
Svar: Aviseringar genereras i följande fall:

• När det finns komprometterade krypteringsnycklar
• När krypteringsnyckeltabellen är full och inga fler nycklar kan läggas till i systemet
• När automatisk export av nycklar misslyckas
• När automatisk nyckelrotation misslyckas
• När kryptering är inaktiverat
• När systemlösenfrasen har ändrats

Fråga: Finns det någon säkerhetscertifiering för DDOS? 
Svar: Data Domain-system uppfyller FIPS 140-2-efterlevnad. 

Fråga: Var lagras krypteringsnyckeln?
Svar: Krypteringsnycklar lagras beständigt i en samlingspartition i DDOS-systemet.

Fråga: Om någon drar ut en hårddisk från ett Data Domain-system, kan du dekryptera data från den?
Svar: Krypteringsnycklar krypteras med hjälp av systemlösenfras som lagras i systemhuvudet. Även om krypteringsnycklar lagras på disken går det inte att dekryptera krypteringsnycklar utan systemlösenfras. Så utan att känna till nyckeln som används för att kryptera data är dekryptering inte möjlig från en hårddisk.  

Fråga: Vilka kryptografiska nycklar och lösenord behövs för återställning, särskilt för haveriberedskap?
Svar: Nycklar kan exporteras i en säker fil och hållas externa i systemet. Återställning av denna fil görs med hjälp av teknik. Vid återställningen måste kunden också känna till den lösenfras som de använde vid tidpunkten för kommandot för export av nycklar.

Fråga: Så här låser du filsystemet innan systemet överförs till en annan plats.
Svar: Nedan följer proceduren för det: 

• Inaktivera filsystemet:

  sysadmin@itrdc-DD630-42# filesys inaktivera

• Lås filsystemet och ange en ny lösenfras (detta kräver autentisering av ovanstående säkerhetsanvändare):

  sysadmin@itrdc-DD630-42# filesys krypteringslås
  Det här kommandot kräver auktorisering av en användare som har en säkerhetsroll.
  Ange inloggningsuppgifter för en sådan användare nedan.
          Användarnamn: secuser
  Lösenord:
  Ange den aktuella lösenfrasen:
  Ange en ny lösenfras:
  Ange den nya lösenfrasen igen:
  Lösenfraser matchade.
  Filsystemet är nu låst.

• Den nya lösenfrasen får INTE försvinna eller glömmas bort. Utan den här lösenfrasen kan filsystemet inte låsas upp, vilket innebär att data på DDR inte kan nås. Om du vill låsa upp systemet när det når en avlägsen plats använder du kommandot nedan:

sysadmin@itrdc-DD630-42# filesys kryptering låsa upp
Det här kommandot kräver auktorisering av en användare som har en säkerhetsroll.
Ange inloggningsuppgifter för en sådan användare nedan.
        Användarnamn: secuser
Lösenord:
Ange lösenfrasen:
Lösenfrasen har verifierats. Använd 'filesys enable' för att starta filsystemet.

• Filsystemet kan nu aktiveras och användas som vanligt

Fråga: Har kommandot "storage sanitize" något samband med filsystemskryptering?
Svar: Nej, filsystemskryptering och lagringssanering är två oberoende funktioner. 

Fråga: Stöds kryptering över tråden i EDP-systemet
(encryption disablement project)?Svar: Vi kan inte aktivera kryptering av data vid vila (DARE) eller kryptering över kabeln (med replikering eller med ddboost) i EDP-systemet.

Systemlösenfras 

Fråga: Vad är systemets lösenfras?
Svar: DDOS har möjlighet att skydda autentiseringsuppgifter i systemet genom att ange en lösenfras på systemnivå. Lösenfrasen är en nyckel som är läsbar (förståelig) för människor, till exempel ett smart card, som används för att generera en maskinanvändbar AES 256-krypteringsnyckel. 

Det ger två fördelar:

• Det gör det möjligt för administratören att ändra lösenfrasen utan att behöva manipulera krypteringsnycklarna. Om du ändrar lösenfrasen ändras nycklarnas kryptering indirekt, men användardata påverkas inte. Om du ändrar lösenfrasen ändras inte den underliggande Data Domain-systemkrypteringsnyckeln. Krypteringen av Data Domain-systemnyckeln ändras, men systemnyckeln förblir densamma.
• Det gör att ett fysiskt Data Domain-system kan levereras med en krypteringsnyckel på systemet, men utan att lösenfrasen lagras på det. Om lådan blir stulen under transporten kan en angripare inte enkelt återställa data eftersom systemet bara har krypterade nycklar och krypterade data.

Lösenfrasen lagras internt på en dold del av Data Domains lagringssystem. Det gör det möjligt för Data Domain-systemet att starta och fortsätta att betjäna dataåtkomst utan att administratören behöver ingripa.

Skapa eller ändra lösenfrasen:

• Systemlösenfrasen kan skapas med hjälp av CLI efter att en administratör har autentiserat med Data Domain-systemet.
• Lösenfrasen för systemet kan ändras med hjälp av CLI efter att en administratör och en säkerhetsrollanvändare (t.ex. en säkerhetsansvarig) har autentiserats med Data Domain-systemet (så att ingen enskild administratör kan göra ändringar oberoende av varandra).

Fråga: När används lösenfrasen?
Svar: Systemlösenfrasen används som primärnyckel av olika DDOS-komponenter, bland annat filsystemskryptering, molnåtkomst, certifikathantering, Boost-token, systemkonfigurationsmoduler i skalbara miljöer och licensieringsinformation. DDOS-programvaran tillhandahåller mekanismer för att ställa in och ändra den här systemlösenfrasen. Det finns även alternativ för att kontrollera om systemlösenfrasen ska lagras på en disk, som särskilt används för ökad säkerhet när DD-systemet transporteras. 

Fråga: Hur används lösenfrasen för säker transport av DD-systemet?
Svar: Under processen används kommandot "filesys encryption lock", som gör det möjligt för användaren att låsa filsystemet genom att ändra lösenfrasen. Användaren anger en ny lösenfras som krypterar krypteringsnyckeln på nytt, men den nya lösenfrasen lagras inte. Krypteringsnycklarna kan inte återställas förrän filsystemet låses upp med kommandot "filesys encryption unlock".

Processen beskrivs i Confluence Lab Security Configuration Guide.

Fråga: Vad händer om lösenfrasen ändras? Går det fortfarande att komma åt data?
Svar: Ja, om du ändrar lösenfrasen ändras inte den underliggande krypteringsnyckeln för Data Domain-systemet, utan endast krypteringen av krypteringsnyckeln. Därför påverkas inte dataåtkomsten.

Fråga: Hur kan vi fråga om en lösenfras har angetts i systemet?
Svar: Om en lösenfras har angetts i systemet uppstår ett fel om du kör kommandot "system passphrase set" som anger att lösenfrasen redan har angetts.

Fråga: Vad händer om lösenfrasen försvinner eller glöms bort?
Svar: Om kunden förlorar lösenfrasen medan rutan är låst förlorar de sina data. Det finns ingen bakdörr eller något alternativt sätt att få tillgång till den. Utan en bra process för att hantera lösenfrasen kan detta hända av misstag och de skulle inte kunna återställa nyckeln eller data. Den krypterade nyckeln kan dock aldrig förloras eller skadas på grund av systemets integrerade skyddsmekanismer.

Fråga: Finns det någon mekanism för att återställa den glömda systemlösenfrasen?
Svar: Systemlösenfrasen kan återställas med tvång endast i vissa scenarier med hjälp av kundsupport. Force-update-mekanismen som introducerades i DDOS 7.2 kan endast användas för detta om specifika villkor är uppfyllda. Mer information finns i KB-artikeln 20983, Data Domain: Så här återställer du en förlorad systemlösenfras i DDOS v7.2 eller senare (inloggning till Dells support krävs för att se artikeln)

Fråga: Finns det något alternativ för att undvika att lagra systemlösenfrasen i DD-systemet?
Svar: Systemlösenfrasen lagras som standard på en dold plats i Data Domain-systemet. Systemalternativet "systemlösenfrasalternativ arkiv-på-disk" kan användas för att ändra detta och undvika lagring av lösenfras på disk.

Inbyggd nyckelhanterare (EKM)

Kommando på högsta nivå:

System# filesys kryptering Alternativet Embedded-Key-Manager <>

Fråga: Stöds nyckelrotation med Embedded Key Manager?
Svar:  Ja, nyckelrotation per Data Domain-system stöds med Embedded Key Manager. Via användargränssnittet eller CLI kan administratören ställa in en nyckelrotationsperiod (veckovis eller månadsvis).

Fråga: Finns det en avgift för den inbyggda nyckelhanteringsfunktionen?
Svar: Den här funktionen är kostnadsfri. Den här funktionen ingår som en del av standardlicensalternativet för DD Encryption-programvara.

Fråga: Kan kunden gå från lokal nyckelhantering till extern nyckelhantering (EKM)?
Svar

• Ja, externa nyckelhanterare kan aktiveras när som helst. De lokala nycklar som används finns dock kvar i Data Domain-systemet. Externa nyckelhanterare kan inte hantera EKM-nycklarna. Befintliga data behöver inte krypteras på nytt. Om efterlevnadsdata för en kund måste krypteras på nytt med EKM-nycklar måste det göras manuellt med hjälp av tillämpa ändringar med den nya RW-nyckeln. Det är inte obligatoriskt att förstöra EKM-nycklar efter ett byte.
  • nyckelhanteraren växlar automatiskt den aktiva nyckeln till nyckeln från KMIP. 
  • Exempel på hur KMIP-nyckelns MUID ser ut när en växel sker

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

Fråga: Vad händer när nyckelrotation har inaktiverats eller aktiverats?
Svar: 

• Nyckelrotation inaktiverad är standardkrypteringsfunktionen om du inte aktiverar nyckelrotation från användargränssnittet eller CLI. I det scenariot krypteras alla data med den befintliga aktiva nyckeln.
• Om nyckelrotation är aktiverat roterar vi nycklarna baserat på rotationsfrekvensen, och data krypteras med den senaste aktiva nyckeln.

Externa nyckelhanterare

Fråga: Vilka externa nyckelhanterare stöds på DD?
Svar: Vi stödjer nedanstående externa nyckelhanterare:

• Gemalto KeySecure (stöd tillagt i DDOS version 7.2)
• Vormetric (stöd tillagt i DDOS version 7.3)
• CipherTrust (stöd tillagt i DDOS version 7.7)
• IBM GKLM (stöd tillagt i DDOS version 7.9)

Fråga: Krävs det en separat licens för att aktivera integrering med en extern nyckelhanterare?
Svar: Ja, det krävs en separat licens från respektive leverantör för att integrera External Key Manager med DD.

Fråga: Hur många nyckelpersoner stöttar samtidigt?
Svar: Endast en nyckelhanterare kan vara aktiv vid en given tidpunkt i ett DD-system.

Fråga: Var hittar jag mer information om hur man konfigurerar KMIP External Key Manager?
Svar: KMIP-integreringsmanualen för DDOS innehåller detaljerad information för att konfigurera de olika externa nyckelhanterare som stöds av DD.

Fråga: Hur hanteras certifikat för externa nyckelhanterare i DD?
Svar: När vi konfigurerar den externa nyckelhanteraren måste vi generera ett CA-certifikat (CA-certifikat kan vara ett självsignerat certifikat eller signerat av tredje part) och värdcertifikat. När konfigurationen är klar på den externa nyckelhanteringsservern måste användarna importera CA-certifikatet och värdcertifikatet till DD-systemet. Sedan konfigurerar och aktiverar vi den externa nyckelhanteraren. 

Fråga: Vad är CA?
Svar: En certifikatutfärdare (CA) fungerar som den ursprungligen betrodda delade enheten mellan peer-datorer och utfärdar signerade certifikat för att göra det möjligt för varje part att lita på den andra. Ett certifikat fungerar vanligtvis som identiteten för en server eller klient. 

Fråga: Vad är ett lokalt CA-signerat certifikat, vad är ett CA-signerat certifikat?
Svar: Ett certifikatutfärdarsignerat certifikat är ett certifikat som har utfärdats och signerats av en offentligt betrodd certifikatutfärdare (CA). Ett CA-signerat certifikat är automatiskt betrott. En lokal certifikatutfärdare kan utfärda signerade certifikat eftersom den privata signeringsnyckeln lagras i Key Manager-systemet. En extern certifikatutfärdare lagrar inte den privata nyckeln. I stället används en extern certifikatutfärdare som en betrodd entitet för olika gränssnitt och tjänster i systemet.

Fråga: Hur skapar man en begäran om certifikatsignering i DD?
Svar: Generera CSR i Data Domain System med hjälp av CLI-kommandot nedan. På så sätt exponeras den privata nyckeln aldrig för den externa nyckelhanteraren.

adminaccess-certifikat certifikat-signering-begäran

Fråga: Är det möjligt att växla mellan nyckelhanterare?
Svar: Det är tillåtet att växla mellan extern nyckelhanterare och inbäddad nyckelhanterare. Men att byta från Embedded Key Manager till External Key Managers kräver lämplig certifikatinstallation och konfiguration. Växla mellan två externa nyckelhanterare (till exempel: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust till GKLM) är också tillåtna. Migrering av Key Manager-nycklar stöds också (mer information finns i KMIP-integreringsmanualen).

Fråga: Vad händer när anslutningen till extern nyckelhanterare slutar fungera? Är mina uppgifter tillgängliga då?
Svar: Ja, data är fortfarande tillgängliga när vi inte kan ansluta till nyckelhanteraren eftersom vi lagrar kopior av nycklarna i DD-systemet också. Det går inte att skapa nya nycklar eller så kan nyckeltillstånd inte synkroniseras när det inte finns någon anslutning till den externa nyckelhanteraren.

Fråga: Finns det något sätt som vi kan undvika att lagra nycklar i DD och endast lagra i External Key Manager?
Svar: Vi lagrar alltid en kopia av nycklarna i DD-systemet för DIA-ändamål. Den här inställningen kan inte ändras.

Fråga: Påverkas prestandan av integreringen med KMIP?
Svar: Nej, prestandan påverkas inte av att du använder externa nyckelhanterare.

Fråga: Är det möjligt att använda KMIP-lösningen för utvalda Data Domains i miljön?
Svar: Ja, kunder har fullständig flexibilitet när det gäller att välja lämplig krypteringsmetod för sina Data Domain-system. De kan fortsätta att använda Data Domains inbäddade nyckelhanterare på vissa Data Domain-system och krypteringsnyckelrotationen med KMIP på andra Data Domain-system i miljön.

Fråga: Är kommunikationen mellan Data Domain och KMIP säker?
Svar: Ja, Data Domain kommunicerar över X509-certifikatautentiserade sessioner med TLS. Användaren kan använda Data Domain CLI för att importera lämpligt X509-certifikat till Data Domain-systemet. Det här certifikatet används sedan för att upprätta den säkra kanalen mellan DD och KMIP.

Nyckellivscykelhantering 

Fråga: Vilka nyckelhanteringsfunktioner finns det med alternativet DD Encryption?
Svar: En nyckelhanterare styr generering, distribution och livscykelhantering av flera krypteringsnycklar. Ett skyddssystem kan använda antingen den inbäddade nyckelhanteraren eller den externa nyckelhanteraren för KMIP-klagomål. Endast en nyckelhanterare kan vara i kraft åt gången. När kryptering är aktiverat i ett skyddssystem används Embedded Key Manager som standard. Om en extern nyckelhanterare har konfigurerats ersätter den den inbäddade nyckelhanteraren och gäller tills den avaktiveras manuellt. Växling från Embedded Key Manager till External Key Manager eller omvänt, resulterar i att en ny nyckel läggs till i systemet och det kräver inte en omstart av filsystemet från version 7.1.

Fråga: Vilka är de olika nyckeltillstånden i Data Domain-systemet?
De olika nyckeltillstånden i Data Domain-systemet är följande:

• Aktiverad – RW: Det finns bara en nyckel i det här läget på alla DD-system och den används för att läsa och skriva data. Den här nyckeln används också av GC-processen för att kryptera om containrar.
• Väntande-aktiverad: Det finns bara en nyckel i det här läget på alla DD-system. Detta identifierade den nyckel som kommer att bli Activated-RW efter nästa omstart av filsystemet. I dag finns det här tillståndet bara när kryptering aktiveras. Ingen annan tidsväntande aktiverad nyckel skapas.  
• Aktiverad-RO: Externa nyckelhanterare kan ha flera aktiverade nycklar. Den senaste nyckeln är i Activated-RW, resten är i det här läget. Nycklar kan försättas i det här läget i DD-systemet när vi inte kan synkronisera tillståndet med nyckelhanteraren.
• Inaktiveras: Detta används för att läsa befintliga data på DD-systemet.
• Äventyras: När en kund komprometterar en extern nyckelhanteringsnyckel ändras tillståndet till den efter nästa nyckelsynkronisering.  
• Märkt för-förstörd: När en kund markerar en nyckel för förstörelse blir nyckeltillståndet Marked-For-Destroyed. När GC körs krypteras alla containrar som krypterats med nycklarna Marked-For-Destroyed på nytt med hjälp av Activated-RW-nyckeln.
• Förstörd: En nyckel i tillståndet Marked-For-Destroyed hamnar i det här tillståndet när det inte finns några data associerade med den.
• Förstörd – komprometterad: En nyckel i komprometterat tillstånd hamnar i det här tillståndet när det inte finns några data associerade med den.

Fråga: Kan krypteringsnycklar exporteras för haveriberedskap?
Svar: Nycklar kan exporteras manuellt med kommandot nedan.

"Export av filesys krypteringsnycklar"

DD-systemet exporterar också nycklar som standard när en ny nyckel läggs till eller när en nyckel tas bort från systemet.

Exporterade filer finns i /ddr/var/.security och det är i ett krypterat format. Filen ska sedan kopieras från DDR och lagras på en säker plats som kan användas i alla katastrofåterställningstillstånd senare.

Obs! Import av nycklar för katastrofåterställning kräver åtgärder från kundsupporten eftersom återställningsprocessen beror på vilken typ av katastrof som påträffas. Vi kan importera den exporterade nyckelfilen med följande kommando.

Filnamn för import <av filesys-krypteringsnycklar> 

Fråga: Lagras nyckeln som genereras av KMIP i Data Domain-systemet?
Svar: Ja, krypteringsnyckeln som hämtas från KMIP lagras krypterat i Data Domain-systemet.

Fråga: Hur tillämpas en viktig statusändring i KMIP-enheten på Data Domain-systemet?
Svar: Nyckelsynkronisering sker dagligen. Om det finns en ny nyckel tillgänglig eller om nyckelns tillstånd ändras uppdaterar synkroniseringen den lokala nyckeltabellen. DD får viktiga uppdateringar från KMIP varje dag vid midnatt.

Fråga: Är det möjligt att manuellt synkronisera nyckeltillstånden mellan DD och KMIP?
Svar: Ja, Data Domain CLI eller UI kan användas för att manuellt synkronisera nyckeltillstånden mellan DD och KMIP. "filesys encryption keys sync" är det kommando som används för det.

Fråga: Är det möjligt att ändra tidpunkten då DD tar emot viktiga uppdateringar från KMIP?
Svar: Nej, det går inte att ändra tiden då DD tar emot viktiga uppdateringar från KMIP.

Fråga: Finns det en gräns för hur många nycklar som stöds av Data Domain-systemet?
Svar: Från och med DDOS 7.8 kan Data Domain-systemet när som helst ha högst 1 024 nycklar i systemet. Det finns bara en nyckel i den aktiverade RW-enheten och resten av nycklarna kan vara i vilket annat läge som helst.

Fråga: Kan olika nycklar användas för olika datauppsättningar i Data Domain-system? Är detta konfigurerbart?
Svar: Nej, vi stöder bara en aktiv nyckel i systemet åt gången och all inkommande data krypteras med den aktuella aktiva nyckeln. Nycklar kan inte styras med en finare kornighet som M-träd.

Fråga: Finns det något meddelande när den maximala nyckelgränsen nås?
Svar: Ja, en avisering utlöses när den maximala nyckelgränsen på 1024 nås.

Fråga: Hur rensar jag varningen om maxgräns för nycklar?
Svar: En av nycklarna måste tas bort för att aviseringen om maximal nyckelgräns ska rensas.

Fråga: Kan vi se mängden data som är associerad med en viss nyckel i Data Domain-systemet?
Svar: Ja, det kan ses på DD men inte på KMIP-servern. Användaren kan använda Data Domain CLI och användargränssnittet för att se mängden data som är associerad med en viss nyckel.

Fråga:  Kan vi se åldern på nycklarna i DD-systemet?
Svar: Ja, det kan ses på med EKM-nycklar med hjälp av UI.

Fråga: Fungerar den gamla nyckeln även om tidsperioden för att göra den nya nyckeln effektiv?
Svar: Det finns inget utgångsdatum för krypteringsnycklar. Gamla nycklar blir skrivskyddade nycklar efter nyckelrotation och finns kvar i DDOS.

Fråga: Raderas krypteringsnyckeln automatiskt när det inte finns några data associerade med den i Data Domain-systemet?
Svar: Nej, nyckeln tas inte bort automatiskt. Användaren måste uttryckligen ta bort nyckeln med hjälp av DD CLI eller användargränssnittet.

Fråga: Kan en nyckel tas bort även om det finns data associerade med den i Data Domain-systemet?
Svar: Nej, om en nyckel har data kopplade till sig kan den inte tas bort. Omkryptering av data krävs med någon annan nyckel för att ta bort en nyckel som har data associerade med den.

Fråga: Om en nyckel tas bort i KMIP, tas då även nyckeln bort från Data Domains nyckellista?
Svar: Nej, användaren måste ta bort nyckeln oberoende med hjälp av DD CLI eller användargränssnittet.

Fråga: Krävs en KMIP på varje plats i en Data Domain-miljö med flera platser?
Svar: Nej, det är inte nödvändigt att ha en KMIP på varje plats med en Data Domain. Vi kan peka på en KMIP-server. Vi rekommenderar att du har en separat nyckelklass för varje DD-system när de använder samma KMIP-server.

Fråga: Om en nyckel komprometteras, har vi en process för att hämta data som krypterats med den gamla nyckeln?
Svar: I det här fallet måste kunden markera nyckeln som komprometterad i KMIP-servern. Gör sedan "filesys encryption keys sync" i DDOS-systemet och kör sedan "filesys encryption apply-changes" och kör sedan GC (filesys clean). GC-körning krypterar om alla data som krypterades med den komprometterade nyckeln med hjälp av en nyare nyckel. När GC är klar ändras nyckeltillståndet till komprometterad-förstörd. Senare kan de ta bort nyckeln. 

Kryptering och replikering

Fråga: Stöds DD Replication och är det kompatibelt med programvaran DD Encryption?
Svar: Ja, DD-replikering kan användas med alternativet DD-kryptering, vilket gör att krypterade data kan replikeras med alla olika typer av replikering. Varje replikeringsformulär fungerar unikt med kryptering och erbjuder samma säkerhetsnivå.

Fråga: Måste både käll- och målsystemen köra samma version av DD OS för att använda kryptering?
Svar: Källa och mål kan vara i olika DDOS-versioner för att använda DARE med replikering om replikeringskompatibilitetsmatris (se administratörsmanualen för kompatibilitetsmatris) finns på plats. 

Fråga: Hur fungerar replikering med kryptering?
Svar: Det beror på vilken form av replikering som används.

Om den konfigurerade replikeringen är MREPL eller MFR:
Om MREPL eller MFR används kan DD Encryption licensieras eller aktiveras på antingen källan eller målet oberoende av varandra beroende på vad kunden vill uppnå.

• När både källa och mål har kryptering aktiverat: När data matas in i källsystemet krypteras de med källsystemets krypteringsnyckel. Källan dekrypterar lokala data, krypterar om dem med hjälp av målsystemets krypteringsnyckel och replikerar sedan krypterade data till målet vid replikeringen.
• När källan har kryptering inaktiverad och målet har kryptering aktiverat: Alla data som matas in till källan krypteras inte (av uppenbara skäl). Men vid replikering krypterar källan data med hjälp av målsystemets krypteringsnyckel och replikerar sedan krypterade data till målsystemet. 
• När källan har kryptering aktiverad och målet har kryptering inaktiverat: Alla data som matas in till källsystemet krypteras med källsystemets krypteringsnyckel. Källan dekrypterar data och replikerar sedan okrypterade data till mål-Data Domain-systemet vid replikeringen.
• Om kryptering är aktiverat på repliken efter att replikeringskontexten har konfigurerats krypteras alla nya segment som nu replikeras vid källan för repliken. Alla segment som finns på repliken innan kryptering aktiveras lämnas i ett okrypterat tillstånd om inte krypteringen tillämpar ändringar och GC körs på målet. 

Om den konfigurerade replikeringen är CREPL:
Med samlingsreplikering måste både käll- och målsystem köra samma DDOS-version. Därför måste kryptering antingen aktiveras eller inaktiveras på båda. Det får inte heller finnas ett matchningsfel i krypteringskonfigurationen. Krypteringsnycklarna är desamma med källa och mål. 

• När både källa och mål har kryptering aktiverat: Alla data som matas in till källsystemet krypteras med källsystemets krypteringsnyckel. Vid replikering skickar källan krypterade data till mål-Data Domain-systemet i krypterat läge. Data Domain-målsystemet har samma nyckel som källan eftersom insamlingsreplikering handlar om en exakt kopia av Data Domain-källsystemet. Inga data kan skrivas till mål-Data Domain-systemet utanför replikeringen, eftersom målet är skrivskyddat.
• När både käll- och målkryptering har inaktiverats: Alla data som matas in till källsystemet krypteras inte (av uppenbara skäl). Vid replikering skickar (replikerar) källan data i okrypterat läge och förblir okrypterade i mål-Data Domain-systemet. Inga data kan skrivas till mål-Data Domain-systemet utanför replikeringen, eftersom målet är skrivskyddat.

Fråga: Lagras målnyckeln på obestämd tid i Data Domain-källsystemet?
Svar: Målets krypteringsnyckel lagras aldrig i Data Domain-källsystemet. Den lagras bara i minnet (krypteras) medan replikeringssessionen är aktiv. Detta gäller för alla typer av replikering utom samlingsreplikering. I samlingsreplikering (CREPL) finns samma uppsättning krypteringsnycklar i källa och mål.  

Fråga: Kan kryptering aktiveras i CREPL-systemet efter att replikeringskontexten har upprättats?
Svar: Ja, i det här fallet måste kryptering aktiveras i både källa och mål. Kryptering kan aktiveras i källa och mål genom att inaktivera replikeringskontexten. Alla nya segment som replikeras krypteras på repliken. Alla segment som finns på repliken innan kryptering aktiveras lämnas i ett okrypterat tillstånd.

Fråga: Kan DD-kryptering aktiveras samtidigt som krypteringsfunktionen over-the-wire-kryptering i programvarualternativet DD Replication?
Svar: Ja, både trådbunden kryptering och D@RE kan aktiveras samtidigt för att uppnå olika säkerhetsmål.

Fråga: Vad händer om både programvarualternativet DD Encryption och krypteringsfunktionen over-the-wire-kryptering i programvarualternativet DD Replication aktiveras samtidigt?
Svar: Den första källan krypterar data med hjälp av målkrypteringsnyckeln. Då krypteras redan krypterade data en andra gång på grund av over the wire-kryptering samtidigt som dessa data skickas till sin destination. På destinationen efter att dekryptering över kabeln är klar kommer data att lagras i ett krypterat format som krypterades med hjälp av destinationens krypteringsnyckel.

Fråga: Måste lösenfrasen vara densamma för båda när kryptering är aktiverat i källan och målet?
Svar: Om den konfigurerade replikeringen är samlingsreplikering (CREPL) måste lösenfrasen vara densamma. För andra typer av replikering (t.ex. MREPL, MFR) kan lösenfrasen vara olika i källa och mål.

Fråga: Krypteras både replikerade data och data från någon annan åtkomstpunkt (till exempel via lokal säkerhetskopiering) när kryptering är aktiverat på målet (frågan gäller inte för CREPL)? Finns det något sätt att separera de två på repliken där endast de replikerade katalogerna krypteras medan annan åtkomst inte krypteras?
Svar: Nej, alla data krypteras på repliken (målet) oavsett startpunkt. Kryptering kan inte aktiveras eller inaktiveras endast på en MTree- eller katalognivågranularitet. 

Fråga: Hur sker nyckelutbytet mellan källa och mål under MREPL eller MFR?
Svar: Under associationsfasen av replikeringen överför måldatorn på ett säkert sätt sin aktuella krypteringsalgoritm och nyckelinformation till källan. Replikeringskontexter autentiseras alltid med en delad hemlighet. Den delade hemligheten används för att upprätta en "sessionsnyckel" med hjälp av ett Diffie-Hellman-protokoll för nyckelutbyte. Sessionsnyckeln används för att kryptera och dekryptera Data Domain-systemets krypteringsnyckel.

Fråga: Vilken typ av krypteringsalgoritm används för Data Domains funktion "kryptering över kabeln" när det gäller kryptering av replikeringstrafiken?
Svar: När autentiseringsläget för replikering är inställt på "enkelriktad" eller "tvåvägs" används DHE (Ephemeral Diffie-Hellman) för utbyte av sessionsnycklar. Serverautentisering sker med RSA. AES 256-bitars GCM-chiffer används för att kapsla in replikerade data över kabeln. Krypteringsinkapslingsskiktet tas omedelbart bort när det landar på destinationssystemet. 

Ett sätt anger att endast destinationscertifikatet är certifierat. Två sätt anger att både käll- och målcertifikaten verifieras. Ömsesidigt förtroende måste upprättas innan du kan använda autentiseringsläge och båda sidor av anslutningen måste aktivera den här funktionen för att krypteringen ska fortsätta.

När replikeringsautentiseringsläget är inställt på "anonymous" används Anonymous Diffie-Hellman (ADH) för utbyte av sessionsnycklar, men i det här fallet autentiserar inte källa och mål varandra före nyckelutbytet. Dessutom, om authentication-mode inte anges, används anonymous som standard.

Fråga: Fungerar nyckelrotation utan omstart av filsystemet med alla typer av replikering?
Svar: Nyckelrotation utan omstart av filsystemet fungerar med alla typer av replikering utom DREPL (DREPL-stödet har redan upphört) och deltareplikering (som även kallas LBO)

Fråga: Om det inte finns några certifikat eller PKI-nyckelpar, hur skyddas målets krypteringsnyckel under nyckelutbytet?
Svar: Det finns en delad hemlighet mellan alla Data Domain-replikeringspar som används för att upprätta en delad sessionsnyckel med hjälp av ett Diffie-Hellman-nyckelutbyte. Den delade nyckeln används för att kryptera målets krypteringsnyckel.

Det finns en skillnad mellan den delade hemlighet som används för replikeringsautentisering och den delade sessionsnyckeln, som allokeras med hjälp av Diffie-Hellman-nyckelutbytesprotokollet. Den delade hemlighet som används för replikeringsautentisering upprättas av Data Domain-programvaran första gången två Data Domain-system vill upprätta en replikeringskontext. Det är också överenskommet genom en Diffie-Hellman som utbyts med hjälp av parametrar som är inbäddade i koden. Detta lagras permanent i systemen för att autentisera varje replikeringssession mellan de två systemen. Replikeringssessionsnyckeln (nyckeln som används för att kryptera målets krypteringsnyckel) upprättas med hjälp av ett annat Diffie-Hellman-utbyte med den tidigare upprättade delade hemligheten, vilket driver protokollet för utbyte av säkra nycklar. Den här nyckeln är inte beständig och finns bara när replikeringskontexten är aktiv.

Fråga: Är det nödvändigt för båda Data Domains i ett replikeringspar att använda samma externa nyckelhanterarlösning (som KMIP-nyckelhanterare) eller kan ett av systemen använda extern nyckelhanterare och ett annat kan använda inbäddad nyckelhanterare?
Svar: Förutom ett insamlingsreplikeringspar är det inte nödvändigt för båda systemen i ett replikeringspar att använda samma nyckelhanterare.

Med samlingsreplikering måste båda Data Domain-systemen konfigureras med samma nyckelhanterare. Men även i det fallet synkroniserar den enda källan nycklar med nyckelhanteraren och dessa nycklar skickas också över till destinationen. Med andra replikeringstyper kan olika nyckelhanterare användas med källa och mål.

Kryptering och migrering

Fråga: Stöds datamigrering på system med kryptering aktiverat?
Svar: Ja, datamigrering stöds på system med kryptering aktiverat. Krypteringskonfiguration på käll- och målsystem måste matchas som en förutsättning innan datamigrering initieras. Vi rekommenderar även att du exporterar och säkerhetskopierar krypteringsnycklar på källsystemet för DIA-ändamål innan migreringen påbörjas.

Fråga: Stöds datamigrering för både aktiv nivå och molnnivåmigrering för krypteringsaktiverade system?
Svar: Ja, datamigrering stöds för både aktiv nivå- och molnnivåmigrering för krypteringsaktiverade system. Listan över nödvändiga attribut som är markerade tillämpas baserat på vilken nivå kryptering har aktiverats.

Fråga: Vilka krypteringsinställningar bevaras som en del av migreringen?
Svar: Krypterade data och krypteringsnycklar migreras som de är, men inställningar som krypteringsnyckelhanterare, systemlösenfras och annan krypteringskonfiguration måste verifieras och matchas manuellt för att datamigreringen ska lyckas. Alla befintliga nyckelhanteringscertifikat överförs också till målsystemet. Konfigurationen av krypteringsnyckelhanteraren måste konfigureras igen i målsystemet efter migreringen.

Fråga: Vilka krypteringskompatibilitetskontroller görs mellan källa och mål under migreringen?
Svar: Systemlösenfras, krypteringsstatus och nyckelhanterarens konfigurationsinformation, systeminställningar för FIPS-läge är några av de krypteringsinställningar som måste vara identiska på käll- och målsystem för att migreringen ska lyckas. Den här KB-artikeln 183040, Data Domain: Migreringsprocedur för molnaktiverade DD-system (logga in på Dells support krävs för att visa artikeln), beskriver stegen för migrering mellan system med moln aktiverat. Samma inställningar gäller även för migrering på aktiv nivå.

Fråga: Stöds migrering mellan system med inställningen Encryption Disablement Project aktiverad?
Svar: Datamigrering stöds mellan två system om antingen båda är EDP eller båda är icke-EDP. Datamigrering tillåts från ett EDP-system till ett icke-EDP-system om on-the-wire-kryptering uttryckligen är inaktiverat. (med hjälp av MIGRATION_ENCRYPTION sysparam)

Kryptering på molnnivå 

Fråga: Stöds kryptering för molnnivån?
Svar: Ja, kryptering stöds på molnnivån. Som standard är kryptering inaktiverat på molnnivån. Kommandotolken "cloud enable" används för att välja om vi vill aktivera kryptering på molnnivån.

Fråga: Stöds KMIP och externa nyckelhanterare med molnnivån?
Svar: Ja, KMIP och externa nyckelhanterare stöds med molnnivå från DDOS 7.8 och framåt.

Fråga: Med vilken kornighet kan kryptering aktiveras i molnet?
Svar: Kryptering kan aktiveras och inaktiveras på varje molnenhet och varje nivå oberoende av varandra.

Fråga: Har molnenheter oberoende nycklar?
Svar: Nej, nyckelhantering är gemensamt för både aktiva nivåer och molnnivåer i DD. Nycklar kopieras över till respektive enhet/nivå/cp när kryptering är aktiverad. Om kryptering är aktiverat på aktiv och inte i molnet reflekteras inte nycklar på aktiv nivå i molnet och omvänt. Detta gäller även molnenheterna. (Exempel: CP1 har kryptering aktiverad och CP2 har inte kryptering aktiverad så CP1-nycklar återspeglas inte i CP2.)   

Fråga: Kan nycklar tas bort i molnet?
Svar: Nej, det går inte att ta bort nycklar från molnet.

Fråga: Var hanteras datakrypteringsnycklar för molnenheter?
Svar: Nycklar är associerade med en cp och varje molnenhet är en annan cp. En kopia av nycklar från alla cps lagras i aktiv cp.

Fråga: Hur återställer vi molnnycklar under katastrofåterställning? 
Svar: cpnameval speglas till molnet som en del av CP-återställningen, krypteringsnycklarna kommer att återställas till cpnameval. Nu måste vi köra ddr_key_util verktyget för att återställa nycklarna.

Obs! Katastrofåterställning kräver åtgärder från kundsupporten.

Fråga: Kan vi flytta data när kryptering endast är aktiverat i molnnivån?
Svar: Nej, vi måste aktivera kryptering i både moln- och aktiv nivå för dataförflyttning.

Fråga: Kan vi aktivera extern nyckelhanterare på molnnivån?
Svar: Ja, extern nyckelhanterare kan aktiveras på molnnivån. Den här funktionen stöds från 7.8 och framåt. Alla åtgärder utom förstöra eller ta bort nyckel som är giltig för den aktiva nivån är också giltiga för molnnivån när det gäller extern nyckelhanterare. 

Kryptering och skräpinsamling

Fråga: Vilken roll spelar den globala rensningsprocessen för kryptering vid vila, och påverkas prestandan när du aktiverar kryptering för första gången?
Svar: Att aktivera kryptering av vilande data för första gången påverkar prestanda för global rensning. Det beror på att data som måste läsas från befintliga behållare på en disk och skrivas till nya behållare kan behöva läsas, dekrypteras och packas upp innan de åter komprimeras, krypteras och skrivs tillbaka till disken. När kryptering är aktiverat på en DD som innehåller en betydande mängd befintliga data och kommandot "filesys encryption apply-changes" körs, görs ett försök att kryptera alla befintliga data i systemet under den efterföljande globala rensningscykeln. Det innebär att alla data måste läsas, okomprimeras, komprimeras, krypteras och skrivas ut till disk. Som ett resultat av detta kan den första globala rensningscykeln efter att ha kört "filesys encryption apply-changes" ta längre tid än normalt. Kunderna bör se till att de har tillräckligt med ledigt utrymme på DD-systemet så att rensningen kan slutföras utan att DD-systemet blir fullt (annars misslyckas säkerhetskopieringarna).

Fråga: Påverkas prestandan av pågående rensningscykler för inhämtning/återställning?
Svar: Ja, prestandan påverkas och beror vanligtvis på mängden data som matas in/återställs mellan rensningscyklerna.

Fråga: Hur lång tid tar det att kryptera befintliga data?
Använd den här KB-artikeln för att beräkna tiden, Data Domain: Beräkna hur lång tid det tar för kryptering i vila att tillämpas.

Kryptering och byte av huvudenhet 

Fråga: Kan kunden flytta disken till ett annat Data Domain-system om en head-enhet slutar fungera och komma åt disken när kryptering är aktiverad?
Svar: Krypteringsnyckeln är inte kopplad till själva Data Domain-systemhuvudet, så du kan flytta diskarna till ett annat Data Domain-systemhuvud och nyckeln är tillgänglig där. På ett nytt Data Domain-systemhuvud är filsystemet låst, så du måste ange lösenfrasen med kommandot "filesys encryption unlock". 

Fråga: Vad händer om kunden glömmer lösenfrasen vid tidpunkten för bytet av huvud?
Svar: Under den tiden kan de ansluta det gamla huvudet och arbeta med stöd för att återställa lösenfrasen och sedan ansluta tillbaka till det nya huvudet och slutföra proceduren för huvudbyte. 

Krypteringsprestanda

Fråga: Vad är den observerade effekten på lagringsförbrukningen när kryptering används?
Svar: Det är försumbart med ungefär 1 procent overhead förknippad med att lagra vissa krypteringsparametrar med användardata.

Fråga: Vad är den observerade effekten på dataflödet (skrivningar och läsningar) när kryptering av vilande data används?
Svar: Påverkan på inmatningsdataflödet när kryptering används kan variera med protokollet och plattformen. I allmänhet är följande procentandelar konservativa prestandaförsämringar i aggregerat dataflöde:CBC-läge
först fullständigt:

~10 % prestandaförsämring på WRITEs
inkrementellt: ~5 % prestandaförsämring vid WRITE-återställningar
: 5–20 % prestandaförsämring på READs

GCM-läge
First Full: 10–20 % prestandaförsämring på WRITEs
inkrementell: 5–10 % prestandaförsämring på WRITEs
återställer: 5–20 % prestandaförsämring på READs

Dessa siffror är specifika för omkostnaderna för kryptering av data vid vila (kryptering över kabeln redovisas separat)
 

Bästa praxis

Fråga: Vad är bästa praxis när det gäller principen för nyckelrotation?
Svar: Principen för automatisk nyckelrotation är inte aktiverad som standard. Kunden har aktiverat det. Vi rekommenderar att du roterar krypteringsnycklarna ofta. När ett system är konfigurerat med en extern KMIP-nyckelhanterare rekommenderar vi att du roterar tangenterna ofta för att hantera eventuella scenarier med nyckelkompromettering i framtiden. När KMIP har konfigurerats med molnnivå är det föreslagna nyckelrotationsintervallet 1 vecka och när KMIP endast har konfigurerats på den aktiva nivån är den föreslagna principen för nyckelrotation 1 månad. Beroende på intagshastigheten kan kunden dock även öka eller minska tangentrotationsfrekvensen. Om Embedded Key Manager har konfigurerats rekommenderas en princip för nyckelrotation var som helst mellan 1 och 3 månader. 

Fråga: Vad är bästa praxis med KMIP-nyckelklass om en kund använder samma KMIP-server för många DD-system?
Svar: Vi rekommenderar att du har en separat nyckelklass för varje DD-system när de använder samma KMIP-server. På så sätt påverkar nyckelrotation som görs i ett DDOS-system inte tillståndet för nyckeln som finns i andra DDOS-system.

Mer information finns i dokumentet Enheter i DELL EMC PowerProtect DD-serien: Krypteringsprogramvara (delltechnologies.com)

Kryptering: Tekniskt informationsdokument Enheter i PowerProtect DD-serien: Krypteringsprogram

Annan dokumentation som rör DD Encryption (administratörsmanual, kommandoreferensmanual och säkerhetskonfigurationsmanual) finns i artikel 126375, PowerProtect och Data Domains kärndokument.

KMIP-integreringsmanual och kompatibilitetsmatris

Titta på den här videon: