CipherTrust Manager säkerhetskopieringsfel

Publicerad: mars 2023. Uppdaterad: augusti 2026. Granskad av Encryption Consultings nyckelhanteringsteam.

En misslyckad säkerhetskopiering av CipherTrust Manager är inte ett kosmetiskt fel. Det betyder att om enheten förloras, skadas eller behöver byggas om, finns det inget verifierat sätt att återställa nycklar, policyer och granskningshistorik. Den här guiden går igenom varför säkerhetskopieringsfelet inträffar, hur man åtgärdar det i ett aktivt kluster och vilken operativ disciplin, ägarskap, rotation, åtkomstkontroll och revisionsbevis som förhindrar att det händer igen.

Vad orsakar säkerhetskopieringsfel i CipherTrust Manager?

De flesta säkerhetskopieringsfel i CipherTrust Manager beror på en av tre grundorsaker: en saknad eller felaktig säkerhetskopieringsnyckel på noden som kör jobbet, en policyförutsättning som inte rensades innan säkerhetskopieringen startade, eller en kompatibilitetsgräns för version och återställning. CipherTrust Manager behandlar varje säkerhetskopia som en nodlokal artefakt krypterad med en specifik nyckel, och synkroniserar inte säkerhetskopior eller säkerhetskopieringsnycklar över ett kluster på egen hand. Enligt Thales egen dokumentation "kopieras inte säkerhetskopior och säkerhetskopieringsnycklar automatiskt till andra noder i ett kluster. De finns bara på en nod där de skapas eller kopieras till." När detta beteende väl förstås visar sig de flesta säkerhetskopierings"fel" vara nyckeldistributionsluckor snarare än en trasig funktion.

Betrakta ett CipherTrust Manager-kluster med fyra noder (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com). Enligt standardproceduren skapar du ett säkerhetskopieringsschema för systemet på en nod, och dessa schemametadata replikeras till de andra. Säkerhetskopieringsnyckeln gör det inte. Om det schemalagda jobbet råkar utlösas på en nod som aldrig fick nyckeln, misslyckas jobbet.

Vanliga felscenarier och grundorsaker

Det här är det scenario som Encryption Consulting oftast ser, och det är fokus för steg-för-steg-åtgärden nedan. Den främsta orsaken till det här felet är att schemalagda säkerhetskopior körs på den nod som hämtar jobbet, och om den noden inte har säkerhetskopianyckeln närvarande och markerad som standard, kan jobbet inte kryptera säkerhetskopian, så det misslyckas.

En handfull andra säkerhetskopierings- och återställningsfel dyker upp tillräckligt regelbundet för att vara värda att dokumentera tillsammans med dem, alla bekräftade mot Thales CipherTrust Manager-administratörsdokumentation:

• Säkerhetskopieringsjobbet misslyckas tyst och ingen fil skapas. Thales dokumentation anger att ”alla kvorumprinciper måste inaktiveras innan en säkerhetskopia skapas.” En kvorumprincip som lämnas aktiverad på noden blockerar jobbet innan det kan köras.
• Säkerhetskopieringen är klar, men återställningen misslyckas med ett nyckelfel. Reservnyckeln som användes vid återställningstillfället matchar inte nyckeln som krypterade filen. Detta händer när en administratör hämtar en reservnyckel som finns tillgänglig på en annan nod istället för den som var aktiv på källnoden vid säkerhetskopieringstillfället.
• Återställningen avvisas på en befintlig klusternod. Systemsäkerhetskopior är inte utformade för att återställa till en aktiv klusternod. Thales vägledning är att använda metoden för att ta bort och återuppbygga kluster istället för en direkt återställning i så fall.
• Återställningen avvisas över en versionsgräns. Säkerhetskopior i CipherTrust Manager återställer som standard till de kommande tre mindre utgåvorna (till exempel återställer en säkerhetskopia 2.6 utan problem till 2.7, 2.8 eller 2.9). Att återställa en äldre säkerhetskopia än den kräver en --force alternativ, och Thales rekommenderar att man involverar support innan man använder det.
• Säkerhetskopierings- eller återställningskommandot misslyckas med ett upptaget- eller låst-fel. Endast en säkerhetskopierings- eller återställningsåtgärd kan köras åt gången på CipherTrust Manager. Ett andra jobb som startas medan ett redan pågår kommer att avvisas.
• En säkerhetskopia som är kopplad till en HSM-rot av förtroende blir oanvändbar. Systemsäkerhetskopior kan valfritt kopplas till en HSM-rotnyckel för extra skydd, men om HSM-nyckeln senare tas bort kan säkerhetskopian som var beroende av den aldrig återställas.

Så här åtgärdar du säkerhetskopieringsfelet i CipherTrust Manager (steg för steg)

Åtgärden för felet NCERRInvalidParamValue-säkerhetskopieringsnyckel är att skapa en standardsystemsäkerhetskopieringsnyckel och skicka den till varje nod i klustret, så att schemat lyckas oavsett vilken nod jobbet landar på. Stegen nedan förutsätter att schemat ursprungligen skapades från thales01.ec.com.

1. På thales01.ec.com, navigera till Säkerhetskopieringsnycklar under Administratörsinställningar.

   

2. Skapa en ny systemnyckel för säkerhetskopiering och ange den som standard.

   

3. Ladda ner den nyligen skapade systemsäkerhetskopieringsnyckeln så att den kan laddas upp till de andra CipherTrust Manager-klusternoderna.

   

4. Ange ett lösenord för säkerhetskopianyckeln och klicka på ”Ladda ner”.

   

5. Följ den här sökvägen för att ladda upp systemsäkerhetskopieringsnyckeln på varje CipherTrust Manager-klusternod: Administratörsinställningar > Säkerhetskopieringsnycklar > Lägg till säkerhetskopieringsnyckel > Ladda upp säkerhetskopieringsnyckel. Välj den nedladdade filen och ange lösenordet från föregående steg.

   

6. När uppladdningen är klar klickar du på överfyllningsikonen och väljer "Använd som standard" på varje nod.

   

7. Navigera till Administratörsinställningar > Scheman för att konfigurera en säkerhetskopiering på systemnivå.

   

8. Klicka på "Lägg till schema".

   

9. Välj "Systemsäkerhetskopiering" och klicka på "Nästa".

   

10. Ange ett schemanamn och klicka på "Nästa".

    

11. Ställ in säkerhetskopieringsfrekvensen och klicka på "Nästa".

    

12. Ange antalet säkerhetskopior som ska behållas och välj "Använd standardnyckel för säkerhetskopiering". Att använda standardnyckeln är det som gör att schemat lyckas oavsett vilken klusternod jobbet körs på, eftersom samma nyckel nu finns överallt.

    

Om jobbet fortfarande Misslyckas efter att varje nod har samma standardnyckel, inaktivera alla aktiva kvorumprinciper före nästa schemalagda körning och bekräfta att inget annat säkerhetskopierings- eller återställningsjobb redan pågår på den noden.

Ägarskap och schemaläggningsansvar för säkerhetskopiering

Felet NCERRInvalidParamValue är vanligtvis ett symptom på en saknad ägare, inte bara en saknad nyckel. När ingen enskild person är ansvarig för att bekräfta att ett säkerhetskopieringsschema lyckades, går luckor i nyckeldistributionen obemärkta förrän en återställning faktiskt behövs. En fungerande ägarmodell för ett CipherTrust Manager-kluster inkluderar:

• En namngiven reservägare (individuell eller jourrotation) som ansvarar för varje nod i klustret, inte bara den nod där schemat skapades.
• En dokumenterad runbook som listar vilken nod som för närvarande innehåller vilken standardnyckel för säkerhetskopiering, som uppdateras varje gång en nod läggs till, återskapas eller tas bort.
• En återkommande kontroll, minst en gång i veckan, som bekräftar att den senaste schemalagda säkerhetskopieringen faktiskt slutfördes på varje nod, inte bara på den nod den råkade köras på.
• En tydlig eskaleringsväg när en schemalagd säkerhetskopiering misslyckas två gånger i rad, snarare än att låta felmeddelanden hopas upp olästa.

Rotationsutlösare för säkerhetskopieringsnycklar

En reservnyckel är en kryptografisk nyckel precis som alla andra CipherTrust Manager-nycklar, och den bör roteras vid definierade utlösare snarare än att lämnas kvar på obestämd tid. Encryption Consulting rekommenderar att man roterar systemets reservnyckel när något av följande inträffar:

• En administratör som hade åtkomst till säkerhetskopianyckelfilen eller dess lösenord lämnar teamet eller byter roll.
• En återställning misslyckas eftersom fel säkerhetskopianod användes, vilket ofta indikerar att nyckelregistret är föråldrat.
• En klusternod är avaktiverad eller ersatt, eftersom dess lokala kopia av säkerhetskopianoden måste tas ur bruk tillsammans med den.
• Organisationens bredare policy för nyckelrotation kräver det, i samma takt som tillämpas på annat långlivat kryptografiskt material.
• En säkerhetskopia var kopplad till en HSM-rot av en förtroendenyckel som i sig roteras eller tas ur bruk, eftersom Thales dokumentation bekräftar att en HSM-kopplad säkerhetskopia inte kan återställas när roten av förtroendenyckeln har tagits bort.

Efter rotationen måste den nya standardnyckeln fortfarande skickas manuellt till varje klusternod, på samma sätt som den ursprungliga nyckeln distribuerades i lösningen ovan. Att rotera på en nod och glömma de andra återskapar helt enkelt det ursprungliga felet under en ny nyckel.

Åtkomstpolicy: Vem kan utlösa eller återställa en säkerhetskopia

CipherTrust Managers åtkomstmodell är byggd på domäner och rollbaserade grupper, och säkerhetskopieringsrelaterade åtgärder bör noggrant begränsas inom den. Thales egen dokumentation anger tydligt att loggnedladdningar från rotdomänen är begränsade till specifika grupper: "endast användare som ingår i systemadministratörer och administratörsgrupper kan ladda ner loggarna från rotdomänen." Samma princip gäller för att skapa och återställa säkerhetskopior, vilket vidrör varje domäns nycklar samtidigt för en systemsäkerhetskopiering.

En sund åtkomstpolicy för säkerhetskopiering håller gruppen som kan skapa eller ladda upp säkerhetskopieringsnycklar liten och separat från de dagliga nyckelhanteringsanvändarna, kräver en andra godkännare innan en återställning körs mot ett produktionskluster och lämnar aldrig ett delat, odokumenterat lösenord för säkerhetskopiering kvar i ett chattmeddelande eller ärende. Återställning är den högriskåtgärden av de två: en felaktig återställning kan återställa nycklar, policyer och användare till ett inaktuellt tillstånd i hela systemet.

Revisionsbevis för säkerhetskopiering som lyckats och misslyckats

Ett säkerhetskopieringsschema som "vanligtvis fungerar" är inte bevis på någonting för en granskare. CipherTrust Managers systemloggar registrerar administrativa åtgärder, konfigurationsändringar och både lyckade och misslyckade operationer, vilket är råmaterialet för bevis för säkerhetskopiering. Loggar kan hämtas från det grafiska användargränssnittet under Administratörsinställningar > Loggar eller via ksctl logs download kommandoradsverktyget och nedladdade loggar är integritetsskyddade med en SHA-256-hash signerad av ett asymmetriskt nyckelpar, verifierbart med OpenSSL.

För en granskningsbar säkerhetskopieringsprocess, dirigera dessa loggar till en central SIEM eller logglagring istället för att enbart förlita dig på CipherTrust Manager-konsolen, spara bevis på varje schemalagd säkerhetskopierings slutförandestatus under organisationens efterlevnadsfönster och för separata register över varje rotation av säkerhetskopieringsnycklar och varje återställningshändelse, inklusive vem som godkände den. Dessa bevis är det som förvandlar "vi har säkerhetskopior" till ett försvarbart svar under en granskning eller efter en incident.

Plattformsjämförelse: Manuell säkerhetskopiering kontra automatiserad/schemalagd säkerhetskopiering

CipherTrust Manager stöder både manuell säkerhetskopiering på begäran och ett återkommande schema. De två är inte utbytbara operativt, och de flesta organisationer behöver båda.

Faktor	Manuell säkerhetskopiering	Automatiserad/schemalagd säkerhetskopiering
Trigger	Körs av en administratör före ett planerat ändrings-, uppgraderings- eller underhållsfönster	Körs med ett definierat intervall oavsett om en administratör tittar på eller inte
Konsistens	Beror på att någon kommer ihåg att köra den	Konsekvent så länge som reservnyckeln och kvorumförutsättningarna är korrekt inställda på noden där jobbet landar
Felsynlighet	Felet ses omedelbart av administratören som körde det	Fel kan gå obemärkt förbi under en hel cykel om inte varning eller en granskningsprocess finns på plats
Verifieringskedja	Engångshändelse, enkel att dokumentera individuellt	Behöver en återkommande logggranskningsprocess för att bevisa fortsatt täckning
Används bäst till	Ögonblicksbilder före ändring och uppgradering	Rutinmässig katastrofåterställningsförsäkring mellan förändringar

Incidentrespons om ett säkerhetskopieringsfel upptäcks under en DR-händelse

Den värsta tiden att upptäcka att en säkerhetskopia av CipherTrust Manager tyst har misslyckats är mitt i en katastrofåterställningshändelse, när det inte finns tid kvar att först åtgärda det underliggande nyckeldistributionsgapet. Om det händer, arbeta igenom det i denna ordning:

1. Identifiera varje nod i klustret och kontrollera varje nod individuellt för en användbar, aktuell säkerhetskopia. Eftersom säkerhetskopior är nodlokala kan en felfri säkerhetskopia finnas på en annan nod än den som just misslyckades.
2. Bekräfta vilken säkerhetskopianod som krypterade den senast användbara säkerhetskopian och leta reda på exakt den nyckelfilen och lösenordet istället för att anta att vilken "standardnyckel" som helst fungerar.
3. Om det bara finns en domänomfattande säkerhetskopia tillgänglig och en fullständig systemåterställning inte är möjlig, återställ först den domänomfattande säkerhetskopian för att återställa nycklar och principer för den domänen, eftersom domänomfattande säkerhetskopior kan återställas på vilken klustrad nod som helst.
4. Om målet är en befintlig, aktiv klusternod, försök inte en direkt systemåterställning på den. Använd metoden för att ta bort och återskapa kluster, eller kontakta Thales support för vägledning om den säkraste sekvensen för den miljön.
5. När tjänsten är återställd, behandla incidenten som utlösare för en fullständig granskning av säkerhetskopieringsnyckeln för varje nod, inte bara den som misslyckades, och korrigera nyckeldistributionsgapet som orsakade det ursprungliga tysta felet.

Encryption Consultings team för krypteringsrådgivning kan köra den här typen av DR-övning mot ett aktivt CipherTrust Manager-kluster innan det blir en verklig incident, så att luckorna dyker upp i en övning istället för under ett faktiskt avbrott.

Felsymptom, trolig orsak och åtgärd

Felsymptom	Troligtvis orsak	Fast
kodbeskrivning: NCERRInvalidParamValue, "Angiven säkerhetskopia finns inte för omfång (system)"	Reservnyckeln laddades inte upp och ställdes inte in som standard på noden som hanterar det schemalagda jobbet	Skapa och ladda ner systemsäkerhetskopieringsnyckeln, ladda upp den till varje klusternod och ange den som standard på var och en.
Schemalagd säkerhetskopiering ger ingen fil och inget tydligt fel	En kvorumpolicy lämnades aktiverad på noden innan jobbet kördes	Inaktivera alla kvorumprinciper innan du kör eller schemalägger säkerhetskopieringen
Säkerhetskopieringen är klar, men återställningen misslyckas på grund av en nyckelmatchning	Säkerhetskopieringsnyckeln som används för återställning är inte exakt den nyckel som krypterade filen på källnoden.	Leta reda på och använd den specifika säkerhetskopieringsnyckelfilen som var aktiv på källnoden vid säkerhetskopieringstillfället
Återställningen avvisas på en befintlig klusternod	Systemsäkerhetskopior är inte utformade för att återställa till en aktiv klusternod	Använd metoden för borttagning och ombyggnad av kluster istället för en direkt återställning
Återställning avvisad över en versionsgräns	Säkerhetskopieringen är mer än tre mindre utgåvor äldre än den pågående CipherTrust Manager-versionen.	Använd alternativet –force restore endast efter att ha konsulterat Thales support, eller återställ först via en mellanliggande version.
Säkerhetskopierings- eller återställningskommandot misslyckas med ett upptaget- eller låst fel	Ett annat säkerhetskopierings- eller återställningsjobb körs redan, och endast ett är tillåtet åt gången	Vänta tills jobbet under flygningen är klart innan du påbörjar ett nytt

Begränsningar

• Säkerhetskopior och säkerhetskopieringsnycklar är nodlokala av design; det finns ingen inbyggd automatisk replikering över ett CipherTrust Manager-kluster, så nyckeldistribution måste hanteras manuellt varje gång ett schema eller en nyckel ändras.
• En systemsäkerhetskopia kan inte återställas direkt till en nod som fortfarande är en del av ett aktivt kluster; återställning av en klustrad miljö kräver borttagnings- och återuppbyggnadssökvägen.
• Återställningskompatibilitet sträcker sig som standard endast framåt med tre mindre utgåvor, vilket begränsar hur länge en gammal säkerhetskopia praktiskt taget kan återställas utan supportinblandning.
• Endast ett säkerhetskopierings- eller återställningsjobb kan köras åt gången, vilket kan skapa en flaskhals under en storskalig återställning som involverar flera domäner.
• Att koppla en säkerhetskopia till en HSM-rot för en förtroendenyckel ger skydd men lägger också till ett hårt felläge: om HSM-nyckeln tas bort blir säkerhetskopian permanent oåterställbar.

Vad skulle krypteringskonsulter rekommendera?

Att åtgärda det omedelbara NCERRInvalidParamValue-felet tar fem minuter när orsaken väl är förstådd. Det återkommande problemet vi ser i alla CipherTrust Manager-distributioner är att säkerhetskopieringsnycklar behandlas som ett engångsinstallationssteg istället för en pågående livscykel, ingen namngiven ägare, ingen rotationskadens och ingen revisionslogg förrän en återställning faktiskt behövs och misslyckas.

Encryption Consultings HSM-as-a-Service ger organisationer ett hanterat operativt lager kring plattformar som CipherTrust Manager, inklusive konsekvent distribution av säkerhetskopieringsnycklar, övervakad schemaläggning och bevisinsamling, utan att lägga till personalstyrka dedikerad till administration av applikationer. För organisationer som först vill utvärdera och formalisera sina nuvarande nyckelhanterings- och säkerhetskopieringsrutiner kan vårt team för krypteringsrådgivningstjänster göra en gap-bedömning mot de ägarskaps-, rotations-, åtkomst- och revisionskriterier som beskrivs ovan och bygga en runbook specifikt för er klustertopologi.

Slutsats

Felet NCERRInvalidParamValue för säkerhetskopieringsnyckeln är enkelt att åtgärda när du väl vet att CipherTrust Manager inte distribuerar säkerhetskopieringsnycklar över ett kluster på egen hand. Den svårare och mer hållbara lösningen är operationell: tilldela en namngiven ägare för säkerhetskopieringsscheman, ställ in verkliga rotationsutlösare för säkerhetskopieringsnyckeln, begränsa vem som kan utlösa eller återställa en säkerhetskopia och spara revisionsbevis som bevisar att schemat faktiskt kördes, inte bara att det var konfigurerat för det. Team som inför den disciplinen slutar upptäcka säkerhetskopieringsfel under en faktisk katastrofåterställningshändelse, vilket är den enda gången de är verkligt dyra att hitta.

För relaterade CipherTrust Manager-problem, se våra guider om CipherTrust Manager-klusterfelet och CipherTrust Manager-webbgränssnittscertifikatfelet , eller vår översikt över att integrera en Thales HSM med CipherTrust Manager lokalt . Om löpande administration är den verkliga flaskhalsen, täcker vår förklaring av varför team använder dedikerad CipherTrust Manager-support den bredare operativa bilden.

Vanliga frågor om partihandel med mat och dryck

Varför säger CipherTrust Manager "Den angivna säkerhetskopianoden finns inte för omfånget (systemet)"?
Det här felet innebär att noden som hämtade det schemalagda säkerhetskopieringsjobbet inte har säkerhetskopieringsnyckeln närvarande och markerad som standard. CipherTrust Manager kopierar inte automatiskt säkerhetskopieringsnycklar mellan klusternoder, så om inte samma standardnyckel laddas upp till varje nod kommer ett jobb som landar på en nod utan den att misslyckas med exakt detta meddelande.

Replikeras säkerhetskopieringsnycklar för CipherTrust Manager automatiskt mellan klusternoder?
Nej. Thales dokumentation anger tydligt att säkerhetskopior och säkerhetskopieringsnycklar inte automatiskt kopieras till andra noder i ett kluster och bara finns på den nod där de skapades eller laddades upp manuellt. Varje nod i klustret behöver samma standardnyckel för säkerhetskopiering laddas upp separat.

Kan en säkerhetskopia av CipherTrust Manager-systemet återställas direkt till en klusternod?
Nej. Systemsäkerhetskopior är inte utformade för att återställa till en nod som fortfarande är en del av ett aktivt kluster. Thales rekommenderar metoden för att ta bort och återskapa klustret i det scenariot. Domänomfattade säkerhetskopior är olika och kan återställas på vilken klustrad nod som helst.

Hur ofta bör säkerhetskopieringsnycklar för CipherTrust Manager roteras?
Det finns inget enskilt Thales-mandaterat intervall, så detta bör följa organisationens bredare policy för nyckelrotation plus händelsebaserade utlösare: efter personalbyten med åtkomst till nyckeln, efter ett återställningsfel kopplat till en nyckelmatchning, innan en nod avvecklas eller efter misstänkt exponering av säkerhetskopianyckelfilen eller lösenordet.

Vad händer om en CipherTrust Manager-säkerhetskopia är kopplad till en HSM-rot för en förtroendenyckel som tas bort?
Enligt Thales dokumentation kan en säkerhetskopia som är kopplad till HSM aldrig återställas om HSM-rotnyckeln som den är beroende av raderas manuellt. Alla organisationer som kopplar säkerhetskopior till en HSM-rotnyckel bör behandla den nyckelns egen livscykel och borttagningskontroller som en del av säkerhetskopieringsstrategin, inte som en separat fråga.

Referensprojekt

• Thales Docs, ”Säkerhetskopior”, CipherTrust Manager 2.9 Administrationsguide, thalesdocs.com
• Thales Docs, ”Säkerhetskopior”, CipherTrust Manager 2.10 Administrationsguide, thalesdocs.com
• Thales-dokument, ”Systemloggar”, CipherTrust Manager-administrationsguide, thalesdocs.com