Data Domain: Häufig gestellte Fragen zur Verschlüsselung

Zusammenfassung: Dieser Wissensdatenbank-Artikel enthält eine Sammlung häufig gestellter Fragen (FAQs) zur Data Domain-Data-at-Rest-Verschlüsselung (DARE) an einem konsolidierten Speicherort, um das Nachschlagen zu erleichtern. ...

Betroffene Produkte

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Andere Ressourcen ansehen

Weisungen

Verschlüsselungskonfiguration

Frage: Wie wird die Data-at-Rest-Verschlüsselung (DARE) in Data Domain konfiguriert?

Antwort: DARE kann mit den folgenden Schritten konfiguriert werden:

Fügen Sie eine Verschlüsselungslizenz hinzu.
1. Halten Sie eine Lizenzdatei mit einer gültigen Encryption-Lizenz bereit.
2. Verwenden Sie den folgenden Befehl, um die E-Lizenz in der Data Domain mithilfe der verfügbaren Lizenzdatei zu aktualisieren:
```
# elicense update
```
Fügen Sie einen Security Officer hinzu und aktivieren Sie die Security Officer-Autorisierungen.
1. Fügen Sie einen Nutzer mit der Rolle "security" (falls noch nicht vorhanden) mithilfe des Befehls hinzu:
```
# user add <username> role security
```
2. Aktivieren Sie die Security Officer-Autorisierung, indem Sie sich als Security Officer anmelden und den folgenden Befehl ausführen:
```
> authorization policy set security-officer enabled
```
Wechseln Sie zurück zu einem Administratorkonto und aktivieren Sie DARE, indem Sie den folgenden Befehl ausführen:
```
# filesys encryption enable
```

Frage: Welche Plattformen werden von DARE unterstützt?

Antwort: Die DARE-Funktion wird auf allen Data Domain-Systemen unterstützt, mit Ausnahme von EDP-Systemen (Encryption Disablement Project).

Frage: Wie kann ich Daten im Klartext auf der Data Domain speichern?

Antwort: Nutzer können sicherstellen, dass die Daten im Klartext gespeichert und nicht in der Data Domain verschlüsselt werden, indem sie bestätigen, dass die Verschlüsselung im Setup deaktiviert ist.

Die Verschlüsselung kann in Data Domain mithilfe des folgenden Befehls deaktiviert werden:

# filesys encryption disable

Frage: Welche Backupanwendungen und -protokolle werden von DARE unterstützt?

Antwort: Die DARE-Funktion ist unabhängig von der zugrunde liegenden Backupanwendung oder dem Protokoll, das von Data Domain verwendet wird.

Frage: Welche Verschlüsselungsalgorithmen können verwendet werden?

Antwort: Die Data Domain-Verschlüsselungssoftware unterstützt AES-Algorithmen mit 128 oder 256 Bit unter Verwendung von CBC (Cipher Block Chaining) oder GCM (Galois Counter Mode).

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 Nur-Text-Block exklusiv mit dem vorherigen Chiffre-Textblock verschlüsselt, bevor er verschlüsselt wird. 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 kann der Verschlüsselungsalgorithmus geändert werden?

Antwort: Verwenden Sie den folgenden Befehl, um einen bestimmten Verschlüsselungsalgorithmus festzulegen:

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

Frage: Wie stelle ich 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 erzwingen, dass das Data Domain-Dateisystem die bereits vorhandenen Daten verschlüsselt:

# filesys encryption apply-changes

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

Frage: Wie deaktiviere ich die Verschlüsselung?

Antwort: Deaktivieren Sie die Verschlüsselungsfunktion in Data Domain mit dem folgenden Befehl:

# filesys encryption disable

Dadurch wird nur die Verschlüsselung für eingehende Daten deaktiviert. Vorhandene verschlüsselte Daten bleiben verschlüsselt, bis sie manuell mit dem Befehl "filesys encryption apply-changes'.

Frage: Bei welchen Verschlüsselungsbefehlen ist ein Neustart des Dateisystems erforderlich, um wirksam zu werden?

Antwort: Für die folgenden Verschlüsselungsbefehle ist ein Neustart des Dateisystems erforderlich, um wirksam zu werden:

filesys encryption enable|disable - Aktiviert oder deaktiviert die Verschlüsselung auf der Data Domain.
filesys encryption algorithm set - Ermöglicht dem Benutzer die Auswahl eines kryptografischen Algorithmus.
filesys encryption algorithm reset - Setzt den Verschlüsselungsalgorithmus im CBC-Modus auf AES 256 zurück (Standardeinstellung).

Frage: Welche Verschlüsselungsbefehle erfordern eine Deaktivierung des Dateisystems, um sie festzulegen oder zu verwenden?

Antwort: Das Data Domain-Dateisystem muss deaktiviert sein, um die folgenden Verschlüsselungsbefehle festzulegen oder zu verwenden:

encryption passphrase change
encryption lock|unlock

Allgemeine Fragen zur Verschlüsselung

Frage: Wird DARE auf allen Data Domain-Systemen unterstützt?

Antwort: Die DARE-Softwareoption wird auf Data Domain-Systemen unterstützt, die nicht Teil des Encryption Disablement Project (EDP) sind. Diese Systeme erlauben keine Aktivierung der Verschlüsselung und werden hauptsächlich in der Region Russland verkauft.

