Sicheres Upgrade auf Vormetric Data Security Manager und nahtlose Migration zu CipherTrust Manager.

Die Aktualisierung des Vormetric Data Security Manager (DSM) , der Schlüssel- und Richtlinienverwaltungs-Appliance von Thales für Vormetric Transparent Encryption (VTE)-Umgebungen, mag auf den ersten Blick unkompliziert erscheinen. Doch wenn etwas schiefgeht, können die durch DSM-verwaltete Verschlüsselung geschützten Daten verloren gehen oder unzugänglich werden. Thales hat angekündigt, dass der Support für Vormetric DSM im Juni 2024 eingestellt wird. Daher ist die Migration zum CipherTrust Manager (CTM) für alle verbleibenden DSM-Nutzer eine dringende und geschäftskritische Entscheidung. Dieser Artikel bietet keine Schritt-für-Schritt-Anleitung für die Aktualisierung, sondern behandelt vielmehr die Aspekte, die Unternehmen beachten sollten: technische und nicht-technische Punkte, die im offiziellen Aktualisierungsleitfaden nicht ausreichend berücksichtigt werden, sowie die Herausforderungen, die DSM-Aktualisierungen und CTM-Migrationen in der Praxis mit sich bringen. Empfohlene Vorgehensweise: Dokumentieren Sie vor jeder Änderung Ihre vollständige Agentenliste und Kompatibilitätsmatrix, aktualisieren Sie Ihren DSM auf Version 6.4.5 oder 6.4.6, bevor Sie die CTM-Migration durchführen, und führen Sie vor der Produktivumstellung umfassende Pilottests in einer Nicht-Produktionsumgebung durch. Für den Kontext der Schlüsselverwaltung siehe CipherTrust Manager und Was ist Schlüsselverwaltung?

Kurzantwort: Welche zwei Wege gibt es und welcher trifft auf Sie zu?

Es gibt zwei unterschiedliche Vorgehensweisen: das Upgrade einer bestehenden DSM-Instanz auf eine neuere DSM-Version und die vollständige Migration von DSM zu CipherTrust Manager (CTM). Für die meisten Organisationen sind diese beiden Vorgehensweisen nicht alternativ, sondern sequenziell: Wenn Ihre DSM-Instanz noch nicht Version 6.4.5 oder 6.4.6 aufweist, müssen Sie DSM zuerst aktualisieren, bevor die Migrationstools Ihre Daten zu CTM übertragen können. Beide Vorgehensweisen bergen das Risiko von Datenverlust und Ausfallzeiten, wenn sie ohne sorgfältige Planung, eine Kompatibilitätsmatrix und Pilottests durchgeführt werden. CTM ist ein eigenständiges Produkt und nicht nur eine aktualisierte Version von DSM. Daher erfordert die Migration auch neue Betriebshandbücher, neue Standardarbeitsanweisungen, eine neue Architekturdokumentation und Schulungen für die Betriebsteams.

Planung: Was Sie vor dem Start dokumentieren sollten

Alles beginnt mit einer guten Planung, und das DSM-Upgrade bildet da keine Ausnahme. Ein vollständiger Scan der aktuellen Umgebung ist unerlässlich, um zukünftige Hindernisse oder Herausforderungen zu erkennen.

1. Dokumentieren Sie alle Agenten, Agentenversionen und Schutzpunkte. Beim Upgrade des DSM können Sie die Liste aller Agenten überprüfen und sicherstellen, dass alle Schutzpunkte aktiv und fehlerfrei sind. Sollten Abweichungen auftreten, ist möglicherweise eine Fehlerbehebung erforderlich, bevor Sie fortfahren. Die Agentenversionen geben zudem Aufschluss darüber, ob Agenten vorhanden sind, die mit der gewünschten DSM-Version inkompatibel sind. Eine Kompatibilitätsmatrix hilft Ihnen dabei, die kompatiblen und die zu aktualisierenden Agenten zu ermitteln. Aus dieser Bestandsaufnahme können Sie außerdem einen Upgrade-Pfad entwickeln. Thales definiert einen obligatorischen Upgrade-Pfad, der unbedingt eingehalten werden muss: Beispielsweise können Sie beim Upgrade von DSM 5.3 auf 6.2 nicht direkt auf Version 6.2 springen, ohne die Zwischenversion 6.0.0 zu verwenden.

2. Planen Sie die Produktionsumstellung. Viele Organisationen, die ein Upgrade planen, verfügen bereits über ein produktives DSM in ihrer Umgebung. Sie bevorzugen es in der Regel, das bestehende DSM nicht zu aktualisieren, sondern ein weiteres DSM in der Zielversion bereitzustellen, Pilottests durchzuführen und erst nach deren Abschluss auf das neue DSM als Produktionsinstanz umzuschalten. Organisationen sollten den Zeitpunkt der Umstellung, die Kommunikation und die Rollback-Verfahren planen, bevor sie mit den Upgrade-Arbeiten beginnen.

Durch eine sorgfältige Planung wird sichergestellt, dass die nachfolgenden Schritte reibungslos verlaufen und DSM ohne unerwartete Daten- oder Serviceunterbrechungen auf die gewünschte Version aktualisiert werden kann.

Aktualisierung von DSMs: Herausforderungen in der Praxis

Eine gute Planung kann den Upgrade-Prozess erleichtern, doch die Aktualisierung eines produktiven DSM-Systems bringt häufig Herausforderungen ans Licht, die in der Planungsphase nicht erkennbar waren. Zu den Herausforderungen, die bei realen Produktions-Upgrades auftreten, gehören:

1. Die Umstellung vom alten auf das neue DSM ohne Unterbrechung der Agentenregistrierung erfordert eine sorgfältige Orchestrierung der Agenten-Neuregistrierungssequenz.
2. Ein Upgrade von DSM auf eine Version, bei der alle vorhandenen Agenten weiterhin kompatibel sind, ist besonders empfehlenswert, wenn die Umgebung eine Mischung von Agentenversionen aus verschiedenen Epochen umfasst.
3. Die Konfiguration von Hochverfügbarkeitsclustern (HA-Clustern) mit DSMs in verschiedenen Subnetzen führt zu Komplexitäten in der Netzwerk- und Cluster-Synchronisierung, die in der grundlegenden Upgrade-Dokumentation nicht behandelt werden.
4. Planung der Upgrade-Dauer: DSM-Upgrades können je nach Umgebungsgröße erhebliche Zeit in Anspruch nehmen, und ohne eine ordnungsgemäße Umstellungsplanung kann es zu ungeplanten Ausfallzeiten von Produktionssystemen kommen; mit angemessener Planung kann die DSM-Umstellung nahtlos und ohne Ausfallzeiten erfolgen.

Organisationen sollten sich umfassend auf die Aktualisierung von DSMs vorbereiten, da ein Fehler im Aktualisierungsprozess dazu führen kann, dass verschlüsselte Daten dauerhaft unzugänglich werden.

Migration zu CipherTrust Manager

Thales gab bekannt, dass Vormetric DSM im Juni 2024 eingestellt wird. Daher migrieren Unternehmen ihre DSM-Systeme zu CipherTrust Manager . Die Migration von DSM zu CTM bringt jedoch neue Herausforderungen mit sich: CTM ist ein eigenständiges Produkt und nicht nur ein aktualisiertes DSM. Die Migration erfordert neben der technischen Migration von Schlüsseln, Richtlinien und Konfigurationen auch die Entwicklung neuer Betriebsabläufe.

Zu den häufigsten Bedenken von Unternehmen bei der Planung einer CTM-Migration gehören:

• Migration von Richtlinien, Schlüsseln, Benutzergruppen und Prozessgruppen: Welche Objekte werden übernommen und welche müssen neu erstellt werden?
• Migration von Hosts und Agenten-Neuregistrierung zu CTM
• Hochverfügbarkeitskonfiguration in der CTM-Architektur, die sich von DSM HA unterscheidet
• Ausfallzeiten und Systemstörungen während des Migrationszeitraums
• Datenverlustrisiko durch fehlerhafte Schlüsselmigration oder Guardpoint-Konfigurationsfehler

Wenn Organisationen bereits DSM 6.4.5 oder 6.4.6 verwenden, können sie zu CipherTrust Manager migrieren und die folgenden Objekte wiederherstellen:

1. Agentenschlüssel, einschließlich versionierter Schlüssel und über KMIP zugänglicher Agentenschlüssel
2. Tresorschlüssel
3. Bring Your Own Keys (BYOK)-Objekte
4. Domains
5. CipherTrust Transparent Encryption (CTE)-Konfiguration

Objekte, die während der Migration NICHT wiederhergestellt werden

1. Most Schlüsselverwaltung KMIP-Schlüssel (Interoperability Protocol), mit Ausnahme von KMIP-zugänglichen Agentenschlüsseln
2. Schlüssel, die mit CipherTrust Cloud Key Manager (CCKM) verknüpft sind, einschließlich Schlüsselmaterial als Dienstleistung (KMaaS)-Schlüssel
3. DSM-Hostname und Hostkonfiguration

Die fehlende Migration von Standard-KMIP- und CCKM-Schlüsseln ist eine der am häufigsten unterschätzten Schwachstellen. Organisationen mit KMIP-basierten Integrationen müssen vor Beginn der Migration planen, wie diese Integrationen in CTM wiederhergestellt werden. Bei der Migration von Kunden sind umfassende Pilottests unerlässlich, um einen verlustfreien Ablauf zu gewährleisten. Kunden sollten vor der Migration außerdem eine Bereinigung des DSM durchführen und alle außer Betrieb genommenen Server und inaktiven Benutzer entfernen, damit nur gültige, aktuelle Konfigurationen in CTM übernommen werden. Bei der Migration von DSM zu CTM müssen Agenten, die VTE-Agenten unter Version 7.0 verwenden, vor der Migration auf CipherTrust Transparent Encryption (CTE) aktualisiert werden.

Vorteile der Migration zu CipherTrust Manager

1. Verbesserte browserbasierte Benutzeroberfläche, die die ältere DSM-Oberfläche ersetzt
2. Keine Hypervisor-Beschränkung: CTM unterstützt die Bereitstellung in physischen und virtuellen Umgebungen ohne die Hypervisor-Beschränkungen von DSM.
3. Vollständig ausgestattete Remote-CLI-Schnittstelle für das operative Management
4. Eingebetteter CipherTrust Cloud Key Manager (CCKM) für einheitliches Cloud-Schlüsselmanagement über AWS, Azure, GCP und andere Cloud-Anbieter hinweg.
5. Verbesserte Schlüsselverwaltungsfunktionen mit KMIP-Schlüsselmaterial: Richtlinien, Protokollierung und Verwaltung werden in einer vereinfachten und umfassenderen KMIP-Benutzeroberfläche integriert.
6. Unterstützt CTE-Agenten (ehemals VTE-Agenten) ab Version 7.0 und bietet damit einen klaren Weg für die Verwaltung verschlüsselter Hosts.
7. Neue REST-API für die Automatisierung, die die Integration mit DevOps-Toolchains und Sicherheitsorchestrierungsplattformen ermöglicht.

Über diese plattformweiten Verbesserungen hinaus bietet CTM auch spezialisierte Funktionen, die es wert sind, in Betracht gezogen zu werden:

1. Passwort- und PED-Authentifizierung: Ähnlich wie bei der Luna HSM der S-Serie bietet Thales für CTM die Wahl zwischen Passwort und PIN-Eingabegerät (PED) als Authentifizierungsmechanismen. Die PED-Authentifizierung bietet erhöhte Sicherheit, ist jedoch nur für physische Geräte der Serie k570 verfügbar.
2. Multi-Cloud- und Hybridbereitstellung: CTM unterstützt die Bereitstellung in Multi-Cloud-Umgebungen, darunter AWS, Azure, GCP, VMware, Hyper-V und Oracle VM. Unternehmen können zudem Hybridcluster bilden, die physische und virtuelle Appliances für Hochverfügbarkeitsumgebungen kombinieren und so eine Bereitstellungsflexibilität bieten, die DSM nicht unterstützte.

DSM-Upgrade vs. CTM-Migration: Entscheidungstabelle

Szenario	Empfohlene Maßnahme	Wichtige Voraussetzung	Primäres Risiko
DSM unter 6.4.5 und noch keine geplante CTM-Migration	Aktualisieren Sie DSM auf Version 6.4.5 oder 6.4.6 mithilfe des obligatorischen Thales-Upgrade-Pfads.	Vollständiges Agenten- und Wachpunktinventar; Kompatibilitätsmatrix	Agenteninkompatibilität; Guardpoint-Unterbrechung während des Upgrades
DSM auf Version 6.4.5 oder 6.4.6 und Planung der CTM-Migration	Führen Sie vor der Produktionsmigration einen umfassenden CTM-Pilotversuch in der Nicht-Produktionsumgebung durch.	Alle VTE-Agenten unter Version 7.0 auf CTE aktualisieren; DSM-Bereinigung vor der Migration	Nicht migrierte KMIP-Schlüssel führen nach der Migration zu fehlerhaften Integrationen.
DSM mit signifikanten KMIP-Integrationen	Vor der Migration alle KMIP-Integrationen erfassen; Wiederherstellung in CTM planen.	Identifizieren Sie alle KMIP-Schlüssel, die nicht migriert werden, und planen Sie die erneute Registrierung.	KMIP-abhängige Anwendungen verlieren nach der Migration den Zugriff auf wichtige Schlüssel.
DSM in HA-Konfiguration auf verschiedenen Subnetzen	Beauftragen Sie Encryption Consulting mit der architekturspezifischen Migrationsplanung.	Dokumentieren Sie alle Details der HA-Netzwerkkonfiguration; planen Sie das Subnetz-Routing.	Fehlkonfiguration des HA-Clusters führt zu Split-Brain- oder Synchronisationsfehlern
DSM hat bereits das Ende seines Lebenszyklus überschritten und es gibt keinen Migrationsplan.	Beginnen Sie unverzüglich mit der Migrationsplanung; priorisieren Sie nach der Kritikalität der Daten.	Zugriff auf Thales-Support und -Dokumentation; Überprüfung des Upgrade-Pfads	Nicht unterstützte DSM-Version führt zu Compliance- und Sicherheitsrisiken

Checkliste vor der Migration

• Dokumentieren Sie alle DSM-Agenten, Agentenversionen und Schutzpunkte; erstellen Sie ein vollständiges Agenteninventar, bevor Sie mit einem Upgrade oder einer Migration beginnen.
• Erstellen Sie eine Kompatibilitätsmatrix, die bestätigt, welche Agenten mit der Zielversion von DSM oder CTM kompatibel sind.
• Überprüfen Sie den obligatorischen DSM-Upgrade-Pfad und ermitteln Sie alle Zwischenversionen, die zum Erreichen der Zielversion erforderlich sind.
• Vergewissern Sie sich vor Beginn der CTM-Migration, dass die DSM-Version 6.4.5 oder 6.4.6 ist; aktualisieren Sie DSM zuerst, falls es sich um eine ältere Version handelt.
• Aktualisieren Sie alle VTE-Agenten unterhalb der Version 7.0 auf CipherTrust Transparent Encryption (CTE)-Agenten vor der CTM-Migration.
• Führen Sie eine DSM-Bereinigungssitzung durch: Entfernen Sie vor der Migration alle außer Betrieb genommenen Server, inaktiven Benutzer, veralteten Richtlinien und nicht verwendeten Objekte.
• Identifizieren Sie alle KMIP- und CCKM-Schlüssel in DSM, die nicht zu CTM migriert werden; planen Sie die Wiederherstellung dieser Integrationen in CTM.
• Richten Sie eine CTM-Instanz außerhalb der Produktionsumgebung ein und führen Sie eine umfassende Pilotmigration durch, bevor Sie das produktive DSM anfassen.
• Vor der Planung der Produktionsmigration sollten alle Schutzpunkte und die Zugänglichkeit wichtiger Schlüssel in der CTM-Pilotumgebung überprüft werden.
• Planen Sie den Zeitpunkt der Produktionsumstellung mit definierten Wartungsfenstern und informieren Sie alle relevanten Geschäftspartner über die zu erwartenden Auswirkungen auf den Service.
• Dokumentieren Sie alle neuen CTM-Runbooks, Standardarbeitsanweisungen und Architekturdokumentationen vor dem Produktionsstart.
• Planen Sie die CTM-HA-Konfiguration für den Produktivbetrieb; testen Sie das HA-Failover in der Nicht-Produktionsumgebung vor der Produktionsbereitstellung.

Fazit

Die Aktualisierung von DSM kann komplex sein und erfordert sorgfältige Planung und Fehlerbehebung. Die Migration zu CTM ist deutlich komplexer, da CTM ein eigenständiges Produkt und nicht einfach ein aktualisiertes DSM ist. Unternehmen, die migrieren, müssen neben der technischen Migration von Schlüsseln und Konfigurationen neue Betriebshandbücher, Standardarbeitsanweisungen und Architekturdokumente erstellen. Da DSM im Juni 2024 das Ende seines Lebenszyklus erreicht, sind Unternehmen, die weiterhin DSM nutzen, einem erhöhten Risiko durch eine nicht mehr unterstützte Plattform ausgesetzt und sollten die Migrationsplanung umgehend priorisieren. Encryption Consulting unterstützt Kunden bei der Planung, Aktualisierung und Migration ihrer bestehenden DSM-Systeme. Als zertifizierter Partner von Thales und langjähriger Partner von Vormetric bei Implementierungen und Aktualisierungen kann Encryption Consulting eine umfassende Migration zu CipherTrust Manager planen und Gap-Analysen sowie eine Vorplanung durchführen, um Datenverlust, Ausfallzeiten und Produktionsprobleme zu vermeiden. Kontaktieren Sie uns für weitere Informationen unter [email protected].

Quellen:

• CipherTrust-Plattform-Dokumentationsportal: DSM-Migration (thalesdocs.com)
• CipherTrust-Plattform-Dokumentationsportal: CTE-DSM-Migration (thalesdocs.com)

Häufig gestellte Fragen

Was ist Vormetric Data Security Manager (DSM) und was ist CipherTrust Manager (CTM)?

Vormetric Data Security Manager (DSM) ist die Schlüssel- und Richtlinienverwaltungs-Appliance von Thales, die Verschlüsselungsschlüssel, Richtlinien, Benutzergruppen, Prozessgruppen und Schutzpunkte für VTE-Agenten auf geschützten Hosts verwaltet. CipherTrust Manager (CTM) ist die Datensicherheitsmanagement-Plattform der nächsten Generation von Thales, die DSM ersetzt. Sie bietet eine moderne, browserbasierte Benutzeroberfläche, keine Hypervisor-Beschränkungen, integriertes CCKM für die Cloud-Schlüsselverwaltung, verbesserte KMIP-Funktionen, CTE-Agentenunterstützung ab Version 7.0 und eine REST-API für die Automatisierung. Thales gab bekannt, dass DSM im Juni 2024 eingestellt wird.

Welche Objekte werden von DSM zu CipherTrust Manager migriert und welche nicht?

Objekte, die von DSM 6.4.5 oder 6.4.6 zu CTM migriert werden, umfassen: Agentenschlüssel (einschließlich versionierter Schlüssel und über KMIP zugänglicher Agentenschlüssel), Vault-Schlüssel, BYOK-Objekte, Domänen und CTE-Konfigurationen. Objekte, die nicht migriert werden, umfassen: die meisten KMIP-Schlüssel (mit Ausnahme von über KMIP zugänglichen Agentenschlüsseln), CCKM- und KMaaS-Schlüssel sowie DSM-Hostnamen und Hostkonfigurationen. Die fehlende Migration von Standard-KMIP-Schlüsseln ist eine der am häufigsten unterschätzten Lücken in der Migrationsplanung.

Welche DSM-Version muss eine Organisation vor der Migration zu CipherTrust Manager verwenden?

Organisationen müssen DSM Version 6.4.5 oder 6.4.6 verwenden, bevor sie zu CTM migrieren können. Bei einer älteren Version muss DSM zunächst über den obligatorischen Thales-Upgrade-Pfad auf Version 6.4.5 oder 6.4.6 aktualisiert werden. Darüber hinaus müssen alle VTE-Agenten unterhalb der Version 7.0 auf CTE-Agenten aktualisiert werden, bevor die CTM-Migration erfolgen kann.

Was sind die größten Risiken bei einem DSM-Upgrade oder einer CTM-Migration?

Die größten Risiken sind: Datenverlust durch Fehler bei der Migration von Schutzpunkten oder Schlüsseln, wodurch verschlüsselte Daten dauerhaft unzugänglich werden; Produktionsausfallzeiten aufgrund schlecht geplanter Umstellungszeiten; Inkompatibilität von Agenten mit der Zielversion von DSM oder CTM; und Konfigurationslücken in KMIP-Integrationen, die abhängige Anwendungen nach der Migration beeinträchtigen. Diese Risiken werden durch eine vollständige Bestandsaufnahme vor dem Upgrade, die Entwicklung einer Kompatibilitätsmatrix, paralleles Staging für Upgrade-Tests, die Bereinigung des DSM vor der Migration und umfassende Pilottests vor jeder Produktionsumstellung minimiert.

Kann ein DSM-Upgrade oder eine CTM-Migration ohne Ausfallzeiten durchgeführt werden?

Ein DSM-Cutover kann ohne Produktionsausfall durch ein paralleles Upgrade erfolgen, bei dem ein neues DSM in der Zielversion gestartet und die Agenten ohne Unterbrechung umgestellt werden. Eine Migration von DSM zu CTM erfordert ein anderes Produkt und eine andere Architektur und typischerweise geplante Wartungsfenster für spezifische Migrationsvorgänge. Die Ausfallzeit hängt von der Komplexität der Umgebung, der Anzahl der Agenten und der Möglichkeit einer gestaffelten Migration ab.