Uppgradera säkert till Vormetric Data Security Manager och migrera sömlöst till CipherTrust Manager

Att uppgradera Vormetric Data Security Manager (DSM) , Thales nyckel- och policyhanteringsverktyg för Vormetric Transparent Encryption (VTE)-miljöer, kan verka relativt enkelt, men om något går fel kan data som skyddas av DSM-hanterad kryptering gå förlorade eller bli oåtkomliga. Thales meddelade att Vormetric DSM nådde slutet av sin livscykel i juni 2024, vilket gör migrering till CipherTrust Manager (CTM) till ett brådskande affärskritiskt beslut för alla återstående DSM-användare. Den här artikeln tillhandahåller inte steg-för-steg-uppgraderingskommandon, utan täcker snarare vad organisationer måste vara försiktiga med: de tekniska och icke-tekniska punkter som den officiella uppgraderingsguiden inte betonar, och de verkliga utmaningar som produktions-DSM-uppgraderingar och CTM-migreringar presenterar. Den rekommenderade åtgärden: dokumentera din fullständiga agentinventering och kompatibilitetsmatris innan du rör vid något, sätt din DSM till 6.4.5 eller 6.4.6 innan du försöker migrera CTM och kör uttömmande pilottester i en icke-produktionsmiljö innan någon produktionsövergång. För nyckelhanteringskontext, se CipherTrust Manager och Vad är nyckelhantering.

Snabbt svar: Vilka är de två vägarna och vilken gäller dig?

Det finns två distinkta operativa vägar: att uppgradera en befintlig DSM-instans till en nyare DSM-version och att migrera från DSM helt till CipherTrust Manager. De två vägarna är sekventiella, inte alternativa, för de flesta organisationer: om din DSM inte redan har version 6.4.5 eller 6.4.6 måste du först uppgradera DSM innan migreringsverktygen kan flytta dina data till CTM. Båda vägarna medför risk för dataförlust och driftstopp om de utförs utan noggrann planering, en kompatibilitetsmatris och pilottester. CTM är en annan produkt än DSM, inte bara en uppgraderad version, så migreringen kräver också nya runbooks, nya standardrutiner, ny arkitekturdokumentation och omskolning för driftsteam.

Planering: Vad du bör dokumentera innan du börjar

Allt börjar med god planering, och DSM-uppgraderingen är inget undantag. En fullständig genomsökning av den nuvarande miljön är avgörande för att bedöma eventuella framtida hinder eller utmaningar som du kan möta.

1. Dokumentera alla agenter, agentversioner och skyddspunkter. När du uppgraderar DSM kan du kontrollera listan över alla agenter och bekräfta om alla skyddspunkter är aktiva och felfria. Om något inte matchar som förväntat kan du behöva felsöka innan du fortsätter. Agentversioner kan också visa om du har agenter som är inkompatibla med den DSM-version du vill uppgradera till. En kompatibilitetsmatris hjälper dig att avgöra vilka agenter som är kompatibla och vilka som behöver uppgraderas. Du kan också utveckla en uppgraderingsväg från denna inventering. Thales definierar en obligatorisk uppgraderingsväg som måste följas: till exempel, om du uppgraderar från DSM 5.3 till 6.2 kan du inte hoppa direkt till 6.2 utan att gå igenom mellanversionen 6.0.0.

2. Planera produktionsövergången. Många organisationer som vill uppgradera bör redan ha en produktions-DSM i drift i sin miljö. De föredrar vanligtvis att inte uppgradera den befintliga produktions-DSM:n; istället aktiverar de en annan DSM vid målversionen, genomför pilottester och byter till den nya DSM:n som produktionsinstans först efter att testningen är klar. Organisationer bör planera tidpunkten för övergången, kommunikationen och återställningsprocedurerna innan de påbörjar något uppgraderingsarbete.

Noggrann planering säkerställer att följande steg går smidigt och att DSM kan uppgraderas till önskad version utan oväntade data- eller tjänsteavbrott.

Uppgradering av DSM:er: Verkliga utmaningar

Planering kan underlätta uppgraderingsprocessen, men uppgradering av ett produktions-DSM avslöjar ofta utmaningar som inte var synliga under planeringen. Utmaningar som uppstår vid verkliga produktionsuppgraderingar inkluderar:

1. Övergång från den gamla DSM till den nya DSM utan att störa agentregistreringen, vilket kräver noggrann orkestrering av agentåterregistreringssekvensen.
2. Uppgradera DSM till en version där alla befintliga agenter förblir kompatibla, särskilt när miljön innehåller en blandning av agentversioner från olika epoker
3. Konfigurera kluster med hög tillgänglighet (HA) med DSM:er på olika undernät, vilket introducerar komplexa nätverks- och klustersynkroniseringsproblem som inte täcks av den grundläggande uppgraderingsdokumentationen.
4. Planering av uppgraderingstid: DSM-uppgraderingar kan ta avsevärd tid beroende på miljöns storlek, och utan korrekt planering av omställning kan produktionssystem drabbas av oplanerade driftstopp. Med tillräcklig planering kan DSM-omställning ske sömlöst utan driftstopp.

Organisationer bör noggrant förbereda sig för att uppgradera DSM:er, eftersom ett fel i uppgraderingsprocessen kan göra krypterad data permanent oåtkomlig.

Migrering till CipherTrust Manager

Thales meddelade att Vormetric DSM nådde slutet av sin livscykel i juni 2024. Som ett resultat migrerar organisationer sina DSM:er till CipherTrust Manager . Att migrera från DSM till CTM medför en annan typ av utmaning: CTM är en annan produkt, inte bara en uppgraderad DSM, och migreringen kräver att nya operativa procedurer bygger från grunden tillsammans med den tekniska migreringen av nycklar, policyer och konfigurationer.

Vanliga problem som organisationer har när de planerar en CTM-migrering inkluderar:

• Migrering av policyer, nycklar, användaruppsättningar och processuppsättningar: vilka objekt överförs och vilka måste byggas om
• Migrering av värdar och omregistrering av agenter till CTM
• Konfiguration av hög tillgänglighet i CTM-arkitekturen, som skiljer sig från DSM HA
• Driftstopp och systemavbrott under migreringsfönstret
• Risk för dataförlust från felaktig nyckelmigrering eller konfigurationsfel för Guardpoint

Om organisationer redan använder DSM 6.4.5 eller 6.4.6 kan de migrera till CipherTrust Manager och återställa följande objekt:

1. Agentnycklar, inklusive versionsnycklar och KMIP-åtkomliga agentnycklar
2. Valvnycklar
3. Ta med egna nycklar (BYOK)-objekt
4. domäner
5. CipherTrust Transparent Encryption (CTE)-konfiguration

Objekt som INTE återställs under migreringen

1. bro Nyckelhantering KMIP-nycklar (Interoperability Protocol), förutom KMIP-åtkomliga agentnycklar
2. Nycklar associerade med CipherTrust Cloud Key Manager (CCKM), inklusive nyckelmaterial som en tjänst (KMaaS)-nycklar
3. DSM-värdnamn och värdkonfiguration

Att standard KMIP-nycklar och CCKM-nycklar inte migreras är en av de mest underskattade bristerna. Organisationer med KMIP-baserade integrationer måste planera för hur dessa integrationer ska återupprättas i CTM innan migreringen påbörjas. När kunder migrerar är omfattande pilottester avgörande för att säkerställa att migreringen fortskrider utan dataförlust. Kunder bör också genomföra en rensningssession av DSM före migreringen, där alla avaktiverade servrar och inaktiva användare tas bort, så att endast giltiga, aktuella konfigurationer överförs till CTM. Vid migrering från DSM till CTM måste agenter som kör VTE-agenter under version 7.0 uppgraderas till CipherTrust Transparent Encryption (CTE) innan migreringen kan fortsätta.

Fördelar med att migrera till CipherTrust Manager

1. Förbättrat webbläsarbaserat användargränssnitt som ersätter DSM:s äldre gränssnitt
2. Inga hypervisorbegränsningar: CTM stöder distribution i fysiska och virtuella miljöer utan hypervisorbegränsningarna i DSM
3. Fullt utrustat fjärrgränssnitt för CLI för driftshantering
4. Inbäddad CipherTrust Cloud Key Manager (CCKM) för enhetlig molnnyckelhantering över AWS, Azure, GCP och andra molnleverantörer
5. Bättre nyckelhanteringsfunktioner med KMIP-nyckelmaterial: integrerar policy, loggning och hantering i en förenklad och rikare KMIP-upplevelse
6. Stöder CTE-agenter (bytt namn från VTE-agenter) från version 7.0, vilket ger en tydlig framåtriktad väg för krypterad värdhantering
7. Nytt REST API för automatisering, vilket möjliggör integration med DevOps-verktygskedjor och säkerhetsorkestreringsplattformar

Utöver dessa plattformsomfattande förbättringar erbjuder CTM även specialiserade funktioner som är värda att överväga:

1. Lösenord och PED-autentisering: I likhet med S-seriens Luna HSM erbjuder Thales möjligheten att välja lösenord och PED (PIN Entry Device) som autentiseringsmekanismer för CTM. PED-autentisering ger förbättrad säkerhet men är endast tillgänglig för fysiska k570-apparater.
2. Multimoln- och hybriddistribution: CTM stöder distribution i flera molnmiljöer, inklusive AWS, Azure, GCP, VMware, HyperV och Oracle VM. Organisationer kan också bilda hybridkluster som kombinerar fysiska och virtuella apparater för miljöer med hög tillgänglighet, vilket ger distributionsflexibilitet som DSM inte stödde.

DSM-uppgradering kontra CTM-migrering: Beslutstabell

Scenario	Rekommenderad åtgärd	Viktig förutsättning	Primär risk
DSM under 6.4.5 och ingen CTM-migrering planerad ännu	Uppgradera DSM till 6.4.5 eller 6.4.6 med hjälp av den obligatoriska Thales-uppgraderingsvägen	Komplett agent- och guardpoint-inventering; kompatibilitetsmatris	Agentinkompatibilitet; GuardPoint-avbrott under uppgradering
DSM vid 6.4.5 eller 6.4.6 och planerar CTM-migrering	Kör en uttömmande CTM-pilot i icke-produktion före produktionsmigrering	Uppgradera alla VTE-agenter under 7.0 till CTE; DSM-rensning före migrering	Icke-migrerande KMIP-nycklar lämnar integrationer trasiga efter migreringen
DSM med betydande KMIP-integrationer	Kartlägg alla KMIP-integrationer före migrering; planera återupprättning i CTM	Identifiera alla KMIP-nycklar som inte kommer att migreras och planera återregistrering	KMIP-beroende applikationer förlorar nyckelåtkomst efter migrering
DSM i HA-konfiguration på olika delnät	Engagera krypteringskonsulttjänster för arkitekturspecifik migreringsplanering	Dokumentera alla detaljer om HA-nätverkskonfiguration; planera subnätsrouting	Felkonfiguration av HA-kluster orsakar split-brain eller synkroniseringsfel
DSM har redan passerat slutet av sin livscykel utan migreringsplan	Börja migreringsplaneringen omedelbart; prioritera baserat på datakritik	Thales support och åtkomst till dokumentation; verifiering av uppgraderingsväg	DSM-version som inte stöds skapar efterlevnads- och säkerhetsrisker

Checklista före migrering

• Dokumentera alla DSM-agenter, agentversioner och guardpoints; skapa en komplett agentinventering innan någon uppgradering eller migreringsaktivitet påbörjas.
• Utveckla en kompatibilitetsmatris som bekräftar vilka agenter som är kompatibla med mål-DSM-versionen eller CTM
• Verifiera den obligatoriska DSM-uppgraderingssökvägen och identifiera alla mellanversioner som krävs för att nå målversionen.
• Bekräfta att DSM-versionen är 6.4.5 eller 6.4.6 innan CTM-migreringen påbörjas; uppgradera DSM först om det finns en tidigare version.
• Uppgradera alla VTE-agenter under version 7.0 till CipherTrust Transparent Encryption (CTE)-agenter före CTM-migrering
• Genomför en DSM-rensningssession: ta bort alla avaktiverade servrar, inaktiva användare, inaktuella principer och oanvända objekt före migrering
• Identifiera alla KMIP-nycklar och CCKM-nycklar i DSM som inte kommer att migreras till CTM; planera för återupprättandet av dessa integrationer i CTM.
• Ställ upp en icke-produktionsinstans av CTM och kör en uttömmande pilotmigrering innan du vidrör produktions-DSM:en
• Validera alla skyddspunkter och nyckelåtkomst i CTM-pilotmiljön innan produktionsmigrering schemaläggs
• Planera tidsplanen för produktionsavbrott med definierade underhållsfönster och meddela alla affärsintressenter om förväntad påverkan på tjänsten
• Dokumentera alla nya CTM-runbooks, standardrutiner och arkitekturdokumentation innan produktionsstart
• Planera CTM HA-konfiguration för produktion; testa HA-redundansväxling i icke-produktionsmiljön före produktionsdistribution

Slutsats

Att uppgradera DSM kan vara utmanande och kräver noggrann planering och felsökning. Att migrera till CTM är en annan nivå av komplexitet eftersom CTM är en annan produkt, inte bara en uppgraderad DSM. Organisationer som migrerar måste utveckla nya runbooks, standardrutiner och arkitekturdokument utöver den tekniska migreringen av nycklar och konfigurationer. Eftersom DSM nådde slutet av sin livscykel i juni 2024 står organisationer som fortfarande använder DSM inför ökande risker från en plattform som inte stöds och bör prioritera migreringsplanering omedelbart. Encryption Consulting kan hjälpa kunder att planera, uppgradera och migrera sina befintliga DSM:er. Som en certifierad partner till Thales och en organisation som har stöttat Vormetric-kunder med implementeringar och uppgraderingar i åratal kan Encryption Consulting hjälpa till att planera en fullständig migrering till CipherTrust Manager och tillhandahålla gap-bedömningar och förplanering för att säkerställa att kunderna inte drabbas av dataförlust, driftstopp eller produktionsproblem. Kontakta oss för mer information på [email protected].

Källor:

• Dokumentationsportal för CipherTrust-plattformen: DSM-migrering (thalesdocs.com)
• Dokumentationsportal för CipherTrust-plattformen: CTE-DSM-migrering (thalesdocs.com)

Vanliga frågor om partihandel med mat och dryck

Vad är Vormetric Data Security Manager (DSM) och vad är CipherTrust Manager (CTM)?

Vormetric Data Security Manager (DSM) är Thales nyckel- och policyhanteringsverktyg som hanterar krypteringsnycklar, policyer, användaruppsättningar, processuppsättningar och skyddspunkter för VTE-agenter på skyddade värdar. CipherTrust Manager (CTM) är Thales nästa generations datasäkerhetshanteringsplattform som ersätter DSM, med ett modernt webbläsarbaserat användargränssnitt, inga hypervisorbegränsningar, inbäddad CCKM för molnnyckelhantering, förbättrade KMIP-funktioner, stöd för CTE-agenter från version 7.0 och ett REST API för automatisering. Thales meddelade att DSM nådde slutet av sin livscykel i juni 2024.

Vilka objekt migrerar från DSM till CipherTrust Manager och vilka migrerar inte?

Objekt som migrerar från DSM 6.4.5 eller 6.4.6 till CTM inkluderar: Agentnycklar (inklusive versionsnycklar och KMIP-åtkomliga agentnycklar), Vaultnycklar, BYOK-objekt, domäner och CTE-konfiguration. Objekt som inte migrerar inkluderar: de flesta KMIP-nycklar förutom KMIP-åtkomliga agentnycklar, CCKM- och KMaaS-nycklar samt DSM-värdnamn och värdkonfiguration. Att standard-KMIP-nycklar inte migreras är en av de vanligaste underskattade bristerna i migreringsplaneringen.

Vilken version av DSM måste en organisation ha innan den migrerar till CipherTrust Manager?

Organisationer måste ha DSM version 6.4.5 eller 6.4.6 innan de migrerar till CTM. Om organisationen har en tidigare version måste de först uppgradera DSM via den obligatoriska Thales-uppgraderingsvägen till 6.4.5 eller 6.4.6. Dessutom måste alla VTE-agenter under version 7.0 uppgraderas till CTE-agenter innan CTM-migreringen kan fortsätta.

Vilka är de största riskerna med en DSM-uppgradering eller CTM-migrering?

De största riskerna är: dataförlust på grund av fel vid guardpoint- eller nyckelmigrering som gör krypterad data permanent oåtkomlig; produktionsavbrott på grund av dåligt planerad övergångstidpunkt; agentens inkompatibilitet med målversionen av DSM eller CTM; och konfigurationsluckor i KMIP-integrationer som orsakar att beroende applikationer går sönder efter migrering. Dessa risker minskas genom fullständig inventering före uppgradering, utveckling av kompatibilitetsmatriser, parallell uppgraderingstestning, rensning av DSM före migrering och omfattande pilottester före eventuell produktionsövergång.

Kan en DSM-uppgradering eller CTM-migrering utföras utan driftstopp?

En DSM-övergång kan utföras utan produktionsavbrott med hjälp av en parallell uppgraderingsmetod där en ny DSM vid målversionen tas upp och agenter växlas över utan avbrott. En migrering från DSM till CTM involverar en annan produkt och arkitektur och kräver vanligtvis planerade underhållsfönster för specifika migreringsåtgärder. Omfattningen av avbrottet beror på miljöns komplexitet, antal agenter och om migreringen kan ske i etapper.