CipherTrust Manager-Sicherungsfehler

Veröffentlicht: März 2023. Aktualisiert: August 2026. Geprüft vom Key Management Engineering Team von Encryption Consulting.

Ein fehlgeschlagenes Backup von CipherTrust Manager ist kein kosmetischer Fehler. Er bedeutet, dass im Falle eines Verlusts, einer Beschädigung oder einer notwendigen Neuinstallation des Systems keine verifizierte Möglichkeit besteht, die Schlüssel, Richtlinien und den Prüfverlauf wiederherzustellen. Dieser Leitfaden erläutert die Ursachen des Backup-Fehlers, dessen Behebung in einem laufenden Cluster sowie die betrieblichen Maßnahmen (z. B. Verantwortlichkeiten, Rotation, Zugriffskontrolle, Prüfprotokolle), die ein erneutes Auftreten verhindern.

Was verursacht Backup-Fehler bei CipherTrust Manager?

Die meisten Backup-Fehler von CipherTrust Manager lassen sich auf eine von drei Hauptursachen zurückführen: einen fehlenden oder nicht übereinstimmenden Backup-Schlüssel auf dem Knoten, auf dem der Auftrag ausgeführt wird, eine Richtlinienvoraussetzung, die vor dem Backup-Start nicht erfüllt wurde, oder eine Kompatibilitätsbeschränkung für Version und Wiederherstellung. CipherTrust Manager behandelt jedes Backup als lokales Artefakt, das mit einem bestimmten Schlüssel verschlüsselt ist, und synchronisiert Backups oder Backup-Schlüssel nicht automatisch clusterweit. Laut der Dokumentation von Thales werden „Backups und Backup-Schlüssel nicht automatisch auf andere Knoten in einem Cluster kopiert. Sie existieren nur auf dem Knoten, auf dem sie erstellt oder kopiert wurden.“ Sobald dieses Verhalten verstanden ist, erweisen sich die meisten Backup-„Fehler“ als Lücken in der Schlüsselverteilung und nicht als Funktionsfehler.

Betrachten wir einen CipherTrust Manager-Cluster mit vier Knoten (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com). Gemäß Standardverfahren wird auf einem Knoten ein System-Backup-Zeitplan erstellt, dessen Metadaten auf die anderen Knoten repliziert werden. Der Backup-Schlüssel wird jedoch nicht repliziert. Wird der geplante Auftrag auf einem Knoten ausgeführt, der den Schlüssel nie erhalten hat, schlägt der Auftrag fehl.

Häufige Fehlerszenarien und ihre Ursachen

Dies ist das Szenario, das Encryption Consulting am häufigsten beobachtet, und es steht im Mittelpunkt der folgenden Schritt-für-Schritt-Anleitung zur Fehlerbehebung. Der Hauptgrund für diesen Fehler ist, dass geplante Backups auf dem Knoten ausgeführt werden, der den Auftrag gerade ausführt. Wenn auf diesem Knoten der Backup-Schlüssel nicht vorhanden und als Standardknoten gekennzeichnet ist, kann der Auftrag die Backup-Datei nicht verschlüsseln und schlägt daher fehl.

Eine Handvoll anderer Backup- und Wiederherstellungsfehler treten regelmäßig genug auf, um sie zusammen mit diesem zu dokumentieren; alle bestätigt anhand der Administratordokumentation des CipherTrust Managers von Thales:

• Der Backup-Vorgang schlägt ohne Fehlermeldung fehl, es wird keine Datei erstellt. Die Dokumentation von Thales besagt, dass „alle Quorumrichtlinien vor dem Erstellen einer Sicherung deaktiviert werden müssen“. Eine auf dem Knoten aktivierte Quorumrichtlinie blockiert den Auftrag, bevor er ausgeführt werden kann.
• Die Datensicherung wurde abgeschlossen, die Wiederherstellung schlägt jedoch aufgrund eines Schlüsselfehlers fehl. Der zum Wiederherstellungszeitpunkt verwendete Sicherungsschlüssel stimmt nicht mit dem Schlüssel überein, mit dem die Datei verschlüsselt wurde. Dies geschieht, wenn ein Administrator einen beliebigen Sicherungsschlüssel von einem anderen Knoten verwendet, anstatt den zum Zeitpunkt der Sicherung auf dem Quellknoten aktiven Schlüssel.
• Die Wiederherstellung auf einem bestehenden Clusterknoten wurde abgelehnt. Systemsicherungen sind nicht für die Wiederherstellung auf einem aktiven Clusterknoten ausgelegt. Thales empfiehlt in diesem Fall, den Cluster zu entfernen und neu aufzubauen, anstatt ihn direkt wiederherzustellen.
• Die Wiederherstellung wird versionsübergreifend abgelehnt. CipherTrust Manager-Backups werden standardmäßig auf die drei nächsthöheren Nebenversionen wiederhergestellt (beispielsweise lässt sich ein 2.6-Backup problemlos auf 2.7, 2.8 oder 2.9 wiederherstellen). Die Wiederherstellung eines älteren Backups erfordert einen --force Thales empfiehlt, vor der Nutzung dieser Option den Support zu kontaktieren.
• Der Sicherungs- oder Wiederherstellungsbefehl schlägt mit einem Besetzt- oder Sperrfehler fehl. Auf CipherTrust Manager kann jeweils nur ein Sicherungs- oder Wiederherstellungsvorgang ausgeführt werden. Ein zweiter Auftrag, der während eines laufenden Vorgangs gestartet wird, wird abgelehnt.
• Ein Backup, das an einen HSM-Vertrauensstamm gebunden ist, wird unbrauchbar. System-Backups können optional zum zusätzlichen Schutz an einen HSM-Root-of-Trust-Key gebunden werden. Wird dieser HSM-Key jedoch später gelöscht, kann das darauf basierende Backup nicht wiederhergestellt werden.

So beheben Sie den CipherTrust Manager-Sicherungsfehler (Schritt für Schritt)

Um den Fehler „NCERRInvalidParamValue“ beim Backup-Schlüssel zu beheben, muss ein standardmäßiger System-Backup-Schlüssel erstellt und auf jeden Knoten im Cluster verteilt werden. Dadurch wird der Zeitplan unabhängig vom Knoten, auf dem der Job ausgeführt wird, erfolgreich abgeschlossen. Die folgenden Schritte setzen voraus, dass der Zeitplan ursprünglich von thales01.ec.com erstellt wurde.

1. Navigieren Sie auf thales01.ec.com zu Backup Keys unter Admin Settings.

   

2. Erstellen Sie einen neuen Systemsicherungsschlüssel und legen Sie ihn als Standard fest.

   

3. Laden Sie den neu erstellten Systemsicherungsschlüssel herunter, damit er auf die anderen CipherTrust Manager-Clusterknoten hochgeladen werden kann.

   

4. Geben Sie ein Passwort für den Sicherungsschlüssel ein und klicken Sie auf „Herunterladen“.

   

5. Folgen Sie diesem Pfad, um den Systemsicherungsschlüssel auf jedem Knoten des CipherTrust Manager-Clusters hochzuladen: Administratoreinstellungen > Sicherungsschlüssel > Sicherungsschlüssel hinzufügen > Sicherungsschlüssel hochladen. Wählen Sie die heruntergeladene Datei aus und geben Sie das Passwort aus dem vorherigen Schritt ein.

   

6. Sobald der Upload erfolgreich war, klicken Sie auf das Überlaufsymbol und wählen Sie bei jedem Knoten „Als Standard festlegen“.

   

7. Navigieren Sie zu Administratoreinstellungen > Zeitpläne, um eine systemweite Datensicherung zu konfigurieren.

   

8. Klicken Sie auf „Zeitplan hinzufügen“.

   

9. Wählen Sie „Systemsicherung“ und klicken Sie auf „Weiter“.

   

10. Geben Sie einen Terminnamen ein und klicken Sie auf „Weiter“.

    

11. Stellen Sie die Sicherungshäufigkeit ein und klicken Sie auf „Weiter“.

    

12. Legen Sie die Anzahl der aufzubewahrenden Backups fest und wählen Sie „Standard-Backup-Schlüssel verwenden“. Durch die Verwendung des Standardschlüssels kann der Zeitplan unabhängig vom Clusterknoten, auf dem der Auftrag ausgeführt wird, erfolgreich ausgeführt werden, da nun überall derselbe Schlüssel vorhanden ist.

    

Falls der Auftrag auch dann noch fehlschlägt, nachdem jeder Knoten denselben Standardschlüssel hat, deaktivieren Sie vor dem nächsten geplanten Lauf alle aktiven Quorumrichtlinien und vergewissern Sie sich, dass auf diesem Knoten kein anderer Sicherungs- oder Wiederherstellungsauftrag bereits ausgeführt wird.

Zuständigkeit für die Backup-Verwaltung und -Planung

Der Fehler NCERRInvalidParamValue deutet in der Regel auf einen fehlenden Besitzer hin, nicht nur auf einen fehlenden Schlüssel. Wenn niemand die erfolgreiche Durchführung eines Backups bestätigt, bleiben Lücken in der Schlüsselverteilung unbemerkt, bis eine Wiederherstellung tatsächlich erforderlich ist. Ein praktikables Besitzmodell für einen CipherTrust Manager-Cluster umfasst Folgendes:

• Ein benannter Backup-Besitzer (einzeln oder im Rahmen einer Rufbereitschaftsrotation), der für jeden Knoten im Cluster verantwortlich ist, nicht nur für den Knoten, auf dem der Zeitplan erstellt wurde.
• Ein dokumentiertes Runbook, das auflistet, welcher Knoten aktuell welchen Standard-Backup-Schlüssel enthält und jedes Mal aktualisiert wird, wenn ein Knoten hinzugefügt, neu erstellt oder entfernt wird.
• Eine regelmäßig wiederkehrende Überprüfung, mindestens wöchentlich, die bestätigt, dass die letzte geplante Datensicherung tatsächlich auf jedem Knoten abgeschlossen wurde, und nicht nur auf dem Knoten, auf dem sie zufällig ausgeführt wurde.
• Ein klarer Eskalationsweg, wenn eine geplante Datensicherung zweimal hintereinander fehlschlägt, anstatt Fehlermeldungen ungelesen anzuhäufen.

Rotationsauslöser für Backup-Verschlüsselungsschlüssel

Ein Backup-Schlüssel ist ein kryptografischer Schlüssel wie jeder andere CipherTrust Manager-Schlüssel und sollte nach festgelegten Kriterien ausgetauscht werden, anstatt ihn unbegrenzt beizubehalten. Encryption Consulting empfiehlt, den System-Backup-Schlüssel zu wechseln, wenn einer der folgenden Fälle eintritt:

• Ein Administrator, der Zugriff auf die Sicherungsschlüsseldatei oder deren Passwort hatte, verlässt das Team oder wechselt die Rolle.
• Die Wiederherstellung schlägt fehl, weil der falsche Sicherungsschlüssel verwendet wurde, was oft darauf hindeutet, dass das Schlüsselinventar veraltet ist.
• Ein Clusterknoten wird außer Betrieb genommen oder ersetzt, da auch seine lokale Kopie des Sicherungsschlüssels entfernt werden muss.
• Die übergeordnete Richtlinie der Organisation zur Schlüsselrotation sieht dies im gleichen Rhythmus vor, der auch für anderes langlebiges kryptografisches Material gilt.
• Ein Backup-Schlüssel wurde an einen HSM-Root-of-Trust-Schlüssel gebunden, der selbst rotiert oder außer Betrieb genommen wird, da die Dokumentation von Thales bestätigt, dass ein HSM-gebundenes Backup nicht wiederhergestellt werden kann, sobald dieser Root-of-Trust-Schlüssel gelöscht ist.

Nach der Rotation muss der neue Standardschlüssel weiterhin manuell auf jeden Clusterknoten übertragen werden, genau wie der ursprüngliche Schlüssel im oben beschriebenen Fix verteilt wurde. Wenn man die Rotation nur auf einem Knoten durchführt und die anderen ignoriert, tritt der ursprüngliche Fehler unter einem neuen Schlüssel erneut auf.

Zugriffsrichtlinie: Wer kann eine Datensicherung auslösen oder wiederherstellen?

Das Zugriffsmodell von CipherTrust Manager basiert auf Domänen und rollenbasierten Gruppen. Backup-Aktionen müssen daher streng auf diese Domänen beschränkt sein. Die Dokumentation von Thales stellt klar, dass das Herunterladen von Protokolldateien aus der Stammdomäne auf bestimmte Gruppen beschränkt ist: „Nur Benutzer der Gruppen ‚Systemadministratoren‘ und ‚Administratoren‘ können die Protokolldateien aus der Stammdomäne herunterladen.“ Dasselbe Prinzip gilt für das Erstellen und Wiederherstellen von Backups, da bei einem System-Backup die Schlüssel aller Domänen gleichzeitig bearbeitet werden.

Eine solide Zugriffsrichtlinie für Backup-Vorgänge hält die Gruppe, die Backup-Schlüssel erstellen oder hochladen kann, klein und trennt sie von den Benutzern, die täglich die Schlüssel verwalten. Sie erfordert eine zweite Genehmigung, bevor eine Wiederherstellung auf einem Produktionscluster durchgeführt wird, und stellt sicher, dass niemals ein undokumentiertes Backup-Schlüsselpasswort in einer Chatnachricht oder einem Ticket gespeichert wird. Die Wiederherstellung ist die risikoreichere der beiden Aktionen: Eine fehlerhafte Wiederherstellung kann Schlüssel, Richtlinien und Benutzer im gesamten System auf einen veralteten Zustand zurücksetzen.

Prüfnachweise für Erfolg und Misserfolg der Datensicherung

Ein Backup-Zeitplan, der „normalerweise funktioniert“, ist für einen Auditor kein Beweis. Die Systemprotokolle von CipherTrust Manager zeichnen administrative Aktionen, Konfigurationsänderungen sowie erfolgreiche und fehlgeschlagene Vorgänge auf und bilden somit das Rohmaterial für Backup-Audits. Die Protokolle können über die grafische Benutzeroberfläche unter „Admin-Einstellungen“ > „Protokolle“ oder über die entsprechende Schnittstelle abgerufen werden. ksctl logs download Das Befehlszeilentool und die heruntergeladenen Protokolle sind durch einen SHA-256-Hash, der mit einem asymmetrischen Schlüsselpaar signiert wurde und mit OpenSSL verifiziert werden kann, integritätsgeschützt.

Für einen nachvollziehbaren Backup-Prozess sollten diese Protokolle an ein zentrales SIEM-System oder einen Protokollspeicher weitergeleitet werden, anstatt sich ausschließlich auf die CipherTrust Manager-Konsole zu verlassen. Der Abschlussstatus jedes geplanten Backups muss für die Dauer der gesetzlichen Aufbewahrungsfrist des Unternehmens dokumentiert werden. Zudem ist jede Schlüsselrotation und jede Wiederherstellung, einschließlich der Genehmigung durch den jeweiligen Autor, separat zu protokollieren. Diese Nachweise machen die Aussage „Wir haben Backups“ im Falle eines Audits oder nach einem Vorfall zu einer stichhaltigen Antwort.

Plattformvergleich: Manuelle Datensicherung vs. automatisierte/geplante Datensicherung

CipherTrust Manager unterstützt sowohl manuelle Backups auf Abruf als auch wiederkehrende Backups. Die beiden Optionen sind betrieblich nicht austauschbar, und die meisten Organisationen benötigen beide.

Faktor	Manuelle Sicherung	Automatisierte/geplante Datensicherung
Auslösen	Führen Sie diese Aktion vor einem geplanten Änderungs-, Upgrade- oder Wartungsfenster von einem Administrator aus.	Wird in einem festgelegten Intervall ausgeführt, unabhängig davon, ob ein Administrator die Funktion überwacht.
Konsistenz	Hängt davon ab, dass jemand daran denkt, es auszuführen.	Die Konsistenz ist gegeben, solange die Voraussetzungen für den Backup-Schlüssel und das Quorum auf dem Knoten, auf dem der Job ausgeführt wird, korrekt festgelegt sind.
Fehlersichtbarkeit	Ein Fehler wird sofort vom Administrator bemerkt, der das System betrieben hat.	Ein Fehler kann über einen gesamten Zyklus unbemerkt bleiben, wenn kein Warn- oder Überprüfungsprozess eingerichtet ist.
Audit-Trail	Einmaliges Ereignis, einfach einzeln zu dokumentieren	Erfordert einen regelmäßigen Protokollprüfungsprozess, um die fortlaufende Abdeckung nachzuweisen.
Am besten geeignet für	Snapshots vor der Änderung und vor dem Upgrade	Routinemäßige Notfallwiederherstellungsabdeckung zwischen Änderungen

Reaktion auf einen Vorfall, wenn während eines DR-Ereignisses ein Backup-Fehler festgestellt wird

Der ungünstigste Zeitpunkt, um festzustellen, dass ein Backup von CipherTrust Manager unbemerkt fehlgeschlagen ist, ist mitten in einer Notfallwiederherstellungsmaßnahme, wenn keine Zeit mehr bleibt, die zugrundeliegende Lücke in der Schlüsselverteilung zu beheben. Gehen Sie in diesem Fall wie folgt vor:

1. Identifizieren Sie jeden Knoten im Cluster und prüfen Sie jeden einzelnen auf eine brauchbare, aktuelle Sicherungsdatei. Da Sicherungen knotenlokal gespeichert werden, kann eine intakte Sicherung auf einem anderen Knoten als dem, der gerade ausgefallen ist, vorhanden sein.
2. Prüfen Sie, mit welchem ​​Sicherungsschlüssel die letzte verwendbare Sicherung verschlüsselt wurde, und suchen Sie genau diese Schlüsseldatei und das zugehörige Passwort, anstatt anzunehmen, dass ein beliebiger „Standardschlüssel“ funktioniert.
3. Wenn nur eine domänenweite Sicherung verfügbar ist und eine vollständige Systemwiederherstellung nicht möglich ist, stellen Sie zuerst die domänenweite Sicherung wieder her, um Schlüssel und Richtlinien für diese Domäne wiederherzustellen, da domänenweite Sicherungen auf jedem Clusterknoten wiederhergestellt werden können.
4. Wenn es sich bei dem Ziel um einen vorhandenen, produktiven Clusterknoten handelt, versuchen Sie keine direkte Systemwiederherstellung darauf. Verwenden Sie stattdessen die Methode zum Entfernen und Neuaufbau des Clusters oder wenden Sie sich an den Thales-Support, um die sicherste Vorgehensweise für diese Umgebung zu ermitteln.
5. Sobald der Dienst wiederhergestellt ist, sollte der Vorfall als Auslöser für eine vollständige Überprüfung der Sicherungsschlüssel auf allen Knoten, nicht nur auf dem ausgefallenen Knoten, betrachtet werden, und die Lücke in der Schlüsselverteilung, die den ursprünglichen stillen Ausfall verursacht hat, sollte behoben werden.

Das Team „Encryption Advisory Services“ von Encryption Consulting kann solche DR-Planspielübungen an einem laufenden CipherTrust Manager-Cluster durchführen, bevor es zu einem realen Vorfall kommt, sodass die Schwachstellen in einer Übung und nicht erst bei einem tatsächlichen Ausfall sichtbar werden.

Fehlersymptom, wahrscheinliche Ursache und Behebung

Fehlersymptom	Wahrscheinliche Ursache	Fixieren
codeDesc: NCERRInvalidParamValue, “Der angegebene Sicherungsschlüssel existiert nicht für den Bereich (System)”	Der Backup-Schlüssel wurde nicht hochgeladen und auf dem Knoten, der den geplanten Auftrag verarbeitet, nicht als Standard festgelegt.	Erstellen und laden Sie den Systemsicherungsschlüssel herunter, laden Sie ihn auf jeden Clusterknoten hoch und legen Sie ihn auf jedem Knoten als Standard fest.
Die geplante Datensicherung erzeugt keine Datei und es wird keine eindeutige Fehlermeldung angezeigt.	Die Quorumrichtlinie war auf dem Knoten vor dem Ausführen des Jobs aktiviert geblieben.	Deaktivieren Sie alle Quorumrichtlinien, bevor Sie die Datensicherung ausführen oder planen.
Die Sicherung wurde abgeschlossen, die Wiederherstellung schlägt jedoch aufgrund eines Schlüsselkonflikts fehl.	Der für die Wiederherstellung verwendete Sicherungsschlüssel ist nicht derselbe Schlüssel, mit dem die Datei auf dem Quellknoten verschlüsselt wurde.	Suchen und verwenden Sie die spezifische Sicherungsschlüsseldatei, die zum Zeitpunkt der Sicherung auf dem Quellknoten aktiv war.
Die Wiederherstellung auf einem vorhandenen Clusterknoten wird abgelehnt.	Systemsicherungen sind nicht dafür ausgelegt, auf einem laufenden Cluster-Knoten wiederhergestellt zu werden.	Verwenden Sie die Methode zum Entfernen und Neuaufbauen des Clusters anstelle einer direkten Wiederherstellung.
Wiederherstellung über eine Versionsgrenze hinweg abgelehnt	Das Backup ist mehr als drei Nebenversionen älter als die aktuell laufende CipherTrust Manager-Version.	Verwenden Sie die Option „–force restore“ nur nach Rücksprache mit dem Thales-Support oder stellen Sie die Wiederherstellung zunächst über eine Zwischenversion wieder her.
Der Sicherungs- oder Wiederherstellungsbefehl schlägt aufgrund eines Besetzt- oder Sperrfehlers fehl.	Ein anderer Sicherungs- oder Wiederherstellungsauftrag wird bereits ausgeführt, und es ist nur einer gleichzeitig zulässig.	Warten Sie, bis der laufende Auftrag abgeschlossen ist, bevor Sie einen neuen starten.

Einschränkungen

• Backups und Backup-Schlüssel sind systembedingt knotenlokal; es gibt keine integrierte automatische Replikation über einen CipherTrust Manager-Cluster hinweg, daher muss die Schlüsselverteilung jedes Mal manuell verwaltet werden, wenn sich ein Zeitplan oder ein Schlüssel ändert.
• Eine Systemsicherung kann nicht direkt auf einem Knoten wiederhergestellt werden, der noch Teil eines aktiven Clusters ist; die Wiederherstellung einer Clusterumgebung erfordert den Weg des Entfernens und anschließenden Neuaufbaus.
• Die Wiederherstellungskompatibilität erstreckt sich standardmäßig nur auf drei Nebenversionen, was die Dauer der praktischen Wiederherstellbarkeit eines alten Backups ohne Unterstützung begrenzt.
• Es kann immer nur ein Sicherungs- oder Wiederherstellungsauftrag gleichzeitig ausgeführt werden, was bei einer groß angelegten Wiederherstellung, die mehrere Domänen betrifft, zu einem Engpass führen kann.
• Die Verknüpfung eines Backups mit einem HSM-Root-of-Trust-Key bietet zwar zusätzlichen Schutz, birgt aber auch ein Risiko: Wird dieser HSM-Key gelöscht, ist das Backup dauerhaft nicht mehr wiederherstellbar.

Was würde Encryption Consulting empfehlen?

Die Behebung des unmittelbaren Fehlers NCERRInvalidParamValue ist in fünf Minuten erledigt, sobald die Ursache bekannt ist. Das wiederkehrende Problem bei CipherTrust Manager-Implementierungen besteht darin, dass Sicherungsschlüssel als einmaliger Einrichtungsschritt und nicht als fortlaufender Lebenszyklus behandelt werden – ohne benannten Besitzer, ohne Rotationsrhythmus und ohne Protokollierung, bis eine Wiederherstellung tatsächlich erforderlich ist und fehlschlägt.

Encryption Consulting bietet mit HSM-as-a-Service Unternehmen eine verwaltete Betriebsschicht für Plattformen wie CipherTrust Manager. Diese umfasst die konsistente Verteilung von Backup-Schlüsseln, überwachte Zeitplanung und die Erfassung von Nachweisen – ohne dass zusätzliches Personal für die Appliance-Administration benötigt wird. Für Unternehmen, die ihre aktuellen Schlüsselverwaltungs- und Backup-Praktiken zunächst bewerten und formalisieren möchten, führt unser Team für Verschlüsselungsberatung eine Gap-Analyse anhand der oben genannten Kriterien für Eigentum, Rotation, Zugriff und Audit durch und erstellt ein speziell auf Ihre Cluster-Topologie zugeschnittenes Runbook.

Fazit

Der Fehler „NCERRInvalidParamValue“ beim Backup-Schlüssel lässt sich leicht beheben, sobald man weiß, dass CipherTrust Manager Backup-Schlüssel nicht automatisch im Cluster verteilt. Die aufwendigere, aber dauerhaftere Lösung ist die operative Umsetzung: Weisen Sie Backup-Zeitplänen einen benannten Verantwortlichen zu, definieren Sie echte Rotationsauslöser für den Backup-Schlüssel, beschränken Sie die Berechtigungen zum Auslösen und Wiederherstellen von Backups und dokumentieren Sie die Ausführung des Zeitplans – nicht nur die Konfiguration. Teams, die diese Vorgehensweise anwenden, vermeiden Backup-Fehler erst im Ernstfall, wenn die Wiederherstellung tatsächlich erfolgt und die Kosten dafür erheblich sind.

Bei verwandten Problemen mit CipherTrust Manager lesen Sie bitte unsere Anleitungen zum Clustering-Fehler und zum Zertifikatsfehler der CipherTrust Manager-Weboberfläche oder unsere Übersicht zur Integration eines Thales HSM mit CipherTrust Manager On-Premises . Falls die laufende Administration den eigentlichen Engpass darstellt, bietet unsere Analyse der Gründe für die Inanspruchnahme von dediziertem CipherTrust Manager-Support einen umfassenden Überblick über die betrieblichen Abläufe.

Häufig gestellte Fragen

Warum meldet CipherTrust Manager: „Der angegebene Sicherungsschlüssel existiert nicht für den Bereich (System)“?
Dieser Fehler bedeutet, dass auf dem Knoten, der den geplanten Sicherungsauftrag ausgeführt hat, der Sicherungsschlüssel nicht vorhanden und nicht als Standardschlüssel gekennzeichnet ist. CipherTrust Manager kopiert Sicherungsschlüssel nicht automatisch zwischen Clusterknoten. Daher schlägt ein Auftrag, der auf einem Knoten ohne diesen Schlüssel ausgeführt wird, mit genau dieser Fehlermeldung fehl, es sei denn, auf jedem Knoten ist derselbe Standardschlüssel vorhanden.

Werden die Sicherungsschlüssel von CipherTrust Manager automatisch auf alle Clusterknoten repliziert?
Nein. Die Dokumentation von Thales besagt eindeutig, dass Backups und Backup-Schlüssel nicht automatisch auf andere Knoten in einem Cluster kopiert werden und nur auf dem Knoten existieren, auf dem sie erstellt oder manuell hochgeladen wurden. Jeder Knoten im Cluster benötigt denselben Standard-Backup-Schlüssel, der separat hochgeladen werden muss.

Kann eine Sicherung des CipherTrust Manager-Systems direkt auf einem Clusterknoten wiederhergestellt werden?
Nein. System-Backups sind nicht für die Wiederherstellung auf einem Knoten ausgelegt, der noch Teil eines aktiven Clusters ist. Thales empfiehlt in diesem Fall die Methode „Cluster entfernen und neu erstellen“. Domänenweite Backups funktionieren anders und können auf jedem Knoten im Cluster wiederhergestellt werden.

Wie oft sollten die Backup-Verschlüsselungsschlüssel von CipherTrust Manager rotiert werden?
Es gibt kein von Thales vorgeschriebenes Intervall, daher sollte dies der allgemeineren Schlüsselrotationsrichtlinie der Organisation sowie ereignisbasierten Auslösern folgen: nach Personalwechseln mit Zugriff auf den Schlüssel, nach einem Wiederherstellungsfehler aufgrund einer Schlüsselabweichung, vor der Außerbetriebnahme eines Knotens oder nach jedem Verdacht auf Offenlegung der Sicherungsschlüsseldatei oder des Passworts.

Was passiert, wenn eine Sicherung des CipherTrust Managers an einen HSM-Vertrauensstammschlüssel gebunden ist, der gelöscht wird?
Laut Thales-Dokumentation kann ein an das HSM gebundenes Backup nicht wiederhergestellt werden, wenn der zugehörige HSM-Root-of-Trust-Schlüssel manuell gelöscht wird. Organisationen, die Backups an einen HSM-Root-of-Trust-Schlüssel binden, sollten dessen Lebenszyklus und Löschmechanismen als Teil ihrer Backup-Strategie und nicht als separate Angelegenheit betrachten.

Referenzen

• Thales Docs, „Backups“, CipherTrust Manager 2.9 Administrationshandbuch, thalesdocs.com
• Thales Docs, „Backups“, CipherTrust Manager 2.10 Administrationshandbuch, thalesdocs.com
• Thales-Dokumentation, „Systemprotokolle“, CipherTrust Manager-Administrationshandbuch, thalesdocs.com