Dell EMC Data Domain Encryption – Ofte stillede spørgsmål

Konfiguration af kryptering

Spørgsmål: Hvordan konfigureres kryptering (DARE) i DD?
Svare: DAR-kryptering kan konfigureres i DD ved hjælp af følgende trin:

1. Tilføj krypteringslicens

2. Tilføj sikkerhedsansvarlig, og aktivér autorisationer som sikkerhedsansvarlig

3. Aktivér kryptering 

1) Tilføj krypteringslicens:
Få tilføjet en licensfil med en gyldig krypteringslicens.
Brug nedenstående kommando til at opdatere elicense i DD ved hjælp af den tilgængelige licensfil.

Opdatering af eLicense

2) Tilføj sikkerhedsofficer og aktiver SO-autorisationer:
a) Tilføj en bruger med en rolle som "sikkerhed" ved hjælp af kommandoen: 

Bruger Tilføj sikkerhed for SECUSER-rolle

b) Aktiver Security Officer Authorization i opsætningen ved hjælp af kommandoen: 

Godkendelsespolitiksæt Sikkerhedsansvarlig aktiveret

3. Aktivér DAR-kryptering:
Aktivér DARE-kryptering ved hjælp af kommandoen:

Aktivér filesys-kryptering

Spørgsmål: Hvilke platforme understøttes af data-at-rest-krypteringsfunktionen?
Svare: Funktionen til kryptering i hvile understøttes på alle Data Domain-systemer med undtagelse af EDP-systemer (Encryption Disablement Project).

Spørgsmål: Hvordan kan brugeren gemme sine data i klar tekst i DD?
Svare: Brugeren kan sikre, at dataene gemmes i klar tekst og ikke krypteres i DD, ved at bekræfte, at kryptering er deaktiveret i opsætningen.
Brugere kan deaktivere kryptering i DD ved hjælp af kommandoen: 

Deaktivering af filesys-kryptering

Spørgsmål: Hvilke sikkerhedskopieringsprogrammer/-protokoller understøttes af funktionen til kryptering af data-at-rest?
Svare: DD DAR-funktionen er uafhængig af det underliggende sikkerhedskopieringsprogram eller den protokol, der anvendes af DD.

Spørgsmål: Hvilke krypteringsalgoritmer kan vælges på Data Domain-systemet?
Svare: DD-krypteringssoftwaren understøtter AES 128- eller 256-bit-algoritmer ved hjælp af CBC (Cipher Block Chaining) eller Galois Counter Mode (GCM). 

GCM er en driftsform for symmetriske kryptografiske nøgleblokcifre. Det er en godkendt krypteringsalgoritme designet til at give både godkendelse og privatliv (fortrolighed). Som navnet antyder, kombinerer GCM den velkendte tællertilstand for kryptering med den nye Galois-godkendelsestilstand. Godkendelsesaspektet af GCM garanterer, at de data, der blev krypteret, blev udført af Data Domain-systemet og ikke blev "injiceret" på anden måde. Dette adskiller sig fra CBC, hvor data er krypteret (privatlivsaspekt), men der er ingen kontrol af ægtheden af de krypterede data.

I CBC-tilstand er hver blok af almindelig tekst eksklusiv ELLERed med den forrige chiffertekstblok, før den krypteres. På denne måde afhænger hver chiffertekstblok af alle almindelige tekstblokke, der er behandlet indtil det tidspunkt. For at gøre hver meddelelse unik skal der også bruges en initialiseringsvektor i den første blok. CBC garanterer kun privatlivets fred (fortrolighed) af dataene gennem kryptering. Der udføres ingen godkendelse af krypteringsalgoritmen eller -processen.

Spørgsmål: Hvordan kan vi ændre krypteringsalgoritmen i DD?

Svar: Brug nedenstående kommando, hvis du vil indstille en bestemt krypteringsalgoritme i opsætningen.

filesys krypteringsalgoritme sæt

Eksempel:

# filesys krypteringsalgoritme sæt {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Spørgsmål: Hvordan sikrer vi, at kryptering udføres på allerede eksisterende data, når kryptering er aktiveret?
Svare: Vi kan tvinge DDFS til at kryptere de allerede eksisterende data ved hjælp af nedenstående kommando:

# filesys kryptering apply-ændringer

Dette gør den næste rene cyklus betydeligt længere og mere ressourcekrævende end normalt.

Spørgsmål: Hvordan deaktiverer vi kryptering i DD?
Svare: Deaktiver krypteringsfunktionen i DD ved hjælp af kommandoen til deaktivering af kryptering: 

Deaktivering af filesys-kryptering

Dette deaktiverer kun kryptering for indgående I/O. Eksisterende krypterede data forbliver krypterede, indtil de dekrypteres manuelt ved hjælp af apply-changes.

Spørgsmål: Hvilke krypteringskommandoer kræver genstart af DD-filsystemet for at træde i kraft?
Svare: Følgende krypteringskommandoer kræver genstart af DD-filsystemet for at træde i kraft:

filesys kryptering aktiveres/deaktiveres - Aktiverer/deaktiverer kryptering på Data Domain-systemet.

filesys krypteringsalgoritme sæt - Tillad brugeren at vælge en kryptografisk algoritme.

Nulstilling af filesys-krypteringsalgoritme - Nulstiller krypteringsalgoritmen til AES 256 i CBC-tilstand (standard).

Spørgsmål: Hvilke krypteringskommandoer kræver, at Data Domain-filsystemet deaktiveres, for at de kan indstilles/bruges?
Svare: Følgende krypteringskommandoer kræver, at Data Domain-filsystemet deaktiveres, for at de kan indstilles eller bruges:

Ændring af adgangsudtryk til kryptering

Krypteringslås/-oplåsning

Generelle krypteringsspørgsmål

Spørgsmål: Understøttes DD-kryptering på alle DD-systemer?
Svare: Muligheden DD-krypteringssoftware understøttes på DD-systemer, hvis det ikke er et krypteringsdeaktiveringsprojekt (EDP), som er de systemer, der ikke tillader, at kryptering aktiveres, hovedsageligt solgt i systemerne i Rusland-regionen.

Spørgsmål: Hvordan udføres kryptografien i DD-systemer?
Svare: Kryptografi udføres ved hjælp af OpenSSL- og RSA BSafe-biblioteker (RSA BSafe er FIPS 140-2-valideret kryptografibibliotek, der bruges af DD-systemer til kryptering af inaktive data) i DDOS. 

Spørgsmål: Hvilken version af BSafe bruges sammen med systemet?
Svare: Fra og med DDOS 7.10 er de anvendte BSafe-versioner "BSAFE Micro Edition Suite 4.4.0.0" og "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Spørgsmål: Hvad er de tilgængelige brugergrænseflader til konfiguration af kryptering i DDOS?
Svare: Kryptering kan konfigureres ved hjælp af CLI, UI eller ved hjælp af REST API'er. REST API-understøttelse tilføjet i DDOS version 8.0 og fremefter.