Frage: Wie wird Kryptografie auf Data Domain-Systemen durchgeführt?

Antwort: Die Verschlüsselung erfolgt mithilfe der OpenSSL- und RSA-BSafe-Bibliotheken. RSA BSafe ist eine nach FIPS 140-2 validierte Kryptografiebibliothek.

Frage: Welche Version von BSafe wird von Data Domain verwendet?

Antwort: Ab DDOS 7.10 sind die verwendeten BSafe-Versionen "BSAFE Micro Edition Suite 4.4.0.0“ als auch „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 Befehlszeile, die Weboberfläche oder mithilfe von REST APIs konfiguriert werden. REST API-Unterstützung wurde in 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. Bei Systemen mit Cloud-Unterstützung kann die Verschlüsselung auf Ebene des Cloud-Tier und der Cloudeinheit 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 verwendet Data Domain?

Antwort: Ab DDOS 7.10 lautet die OpenSSL-Version "OpenSSL 1.0.2zd-fips“.

Frage: Wie schützt DARE vor Datenzugriffen 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 die Data Domain, aber alle Daten, die sich physisch auf der Data Domain 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.
Die Data Domain-Verschlüsselung ist so konzipiert, dass, wenn ein Eindringling andere Netzwerksicherheitskontrollen umgeht und Zugriff auf verschlüsselte Daten erhält, die Daten für diese Person ohne die richtigen kryptografischen Schlüssel 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 DARE-Funktion 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 dem System keine weiteren Schlüssel 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 die System-Passphrase geändert wird

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 Erfassungspartition im DDOS gespeichert.

Frage: Wenn jemand eine Festplatte aus einer Data Domain herauszieht, kann er dann Daten daraus 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 sind, können Chiffrierschlüssel nicht ohne die System-Passphrase 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 mit dem Befehl "keys export" verwendet wurde.

Frage: Wie kann das Dateisystem gesperrt werden, bevor es an einen anderen Speicherort verschoben wird?

Antwort: Im Folgenden finden Sie das Verfahren zum Sperren des Systems:

Deaktivieren Sie das Dateisystem:
```
# filesys disable
```
Sperren Sie das Dateisystem und geben Sie eine neue Passphrase ein (dies erfordert die Authentifizierung durch einen Sicherheitsnutzer):
```
# filesys encryption lock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the current passphrase:
Enter new passphrase:
Re-enter new passphrase:
Passphrases matched.
The filesystem is now locked.
```
1. Die neue Passphrase darf NICHT verloren gehen oder vergessen werden. Ohne diese Passphrase kann das Dateisystem nicht entsperrt werden, was bedeutet, dass auf die Daten in der Data Domain nicht zugegriffen werden kann.

Verwenden Sie den folgenden Befehl, um das System zu entsperren, wenn es einen Remotestandort erreicht:

# filesys encryption unlock
This command requires authorization by a user having a 'security' role.
Please present credentials for such a user below.
        Username: secuser
        Password:
Enter the passphrase:
The passphrase has been verified. Use 'filesys enable' to start the filesystem.

Das Dateisystem kann jetzt aktiviert und wie gewohnt verwendet werden.

Frage: Wird die '`storage sanitize`Haben Sie eine Beziehung zur Dateisystemverschlüsselung?

Antwort: Nein, Dateisystemverschlüsselung und Storage-Bereinigung sind zwei unabhängige Funktionen.

Frage: Wird die Over-the-Wire-Verschlüsselung für EDV-Systeme unterstützt?

Antwort: DARE und Over-the-Wire-Verschlüsselung werden für EDP-Systeme nicht unterstützt.

System-Passphrase

Frage: Was ist die System-Passphrase?

Antwort: DDOS ist in der Lage, Anmeldedaten innerhalb des Systems zu sichern, indem eine Passphrase auf Systemebene festgelegt wird. Die Passphrase ist ein für Menschen lesbarer Schlüssel wie eine Smartcard, die 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 werden und weiterhin Datenzugriff ohne Eingriff des Administrators bereitstellen.

Erstellen oder Ändern der Passphrase:

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

Frage: Wann wird die Passphrase verwendet?

Antwort: Die Systempassphrase wird von verschiedenen DDOS-Komponenten als Primärschlüssel verwendet, einschließlich Dateisystemverschlüsselung, Cloud-Zugriff, Zertifikatmanagement, DD Boost-Token, Systemkonfigurationsmodulen in Scale-out-Umgebungen und Lizenzierungsinformationen. DDOS bietet Mechanismen zum Festlegen und Ändern dieser System-Passphrase. Sie bietet auch Optionen, mit denen gesteuert werden kann, ob die System-Passphrase auf der Festplatte gespeichert wird, was insbesondere für erhöhte Sicherheit bei der Übertragung der Data Domain verwendet wird.

Frage: Wie wird die Passphrase für den sicheren Transport der Data Domain verwendet?

Antwort: Der Prozess verwendet die 'filesys encryption lock'-Befehl, 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 mithilfe von 'filesys encryption unlock'-Befehl.

Der Prozess wird in den Data Domain-Sicherheitskonfigurationsleitfäden 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 finde ich heraus, ob auf dem System eine Passphrase eingestellt ist?

Antwort: Wenn eine Passphrase auf dem System festgelegt ist, wird die Ausführung des Befehls 'system passphrase set' löst einen Fehler aus, 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 einer verlorenen System-Passphrase?

Antwort: Die System-Passphrase kann nur in bestimmten Szenarien mit Hilfe 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 Details finden Sie in diesem Artikel: Data Domain: Zurücksetzen einer verlorenen System-Passphrase in DDOS v7.2 oder höher (Anmeldung beim Dell Support erforderlich)

Frage: Gibt es eine Option, um das Speichern der Systempassphrase in der Data Domain zu vermeiden?

Antwort: Die Systempassphrase wird standardmäßig an einem versteckten Speicherort auf dem Data Domain-System gespeichert. Der Befehl 'system passphrase option store-on-disk' kann verwendet werden, um dies zu ändern und zu vermeiden, dass die Passphrase auf der Festplatte gespeichert wird.

Integrierter Key Manager (EKM)

Befehl der obersten Ebene:

# filesys encryption embedded-key-manager <option>

Frage: Wird die Schlüsselrotation mit EKM 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. Sie ist als Teil der standardmäßigen Softwarelizenzoption für Data Domain Encryption enthalten.

Frage: Kann ich von lokalem zu externem Key-Management wechseln?

Antwort: Ja, externe Key Manager können jederzeit aktiviert werden. Die verwendeten lokalen Schlüssel verbleiben jedoch auf Data Domain. Externe Key Manager sind nicht in der Lage, die lokalen Schlüssel zu verwalten. Vorhandene Daten müssen nicht erneut verschlüsselt werden. Wenn Compliance-Daten mit EKM-Schlüsseln neu verschlüsselt werden müssen, muss dies manuell mithilfe von 'filesys encryption apply-changes' mit dem neuen RW Taste. Das Löschen von EKM-Schlüsseln nach einem Wechsel ist nicht zwingend erforderlich.

Beim Ändern des Key Managers wird der aktive Schlüssel automatisch auf den Schlüssel von KMIP umgestellt.

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 geschieht, wenn die Schlüsselrotation deaktiviert oder aktiviert wird?

Antwort: Die Schlüsselrotation ist standardmäßig deaktiviert. In diesem Szenario werden alle Daten mit dem vorhandenen aktiven Schlüssel verschlüsselt. Wenn die Schlüsselrotation aktiviert ist, werden die Daten basierend auf der konfigurierten Rotationsfrequenz mit dem neuesten aktiven Schlüssel verschlüsselt.

Externe Key-Manager

Frage: Welche externen Key-Manager werden von Data Domain unterstützt?

Antwort: Data Domain unterstützt 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 einen externen Key Manager in Data Domain zu integrieren.

Frage: Wie viele Key Manager können gleichzeitig eingesetzt werden?

Antwort: Es kann immer nur ein Key Manager in einer Data Domain aktiv sein.

Frage: Wo finde ich weitere Informationen zur Konfiguration von externen KMIP-Key-Managern?

Antwort: Der KMIP-Integrationsleitfaden für DDOS enthält detaillierte Informationen zur Konfiguration der verschiedenen externen Key-Manager, die von Data Domain unterstützt werden.

Frage: Wie werden Zertifikate für externe Key Manager in Data Domain verwaltet?

Antwort: Die Konfiguration des externen Key Managers erfordert die Generierung eines CA-Zertifikats (das selbstsigniert oder von einem Drittanbieter signiert sein kann) und eines Hostzertifikats. Sobald die Konfiguration auf dem externen Key-Manager-Server abgeschlossen ist, müssen das CA-Zertifikat und das Hostzertifikat in das Data Domain-System importiert werden. Anschließend kann der externe Key Manager konfiguriert und aktiviert werden.

Frage: Was ist eine Zertifizierungsstelle?

Antwort: Eine Zertifizierungsstelle (Certificate Authority, CA) fungiert als zunächst vertrauenswürdige freigegebene 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 CA-signiertes Zertifikat? Was ist ein lokales, von einer Zertifizierungsstelle signiertes Zertifikat?

Antwort: Ein CA-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 Dienste innerhalb des Systems verwendet.

Frage: Wie erstelle ich eine Zertifikatsignieranforderung auf einer Data Domain?

Antwort: Eine Data Domain-Zertifikatsignieranforderung (CSR) kann mit dem folgenden Befehl erzeugt werden. Auf diese Weise wird der private Schlüssel niemals für den externen Key-Manager verfügbar gemacht.

# adminaccess certificate cert-signing-request

Frage: Ist es möglich, zwischen Key Managern zu wechseln?

Antwort: Der Wechsel von einem externen Key Manager zum integrierten Key Manager ist zulässig und verläuft nahtlos. Der Wechsel von embedded Key Manager zu externen Key Managern erfordert jedoch eine entsprechende Zertifikatinstallation und -konfiguration. Wechseln zwischen zwei externen Key-Managern (z. B.: KMIP-CipherTrust, DSM-Ciphertrust, CipherTrust an GKLM) ist ebenfalls zulässig. Die Migration von 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 noch zugänglich?

Antwort: Ja, die Daten sind auch dann zugänglich, wenn keine Verbindung zum Key Manager hergestellt werden kann, da auch eine Kopie der Schlüssel in der Data Domain gespeichert ist. Es können keine neuen Schlüssel erstellt und Schlüsselstatus nicht synchronisiert werden, wenn keine Verbindung mit dem externen Key Manager besteht.

Frage: Gibt es eine Möglichkeit, Schlüssel nur im externen Key Manager und nicht in Data Domain zu speichern?

Antwort: Eine Kopie der Schlüssel wird für DIA-Zwecke (Data Invulnerability Architecture) immer im Data Domain-System gespeichert. Diese Einstellung kann nicht geändert werden.

Frage: Hat die Integration mit KMIP Auswirkungen auf die Performance?

Antwort: Nein, die Verwendung externer Key Manager hat keine Auswirkungen auf die Performance.

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 Domains. Sie können weiterhin den integrierten Key Manager von Data Domain auf einigen Systemen und die Rotation des Verschlüsselungsschlüssels mithilfe von KMIP auf anderen 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. Die Data Domain-CLI kann verwendet werden, um das entsprechende X509-Zertifikat in das Data Domain-System zu importieren. Dieses Zertifikat wird dann verwendet, um den sicheren Kanal zwischen Data Domain und KMIP herzustellen.

Schlüssel-Lebenszyklusmanagement

Frage: Welche Schlüsselmanagementfunktionen gibt es bei der Data Domain-Verschlüsselung?

Antwort: Ein Key Manager steuert die Erzeugung, Verteilung und das Lebenszyklusmanagement mehrerer Verschlüsselungsschlüssel. Ein Datenschutzsystem kann entweder den integrierten Key Manager oder einen 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. Ab DDOS 7.1 ist dafür kein Neustart des Dateisystems erforderlich.

Frage: Was sind die verschiedenen Schlüsselstatus auf der Data Domain?

Die verschiedenen Schlüsselstatus auf der Data Domain lauten wie folgt:

Activated-RWverwalten: Es gibt immer nur einen Schlüssel in diesem Zustand auf einer Data Domain, der zum Lesen und Schreiben von Daten verwendet wird. Dieser Schlüssel wird auch vom Prozess zur automatischen Speicherbereinigung verwendet, um Container erneut zu verschlüsseln.
Pending-Activatedverwalten: Es gibt immer nur einen Schlüssel in diesem Zustand auf einer Data Domain. Dies identifiziert den Schlüssel, der zu Activated-RW nach dem nächsten Neustart des Dateisystems. Dieser Status ist nur zum Zeitpunkt der Aktivierung der Verschlüsselung vorhanden. Pending-activated Schlüssel werden zu keinem anderen Zeitpunkt erstellt.
Activated-ROverwalten: Externe Key Manager können über mehrere aktivierte Schlüssel verfügen. Der aktuellste Schlüssel befindet sich in Activated-RW, und der Rest befindet sich in diesem Zustand. Schlüssel können auf der Data Domain in diesen Status wechseln, wenn der Status nicht mit dem Key Manager synchronisiert werden kann.
Deactivatedverwalten: Dies wird zum Lesen vorhandener Daten auf dem Data Domain-System verwendet.
Compromisedverwalten: Wenn ein externer Key-Manager-Schlüssel kompromittiert wird, wechselt er nach der nächsten Schlüsselsynchronisierung in diesen Status.
Marked-For-Destroyedverwalten: Wenn ein Kunde einen Schlüssel für die Vernichtung markiert, ändert sich der Schlüssel in diesen Status. Wenn die automatische Speicherbereinigung ausgeführt wird, werden alle Container, die mit Marked-For-Destroyed Schlüssel werden mithilfe der Activated-RW Taste.
Destroyedverwalten: Ein Schlüssel in der Marked-For-Destroyed Status wechselt in diesen Status, wenn ihm keine Daten zugeordnet sind.
Destroyed-compromisedverwalten: Ein Schlüssel in der Compromised Status 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

Data Domain 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 befinden sich im Ordner /ddr/var/.security Verzeichnis in einem verschlüsselten Format. Diese Datei kann aus der Data Domain kopiert und an einem sicheren Ort gespeichert werden, um sie später in einer Disaster-Recovery-Bedingung zu verwenden.

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.

# filesys encryption keys import <filename>

Frage: Wird der von KMIP generierte Schlüssel in Data Domain gespeichert?

Antwort: Ja, der von der KMIP abgerufene Verschlüsselungsschlüssel wird auf verschlüsselte Weise in Data Domain gespeichert.

Frage: Wie wird eine Schlüsselstatusänderung in der KMIP-Appliance auf die Data Domain angewendet?

Antwort: Die Schlüsselsynchronisierung erfolgt täglich. Wenn ein neuer Schlüssel verfügbar ist oder der Status eines Schlüssels geändert wird, aktualisiert die Synchronisierung die lokale Schlüsseltabelle. Data Domain empfängt jeden Tag um Mitternacht wichtige Updates vom KMIP.

Frage: Ist es möglich, die Schlüsselstatus zwischen Data Domain und KMIP manuell zu synchronisieren?

Antwort: Ja, die Data Domain-CLI oder -Benutzeroberfläche kann verwendet werden, um die Schlüsselstatus zwischen Data Domain und KMIP manuell zu synchronisieren. Der Befehl hierfür lautet 'filesys encryption keys sync'.

Frage: Ist es möglich, den Zeitpunkt zu ändern, zu dem die Data Domain wichtige Updates von KMIP erhält?

Antwort: Nein, es ist nicht möglich, den Zeitpunkt zu ändern, zu dem die Data Domain wichtige Updates vom KMIP erhält.

Frage: Gibt es eine Begrenzung für die Anzahl der in Data Domain gespeicherten Schlüssel?

Antwort: Ab DDOS 7.8 kann das Data Domain-System maximal 1.024 Schlüssel auf dem System haben. Es gibt nur einen Schlüssel im Activated-RW Staat; Alle anderen Schlüssel können sich in einem anderen Zustand befinden.

Frage: Können unterschiedliche Schlüssel für verschiedene Datenvolumen in Data Domain verwendet werden?

Antwort: Nein, Data Domain unterstützt jeweils nur einen aktiven Schlüssel im System. Alle eingehenden Daten werden mit dem aktuellen aktiven Schlüssel verschlüsselt. Schlüssel können nicht mit einer feineren Granularität (z. B. pro MTree) 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üsselbegrenzung löschen?

Antwort: Einer der Schlüssel muss gelöscht werden, um die Warnmeldung zur maximalen Schlüsselbegrenzung zu löschen.

Frage: Kann ich die Datenmenge sehen, die mit einem bestimmten Schlüssel in der Data Domain verknüpft ist?

Antwort: Ja, dies kann auf Data Domain, aber nicht auf dem KMIP-Server angezeigt werden. Die Data Domain-CLI und die Benutzeroberfläche ermöglichen es dem Nutzer, die Datenmenge anzuzeigen, die einem bestimmten Schlüssel zugeordnet ist. Der Befehl hierfür lautet 'filesys encryption keys show summary'.

Frage: Kann ich das Alter der Schlüssel auf der Data Domain anzeigen?

Antwort: Ja, er kann für EKM-Schlüssel über die Benutzeroberfläche angezeigt werden.

Frage: Funktioniert der alte Schlüssel auch dann, wenn die Frist für die Wirksamkeit des neuen Schlüssels abgelaufen ist?

Antwort: Es gibt kein Ablaufdatum für Verschlüsselungsschlüssel. Alte Schlüssel werden nach der Schlüsselrotation schreibgeschützt und verbleiben im DDOS.

Frage: Werden Verschlüsselungsschlüssel automatisch gelöscht, wenn ihnen in Data Domain keine Daten zugeordnet sind?

Antwort: Nein, der Schlüssel wird nicht automatisch gelöscht. Der Nutzer muss den Schlüssel explizit über die Data Domain-CLI oder -Benutzeroberfläche löschen.

Frage: Kann ein Schlüssel auch dann gelöscht werden, wenn ihm Daten in der Data Domain zugeordnet sind?

Antwort: Nein, wenn einem Schlüssel Daten zugeordnet sind, kann er nicht gelöscht werden. Daten müssen mit einem anderen Schlüssel erneut verschlüsselt werden, 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 unabhängig mithilfe der Data Domain-CLI oder -Benutzeroberfläche 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. Ein KMIP-Server kann für alle verwendet werden. Es wird empfohlen, eine separate Schlüsselklasse für jedes Data Domain-System zu verwenden, wenn sie denselben KMIP-Server verwenden.

Frage: Wenn ein Schlüssel kompromittiert ist, gibt es einen Prozess, um die Daten abzurufen, die mit dem alten Schlüssel verschlüsselt sind?

Antwort: In diesem Fall muss der Kunde den Schlüssel im KMIP-Server als kompromittiert markieren. Dann in der Data Domain:

Führen Sie den Befehl "filesys encryption keys sync'.
Führen Sie den Befehl "filesys encryption apply-changes'.
Starten Sie eine Dateisystembereinigung.
1. Bei der Bereinigung werden alle Daten, die mit dem kompromittierten Schlüssel verschlüsselt wurden, mit einem neueren Schlüssel erneut verschlüsselt.
2. Sobald die Bereinigung abgeschlossen ist, wird der alte Schlüsselstatus in Compromised-Destroyed.
Löschen Sie den alten Schlüssel.

Verschlüsselung und Replikation

Frage: Wird die Data Domain-Replikation unterstützt und ist sie mit DARE interoperabel?

Antwort: Ja, die Data Domain-Replikation kann mit DARE verwendet werden. Auf diese Weise können verschlüsselte Daten mit allen verschiedenen Replikationsarten repliziert werden. Jeder Replikationstyp arbeitet auf einzigartige Weise mit Verschlüsselung und bietet das gleiche Maß an Sicherheit.

Frage: Muss auf dem Quell- und Zielsystem dieselbe DDOS-Version ausgeführt werden, damit die Verschlüsselung verwendet werden kann?

Antwort: Quelle und Ziel können unterschiedliche DDOS-Versionen verwenden, um DARE mit der Replikation zu verwenden, wenn sie für die Replikation kompatibel sind (die Kompatibilitätsmatrix finden Sie im Data Domain-Administrationshandbuch ).

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 eine MTree-Replikation (MREPL) oder eine verwaltete Dateireplikation (MFR) handelt:

DARE kann unabhängig auf der Quelle oder dem Ziel lizenziert oder aktiviert werden, je nachdem, was der Kunde erreichen möchte.
Wenn sowohl die Quelle als auch das Ziel verschlüsselt sind:
- In die Quelle aufgenommene Daten werden 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 dann die verschlüsselten Daten auf das Ziel.
Wenn die Verschlüsselung für die Quelle deaktiviert und für das Ziel die Verschlüsselung aktiviert ist:
- Daten, die in die Quelle aufgenommen werden, werden nicht verschlüsselt.
- Bei der Replikation verschlüsselt die Quelle die Daten mit dem Chiffrierschlüssel des Zielsystems und repliziert dann die verschlüsselten Daten auf das Zielsystem.
Wenn für die Quelle die Verschlüsselung aktiviert und für das Ziel die Verschlüsselung deaktiviert ist:
- Daten, die in das Quellsystem aufgenommen werden, werden mit dem Chiffrierschlüssel des Quellsystems verschlüsselt.
- Die Quelle entschlüsselt die Daten und repliziert dann die unverschlüsselten Daten auf das 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, verbleiben in einem unverschlüsselten Zustand, es sei denn, Änderungen werden angewendet und eine Bereinigung wird auf dem Ziel ausgeführt.

Wenn es sich bei der konfigurierten Replikation um eine Sammelreplikation (CREPL) handelt:

Auf dem Quell- und Zielsystem muss dieselbe DDOS-Version ausgeführt werden.
Die Verschlüsselung muss 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 Zielsystem.
- Das Ziel hat denselben Schlüssel wie die Quelle, da es bei der Sammelreplikation um ein exaktes Replikat des Quellsystems geht.
- Außerhalb der Replikation können keine Daten auf das Ziel geschrieben werden, da das Ziel ein schreibgeschütztes System ist.
Wenn sowohl Quelle als auch Ziel die Verschlüsselung deaktiviert haben:
- Daten, die in das Quellsystem aufgenommen werden, werden nicht verschlüsselt.
- Bei der Replikation sendet die Quelle die Daten in einem unverschlüsselten Zustand und sie bleiben am Ziel unverschlüsselt.
- Außerhalb der Replikation können keine Daten auf das Ziel geschrieben werden, da das Ziel ein schreibgeschütztes System ist.

Frage: Wird der Schlüssel des Ziels auf unbestimmte Zeit im Quell-Data Domain 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 Replikationstypen mit Ausnahme der Sammelreplikation. Bei der Sammelreplikation ist derselbe Satz von Chiffrierschlüsseln sowohl auf der Quelle als auch auf dem Ziel vorhanden.

Frage: Kann die Verschlüsselung auf einem Sammelreplikationssystem 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. Der Replikationskontext muss deaktiviert sein, um die Verschlüsselung zu konfigurieren. 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 DARE gleichzeitig mit der Übertragungsverschlüsselungsfunktion für die Data Domain-Replikation aktiviert werden?

Antwort: Ja, sowohl die Over-the-Wire-Verschlüsselung (OTW) als auch DARE können gleichzeitig aktiviert werden, um unterschiedliche Sicherheitsziele zu erreichen.

Frage: Was passiert, wenn sowohl DARE- als auch OTW-Verschlüsselung gleichzeitig aktiviert sind?

Antwort: Die Quelle verschlüsselt zunächst Daten mit dem Zielverschlüsselungsschlüssel. Dann werden bereits verschlüsselte Daten ein zweites Mal durch die OTW-Verschlüsselung verschlüsselt, während diese Daten an ihr Ziel gesendet werden. Am Zielort, nachdem die OTW-Entschlüsselung abgeschlossen ist, werden die Daten in einem verschlüsselten Format gespeichert, das mit dem Verschlüsselungsschlüssel des Ziels verschlüsselt wurde.

Frage: Wenn die Verschlüsselung sowohl auf der Quelle als auch auf dem Ziel aktiviert ist, müssen sie dieselbe Passphrase verwenden?

Antwort: Wenn es sich bei der konfigurierten Replikation um eine Sammelreplikation handelt, muss die Passphrase identisch sein. Für andere Replikationsarten (wie MREPL, MFR) können die Systeme unterschiedliche Passphrasen verwenden.

Frage: Werden bei aktivierter Verschlüsselung am Ziel sowohl die replizierten Daten als auch Daten von einem anderen Zugriffspunkt (z. B. über ein lokales Backup) verschlüsselt? Gibt es eine Möglichkeit, die beiden auf dem Ziel zu trennen, sodass nur die replizierten Verzeichnisse verschlüsselt werden?

Antwort: Nein, alle Daten werden am Ziel unabhängig vom Einstiegspunkt verschlüsselt. Die Verschlüsselung kann nicht nur auf MTree- oder Verzeichnisebene aktiviert oder deaktiviert werden. Dies gilt nicht für CREPL.

Frage: Wie erfolgt der Schlüsselaustausch zwischen Quelle und Ziel während MREPL oder MFR?

Antwort: Während der Zuordnungsphase der Replikation überträgt das Ziel seinen 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 Data-Domain-Verschlüsselungsschlüssel zu verschlüsseln und zu entschlüsseln.

Frage: Welche Art von Algorithmus verwendet die OTW-Verschlüsselung, um den Replikationsverkehr zu verschlüsseln?

Antwort: Wenn der Replikationsauthentifizierungsmodus auf "one-way" oder "two-way" festgelegt 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.

"One-way" gibt an, dass nur das Zielzertifikat zertifiziert ist. "two-way" bedeutet, dass sowohl die Quell- als auch die Zielzertifikate überprüft wurden. Es muss gegenseitiges Vertrauen hergestellt werden, bevor Sie diesen Authentifizierungsmodus verwenden können, und beide Seiten der Verbindung müssen diese Funktion aktivieren, damit die Verschlüsselung fortgesetzt werden kann.

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

Frage: Funktioniert die Schlüsselrotation ohne Dateisystemneustart mit allen Replikationstypen?

Antwort: Die Schlüsselrotation ohne Dateisystemneustart funktioniert mit allen Replikationstypen außer Verzeichnisreplikation (die nicht mehr unterstützt wird) und Deltareplikation (auch bekannt als Optimierung bei niedriger Bandbreite oder LBO).

Frage: Wie wird der Chiffrierschlü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 Domains zum ersten Mal einen Replikationskontext einrichten möchten. Es wird auch über einen Diffie-Hellman-Austausch unter Verwendung von Parametern, die in den Code eingebettet sind, vereinbart. 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: Müssen beide Systeme in einem Replikationspaar dieselbe externe Key-Manager-Lösung (z. B. KMIP Key Manager) verwenden, oder kann eines der Systeme einen externen Key Manager und ein anderes einen integrierten Key Manager verwenden?

Antwort: Abgesehen von der Sammelreplikation 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. Allerdings synchronisiert nur die Quelle Schlüssel mit dem Key Manager, und diese Schlüssel werden auch an das Ziel gesendet. Bei anderen Replikationstypen können verschiedene Key Manager für Quelle und Ziel verwendet werden.

Verschlüsselung und Migration

Frage: Wird die Datenmigration auf Systemen unterstützt, auf denen DARE aktiviert ist?

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 vom aktiven Tier und vom Cloud-Tier mit aktiviertem DARE 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 vorausgesetzten Attribute 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 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 verläuft, sind Systempassphrase, Verschlüsselungsstatus, Schlüssel-Manager-Konfigurationsdetails und System-FIPS-Moduseinstellungen. In diesem KB-Artikel (Anmeldung beim Dell Support erforderlich) werden die Schritte für die Migration zwischen Systemen mit aktivierter Cloud beschrieben. Die gleichen Einstellungen gelten auch für die Migration aktiver Tiers.

Frage: Wird die Migration zwischen EDV-Systemen unterstützt?

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 erlaubt, wenn die OTW-Verschlüsselung explizit über die MIGRATION_ENCRYPTION Systemparameter.

Verschlüsselung und Cloud-Tier

Frage: Wird Verschlüsselung für Cloud-Tier unterstützt?

Antwort: Ja, Verschlüsselung wird für Cloud-Tier unterstützt. Sie ist standardmäßig deaktiviert. Die 'cloud enable' Eingabeaufforderungen, um auszuwählen, ob die Verschlüsselung auf dem Cloud-Tier aktiviert werden soll oder nicht.

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 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 Data Domain gleich. Schlüssel werden in die entsprechende Einheit, das Tier oder die Sammlungspartition 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. Zum Beispiel: Wenn cp1 Verschlüsselung aktiviert hat und cp2 Verschlüsselung nicht aktiviert hat, dann cp1 Schlüssel reflektieren nicht auf cp2.

Frage: Können Schlüssel aus 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 zugeordnet collection partition (CP)und jede Cloudeinheit ist ein anderer CP. Eine Kopie der Schlüssel von allen CPs wird in der aktiven Partition gespeichert.

Frage: Wie stelle ich Cloud-Schlüssel während der Disaster Recovery wieder her?

Antwort: Bei der cpnameval wird im Rahmen der CP-Wiederherstellung in die Cloud gespiegelt und die Verschlüsselungsschlüssel werden wiederhergestellt auf cpnameval. Anschließend wird die ddr_key_util wird verwendet, um die Schlüssel wiederherzustellen.

Hinweis: Für die Disaster Recovery ist die Unterstützung des Kundensupports erforderlich.

Frage: Kann eine Datenverschiebung ausgeführt werden, wenn die Verschlüsselung nur für den Cloud-Tier aktiviert ist?

Antwort: Nein, die Verschlüsselung muss sowohl in der Cloud als auch in aktiven Tiers aktiviert sein, damit die Datenverschiebung ausgeführt werden kann.

Frage: Kann ein externer Key Manager mit Cloud-Tier verwendet werden?

Antwort: Ja, externer Key Manager kann mit Cloud-Tier verwendet werden. Diese Funktion wird ab DDOS 7.8 unterstützt. Alle Vorgänge (mit Ausnahme des Löschens oder Löschens eines Schlüssels, der für den aktiven Tier verwendet wird) sind auch für Cloud-Tier in Bezug auf den externen Key Manager gültig.

Verschlüsselung und automatische Speicherbereinigung

Frage: Welche Rolle spielt der Prozess zur automatischen Speicherbereinigung (Garbage Collection, GC) bei DARE? Wirkt sich die Aktivierung der Verschlüsselung beim erstmaligen Aktivieren der Verschlüsselung auf die Leistung aus?

Antwort: Die erstmalige Aktivierung von DARE hat Auswirkungen auf die GC-Performance. Wenn GC ausgeführt wird, liest es Daten aus vorhandenen Containern auf der Festplatte und schreibt sie in neue Container. Nach der Aktivierung von DARE müssen diese Daten möglicherweise gelesen, entschlüsselt und dekomprimiert werden, bevor sie erneut komprimiert, verschlüsselt und wieder auf die Festplatte geschrieben werden. Wenn die Verschlüsselung auf einer Data Domain aktiviert ist, die eine erhebliche Menge an bereits vorhandenen Daten enthält, und die 'filesys encryption apply-changes' ausgeführt wird, versucht der nächste GC-Zyklus, 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. Daher wird der erste GC nach dem Ausführen von 'filesys encryption apply-changes' kann länger als normal dauern. Stellen Sie sicher, dass ausreichend freier Speicherplatz auf dem Data Domain-System vorhanden ist, damit die Bereinigung abgeschlossen werden kann, ohne dass das Data Domain-System voll wird (andernfalls schlagen Backups fehl).

Frage: Gibt es Auswirkungen auf die Performance, wenn Bereinigungszyklen laufen?

Antwort: Ja, es gibt Auswirkungen auf die Performance. Die Auswirkungen hängen im Allgemeinen von der Menge der Daten ab, die zwischen den Bereinigungszyklen aufgenommen und wiederhergestellt werden.

Frage: Wie lange dauert es, vorhandene Daten zu verschlüsseln?

Verwenden Sie diesen Wissensdatenbank-Artikel, um die Zeit zu schätzen: Data Domain: Es wird berechnet, wie lange die Anwendung der Verschlüsselung im Ruhezustand dauert.

Verschlüsselung und Headswap

Frage: Wenn eine Data Domain mit DARE-Konfiguration einen Headswap durchläuft, sind Festplatten dann weiterhin mit der neuen Haupteinheit zugänglich?

Antwort: Der Verschlüsselungsschlüssel ist nicht an den Data Domain-Systemkopf selbst gebunden, sodass die Festplatten auf einen anderen Data Domain-Kopf verschoben werden können und der Schlüssel dort weiterhin zugänglich ist. Das Dateisystem ist auf der neuen Hauptplatine gesperrt und muss mit der Option 'filesys encryption unlock"-Befehl und die Systempassphrase.

Frage: Was passiert, wenn die Passphrase zum Zeitpunkt des Headswap-Vorgangs verloren geht?

Antwort: Wenn die Passphrase verloren geht, schließen Sie den alten Head an und arbeiten Sie mit dem Support zusammen, um die Passphrase zurückzusetzen. Stellen Sie dann die Verbindung zum neuen Head wieder her und schließen Sie den Headswap-Vorgang ab.

Verschlüsselung und Leistung

Frage: Welche Auswirkungen auf die Storage-Nutzung werden beobachtet, wenn DARE verwendet wird?

Antwort: Die Auswirkungen auf die Storage-Nutzung sind vernachlässigbar, wobei etwa 1 % Overhead mit der Speicherung einiger Verschlüsselungsparameter mit Nutzerdaten verbunden ist.

Frage: Welche Auswirkungen wird auf den Durchsatz (Schreib- und Lesevorgänge) beobachtet, wenn DARE 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 aggregierten Durchsatz:

CBC-Modus

Erste Vollversion: ~10 % Performanceverschlechterung bei Schreibvorgängen
Inkrementelle: ~5 % Performanceverschlechterung bei Schreibvorgängen
Stellt: 5 bis 20 % Leistungseinbußen bei Lesevorgängen

GCM-Modus

Erste Vollversion: 10 bis 20 % Performanceverschlechterung bei Schreibvorgängen
Inkrementelle: 5 bis 10 % Performanceverschlechterung bei Schreibvorgängen
Stellt: 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 berücksichtigt.

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. 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, ist das vorgeschlagene Schlüsselrotationsintervall wöchentlich. Wenn KMIP nur für den aktiven Tier konfiguriert ist, lautet die vorgeschlagene Policy für die Schlüsselrotation monatlich. Dies kann jedoch je nach Einnahmerate erhöht oder verringert werden. Wenn der integrierte Key Manager konfiguriert ist, wird eine Policy für die Schlüsselrotation mit einer Laufzeit von 1 bis 3 Monaten empfohlen.

Frage: Was sind Best Practices für die KMIP-Schlüsselklasse, wenn derselbe KMIP-Server für viele Data Domains verwendet wird?

Antwort: Es wird empfohlen, eine separate Schlüsselklasse für jede Data Domain zu verwenden, wenn sie denselben KMIP-Server verwenden. Auf diese Weise hat die Schlüsselrotation, die auf einem System durchgeführt wird, keine Auswirkungen auf den Status des Schlüssels, der in anderen Systemen vorhanden ist.

Weitere Informationen

Weitere Dokumentationen zur Data Domain-Verschlüsselung (Administratorhandbuch, Befehlsreferenzhandbuch und Sicherheitskonfigurationshandbuch) finden Sie hier: Wichtige Dokumente zu PowerProtect und Data Domain

Sehen Sie sich dieses Video an: