EMC VNX2: Data at Rest Encryption

Transcrição

White Paper
EMC VNX2: DATA AT REST ENCRYPTION
VNX5200, VNX5400, VNX5600, VNX5800, VNX7600 UND
VNX8000
Zusammenfassung
In diesem White Paper wird mit Data at Rest Encryption
für EMC® VNX2 eine Funktion vorgestellt, die
Datenschutz bei gestohlenen oder verloren
gegangenen Laufwerken bietet. Es bietet eine
detaillierte Beschreibung der Technologie und erläutert
ihre Implementierung auf Speichersystemen der VNX2Serie.
September 2014
Copyright © 2014 EMC Corporation. Alle Rechte
vorbehalten.
EMC ist der Ansicht, dass die Informationen in dieser
Veröffentlichung zum Zeitpunkt der Veröffentlichung
korrekt sind. Diese Informationen können jederzeit ohne
vorherige Ankündigung geändert werden.
Die Informationen in dieser Veröffentlichung werden
ohne Gewähr zur Verfügung gestellt. Die EMC
Corporation macht keine Zusicherungen und übernimmt
keine Haftung jedweder Art im Hinblick auf die in diesem
Dokument enthaltenen Informationen und schließt
insbesondere jedwede implizite Haftung für die
Handelsüblichkeit und die Eignung für einen bestimmten
Zweck aus.
Für die Nutzung, das Kopieren und die Verbreitung der in
dieser Veröffentlichung beschriebenen Software von
EMC ist eine entsprechende Softwarelizenz erforderlich.
Eine aktuelle Liste der Produkte von EMC finden Sie unter
EMC Corporation Trademarks auf
http://germany.emc.com.
Art.-Nr.: H13296
VNX5200, VNX5400, VNX5600, VNX5800, VNX7600 UND VNX8000
2
Inhaltsverzeichnis
Zusammenfassung............................................................................................... 4
Zielgruppe ............................................................................................................ 4
Terminologie......................................................................................................... 4
Einführung ............................................................................................................. 6
Überblick über Data at Rest Encryption (D@RE)................................................ 6
Wie funktioniert Verschlüsselung? ................................................................................. 8
Platten und erweiterte Datenservices .......................................................................... 9
Compliance ....................................................................................................... 10
Gerade übertragene Daten ........................................................................................ 11
Migrationsfreies Upgrade.............................................................................................. 11
Scrubbing ........................................................................................................................ 12
Laufwerksausfälle ........................................................................................................... 13
Verschlüsselungsverfahren ............................................................................... 13
Verschlüsselungsaktivierung ......................................................................................... 13
Verschlüsselungsstatus .................................................................................................. 19
Keystore-Backup ............................................................................................................ 21
Keystore-Wiederherstellung .......................................................................................... 25
Auditprotokoll ................................................................................................................. 27
Performance ...................................................................................................... 29
Ersetzen von Hardware ..................................................................................... 30
FIPS 140-2-Validierung ...................................................................................... 30
Fazit ..................................................................................................................... 31
Referenzen ......................................................................................................... 31
3
Zusammenfassung
Die Menge der täglich erzeugten sensiblen Daten wächst heutzutage exponentiell
an. Eine der größten Herausforderungen dabei ist die Sicherheit dieser Daten. Zur
Bewältigung dieser Herausforderung bietet die EMC® VNX2-Serie mit Data at Rest
Encryption (D@RE) eine Technologie, mit der Daten bereits beim Schreiben auf eine
Festplatte verschlüsselt werden.
VNX2 erreicht dieses Sicherheitsniveau auf Hardwareebene mithilfe von ControllerBased Encryption (CBE). Alle geschriebenen Daten werden beim Durchlaufen des
SAS-Controllers verschlüsselt, bevor sie auf Platte gespeichert werden. Analog dazu
werden die Daten, wenn sie von der Platte gelesen werden, vom SAS-Controller
entschlüsselt.
Zielgruppe
Dieses White Paper richtet sich an EMC Kunden, Partner und Mitarbeiter,
denen Datensicherheit ein wichtiges Anliegen ist. Es wird vorausgesetzt,
dass der Leser über allgemeine IT-Kenntnisse einschließlich des Know-hows
eines System- oder Netzwerkadministrators verfügt.
Terminologie
In diesem White Paper wird die folgende Terminologie verwendet:
Background Zeroing – Hintergrundprozess, der neue Laufwerke beim
Einfügen in das System mit Nullen beschreibt
Controller-Based Encryption (CBE) – Verschlüsselung von Daten im SASController, bevor sie auf Platte übertragen werden
Data at Rest Encryption (D@RE) – Prozess, mit dem Daten verschlüsselt und
vor unbefugtem Zugriff geschützt werden, wenn kein gültiger Schlüssel
bereitgestellt wird. Verhindert den Zugriff auf Daten und stellt einen CryptoErase-Mechanismus zum schnellen Löschen von Daten durch Erstellung
eines neuen Schlüssels bereit
Data Encryption Key (DEK) – Ein nach dem Zufallsprinzip generierter
Schlüssel zum Verschlüsseln von Daten auf einer Platte. Bei VNX2 ist ein
eindeutiger Schlüssel für jedes angebundene Laufwerk verfügbar.
Key Encryption Key (KEK) – Ein nach dem Zufallsprinzip generierter
Schlüssel, der Data Encryption Keys verschlüsselt, damit sie während der
Weiterleitung vom Key Manager zum SAS-Controller geschützt sind. Er wird
4
beim Systemstart an den SAS-Controller weitergeleitet und wird vom KWK
geschützt.
KEK Wrapping Key (KWK) – Ein nach dem Zufallsprinzip generierter
Schlüssel, der bei der Installation von D@RE Enabler generiert sowie an das
SAS-Verschlüsselungsmodul weitergeleitet und darin gespeichert wird. Er
wird zum Verschlüsseln des KEK verwendet, wenn dieser vom Key Manager
zum SAS-Controller weitergeleitet wird.
Keystore – Ein eingebetteter und unabhängig verschlüsselter Container,
der alle D@RE-Chiffrierschlüssel des Arrays enthält.
Bereinigung – Prozess zum Entfernen von Daten von einem Datenträger,
damit eine Datenwiederherstellung verhindert wird
SAS-Controller (Serial Attached SCSI) – Gerät zur Verwaltung von SASBussen, die mit Platten verbunden sind. Auf VNX-Systemen ist dieses Gerät
in den Speicherprozessor (nur DPE-basierte Modelle) oder in ein 6-Gbit-SASUltraFlex-I/O-Modul (alle Modelle) integriert.
Solid State Drive (SSD) – Gerät, das Flashspeicherchips anstelle von
rotierenden Platten zum Speichern von Daten verwendet. Wird auch als
„Flashlaufwerk“ bezeichnet.
Scrubbing – Prozess, bei dem zufällig ausgewählte Daten in unbelegten
Speicherplatz auf Laufwerken geschrieben werden oder bei dem Nullen
auf ungebundene Laufwerke geschrieben werden, um Restdaten aus
früherer Verwendung zu löschen
Self-Encrypting Drive (SED) – Laufwerk mit integrierter Elektronik, die alle
Daten verschlüsselt, bevor sie auf ein Speichermedium geschrieben
werden, und dieselben Daten vor dem Lesen entschlüsselt
Speicherpool – Ein einzelnes Repository aus homogenen oder heterogenen
physischen Platten, aus denen LUNs erstellt werden können
Speicherprozessor (SP) – Hardwarekomponente, die System-I/Os zwischen
Hosts und Platten verwaltet
Unisphere – Die Managementoberfläche zum Erstellen, Verwalten und
Überwachen von VNX-Speichersystemen
Unisphere Service Manager – Gruppe von Tools, mit deren Hilfe Sie Ihre
Systemhardware und -software aktualisieren, installieren und verwalten
sowie Ihrem Serviceprovider Kontakt- und Systeminformationen zur
Verfügung stellen können
5
Einführung
Da erhebliche Datenschutzverstöße immer häufiger auftreten, stellt die
Sicherheit heutzutage eine der größten Herausforderungen dar, denen
Speicheradministratoren ausgesetzt sind. Solche Verstöße können nicht nur
die Finanzlage und den guten Ruf eines Unternehmens beschädigen,
sondern sie können auch zu einer zivil- und strafrechtlichen Haftung
führen. Daher betonen Unternehmen immer mehr, wie wichtig der Schutz
ihrer privaten und sensiblen Daten ist. Darüber hinaus erfordern strenge
branchenspezifische und gesetzliche Vorschriften im Gesundheitswesen, im
Finanzwesen, in Regierungsbehörden und der Justiz sowie in anderen
Bereichen, dass alle Daten sicher sein müssen.
Neben ihren alltäglichen Aufgaben müssen Speicheradministratoren
sicherstellen, dass ihre Daten vor unbefugtem Zugriff geschützt sind. In
diesem White Paper wird Data at Rest Encryption (D@RE) für die VNX2
unter Verwendung von Controller-Based Encryption (CBE) vorgestellt. Diese
Lösung soll Speicheradministratoren dabei helfen sicherzustellen, dass ihre
Daten sicher sind, wenn Laufwerke aus dem Speichersystem entfernt
werden. Als „Verschlüsselung“ wird der Prozess bezeichnet, bei dem in
Klartext vorliegende Daten in verschlüsselten Text umgewandelt werden,
sodass sie ohne den entsprechenden Chiffrierschlüssel nicht gelesen
werden können. Nur mithilfe des richtigen Schlüssels kann der Klartext
wieder entschlüsselt werden.
Wenn VNX2 Data at Rest Encryption installiert ist, verschlüsselt diese
Funktion automatisch alle Block- und File-basierten Daten, bevor sie auf
den Festplatten und SSDs im Speichersystem gespeichert werden. Da die
Chiffrierschlüssel nur dem Speichersystem bekannt sind, können die Daten
auf diesen Platten nicht gelesen werden, wenn diese Laufwerke aufgrund
eines Sicherheitsverstoßes im Rechenzentrum oder im Rahmen normaler
Serviceprozesse aus dem Speichersystem entfernt werden.
Überblick über Data at Rest Encryption (D@RE)
Mit der VNX2-Serie wird die Data at Rest Encryption-Technologie (D@RE)
eingeführt, die in den SAS-Controller (Serial Attached SCSI) integrierte
Hardware zum Verschlüsseln von auf Platte gespeicherten Daten
verwendet. D@RE ist in der gesamten VNX2-Serie von VNX5200 bis VNX8000
als optionale Softwarelizenz verfügbar.
Der Zweck der VNX2 D@RE-Lösung besteht darin, alle in das Array
geschriebenen Daten mithilfe eines regulären Datenpfadprotokolls zu
6
verschlüsseln. Hierzu werden die Daten unter Verwendung eines
eindeutigen Schlüssels für jede Platte verschlüsselt, während sie auf Platte
geschrieben werden. Wenn Laufwerke aus dem Array entfernt werden
(z. B. durch einen Ausfall oder Diebstahl), sind die Daten auf dem Laufwerk
unleserlich. Außerdem beinhaltet die VNX2 D@RE-Lösung einen CryptoErase-Mechanismus zum Löschen von Daten durch Erstellen eines neuen
Schlüssels, durch den die zugehörigen Schlüssel auf dem Speichersystem
zusammen mit der RAID-Gruppe oder dem Speicherpool gelöscht werden.
Dadurch kann ein Array sicher und einfach einer neuen Verwendung
zugeführt werden.
Zu den wichtigsten Funktionen von D@RE gehören:
•
•
•
•
•
•
Verschlüsselung aller Benutzerdaten 1
Integrierte, vollständig automatisierte und sichere Schlüsselgenerierung, -speicherung, -löschung und -weiterleitung innerhalb
des Systems:
o RSA BSAFE® zur Schlüsselgenerierung
o LockBox zur Schlüsselspeicherung
o VNX Key Manager zur Überwachung von Statusänderungen
auf Laufwerken
o Verschlüsselung aller Data Encryption Keys (DEKs) vor dem
Verschieben innerhalb eines Arrays
Minimale Leistungsbeeinträchtigungen bei typischen gemischten
Workloads
Unterstützung für alle Laufwerkstypen, -geschwindigkeiten und größen
Unterstützung für alle erweiterten Datenservices (z. B. Komprimierung,
Deduplizierung)
Für den Benutzer nach der Aktivierung weitgehend unsichtbar,
abgesehen vom Keystore-Backup für Administratoren
Auf der Systempartition können sich unverschlüsselte Daten befinden (z. B. Hostnamen, IP-Adressen,
Speicherauszüge). Wenn Diagnosematerial auf die Systempartition geschrieben wurde, können daraus
außerdem einige wenige unverschlüsselte Benutzerdaten resultieren. Alle unter Verwendung von regulären
I/O-Protokollen (iSCSI, FC) in das Array geschriebenen Daten sind verschlüsselt. Alle unter Verwendung des
Steuerpfades in das Array geschriebenen Daten werden von dieser Lösung nicht verschlüsselt. Sensible Daten
(z. B. Passwörter) werden über einen anderen Mechanismus verschlüsselt (da sie sich auf nicht
verschlüsselnden Arrays befinden).
1
7
Da diese Funktion dem Schutz von Benutzerdaten dient, werden einige
Systemkonfigurationsdaten nicht verschlüsselt. Darüber hinaus schützt
D@RE keine Daten in folgenden Szenarien:
•
•
•
Verlust des gesamten Arrays
Daten während der Übertragung nach Verlassen des Arrays
Zugriff auf Daten mithilfe von Standardprotokollen für den
Datenzugriff (z. B. keine Auswirkung von D@RE auf über iSCSI
angebundene Hosts)
Die SED-Technologie (Self-Encrypting Drive) ist eine Variation von D@RE, die
weit verbreitet ist und ähnliche Funktionen bietet wie CBE. Bei SEDs müssen
Sie jedoch für jedes Laufwerk eine Gebühr zahlen, und es werden nur
bestimmte Laufwerke im SED-Format angeboten. Zu den Vorteilen von CBE
gehören erhöhte Flexibilität, geringere Kosten und universelle Unterstützung
für alle Laufwerkstypen und -größen.
Wie funktioniert Verschlüsselung?
Alle D@RE-Chiffrierschlüssel haben eine Größe von 256 Bit. Zum
Verschlüsseln von Daten mithilfe von DEKs verwendet D@RE XOR Encrypt
XOR Tweakable Block Cipher mit Ciphertext Stealing (XTS), einen
Betriebsmodus des AES-Algorithmus (Advanced Encryption Standard). XTSAES ist ein Standard des Institute of Electrical and Electronics Engineers
(IEEE) und des United States National Institute of Standards and Technology
(NIST). Weitere Informationen zu XTS-AES finden Sie in IEEE P1619 und NIST
SP 800-38E.
Für die Verschlüsselung wird auch, wie in RFC 3394 spezifiziert, der AES Key
Wrap Algorithm zum Generieren eines Key Encryption Key (KEK) und eines
KEK Wrapping Key (KWK) verwendet. Der KEK schützt die DEKs vor einer
versehentlichen Offenlegung, während sie im Array verschoben werden
(z. B. vom Key Manager zum SAS-Controller). Weitere Informationen zum
AES Key Wrap Algorithm finden Sie im RFC 3394.
Beim NIST-Prüfprozess wird der AES-Algorithmus wesentlich genauer
untersucht als die meisten anderen Verschlüsselungsalgorithmen. Daher
wird dies sowohl unter praktischen als auch unter theoretischen
Gesichtspunkten derzeit als die sicherste Option angesehen.
8
Nach der Installation und Aktivierung der Funktion werden die folgenden
Schlüssel von RSA BSAFE generiert, an die LockBox weitergeleitet und in der
LockBox gespeichert:
•
•
KEK Wrapping Key (KWK)
Data Encryption Keys (DEKs) für alle angebundenen Laufwerke
Der KWK wird auch an den SAS-Controller weitergeleitet und auf dem
Controller gespeichert.
Hinweis: Es gibt keine Methode zum erneuten Generieren von Schlüsseln für
an RAID-Gruppen oder Speicherpools angebundene Laufwerke.
Bei jedem Arraystart wird ein neuer KEK generiert. Während des
Systemstarts wird der KEK durch den KWK verschlüsselt, an den SASController weitergeleitet und auf dem Controller gespeichert. Mithilfe des
gespeicherten KWK kann der SAS-Controller den KEK entschlüsseln.
Darüber hinaus werden die DEKs für alle angebundenen Laufwerke mit
dem KEK verschlüsselt und beim Systemstart sowie bei Bedarf an den SASController weitergeleitet. Mithilfe des entschlüsselten KEK kann der SASController die DEKs für die Laufwerke entschlüsseln. Durch diesen Prozess
wird die Zeitspanne minimiert, in der die DEKS ungeschützt sind.
Beim Schreibvorgang werden Daten vom SAS-Controller mithilfe des
zugehörigen DEK verschlüsselt, bevor sie auf Platte geschrieben werden.
Beim Lesevorgang werden die Daten mithilfe desselben Schlüssels
entschlüsselt. Wenn Platten verloren gehen oder gestohlen werden,
können die verschlüsselten Daten nicht gelesen werden, da nur das Array
über die erforderlichen Schlüssel verfügt.
Platten und erweiterte Datenservices
Verschlüsselung ist bei integrierten SAS-Modulen mit zwei Ports auf DPEbasierten VNX2-Modellen und bei 6-Gbit-SAS-UltraFlex-I/O-Modulen mit vier
Ports möglich. Da Verschlüsselung auf SAS-Controller-Ebene stattfindet, ist
sie für die Laufwerke und die erweiterten Datenservices transparent.
Dadurch wird Verschlüsselung für alle erweiterten Datenservices sowie alle
Plattentypen, -geschwindigkeiten und -größen unterstützt.
Beim Lesevorgang werden die Daten erst vom SAS-Controller entschlüsselt,
bevor erweiterte Datenservices ausgeführt werden. Beim Schreibvorgang
werden die erweiterten Datenservices ausgeführt, bevor die Daten vom
SAS-Controller verschlüsselt werden. Dadurch kann die Funktion für File und
Block und für alle erweiterten Datenservices eingesetzt werden, die im
9
Array
verfügbar
sind.
Außerdem
wirkt
sie
sich
nicht
Dateneffizienzservices wie Komprimierung und Deduplizierung aus.
auf
Gesicherte Daten aus einem D@RE-aktivierten Array liegen in
unverschlüsselter Form vor, weil die Daten entschlüsselt werden, bevor sie
vom Backupserver gelesen werden. Wenn Backupdaten verschlüsselt
werden
müssen,
müssen
Sie
eine
Backup-Appliance
mit
Verschlüsselungsfunktionen wie EMC Avamar oder Data Domain
verwenden.
Wenn es für eine Replikation erforderlich ist, dass Daten am
Remotestandort verschlüsselt sind, benötigen Sie am Remotestandort eine
weitere VNX2 mit aktivierter Verschlüsselung. Da die Laufwerke am
Remotestandort über einen eigenen Satz generierter Schlüssel verfügen,
werden die replizierten Daten mithilfe anderer Schlüssel verschlüsselt als die
Daten auf dem Quelllaufwerk. Die replizierten Daten sind jedoch identisch.
Es ist auch möglich, eine Replikation auf einer VNX durchzuführen, die
keine Verschlüsselung unterstützt oder bei der die Verschlüsselung nicht
aktiviert ist. Der Administrator muss sicherstellen, dass der primäre und der
sekundäre Standort ordnungsgemäß eingerichtet sind.
Da der Keystore vom Speicherprozessor (SP) verwaltet wird, müssen für eine
Verschlüsselung keine Änderungen an den vorhandenen Laufwerken im
Array vorgenommen werden. Die DEKs angebundener Laufwerke werden
im Keystore generiert und gespeichert. Der SAS-Controller verwendet den
zugehörigen DEK, um Daten zu verschlüsseln, bevor sie auf das Laufwerk
geschrieben
werden.
Dadurch
können
alle
Laufwerktypen, -geschwindigkeiten und -größen unterstützt werden, ohne dass
weitere spezielle Hardware erforderlich ist.
Compliance
Sie müssen unbedingt sicherstellen, dass Sie VNX2 D@RE in einer Weise
verwenden, die den Sicherheitsrichtlinien Ihres Unternehmens sowie allen
geltenden branchenspezifischen und gesetzlichen Vorschriften entspricht.
Es gibt eine Reihe von Standards, nach denen eine Verschlüsselung von
Daten im Ruhezustand erforderlich ist oder empfohlen wird (z. B. HIPPA und
PCI DSS). Es ist unwahrscheinlich, dass eine Verschlüsselungslösung auf
Laufwerksebene alle Verschlüsselungs- oder Datenschutzanforderungen
gemäß HIPPA oder PCI DSS erfüllen kann. Die VNX2 D@RE-Lösung bietet
hingegen Unterstützung für diese und ähnliche Anforderungen.
10
Gerade übertragene Daten
Durch Verschlüsselung werden nur Daten im Ruhezustand geschützt,
nachdem sie auf die Laufwerke geschrieben wurden. Verschlüsselung
bietet keinen Schutz für Daten, die gerade an externe Hosts übertragen
werden, sobald diese Daten vom SAS-Controller entschlüsselt wurden.
Allerdings kann bei Bedarf neben D@RE ein eigenständiger externer
Verschlüsselungsservice zur Verschlüsselung von Daten während der
Übertragung verwendet werden.
Migrationsfreies Upgrade
Für bereits verwendete Arrays bietet EMC ein migrationsfreies Upgrade zum
Verschlüsseln der Daten an, die sich bereits im Array befinden. Bei diesem
Prozess werden alle Datenblöcke auf einem Laufwerk gelesen und mithilfe
des eindeutigen Schlüssels des Laufwerks in unverschlüsselter Form zurück
auf das Laufwerk geschrieben. Mithilfe verschlüsselter Nullen wird der
gesamte adressierbare freie Speicherplatz ebenfalls überschrieben. Auch
der Speicherplatz auf ungebundenen Laufwerken wird mit unverschlüsselten Nullen oder Nullen in Klartext überschrieben (für den Fall, dass
es noch latente Informationen aus vorheriger Verwendung gibt).
Hinweis: Speicherplatz auf Laufwerken, der nicht mithilfe der üblichen I/OMechanismen adressiert werden kann, wird während eines
migrationsfreien Upgrades nicht verändert. Die Daten auf einem solchen
Speicherplatz können zwar nicht mithilfe der üblichen I/O-Mechanismen
abgerufen werden, es ist jedoch denkbar, dass diese nicht adressierbaren
Daten mittels eines forensischen Angriffs abgerufen werden könnten.
Wenn die Befürchtung besteht, dass sich in den verborgenen Bereichen
eines Laufwerks Klartextdaten befinden könnten, empfiehlt EMC dringend,
eine Verschlüsselung bereits zu aktivieren, bevor Daten in das Array
geschrieben werden, oder eine Migration zu einem neuen oder
ausreichend bereinigten Array mit bereits aktivierter Verschlüsselung
durchzuführen. Auf einem HDD oder SSD, auf dem gerade ein
migrationsfreies Upgrade stattfindet, wird kein sicheres Löschen (Secure
Erase) durchgeführt. Nur der adressierbare Bereich des Laufwerks wird
überschrieben. Alle restlichen Klartextdaten, die sich in verborgenen
Positionen auf dem Laufwerk befinden, werden nicht verschlüsselt. Diese
Daten können nicht ohne Weiteres über Standardschnittstellen abgerufen
werden, aber mithilfe fortschrittlicher Verfahren kann ein Zugriff möglich
sein. Zur Bereinigung kann eine Lösung wie EMC Disk Security Services
verwendet werden, die ein zertifiziertes Löschen von Platten bietet und
11
umfassende Berichterstellung sowie ein Abschlusszertifikat beinhaltet. Für
weitere Informationen zur Bereinigung siehe NIST SP800-88.
Da Sie FAST Cache deaktivieren müssen, bevor Sie die Verschlüsselung
aktivieren, können Sie FAST Cache-Laufwerke auf sichere Weise entfernen
und bereinigen, bevor Sie FAST Cache wieder aktivieren. Wenn ein SSD nur
als FAST Cache-Hot-Spare verwendet wird, kann es auch sofort bereinigt
werden. Wenn es jedoch zugleich als Speicherpool oder als RAIDGruppen-Hot-Spare verwendet wird, können Klartextdaten auf das SSD
geschrieben werden, falls es während eines migrationsfreien Upgrades für
eine Wiederherstellung verwendet wird. Bereinigen Sie diese Hot Spares
daher erst nach Abschluss eines migrationsfreien Upgrades.
Falls sich LUN- oder Dateisystemdaten auf den Vault-Laufwerken (den
ersten vier Laufwerken) der VNX2 befinden, müssen Sie zum Ersetzen dieser
Laufwerke eine besondere Vorgehensweise anwenden. Migrieren Sie die
LUNs auf eine andere Laufwerksgruppe und setzen Sie dann ein neues,
noch nicht verwendetes, kompatibles Laufwerk in Position 0_0_0 ein.
Warten Sie, bis das System die Laufwerksinhalte vollständig
wiederhergestellt hat. Dies sollte ungefähr eine Stunde dauern. Diesen
Vorgang müssen Sie anschließend für die übrigen drei Laufwerke (0_0_1,
0_0_2 und 0_0_3) wiederholen. Achten Sie darauf, dass jede Wiederherstellung abgeschlossen sein muss, bevor Sie mit dem nächsten Laufwerk
fortfahren. Nachdem Sie die Laufwerke ersetzt haben, können Sie die LUNs
zurück auf die Vault-Laufwerke migrieren und anschließend die
ursprünglichen Laufwerke bereinigen.
Scrubbing
Beim Scrubbing handelt es sich um den Prozess des Überschreibens von
Restdaten auf Laufwerken, die im Betrieb zum Array hinzugefügt wurden
(z. B. ein neues Hot Spare). Beim Scrubbing wird nur der adressierbare
Speicherplatz auf der Platte überschrieben. Alle restlichen Klartextdaten,
die sich in verborgenen Positionen auf dem Laufwerk befinden, werden
nicht überschrieben. Diese Daten können nicht ohne Weiteres über
Standardschnittstellen abgerufen werden, aber mithilfe fortschrittlicher
Verfahren kann ein Zugriff möglich sein. Falls ein potenzieller Zugriff auf
Datenreste aus der vorherigen Nutzung eines Laufwerks gegen die
Sicherheitsrichtlinien Ihres Unternehmens verstößt, müssen Sie das Laufwerk
gesondert bereinigen, bevor es mit aktivierter Verschlüsselung in eine VNX2
eingesetzt wird.
Beim Scrubbing handelt es sich nicht um den Versuch, eine mehrschrittige
Überschreiboperation
(wie
gemäß
NIST-Standards
erforderlich)
12
auszuführen. Deshalb sollten bei jeder Konfiguration, für die ein derart
gründliches Überschreiben erforderlich ist, die Laufwerke unabhängig vom
System bereinigt und erst dann installiert werden. Bei bereits vorhandenen
VNX2-Arrays, für die diese Anforderungen gelten, empfiehlt EMC die
Migration auf eine neue Gruppe von Laufwerken, die bereits bereinigt sind.
Laufwerksausfälle
Wenn ein Laufwerk ausfällt und ein Hot Spare übernimmt, wird der DEK für
das ausgefallene Laufwerk automatisch gelöscht. Wenn jedoch für das
Array ein migrationsfreies Upgrade durchgeführt wird und die Laufwerke
nicht unabhängig voneinander mit der erforderlichen Gründlichkeit
bereinigt wurden, besteht die Möglichkeit, dass sich in den verborgenen
Bereichen des Laufwerks noch Klartextdaten befinden. Falls die
Sicherheitsrichtlinien Ihres Unternehmens eine Bereinigungsoperation oder
die Zerstörung eines ausgefallenen Laufwerks vorschreiben, sollte der
jeweilige Vorgang gesondert ausgeführt werden.
Verschlüsselungsverfahren
Verschlüsselungsaktivierung
Verschlüsselung wird auf allen VNX2-Arrays mit Block OE 05.33.000.5.072
oder höher unterstützt. Bei neuen VNX2-Systemen, die mit der Funktion
D@RE bestellt werden, ist Verschlüsselung bei Lieferung standardmäßig
aktiviert. Wenn Sie den Status der Funktion D@RE in Unisphere anzeigen
möchten, navigieren Sie zu System  System Properties  Encryption, wie
in Abbildung 1 dargestellt.
13
Abbildung 1
Verschlüsselungsstatus
Wenn unter Encryption Mode die Angabe N/A erscheint, ist der Data at
Rest Encryption Enabler nicht installiert. Wenn unter Encryption Mode die
Angabe Unencrypted erscheint, ist der Enabler installiert, D@RE jedoch
nicht aktiviert. EMC empfiehlt dringend, die Verschlüsselung zu aktivieren,
bevor Daten in das Array geschrieben werden. Zum Aktivieren der
Verschlüsselung müssen Sie zuerst den Data at Rest Encryption Enabler in
Unisphere Service Manager (USM) installieren, wie in Abbildung 2
dargestellt. Hierzu muss der Speicherprozessor neu gestartet werden.
14
Abbildung 2
Installieren des D@RE-Enabler
Nachdem Sie den D@RE-Enabler installiert haben, melden Sie sich bei
Unisphere an, navigieren Sie zur Registerkarte System und führen Sie den
Data at Rest Encryption Activation Wizard aus, wie in Abbildung 3
dargestellt.
15
Abbildung 3
Data at Rest Encryption Activation Wizard
Hinweis: Sobald Data at Rest Encryption aktiviert ist, werden alle
Benutzerdaten im gesamten Array verschlüsselt. Diese Einstellung kann
nicht rückgängig gemacht werden.
Falls Multicore FAST Cache im Array erstellt wurde, muss es zerstört werden,
bevor die Verschlüsselung aktiviert wird. Wenn Multicore FAST Cache
zerstört wird, führt dies dazu, dass alle Daten in Multicore FAST Cache auf
die Festplatte geschrieben werden. Wenn Sie versuchen, die
Verschlüsselung zu aktivieren, während Multicore FAST Cache noch
vorhanden ist, erhalten Sie eine Fehlermeldung mit der Aufforderung,
Multicore FAST Cache zu zerstören. Sie können Multicore FAST Cache sofort
nach der Aktivierung der Verschlüsselung neu erstellen. Da die vorherigen
FAST Cache-Daten auf die Festplatte geschrieben wurden, muss FAST
Cache wieder aktiviert werden. Dies kann einige Zeit dauern. Solange die
Daten noch nicht in FAST Cache zurückübertragen wurden, kann die
Performance beeinträchtigt sein.
Der Aktivierungsassistent startet den Verschlüsselungsprozess und fordert
Sie dann zum ersten Sichern des Keystore auf, wie in Abbildung 4
dargestellt. Die Keystore-Datei enthält eine Kopie der Data Encryption Keys
16
für alle derzeit ans Array angebundenen Laufwerke. Das Keystore-Backup
ist verschlüsselt und kann nur in dem Array wiederhergestellt werden, in
dem sich die Keystore-Datei befindet.
Abbildung 4
Erstes Keystore-Backup
Wie in Abbildung 5 dargestellt, können Sie die Verschlüsselung auch
aktivieren, indem Sie den folgenden NaviSecCLI-Befehl ausführen:
naviseccli –h <SP-IP> securedata –feature –activate
17
Abbildung 5
Verschlüsselungsaktivierung – NaviSecCLI
Hinweis: Bei dieser Methode werden Sie nach dem Aktivieren der
Verschlüsselung nicht zum Sichern des Keystore aufgefordert. Sie sollten ein
Backup manuell initiieren. Für weitere Details siehe Keystore Backup.
Sobald der D@RE-Aktivierungsprozess entweder über Unisphere oder über
NaviSecCLI erfolgreich gestartet wurde, überprüfen Sie, ob für den
Verschlüsselungsprozess entweder „In Process“ (Wird ausgeführt),
„Encrypted“ (Verschlüsselt) oder „Scrubbing“ angezeigt wird. Nachdem
der Status des Verschlüsselungsprozesses überprüft wurde, müssen die
einzelnen Speicherprozessoren in einer koordinierten Weise manuell neu
gestartet werden. Es ist wichtig, dass Sie die Speicherprozessoren einzeln
neu starten und dass Sie erst überprüfen, ob der erste Speicherprozessor
betriebsbereit ist, bevor Sie den zweiten neu starten. Es spielt keine Rolle, in
welcher Reihenfolge Sie die Speicherprozessoren neu starten (z. B. erst SP A
und dann SP B oder erst SP B und dann SP A). Danach ist der Installationsund Aktivierungsprozess abgeschlossen.
In Unisphere gehen Sie dazu wie folgt vor:
1. Öffnen Sie EMC Unisphere, indem Sie die IP-Adresse Ihres
Speicherprozessors in einem unterstützten Browser eingeben.
2. Klicken Sie auf das Array, und wählen Sie System  Storage
Hardware aus.
3. Erweitern Sie die Registerkarte für SPs.
4. Klicken Sie mit der rechten Maustaste auf den SP, den Sie neu
starten möchten (z. B. SP A).
18
5. Wählen Sie Reboot aus.
6. Wählen Sie im Bestätigungsfenster Yes aus.
7. Bevor Sie den zweiten Speicherprozessor neu starten, müssen Sie
zunächst überprüfen, ob Sie sich bei Unisphere anmelden und das
Array verwalten können.
8. Wiederholen Sie die Schritte 4 bis 6 für den zweiten SP.
Alternativ können Sie den SP auch mithilfe von NaviSecCLI neu starten:
1. naviseccli –h <SP-IP> reboot
2. Bevor Sie den zweiten Speicherprozessor neu starten, müssen Sie
zunächst überprüfen, ob Sie sich bei Unisphere anmelden und das
Array verwalten können.
3. Wiederholen Sie Schritt 1 für den zweiten SP.
Verschlüsselungsstatus
Nach der Aktivierung generiert das System die erforderlichen Schlüssel und
startet den Verschlüsselungsprozess. Alle Daten im Array werden gelesen
und als verschlüsselte Daten zurück auf die Laufwerke geschrieben. Dieser
Prozess belegt SP-, Bus- und Laufwerksressourcen, wird aber automatisch
gedrosselt, um mögliche Einschränkungen der I/O-Performance auf dem
Host zu minimieren. Je nach Datenmenge und Systemnutzung kann der
Prozess zur Verschlüsselung des gesamten Arrays einige Zeit in Anspruch
nehmen. Während des Prozesses neu in das Array geschriebene Daten
werden nur dann in verschlüsselter Form geschrieben, wenn die Ziel-RAIDGruppe bzw. der Zielspeicherpool bereits umgewandelt wurde. Daraus
folgt, dass Sie sich vor Abschluss des migrationsfreien Upgrades nicht
darauf verlassen können, dass ein bestimmtes I/O in das Array verschlüsselt
ist. Darauf können Sie sich erst verlassen, wenn für das migrationsfreie
Upgrade gemeldet wird, dass 100 % der Daten verschlüsselt sind.
Obwohl für diesen Prozess nicht viel freier Speicherplatz benötigt wird, wird
die Umwandlung unter bestimmten Bedingungen angehalten. Dazu
gehören:
•
•
•
•
•
Fehlerhafte Festplatte
Beschreiben der Platte mit Nullen wird ausgeführt
Wiederherstellung der Platte wird ausgeführt
Überprüfung der Platte wird ausgeführt
Cache deaktiviert
Der Prozess wird automatisch wieder fortgesetzt, sobald die Ursache für
das Anhalten behoben ist.
19
Sie können den Status dieses Prozesses in Unisphere verfolgen, indem Sie zu
System  System Properties  Encryption navigieren, wie in Abbildung 6
dargestellt.
Abbildung 6
Verschlüsselungsstatus – Unisphere
Wie in Abbildung 7 dargestellt, können Sie den Verschlüsselungsstatus
auch überprüfen, indem Sie den folgenden NaviSecCLI-Befehl ausführen:
naviseccli –h <SP-IP> securedata –feature –info
20
Abbildung 7
Verschlüsselungsstatus – NaviSecCLI
Der derzeit im Array bereitgestellte Speicherplatz wird verschlüsselt, wenn
für Encryption Percentage (Prozentsatz der Verschlüsselung) der Wert 100%
erreicht wird. Anschließend ändert sich der Encryption Status
(Verschlüsselungsstatus) in Scrubbing. Durch diesen Prozess soll die Gefahr
ungeschützter Daten verringert werden, indem bereits vorhandene Daten
aus einer möglichen vorherigen Benutzung entfernt werden. Beispiele
hierfür sind nicht angebundene Laufwerke, die als Hot Spares verwendet
wurden, oder Laufwerke in Speicherpools oder RAID-Gruppen, die zerstört
wurden, bevor die Verschlüsselung aktiviert wurde.
Beim Scrubbing für angebundene Laufwerke wird der nicht belegte
Speicherplatz mit verschlüsselten Nullen beschrieben. Beim Erstellen einer
RAID-Gruppe mit Laufwerken unterschiedlicher Größe wird für die
überschüssige Kapazität ebenfalls ein Scrubbing mit verschlüsselten Nullen
durchgeführt. Bei ungebundenen Laufwerken erfolgt das Scrubbing mittels
eines normalen Beschreibens mit Nullen, da hiermit kein DEK verbunden ist.
Für jedes weitere Laufwerk, das nach der Aktivierung der Verschlüsselung
eingefügt wird, findet ebenfalls ein Scrubbing statt. Nach Abschluss des
Scrubbingprozesses ändert sich der Status in Encrypted (Verschlüsselt).
Keystore-Backup
Beim Keystore handelt es sich um einen Container, der alle DEKs im Array
enthält. Außerdem enthält das Array redundante Kopien des Keystore, um
die Verfügbarkeit der DEKs und der von ihnen geschützten Daten
sicherzustellen. Darüber hinaus haben Sie die Möglichkeit, eine
21
verschlüsselte Kopie des Keystore extern zu sichern, z. B. auf einem Laptop
oder einem PC, um den Keystore geheim zu halten. Es ist wichtig, ein
externes Backup des Keystore zu erstellen, da Daten nicht mehr zugänglich
sind, wenn auf den Keystore im Array nicht mehr zugegriffen werden kann
oder der Keystore beschädigt wird. (Dieser Fall ist unwahrscheinlich, aber
nicht unmöglich.) EMC bewahrt keine Backups der Keystores von Kunden
auf.
Das Array verfügt über einen internen Key Manager, den VNX Key
Manager. Externe Key Manager werden nicht unterstützt. Wenn neue
Laufwerke an einen Speicherpool oder eine RAID-Gruppe angebunden
werden, greift VNX Key Manager automatisch auf RSA BSAFE zurück, um
einen eindeutigen DEK für jedes neue Laufwerk zu generieren. Wenn ein
Speicherpool oder eine RAID-Gruppe gelöscht wird oder wenn ein
Laufwerk aus dem Array entfernt wird, werden zudem die zugehörigen
DEKs automatisch gelöscht.
Wenn ein Laufwerk ausfällt und ein Hot Spare übernimmt, wird für den Hot
Spare ein DEK generiert und der DEK für das ausgefallene Laufwerk wird
automatisch gelöscht. Wenn ein Laufwerk innerhalb des für eine HotSpare-Operation vorgesehenen Zeitfensters von fünf Minuten entfernt und
wieder eingesetzt wird, zieht dies keine Änderungen am Keystore nach
sich.
Jedes Mal, wenn eine Änderung am Keystore vorgenommen wird, sollte
ein neues Backup initiiert werden, da das vorherige Backup dann nicht
mehr alle Schlüssel enthält. In Unisphere wird so lange eine kritische
Warnmeldung angezeigt, bis ein neues Backup des Keystores initiiert wird,
wie in Abbildung 8 dargestellt. Dadurch wird sichergestellt, dass auf alle
Daten zugegriffen werden kann, sollte der unwahrscheinliche Fall
eintreten, dass eine Keystore-Wiederherstellung aus einem Backup
erforderlich wird.
22
Abbildung 8
Alarmmeldung für Keystore-Backup – Unisphere
Wie in Abbildung 9 dargestellt, können Sie überprüfen, ob ein neues
Keystore-Backup erforderlich ist, indem Sie den folgenden NaviSecCLIBefehl ausführen:
naviseccli –h <SP-IP> securedata –backupkeys –status
Abbildung 9
Keystore-Backupvorgang erforderlich – NaviSecCLI
Zum Initiieren eines neuen Keystore-Backups öffnen Sie Unisphere und
navigieren Sie zu System  Backup Keystore File (Datei für Keystore
Backup), wie in Abbildung 10 dargestellt.
23
Abbildung 10
Keystore-Backup – Unisphere
Wie in Abbildung 11 dargestellt, können Sie den Keystore auch sichern,
indem Sie den folgenden NaviSecCLI-Befehl ausführen:
naviseccli –h <SP-IP> securedata –backupkeys –retrieve –path
<Pfad>
24
Abbildung 11
Keystore-Backup – NaviSecCLI
Der Standarddateiname für das Keystore-Backup hat das folgende
Format:
<Seriennummer>_<Zeitstempel>_<Revision>.lbb
Dabei gilt Folgendes:
<Seriennummer> = Seriennummer des Arrays
<Zeitstempel> = Zeitstempel, der angibt, wann der Keystore gesichert
wurde
<Revision> = Hexadezimalwert, der sich bei jeder Änderung des Keystore
erhöht
Keystore-Wiederherstellung
Wenn auf keine der Kopien des Keystore im Array zugegriffen werden
kann, wird das System im Diagnosemodus gestartet und auf keine Daten
im System kann zugegriffen werden. Im Diagnosemodus geben
NaviSecCLI- und Unisphere-Meldungen die Ursache des Problems an und
fordern den Benutzer auf, Artikel 184709 der EMC Knowledgebase zu lesen,
wie in Abbildung 12 und Abbildung 13 dargestellt.
25
Abbildung 12
Diagnosemodus – Unisphere
Abbildung 13
Diagnosemodus – NaviSecCLI
Der Artikel in der EMC Knowledgebase enthält Informationen zur Situation
und gibt dem Benutzer eine Anleitung, wie er den EMC Support zur
Wiederherstellung kontaktieren kann. Damit auf das Array wieder
zugegriffen werden kann, muss der Keystore aus einem Backup
wiederhergestellt werden. Beachten Sie, dass in diesem Systemstatus keine
Unisphere- oder NaviSecCLI-Befehle verwendet werden können. Für die
Wiederherstellung ist ein Vorgang erforderlich, der nur vom EMC Support
ausgeführt werden kann. Während dieses Vorgangs werden die DEKs und
die verschlüsselten Daten dem EMC Support gegenüber nicht offengelegt.
26
Ein Keystore-Backup kann nur in dem Array erstellt werden, aus dem der zu
sichernde Keystore stammt. Falls eine Keystore-Wiederherstellung aus
einem Backup erforderlich ist, sollte nach Möglichkeit das letzte KeystoreBackup, das der aktuellen Arraykonfiguration entspricht, verwendet
werden. Im Notfall kann auch ein älteres Backup, das nicht genau der
Arraykonfiguration entspricht, verwendet werden. In diesem Fall werden
alle im Backup verfügbaren Schlüssel auf den entsprechenden Laufwerken
wiederhergestellt. Für alle neu angebundenen Laufwerke, die vom Backup
nicht abgedeckt sind, muss ein neuer Schlüssel generiert werden, wodurch
die Daten unlesbar werden. Wenn sich in der Keystore-Backupdatei
Schlüssel für Laufwerke befinden, die nicht mehr angebunden sind oder
aus dem Array entfernt wurden, werden diese Schlüssel nicht
wiederhergestellt.
Auditprotokoll
Ereignisse in Bezug auf D@RE werden in Auditprotokollen aufgezeichnet,
die so lange bestehen bleiben wie das Array. Die Protokolle werden in
privaten Bereichen im Array gespeichert und monatlich in einzelne Dateien
unterteilt. Die Protokolle beinhalten z. B. die folgenden Ereignisse:
•
•
•
•
•
•
Funktionsaktivierung
Schlüsselerstellung
Schlüssellöschung
Keystore-Backup
Keystore-Wiederherstellung
Hinzufügung eines 6-Gbit-SAS-UltraFlex-I/O-Moduls
Sie können das Auditprotokoll wie in Abbildung 14 dargestellt abrufen,
indem Sie den folgenden NaviSecCLI-Befehl ausführen:
naviseccli –h <SP-IP> securedata –auditlog -retrieve mmyyyy
–path <Pfad>
27
Abbildung 14
Abrufen des Auditprotokolls
Protokolle, die über NaviSecCLI aus dem Array abgerufen werden, dürfen
eine Größe von 100 MB nicht überschreiten. Ein Protokoll mit einer Größe
von 100 MB enthält ungefähr 1.500.000 Einträge. Wenn die Größe des
vollständigen Protokolls 100 MB überschreitet, werden beim Abrufen vom
Anfang des Protokolls ausgehend alle Zeilen übernommen, bis die
Ausgabedatei 100 MB erreicht. An den Dateinamen wird das Wort
„partial“ (teilweise) angehängt, um darauf hinzuweisen, dass es sich nicht
um ein vollständiges Protokoll handelt.
Zu jedem aus dem Array abgerufenen Protokoll gehört eine SHA-256-HASHDatei (mit der Erweiterung hsh). Überprüfen Sie mithilfe der HASH-Datei,
dass der Inhalt des Protokolls nicht geändert wurde.
In Fällen, in denen nur die Protokolldatei verfügbar ist oder ein
Administrator die Gültigkeit des Protokolls überprüfen möchte, kann die
zugehörige HASH-Datei separat aus dem Array abgerufen werden. Wie in
Abbildung 15 dargestellt, können Sie die HASH-Datei eines Auditprotokolls
abrufen, indem Sie den folgenden NaviSecCLI-Befehl ausführen:
naviseccli
–h
<SP-IP>
securedata
–auditlog
<Name_der_Auditprotokolldatei> –path <Pfad>
–cksum
28
Abbildung 15
Abrufen der Prüfsumme eines Auditprotokolls
Performance
Bei stabilen Bedingungen haben Verschlüsselungsfunktionen kaum
Auswirkungen auf den Softwarestapel bei normalen I/O-Operationen.
Abgesehen davon, dass einem I/O-Paket eine Schlüsselkennung
zugeordnet werden muss, sind nicht viele Aktionen erforderlich. Dies führt
zu einer hochgradig skalierbaren Lösung mit minimaler Beeinträchtigung
der Performance.
Bei der Konzeption von D@RE wurde darauf geachtet, dass die
Beeinträchtigung der Performance bei üblichen gemischten Workloads
minimal ist. Bei zufälligen und schreibintensiven Workloads sowie Workloads
mit kleinen Blöcken wird eine geringe (unter 5 %) oder keine
Beeinträchtigung erwartet. Allerdings kann es bei Workloads mit großen
Blöcken (über 256 KB) oder mit großer Bandbreite, die sich den
Kapazitätsgrenzen des Arrays annähern, zu einer zusätzlichen
Beeinträchtigung der Performance kommen.
Während des Umwandlungsprozesses zur Verschlüsselung vorhandener
Daten werden Daten gelesen und zurück auf die Laufwerke geschrieben,
wodurch SP-, Bus- und Laufwerksressourcen belegt werden. Dieser Prozess
wird automatisch gedrosselt, um eine mögliche Beeinträchtigung der I/OPerformance auf dem Host zu minimieren. Je nach Datenmenge und
Systemauslastung kann dieser Prozess einige Zeit in Anspruch nehmen.
29
D@RE ändert den Prozess des Beschreibens des Laufwerks mit Nullen je
nach Art der Verschlüsselung und gemäß der Anforderung, dass jeder
Block eindeutig sein muss. Das Beschreiben einer Platte mit Nullen erfordert
möglicherweise zusätzliche Bandbreite und weitere Ressourcen. Dieser
Prozess wird jedoch genauso wie das normale Beschreiben mit Nullen
automatisch gedrosselt, um die Beeinträchtigungen des I/O auf dem Host
zu minimieren.
Ersetzen von Hardware
Der generierte Keystore steht in Verbindung mit der Hardware. Fehler beim
Entfernen von Hardware können dazu führen, dass auf Daten nicht
zugegriffen werden kann. Wenn für ein Array mit aktivierter D@RE ein
Ersatzlaufwerk oder -speicherprozessor benötigt wird, kann das
Standardverfahren zum Ersetzen von VNX2-Hardware angewendet
werden.
Wenn ein 6-Gbit-SAS-UltraFlex-I/O-Modul hinzugefügt oder ersetzt werden
muss, kann ebenfalls das VNX2-Standardverfahren angewendet werden.
Allerdings müssen Sie nach Abschluss des Verfahrens den oder die
betroffenen Speicherprozessoren zusätzlich manuell neu starten.
In Fällen, in denen sowohl das Gehäuse als auch beide
Speicherprozessoren (SPs) ersetzt werden müssen, ist ein besonderes
Verfahren erforderlich, da der Keystore mit der Hardware verbunden ist.
Ersetzen Sie nicht beide SPs gleichzeitig. Behalten Sie stattdessen einen SP,
bis das Array wieder online ist, bevor Sie den zweiten SP ersetzen. Wenn die
Hardware bereits ersetzt wurde, können Sie alternativ mithilfe des EMC
Support den Keystore aus einem Backup wiederherstellen.
FIPS 140-2-Validierung
D@RE greift zum Generieren von Schlüsseln und Zufallszahlen sowie für das
Hashing auf ein FIPS 140-2-validiertes kryptografisches Modul (RSA BSAFE)
zurück. EMC beabsichtigt, die VNX2 D@RE-Hardwareverschlüsselung zur
Validierung auf Compliance mit FIPS 140-2 Ebene 1 einzureichen. Weitere
Einzelheiten hierzu werden bekannt gegeben, sobald die Validierung
erfolgreich abgeschlossen ist.
30
Fazit
Für die Arbeit in einer IT-Abteilung ist Datensicherheit sehr wichtig. Bösartige
Angreifer können Sicherheitslücken ausnutzen, um unbefugten Zugriff auf
private und vertrauliche Informationen zu erhalten. Dies kann für ein
Unternehmen verheerende finanzielle und rechtliche Folgen haben sowie
den guten Ruf nachhaltig beschädigen.
EMC VNX2 ermöglicht Ihnen die Nutzung von Data at Rest Encryption, um
dem Bedarf der meisten heutigen IT-Umgebungen an mehr Datensicherheit
Rechnung zu tragen. Dadurch können Sie sich besser darauf verlassen, dass
Informationen geschützt sind, auch wenn ein Laufwerk nicht mehr physisch
kontrolliert wird. Speicheradministratoren erhalten das beruhigende Gefühl,
dass ihre Daten sicher sind.
Referenzen
Die folgende Dokumentation ist auf der EMC Online Support-Website
verfügbar:
•
•
•
•
•
•
•
Einführung in die EMC VNX2-Serie
VNX MCx™: Multicore Everything™
EMC VNX Multicore FAST™ Cache
EMC VNX Unified Best Practices für Performance: Leitfaden zur
Anwendung von Best Practices
Sicherheitskonfigurationsleitfaden für VNX
VNX-Befehlszeilenoberflächen-Referenz für Block
Approaches for Encryption of Data-at-Rest in the Enterprise: A
Detailed Review
Die folgenden Dokumente sind online verfügbar:
•
•
•
•
IEEE P1619 – Standard für Verschlüsselungsschutz für Daten auf Blockorientierten Speichergeräten
NIST SP 800-88 – Guidelines for Media Sanitization
NIST SP 800-38E – Recommendation for Block Cipher Modes of
Operation: The XTS-AES Mode for Confidentiality on Storage Devices
RFC 3394 – Advanced Encryption Standard (AES) Key Wrap Algorithm
31

EMC VNX2: Data at Rest Encryption

Transcrição

Documentos relacionados

Personalbogen - SachsenCenter Stollberg

nevada - Web Möbel

EgoSecure Trainings mit Zertifizierung

Prozedurale Programmierung (PPG)

PDF Success Story Dietz

emc vnx vg8-gateway - EMC Deutschland GmbH

Stadtwerke Gießen - EMC Computer Systems Austria GmbH

Vorteile

Westcon Security Check Point Endpoint Datenblatt DE

Cleankeys-Tastatur