Spørgsmål: Selektiv kryptering af data er mulig? Kan du kun lide ét MTree eller én fil?
Svare: Selektiv kryptering er IKKE mulig. Kryptering kan kun aktiveres eller deaktiveres i hele systemet og ikke selektivt. For systemer med cloud-understøttelse kan kryptering aktiveres eller deaktiveres ved granularitet for cloud-niveau og cloud-enhed.  

Spørgsmål: Overføres eller gemmes kryptografiske nøgler eller kontoadgangskoder i klar tekst eller under svage cifre, f.eks. når en enhed godkender, i datafil, i programmer eller i godkendelsesmapper?
Svare: Absolut ikke.

Spørgsmål: Hvilken version af OpenSSL bruges sammen med systemet?
Svare: Fra DDOS 7.10-udgivelsen er openssl-versionen "OpenSSL 1.0.2zd-fips"

Spørgsmål: Hvordan beskytter data-at-rest-kryptering mod dataadgang fra brugere og programmer?
Svare: 

• Kryptering af data i hvile handler om at kryptere de data, som findes på diskens undersystem. Kryptering eller dekryptering sker ved komprimeringslaget. Brugere eller programmer sender og modtager klare tekstdata til Data Domain-systemet, men alle data, der fysisk befinder sig i Data Domain-systemet, krypteres.
• Al kryptering sker under filsystemet og navneområdet og er usynlig for brugerne eller programmerne. Hvis en bruger eller et program allerede har autoriseret adgang til en fil eller mappe, kan dataene læses i deres oprindelige format uanset kryptering.
• DD-kryptering er designet således, at hvis en ubuden gæst omgår andre netværkssikkerhedskontroller og får adgang til krypterede data uden de korrekte kryptografiske nøgler, er dataene ulæselige og ubrugelige for den pågældende person. 

Spørgsmål: Vil kryptering ske efter deduplikering
?Svare: Ja, kryptering sker på deduplikerede data. Data krypteres, før de gemmes på disken. 

Spørgsmål: Hvordan sikrer Data Domain datasikkerheden?
Svare: Data sikres ved hjælp af funktionen til kryptering af inaktive data. Når enheden fjernes (head-swap, filsystemlås), fjernes adgangsudtrykket desuden fra systemet. Denne adgangssætning bruges til at kryptere krypteringsnøgler, så dataene beskyttes yderligere.

Spørgsmål: Hvilke advarsler genereres med kryptering?
Svare: Påmindelser genereres i følgende tilfælde:

• Når der er kompromitterede, er krypteringsnøgler til stede
• Når krypteringsnøgletabellen er fuld, og der ikke kan tilføjes flere nøgler i systemet
• Når eksport af automatisk nøgle mislykkes
• Når automatisk nøglerotation mislykkes
• Når kryptering er deaktiveret
• Når systemadgangsudtrykket blev ændret

Spørgsmål: Er der nogen sikkerhedscertificering for DDOS? 
Svar: Data Domain-systemer overholder FIPS 140-2. 

Spørgsmål: Hvor gemmes krypteringsnøglen?
Svare: Krypteringsnøgler gemmes permanent i en samlingspartition i DDOS-systemet.

Spørgsmål: Hvis nogen trækker en harddisk ud af et Data Domain-system, kan du så dekryptere data fra det?
Svare: Krypteringsnøgler krypteres ved hjælp af systemadgangsudtryk, som er gemt i systemhovedet. Selvom krypteringsnøgler er gemt på disken, kan krypteringsnøgler ikke dekrypteres uden adgangsudtryk til systemet. Så uden at kende nøglen, der bruges til at kryptere dataene, er dekryptering ikke mulig fra en harddisk.  

Spørgsmål: Hvilke kryptografiske nøgler og adgangskoder er nødvendige for gendannelse, især til genoprettelse efter nedbrud?
Svare: Nøgler kan eksporteres i en sikker fil og opbevares eksternt i forhold til systemet. Gendannelse af denne fil sker ved hjælp af teknik. På tidspunktet for genoprettelse skal kunden også kende det adgangsudtryk, som vedkommende brugte på tidspunktet for kommandoen til nøgleeksport.

Spørgsmål: Sådan låses filsystemet før transit af systemet til fjernplacering.
Svare: Nedenfor er proceduren for det: 

• Deaktiver filsystemet:

  sysadmin@itrdc-DD630-42# filesys deaktiveres

• Lås filsystemet, og indtast et nyt adgangsudtryk (dette kræver godkendelse af ovenstående sikkerhedsbruger):

  sysadmin@itrdc-DD630-42# filesys-krypteringslås
  Denne kommando kræver godkendelse fra en bruger, der har en "sikkerheds"-rolle.
  Vis legitimationsoplysninger for en sådan bruger nedenfor.
          Brugernavn: secuser
  Password:
  Indtast den aktuelle adgangssætning:
  Indtast ny adgangssætning:
  Indtast ny adgangssætning igen:
  Adgangssætninger matchede.
  Filsystemet er nu låst.

• Den nye adgangssætning må IKKE gå tabt eller glemmes. Uden denne adgangssætning kan filsystemet ikke låses op, hvilket betyder, at der ikke er adgang til data på DDR. For at låse systemet op, når det når en fjernplacering, skal du bruge nedenstående kommando:

sysadmin@itrdc-DD630-42# filesys-kryptering låser op
Denne kommando kræver godkendelse fra en bruger, der har en "sikkerheds"-rolle.
Vis legitimationsoplysninger for en sådan bruger nedenfor.
        Brugernavn: secuser
Password:
Indtast adgangssætningen:
Adgangssætningen er blevet bekræftet. Brug 'filesys enable' til at starte filsystemet.

• Filsystemet kan nu aktiveres og bruges som normalt

Spørgsmål: Har kommandoen storage sanitize nogen relation til filsystemkryptering?
Svare: Nej, filsystemkryptering og lagerrensning er to uafhængige funktioner. 

Spørgsmål: Understøttes kryptering over tråden i EDP-systemet (encryption disablement project)?
Svare: Vi kan ikke aktivere Data at Rest Encryption (DARE) eller over trådkrypteringen (med replikering eller med ddboost) i EDP-systemet.

Systemadgangsudtryk 

Spørgsmål: Hvad er systemadgangsudtrykket?
Svare: DDOS har mulighed for at sikre legitimationsoplysninger i systemet ved at angive et adgangsudtryk på systemniveau. Adgangsudtrykket er en menneskelig læsbar (forståelig) nøgle, som f.eks. et smartcard, der bruges til at generere en maskinanvendelig AES 256-krypteringsnøgle. 

Det giver to fordele:

• Det giver administratoren mulighed for at ændre adgangsudtrykket uden at skulle manipulere krypteringsnøglerne. Ændring af adgangsudtrykket ændrer indirekte krypteringen af nøglerne, men påvirker ikke brugerdata. Ændring af adgangsudtrykket ændrer ikke den underliggende Data Domain-systemkrypteringsnøgle. Det ændrer krypteringen af Data Domain-systemnøglen, men systemnøglen forbliver den samme.
• Det gør det muligt at levere et fysisk Data Domain-system med en krypteringsnøgle på systemet, men uden at adgangsudtrykket gemmes på det. På denne måde, hvis boksen stjæles under transit, kan en angriber ikke let gendanne dataene, da systemet kun har krypterede nøgler og krypterede data.

Adgangsudtrykket gemmes internt i en skjult del af Data Domain-lagersystemet. Dette gør det muligt for Data Domain-systemet at starte og fortsætte med at servicere dataadgang uden indblanding fra administratoren.

Oprettelse eller ændring af adgangssætningen:

• Systemadgangsudtrykket kan oprettes ved hjælp af CLI, når en administrator har godkendt Data Domain-systemet.
• Systemadgangsudtrykket kan ændres ved hjælp af CLI, når en administrator og en bruger med sikkerhedsrollen (f.eks. en sikkerhedsansvarlig) er godkendt med Data Domain-systemet (så ingen enkelt administrator kan foretage ændringer uafhængigt).

Spørgsmål: Hvornår bruges adgangsudtrykket?
Svare: Systemadgangsudtrykket bruges som en primær nøgle af forskellige DDOS-komponenter, som omfatter filsystemkryptering, cloudadgang, certifikatstyring, Boost-tokens, systemkonfigurationsmoduler i skalerbare miljøer og licensoplysninger. DDOS-software indeholder mekanismer til at indstille og ændre dette systemadgangsudtryk. Den indeholder også indstillinger til at styre, om systemets adgangsudtryk er gemt på disken, hvilket især bruges til at øge sikkerheden, når DD-systemet transporteres. 

Spørgsmål: Hvordan bruges adgangsudtrykket til sikker transport af DD-systemet?
Svare: Processen bruger kommandoen "filesys encryption lock", som giver brugeren mulighed for at låse filsystemet ved at ændre adgangssætningen. Brugeren indtaster et nyt adgangsudtryk, der krypterer krypteringsnøglen igen, men det nye adgangsudtryk gemmes ikke. Krypteringsnøglerne kan ikke gendannes, før filsystemet låses op ved hjælp af kommandoen "filesys encryption unlock".

Processen er beskrevet i Confluence Lab Security Configuration Guide.

Spørgsmål: Hvad sker der, hvis adgangsudtrykket ændres? Kan der stadig opnås adgang til data?
Svare: Ja, ændring af adgangsudtrykket ændrer ikke den underliggende Data Domain-systemkrypteringsnøgle, kun krypteringen af krypteringsnøglen. Derfor påvirkes dataadgangen ikke.

Spørgsmål: Hvordan kan vi forespørge, om der er angivet en adgangssætning på systemet?
Svare: Hvis der er angivet et adgangsudtryk på systemet, vil kørsel af kommandoen "system passphrase set" medføre en fejl, der angiver, at adgangsudtrykket allerede er indstillet.

Spørgsmål: Hvad sker der, hvis adgangsudtrykket går tabt eller glemmes?
Svare: Hvis kunden mister adgangsudtrykket, mens boksen er låst, mister kunden sine data. Der er ingen bagdør eller alternativ måde at få adgang til det på. Uden en god proces til styring af denne adgangssætning kunne dette ske ved et uheld, og de ville ikke være i stand til at gendanne nøglen eller dataene. Den krypterede nøgle kan dog aldrig gå tabt eller blive ødelagt på grund af systemets integrerede beskyttelsesmekanismer.

Spørgsmål: Er der nogen mekanisme til at nulstille det glemte adgangsudtryk til systemet?
Svare: I visse scenarier kan systemets adgangsudtryk kun nulstilles med magt ved hjælp af kundesupport. Force-update-mekanismen, der blev introduceret i DDOS 7.2, kan kun bruges til dette, hvis specifikke betingelser er opfyldt. Du kan finde flere oplysninger i KB-artikel 20983, Data Domain: Sådan nulstilles et mistet adgangsudtryk til systemet i DDOS v7.2 eller nyere (log på Dell Support påkrævet for at se artiklen)

Spørgsmål: Er der mulighed for at undgå at gemme systemadgangsudtryk på DD-systemet?
Svare: Systemadgangsudtrykket gemmes som standard et skjult sted i Data Domain-systemet. Systemindstillingen "system passphrase option store-on-disk" kan bruges til at ændre dette og undgå at gemme adgangsudtryk på disken.

Embedded Key Manager (EKM)

Kommando på øverste niveau:

System# filesys kryptering integreret-key-manager <mulighed>

Spørgsmål: Understøttes nøglerotation med Embedded Key Manager?
Svare:  Ja, nøglerotation pr. Data Domain-system understøttes med Embedded Key Manager. Via brugergrænsefladen eller CLI kan administratoren oprette en nøglerotationsperiode (ugentligt eller månedligt).

Spørgsmål: Er der et gebyr for den integrerede nøgleadministrationsfunktionalitet?
Svare: Der er intet gebyr for denne funktionalitet. Denne funktionalitet er inkluderet som en del af standardlicensmuligheden for DD-krypteringssoftware.

Spørgsmål: Kan kunden gå fra lokal nøgleadministration til ekstern nøgleadministration (EKM)?
Svare

• Ja, eksterne nøgleadministratorer kan aktiveres når som helst. De lokale nøgler, der bruges, forbliver dog på Data Domain-systemet. Eksterne nøgleadministratorer kan ikke administrere EKM-nøglerne. Eksisterende data kræver ikke genkryptering. Hvis overholdelsesdata for en kunde skal krypteres igen med EKM-nøgler, skal det gøres manuelt ved hjælp af anvend-ændringer med den nye RW-nøgle. Det er ikke obligatorisk at ødelægge EKM-nøgler efter en switch.
  • key-manager switch skifter automatisk den aktive nøgle til nøglen fra KMIP. 
  • Eksempel på, hvordan KMIP-nøglens MUID ser ud, når der sker en switch

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

Spørgsmål: Hvad sker der, når nøglerotation er deaktiveret eller aktiveret?
Svare: 

• Deaktiveret nøglerotation er standardkrypteringsfunktionen, hvis du ikke aktiverer nøglerotation fra brugergrænsefladen eller CLI. I dette scenarie krypteres alle data med den eksisterende aktive nøgle.
• Hvis nøglerotation er aktiveret, roterer vi tasterne baseret på rotationsfrekvensen, og dataene krypteres med den nyeste aktive nøgle.

Eksterne nøgleadministratorer

Spørgsmål: Hvilke eksterne nøgleadministratorer understøttes på DD?
Svare: Vi understøtter nedenstående eksterne nøgleadministratorer:

• Gemalto KeySecure (understøttelse tilføjet i DDOS version 7.2)
• Vormetric (understøttelse tilføjet i DDOS version 7.3)
• CipherTrust (understøttelse tilføjet i DDOS version 7.7)
• IBM GKLM (understøttelse tilføjet i DDOS version 7.9)

Spørgsmål: Kræves der en separat licens for at aktivere integrationen med en ekstern nøglehåndtering?
Svare: Ja, der kræves en separat licens fra den respektive leverandør for at integrere External Key Manager med DD.

Spørgsmål: Hvor mange nøgleadministratorer støtter ad gangen?
Svare: Kun én nøglehåndtering kan være aktiv på et givet tidspunkt på et DD-system.

Spørgsmål: Hvor kan jeg finde flere oplysninger om, hvordan jeg konfigurerer KMIP External Key Manager?
Svare: KMIP-integrationsvejledningen til DDOS indeholder detaljerede oplysninger om konfiguration af de forskellige eksterne nøgleadministratorer, der understøttes af DD.

Spørgsmål: Hvordan administreres certifikater for eksterne nøgleadministratorer i DD?
Svare: Mens vi konfigurerer den eksterne nøglehåndtering, skal vi generere et CA-certifikat (CA-certifikat kan være et selvsigneret certifikat eller signeret af tredjepart) og værtscertifikat. Når konfigurationen er udført på External Key Manager-serveren, skal brugerne importere CA-certifikatet og værtscertifikatet på DD-systemet. Derefter konfigurerer og aktiverer vi den eksterne nøglehåndtering. 

Spørgsmål: Hvad er CA?
Svare: Et nøglecenter (CA) fungerer som den oprindeligt betroede delte enhed mellem peers og udsteder signerede certifikater for at gøre det muligt for hver part at stole på den anden. Et certifikat fungerer generelt som identiteten af en server eller klient. 

Spørgsmål: Hvad er et lokalt CA-signeret certifikat, hvad er et CA-signeret certifikat?
Svare: Et CA-signeret certifikat er et certifikat, der er udstedt og signeret af et offentligt betroet nøglecenter. Der er automatisk tillid til et CA-signeret certifikat. Et lokalt nøglecenter kan udstede signerede certifikater, da den private signeringsnøgle er gemt i Key Manager-systemet. Et eksternt nøglecenter gemmer ikke den private nøgle. I stedet bruges en ekstern CA som en betroet enhed til forskellige grænseflader og tjenester inde i systemet.

Spørgsmål: Hvordan oprettes en anmodning om certifikatsignering i DD?
Svare: På Data Domain System skal du generere CSR ved hjælp af nedenstående CLI-kommando. På denne måde vises den private nøgle aldrig for den eksterne nøglehåndtering.

adminaccess certifikat cert-signing-request

Spørgsmål: Er det muligt at skifte mellem nøgleadministratorer?
Svare: Skift mellem ekstern nøglehåndtering og integreret nøglehåndtering er tilladt og problemfrit. Men skift fra Embedded Key Manager til External Key Managers kræver passende certifikatinstallation og konfiguration. Skift mellem to eksterne nøgleadministratorer (f.eks.: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust til GKLM) er også tilladt. Migrering af Key Manager-nøgler understøttes også (se KMIP-integrationsvejledning for at få flere oplysninger).

Spørgsmål: Hvad sker der, når den eksterne Key Manager-forbindelse går ned? Er mine data så tilgængelige?
Svare: Ja, data er stadig tilgængelige, når vi ikke kan oprette forbindelse til nøglehåndteringen, da vi også gemmer en kopi af nøglerne i DD-systemet. Nye nøgler kan ikke oprettes, eller nøgletilstande kan ikke synkroniseres, når der ikke er forbindelse til den eksterne nøglehåndtering.

Spørgsmål: Er der en måde, hvorpå vi kan undgå at gemme nøgler i DD og kun gemme i External Key Manager?
Svare: Vi gemmer altid en kopi af nøglerne i DD-systemet til DIA-formål. Denne indstilling kan ikke ændres.

Spørgsmål: Er der nogen præstationspåvirkning på grund af integrationen med KMIP?
Svare: Nej, der er ingen påvirkning af ydeevnen på grund af brugen af eksterne nøgleadministratorer.

Spørgsmål: Er det muligt at udnytte KMIP-løsningen til udvalgte Data Domains i miljøet?
Svare: Ja, kunderne har fuld fleksibilitet, når de skal vælge den relevante krypteringsmetode til deres Data Domain-systemer. De kan fortsat udnytte Data Domains integrerede nøglehåndtering på nogle Data Domain-systemer og rotationen af krypteringsnøglen ved hjælp af KMIP på andre Data Domain-systemer i deres miljø.

Spørgsmål: Er Data Domain til KMIP-kommunikationen sikker?
Svare: Ja, Data Domain kommunikerer via X509-certifikatets gensidigt godkendte sessioner med TLS'en. Brugeren kan bruge Data Domain CLI til at importere det relevante X509-certifikat til Data Domain-systemet. Dette certifikat bruges derefter til at etablere den sikre kanal mellem DD og KMIP.

Vigtig livscyklusadministration 

Spørgsmål: Hvilke vigtige administrationsfunktioner findes der med DD-krypteringsmuligheden?
Svare: En nøgleadministrator styrer generering, distribution og livscyklusadministration af flere krypteringsnøgler. Et beskyttelsessystem kan bruge enten den integrerede nøglehåndtering eller den eksterne KMIP-nøglehåndtering. Kun én nøglehåndtering kan være i kraft ad gangen. Når kryptering er aktiveret på et beskyttelsessystem, er Embedded Key Manager aktiveret som standard. Hvis der er konfigureret en ekstern nøglehåndtering, erstatter den den integrerede nøglehåndtering og forbliver i kraft, indtil den deaktiveres manuelt. Skift fra Embedded Key Manager til External Key Manager eller omvendt resulterer i, at der føjes en ny nøgle til systemet, og det kræver ikke genstart af filsystemet fra version 7.1.

Spørgsmål: Hvad er de forskellige nøgletilstande i Data Domain-systemet?
De forskellige nøgletilstande på Data Domain-systemet er som følger:

• Aktiveret-RW: Der er kun én nøgle i denne tilstand på ethvert DD-system og bruges til læsning og skrivning af data. Denne nøgle bruges også af GC-processen til at kryptere containere igen.
• Afventer-Aktiveret: Der er kun én nøgle i denne tilstand på et DD-system. Dette identificerede den nøgle, der bliver Activated-RW efter næste genstart af filsystemet. I dag eksisterer denne tilstand kun på tidspunktet for aktivering af kryptering. Der oprettes ingen anden afventende aktiveret nøgle.  
• Aktiveret-RO: Eksterne nøgleadministratorer kan have flere aktiverede nøgler. Den seneste nøgle er i Activated-RW, resten er i denne tilstand. Nøgler kan gå i denne tilstand på DD-systemet, når vi ikke kan synkronisere tilstand med nøglehåndteringen.
• Deaktiveret: Dette bruges til at læse eksisterende data på DD-systemet.
• Kompromitteret: Når en kunde kompromitterer en ekstern nøglehåndteringsnøgle, ændres tilstanden til den efter næste nøglesynkronisering.  
• Markeret til destruktion: Når en kunde markerer en nøgle til destruktion, bliver nøgletilstanden markeret til ødelagt. Når GC køres, krypteres alle beholdere, der er krypteret med nøgler markeret til destrueret, igen ved hjælp af nøglen Activated-RW.
• Ødelagt: En nøgle i tilstanden Markeret til ødelagt går til denne tilstand, når der ikke er knyttet nogen data til den.
• Ødelagt-kompromitteret: En nøgle i tilstanden Kompromitteret går til denne tilstand, når der ikke er knyttet nogen data til den.

