Dell EMC Data Domain Encryption – usein kysytyt kysymykset

Salauksen määritykset

Kysymys: Miten salaus (DARE) määritetään DD:ssä?
Vastata: DARE Encryption voidaan määrittää DD:ssä seuraavasti:

1. Lisää salauslisenssi

2. Security Officerin lisääminen ja Security Officerin valtuutusten ottaminen käyttöön

3. Ota salaus käyttöön 

1) Lisää salauslisenssi:
Lisää käyttöoikeustiedosto, johon on lisätty voimassa oleva salauskäyttöoikeus.
Päivitä DD:n e-lisenssi käyttämällä käytettävissä olevaa käyttöoikeustiedostoa alla olevalla komennolla.

eLicense-päivitys

2) Lisää Security Officer ja ota SO-valtuutukset käyttöön:
a) Lisää käyttäjä, jolla on "security"-rooli, komennolla 

Käyttäjä lisää secworker-roolin suojauksen

b) Ota Security Officerin valtuutus käyttöön asetuksissa komennolla 

Valtuutuskäytännön määritys Security Officer käytössä

3. Ota DARE-salaus käyttöön:
Ota DARE Encryption käyttöön komennolla

Filesys-salauksen käyttöönotto

Kysymys: Mitä ympäristöjä levossa olevien tietojen salaustoiminto tukee?
Vastata: Kaikki Data Domain -järjestelmät tukevat levossa olevien tietojen salausominaisuutta EDP (Encryption Disablement Project) -järjestelmiä lukuun ottamatta.

Kysymys: Miten käyttäjä voi tallentaa tietonsa selkeänä tekstinä DD:hen?
Vastata: Käyttäjä voi varmistaa, että tiedot on tallennettu salaamattomana eikä salattu DD:ssä, varmistamalla, että salaus on poistettu käytöstä asetuksissa.
Käyttäjät voivat poistaa DD:n salauksen käytöstä komennolla 

Filesys-salauksen poistaminen käytöstä

Kysymys: Mitä varmuuskopiosovelluksia/protokollia levossa olevien tietojen salaustoiminto tukee?
Vastata: DD DARE -ominaisuus ei riipu varmuuskopiointisovelluksesta tai DD:n käyttämästä protokollasta.

Question: Mitä salausalgoritmeja Data Domain -järjestelmässä voi valita?
Vastata: DD Encryption -ohjelmisto tukee AES 128- tai 256-bittistä algoritmia, joka käyttää CBC (Cipher Block Chaining)- tai GCM (Galois Counter Mode) -tilaa. 

GCM on symmetristen avainten salauslohkojen salausten toimintatapa. Se on todennettu salausalgoritmi, joka on suunniteltu tarjoamaan sekä todennus että yksityisyys (luottamuksellisuus). Kuten nimestä voi päätellä, GCM yhdistää tunnetun salaustilan uuteen Galois-todennustilaan. GCM:n todennusnäkökohta takaa, että Data Domain -järjestelmä teki salatut tiedot eikä niitä "syötetty" jollakin muulla tavalla. Tämä eroaa CBC: stä, jossa tiedot salataan (yksityisyyden näkökulmasta), mutta salattujen tietojen aitoutta ei tarkisteta.

CBC-tilassa jokainen pelkkää tekstiä sisältävä lohko on yksinomainen ORed edellisen salaustekstilohkon kanssa ennen salausta. Tällä tavalla jokainen salaustekstilohko riippuu kaikista siihen mennessä käsitellyistä pelkistä tekstilohkoista. Jotta jokainen viesti olisi ainutlaatuinen, ensimmäisessä lohkossa on käytettävä alustusvektoria. CBC takaa tietojen yksityisyyden (luottamuksellisuuden) vain salauksen avulla. Salausalgoritmia tai -prosessia ei todenneta.

Kysymys: Miten DD:n salausalgoritmia voidaan muuttaa?

Vastaus: Käytä alla olevaa komentoa, jos haluat määrittää asetuksissa tietyn salausalgoritmin.

Filesys-salausalgoritmijoukko

Esimerkki:

# filesys salausalgoritmijoukko {aes_128_cbc | aes_256_cbc | aes_128_gcm | aes_256_gcm}

Kysymys: Miten varmistetaan, että käytössä olevat tiedot salataan?
Vastata: DDFS:n voi pakottaa salaamaan olemassa olevat tiedot seuraavalla komennolla:

# filesys encryption apply-changes

Tämä tekee seuraavasta puhdistusjaksosta huomattavasti normaalia pidemmän ja resurssi-intensiivisemmän.

Kysymys: Miten DD:n salaus poistetaan käytöstä?
Vastata: Poista DD:n salaustoiminto käytöstä salauksen käytöstä poistokomennolla: 

Filesys-salauksen poistaminen käytöstä

Tämä poistaa salauksen käytöstä ainoastaan saapuvilta I/O-liitännöiltä. Olemassa olevat salatut tiedot pysyvät salattuina, kunnes niiden salaus puretaan manuaalisesti apply-changes-toiminnolla.

Kysymys: Mitkä salauskomennot vaativat DD-tiedostojärjestelmän uudelleenkäynnistyksen, jotta ne tulevat voimaan?
Vastata: Seuraavat salauskomennot vaativat DD-tiedostojärjestelmän uudelleenkäynnistyksen, jotta se tulee voimaan:

Filesys-salaus Ota käyttöön / poista käytöstä - Ottaa salauksen käyttöön tai poistaa sen käytöstä Data Domain -järjestelmässä.

Filesys Encryption Algorithm Set - Anna käyttäjän valita salausalgoritmi.

Filesys-salausalgoritmin nollaus - Palauttaa salausalgoritmiksi AES 256:n CBC-tilassa (oletus).

Kysymys: Mitkä salauskomennot edellyttävät Data Domain -tiedostojärjestelmän poistamista käytöstä, jotta tiedostojärjestelmä voidaan määrittää/käyttää?
Vastata: Seuraavat salauskomennot edellyttävät, että Data Domain -tiedostojärjestelmä on poistettu käytöstä, jotta sitä voi määrittää ja käyttää:

Salauksen tunnuslauseen muutos

Salauksen lukitus/avaus

Yleisiä salauskysymyksiä

Kysymys: Tuetaanko DD-salausta kaikissa DD-järjestelmissä?
Vastata: DD Encryption -ohjelmistovaihtoehtoa tuetaan DD-järjestelmissä, jos kyseessä ei ole salauksen käytöstäpoistoprojekti (EDP), jotka ovat järjestelmiä, jotka eivät salli salauksen käyttöönottoa ja joita myydään pääasiassa Venäjän alueen järjestelmissä.

Kysymys: Miten salaus suoritetaan DD-järjestelmissä?
Vastata: Salaus tehdään OpenSSL- ja RSA BSafe -kirjastoilla (RSA BSafe on FIPS 140-2 -validoitu salauskirjasto, jota DD-järjestelmät käyttävät lepotilassa olevien tietojen salaamiseen). 

Kysymys: Mitä BSafe-versiota järjestelmän kanssa käytetään?
Vastata: DDOS 7.10 -versiosta lähtien käytetyt BSafe-versiot ovat "BSAFE Micro Edition Suite 4.4.0.0" ja "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Kysymys: Mitkä ovat käytettävissä olevat käyttöliittymät salauksen määrittämiseen DDOS:ssa?
Vastata: Salaus voidaan määrittää komentoriviliittymän, käyttöliittymän tai REST-ohjelmointirajapintojen avulla. Tuettu REST API on lisätty DDOS-versioon 8.0 alkaen.

Kysymys: Tietojen valikoiva salaus on mahdollista? Kuten vain yksi MTree tai tiedosto?
Vastata: Valikoiva salaus EI ole mahdollista. Salaus voidaan ottaa käyttöön tai poistaa käytöstä vain koko järjestelmässä, ei valikoivasti. Järjestelmissä, joissa on pilvituki, salaus voidaan ottaa käyttöön tai poistaa käytöstä pilvitason ja pilviyksikön rakeisuuden mukaan.  

Kysymys: Lähetetäänkö tai tallennetaanko salausavaimia tai tilien salasanoja selkeällä tekstillä tai heikoilla salauksilla, kuten entiteetin todennuksen yhteydessä, datatiedostossa, ohjelmissa tai todennushakemistoissa?
Vastata: Ehdottomasti ei.

Kysymys: Mitä OpenSSL-versiota järjestelmässä käytetään?
Vastata: DDOS 7.10 -julkaisusta lähtien openssl-versio on "OpenSSL 1.0.2zd-fips"

Kysymys: Miten levossa olevien tietojen salaus suojaa käyttäjien ja sovellusten tietojen käytöltä?
Vastata: 

• Lepotilassa olevien tietojen salaus tarkoittaa levyn alijärjestelmässä olevien tietojen salausta. Salaus tai salauksen purku tapahtuu pakkauskerroksessa. Käyttäjät tai sovellukset lähettävät ja vastaanottavat selkeää tekstiä Data Domain -järjestelmään, mutta kaikki Data Domain -järjestelmässä fyysisesti olevat tiedot salataan.
• Kaikki salaus tapahtuu tiedostojärjestelmän ja nimitilan alapuolella, eikä se näy käyttäjille tai sovelluksille. Jos käyttäjällä tai sovelluksella on jo valtuutettu käyttöoikeus tiedostoon tai hakemistoon, tiedot voidaan lukea alkuperäisessä muodossaan salauksesta riippumatta.
• DD-salaus on suunniteltu siten, että jos tunkeilija kiertää muita verkon turvatoimintoja ja pääsee käsiksi salattuihin tietoihin ilman asianmukaisia salausavaimia, tiedot ovat lukukelvottomia ja käyttökelvottomia kyseiselle henkilölle. 

Kysymys: Tapahtuuko salaus deduplikoinnin jälkeen?
Vastata: Kyllä, tietojen kaksoiskappaleiden poistaminen salataan. Tiedot salataan ennen levylle tallentamista. 

Kysymys: Miten Data Domain varmistaa tietojen turvallisuuden?
Vastata: Tiedot suojataan käyttämällä lepotilassa olevien tietojen salausominaisuutta. Lisäksi, kun laite poistetaan (pään vaihto, tiedostojärjestelmän lukitus), salasana poistetaan järjestelmästä. Tätä salasanaa käytetään salausavainten salaamiseen, joten tiedot ovat paremmin suojattuja.

Kysymys: Mitä hälytyksiä salaus
luo?Vastata: Hälytykset luodaan seuraavissa tapauksissa:

• Kun salausavaimet ovat vaarantuneet
• Kun salausavainten taulukko on täynnä eikä järjestelmään voi lisätä uusia avaimia
• Kun automaattinen avainten vienti epäonnistuu
• Kun automaattinen näppäinkierto epäonnistuu
• Kun salaus on poistettu käytöstä
• Kun järjestelmän salasana muuttui

Kysymys: Onko DDOS:lle tietoturvasertifikaattia? 
Vastaus: Data domain -järjestelmät täyttävät FIPS 140-2 -vaatimukset. 

Kysymys: Mihin salausavain tallennetaan?
Vastata: Salausavaimet tallennetaan pysyvästi DDOS-järjestelmän keräysosioon.

Kysymys: Jos joku vetää kiintolevyn Data Domain -järjestelmästä, voiko tietojen salauksen purkaa?
Vastata: Salausavaimet salataan järjestelmän salasanalla, joka on tallennettu järjestelmän päähän. Vaikka salausavaimet on tallennettu levylle, salausavaimia ei voi purkaa ilman järjestelmän salasanaa. Joten tietämättä avainta, jota käytettiin tietojen salaamiseen, salauksen purkaminen ei ole mahdollista kiintolevyltä.  

Kysymys: Mitä salausavaimia ja salasanoja tarvitaan palautukseen, erityisesti katastrofista palautumiseen?
Vastata: Avaimet voidaan viedä suojattuun tiedostoon ja pitää järjestelmän ulkopuolella. Tämän tiedoston palauttaminen tapahtuu suunnittelun avulla. Myös palautuksen aikana asiakkaan on tiedettävä salasana, jota hän käytti näppäinten vientikomennon aikana.

Kysymys: Tiedostojärjestelmän lukitseminen ennen järjestelmän siirtämistä etäsijaintiin.
Vastata: Alla on menettely: 

• Poista tiedostojärjestelmä käytöstä:

  sysadmin@itrdc-DD630-42# filesys pois käytöstä

• Lukitse tiedostojärjestelmä ja kirjoita uusi tunnuslause (tämä edellyttää edellä mainitun suojauskäyttäjän suorittamaa todennusta):

  sysadmin@itrdc-DD630-42# filesys -salauslukko
  Tämä komento edellyttää suojausroolin omaavan käyttäjän valtuutusta.
  Esitä tällaisen käyttäjän tunnistetiedot alla.
          Käyttäjätunnus: secuser
  Salasana:
  Anna nykyinen tunnuslause:
  Kirjoita uusi tunnuslause:
  Kirjoita uusi tunnuslause uudelleen:
  Vastaavat tunnuslauseet.
  Tiedostojärjestelmä on nyt lukittu.

• Uusi tunnuslause EI saa kadota tai unohtua. Ilman tätä salasanaa tiedostojärjestelmän lukitusta ei voi avata, mikä tarkoittaa, että DDR:n tietoja ei voi käyttää. Voit avata järjestelmän lukituksen, kun se saavuttaa etäsijainnin, käyttämällä alla olevaa komentoa:

sysadmin@itrdc-DD630-42# filesys -salauksen lukituksen poisto
Tämä komento edellyttää suojausroolin omaavan käyttäjän valtuutusta.
Esitä tällaisen käyttäjän tunnistetiedot alla.
        Käyttäjätunnus: secuser
Password:
Anna salasana:
Salasana on vahvistettu. Käynnistä tiedostojärjestelmä komennolla 'filesys enable'.

• Tiedostojärjestelmä voidaan nyt ottaa käyttöön ja sitä voidaan käyttää normaalisti

Kysymys: Onko storage sanitize -komennolla mitään yhteyttä tiedostojärjestelmän salaukseen?
Vastata: Ei, tiedostojärjestelmän salaus ja tallennustilan tyhjentäminen ovat kaksi toisistaan riippumatonta ominaisuutta. 

Kysymys: Tukeeko EDP (encryption disablement project) -järjestelmä over the wire -salausta?
Vastata: Emme voi ottaa käyttöön DARE (Data at Rest Encryption -salausta) tai langallista salausta (replikoinnin tai ddboostin avulla) EDP-järjestelmässä.

Järjestelmän tunnuslause 

Kysymys: Mikä on järjestelmän salasana?
Vastata: DDOS suojaa järjestelmän tunnistetiedot järjestelmätason tunnuslauseella. Salasana on ihmisen luettavissa oleva (ymmärrettävä) avain, kuin älykortti, jonka avulla luodaan konekäyttöinen AES 256 -salausavain. 

Se tarjoaa kaksi etua:

• Sen avulla järjestelmänvalvoja voi muuttaa salasanaa salausavaimia käsittelemättä. Epäsuora salasanan muuttaminen muuttaa avainten salausta, mutta ei vaikuta käyttäjätietoihin. Tunnuslauseen muuttaminen ei muuta pohjana olevaa Data Domain -järjestelmän salausavainta. Se muuttaa Data Domain -järjestelmäavaimen salausta, mutta järjestelmäavain pysyy samana.
• Sen avulla fyysisen Data Domain -järjestelmän mukana voidaan toimittaa salausavain järjestelmään ilman, että salasanaa tallennetaan järjestelmään. Tällä tavalla, jos laatikko varastetaan kuljetuksen aikana, hyökkääjä ei voi helposti palauttaa tietoja, koska järjestelmässä on vain salatut avaimet ja salatut tiedot.

Salasana tallennetaan sisäisesti Data Domain -tallennusjärjestelmän piilotettuun osaan. Näin Data Domain -järjestelmä voi käynnistyä ja jatkaa tietojen ylläpitoa ilman järjestelmänvalvojan toimia.

Tunnuslauseen luominen tai muuttaminen:

• Järjestelmän salasana voidaan luoda komentoriviliittymässä, kun järjestelmänvalvoja on suorittanut todennuksen Data Domain -järjestelmässä.
• Järjestelmän salasanaa voidaan muuttaa komentoriviliittymässä, kun järjestelmänvalvoja ja käyttöoikeusroolin käyttäjä (kuten suojausvastaava) ovat todentaneet Data Domain -järjestelmässä (jolloin yksikään järjestelmänvalvoja ei voi tehdä muutoksia itsenäisesti).

Kysymys: Milloin salasanaa käytetään?
Vastata: Järjestelmän salasanaa käytetään ensisijaisena avaimena useissa DDOS-komponenteissa, joita ovat esimerkiksi tiedostojärjestelmän salaus, pilvipalvelun käyttö, varmenteiden hallinta, Boost-tunnukset, järjestelmän kokoonpanomoduulit skaalautuvissa ympäristöissä ja lisenssitiedot. DDOS-ohjelmisto tarjoaa mekanismeja tämän järjestelmän salasanan asettamiseen ja muokkaamiseen. Sillä voi myös hallita, tallennetaanko järjestelmän salasana levylle, jota käytetään erityisesti parantamaan suojausta DD-järjestelmää siirrettäessä. 

Kysymys: Miten salasanaa käytetään DD-järjestelmän turvalliseen kuljetukseen?
Vastata: Prosessi käyttää filesys encryption lock -komentoa, jolla käyttäjä voi lukita tiedostojärjestelmän vaihtamalla salasanan. Käyttäjä antaa uuden tunnuslauseen, joka salaa salausavaimen uudelleen, mutta uutta tunnuslausetta ei tallenneta. Salausavaimia ei voi palauttaa, ennen kuin tiedostojärjestelmän lukitus avataan komennolla filesys encryption unlock.

Prosessi on kuvattu Confluence Lab Security Configuration Guide -oppaassa.

Kysymys: Mitä tapahtuu, jos salasana muuttuu? Voiko tietoja silti käyttää?
Vastata: Kyllä, salasanan muuttaminen ei muuta pohjana olevaa Data Domain -järjestelmän salausavainta, vaan ainoastaan salausavaimen salausavainta. Siksi tämä ei vaikuta tietojen käyttöön.

Kysymys: Miten voimme kysyä, onko järjestelmässä
määritetty salasana?Vastata: Jos järjestelmässä on luotu salasana, system passphrase set -komennon suorittaminen tuo esiin virheen, joka osoittaa, että salasana on jo määritetty.

Kysymys: Mitä tapahtuu, jos salasana katoaa tai unohtuu?
Vastata: Jos asiakas kadottaa salasanan, kun laatikko on lukittu, hän menettää tietonsa. Ei ole olemassa takaovea tai vaihtoehtoista tapaa päästä siihen käsiksi. Ilman hyvää prosessia kyseisen tunnuslauseen hallintaan tämä voi tapahtua vahingossa, eivätkä he pysty palauttamaan avainta tai tietoja. Salattu avain ei kuitenkaan voi koskaan kadota tai vioittua järjestelmän integroitujen suojausmekanismien vuoksi.

Kysymys: Onko olemassa mekanismia unohtuneen järjestelmän salasanan nollaamiseksi?
Vastata: Järjestelmän salasana voidaan nollata voimalla vain tietyissä tilanteissa asiakastuen avulla. DDOS 7.2:ssa käyttöön otettua force-update-mekanismia voidaan käyttää tähän vain, jos tietyt ehdot täyttyvät. Lisätietoja on tietämyskannan artikkelissa 20983, Data Domain: Kadonneen järjestelmän salasanan palauttaminen DDOS 7.2:ssa tai uudemmassa (artikkeli edellyttää kirjautumista Dell-tukeen)

Kysymys: Voiko järjestelmän salasanaa olla tallentamatta DD-järjestelmään?
Vastata: Järjestelmän salasana tallennetaan oletusarvoisesti piilotettuun sijaintiin Data Domain -järjestelmässä. Järjestelmän asetuksella system passphrase option store-on-disk voidaan muuttaa tämä asetus ja välttää tunnuslauseen tallentaminen levylle.

Upotettu avainten hallinta (EKM)

Ylätason komento:

System# Filesys Encryption Embedded-Key-Manager <-vaihtoehto>

Kysymys: Tukeeko Embedded Key Manager näppäinten kiertoa?
Vastata:  Kyllä, Embedded Key Manager tukee näppäinten kiertoa Data Domain -järjestelmää kohti. Käyttöliittymän tai komentoriviliittymän kautta järjestelmänvalvoja voi määrittää avainten kiertojakson (viikoittain tai kuukausittain).

Kysymys: Onko upotetun avaimen hallintatoiminto maksullinen?
Vastata: Tämä toiminto on maksuton. Tämä toiminto sisältyy DD Encryption -ohjelmiston vakiokäyttöoikeusvaihtoehtoon.

Kysymys: Voiko asiakas siirtyä paikallisesta avainhallinnasta ulkoisten avainten hallintaan (EKM)?
Vastata

• Kyllä, ulkoisten avainten hallintaohjelmat voidaan ottaa käyttöön milloin tahansa. Käytettävät paikalliset avaimet säilyvät kuitenkin Data Domain -järjestelmässä. Ulkoiset avainpäälliköt eivät pysty hallitsemaan EKM-avaimia. Olemassa olevia tietoja ei tarvitse salata uudelleen. Jos asiakkaan vaatimustenmukaisuustiedot on salattava uudelleen EKM-avaimilla, se on tehtävä manuaalisesti käyttämällä Apply Changes -toimintoa uudella RW-avaimella. EKM-avainten tuhoaminen vaihdon jälkeen ei ole pakollista.
  • Avaintenhallinnan kytkin vaihtaa aktiivisen avaimen automaattisesti KMIP:n avaimeen. 
  • Esimerkki siitä, miltä KMIP-avaimen MUID näyttää vaihdon yhteydessä

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

Kysymys: Mitä tapahtuu, jos näppäinten kierto on poistettu käytöstä tai otettu käyttöön?
Vastata: 

• Näppäinten kierto poistettu käytöstä on oletusarvoinen salaustoiminto, jos et ota käyttöön näppäinten kiertoa käyttöliittymässä tai komentoriviliittymässä. Tässä tilanteessa kaikki tiedot salataan olemassa olevalla aktiivisella avaimella.
• Jos näppäinten kierto on käytössä, kierrämme näppäimiä pyöritystaajuuden perusteella ja tiedot salataan uusimmalla aktiivisella avaimella.

Ulkoiset avainpäälliköt

Kysymys: Mitä ulkoisia avainten hallinnoijia DD tukee?
Vastata: Tuemme seuraavia ulkoisia avainhenkilöitä:

• Gemalto KeySecure (tuki lisätty DDOS-versioon 7.2)
• Vormetric (tuki lisätty DDOS-versioon 7.3)
• CipherTrust (tuki lisätty DDOS-versioon 7.7)
• IBM GKLM (tuki lisätty DDOS-versioon 7.9)

Kysymys: Tarvitaanko erillinen lisenssi, jotta integrointi ulkoisen avainten hallinnan kanssa on mahdollista?
Vastata: Kyllä, ulkoisen avainhallinnan integrointiin DD:hen tarvitaan erillinen lisenssi kyseiseltä valmistajalta.

Kysymys: Kuinka monta avainhenkilöä tukee kerrallaan?
Vastata: Vain yksi avaintenhallinta voi olla aktiivisena kerrallaan DD-järjestelmässä.

Kysymys: Mistä saan lisätietoja KMIP External Key Managerin määrittämisestä?
Vastata: DDOS:n KMIP-integrointioppaassa on yksityiskohtaisia tietoja DD:n tukemien ulkoisten avainten hallintaohjelmien määrittämisestä.

Kysymys: Miten ulkoisten avainten valvojien varmenteita hallitaan DD:ssä?
Vastata: Ulkoisen avaimen hallintaa määritettäessä on luotava CA-varmenne (CA-varmenne voi olla itse allekirjoitettu tai kolmannen osapuolen allekirjoittama) ja isäntävarmenne. Kun määritys on tehty ulkoisten avainten hallintapalvelimessa, käyttäjien on tuotava CA-varmenne ja isäntävarmenne DD-järjestelmään. Sen jälkeen määritämme ja otamme käyttöön ulkoisen avainten hallinnan. 

Kysymys: Mikä on CA?
Vastata: Varmenteiden myöntäjä (CA) toimii alun perin luotettuna jaettuna yksikkönä vertaisryhmien välillä ja myöntää allekirjoitettuja varmenteita, jotta kumpikin osapuoli voi luottaa toiseen. Varmenne toimii yleensä palvelimen tai asiakkaan identiteettinä. 

Kysymys: Mikä on paikallinen varmenteiden myöntäjän allekirjoittama varmenne ja mikä varmenteiden myöntäjän allekirjoittama varmenne?
Vastata: CA:n allekirjoittama varmenne on varmenne, jonka on myöntänyt ja allekirjoittanut julkisesti luotettu varmenteiden myöntäjä (CA). CA:n allekirjoittamaan varmenteeseen luotetaan automaattisesti. Paikallinen varmenteiden myöntäjä voi myöntää allekirjoitettuja varmenteita, koska yksityinen allekirjoitusavain on tallennettu Key Manager -järjestelmään. Ulkoinen varmenteiden myöntäjä ei tallenna yksityistä avainta. Sen sijaan ulkoista varmentajaa käytetään luotettuna kokonaisuutena erilaisille rajapinnoille ja palveluille järjestelmän sisällä.

Kysymys: Kuinka luoda varmenteen allekirjoituspyyntö DD: ssä?
Vastata: Luo Data Domain -järjestelmässä CSR käyttämällä alla olevaa komentoriviliittymän komentoa. Tällä tavoin yksityinen avain ei koskaan paljastu ulkoiselle avainten hallinnalle.

AdminAccess-varmenne Cert-Signing-Request

Kysymys: Voiko avainpäälliköiden välillä vaihtaa?
Vastata: Vaihtaminen ulkoisesta avainhallinnasta Embedded Key Manageriin on sallittua ja saumatonta. Siirtyminen Embedded Key Managerista External Key Manageriin edellyttää kuitenkin varmenteen asianmukaista asennusta ja määritystä. Vaihtaminen kahden ulkoisten avainten hallintaohjelman välillä (esimerkiksi: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust to GKLM) ovat myös sallittuja. Myös Key Manager -avainten siirtoa tuetaan (katso lisätietoja KMIP-integrointioppaasta).

Kysymys: Mitä tapahtuu, kun yhteys ulkoiseen avainhallintaan katkeaa? Ovatko tietoni silloin käytettävissä?
Vastata: Kyllä, tiedot ovat edelleen käytettävissä, vaikka emme voi muodostaa yhteyttä avainten hallintaan, koska tallennamme avainten kopion myös DD-järjestelmään. Uusia avaimia ei voi luoda tai avaintiloja ei voi synkronoida, kun yhteyttä ulkoiseen avainten hallintaan ei ole.

Kysymys: Onko olemassa tapa, jolla voimme välttää avainten tallentamisen DD: hen ja tallentaa vain ulkoiseen avainhallintaan?
Vastata: Tallennamme aina kopion avaimista DD-järjestelmään DIA-tarkoituksiin. Tätä asetusta ei voi muuttaa.

Kysymys: Onko KMIP-integroinnilla vaikutusta suorituskykyyn?
Vastata: Ei, ulkoisten avainten hallinnan käyttäminen ei vaikuta suorituskykyyn.

Kysymys: Voiko KMIP-ratkaisua hyödyntää tietyissä ympäristön Data Domains -toimialueissa?
Vastata: Kyllä, asiakkaat voivat valita täysin joustavasti sopivan salausmenetelmän Data Domain -järjestelmilleen. Ne voivat jatkaa Data Domainin sulautetun avainten hallinnan hyödyntämistä joissakin Data Domain -järjestelmissä ja salausavaimen kiertoa KMIP:n avulla muissa ympäristönsä Data Domain -järjestelmissä.

Kysymys: Onko Data Domain–KMIP -tietoliikenne turvallista?
Vastata: Kyllä, Data Domain viestii X509-varmenteen kautta molemminpuolisesti todennettujen istuntojen kautta TLS:n kanssa. Käyttäjä voi tuoda asianmukaisen X509-varmenteen Data Domain -järjestelmään Data Domain -komentoriviliittymässä. Tämän varmenteen avulla muodostetaan suojattu kanava DD:n ja KMIP:n välille.

Keskeinen elinkaaren hallinta 

Kysymys: Mitä avainten hallintaominaisuuksia DD Encryption -asetus tarjoaa?
Vastata: Avainten hallinta ohjaa useiden salausavainten luontia, jakelua ja elinkaaren hallintaa. Suojausjärjestelmä voi käyttää joko upotettua avainhallintaa tai KMIP-valituksen ulkoista avainhallintaa. Vain yksi avainpäällikkö voi olla voimassa kerrallaan. Kun salaus on käytössä suojausjärjestelmässä, Embedded Key Manager on oletusarvoisesti käytössä. Jos ulkoinen avainten hallinta on määritetty, se korvaa upotetun avainten hallinnan ja pysyy voimassa, kunnes se poistetaan käytöstä manuaalisesti. Vaihtaminen Embedded Key Managerista External Key Manageriin tai päinvastoin johtaa uuden avaimen lisäämiseen järjestelmään, eikä tiedostojärjestelmää tarvitse käynnistää uudelleen versiosta 7.1 alkaen.

Kysymys: Mitkä ovat Data Domain -järjestelmän eri avaintilat?
Data Domain -järjestelmän eri avaintilat ovat seuraavat:

• Aktivoitu RW: Tässä tilassa on vain yksi avain missä tahansa DD-järjestelmässä, ja sitä käytetään tietojen lukemiseen ja kirjoittamiseen. Myös GC-prosessi käyttää tätä avainta säilöjen uudelleensalaamiseen.
• Odottaa-aktivoitu: DD-järjestelmässä on tässä tilassa vain yksi avain. Tämä tunnistaa avaimen, joka aktivoituu seuraavan tiedostojärjestelmän uudelleenkäynnistyksen jälkeen. Tässä tilassa on nykyisin salaus vain silloin, kun salaus otetaan käyttöön. Mitään muuta odottavaa aktivoitua avainta ei luoda.  
• Aktivoitu-RO: Ulkoisilla avainten hallintaohjelmilla voi olla useita aktivoituja avaimia. Viimeisin avain on Activated-RW:ssä, loput ovat tässä tilassa. Avaimet voivat siirtyä tähän tilaan DD-järjestelmässä, kun tilaa ei voida synkronoida avainten hallinnan kanssa.
• Poistettu käytöstä: Sitä käytetään olemassa olevien tietojen lukemiseen DD-järjestelmästä.
• Vaarantunut: Kun asiakas vaarantaa ulkoisen avainten hallinta-avaimen, tila muuttuu siihen seuraavan avaimen synkronoinnin jälkeen.  
• Hävitetyksi merkitty: Kun asiakas merkitsee avaimen tuhottavaksi, avaimen tila muuttuu hävitetyksi. Kun GC suoritetaan, kaikki säilöt, jotka on salattu tuhottujen merkittyjen avainten avulla, salataan uudelleen Activated-RW-avaimella.
• Tuhottu: Hävitetyiksi merkityssä tilassa oleva avain siirtyy tähän tilaan, kun siihen ei liity tietoja.
• Tuhoutunut-vaarantunut: Vaarantunut-tilassa oleva avain siirtyy tähän tilaan, kun siihen ei liity tietoja.

Kysymys: Voiko salausavaimia viedä katastrofista palautumista varten?
Vastata: Avaimet voidaan viedä manuaalisesti alla olevalla komennolla.

Filesys Encryption keys Export

DD-järjestelmä vie avaimet oletusarvoisesti myös silloin, kun uusi avain lisätään tai kun jokin avain poistetaan järjestelmästä.

Viedyt tiedostot ovat hakemistossa /ddr/var/.security, ja se on salatussa muodossa. Tämä tiedosto on kopioitava DDR:stä ja tallennettava turvalliseen paikkaan, jota voidaan käyttää missä tahansa katastrofista palautumisessa myöhemmin.

Huomautus: Avainten tuominen katastrofista palautumista varten edellyttää asiakastuen toimia, sillä palautusprosessi määräytyy katastrofin tyypin mukaan. Viedyn avaintiedoston voi tuoda seuraavalla komennolla.

Filesys salausavaimet tuo <tiedostonimi> 

Kysymys: Onko KMIP:n luoma avain tallennettu Data Domain -järjestelmään?
Vastata: Kyllä, KMIP:stä saatu salausavain tallennetaan Data Domain -järjestelmään salattuna.

Kysymys: Miten KMIP-laitteen avaintilan muutos otetaan käyttöön Data Domain -järjestelmässä?
Vastata: Avainten synkronointi tapahtuu päivittäin. Jos käytettävissä on uusi avain tai avaimen tila muuttuu, synkronointi päivittää paikallisen avaimen taulukon. DD saa tärkeimmät päivitykset KMIP:ltä joka päivä keskiyöllä.

Kysymys: Voiko DD:n ja KMIP:n väliset avaintilat synkronoida manuaalisesti?
Vastata: Kyllä, DD:n ja KMIP:n väliset avaintilat voidaan synkronoida manuaalisesti Data Domain -komentoriviliittymässä tai -käyttöliittymässä. Filesys Encryption keys Sync on komennossa.

Kysymys: Voiko aikaa, jolloin DD vastaanottaa tärkeimmät päivitykset KMIP:ltä, muuttaa?
Vastata: Ei ole mahdollista muuttaa aikaa, jolloin DD vastaanottaa tärkeimmät päivitykset KMIP:stä.

Kysymys: Onko Data Domain -järjestelmän tukemien avainten määrää rajoitettu?
Vastata: DDOS 7.8 -versiosta alkaen Data Domain -järjestelmässä voi milloin tahansa olla enintään 1024 avainta. Activated-RW:ssä on vain yksi avain, ja muut avaimet voivat olla missä tahansa muussa tilassa.

Kysymys: Voiko Data Domain -järjestelmien eri tietojoukoissa käyttää eri avaimia? Onko tämä määritettävissä?
Vastata: Ei, tuemme vain yhtä aktiivista avainta järjestelmässä kerrallaan ja kaikki saapuvat tiedot salataan aktiivisella avaimella. Avaimia ei voi ohjata hienommalla rakeisuudella kuten M-puita.

Kysymys: Onko tiedossa ilmoitusta, kun avainten enimmäisraja saavutetaan?
Vastata: Kyllä, hälytys annetaan, kun avainten enimmäismäärä 1024 saavutetaan.

Kysymys: Miten voin poistaa hälytyksen avainten enimmäisrajasta?
Vastata: Yksi avaimista on poistettava, jotta näppäinten enimmäisrajahälytys voidaan poistaa.

Kysymys: Näemmekö Data Domain -järjestelmän tiettyyn avaimeen liittyvien tietojen määrän?
Vastata: Kyllä, tämä näkyy DD:ssä, mutta ei KMIP-palvelimessa. Käyttäjä voi tarkastella tiettyyn avaimeen liittyvien tietojen määrää Data Domain -komentoriviliittymässä ja käyttöliittymässä.

Kysymys:  Näemmekö DD-järjestelmän avainten iän?
Vastata: Kyllä, se näkyy EKM-näppäimillä käyttöliittymän avulla.

Kysymys: Toimiiko vanha avain, vaikka uuden avaimen voimaantuloaika olisi kulunut?
Vastata: Salausavaimilla ei ole vanhentumispäivää. Vanhoista näppäimistä tulee vain luku -näppäimiä, kun niitä kierretään, ja ne pysyvät DDOS:ssa.

Kysymys: Poistetaanko salausavain automaattisesti, kun siihen ei liity tietoja Data Domain -järjestelmässä?
Vastata: Ei, avainta ei poisteta automaattisesti. Käyttäjän on nimenomaisesti poistettava avain DD:ssä, komentoriviliittymässä tai käyttöliittymässä.

Kysymys: Voiko avaimen poistaa, vaikka siihen liittyy tietoja Data Domain -järjestelmässä?
Vastata: Ei, jos avaimeen liittyy tietoja, sitä ei voi poistaa. Tietojen uudelleensalaus on tarpeen jollakin muulla avaimella, jotta voidaan poistaa avain, johon liittyy tietoja.

Kysymys: Jos avain poistetaan KMIP:stä, poistetaanko avain myös Data Domainin avainluettelosta?
Vastata: Ei, vaan käyttäjän on poistettava avain itsenäisesti DD-komentoriviliittymän tai käyttöliittymän avulla.

Kysymys: Tarvitaanko usean toimipaikan Data Domain -ympäristössä KMIP joka sijainnissa?
Vastata: Ei, KMIP:tä ei tarvitse olla jokaisessa Data Domainia käyttävässä toimipaikassa. Voimme osoittaa yhteen KMIP-palvelimeen. On suositeltavaa, että jokaisella DD-järjestelmällä on oma avainluokkansa, kun ne käyttävät samaa KMIP-palvelinta.

Kysymys: Jos avain vaarantuu, onko meillä prosessi vanhalla avaimella salattujen tietojen hakemiseksi?
Vastata: Tässä tapauksessa asiakkaan on merkittävä avain vaarantuneeksi KMIP-palvelimessa. Tee sitten "filesys encryption keys sync" DDOS-järjestelmässä, suorita sitten "filesys encryption apply-changes" ja suorita sitten GC (filesys clean). GC-suoritus salaa kaikki vaarantuneella avaimella salatut tiedot uudemmalla avaimella. Kun GC on valmis, avaimen tilaksi muuttuu vaarantunut-tuhoutunut. Myöhemmin he voivat poistaa kyseisen avaimen. 

Salaus ja replikointi

Kysymys: Tuetaanko DD Replicationia ja onko se yhteentoimiva DD Encryption -ohjelmistovaihtoehdon kanssa?
Vastata: Kyllä, DD-replikointia voidaan käyttää DD-salauksen kanssa, jolloin salatut tiedot voidaan replikoida käyttämällä erilaisia replikointimenetelmiä. Jokainen replikointilomake toimii yksilöllisesti salauksen kanssa ja tarjoaa saman turvallisuustason.

Kysymys: Onko sekä lähde- että kohdejärjestelmässä oltava sama DD-käyttöjärjestelmän versio, jotta salausta voidaan käyttää?
Vastata: Lähde ja kohde voivat olla eri DDOS-versiossa, jotta DARE voidaan käyttää replikoinnin kanssa, jos replikoinnin yhteensopivuusmatriisi (katso yhteensopivuusmatriisin järjestelmänvalvojan oppaasta) on käytössä. 

Kysymys: Miten replikointi toimii salauksen kanssa?
Vastata: Se riippuu siitä, mitä replikointimuotoa käytetään.

Jos määritetty replikointi on MREPL tai MFR:
Jos käytetään MREPL:ää tai MFR:ää, DD Encryption voidaan lisensoida tai ottaa käyttöön joko lähteessä tai kohteessa itsenäisesti riippuen siitä, mitä asiakas haluaa saavuttaa.

• Kun salaus on käytössä sekä lähteessä että kohteessa: Kun tietoja syötetään lähdejärjestelmään, ne salataan lähdejärjestelmän salausavaimella. Lähde purkaa paikallisten tietojen salauksen, salaa ne uudelleen kohdejärjestelmän salausavaimella ja replikoi sitten salatut tiedot kohteeseen replikoinnin yhteydessä.
• Kun lähteen salaus on poistettu käytöstä ja kohteen salaus on käytössä: Kaikkia lähteeseen syötettyjä tietoja ei salata (ilmeisestä syystä). Replikoitaessa lähde kuitenkin salaa tiedot kohdejärjestelmän salausavaimella ja replikoi sitten salatut tiedot kohdejärjestelmään. 
• Kun lähteen salaus on käytössä ja kohteen salaus on poistettu käytöstä: Kaikki lähdejärjestelmään syötetyt tiedot salataan lähdejärjestelmän salausavaimella. Lähde purkaa tietojen salauksen ja replikoi sitten salaamattomat tiedot Data Domain -kohdejärjestelmään replikoinnin yhteydessä.
• Jos salaus on käytössä replikassa replikointikontekstin määrittämisen jälkeen, kaikki uudet replikoitavat segmentit salataan replikan lähteessä. Kaikki segmentit, jotka sijaitsivat replikassa ennen salauksen käyttöönottoa, jätetään salaamattomaan tilaan, ellei salausta oteta käyttöön ja GC suorita kohdetta. 

Jos määritetty replikointi on CREPL:
Kokoelmareplikointia käytettäessä sekä lähde- että kohdejärjestelmässä on oltava käytössä sama DDOS-versio. Siksi salaus on otettava käyttöön tai poistettava käytöstä molemmissa. Ristiriitaa ei voi esiintyä myöskään salausmäärityksissä. Salausavaimet ovat samat lähteen ja kohteen mukaan. 

• Kun salaus on käytössä sekä lähteessä että kohteessa: Kaikki lähdejärjestelmään syötetyt tiedot salataan lähdejärjestelmän salausavaimella. Replikoinnin aikana lähde lähettää salattuja tietoja Data Domain -kohdejärjestelmään sen salatussa tilassa. Data Domain -kohdejärjestelmässä on sama avain kuin lähteessä, koska kokoelman replikointi tarkoittaa lähde-Data Domain -järjestelmän tarkkaa kopiota. Data Domain -kohdejärjestelmään ei voi kirjoittaa tietoja replikoinnin ulkopuolella, sillä kohde on vain luku -järjestelmä.
• Kun salaus on poistettu käytöstä sekä lähteessä että kohteessa: Kaikkia lähdejärjestelmään syötettyjä tietoja ei salata (ilmeisestä syystä). Replikoinnin aikana lähde lähettää (replikoi) tiedot salaamattomassa tilassa, ja ne pysyvät salaamattomina Data Domain -kohdejärjestelmässä. Data Domain -kohdejärjestelmään ei voi kirjoittaa tietoja replikoinnin ulkopuolella, sillä kohde on vain luku -järjestelmä.

Kysymys: Tallennetaanko kohteen avain Data Domain -lähdejärjestelmään määräämättömäksi ajaksi?
Vastata: Kohteen salausavainta ei koskaan tallenneta Data Domain -lähdejärjestelmään. Sitä säilytetään ainoastaan salatussa muistissa replikointi-istunnon ollessa aktiivinen. Tämä koskee kaikenlaista replikointia kokoelmareplikointia lukuun ottamatta. Kokoelman replikaatiossa (CREPL) samat salausavaimet ovat läsnä lähteessä ja kohteessa.  

Kysymys: Voiko salaus ottaa käyttöön CREPL-järjestelmässä, kun replikointikonteksti on luotu?
Vastata: Kyllä, tässä tapauksessa salaus on otettava käyttöön sekä lähteessä että kohteessa. Salaus voidaan ottaa käyttöön lähteessä ja kohteessa poistamalla replikointikonteksti käytöstä. Kaikki replikoidut uudet segmentit salataan replikassa. Kaikki segmentit, jotka olivat replikassa ennen salauksen käyttöönottoa, jätetään salaamattomaan tilaan.

Kysymys: Voiko DD-salauksen ottaa käyttöön samanaikaisesti DD Replication -ohjelmiston Over-the-Wire-salausominaisuuden kanssa?
Vastata: Kyllä, sekä langallinen salaus että D@RE voidaan ottaa käyttöön samanaikaisesti erilaisten tietoturvatavoitteiden saavuttamiseksi.

Kysymys: Mitä tapahtuu, jos sekä DD Encryption -ohjelmiston asetus että DD Replication -ohjelmiston over-the-wire-salausominaisuus otetaan käyttöön samanaikaisesti?
Vastata: Ensimmäinen lähde salaa tiedot kohteen salausavaimella. Sitten jo salatut tiedot salataan toisen kerran langan yli salauksen vuoksi, kun nämä tiedot lähetetään määränpäähänsä. Määränpäässä langan salauksen purkamisen jälkeen tiedot tallennetaan salatussa muodossa, joka salattiin kohteen salausavaimella.

Kysymys: Kun salaus on käytössä lähteessä ja kohteessa, onko salasanan oltava sama molemmissa?
Vastata: Jos määritetty replikointi on kokoelmareplikointi (CREPL), salasanan on oltava sama. Muunlaisten replikointien (kuten MREPL, MFR) tunnuslause voi olla erilainen lähteeltään ja kohteeltaan.

Kysymys: Kun salaus on käytössä kohteessa (kysymys ei koske CREPL:ää), salataanko sekä replikoidut tiedot että jostakin muusta tukiasemasta (esimerkiksi paikallisen varmuuskopioinnin kautta) saadut tiedot? Onko olemassa tapa erottaa nämä kaksi kopiossa, jossa vain replikoidut hakemistot salataan, kun taas muuta käyttöä ei salata?
Vastata: Ei, kaikki tiedot salataan replikassa (määränpäässä) aloituskohdasta riippumatta. Salausta ei voi ottaa käyttöön tai poistaa käytöstä ainoastaan MTree- tai hakemistotasolla. 

Kysymys: Miten avaimenvaihto tapahtuu lähteen ja määränpään välillä MREPL: n tai MFR: n aikana?
Vastata: Replikoinnin yhdistämisvaiheen aikana kohdekone lähettää turvallisesti nykyisen salausalgoritminsa ja keskeiset tiedot lähteelle. Replikointikontekstit todennetaan aina jaetun salaisuuden avulla. Tätä jaettua salaisuutta käytetään "istuntoavaimen" luomiseen käyttämällä Diffie-Hellman-avaimenvaihtoprotokollaa. Tätä istuntoavainta käytetään Data Domain -järjestelmän salausavaimen salaukseen ja salauksen purkamiseen.

Kysymys: Minkä tyyppistä salausalgoritmia käytetään Data Domainin "encryption over the wire" -ominaisuudessa, joka koskee replikointiliikenteen salaamista?
Vastata: Kun replikoinnin todennustilaksi on määritetty yksisuuntainen tai kaksisuuntainen, istuntoavainten vaihtoon käytetään DHE (Ephemeral Diffie-Hellman). Palvelimen todennus tapahtuu RSA: n avulla. AES 256-bittistä GCM-salausta käytetään kapseloimaan replikoidut tiedot langan yli. Salauksen kapselointikerros poistetaan välittömästi, kun se laskeutuu kohdejärjestelmään. 

Yksi tapa osoittaa, että vain kohdevarmenne on sertifioitu. Kaksi tapaa osoittaa, että sekä lähde- että kohdevarmenteet tarkistetaan. Molemminpuolinen luottamus on muodostettava, ennen kuin voit käyttää todennustilaa, ja yhteyden molempien osapuolten on otettava tämä ominaisuus käyttöön, jotta salaus voi jatkua.

Kun replikoinnin todennustilaksi on määritetty anonyymi, istuntoavainten vaihtoon käytetään anonyymiä Diffie-Hellmania (ADH), mutta tässä tapauksessa lähde ja kohde eivät todenna toisiaan ennen avaimenvaihtoa. Jos todennustilaa ei ole määritetty, oletuksena käytetään anonyymiä.

Kysymys: Toimiiko näppäinten kierto ilman tiedostojärjestelmän uudelleenkäynnistystä kaikenlaisten replikointien kanssa?
Vastata: Näppäinten kierto ilman tiedostojärjestelmän uudelleenkäynnistystä toimii kaikenlaisten replikointien kanssa paitsi DREPL (DREPL-tuki on jo päättynyt) ja deltareplikointi (tunnetaan myös nimellä LBO)

Kysymys: Jos varmenteita tai PKI-avainpareja ei ole, miten kohteen salausavain suojataan avaimenvaihdon aikana?
Vastata: Kaikilla Data Domain -replikointipareilla on yhteinen salaisuus, jota käytetään jaetun istuntoavaimen muodostamiseen Diffie-Hellman-avainvaihdon avulla. Tätä jaettua avainta käytetään kohteen salausavaimen salaamiseen.

Replikointitodennukseen käytetyn jaetun salaisuuden ja jaetun istuntoavaimen välillä on ero, sillä se on varattu Diffie-Hellman-avaimenvaihtoprotokollan avulla. Data Domain -ohjelmisto määrittää replikoinnin todennukseen käytettävän jaetun salaisuuden, kun kaksi Data Domain -järjestelmää haluaa ensimmäisen kerran muodostaa replikointikontekstin. Siitä sovitaan myös Diffie-Hellmanin kautta, joka vaihdetaan koodiin upotettujen parametrien avulla. Tämä tallennetaan järjestelmään jatkuvasti, jotta jokainen replikointi-istunto voidaan todentaa kahden järjestelmän välillä. Replikointi-istunnon avain (avain, jota käytetään kohteen salausavaimen salaamiseen) muodostetaan käyttämällä toista Diffie-Hellman-vaihtoa aiemmin määritetyn jaetun salaisuuden kanssa, mikä ohjaa suojattua avainten vaihtoprotokollaa. Tämä avain ei ole pysyvä, ja se on olemassa vain, kun replikointikonteksti on aktiivinen.

Kysymys: Onko replikointiparin molempien Data Domainien käytettävä samaa ulkoisen avaimenhallinnan (kuten KMIP key manager) ratkaisua vai voiko toinen järjestelmistä käyttää ulkoista avainten hallintaa ja toinen sulautettua avainten hallintaa?
Vastata: Kokoelman replikointiparia lukuun ottamatta replikointiparin molempien järjestelmien ei tarvitse käyttää samaa avainten hallintaa.

Kokoelman replikoinnin avulla molemmissa Data Domain -järjestelmissä on oltava sama avainten hallinta. Mutta tässäkin tapauksessa ainoa lähde on avainten synkronointi avainten hallinnan kanssa, ja nämä avaimet lähetetään myös kohteeseen. Muissa replikointityypeissä voidaan käyttää eri avainten hallintaohjelmia lähteen ja kohteen kanssa.

Salaus ja siirto

Kysymys: Tuetaanko tietojen siirtoa järjestelmissä, joissa salaus on käytössä?
Vastata: Kyllä, tietojen siirtoa tuetaan järjestelmissä, joissa salaus on käytössä. Lähde- ja kohdejärjestelmien salauksen määritysten on oltava identtiset, ennen kuin tietojen siirto voidaan aloittaa. Lisäksi suosittelemme viemään ja varmuuskopioimaan lähdejärjestelmän salausavaimet DIA-tarkoituksia varten ennen siirron aloittamista.

Kysymys: Tukeeko tietojen siirto sekä Active Tier- että Cloud Tier -siirtoa salausta käyttävissä järjestelmissä?
Vastata: Kyllä, tietojen siirtoa tuetaan sekä Active Tier- että Cloud Tier -siirrossa salausta tukevissa järjestelmissä. Tarkistettujen edellytysten määritteiden luetteloa käytetään sen mukaan, millä tasolla salaus on käytössä.

Kysymys: Mitkä salausasetukset säilytetään siirron yhteydessä?
Vastata: Salatut tiedot ja salausavaimet siirretään sellaisenaan, mutta tietojen siirto edellyttää, että esimerkiksi salausavainten hallinta, järjestelmän salasana ja muut salausmääritykset tarkistetaan ja täsmäytetään manuaalisesti. Myös olemassa olevat avaintenhallintavarmenteet siirretään kohdejärjestelmään. Salausavainten hallinnan määritys on määritettävä uudelleen kohdejärjestelmässä siirron jälkeen.

Kysymys: Mitä salauksen yhteensopivuustarkistuksia lähteen ja kohteen välillä tehdään siirron aikana?
Vastata: Järjestelmän tunnuslause, salauksen tila ja avainhallinnan konfiguraatiotiedot, järjestelmän FIPS-tilan asetukset ovat joitakin salausasetuksia, joiden on oltava samat lähde- ja kohdejärjestelmissä, jotta siirto onnistuu. Tämä tietämyskannan artikkeli 183040, Data Domain: Pilvipalveluja käyttävien DD-järjestelmien siirtomenettely (artikkeli edellyttää kirjautumista Dellin tukeen) sisältää yksityiskohtaiset ohjeet siirtymiseen sellaisten järjestelmien välillä, joissa on käytössä pilvi. Samat asetukset koskevat myös vain aktiivisen tason siirtoa.

Kysymys: Tuetaanko siirtoa järjestelmien välillä, kun Encryption Disablement Project -asetus on käytössä?
Vastata: Tietojen siirtoa tuetaan kahden järjestelmän välillä, jos molemmat ovat EDP-järjestelmiä tai molemmat eivät ole EDP-järjestelmiä. Tietojen siirto EDP-järjestelmästä muuhun kuin EDP-järjestelmään on sallittua, jos verkkosalaus on nimenomaisesti poistettu käytöstä. (käyttämällä MIGRATION_ENCRYPTION sysparamia)

Salaus pilvitasolla 

Kysymys: Tuetaanko salausta pilvitasolla?
Vastata: Kyllä, salausta tuetaan pilvitasolla. Salaus on oletusarvoisesti pois käytöstä pilvitasolla. Cloud Enable -komentokehotteet pyytävät valitsemaan, otetaanko salaus käyttöön pilvitasolla.

Kysymys: Tuetaanko KMIP:tä ja ulkoisten avainten hallintaa pilvitasolla?
Vastata: Kyllä, KMIP:tä ja ulkoisten avainten hallintaa tuetaan pilvitasolla DDOS 7.8 -versiosta alkaen.

Kysymys: Millä tarkkuudella salaus voidaan ottaa käyttöön pilvessä?
Vastata: Salaus voidaan ottaa käyttöön ja poistaa käytöstä kussakin pilviyksikössä ja tasolla erikseen.

Kysymys: Onko pilviyksiköillä itsenäisiä avaimia?
Vastata: Ei, avainten hallinta on yhteistä DD:n sekä aktiiviselle että pilvitasolle. Avaimet kopioidaan vastaavaan yksikköön/tasoon/cp:hen, kun salaus on käytössä. Jos salaus on käytössä aktiivisessa eikä pilvessä, aktiivisen tason avaimet eivät heijastu pilveen ja päinvastoin. Tämä koskee myös pilviyksiköitä. (Esimerkiksi: CP1:ssä on salaus käytössä ja CP2:ssa salaus ei ole käytössä, jolloin CP1-avaimet eivät näy CP2:ssa.)   

Kysymys: Voiko avaimia poistaa pilvestä?
Vastata: Ei, avainten poistamista pilvestä ei tueta.

Kysymys: Missä pilviyksiköiden tietojen salausavaimia hallitaan?
Vastata: Avaimet liittyvät cp:hen ja jokainen pilviyksikkö on eri cp. Kopio kaikkien cps:ien avaimista tallennetaan aktiiviseen cp:hen.

Kysymys: Miten pilviavaimet palautetaan katastrofista palautumisen aikana? 
Vastaus: CPNAMEVAL peilataan pilveen osana CP-palautusta, salausavaimet palautetaan cpnamevaliin. Nyt meidän on suoritettava ddr_key_util työkalu avainten palauttamiseksi.

Huomautus: Katastrofista palautuminen edellyttää asiakastuen toimia.

Kysymys: Voimmeko siirtää tietoja, kun salaus on käytössä vain pilvitasolla?
Vastata: Ei, meidän on otettava salaus käyttöön sekä pilvitasolla että aktiivisella tasolla tiedonsiirtoa varten.

Kysymys: Voimmeko ottaa ulkoisen avainhallinnan käyttöön pilvitasolla?
Vastata: Kyllä, ulkoisen avaimen hallinnan voi ottaa käyttöön pilvitasolla. Tätä ominaisuutta tuetaan versiosta 7.8 alkaen. Kaikki toiminnot lukuun ottamatta aktiiviselle tasolle kelpaavan avaimen tuhoamista tai poistamista koskevat myös pilvitasoa ulkoisen avaimenhallinnan kannalta. 

Salaus ja roskien kerääminen

Kysymys: Mikä rooli yleisellä puhdistusprosessilla on levossa olevassa salauksessa, ja vaikuttaako se suorituskykyyn, kun salaus otetaan käyttöön ensimmäistä kertaa?
Vastata: Kun lepotilassa olevien tietojen salaus otetaan käyttöön ensimmäistä kertaa, se vaikuttaa yleisen puhdistuksen suorituskykyyn. Tämä johtuu siitä, että tiedot, jotka on luettava levyllä olevista säilöistä ja tallennettava uusiin säilöihin, on ehkä luettava, niiden salaus on purettava ja itse tiedot on purettava, ennen kuin ne pakataan uudelleen, salataan ja tallennetaan takaisin levylle. Kun salaus on käytössä DD:ssä, jossa on huomattava määrä ennestään tietoja, ja suoritetaan komento filesys encryption apply-changes, seuraava yleinen puhdistus yrittää salata kaikki järjestelmässä olevat tiedot. Tämä tarkoittaa, että kaikki tiedot on luettava, purettava, pakattava, salattava ja kirjoitettava levylle. Siksi ensimmäinen yleinen puhdistus komennon 'filesys encryption apply-changes' jälkeen saattaa kestää tavallista kauemmin. Asiakkaiden on varmistettava, että DD-järjestelmässä on riittävästi tilaa, jotta puhdistus voidaan suorittaa loppuun DD-järjestelmän täyttymättä (muuten varmuuskopiot epäonnistuvat).

Kysymys: Onko meneillään olevilla nielemis-/palautusjaksoilla vaikutusta suorituskykyyn?
Vastata: Kyllä, vaikutus suorituskykyyn on olemassa, ja vaikutus riippuu yleensä siitä, kuinka paljon tietoja nautitaan/palautetaan puhtaiden jaksojen välillä.

Kysymys: Kuinka kauan nykyisten tietojen salaaminen kestää?
Tämän tietämyskannan artikkelin avulla voit arvioida aikaa, Data Domain: Lasketaan, kuinka kauan salaus levossa kestää.

Salaus ja headswap 

Kysymys: Voiko asiakas siirtää levyn toiseen Data Domain -järjestelmään, jos pää pettää, ja käyttää levyä, kun salaus on käytössä?
Vastata: Salausavainta ei ole sidottu itse Data Domain -järjestelmäpäähän, joten voit siirtää levyt toiseen Data Domain -järjestelmäpäähän, jossa avain on käytettävissä. Uudessa Data Domain -järjestelmäpäässä tiedostojärjestelmä on lukittu, joten sinun on annettava salasana "filesys encryption unlock" -komennolla. 

Kysymys: Entä jos asiakas unohti salasanan päänvaihdon aikana?
Vastata: Tänä aikana he voivat yhdistää vanhan pään ja työskennellä tuen kanssa salasanan nollaamiseksi ja sitten muodostaa yhteyden takaisin uuteen päähän ja lopettaa päänvaihdon. 

Salauksen suorituskyky

Kysymys: Miten salauksen käytön havaitaan vaikuttavan tallennustilan kulutukseen?
Vastata: Se on vähäinen, ja noin 1 prosentin yleiskustannukset liittyvät joidenkin salausparametrien tallentamiseen käyttäjätietoihin.

Kysymys: Miten havaittu vaikutus siirtonopeuteen (kirjoitus ja luku) on, kun käytössä on tallennettujen tietojen salaus?
Vastata: Vaikutus käsittelyn suoritustehoon salausta käytettäessä voi vaihdella protokollan ja alustan mukaan. Yleensä seuraavat prosenttiosuudet ovat varovaisia suorituskyvyn heikkenemistä kokonaissuorituskyvyssä:CBC-tilan


ensimmäinen täysi: ~10 %:n suorituskyvyn heikkeneminen WRITE-kirjoituksissa
Inkrementaalinen: ~5 %:n suorituskyvyn heikkeneminen WRITE-toiminnoissa Palautukset
: 5–20 % suorituskyvyn heikkeneminen READ-laitteissa GCM-tila


ensin täysi: 10–20 %:n suorituskyvyn heikkeneminen WRITE-kirjoituksissa
Vaiheittainen: 5–10 %:n suorituskyvyn heikkeneminen WRITE-toiminnoilla Palauttaa
: 5–20 % suorituskyvyn heikkeneminen READ-laitteissa

Nämä luvut koskevat lepotilassa olevien tietojen salauksen yleiskustannuksia (langallinen salaus lasketaan erikseen)
 

Parhaat käytännöt

Kysymys: Mitkä ovat avainten kiertoon liittyvät parhaat käytännöt?
Vastata: Automaattinen näppäinten kiertokäytäntö on oletusarvoisesti poissa käytöstä. Asiakas on ottanut sen käyttöön. Salausavaimia kannattaa kiertää usein. Kun järjestelmään on konfiguroitu ulkoinen KMIP-avainten hallinta, on suositeltavaa vaihtaa näppäimiä usein, jotta mahdolliset tulevat kompromissitilanteet voidaan ratkaista. Kun KMIP:lle on määritetty pilvitaso, ehdotettu avainten kiertoväli on 1 viikko. Jos KMIP on määritetty vain aktiiviselle tasolle, ehdotettu avainten kiertokäytäntö on 1 kuukausi. Käsittelynopeuden perusteella asiakas voi kuitenkin myös lisätä tai vähentää näppäinten kiertotiheyttä. Jos sulautettu avainten hallinta on määritetty, avainten kiertokäytäntöä suositellaan 1–3 kuukauden välille. 

Kysymys: Mitkä ovat KMIP-avainluokan parhaat käytännöt, jos asiakas käyttää samaa KMIP-palvelinta useissa DD-järjestelmissä?
Vastata: On suositeltavaa, että jokaisella DD-järjestelmällä on oma avainluokkansa, kun ne käyttävät samaa KMIP-palvelinta. Tällä tavoin näppäinten kierto yhdessä DDOS-järjestelmässä ei vaikuta toisessa DDOS-järjestelmässä olevan avaimen tilaan.

Lisätietoja on asiakirjassa DELL EMC PowerProtect DD -sarjan laitteet: Salausohjelmisto (delltechnologies.com)

Salaus: Tekninen raportti PowerProtect DD -sarjan laitteet: Salausohjelmisto

Muita DD-salaukseen liittyviä ohjeita (järjestelmänvalvojan opas, komentojen viiteopas ja suojauksen määritysopas) on keskeisissä artikkeleissa 126375, PowerProtect ja Data Domain.

KMIP-integrointiopas ja yhteensopivuusmatriisi

Katso tämä video: