CipherTrust Manager-back-upfout

Gepubliceerd: maart 2023. Bijgewerkt: augustus 2026. Beoordeeld door het Key Management Engineering-team van Encryption Consulting.

Een mislukte back-up van CipherTrust Manager is geen cosmetische fout. Het betekent dat als het apparaat verloren gaat, beschadigd raakt of opnieuw moet worden opgebouwd, er geen gegarandeerde manier is om de sleutels, beleidsregels en auditgeschiedenis te herstellen. Deze handleiding beschrijft waarom de back-upfout optreedt, hoe u deze kunt verhelpen in een actief cluster en welke operationele discipline, verantwoordelijkheid, rotatie, toegangscontrole en auditbewijs nodig zijn om herhaling te voorkomen.

Wat veroorzaakt back-upfouten bij CipherTrust Manager?

De meeste fouten bij back-ups van CipherTrust Manager zijn terug te voeren op een van de volgende drie hoofdoorzaken: een ontbrekende of onjuiste back-upsleutel op het knooppunt waarop de taak wordt uitgevoerd, een beleidsvoorwaarde die niet is gewist voordat de back-up startte, of een compatibiliteitslimiet voor versies en herstel. CipherTrust Manager behandelt elke back-up als een lokaal artefact op het knooppunt, versleuteld met een specifieke sleutel, en synchroniseert back-ups of back-upsleutels niet automatisch over een cluster. Volgens de documentatie van Thales zelf worden "back-ups en back-upsleutels niet automatisch naar andere knooppunten in een cluster gekopieerd. Ze bestaan ​​alleen op het knooppunt waar ze zijn aangemaakt of naartoe zijn gekopieerd." Zodra dit gedrag is begrepen, blijken de meeste back-upfouten eerder te wijten aan hiaten in de sleuteldistributie dan aan een defecte functionaliteit.

Stel je een CipherTrust Manager-cluster voor met vier knooppunten (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com). Volgens de standaardprocedure maak je een back-upschema voor het systeem op één knooppunt, en de metadata van dat schema worden naar de andere knooppunten gerepliceerd. De back-upsleutel wordt echter niet gerepliceerd. Als de geplande taak wordt uitgevoerd op een knooppunt dat de sleutel nooit heeft ontvangen, mislukt de taak.

Veelvoorkomende foutscenario's en hun oorzaken

Dit is het scenario dat Encryption Consulting het vaakst tegenkomt, en het is de focus van de onderstaande stapsgewijze oplossing. De voornaamste oorzaak van deze fout is dat geplande back-ups worden uitgevoerd op het knooppunt dat de taak oppakt, en als dat knooppunt de back-upsleutel niet heeft en deze niet als standaard is gemarkeerd, kan de taak het back-upbestand niet versleutelen en mislukt deze.

Een handvol andere back-up- en herstelfouten komen regelmatig genoeg voor om erbij te documenteren, en zijn allemaal bevestigd aan de hand van de beheerdersdocumentatie van Thales' CipherTrust Manager:

• De back-uptaak ​​mislukt stilzwijgend en er wordt geen bestand aangemaakt. In de documentatie van Thales staat dat "alle quorumbeleidsregels moeten worden uitgeschakeld voordat een back-up wordt gemaakt". Een ingeschakelde quorumbeleidsregel op het knooppunt blokkeert de taak voordat deze kan worden uitgevoerd.
• De back-up is voltooid, maar het herstel mislukt met een belangrijke foutmelding. De back-upsleutel die tijdens het herstellen wordt gebruikt, komt niet overeen met de sleutel waarmee het bestand is versleuteld. Dit gebeurt wanneer een beheerder een willekeurige back-upsleutel van een andere server gebruikt in plaats van de sleutel die actief was op de bronserver tijdens het maken van de back-up.
• Het herstelverzoek wordt geweigerd op een bestaand clusterknooppunt. Systeembackups zijn niet ontworpen om te worden hersteld op een actief clusterknooppunt. Thales adviseert daarom om in dat geval de methode voor het verwijderen en opnieuw opbouwen van het cluster te gebruiken in plaats van een directe herstelbewerking.
• Het herstelproces wordt geweigerd vanwege een versieovergang. Bij het herstellen van back-ups van CipherTrust Manager worden standaard de drie eerstvolgende minor releases gebruikt (bijvoorbeeld, een back-up van versie 2.6 kan probleemloos worden hersteld naar versie 2.7, 2.8 of 2.9). Het herstellen van een oudere back-up vereist een --force Deze optie is beschikbaar, en Thales raadt aan om eerst contact op te nemen met de supportafdeling voordat u deze gebruikt.
• De back-up- of herstelopdracht mislukt met een 'bezet' of 'vergrendeld'-fout. Op CipherTrust Manager kan slechts één back-up- of herstelbewerking tegelijk worden uitgevoerd. Een tweede taak die wordt gestart terwijl er al een bezig is, wordt geweigerd.
• Een back-up die gekoppeld is aan een HSM-root of trust wordt onbruikbaar. Systeembackups kunnen optioneel worden gekoppeld aan een HSM-vertrouwenssleutel voor extra bescherming, maar als die HSM-sleutel later wordt verwijderd, kan de back-up die ervan afhankelijk was nooit meer worden hersteld.

Hoe los je de back-upfout van CipherTrust Manager op (stap voor stap)?

De oplossing voor de NCERRInvalidParamValue-fout bij de back-upsleutel is het aanmaken van één standaard systeemback-upsleutel en deze naar elk knooppunt in het cluster te pushen, zodat de planning slaagt, ongeacht op welk knooppunt de taak terechtkomt. De onderstaande stappen gaan ervan uit dat de planning oorspronkelijk is aangemaakt vanaf thales01.ec.com.

1. Ga op thales01.ec.com naar 'Backup Keys' onder 'Admin Settings'.

   

2. Maak een nieuwe systeemback-upsleutel aan en stel deze in als standaard.

   

3. Download de zojuist aangemaakte systeemback-upsleutel, zodat deze kan worden geüpload naar de andere CipherTrust Manager-clusterknooppunten.

   

4. Voer een wachtwoord in voor de back-upsleutel en klik op 'Downloaden'.

   

5. Volg dit pad om de systeemback-upsleutel op elk CipherTrust Manager-clusterknooppunt te uploaden: Beheerinstellingen > Back-upsleutels > Back-upsleutel toevoegen > Back-upsleutel uploaden. Selecteer het gedownloade bestand en voer het wachtwoord van de vorige stap in.

   

6. Zodra het uploaden is gelukt, klikt u op het overloopicoon en selecteert u 'Instellen als standaard' voor elk knooppunt.

   

7. Ga naar Beheerinstellingen > Schema's om een ​​back-up op systeemniveau te configureren.

   

8. Klik op "Schema toevoegen".

   

9. Selecteer ‘Systeemback-up’ en klik op ‘Volgende’.

   

10. Voer een planningsnaam in en klik op 'Volgende'.

    

11. Stel de back-upfrequentie in en klik op 'Volgende'.

    

12. Stel het aantal te bewaren back-ups in en selecteer 'Standaard back-upsleutel gebruiken'. Door de standaardsleutel te gebruiken, kan de planning succesvol worden uitgevoerd, ongeacht op welk clusterknooppunt de taak wordt uitgevoerd, omdat dezelfde sleutel nu overal aanwezig is.

    

Als de taak nog steeds mislukt nadat alle knooppunten dezelfde standaardsleutel hebben, schakel dan alle actieve quorumbeleidsregels uit vóór de volgende geplande uitvoering en controleer of er geen andere back-up- of hersteltaak al bezig is op dat knooppunt.

Reserveverantwoordelijkheid voor eigendom en planning

De NCERRInvalidParamValue-fout is meestal een symptoom van een ontbrekende eigenaar, niet alleen van een ontbrekende sleutel. Wanneer niemand verantwoordelijk is voor het bevestigen dat een back-upschema is geslaagd, blijven hiaten in de sleuteldistributie onopgemerkt totdat een herstel daadwerkelijk nodig is. Een werkbaar eigenaarschapsmodel voor een CipherTrust Manager-cluster omvat:

• Een aangewezen back-upbeheerder (individueel of via een oproepdienst) is verantwoordelijk voor elk knooppunt in het cluster, niet alleen voor het knooppunt waarop het schema is aangemaakt.
• Een gedocumenteerd draaiboek dat aangeeft welke node momenteel welke standaard back-upsleutel bevat, en dat wordt bijgewerkt telkens wanneer een node wordt toegevoegd, opnieuw opgebouwd of verwijderd.
• Een terugkerende controle, minimaal wekelijks, die bevestigt dat de laatst geplande back-up daadwerkelijk op alle knooppunten is voltooid, en niet alleen op het knooppunt waarop deze toevallig is uitgevoerd.
• Een duidelijke escalatieprocedure wanneer een geplande back-up twee keer achter elkaar mislukt, in plaats van dat foutmeldingen ongelezen blijven opstapelen.

Rotatietriggers voor back-upversleutelingssleutels

Een back-upsleutel is een cryptografische sleutel, net als elke andere CipherTrust Manager-sleutel, en moet worden geroteerd op vooraf bepaalde momenten in plaats van permanent te worden bewaard. Encryption Consulting raadt aan de systeemback-upsleutel te roteren wanneer een van de volgende situaties zich voordoet:

• Een beheerder die toegang had tot het back-upbestand of het bijbehorende wachtwoord verlaat het team of verandert van functie.
• Een herstelbewerking mislukt omdat de verkeerde back-upsleutel is gebruikt, wat vaak duidt op een verouderde sleutelinventaris.
• Een clusterknooppunt wordt buiten gebruik gesteld of vervangen, omdat de lokale kopie van de back-upsleutel samen met het knooppunt moet worden verwijderd.
• Het algemene sleutelrotatiebeleid van de organisatie vereist dit, met dezelfde frequentie als die wordt toegepast op ander langlevend cryptografisch materiaal.
• Een back-upsleutel was gekoppeld aan een HSM-root-of-trust-sleutel die zelf wordt geroteerd of buiten gebruik gesteld, aangezien de documentatie van Thales bevestigt dat een aan een HSM gekoppelde back-up niet kan worden hersteld zodra die root-of-trust-sleutel is verwijderd.

Na de rotatie moet de nieuwe standaardsleutel nog steeds handmatig naar elk clusterknooppunt worden gepusht, op dezelfde manier als de oorspronkelijke sleutel werd gedistribueerd in de bovenstaande oplossing. Door slechts één knooppunt te roteren en de andere knooppunten te negeren, wordt de oorspronkelijke fout simpelweg opnieuw veroorzaakt, maar dan met een nieuwe sleutel.

Toegangsbeleid: Wie mag een back-up starten of herstellen?

Het toegangsmodel van CipherTrust Manager is gebaseerd op domeinen en op rollen gebaseerde groepen, en back-upgerelateerde acties moeten daar strikt binnen blijven. De documentatie van Thales zelf stelt expliciet dat het downloaden van logbestanden van het rootdomein beperkt is tot specifieke groepen: "alleen gebruikers die deel uitmaken van de groepen Systeembeheerders en Beheerders kunnen de logbestanden van het rootdomein downloaden." Hetzelfde principe geldt voor het maken en herstellen van back-ups, waarbij voor een systeemback-up de sleutels van alle domeinen tegelijk worden aangepast.

Een degelijk toegangsbeleid voor back-upbewerkingen zorgt ervoor dat de groep die back-upsleutels kan aanmaken of uploaden klein en gescheiden blijft van de gebruikers die dagelijks sleutels beheren, vereist een tweede goedkeurder voordat een herstelbewerking wordt uitgevoerd op een productiecluster en zorgt ervoor dat een gedeeld, ongedocumenteerd wachtwoord voor back-upsleutels nooit in een chatbericht of ticket blijft staan. Herstellen is de actie met het grootste risico: een mislukte herstelbewerking kan sleutels, beleidsregels en gebruikers in het hele systeem terugzetten naar een verouderde status.

Auditbewijs voor het succes en falen van back-ups

Een back-upschema dat "meestal werkt" is voor een auditor geen enkel bewijs. De systeemlogboeken van CipherTrust Manager registreren beheerdersacties, configuratiewijzigingen en zowel geslaagde als mislukte bewerkingen. Dit vormt de basis voor bewijsmateriaal bij een back-upaudit. Logboeken kunnen worden opgevraagd via de GUI onder Beheerinstellingen > Logboeken of via de ksctl logs download De logbestanden die via de commandoregel worden gedownload, zijn beveiligd met een SHA-256-hash die is ondertekend met een asymmetrisch sleutelpaar en verifieerbaar is met OpenSSL.

Voor een controleerbaar back-upproces is het raadzaam om deze logbestanden naar een centrale SIEM of logopslag te sturen in plaats van alleen op de CipherTrust Manager-console te vertrouwen. Bewaar bewijs van de voltooiingsstatus van elke geplande back-up gedurende de wettelijke bewaartermijn van de organisatie en houd een apart register bij van elke back-upsleutelrotatie en elke herstelgebeurtenis, inclusief wie deze heeft goedgekeurd. Dit bewijs maakt van "we hebben back-ups" een verdedigbaar antwoord tijdens een audit of na een incident.

Platformvergelijking: Handmatige back-up versus geautomatiseerde/geplande back-up

CipherTrust Manager ondersteunt zowel handmatige back-ups op aanvraag als back-ups volgens een terugkerend schema. De twee zijn operationeel niet uitwisselbaar en de meeste organisaties hebben beide nodig.

Factor	Handmatige back-up	Geautomatiseerde/geplande back-up
Trigger	Voer dit uit door een beheerder vóór een geplande wijziging, upgrade of onderhoudsperiode.	Wordt uitgevoerd met een vast interval, ongeacht of een beheerder meekijkt.
Consistentie	Het hangt ervan af of iemand eraan denkt om het te starten.	Consistent zolang de back-upsleutel en de quorumvoorwaarden correct zijn ingesteld op het knooppunt waarop de taak terechtkomt.
Foutzichtbaarheid	De foutmelding wordt direct opgemerkt door de beheerder die het programma heeft uitgevoerd.	Een storing kan een volledige cyclus onopgemerkt blijven, tenzij er een waarschuwings- of beoordelingsproces is ingesteld.
Controlespoor	Eenmalig evenement, gemakkelijk individueel te documenteren.	Een terugkerend logboekcontroleproces is nodig om de voortdurende dekking aan te tonen.
Best gebruikt voor	Momentopnamen van vóór de wijziging en vóór de upgrade.	Reguliere dekking voor herstel na rampen tussen veranderingen

Incidentrespons indien een back-upfout wordt ontdekt tijdens een noodherstelprocedure

Het slechtste moment om te ontdekken dat een back-up van CipherTrust Manager stilletjes is mislukt, is midden in een noodherstelprocedure, wanneer er geen tijd meer is om eerst het onderliggende probleem met de sleuteldistributie op te lossen. Als dat gebeurt, werk dan in deze volgorde:

1. Identificeer elk knooppunt in het cluster en controleer elk knooppunt afzonderlijk op een bruikbaar, recent back-upbestand. Omdat back-ups lokaal op de knooppunten worden opgeslagen, kan een goede back-up aanwezig zijn op een ander knooppunt dan het knooppunt dat zojuist is uitgevallen.
2. Controleer welke back-upsleutel de meest recente bruikbare back-up heeft versleuteld en zoek het bijbehorende sleutelbestand en wachtwoord op, in plaats van ervan uit te gaan dat elke willekeurige "standaard" sleutel die je bij de hand hebt, werkt.
3. Als er alleen een back-up op domeinniveau beschikbaar is en een volledig systeemherstel niet mogelijk is, herstel dan eerst de back-up op domeinniveau om de sleutels en beleidsregels voor dat domein te herstellen, aangezien back-ups op domeinniveau op elk clusterknooppunt kunnen worden hersteld.
4. Als het doel een bestaand, actief clusterknooppunt is, probeer dan geen rechtstreeks systeemherstel uit te voeren. Gebruik de methode voor het verwijderen en opnieuw opbouwen van het cluster, of neem contact op met de Thales-ondersteuning voor advies over de veiligste procedure voor die omgeving.
5. Zodra de dienstverlening is hersteld, moet het incident worden beschouwd als de aanleiding voor een volledige controle van de back-upsleutels op alle knooppunten, niet alleen op het knooppunt dat is uitgevallen, en moet de fout in de sleuteldistributie worden gecorrigeerd die de oorspronkelijke, onopgemerkte storing heeft veroorzaakt.

Het Encryption Advisory Services-team van Encryption Consulting kan dit soort DR-simulaties uitvoeren op een live CipherTrust Manager-cluster voordat er zich een echt incident voordoet. Zo komen de tekortkomingen aan het licht tijdens een oefening in plaats van tijdens een daadwerkelijke storing.

Foutsymptoom, waarschijnlijke oorzaak en oplossing

Foutsymptoom	waarschijnlijke oorzaak	Bepalen
codeDesc: NCERRInvalidParamValue, “De opgegeven back-upsleutel bestaat niet voor het bereik (systeem)”	De back-upsleutel is niet geüpload en niet als standaard ingesteld op het knooppunt dat de geplande taak uitvoert.	Maak de systeemback-upsleutel aan en download deze, upload hem naar elk clusterknooppunt en stel hem op elk knooppunt in als standaard.
De geplande back-up produceert geen bestand en geeft geen duidelijke foutmelding.	Voordat de taak werd uitgevoerd, bleef het quorumbeleid ingeschakeld op het knooppunt.	Schakel alle quorumbeleidsregels uit voordat u de back-up uitvoert of plant.
De back-up is voltooid, maar het herstel mislukt vanwege een sleutelmismatch.	De back-upsleutel die voor het herstel wordt gebruikt, is niet exact dezelfde sleutel waarmee het bestand op het bronknooppunt is versleuteld.	Zoek en gebruik het specifieke back-upsleutelbestand dat actief was op het bronknooppunt tijdens de back-up.
Het herstelverzoek wordt geweigerd op een bestaand clusterknooppunt.	Systeembackups zijn niet ontworpen om te worden hersteld op een actief clusterknooppunt.	Gebruik de methode voor het verwijderen en opnieuw opbouwen van het cluster in plaats van een directe herstelbewerking.
Herstel geweigerd vanwege een versieoverschrijding	De back-up is meer dan drie kleine releases ouder dan de huidige versie van CipherTrust Manager.	Gebruik de optie –force restore alleen na overleg met de Thales-ondersteuning, of herstel eerst via een tussenliggende versie.
De back-up- of herstelopdracht mislukt met een melding dat de computer bezet is of vergrendeld is.	Er is al een andere back-up- of herstelbewerking actief, en er is er maar één tegelijk toegestaan.	Wacht tot de lopende taak is voltooid voordat je een nieuwe start.

Beperkingen

• Backups en back-upsleutels zijn per definitie lokaal op de node; er is geen ingebouwde automatische replicatie binnen een CipherTrust Manager-cluster, dus de sleuteldistributie moet handmatig worden beheerd telkens wanneer een schema of sleutel wijzigt.
• Een systeemback-up kan niet rechtstreeks worden hersteld op een knooppunt dat nog steeds deel uitmaakt van een actief cluster; het herstellen van een geclusterde omgeving vereist het verwijderen en opnieuw opbouwen van het systeem.
• Compatibiliteit bij het herstellen van een back-up geldt standaard slechts voor drie kleinere releases, waardoor de periode waarin een oude back-up praktisch herstelbaar blijft zonder tussenkomst van de supportafdeling, beperkt is.
• Er kan slechts één back-up- of hersteltaak tegelijk worden uitgevoerd, wat een knelpunt kan vormen tijdens een grootschalig herstel waarbij meerdere domeinen betrokken zijn.
• Het koppelen van een back-up aan een HSM-root-of-trust-sleutel biedt extra bescherming, maar introduceert ook een permanent risico: als die HSM-sleutel wordt verwijderd, kan de back-up niet meer worden hersteld.

Wat zou Encryption Consulting aanbevelen?

Het oplossen van de directe NCERRInvalidParamValue-fout is een klusje van vijf minuten zodra de oorzaak bekend is. Het terugkerende probleem dat we zien bij CipherTrust Manager-implementaties is dat back-upsleutels worden behandeld als een eenmalige installatiestap in plaats van een doorlopend onderdeel van de levenscyclus, zonder benoemde eigenaar, zonder rotatiecyclus en zonder auditlogboek totdat een herstel daadwerkelijk nodig is en mislukt.

De HSM-as-a-Service van Encryption Consulting biedt organisaties een beheerde operationele laag rond platforms zoals CipherTrust Manager, inclusief consistente distributie van back-upsleutels, gecontroleerde planning en bewijsverzameling, zonder dat er extra personeel nodig is voor het beheer van de appliance. Organisaties die eerst hun huidige sleutelbeheer- en back-uppraktijken willen beoordelen en formaliseren, kunnen bij ons Encryption Advisory Services- team een ​​analyse uitvoeren op basis van de hierboven beschreven criteria voor eigendom, rotatie, toegang en audit, en een draaiboek opstellen dat specifiek is afgestemd op hun clustertopologie.

Conclusie

De NCERRInvalidParamValue-fout in de back-upsleutel is eenvoudig te verhelpen als u weet dat CipherTrust Manager back-upsleutels niet automatisch over een cluster verdeelt. De complexere, maar duurzamere oplossing is operationeel: wijs een benoemde eigenaar toe voor back-upschema's, stel daadwerkelijke rotatietriggers in voor de back-upsleutel, beperk wie een back-up kan starten of herstellen en bewaar auditbewijs dat aantoont dat het schema daadwerkelijk is uitgevoerd, en niet alleen dat het was geconfigureerd. Teams die deze discipline hanteren, ontdekken back-upfouten niet langer tijdens een daadwerkelijke ramp, wat het enige moment is waarop het opsporen ervan echt kostbaar is.

Voor gerelateerde problemen met CipherTrust Manager kunt u onze handleidingen raadplegen over de clusterfout van CipherTrust Manager en de certificaatfout in de webinterface van CipherTrust Manager , of ons overzicht van de integratie van een Thales HSM met CipherTrust Manager on-premises . Als het doorlopende beheer het werkelijke knelpunt vormt, beschrijft onze uitleg over waarom teams speciale ondersteuning voor CipherTrust Manager inschakelen het bredere operationele plaatje.

Veelgestelde Vragen / FAQ

Waarom geeft CipherTrust Manager de melding "De opgegeven back-upsleutel bestaat niet voor het bereik (systeem)"?
Deze foutmelding betekent dat het knooppunt dat de geplande back-uptaak ​​heeft opgepakt, de back-upsleutel niet heeft en deze niet als standaard heeft ingesteld. CipherTrust Manager kopieert back-upsleutels niet automatisch tussen clusterknooppunten. Tenzij dezelfde standaardsleutel naar elk knooppunt is geüpload, zal een taak die op een knooppunt zonder deze sleutel terechtkomt, mislukken met deze foutmelding.

Worden de back-upsleutels van CipherTrust Manager automatisch gerepliceerd over alle clusterknooppunten?
Nee. In de documentatie van Thales staat duidelijk vermeld dat back-ups en back-upsleutels niet automatisch naar andere knooppunten in een cluster worden gekopieerd en alleen bestaan ​​op het knooppunt waar ze zijn aangemaakt of handmatig geüpload. Elk knooppunt in het cluster heeft dezelfde standaard back-upsleutel nodig, die afzonderlijk moet worden geüpload.

Kan een systeemback-up van CipherTrust Manager rechtstreeks worden hersteld op een clusterknooppunt?
Nee. Systeembackups zijn niet ontworpen om te worden hersteld op een node die nog steeds deel uitmaakt van een actief cluster. Thales raadt in dat geval de methode aan om het cluster te verwijderen en opnieuw op te bouwen. Back-ups op domeinniveau zijn anders en kunnen op elke clusternode worden hersteld.

Hoe vaak moeten de back-upsleutels van CipherTrust Manager worden geroteerd?
Er is geen vast door Thales voorgeschreven interval, dus dit moet aansluiten bij het algemene sleutelrotatiebeleid van de organisatie, aangevuld met gebeurtenisgestuurde triggers: na personeelswijzigingen met toegang tot de sleutel, na een herstelfout als gevolg van een sleutelmismatch, vóór het buitenbedrijf stellen van een node, of na een vermoedelijke blootstelling van het back-upsleutelbestand of wachtwoord.

Wat gebeurt er als een back-up van CipherTrust Manager is gekoppeld aan een HSM-root-of-trust-sleutel die wordt verwijderd?
Volgens de documentatie van Thales kan een back-up die aan de HSM is gekoppeld nooit worden hersteld als de HSM-vertrouwenssleutel waarvan deze afhankelijk is, handmatig wordt verwijderd. Elke organisatie die back-ups koppelt aan een HSM-vertrouwenssleutel, moet de levenscyclus en verwijderingsbeheer van die sleutel beschouwen als onderdeel van de back-upstrategie, en niet als een aparte kwestie.

Referenties

• Thales Docs, “Backups,” CipherTrust Manager 2.9 Beheerhandleiding, thalesdocs.com
• Thales Docs, “Backups,” CipherTrust Manager 2.10 Beheerhandleiding, thalesdocs.com
• Thales Docs, “Systeemlogboeken,” CipherTrust Manager Beheerhandleiding, thalesdocs.com