Spørgsmål: Kan krypteringsnøgler eksporteres til genoprettelse efter nedbrud?
Svare: Nøgler kan eksporteres manuelt ved hjælp af nedenstående kommando.

"Eksport af filesys-krypteringsnøgler"

DD-systemet eksporterer også nøgler som standard, når en ny nøgle tilføjes, eller når en nøgle slettes fra systemet.

Eksporterede filer findes i /ddr/var/.security, og det er i et krypteret format. Denne fil skal derefter kopieres ud af DDR og gemmes på et sikkert sted, som senere kan bruges i enhver katastrofegendannelsestilstand.

Bemærk: Import af nøgler til genoprettelse efter nedbrud kræver indgriben fra kundesupport, da gendannelsesprocessen afhænger af den type katastrofe, der er opstået. Vi kan importere den eksporterede nøglefil ved hjælp af følgende kommando.

Fileys-krypteringsnøgler importerer <filnavn> 

Spørgsmål: Er den nøgle, der genereres af KMIP, gemt i Data Domain-systemet?
Svare: Ja, krypteringsnøglen fra KMIP gemmes krypteret på Data Domain-systemet.

Spørgsmål: Hvordan anvendes en ændring af nøgletilstanden i KMIP-enheden på Data Domain-systemet?
Svare: Nøglesynkronisering sker dagligt. Hvis der er en ny nøgle tilgængelig, eller nøglens tilstand ændres, opdaterer synkroniseringen tabellen for den lokale nøgle. DD modtager vigtige opdateringer fra KMIP hver dag ved midnat.

Spørgsmål: Er det muligt manuelt at synkronisere nøgletilstandene mellem DD og KMIP?
Svare: Ja, Data Domain CLI eller brugergrænsefladen kan bruges til manuelt at synkronisere nøgletilstandene mellem DD og KMIP. "filesys encryption keys sync" er den kommando, der bruges til det.

Spørgsmål: Er det muligt at ændre det tidspunkt, hvor DD modtager vigtige opdateringer fra KMIP?
Svare: Nej, det er ikke muligt at ændre det tidspunkt, hvor DD modtager vigtige opdateringer fra KMIP.

Spørgsmål: Er der en grænse for antallet af nøgler, der understøttes af Data Domain-systemet?
Svare: Fra og med DDOS 7.8 kan Data Domain-systemet til enhver tid maksimalt have 1024 nøgler på systemet. Der er kun én nøgle i Activated-RW, og resten af nøglerne kan være i en hvilken som helst anden tilstand.

Spørgsmål: Kan forskellige nøgler bruges til forskellige datasæt på Data Domain-systemer? Kan dette konfigureres?
Svare: Nej, vi understøtter kun én aktiv nøgle i systemet ad gangen, og alle indgående data krypteres ved hjælp af den aktuelle aktive nøgle. Nøgler kan ikke kontrolleres ved en finere granularitet som M-træer.

Spørgsmål: Er der nogen meddelelse, når den maksimale nøglegrænse er nået?
Svare: Ja, der vises en advarsel, når den maksimale nøglegrænse på 1024 er nået.

Spørgsmål: Hvordan rydder jeg advarslen om maksimal nøglegrænse?
Svare: En af tasterne skal slettes for at rydde advarslen om maksimal nøglegrænse.

Spørgsmål: Kan vi se mængden af data, der er knyttet til en bestemt nøgle i Data Domain-systemet?
Svare: Ja, dette kan ses på DD, men kan ikke ses på KMIP-serveren. Brugeren kan bruge Data Domain CLI og brugergrænsefladen til at se mængden af data, der er knyttet til en bestemt nøgle.

Spørgsmål:  Kan vi se alderen på tasterne på DD-systemet?
Svare: Ja, det kan ses med EKM-nøgler ved hjælp af brugergrænseflade.

Spørgsmål: Fungerer den gamle nøgle, selvom tidsperioden er udløbet, med at gøre den nye nøgle effektiv?
Svare: Der er ingen udløbsdato for krypteringsnøgler. Gamle nøgler bliver skrivebeskyttede nøgler efter nøglerotation og forbliver i DDOS.

Spørgsmål: Slettes krypteringsnøglen automatisk, når der ikke er knyttet nogen data til den på Data Domain-systemet?
Svare: Nej, nøglen slettes ikke automatisk. Brugeren skal eksplicit slette nøglen ved hjælp af DD CLI eller brugergrænsefladen.

Spørgsmål: Kan en nøgle slettes, selvom der er data tilknyttet den på Data Domain-systemet?
Svare: Nej, hvis en nøgle har data tilknyttet, kan den ikke slettes. Genkryptering af data er nødvendig med en anden nøgle for at slette en nøgle, der har data tilknyttet.

Spørgsmål: Hvis en nøgle slettes i KMIP'en, slettes nøglen så også fra Data Domains nøgleliste?
Svare: Nej, brugeren skal uafhængigt slette nøglen ved hjælp af DD CLI eller brugergrænsefladen.

Spørgsmål: Kræves der en KMIP på alle placeringer i et Data Domain-miljø med flere lokationer?
Svare: Nej, det er ikke nødvendigt at have en KMIP på hvert websted med et Data Domain. Vi kan pege på én KMIP-server. Det anbefales at have en separat nøgleklasse for hvert DD-system, når de bruger den samme KMIP-server.

Spørgsmål: Hvis en nøgle er kompromitteret, har vi så en proces til at hente de data, der er krypteret med den gamle nøgle?
Svare: I dette tilfælde skal kunden markere nøglen som kompromitteret i KMIP-serveren. Udfør derefter "filesys encryption keys sync" i DDOS-systemet, og kør derefter "filesys encryption apply-changes", og kør derefter GC (filesys clean). GC run krypterer alle de data, der blev krypteret med den kompromitterede nøgle ved hjælp af en nyere nøgle. Når GC er færdig, ændres nøgletilstanden til kompromitteret-ødelagt. Senere kan de slette den nøgle. 

Kryptering og replikering

Spørgsmål: Understøttes DD-replikering og er den interoperabel med DD-krypteringssoftwaremuligheden?
Svare: Ja, DD-replikering kan bruges med DD-krypteringsindstillingen, hvilket gør det muligt at replikere krypterede data ved hjælp af alle forskellige former for replikering. Hver replikeringsformular fungerer entydigt med kryptering og tilbyder det samme sikkerhedsniveau.

Spørgsmål: Skal både kilde- og destinationssystemerne køre den samme version af DD OS for at bruge kryptering?
Svare: Kilde og destination kan være i forskellige DDOS-versioner for at bruge DARE med replikering, hvis replikeringskompatibilitetsmatrixen (se administratorvejledningen for kompatibilitetsmatrix) er på plads. 

Spørgsmål: Hvordan fungerer replikering med kryptering?
Svare: Det afhænger af, hvilken form for replikering der bruges.

Hvis den konfigurerede replikering er MREPL eller MFR:
Hvis der anvendes MREPL eller MFR, kan DD-kryptering licenseres eller aktiveres på enten kilden eller destinationen uafhængigt afhængigt af, hvad kunden ønsker at opnå.

• Når kryptering er aktiveret for både kilde og destination: Når data indtages i kildesystemet, krypteres de med kildesystemets krypteringsnøgle. Kilden dekrypterer de lokale data, krypterer dem igen ved hjælp af destinationssystemets krypteringsnøgle og replikerer derefter de krypterede data til destinationen, når de replikeres.
• Når kryptering er deaktiveret for kilden, og kryptering er aktiveret for destinationen: Alle data, der indtages til kilden, er ikke krypteret (af indlysende grund.) Men når der replikeres, krypterer kilden dataene ved hjælp af destinationssystemets krypteringsnøgle og replikerer derefter de krypterede data til destinationssystemet. 
• Når kryptering er aktiveret for kilden, og kryptering er deaktiveret for destinationen: Alle data, der indtages i kildesystemet, krypteres med kildesystemets krypteringsnøgle. Kilden dekrypterer dataene og replikerer derefter de ukrypterede data til destinationsdatadomænesystemet, når der replikeres.
• Hvis kryptering er aktiveret på replikaen, efter replikeringskonteksten er konfigureret, krypteres alle nye segmenter, der nu replikeres, ved kilden til replikaen. Alle segmenter, der er placeret på replikaen, før kryptering aktiveres, forbliver i en ikke-krypteret tilstand, medmindre kryptering anvender ændringer, og GC køres på destinationen. 

Hvis den konfigurerede replikering er CREPL:
Ved samlingsreplikering skal både kilde- og destinationssystemer køre samme DDOS-udgivelse. Derfor skal kryptering enten aktiveres eller deaktiveres på begge. Der kan heller ikke være en uoverensstemmelse i krypteringskonfigurationen. Krypteringsnøgler er de samme med kilde og destination. 

• Når kryptering er aktiveret for både kilde og destination: Alle data, der indtages i kildesystemet, krypteres ved hjælp af kildesystemets krypteringsnøgle. Når der replikeres, sender kilden krypterede data til destinationsdatadomænesystemet i krypteret tilstand. Data Domain-destinationssystemet har den samme nøgle som kilden, da samlingsreplikering handler om en nøjagtig replika af Data Domain-kildesystemet. Der kan ikke skrives data til Data Domain-destinationssystemet uden replikering, da destinationen er skrivebeskyttet.
• Når kryptering er deaktiveret for både kilde og destination: Alle data, der indtages til kildesystemet, er ikke krypteret (af indlysende grund.) Når der replikeres, sender (replikerer) kilden dataene i ukrypteret tilstand, og de forbliver ukrypterede på destinationsdata Domain-systemet. Der kan ikke skrives data til Data Domain-destinationssystemet uden replikering, da destinationen er skrivebeskyttet.

Spørgsmål: Er destinationens nøgle gemt på ubestemt tid på kildesystemet Data Domain?
Svare: Destinationens krypteringsnøgle gemmes aldrig på Data Domain-kildesystemet. Den opbevares kun i hukommelsen (krypteret), mens replikeringssessionen er aktiv. Dette gælder for alle former for replikering med undtagelse af samlingsreplikering. I samlingsreplikering (CREPL) findes det samme sæt krypteringsnøgler i kilde og destination.  

Spørgsmål: Kan kryptering aktiveres i CREPL-systemet, når replikeringskonteksten er etableret?
Svare: Ja, i dette tilfælde skal kryptering være aktiveret på både kilde og destination. Kryptering kan aktiveres i kilde og destination ved at deaktivere replikeringskonteksten. Alle nye replikerede segmenter krypteres på replikaen. Alle segmenter, der findes på replikaen, før kryptering aktiveres, forbliver i en ikke-krypteret tilstand.

Spørgsmål: Kan DD-kryptering aktiveres samtidig med over-the-wire-krypteringsfunktionen i DD-replikeringssoftwarevalgmuligheden?
Svare: Ja, både trådkryptering og D@RE kan aktiveres samtidigt for at opnå forskellige sikkerhedsmål.

Spørgsmål: Hvad sker der, hvis både DD-krypteringssoftwareindstillingen og over-the-wire-krypteringsfunktionen i DD-replikeringssoftwareindstillingen aktiveres samtidigt?
Svare: Den første kilde krypterer data ved hjælp af destinationskrypteringsnøglen. Derefter krypteres allerede krypterede data en anden gang på grund af kryptering over ledningen, mens disse data sendes til deres destination. På destinationen, efter at dekrypteringen over ledningen er udført, gemmes data i et krypteret format, der blev krypteret ved hjælp af destinationens krypteringsnøgle.

Spørgsmål: Når kryptering er aktiveret i kilde og destination, skal adgangsudtrykket så være det samme på begge?
Svare: Hvis den konfigurerede replikering er samlingsreplikering (CREPL), skal adgangssætningen være den samme. For andre former for replikering (f.eks. MREPL, MFR) kan adgangsudtryk være forskellige i kilde og destination.

Spørgsmål: Når kryptering er aktiveret på destinationen (spørgsmålet gælder ikke for CREPL), bliver både de replikerede data og data fra et andet adgangspunkt (f.eks. via lokal backup) krypteret? Er der en måde at adskille de to på replikaen, hvor kun de replikerede mapper krypteres, mens anden adgang ikke er krypteret?
Svare: Nej, alle data krypteres på replikaen (destinationen) uanset indgangspunktet. Kryptering kan ikke kun aktiveres eller deaktiveres ved granularitet på MTree- eller mappeniveau. 

Spørgsmål: Hvordan foregår nøgleudvekslingen mellem kilde og destination under MREPL eller MFR?
Svare: I replikeringsfasen overfører destinationsmaskinen sin aktuelle krypteringsalgoritme og nøgleoplysninger sikkert til kilden. Replikeringskontekster godkendes altid med en delt hemmelighed. Denne delte hemmelighed bruges til at etablere en "session" -nøgle ved hjælp af en Diffie-Hellman-nøgleudvekslingsprotokol. Denne sessionsnøgle bruges til at kryptere og dekryptere Data Domain-systemkrypteringsnøglen.

Spørgsmål: Hvilken type krypteringsalgoritme bruges til Data Domains "kryptering over ledningen"-funktion vedrørende kryptering af replikeringstrafikken?
Svare: Når replikeringsgodkendelsestilstand er indstillet til "envejs" eller "tovejs", bruges DHE (Ephemeral Diffie-Hellman) til udveksling af sessionsnøgler. Servergodkendelse sker ved hjælp af RSA. AES 256-bit GCM-kryptering bruges til at indkapsle de replikerede data over ledningen. Krypteringsindkapslingslaget fjernes straks, når det lander på destinationssystemet. 

En måde angiver, at kun destinationscertifikatet er certificeret. To måder angiver, at både oprindelses- og destinationscertifikaterne er verificeret. Der skal skabes gensidig tillid, før du kan bruge godkendelsestilstand, og begge sider af forbindelsen skal aktivere denne funktion, for at krypteringen kan fortsætte.

Når replikeringsgodkendelsestilstand er indstillet til "anonym", bruges Anonymous Diffie-Hellman (ADH) til udveksling af sessionsnøgler, men i dette tilfælde godkender kilde og destination ikke hinanden før nøgleudvekslingen. Hvis godkendelsestilstanden ikke er angivet, bruges anonym som standard.

Spørgsmål: Fungerer nøglerotation uden genstart af filsystemet med alle former for replikering?
Svare: Nøglerotation uden genstart af filsystemet fungerer med alle former for replikering undtagen DREPL (DREPL-understøttelse er allerede afsluttet) og delta-replikering (som også kaldes LBO)

Spørgsmål: Hvis der ikke findes certifikater eller PKI-nøglepar, hvordan beskyttes destinationens krypteringsnøgle så under nøgleudvekslingen?
Svare: Der er en delt hemmelighed mellem alle Data Domain-replikeringspar, der bruges til at oprette en delt sessionsnøgle ved hjælp af en Diffie-Hellman-nøgleudveksling. Den delte nøgle bruges til at kryptere destinationens krypteringsnøgle.

Der er forskel på den delte hemmelighed, der bruges til replikeringsgodkendelse, og den delte sessionsnøgle, som tildeles ved hjælp af Diffie-Hellman-nøgleudvekslingsprotokollen. Den delte hemmelighed, der bruges til replikeringsgodkendelse, oprettes af Data Domain-softwaren, første gang to Data Domain-systemer ønsker at etablere en replikeringskontekst. Det aftales også gennem en Diffie-Hellman, der udveksles ved hjælp af parametre, der er indlejret i koden. Dette gemmes vedvarende i systemerne for at godkende hver replikeringssession mellem de to systemer. Replikeringssessionsnøglen (nøglen, der bruges til at kryptere destinationens krypteringsnøgle) oprettes ved hjælp af en anden Diffie-Hellman-udveksling med den tidligere etablerede delte hemmelighed, hvorved den sikre nøgleudvekslingsprotokol køres. Denne nøgle er ikke vedvarende og findes kun, mens replikeringskonteksten er aktiv.

Spørgsmål: Er det nødvendigt, at begge Data Domains i et replikeringspar bruger den samme eksterne nøglehåndteringsløsning (f.eks. KMIP-nøglehåndtering), eller kan et af systemerne bruge ekstern nøglehåndtering, og et andet system kan bruge integreret nøglehåndtering?
Svare: Bortset fra et samlingsreplikeringspar er det ikke nødvendigt, at begge systemer i et replikeringspar bruger samme nøglehåndtering.

Ved samlingsreplikering skal begge Data Domain-systemer konfigureres med den samme nøglestyring. Men også i dette tilfælde synkroniserer den eneste kilde nøgler med nøglehåndteringen, og disse nøgler sendes også over til destinationen. Med andre replikeringstyper kan forskellige nøgleadministratorer bruges med kilde og destination.

Kryptering og migrering

Spørgsmål: Understøttes datamigration på systemer med kryptering aktiveret?
Svare: Ja, datamigration understøttes på systemer, hvor kryptering er aktiveret. Krypteringskonfigurationen på kilde- og destinationssystemer skal matches som en forudsætning, før datamigreringen påbegyndes. Det anbefales også at eksportere og sikkerhedskopiere krypteringsnøgler på kildesystemet til DIA-formål, før migreringen påbegyndes.

Spørgsmål: Understøttes datamigrering for migrering på både aktivt niveau og cloud niveau for krypteringsaktiverede systemer?
Svare: Ja, datamigration understøttes til migrering på både aktivt niveau og på cloudniveau for krypteringsaktiverede systemer. Listen over påkrævede attributter, der er kontrolleret, anvendes ud fra, hvilket niveau der har kryptering aktiveret.

Spørgsmål: Hvilke krypteringsindstillinger bevares som en del af overførslen?
Svare: Krypterede data og krypteringsnøgler overføres, som de er, men indstillinger som krypteringsnøglehåndtering, systemadgangsudtryk og anden krypteringskonfiguration skal bekræftes manuelt og matches for at gennemføre datamigrering. Eventuelle eksisterende key-manager-certifikater overføres også til destinationssystemet. Konfigurationen af krypteringsnøglehåndteringen skal konfigureres igen på destinationssystemet efter migreringen.

Spørgsmål: Hvilke kontroller af krypteringskompatibilitet udføres mellem kilde og destination under migreringen?
Svare: Systemadgangsudtryk, krypteringsstatus og key-manager-konfigurationsoplysninger, system-FIPS-tilstandsindstillinger er nogle af de krypteringsindstillinger, der skal være identiske på kilde- og destinationssystemer, for at migreringen kan lykkes. Denne KB-artikel 183040, Data Domain: Migreringsprocedure for cloud-aktiverede DD-systemer (log på Dell Support kræves for at se artiklen), beskriver trinnene til migrering mellem systemer med cloud-funktionalitet aktiveret. De samme indstillinger gælder også for migrering kun på aktivt niveau.

Spørgsmål: Understøttes migrering mellem systemer med indstillingen Encryption Disablement Project aktiveret?
Svare: Datamigration understøttes mellem to systemer, hvis et af dem begge er omfattet af proceduren i forbindelse med uforholdsmæssigt store underskud, eller begge er systemer uden proceduren i forbindelse med uforholdsmæssigt store underskud. Datamigration er tilladt fra et EDP-system til et ikke-EDP-system, hvis on-the-wire-kryptering udtrykkeligt er slået fra. (ved hjælp af MIGRATION_ENCRYPTION sysparam)

Kryptering i Cloud Tier 

Spørgsmål: Understøttes kryptering på cloudniveau?
Svare: Ja, kryptering understøttes på Cloud Tier. Kryptering er som standard deaktiveret på cloudniveauet. Kommandoen "Cloud Enable" giver dig mulighed for at vælge, om vi vil aktivere kryptering på Cloud Tier.

Spørgsmål: Understøttes KMIP og eksterne nøgleadministratorer med cloudniveauet?
Svare: Ja, KMIP og eksterne nøgleadministratorer understøttes med Cloud Tier fra DDOS 7.8 og frem.

Spørgsmål: Med hvilken granularitet kan kryptering aktiveres i skyen?
Svare: Kryptering kan aktiveres og deaktiveres på hver cloudenhed og hvert niveau uafhængigt af hinanden.

Spørgsmål: Har cloud-enheder uafhængige nøgler?
Svare: Nej, nøgleadministration er fælles for både aktive niveauer og cloudniveauer i DD. Nøglerne kopieres over til den respektive enhed/niveau/cp, når kryptering er aktiveret. Hvis kryptering er aktiveret på aktiv og ikke på cloud, afspejles aktive niveaunøgler ikke på cloud og omvendt. Dette gælder også for cloud-enhederne. (For eksempel: CP1 har kryptering aktiveret, og CP2 har ikke kryptering aktiveret, så afspejler CP1-nøgler ikke CP2.)   

Spørgsmål: Kan nøgler slettes i skyen?
Svare: Nej, sletning af nøgler fra skyen understøttes ikke.

Spørgsmål: Hvor administreres datakrypteringsnøgler til cloudenheder?
Svare: Nøgler er knyttet til en cp, og hver cloud-enhed er en anden cp. En kopi af nøgler fra alle cps gemmes i aktiv cp.

Spørgsmål: Hvordan gendanner vi skynøgler under katastrofegendannelse? 
Svar: cpnameval spejles til skyen som en del af CP-gendannelsen, krypteringsnøglerne gendannes til cpnameval. Nu skal vi køre ddr_key_util værktøj til at gendanne nøglerne.

Bemærk: Genoprettelse efter nedbrud kræver indgriben fra kundesupport.

Spørgsmål: Kan vi foretage dataflytning, når kryptering kun er aktiveret i Cloud Tier?
Svare: Nej, vi skal aktivere kryptering i både sky og aktive niveauer til dataflytning.

Spørgsmål: Kan vi aktivere ekstern nøglehåndtering på skyniveau?
Svare: Ja, ekstern nøglehåndtering kan aktiveres på cloudniveau. Denne funktion understøttes 7.8 og senere. Alle handlinger undtagen ødelæggelse eller sletning af nøgle, der er gyldig for aktivt niveau, gælder også for Cloud Tier med hensyn til ekstern nøglehåndtering. 

Kryptering og affaldsindsamling

Spørgsmål: Hvilken rolle spiller den globale rensningsproces i Encryption-At-Rest, og har det en indvirkning på ydeevnen, når du aktiverer kryptering for første gang?
Svare: Aktivering af kryptering af data i hvile for første gang har en indvirkning på ydeevnen af global rensning. Dette skyldes, at data, der skal læses fra eksisterende beholdere på disken og skrives til nye beholdere, muligvis skal læses, dekrypteres, og dekomprimeres, før de komprimeres igen, krypteres og skrives tilbage til disken. Når kryptering er aktiveret på en DD, der indeholder en betydelig mængde allerede eksisterende data, og kommandoen 'filesys encryption apply-changes' køres, forsøger den efterfølgende globale oprydningscyklus at kryptere alle eksisterende data på systemet. Det betyder, at alle data skal læses, dekomprimeres, komprimeres, krypteres og skrives ud på disken. Som følge heraf kan den første globale rengøringscyklus efter at have kørt 'filesys encryption apply-changes' tage længere tid end normalt. Kunderne skal sikre, at de har tilstrækkelig ledig plads på deres DD-system til at lade rensningen køre til færdiggørelse, uden at DD-systemet bliver fuldt (ellers mislykkes sikkerhedskopieringer).

Spørgsmål: Har en indvirkning på ydeevnen ved fortsat at indtage/gendanne rene cyklusser?
Svare: Ja, der er påvirkning af ydeevnen, og påvirkningen afhænger generelt af mængden af data, der indtages/gendannes mellem rene cyklusser.

Spørgsmål: Hvor lang tid tager det at kryptere mine eksisterende data?
Brug denne KB-artikel til at estimere tiden, Data Domain: Beregning af, hvor lang tid kryptering i hvile tager at anvende.

Kryptering og headswap 

Spørgsmål: Kan kunden flytte disken til et andet Data Domain-system, hvis et hoved svigter, og få adgang til disken, når kryptering er aktiveret?
Svare: Krypteringsnøglen er ikke bundet til selve Data Domain-systemhovedet, så du kan flytte diskene til et andet Data Domain-systemhoved, og nøglen er tilgængelig der. På et nyt Data Domain-systemhoved er filsystemet låst, så du skal indtaste adgangsudtrykket med kommandoen "filesys encryption unlock". 

Spørgsmål: Hvad hvis en kunde glemte adgangssætningen på tidspunktet for headswap-handlingen?
Svare: I løbet af denne tid kan de tilslutte det gamle hoved og arbejde med support for at nulstille adgangssætningen og derefter oprette forbindelse tilbage til det nye hoved og afslutte headswap-proceduren. 

Krypteringsydeevne

Spørgsmål: Hvad er den observerede indvirkning på lagerforbruget, når der anvendes kryptering?
Svare: Det er ubetydeligt med ca. 1 procent overhead forbundet med lagring af nogle krypteringsparametre med brugerdata.

Spørgsmål: Hvad er den observerede indvirkning på gennemstrømning (skrivninger og læsninger), når der anvendes kryptering af inaktive data?
Svare: Påvirkningen af overførselshastigheden, når der anvendes kryptering, kan variere afhængigt af protokollen og platformen. Generelt er følgende procentdele konservative forringelser af ydeevnen i samlet overførselshastighed:

CBC-tilstand
først fuld: ~10 % forringelse af ydeevnen på SKRIVNINGER
Trinvis: ~5 % forringelse af ydeevnen på WRITEs
Gendannelser: 5-20 % forringelse af ydeevnen på READs GCM-tilstand


First Full: 10-20 % forringelse af ydeevnen på SKRIVNINGER
Trinvis: 5-10 % forringelse af ydeevnen på SKRIVNINGER
Gendannelser: 5-20 % forringelse af ydeevnen på READ'er

Disse tal er specifikke for de faste omkostninger ved kryptering af inaktive data (kryptering over tråden bogføres separat)
 

Bedste fremgangsmåder

Spørgsmål: Hvad er bedste praksis vedrørende central rotationspolitik?
Svare: Automatisk nøglerotationspolitik er som standard ikke aktiveret. Kunden har aktiveret det. Det anbefales at rotere krypteringsnøgler ofte. Når et system er konfigureret med en ekstern KMIP-nøglehåndtering, anbefales det at rotere taster ofte for at håndtere eventuelle vigtige kompromitteringsscenarier i fremtiden. Når KMIP er konfigureret med cloudniveauet, er det foreslåede nøglerotationsinterval 1 uge, og når KMIP kun er konfigureret på det aktive niveau, er den foreslåede nøglerotationspolitik 1 måned. Baseret på indtagelseshastigheden kan kunden dog også øge eller mindske nøglerotationsfrekvensen. Hvis integreret nøglehåndtering er konfigureret, anbefales nøglerotationspolitik hvor som helst mellem 1 - 3 måneder. 

Spørgsmål: Hvad er bedste praksis med KMIP-nøgleklasse, hvis en kunde bruger den samme KMIP-server til mange DD-systemer?
Svare: Det anbefales at have en separat nøgleklasse for hvert DD-system, når de bruger den samme KMIP-server. På den måde påvirker nøglerotation udført i et DDOS-system ikke tilstanden for den nøgle, der findes i andet DDOS-system.

Du kan finde flere oplysninger i dokumentet DELL EMC PowerProtect DD-seriens enheder: Krypteringssoftware (delltechnologies.com)

Kryptering: Teknisk hvidbog om PowerProtect DD-seriens enheder: Krypteringssoftware

Anden dokumentation relateret til DD-kryptering (administratorvejledning, kommandoreferencevejledning og sikkerhedskonfigurationsvejledning) kan findes i artikel 126375, PowerProtect- og Data Domain-kernedokumenter.

KMIP-integrationsvejledning og kompatibilitetsmatrix

Se denne video: