Dell EMC Data Domain Encryption – Häufig gestellte Fragen

Verschlüsselungskonfiguration

Frage: Wie wird die Verschlüsselung (DARE) in der DD konfiguriert?
Antwort: Die DARE-Verschlüsselung kann in der DD mit den folgenden Schritten konfiguriert werden:

1. Verschlüsselungslizenz hinzufügen

2. Hinzufügen eines Security Officer und Aktivieren der Security Officer-Autorisierungen

3. Verschlüsselung aktivieren 

1) Verschlüsselungslizenz hinzufügen:
Halten Sie eine Lizenzdatei mit einer gültigen Verschlüsselungslizenz bereit.
Verwenden Sie den folgenden Befehl, um die eLicense in der DD mithilfe der verfügbaren Lizenzdatei zu aktualisieren.

eLicense-Aktualisierung

2) Hinzufügen eines Sicherheitsbeauftragten und Aktivieren der SO-Autorisierungen:
a) Hinzufügen eines Nutzers mit der Rolle "Security" mithilfe des Befehls: 

Sicherheit der Nutzer-Rolle "Secuser" hinzufügen

b) Aktivieren Sie die Security Officer Authorization im Setup mit dem Befehl: 

Autorisierungs-Policy-Set Security-Officer aktiviert

3. Aktivieren Sie die DARE-Verschlüsselung:
Aktivieren Sie die DARE-Verschlüsselung mithilfe des Befehls:

Filesys-Verschlüsselung aktivieren

Frage: Welche Plattformen werden mit der Data-at-Rest-Verschlüsselungsfunktion unterstützt?
Antwort: Die Data-at-Rest-Verschlüsselungsfunktion wird auf allen Data Domain-Systemen unterstützt, mit Ausnahme von EDP-Systemen (Encryption Disablement Project).

Frage: Wie kann der Nutzer seine Daten im Klartext in DD speichern?
Antwort: Der Nutzer kann sicherstellen, dass die Daten im Klartext gespeichert und in der DD nicht verschlüsselt werden, indem er bestätigt, dass die Verschlüsselung im Setup deaktiviert ist.
Nutzer können die Verschlüsselung in DD mithilfe des folgenden Befehls deaktivieren: 

Dateisys-Verschlüsselung deaktivieren

Frage: Welche Backupanwendungen/-protokolle werden von der Data-at-Rest-Verschlüsselungsfunktion unterstützt?
Antwort: Die DD DARE-Funktion ist unabhängig von der zugrunde liegenden Backupanwendung oder dem Protokoll, das von DD verwendet wird.

Fuestion: Welche Verschlüsselungsalgorithmen können auf dem Data Domain-System ausgewählt werden?
Antwort: Die DD Encryption-Software unterstützt AES 128- oder 256-Bit-Algorithmen mit Cipher Block Chaining (CBC) oder Galois Counter Mode (GCM). 

GCM ist ein Betriebsmodus für kryptografische Blockchiffren mit symmetrischem Schlüssel. Es handelt sich um einen authentifizierten Verschlüsselungsalgorithmus, der sowohl Authentifizierung als auch Datenschutz (Vertraulichkeit) bietet. Wie der Name schon sagt, kombiniert GCM den bekannten Counter-Verschlüsselungsmodus mit dem neuen Galois-Authentifizierungsmodus. Der Authentifizierungsaspekt von GCM garantiert, dass die Daten, die verschlüsselt wurden, vom Data Domain-System durchgeführt wurden und nicht mit anderen Mitteln "injiziert" wurden. Dies unterscheidet sich von CBC, bei dem Daten verschlüsselt werden (Datenschutzaspekt), aber es gibt keine Überprüfung auf die Authentizität der verschlüsselten Daten.

Im CBC-Modus wird jeder Klartextblock vor der Verschlüsselung exklusiv mit dem vorherigen Chiffretextblock verglichen. Auf diese Weise hängt jeder Chiffretextblock von allen bis dahin verarbeiteten Klartextblöcken ab. Um jede Nachricht eindeutig zu machen, muss außerdem ein Initialisierungsvektor im ersten Block verwendet werden. CBC garantiert lediglich die Vertraulichkeit (Vertraulichkeit) der Daten durch Verschlüsselung. Es erfolgt keine Authentifizierung des Verschlüsselungsalgorithmus oder -prozesses.

Frage: Wie können wir den Verschlüsselungsalgorithmus in der DD ändern?

Antwort: Verwenden Sie den folgenden Befehl, wenn Sie einen bestimmten Verschlüsselungsalgorithmus im Setup festlegen möchten.

Dateisys-Verschlüsselungsalgorithmus festgelegt

Beispiel:

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

Frage: Wie stellen wir sicher, dass die Verschlüsselung für bereits vorhandene Daten erfolgt, sobald die Verschlüsselung aktiviert ist?
Antwort: Mit dem folgenden Befehl können Sie DDFS zwingen, die bereits vorhandenen Daten zu verschlüsseln:

# filesys encryption apply-changes

Dadurch wird der nächste Reinigungszyklus deutlich länger und ressourcenintensiver als normalerweise.

Frage: Wie deaktivieren wir die Verschlüsselung in der DD
?Antwort: Deaktivieren Sie die Verschlüsselungsfunktion in DD mithilfe des Befehls zum Deaktivieren der Verschlüsselung: 

Dateisys-Verschlüsselung deaktivieren

Dadurch wird nur die Verschlüsselung für eingehende I/O-Vorgänge deaktiviert. Vorhandene verschlüsselte Daten bleiben verschlüsselt, bis sie manuell mit apply-changes entschlüsselt werden.

Frage: Bei welchen Verschlüsselungsbefehlen ist ein Neustart des DD-Dateisystems erforderlich, um wirksam zu werden?
Antwort: Für die folgenden Verschlüsselungsbefehle ist ein Neustart des DD-Dateisystems erforderlich, um wirksam zu werden:

Filesys-Verschlüsselung aktivieren/deaktivieren – Aktiviert/deaktiviert die Verschlüsselung auf dem Data Domain-System.

Dateisys-Verschlüsselungsalgorithmus-Set - Ermöglicht dem Nutzer die Auswahl eines kryptografischen Algorithmus.

Dateisys-Verschlüsselungsalgorithmus zurücksetzen - Setzt den Verschlüsselungsalgorithmus im CBC-Modus auf AES 256 zurück (Standardeinstellung).

Frage: Für welche Verschlüsselungsbefehle muss das Data Domain-Dateisystem deaktiviert sein, um sie einrichten/verwenden zu können?
Antwort: Für die folgenden Verschlüsselungsbefehle muss das Data Domain-Dateisystem deaktiviert sein, um sie festzulegen oder zu verwenden:

Änderung der Verschlüsselungspassphrase

Verschlüsselung sperren/entsperren

Allgemeine Fragen zur Verschlüsselung

Frage: Wird DD-Verschlüsselung auf allen DD-Systemen unterstützt?
Antwort: Die DD Encryption-Softwareoption wird auf DD-Systemen unterstützt, wenn es sich nicht um ein Verschlüsselungsdeaktivierungsprojekt (EDP) handelt, bei dem es sich um Systeme handelt, bei denen die Verschlüsselung nicht aktiviert werden kann. Dies werden hauptsächlich in Systemen der Region Russland verkauft.

Frage: Wie wird die Verschlüsselung in DD-Systemen durchgeführt?
Antwort: Die Kryptografie erfolgt mithilfe von OpenSSL- und RSA BSafe-Bibliotheken (RSA BSafe ist eine FIPS 140-2-validierte Kryptografiebibliothek, die von DD-Systemen zur Verschlüsselung von Data at Rest verwendet wird) Bibliotheken in DDOS. 

Frage: Welche Version von BSafe wird mit dem System verwendet?
Antwort: Ab DDOS 7.10 werden die BSafe-Versionen "BSAFE Micro Edition Suite 4.4.0.0" und "BSAFE Crypto-C Micro Edition: 4.1.4.0"

Frage: Welche Benutzeroberflächen stehen für die Konfiguration der Verschlüsselung in DDOS zur Verfügung?
Antwort: Die Verschlüsselung kann über die CLI, die Benutzeroberfläche oder über REST APIs konfiguriert werden. Die Unterstützung für REST API wurde ab DDOS-Version 8.0 hinzugefügt.

Frage: Ist eine selektive Verschlüsselung von Daten möglich? Möchten Sie nur einen MTree oder eine Datei?
Antwort: Eine selektive Verschlüsselung ist NICHT möglich. Die Verschlüsselung kann nur systemweit und nicht selektiv aktiviert oder deaktiviert werden. Für Systeme mit Cloud-Unterstützung kann die Verschlüsselung je nach Cloud-Tier und Cloudeinheitsgranularität aktiviert oder deaktiviert werden.  

Frage: Werden kryptografische Schlüssel oder Kontokennwörter im Klartext oder unter schwachen Chiffren übertragen oder gespeichert, z. B. bei der Authentifizierung einer Entität in Datendateien, in Programmen oder in Authentifizierungsverzeichnissen?
Antwort: Auf keinen Fall.

Frage: Welche Version von OpenSSL wird mit dem System verwendet?
Antwort: Ab DDOS 7.10 lautet die OpenSSL-Version "OpenSSL 1.0.2zd-fips"

Frage: Wie schützt die Data-at-Rest-Verschlüsselung vor dem Datenzugriff von Nutzern und Anwendungen?
Antwort: 

• Bei der Data-at-Rest-Verschlüsselung geht es um die Verschlüsselung der Daten, die sich auf dem Festplattensubsystem befinden. Die Verschlüsselung oder Entschlüsselung erfolgt auf der Komprimierungsebene. Nutzer oder Anwendungen senden und empfangen Klartextdaten an das Data Domain-System, aber alle Daten, die sich physisch auf dem Data Domain-System befinden, werden verschlüsselt.
• Die gesamte Verschlüsselung erfolgt unterhalb des Dateisystems und Namespace und ist für die Nutzer oder Anwendungen nicht sichtbar. Wenn ein Nutzer oder eine Anwendung bereits autorisierten Zugriff auf eine Datei oder ein Verzeichnis hat, können die Daten unabhängig von der Verschlüsselung im nativen Format gelesen werden.
• DD Encryption ist so konzipiert, dass, wenn ein Eindringling andere Netzwerksicherheitskontrollen umgeht und Zugriff auf verschlüsselte Daten erhält, die ohne die richtigen kryptografischen Schlüssel für diese Person unlesbar und unbrauchbar sind. 

Frage: Erfolgt die Verschlüsselung nach der Deduplizierung?
Antwort: Ja, die Verschlüsselung erfolgt für deduplizierte Daten. Die Daten werden verschlüsselt, bevor sie auf der Festplatte gespeichert werden. 

Frage: Wie gewährleistet Data Domain die Sicherheit der Daten?
Antwort: Daten werden mit der Data-at-Rest-Verschlüsselungsfunktion gesichert. Außerdem wird die Passphrase aus dem System entfernt, wenn das Gerät entfernt wird (Head-Swap, Dateisystemsperre). Diese Passphrase wird verwendet, um Verschlüsselungsschlüssel zu verschlüsseln, damit die Daten weiter geschützt sind.

Frage: Welche Warnmeldungen werden mit Verschlüsselung erzeugt?
Antwort: Warnmeldungen werden in den folgenden Fällen erzeugt:

• Wenn kompromittierte Verschlüsselungsschlüssel vorhanden sind
• Wenn die Verschlüsselungsschlüsseltabelle voll ist und keine weiteren Schlüssel im System hinzugefügt werden können
• Wenn das automatische Exportieren von Schlüsseln fehlschlägt
• Wenn die automatische Schlüsselrotation fehlschlägt
• Wenn die Verschlüsselung deaktiviert ist
• Wenn sich die System-Passphrase geändert hat

Frage: Gibt es eine Sicherheitszertifizierung für DDOS? 
Antwort: Data Domain-Systeme erfüllen die FIPS 140-2-Compliance. 

Frage: Wo wird der Verschlüsselungsschlüssel gespeichert?
Antwort: Verschlüsselungsschlüssel werden dauerhaft in einer Sammelpartition im DDOS-System gespeichert.

Frage: Wenn jemand eine Festplatte aus einem Data Domain-System herauszieht, können Sie dann Daten davon entschlüsseln?
Antwort: Verschlüsselungsschlüssel werden mithilfe der Systempassphrase verschlüsselt, die im Systemkopf gespeichert ist. Obwohl Verschlüsselungsschlüssel auf der Festplatte gespeichert werden, können Chiffrierschlüssel ohne Systempassphrase nicht entschlüsselt werden. Ohne den Schlüssel zu kennen, mit dem die Daten verschlüsselt wurden, ist eine Entschlüsselung von einer Festplatte nicht möglich.  

Frage: Welche kryptografischen Schlüssel und Kennwörter werden für die Recovery benötigt, insbesondere für die Disaster Recovery?
Antwort: Schlüssel können in eine sichere Datei exportiert und außerhalb des Systems aufbewahrt werden. Die Wiederherstellung dieser Datei erfolgt mit Hilfe von Ingenieuren. Außerdem muss der Kunde zum Zeitpunkt der Recovery die Passphrase kennen, die er zum Zeitpunkt des Schlüsselexportbefehls verwendet hat.

Frage: So sperren Sie das Dateisystem vor der Übertragung des Systems an einen Remotestandort.
Antwort: Im Folgenden finden Sie die Vorgehensweise dafür: 

• Deaktivieren Sie das Dateisystem:

  sysadmin@itrdc-DD630-42# filesys deaktivieren

• Sperren Sie das Dateisystem und geben Sie eine neue Passphrase ein (dies erfordert die Authentifizierung durch den oben genannten Sicherheitsnutzer):

  sysadmin@itrdc-DD630-42# filesys encryption lock
  Für diesen Befehl ist eine Autorisierung durch einen Nutzer mit der Rolle "security" erforderlich.
  Bitte geben Sie unten die Anmeldeinformationen für einen solchen Nutzer an.
          Benutzername: secuser
  Kennwort:
  Geben Sie die aktuelle Passphrase ein:
  Enter new passphrase:
  Re-enter new passphrase:
  Passphrases stimmen überein.
  Das Dateisystem ist jetzt gesperrt.

• Die neue Passphrase darf NICHT verloren gehen oder vergessen werden. Ohne diese Passphrase kann das Dateisystem nicht entsperrt werden, was bedeutet, dass auf Daten auf dem DDR nicht zugegriffen werden kann. Um das System zu entsperren, wenn es einen entfernten Standort erreicht, verwenden Sie den folgenden Befehl:

sysadmin@itrdc-DD630-42# Dateisystemverschlüsselung entsperrt
Für diesen Befehl ist eine Autorisierung durch einen Nutzer mit der Rolle "security" erforderlich.
Geben Sie unten die Zugangsdaten für einen solchen Nutzer an.
        Nutzername: secuser
Kennwort:
Passphrase eingeben:
Die Passphrase wurde überprüft. Verwenden Sie 'filesys enable', um das Dateisystem zu starten.

• Das Dateisystem kann jetzt aktiviert und wie gewohnt verwendet werden

Frage: Steht der Befehl "storage sanitize" in irgendeiner Beziehung zur Dateisystemverschlüsselung?
Antwort: Nein, Dateisystemverschlüsselung und Speicherbereinigung sind zwei unabhängige Funktionen. 

Frage: Wird die Verschlüsselung über das Internet im EDP-System (Encryption Disablement Project) unterstützt?
Antwort: Wir können weder die Data-at-Rest-Verschlüsselung (DARE) noch die Verschlüsselung über das Internet (mit Replikation oder mit ddboost) im EDP-System aktivieren.

System-Passphrase 

Frage: Was ist die System-Passphrase?
Antwort: DDOS bietet die Möglichkeit, Zugangsdaten innerhalb des Systems zu sichern, indem eine Passphrase auf Systemebene festgelegt wird. Die Passphrase ist ein für Menschen lesbarer (verständlicher) Schlüssel wie eine Smartcard, der verwendet wird, um einen vom Computer nutzbaren AES 256-Verschlüsselungsschlüssel zu erzeugen. 

Sie bietet zwei Vorteile:

• Sie ermöglicht es dem Administrator, die Passphrase zu ändern, ohne die Verschlüsselungsschlüssel bearbeiten zu müssen. Das Ändern der Passphrase ändert indirekt die Verschlüsselung der Schlüssel, wirkt sich jedoch nicht auf die Nutzerdaten aus. Durch das Ändern der Passphrase wird nicht der zugrunde liegende Data Domain-Systemchiffrierschlüssel geändert. Die Verschlüsselung des Data Domain-Systemschlüssels wird geändert, der Systemschlüssel bleibt jedoch unverändert.
• Sie ermöglicht es, ein physisches Data Domain-System mit einem Verschlüsselungsschlüssel auf dem System zu liefern, ohne dass die Passphrase darauf gespeichert wird. Auf diese Weise kann ein Angreifer die Daten nicht wiederherstellen, wenn die Box während des Transports gestohlen wird, da das System nur über verschlüsselte Schlüssel und verschlüsselte Daten verfügt.

Die Passphrase wird intern in einem verborgenen Teil des Data Domain-Speichersystems gespeichert. Auf diese Weise kann das Data Domain-System gestartet und der Datenzugriff ohne Intervention des Administrators fortgesetzt werden.

Erstellen oder Ändern der Passphrase:

• Die System-Passphrase kann mithilfe der CLI erstellt werden, nachdem sich ein Administrator beim Data Domain-System authentifiziert hat.
• Die Systempassphrase kann mithilfe der CLI geändert werden, nachdem sich ein Administrator und ein Sicherheitsrollennutzer (z. B. ein Sicherheitsbeauftragter) beim Data Domain-System authentifiziert haben (sodass kein einzelner Administrator unabhängig voneinander Änderungen vornehmen kann).

Frage: Wann wird die Passphrase verwendet?
Antwort: Die System-Passphrase wird von verschiedenen DDOS-Komponenten als Primärschlüssel verwendet. Dazu gehören Dateisystemverschlüsselung, Cloud-Zugriff, Zertifikatmanagement, Boost-Token, Systemkonfigurationsmodule in Scale-out-Umgebungen und Lizenzierungsinformationen. Die DDOS-Software bietet Mechanismen zum Festlegen und Ändern dieser System-Passphrase. Es bietet auch Optionen, mit denen gesteuert werden kann, ob die System-Passphrase auf der Festplatte gespeichert wird. Dies wird insbesondere für erhöhte Sicherheit beim Transport des DD-Systems verwendet. 

Frage: Wie wird die Passphrase für den sicheren Transport des DD-Systems verwendet?
Antwort: Der Prozess verwendet den Befehl "filesys encryption lock", mit dem der Nutzer das Dateisystem durch Ändern der Passphrase sperren kann. Der Nutzer gibt eine neue Passphrase ein, die den Chiffrierschlüssel erneut verschlüsselt, die neue Passphrase wird jedoch nicht gespeichert. Die Verschlüsselungsschlüssel können erst wiederhergestellt werden, wenn das Dateisystem mit dem Befehl "filesys encryption unlock" entsperrt wird.

Der Vorgang ist im Confluence Lab Security Configuration Guide beschrieben.

Frage: Was passiert, wenn sich die Passphrase ändert? Kann weiterhin auf die Daten zugegriffen werden?
Antwort: Ja, durch das Ändern der Passphrase wird nicht der zugrunde liegende Data Domain-Systemchiffrierschlüssel geändert, sondern nur die Verschlüsselung des Verschlüsselungsschlüssels. Daher ist der Datenzugriff nicht betroffen.

Frage: Wie können wir abfragen, ob eine Passphrase auf dem System eingestellt ist?
Antwort: Wenn eine Passphrase auf dem System festgelegt ist, wird beim Ausführen des Befehls "system passphrase set" ein Fehler ausgegeben, der darauf hinweist, dass die Passphrase bereits festgelegt ist.

Frage: Was passiert, wenn die Passphrase verloren geht oder vergessen wurde?
Antwort: Wenn der Kunde die Passphrase verliert, während das Feld gesperrt ist, verliert er seine Daten. Es gibt keine Hintertür oder alternative Möglichkeit, darauf zuzugreifen. Ohne einen guten Prozess für das Management dieser Passphrase könnte dies versehentlich passieren und sie wären nicht in der Lage, den Schlüssel oder die Daten wiederherzustellen. Der verschlüsselte Schlüssel kann jedoch aufgrund der integrierten Schutzmechanismen des Systems niemals verloren gehen oder beschädigt werden.

Frage: Gibt es einen Mechanismus zum Zurücksetzen der vergessenen Systempassphrase?
Antwort: Die System-Passphrase kann nur in bestimmten Szenarien mithilfe des Kundensupports erzwungen zurückgesetzt werden. Der in DDOS 7.2 eingeführte Mechanismus der erzwungenen Aktualisierung kann hierfür nur verwendet werden, wenn bestimmte Bedingungen erfüllt sind. Weitere Informationen finden Sie im Wissensdatenbank-Artikel 20983, Data Domain: So setzen Sie eine verlorene System-Passphrase in DDOS v7.2 oder höher zurück (Anmeldung beim Dell Support erforderlich, um den Artikel anzuzeigen)

Frage: Gibt es eine Option, um das Speichern der Systempassphrase auf dem DD-System zu vermeiden?
Antwort: Die System-Passphrase wird standardmäßig an einem verborgenen Speicherort auf dem Data Domain-System gespeichert. Die Systemoption "system passphrase option store-on-disk" kann verwendet werden, um dies zu ändern und das Speichern der Passphrase auf der Festplatte zu vermeiden.

Integrierter Key Manager (EKM)

Befehl der obersten Ebene:

system# filesys encryption embedded-key-manager-Option <>

Frage: Wird die Schlüsselrotation mit integriertem Key Manager unterstützt?
Antwort:  Ja, die Schlüsselrotation pro Data Domain-System wird mit integriertem Key Manager unterstützt. Über die Benutzeroberfläche oder CLI kann der Administrator einen Zeitraum für die Schlüsselrotation (wöchentlich oder monatlich

) einrichten.Frage: Wird die integrierte Schlüsselverwaltung kostenpflichtig?
Antwort: Diese Funktion ist kostenlos. Diese Funktion ist in der standardmäßigen DD Encryption-Softwarelizenzoption enthalten.

Frage: Kann der Kunde vom lokalen Key-Management zum externen Key-Management (EKM) wechseln?
Antwort

• Ja, externe Key Manager können jederzeit aktiviert werden. Die verwendeten lokalen Schlüssel verbleiben jedoch auf dem Data Domain-System. Externe Key-Manager können die EKM-Schlüssel nicht managen. Vorhandene Daten müssen nicht erneut verschlüsselt werden. Wenn für einen Kunden Compliance-Daten mit EKM-Schlüsseln neu verschlüsselt werden müssen, muss dies manuell mithilfe von apply-changes mit dem neuen RW-Schlüssel erfolgen. Das Löschen von EKM-Schlüsseln nach einem Wechsel ist nicht zwingend erforderlich.
  • Der Key-Manager-Switch schaltet den aktiven Schlüssel automatisch auf den Schlüssel von KMIP um. 
  • Beispiel für das Aussehen der KMIP-Schlüssel-MUID bei einem Wechsel

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

Frage: Was passiert, wenn die Schlüsselrotation deaktiviert oder aktiviert wird?
Antwort: 

• Die deaktivierte Schlüsselrotation ist die standardmäßige Verschlüsselungsfunktion, wenn Sie die Schlüsselrotation nicht über die Benutzeroberfläche oder CLI aktivieren. In diesem Szenario werden alle Daten mit dem vorhandenen aktiven Schlüssel verschlüsselt.
• Wenn die Schlüsselrotation aktiviert ist, werden die Schlüssel basierend auf der Rotationsfrequenz rotiert und die Daten werden mit dem neuesten aktiven Schlüssel verschlüsselt.

Externe Key-Manager

Frage: Welche externen Key Manager werden auf DD unterstützt?
Antwort: Wir unterstützen die folgenden externen Key Manager:

• Gemalto KeySecure (Support hinzugefügt in DDOS-Version 7.2)
• Vormetric (Unterstützung hinzugefügt in DDOS-Version 7.3)
• CipherTrust (Unterstützung hinzugefügt in DDOS-Version 7.7)
• IBM GKLM (Unterstützung hinzugefügt in DDOS-Version 7.9)

Frage: Ist eine separate Lizenz erforderlich, um die Integration mit einem externen Key Manager zu aktivieren?
Antwort: Ja, es ist eine separate Lizenz vom jeweiligen Anbieter erforderlich, um External Key Manager in DD zu integrieren.

Frage: Wie viele wichtige ManagerInnen unterstützen gleichzeitig?
Antwort: Auf einem DD-System kann immer nur ein einziger Key Manager aktiv sein.

Frage: Wo finde ich weitere Informationen zur Konfiguration von KMIP External Key Manager?
Antwort: Der KMIP-Integrationsleitfaden für DDOS enthält detaillierte Informationen zur Konfiguration der verschiedenen externen Key-Manager, die von DD unterstützt werden.

Frage: Wie werden Zertifikate für externe Key Manager in DD verwaltet?
Antwort: Bei der Konfiguration des externen Key-Managers müssen wir ein CA-Zertifikat (das CA-Zertifikat kann ein selbstsigniertes Zertifikat oder ein von einem Drittanbieter signiertes Zertifikat sein) und ein Hostzertifikat erzeugen. Sobald die Konfiguration auf dem externen Key-Manager-Server abgeschlossen ist, müssen Nutzer das CA-Zertifikat und das Hostzertifikat auf das DD-System importieren. Anschließend konfigurieren und aktivieren wir den externen Key Manager. 

Frage: Was ist CA?
Antwort: Eine Zertifizierungsstelle (Certificate Authority, CA) fungiert als anfänglich vertrauenswürdige gemeinsame Entität zwischen Peers und stellt signierte Zertifikate aus, damit jede Partei der anderen vertrauen kann. Ein Zertifikat fungiert in der Regel als Identität eines Servers oder Clients. 

Frage: Was ist ein lokales, von einer Zertifizierungsstelle signiertes Zertifikat, was ist ein von einer Zertifizierungsstelle signiertes Zertifikat?
Antwort: Ein von einer Zertifizierungsstelle signiertes Zertifikat ist ein Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt und signiert wurde. Ein von einer Zertifizierungsstelle signiertes Zertifikat wird automatisch als vertrauenswürdig eingestuft. Eine lokale Zertifizierungsstelle kann signierte Zertifikate ausstellen, da der private Signaturschlüssel im Key-Manager-System gespeichert ist. Eine externe Zertifizierungsstelle speichert den privaten Schlüssel nicht. Stattdessen wird eine externe Zertifizierungsstelle als vertrauenswürdige Entität für verschiedene Schnittstellen und Services innerhalb des Systems verwendet.

Frage: Wie erstelle ich eine Zertifikatsignieranforderung in DD?
Antwort: Erzeugen Sie die CSR auf dem Data Domain-System mithilfe des folgenden CLI-Befehls. Auf diese Weise wird der private Schlüssel niemals für den externen Key-Manager verfügbar gemacht.

AdminAccess-Zertifikat Zertifikatsignierungsanforderung

Frage: Ist es möglich, zwischen Key Managern zu wechseln?
Antwort: Der Wechsel zwischen External Key Manager und Embedded Key Manager ist zulässig und verläuft nahtlos. Der Wechsel von Embedded Key Manager zu External Key Manager erfordert jedoch eine entsprechende Zertifikatinstallation und -konfiguration. Wechseln zwischen zwei externen Key-Managern (z. B.: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust an GKLM) sind ebenfalls zulässig. Die Migration von Key-Manager-Schlüsseln wird ebenfalls unterstützt (weitere Informationen finden Sie im KMIP-Integrationshandbuch).

Frage: Was passiert, wenn die externe Key Manager-Konnektivität ausfällt? Sind meine Daten dann zugänglich?
Antwort: Ja, die Daten sind weiterhin zugänglich, wenn keine Verbindung zum Key Manager hergestellt werden kann, da wir auch Kopien der Schlüssel im DD-System speichern. Es können keine neuen Schlüssel erstellt oder Schlüsselstatus nicht synchronisiert werden, wenn keine Verbindung mit dem externen Key Manager besteht.

Frage: Gibt es eine Möglichkeit, das Speichern von Schlüsseln in DD zu vermeiden und nur im externen Key Manager zu speichern?
Antwort: Wir speichern immer eine Kopie der Schlüssel im DD-System für DIA-Zwecke. Diese Einstellung kann nicht geändert werden.

Frage: Entstehen durch die Integration mit KMIP Leistungseinbußen?
Antwort: Nein, die Verwendung externer Key Manager beeinträchtigt die Performance nicht.

Frage: Ist es möglich, die KMIP-Lösung für ausgewählte Data Domains innerhalb der Umgebung zu nutzen?
Antwort: Ja, Kunden haben volle Flexibilität bei der Auswahl der geeigneten Verschlüsselungsmethodik für ihre Data Domain-Systeme. Sie können weiterhin den integrierten Key Manager von Data Domain auf einigen Data Domain-Systemen und die Rotation von Chiffrierschlüsseln über KMIP auf anderen Data Domain-Systemen in ihrer Umgebung nutzen.

Frage: Ist die Kommunikation zwischen Data Domain und KMIP sicher?
Antwort: Ja, Data Domain kommuniziert über gegenseitig authentifizierte X509-Zertifikatssitzungen mit TLS. Der Nutzer kann die Data Domain-CLI verwenden, um das entsprechende X509-Zertifikat in das Data Domain-System zu importieren. Dieses Zertifikat wird dann verwendet, um den sicheren Kanal zwischen DD und KMIP einzurichten.

Schlüssel-Lebenszyklusmanagement 

Frage: Welche Key-Management-Funktionen gibt es bei der Option "DD Encryption"?
Antwort: Ein Key Manager steuert die Erzeugung, Verteilung und das Lebenszyklusmanagement mehrerer Verschlüsselungsschlüssel. Ein Datenschutzsystem kann entweder den integrierten Key Manager oder den KMIP-konformen externen Key Manager verwenden. Es kann jeweils nur ein Key Manager wirksam sein. Wenn die Verschlüsselung auf einem Datenschutzsystem aktiviert ist, ist standardmäßig der integrierte Key Manager aktiv. Wenn ein externer Key Manager konfiguriert ist, ersetzt er den integrierten Key Manager und bleibt aktiv, bis er manuell deaktiviert wird. Der Wechsel vom integrierten Key Manager zum externen Key Manager oder umgekehrt führt dazu, dass dem System ein neuer Schlüssel hinzugefügt wird und kein Neustart des Dateisystems ab Version 7.1 erforderlich ist.

Frage: Was sind die verschiedenen Schlüsselstatus auf dem Data Domain-System?
Die verschiedenen Schlüsselstatus auf dem Data Domain-System lauten wie folgt:

• Aktiviert-RW: In diesem Status gibt es auf jedem DD-System nur einen Schlüssel, der zum Lesen und Schreiben von Daten verwendet wird. Dieser Schlüssel wird auch vom GC-Prozess verwendet, um Container erneut zu verschlüsseln.
• Ausstehend-aktiviert: In diesem Status gibt es auf jedem DD-System nur einen Schlüssel. Dadurch wurde der Schlüssel identifiziert, der nach dem nächsten Neustart des Dateisystems zu Activated-RW wird. Heute ist dieser Zustand nur zum Zeitpunkt der Aktivierung der Verschlüsselung vorhanden. Es wird kein anderer aktivierter Schlüssel erstellt.  
• Aktiviert-RO: Externe Key Manager können über mehrere aktivierte Schlüssel verfügen. Der aktuellste Schlüssel befindet sich in Activated-RW, der Rest befindet sich in diesem Status. Schlüssel können auf dem DD-System in diesen Status versetzt werden, wenn der Status nicht mit dem Key Manager synchronisiert werden kann.
• Deaktiviert: Dies wird zum Lesen vorhandener Daten auf dem DD-System verwendet.
• Kompromittiert: Wenn ein Kunde einen externen Key-Manager-Schlüssel kompromittiert, wird der Status nach der nächsten Schlüsselsynchronisierung in diesen Schlüssel geändert.  
• Marked-For-Destroyed: Wenn ein Kunde einen Schlüssel für die Löschung markiert, wechselt der Schlüsselstatus zu "Marked-For-Destroyed". Wenn GC ausgeführt wird, werden alle mit Marked-For-Destroyed-Schlüsseln verschlüsselten Container mithilfe des Activated-RW-Schlüssels erneut verschlüsselt.
• Zerstört: Ein Schlüssel im Status "Marked-For-Destroyed" wechselt in diesen Status, wenn ihm keine Daten zugeordnet sind.
• Zerstört – kompromittiert: Ein Schlüssel im Status "Compromised" wechselt in diesen Status, wenn ihm keine Daten zugeordnet sind.

Frage: Können Verschlüsselungsschlüssel für die Disaster Recovery exportiert werden?
Antwort: Schlüssel können manuell mit dem folgenden Befehl exportiert werden.

"filesys encryption keys export"

Das DD-System exportiert auch standardmäßig Schlüssel, wenn ein neuer Schlüssel hinzugefügt oder ein Schlüssel aus dem System gelöscht wird.

Exportierte Dateien liegen in /ddr/var/.security in einem verschlüsselten Format vor. Diese Datei sollte dann aus dem DDR kopiert und an einem sicheren Ort gespeichert werden, der später in jeder Disaster-Recovery-Bedingung verwendet werden kann.

Hinweis: Das Importieren von Schlüsseln für die Notfallwiederherstellung erfordert ein Eingreifen des Kundensupports, da der Wiederherstellungsprozess von der Art des aufgetretenen Notfalls abhängt. Wir können die exportierte Schlüsseldatei mit dem folgenden Befehl importieren.

Dateisys-Verschlüsselungsschlüssel Importdateiname <> 

Frage: Wird der von KMIP generierte Schlüssel im Data Domain-System gespeichert?
Antwort: Ja, der von der KMIP abgerufene Verschlüsselungsschlüssel wird verschlüsselt auf dem Data Domain-System gespeichert.

Frage: Wie wird eine Schlüsselstatusänderung in der KMIP-Appliance auf das Data Domain-System angewendet?
Antwort: Die Schlüsselsynchronisierung erfolgt täglich. Wenn ein neuer Schlüssel verfügbar ist oder der Status des Schlüssels geändert wird, aktualisiert die Synchronisierung die lokale Schlüsseltabelle. DD empfängt täglich um Mitternacht wichtige Updates vom KMIP.

Frage: Ist es möglich, die Schlüsselstatus zwischen DD und KMIP manuell zu synchronisieren?
Antwort: Ja, die Data Domain-CLI oder -Benutzeroberfläche kann verwendet werden, um die Schlüsselstatus zwischen DD und KMIP manuell zu synchronisieren. "filesys encryption keys sync" ist der dafür verwendete Befehl.

Frage: Ist es möglich, die Zeit zu ändern, zu der die DD wichtige Updates von KMIP erhält?
Antwort: Nein, es ist nicht möglich, den Zeitpunkt zu ändern, zu dem das DD-System wichtige Updates von KMIP erhält.

Frage: Gibt es eine Begrenzung für die Anzahl der Schlüssel, die vom Data Domain-System unterstützt werden?
Antwort: Ab DDOS 7.8 kann das Data Domain-System jederzeit maximal 1024 Schlüssel auf dem System haben. Es gibt nur einen Schlüssel in der Activated-RW und die restlichen Schlüssel können sich in einem beliebigen anderen Zustand befinden.

Frage: Können unterschiedliche Schlüssel für verschiedene Datenvolumen auf Data Domain-Systemen verwendet werden? Ist das konfigurierbar?
Antwort: Nein, wir unterstützen jeweils nur einen aktiven Schlüssel im System und alle eingehenden Daten werden mit dem aktuellen aktiven Schlüssel verschlüsselt. Schlüssel können nicht mit einer feineren Granularität wie M-Strukturen gesteuert werden.

Frage: Gibt es eine Benachrichtigung, wenn die maximale Anzahl an Schlüsseln erreicht ist?
Antwort: Ja, eine Warnmeldung wird ausgelöst, wenn die maximale Schlüsselanzahl von 1024 erreicht ist.

Frage: Wie kann ich die Warnmeldung über die maximale Schlüsselanzahl löschen?
Antwort: Einer der Schlüssel muss gelöscht werden, um die Warnmeldung zur maximalen Schlüsselbegrenzung zu löschen.

Frage: Können wir die Datenmenge sehen, die einem bestimmten Schlüssel im Data Domain-System zugeordnet ist?
Antwort: Ja, dies kann auf DD angezeigt werden, aber nicht auf dem KMIP-Server. Der Nutzer kann die Data Domain-CLI und die Benutzeroberfläche verwenden, um die Datenmenge anzuzeigen, die einem bestimmten Schlüssel zugeordnet ist.

Frage:  Können wir das Alter der Schlüssel auf dem DD-System anzeigen?
Antwort: Ja, es kann auf EKM-Schlüsseln über die Benutzeroberfläche angezeigt werden.

Frage: Funktioniert der alte Schlüssel auch dann, wenn die Frist abgelaufen ist, um den neuen Schlüssel wirksam zu machen?
Antwort: Es gibt kein Ablaufdatum für Verschlüsselungsschlüssel. Alte Schlüssel werden nach der Schlüsselrotation zu schreibgeschützten Schlüsseln und verbleiben im DDOS.

Frage: Wird der Verschlüsselungsschlüssel automatisch gelöscht, wenn ihm keine Daten auf dem Data Domain-System zugeordnet sind?
Antwort: Nein, der Schlüssel wird nicht automatisch gelöscht. Der Nutzer muss den Schlüssel explizit über die DD-CLI oder -Benutzeroberfläche löschen.

Frage: Kann ein Schlüssel gelöscht werden, auch wenn ihm Daten auf dem Data Domain-System zugeordnet sind?
Antwort: Nein, wenn einem Schlüssel Daten zugeordnet sind, kann er nicht gelöscht werden. Eine erneute Verschlüsselung von Daten ist mit einem anderen Schlüssel erforderlich, um einen Schlüssel zu löschen, dem Daten zugeordnet sind.

Frage: Wenn ein Schlüssel auf der KMIP gelöscht wird, wird er dann auch aus der Schlüsselliste von Data Domain gelöscht?
Antwort: Nein, der Nutzer muss den Schlüssel mithilfe der DD-CLI oder -Benutzeroberfläche separat löschen.

Frage: Ist in einer Data Domain-Umgebung mit mehreren Standorten an jedem Standort ein KMIP erforderlich?
Antwort: Nein, es ist nicht notwendig, an jedem Standort mit einer Data Domain eine KMIP zu haben. Wir können auf einen KMIP-Server verweisen. Es wird empfohlen, eine separate Schlüsselklasse für jedes DD-System zu verwenden, wenn sie denselben KMIP-Server verwenden.

Frage: Haben wir einen Prozess, um die mit dem alten Schlüssel verschlüsselten Daten abzurufen, wenn ein Schlüssel kompromittiert ist?
Antwort: In diesem Fall muss der Kunde den Schlüssel im KMIP-Server als kompromittiert markieren. Führen Sie dann "filesys encryption keys sync" im DDOS-System aus und führen Sie dann "filesys encryption apply-changes" und dann GC (filesys clean) aus. Bei der GC-Ausführung werden alle Daten, die mit dem kompromittierten Schlüssel verschlüsselt wurden, mit einem neueren Schlüssel erneut verschlüsselt. Sobald GC abgeschlossen ist, wird der Schlüsselstatus in "compromised-destroyed" geändert. Später können sie diesen Schlüssel löschen. 

Verschlüsselung und Replikation

Frage: Wird DD Replication unterstützt und ist die Lösung mit der DD Encryption-Softwareoption interoperabel?
Antwort: Ja, DD Replication kann mit der Option "DD Encryption" verwendet werden, wodurch verschlüsselte Daten mit allen verschiedenen Replikationsarten repliziert werden können. Jede Replikationsform arbeitet auf einzigartige Weise mit Verschlüsselung und bietet das gleiche Maß an Sicherheit.

Frage: Müssen auf dem Quell- und Zielsystem dieselbe Version des DD OS ausgeführt werden, damit die Verschlüsselung verwendet werden kann?
Antwort: Quelle und Ziel können unterschiedliche DDOS-Versionen aufweisen, um DARE mit der Replikation zu verwenden, wenn eine Replikationskompatibilitätsmatrix (siehe Administratorhandbuch für die Kompatibilitätsmatrix) vorhanden ist. 

Frage: Wie funktioniert die Replikation mit Verschlüsselung?
Antwort: Es hängt davon ab, welche Form der Replikation verwendet wird.

Wenn es sich bei der konfigurierten Replikation um MREPL oder MFR handelt:
Wenn MREPL oder MFR verwendet wird, kann die DD-Verschlüsselung je nach den vom Kunden gewünschten Zielen unabhängig auf der Quelle oder dem Ziel lizenziert oder aktiviert werden.

• Wenn sowohl die Quelle als auch das Ziel verschlüsselt sind: Wenn Daten in das Quellsystem aufgenommen werden, werden sie mit dem Chiffrierschlüssel des Quellsystems verschlüsselt. Die Quelle entschlüsselt die lokalen Daten, verschlüsselt sie erneut mit dem Chiffrierschlüssel des Zielsystems und repliziert die verschlüsselten Daten dann bei der Replikation auf das Ziel.
• Wenn die Verschlüsselung für die Quelle deaktiviert und für das Ziel die Verschlüsselung aktiviert ist: Alle Daten, die in die Quelle aufgenommen werden, werden (aus offensichtlichen Gründen) nicht verschlüsselt. Bei der Replikation verschlüsselt die Quelle die Daten jedoch mit dem Chiffrierschlüssel des Zielsystems und repliziert die verschlüsselten Daten dann auf das Zielsystem. 
• Wenn für die Quelle die Verschlüsselung aktiviert und für das Ziel die Verschlüsselung deaktiviert ist: Alle Daten, die in das Quellsystem aufgenommen werden, werden mit dem Chiffrierschlüssel des Quellsystems verschlüsselt. Die Quelle entschlüsselt die Daten und repliziert die unverschlüsselten Daten dann bei der Replikation auf das Data Domain-Zielsystem.
• Wenn die Verschlüsselung auf dem Replikat aktiviert wird, nachdem der Replikationskontext eingerichtet wurde, werden alle neuen Segmente, die jetzt repliziert werden, an der Quelle für das Replikat verschlüsselt. Alle Segmente, die sich vor der Aktivierung der Verschlüsselung auf dem Replikat befinden, bleiben in einem unverschlüsselten Zustand, es sei denn, die Verschlüsselung wendet Änderungen an und GC wird auf dem Ziel ausgeführt. 

Wenn die Replikation CREPL ist:
Bei der Sammelreplikation muss auf Quell- und Zielsystemen dieselbe DDOS-Version ausgeführt werden. Daher muss die Verschlüsselung auf beiden entweder aktiviert oder deaktiviert sein. Auch bei der Verschlüsselungskonfiguration darf es keine Nichtübereinstimmung geben. Verschlüsselungsschlüssel sind für Quelle und Ziel identisch. 

• Wenn sowohl die Quelle als auch das Ziel verschlüsselt sind: Alle Daten, die in das Quellsystem aufgenommen werden, werden mit dem Chiffrierschlüssel des Quellsystems verschlüsselt. Bei der Replikation sendet die Quelle verschlüsselte Daten im verschlüsselten Zustand an das Data Domain-Zielsystem. Das Data Domain-Zielsystem hat denselben Schlüssel wie die Quelle, da es bei der Sammelreplikation um ein exaktes Replikat des Data Domain-Quellsystems geht. Außerhalb der Replikation können keine Daten auf das Data Domain-Zielsystem geschrieben werden, da das Ziel ein schreibgeschütztes System ist.
• Wenn sowohl Quelle als auch Ziel die Verschlüsselung deaktiviert haben: Alle Daten, die in das Quellsystem aufgenommen werden, sind (aus offensichtlichen Gründen) nicht verschlüsselt. Bei der Replikation sendet (repliziert) die Quelle die Daten in einem unverschlüsselten Zustand und sie bleiben auf dem Data Domain-Zielsystem unverschlüsselt. Außerhalb der Replikation können keine Daten auf das Data Domain-Zielsystem geschrieben werden, da das Ziel ein schreibgeschütztes System ist.

Frage: Wird der Schlüssel des Ziels auf dem Data Domain-Quellsystem für unbestimmte Zeit gespeichert?
Antwort: Der Verschlüsselungsschlüssel des Ziels wird niemals auf dem Data Domain-Quellsystem gespeichert. Sie werden nur im Arbeitsspeicher gehalten (verschlüsselt), während die Replikationssitzung aktiv ist. Dies gilt für alle Replikationsarten mit Ausnahme der Sammelreplikation. Bei der Sammelreplikation (CREPL) ist derselbe Satz von Verschlüsselungsschlüsseln in Quelle und Ziel vorhanden.  

Frage: Kann die Verschlüsselung im CREPL-System aktiviert werden, nachdem der Replikationskontext eingerichtet wurde?
Antwort: Ja, in diesem Fall muss die Verschlüsselung sowohl in der Quelle als auch im Ziel aktiviert werden. Die Verschlüsselung kann in Quelle und Ziel aktiviert werden, indem der Replikationskontext deaktiviert wird. Alle neu replizierten Segmente werden auf dem Replikat verschlüsselt. Alle Segmente, die sich vor der Aktivierung der Verschlüsselung auf dem Replikat befinden, verbleiben in einem unverschlüsselten Zustand.

Frage: Kann DD Encryption gleichzeitig mit der Over-the-Wire-Verschlüsselungsfunktion in der Softwareoption DD Replication aktiviert werden?
Antwort: Ja, sowohl die Übertragungsverschlüsselung als auch D@RE können gleichzeitig aktiviert werden, um unterschiedliche Sicherheitsziele zu erreichen.

Frage: Was geschieht, wenn sowohl die DD Encryption-Softwareoption als auch die Übertragungsverschlüsselungsfunktion in der DD Replication-Softwareoption gleichzeitig aktiviert sind?
Antwort: Die erste Quelle verschlüsselt Daten mit dem Zielverschlüsselungsschlüssel. Dann werden bereits verschlüsselte Daten ein zweites Mal verschlüsselt, da diese Daten beim Senden dieser Daten an ihr Ziel durch eine Over-the-Wire-Verschlüsselung verschlüsselt werden. Nachdem die Entschlüsselung über das Kabel durchgeführt wurde, werden die Daten am Ziel in einem verschlüsselten Format gespeichert, das mit dem Chiffrierschlüssel des Ziels verschlüsselt wurde.

Frage: Wenn die Verschlüsselung in Quelle und Ziel aktiviert ist, muss die Passphrase auf beiden identisch sein?
Antwort: Wenn es sich bei der konfigurierten Replikation um eine Sammelreplikation (CREPL) handelt, muss die Passphrase identisch sein. Bei anderen Replikationsarten (z. B. MREPL, MFR) kann sich die Passphrase in Quelle und Ziel unterscheiden.

Frage: Werden bei aktivierter Verschlüsselung auf dem Ziel (Frage gilt nicht für CREPL) sowohl die replizierten Daten als auch Daten von einem anderen Zugriffspunkt (z. B. über lokale Backups) verschlüsselt? Gibt es eine Möglichkeit, die beiden auf dem Replikat zu trennen, wobei nur die replizierten Verzeichnisse verschlüsselt werden, während der andere Zugriff nicht verschlüsselt wird?
Antwort: Nein, alle Daten werden unabhängig vom Einstiegspunkt auf dem Replikat (Ziel) verschlüsselt. Die Verschlüsselung kann nicht nur auf MTree- oder Verzeichnisebene aktiviert oder deaktiviert werden. 

Frage: Wie erfolgt der Schlüsselaustausch zwischen Quelle und Ziel während MREPL oder MFR?
Antwort: Während der Zuordnungsphase der Replikation überträgt der Zielcomputer den aktuellen Verschlüsselungsalgorithmus und die Schlüsselinformationen sicher an die Quelle. Replikationskontexte werden immer mit einem gemeinsamen geheimen Schlüssel authentifiziert. Dieser gemeinsame geheime Schlüssel wird verwendet, um einen "Sitzungsschlüssel" mithilfe eines Diffie-Hellman-Schlüsselaustauschprotokolls einzurichten. Dieser Sitzungsschlüssel wird verwendet, um den Chiffrierschlüssel des Data Domain-Systems zu verschlüsseln und zu entschlüsseln.

Frage: Welche Art von Verschlüsselungsalgorithmus wird für die Data Domain-Funktion "Verschlüsselung über Leitung" in Bezug auf die Verschlüsselung des Replikationsdatenverkehrs verwendet?
Antwort: Wenn der Replikationsauthentifizierungsmodus auf "one-way" oder "two-way" eingestellt ist, wird DHE (Ephemeral Diffie-Hellman) für den Austausch von Sitzungsschlüsseln verwendet. Die Serverauthentifizierung erfolgt mithilfe von RSA. Die AES-256-Bit-GCM-Verschlüsselung wird verwendet, um die replizierten Daten über die Leitung zu kapseln. Die Verschlüsselungskapselungsschicht wird sofort entfernt, wenn sie auf dem Zielsystem landet. 

Eine Methode gibt an, dass nur das Zielzertifikat zertifiziert ist. Es gibt zwei Möglichkeiten, anzugeben, dass sowohl die Quell- als auch die Zielzertifikate überprüft werden. Es muss gegenseitiges Vertrauen hergestellt werden, bevor Sie den Authentifizierungsmodus verwenden können, und beide Seiten der Verbindung müssen diese Funktion aktivieren, damit die Verschlüsselung fortgesetzt werden kann.

Wenn der Replikationsauthentifizierungsmodus auf "anonymous" festgelegt ist, wird Anonymous Diffie-Hellman (ADH) für den Austausch von Sitzungsschlüsseln verwendet, aber in diesem Fall authentifizieren sich Quelle und Ziel vor dem Schlüsselaustausch nicht gegenseitig. Wenn der Authentifizierungsmodus nicht angegeben ist, wird standardmäßig anonym verwendet.

Frage: Funktioniert die Schlüsselrotation ohne Dateisystemneustart mit allen Arten von Replikation?
Antwort: Die Schlüsselrotation ohne Dateisystemneustart funktioniert mit allen Arten von Replikationen außer DREPL (DREPL Support wurde bereits beendet) und Delta-Replikation (auch bekannt als LBO)

Frage: Wie wird der Verschlüsselungsschlüssel des Ziels während des Schlüsselaustauschs geschützt, wenn keine Zertifikate oder PKI-Schlüsselpaare vorhanden sind?
Antwort: Es gibt einen gemeinsamen geheimen Schlüssel für alle Data Domain-Replikationspaare, der verwendet wird, um einen gemeinsamen Sitzungsschlüssel mithilfe eines Diffie-Hellman-Schlüsselaustauschs einzurichten. Dieser gemeinsam verwendete Schlüssel wird verwendet, um den Verschlüsselungsschlüssel des Ziels zu verschlüsseln.

Es besteht ein Unterschied zwischen dem gemeinsamen geheimen Schlüssel, der für die Replikationsauthentifizierung verwendet wird, und dem gemeinsam genutzten Sitzungsschlüssel, der mithilfe des Diffie-Hellman-Schlüsselaustauschprotokolls zugewiesen wird. Der gemeinsame geheime Schlüssel, der für die Replikationsauthentifizierung verwendet wird, wird von der Data Domain-Software eingerichtet, wenn zwei Data Domain-Systeme zum ersten Mal einen Replikationskontext einrichten möchten. Es wird auch durch einen Diffie-Hellman vereinbart, der mit im Code eingebetteten Parametern ausgetauscht wird. Diese werden dauerhaft in den Systemen gespeichert, um jede Replikationssitzung zwischen den beiden Systemen zu authentifizieren. Der Schlüssel für die Replikationssitzung (der Schlüssel, der verwendet wird, um den Verschlüsselungsschlüssel des Ziels zu verschlüsseln) wird mithilfe eines anderen Diffie-Hellman-Austauschs mit dem zuvor festgelegten gemeinsamen geheimen Schlüssel eingerichtet, wodurch das sichere Schlüsselaustauschprotokoll gesteuert wird. Dieser Schlüssel ist nicht persistent und nur verfügbar, solange der Replikationskontext aktiv ist.

Frage: Ist es erforderlich, dass beide Data Domains eines Replikationspaars dieselbe externe Key-Manager-Lösung (wie KMIP Key Manager) verwenden, oder kann eines der Systeme einen externen Key-Manager und ein anderes einen integrierten Key Manager verwenden?
Antwort: Abgesehen von einem Sammelreplikationspaar ist es nicht erforderlich, dass beide Systeme innerhalb eines Replikationspaars denselben Key Manager verwenden.

Bei der Sammelreplikation müssen beide Data Domain-Systeme mit demselben Key Manager konfiguriert werden. Aber auch in diesem Fall ist die einzige Quelle die Synchronisierung der Schlüssel mit dem Key Manager. Diese Schlüssel werden ebenfalls an das Ziel gesendet. Bei anderen Replikationstypen können verschiedene Key Manager mit Quelle und Ziel verwendet werden.

Verschlüsselung und Migration

Frage: Wird die Datenmigration auf Systemen mit aktivierter Verschlüsselung unterstützt?
Antwort: Ja, die Datenmigration wird auf Systemen mit aktivierter Verschlüsselung unterstützt. Die Verschlüsselungskonfiguration auf Quell- und Zielsystemen muss als Voraussetzung übereinstimmen, bevor die Datenmigration initiiert wird. Es wird außerdem empfohlen, Verschlüsselungsschlüssel zu DIA-Zwecken auf dem Quellsystem zu exportieren und zu sichern, bevor die Migration initiiert wird.

Frage: Wird die Datenmigration sowohl für die aktive Tier- als auch für die Cloud-Tier-Migration für Systeme mit aktivierter Verschlüsselung unterstützt?
Antwort: Ja, die Datenmigration wird sowohl für die aktive Tier- als auch für die Cloud-Tier-Migration für Systeme mit aktivierter Verschlüsselung unterstützt. Die Liste der geprüften Voraussetzungsattribute wird basierend auf dem Tier angewendet, für den Verschlüsselung aktiviert ist.

Frage: Welche Verschlüsselungseinstellungen werden im Rahmen der Migration beibehalten?
Antwort: Verschlüsselte Daten und Verschlüsselungsschlüssel werden unverändert migriert, Einstellungen wie Encryption Key Manager, System-Passphrase und andere Verschlüsselungskonfigurationen müssen jedoch manuell überprüft und für eine erfolgreiche Datenmigration abgeglichen werden. Alle vorhandenen Key-Manager-Zertifikate werden ebenfalls an das Zielsystem übertragen. Die Encryption Key Manager-Konfiguration muss nach der Migration auf dem Zielsystem erneut eingerichtet werden.

Frage: Welche Verschlüsselungskompatibilitätsprüfungen werden zwischen Quelle und Ziel während der Migration durchgeführt?
Antwort: Zu den Verschlüsselungseinstellungen, die auf Quell- und Zielsystemen identisch sein müssen, damit die Migration erfolgreich ist, sind Systempassphrase, Verschlüsselungsstatus und Schlüssel-Manager-Konfigurationsdetails, System-FIPS-Moduseinstellungen. Dieser Wissensdatenbank-Artikel 183040, Data Domain: Das Migrationsverfahren für Cloud-fähige DD-Systeme (Anmeldung beim Dell Support erforderlich, um den Artikel anzuzeigen) beschreibt die Schritte für die Migration zwischen Systemen mit Cloud-Funktion. Die gleichen Einstellungen gelten auch für die Migration nur des aktiven Tiers.

Frage: Wird die Migration zwischen Systemen unterstützt, auf denen das Encryption Disablement Project aktiviert ist?
Antwort: Die Datenmigration zwischen zwei Systemen wird unterstützt, wenn entweder beide EDP- oder Nicht-EDP-Systeme sind. Die Datenmigration von einem EDP-System zu einem Nicht-EDP-System ist zulässig, wenn die On-the-Wire-Verschlüsselung explizit deaktiviert ist. (unter Verwendung des MIGRATION_ENCRYPTION sysparam)

Verschlüsselung in Cloud Tier 

Frage: Wird Verschlüsselung für Cloud-Tier unterstützt?
Antwort: Ja, die Verschlüsselung wird auf Cloud-Tier unterstützt. Standardmäßig ist die Verschlüsselung im Cloud-Tier deaktiviert. "Cloud Enable"-Eingabeaufforderungen, um auszuwählen, ob die Verschlüsselung auf dem Cloud-Tier aktiviert werden soll.

Frage: Werden KMIP und externe Key Manager von Cloud-Tier unterstützt?
Antwort: Ja, KMIP und externe Key Manager werden mit Cloud-Tier ab DDOS 7.8 unterstützt.

Frage: Mit welcher Granularität kann die Verschlüsselung in der Cloud aktiviert werden?
Antwort: Die Verschlüsselung kann für jede Cloudeinheit und jeden Tier unabhängig voneinander aktiviert und deaktiviert werden.

Frage: Haben Cloudeinheiten unabhängige Schlüssel?
Antwort: Nein, das Key-Management ist für aktive und Cloud-Tiers in DD gleich. Schlüssel werden auf die entsprechende Einheit/Ebene/CP kopiert, wenn die Verschlüsselung aktiviert ist. Wenn die Verschlüsselung in der aktiven und nicht in der Cloud aktiviert ist, werden die aktiven Tier-Schlüssel nicht in der Cloud angezeigt und umgekehrt. Dies gilt auch für die Cloud-Einheiten. (Beispiel: Wenn für CP1 Verschlüsselung aktiviert ist und für CP2 keine Verschlüsselung aktiviert ist, werden CP1-Schlüssel nicht auf CP2 angezeigt.)   

Frage: Können Schlüssel in der Cloud gelöscht werden?
Antwort: Nein, das Löschen von Schlüsseln aus der Cloud wird nicht unterstützt.

Frage: Wo werden Datenverschlüsselungsschlüssel für Cloudeinheiten verwaltet?
Antwort: Schlüssel sind einem CP zugeordnet und jede Cloudeinheit ist ein anderer CP. Eine Kopie der Schlüssel von allen CPs wird im aktiven CP gespeichert.

Frage: Wie stellen wir Cloud-Schlüssel während der Disaster Recovery wieder her? 
Antwort: cpnameval wird im Rahmen der CP-Recovery in die Cloud gespiegelt. Die Verschlüsselungsschlüssel werden auf cpnameval wiederhergestellt. Jetzt müssen wir ddr_key_util Tool ausführen, um die Schlüssel wiederherzustellen.

Hinweis: Disaster Recovery erfordert das Eingreifen des Kundensupports.

Frage: Können wir eine Datenverschiebung durchführen, wenn die Verschlüsselung nur im Cloud-Tier aktiviert ist?
Antwort: Nein, wir müssen die Verschlüsselung sowohl in Cloud- als auch in aktiven Tiers für die Datenverschiebung aktivieren.

Frage: Können wir den externen Key-Manager auf Cloud-Tier aktivieren?
Antwort: Ja, der externe Key Manager kann auf Cloud-Tier aktiviert werden. Diese Funktion wird ab 7.8 unterstützt. Alle Vorgänge außer dem Löschen oder Löschen des Schlüssels, der für den aktiven Tier gültig ist, sind auch für den Cloud-Tier in Bezug auf den externen Key Manager gültig. 

Verschlüsselung und automatische Speicherbereinigung

Frage: Welche Rolle spielt der globale Bereinigungsprozess bei der Verschlüsselung im Ruhezustand und wirkt sich die Aktivierung der Verschlüsselung zum ersten Mal auf die Leistung aus?
Antwort: Die erstmalige Aktivierung der Data-at-Rest-Verschlüsselung wirkt sich auf die Performance der globalen Bereinigung aus. Dies liegt daran, dass Daten, die aus vorhandenen Containern auf der Festplatte gelesen und in neue Container geschrieben werden müssen, möglicherweise gelesen, entschlüsselt und dekomprimiert werden müssen, bevor sie erneut komprimiert, verschlüsselt und wieder auf die Festplatte geschrieben werden können. Wenn die Verschlüsselung auf einem DD-System aktiviert ist, das eine erhebliche Menge an bereits vorhandenen Daten enthält, und der Befehl "filesys encryption apply-changes" ausgeführt wird, versucht der nachfolgende globale Bereinigungszyklus, alle vorhandenen Daten auf dem System zu verschlüsseln. Das bedeutet, dass alle Daten gelesen, dekomprimiert, komprimiert, verschlüsselt und auf die Festplatte geschrieben werden müssen. Infolgedessen kann der erste globale Bereinigungszyklus nach dem Ausführen von "filesys encryption apply-changes" länger als normal dauern. Kunden sollten sicherstellen, dass ausreichend freier Speicherplatz auf ihrem DD-System vorhanden ist, damit die Bereinigung abgeschlossen werden kann, ohne dass das DD-System voll wird (andernfalls schlagen Backups fehl).

Frage: Gibt es Auswirkungen auf die Performance, wenn die laufenden Bereinigungszyklen für die Aufnahme und Wiederherstellung laufen?
Antwort: Ja, es gibt Auswirkungen auf die Performance, und die Auswirkungen hängen im Allgemeinen von der Menge der Daten ab, die zwischen den Bereinigungszyklen aufgenommen/wiederhergestellt werden.

Frage: Wie lange dauert es, meine vorhandenen Daten zu verschlüsseln?
Verwenden Sie diesen Wissensdatenbank-Artikel, um die Zeit für Data Domain zu schätzen: Es wird berechnet, wie lange die Anwendung der Verschlüsselung im Ruhezustand dauert.

Verschlüsselung und Headswap 

Frage: Kann der Kunde die Festplatte in ein anderes Data Domain-System verschieben, wenn ein Head ausfällt, und auf die Festplatte zugreifen, wenn die Verschlüsselung aktiviert ist?
Antwort: Der Verschlüsselungsschlüssel ist nicht an den Data Domain-Systemkopf selbst gebunden, sodass Sie die Festplatten auf einen anderen Data Domain-Systemkopf verschieben können und dort auf den Schlüssel zugreifen kann. Auf einem neuen Data Domain-Systemkopf ist das Dateisystem gesperrt, sodass Sie die Passphrase mit dem Befehl "filesys encryption unlock" eingeben müssen. 

Frage: Was passiert, wenn ein Kunde die Passphrase zum Zeitpunkt des Headswap-Vorgangs vergessen hat?
Antwort: Während dieser Zeit können sie den alten Head verbinden und mit dem Support zusammenarbeiten, um die Passphrase zurückzusetzen, dann wieder eine Verbindung zum neuen Head herstellen und den Headswap-Vorgang abschließen. 

Verschlüsselungsperformance

Frage: Welche Auswirkungen wird bei Verwendung von Verschlüsselung auf den Speicherverbrauch beobachtet?
Antwort: Er ist mit etwa 1 Prozent Overhead im Zusammenhang mit der Speicherung einiger Verschlüsselungsparameter mit Nutzerdaten vernachlässigbar.

Frage: Welche Auswirkungen wird auf den Durchsatz (Schreib- und Lesevorgänge) beobachtet, wenn Data-at-Rest-Verschlüsselung verwendet wird?
Antwort: Die Auswirkungen auf den Aufnahmedurchsatz bei Verwendung der Verschlüsselung können je nach Protokoll und Plattform variieren. Im Allgemeinen handelt es sich bei den folgenden Prozentsätzen um konservative Performanceverschlechterungen im Verhältnis zum aggregierten Durchsatz:

CBC-Modus
Erstes voll: ~10 % Performanceverschlechterung bei Schreibvorgängen
Inkrementell: ~5 % Performanceverschlechterung bei WRITE-Wiederherstellungen
: 5 - 20 % Leistungsverschlechterung bei Lesevorgängen

GCM-Modus
Erste vollständige Prüfung: 10 bis 20 % Performanceverschlechterung bei WRITEs
Inkrementell: 5 bis 10 % Performanceverschlechterung bei WRITE-Wiederherstellungen
: 5 bis 20 % Leistungseinbußen bei Lesevorgängen

Diese Zahlen beziehen sich spezifisch auf den Overhead der Data-at-Rest-Verschlüsselung (die Verschlüsselung über das Internet wird separat berechnet)
 

Best Practices

Frage: Was sind Best Practices in Bezug auf die Policy für die Schlüsselrotation?
Antwort: Die Policy für die automatisierte Schlüsselrotation ist standardmäßig nicht aktiviert. Der Kunde hat sie aktiviert. Es wird empfohlen, Verschlüsselungsschlüssel häufig zu rotieren. Wenn ein System mit einem externen KMIP-Key-Manager konfiguriert ist, ist es ratsam, die Schlüssel häufig zu rotieren, um zukünftige Key-Compromise-Szenarien zu bewältigen. Wenn KMIP mit Cloud-Tier konfiguriert ist, beträgt das vorgeschlagene Schlüsselrotationsintervall 1 Woche. Wenn KMIP nur im aktiven Tier konfiguriert ist, beträgt die vorgeschlagene Policy für die Schlüsselrotation 1 Monat. Basierend auf der Aufnahmerate kann der Kunde jedoch auch die Schlüsselrotationsfrequenz erhöhen oder verringern. Wenn der integrierte Key Manager konfiguriert ist, wird eine Policy für die Schlüsselrotation zwischen 1 und 3 Monaten empfohlen. 

Frage: Was sind Best Practices für die KMIP-Schlüsselklasse, wenn ein Kunde denselben KMIP-Server für viele DD-Systeme verwendet?
Antwort: Es wird empfohlen, eine separate Schlüsselklasse für jedes DD-System zu verwenden, wenn sie denselben KMIP-Server verwenden. Auf diese Weise hat die Schlüsselrotation, die in einem DDOS-System durchgeführt wird, keine Auswirkungen auf den Status des Schlüssels, der in einem anderen DDOS-System vorhanden ist.

Weitere Informationen finden Sie im Dokument Appliances der Dell EMC PowerProtect DD-Serie: Verschlüsselungssoftware (delltechnologies.com)

Verschlüsselung: Technisches Whitepaper Appliances der PowerProtect DD Serie: Verschlüsselungssoftware

Weitere Dokumentation zur DD-Verschlüsselung (Administratorhandbuch, Befehlsreferenzhandbuch und Sicherheitskonfigurationshandbuch) finden Sie in Artikel 126375 sowie in den Kerndokumenten zu PowerProtect und Data Domain.

KMIP-Integrationshandbuch und Kompatibilitätsmatrix

Sehen Sie sich dieses Video an: