Back-up en herstel voor geclassificeerde cloudworkloads: RTO, RPO en cryptografische continuïteit

Geclassificeerde militaire cloudworkloads zijn geen abstracte bezittingen. Ze draaien de targeting-pipelines, communicatie-infrastructuur en inlichtingenfusielagen die bepalen of een eenheid situationeel bewustzijn behoudt onder vuur. Wanneer die workloads uitvallen — en hardware faalt, faciliteiten stroomuitval ervaren en tegenstanders elk bereikbaar oppervlak aftasten — heeft de organisatie een getest, uitvoerbaar herstelplan nodig dat ze herstelt binnen de tijd die de missie kan tolereren. Back-up en noodherstel voor geclassificeerde systemen is geen afgeslankte versie van commercieel DR; het is een aparte ingenieursdiscipline gevormd door accreditatiebeperkingen, cryptografische sleutelafhankelijkheden en de operationele realiteit dat de systemen die het meest behoefte hebben aan snel herstel, het moeilijkst te herstellen zijn onder druk.

Dit artikel onderzoekt de volledige herstelstack voor geclassificeerde cloudworkloads: hoe RTO- en RPO-doelstellingen af te leiden uit missionskritische niveaus, hoe back-uparchitectuur te ontwerpen die voldoet aan classificatiegrenzen, hoe versleutelingssleutels te beheren zodat ze een primaire sitefout overleven en toegankelijk zijn op de DR-site binnen het herstellingsbudget, hoe databases en Kubernetes-clusters te back-uppen, hoe herstel te testen in omgevingen met beperkte fysieke toegang, en hoe cryptografische continuïteit te herstellen zodra systemen zijn teruggezet. De aanpak is technisch en operationeel — de beslissingen hier behoren toe aan platformengineers, information system security officers (ISSOs) en programmaarchitecten die samenwerken.

RTO- en RPO-vereisten voor militaire C2- en ISR-systemen

Recovery Time Objective (RTO) en Recovery Point Objective (RPO) zijn geen IT-serviceniveauovereenkomsten overgenomen uit een commercieel sjabloon. Voor geclassificeerde defensiesystemen worden ze afgeleid van het operationele tempo — het ritme waarop commandanten actuele gegevens nodig hebben om beslissingen te nemen — en van de missionskritische aard, die bepaalt hoe lang een capability afwezig kan zijn voordat de missie tot een onaanvaardbaar niveau degradeert.

Een praktisch kriticiteitskader deelt systemen in drie niveaus in:

• Niveau 1 — Missionskritische C2 en real-time ISR. Commando- en controleplatformen, real-time sensorfusie en actieve targetingsystemen. RTO: onder vier uur. RPO: onder 15 minuten. Een C2-systeem dat meer dan vier uur niet beschikbaar is tijdens een actieve operatie belemmert het vermogen van de commandant om orders uit te geven, te volgen en te herzien. Een RPO groter dan 15 minuten betekent mogelijk verlies van recente targeting- of situationele data die niet gereconstrueerd kan worden.
• Niveau 2 — ISR-analyse en missieondersteuningssystemen. Inlichtingenanalysewerkstations, communicatieopname en logistiekbeheer. RTO: 8–24 uur. RPO: één tot vier uur. Deze systemen ondersteunen missieplanning en -beoordeling in plaats van real-time uitvoering; hun afwezigheid vermindert de efficiëntie maar stopt de operaties niet onmiddellijk.
• Niveau 3 — Administratieve en archiefsystemen. Personeelssystemen, archiefopslag en administratieve toepassingen. RTO: 48–72 uur. RPO: 24 uur. Verlengde onbeschikbaarheid is operationeel aanvaardbaar; gegevensverlies van maximaal één werkdag is acceptabel.

De kritische ontwerpimplicatie van de niveauindeling is dat RTO-doelstellingen van niveau 1 — herstel in minder dan vier uur — alleen haalbaar zijn met hot- of warm-standby-architecturen. Koude back-up (tape of schijfback-up zonder lopende standby) introduceert herstelstappen die samen niet binnen vier uur kunnen worden voltooid: mediaopvraging, infrastructuurprovisioning, besturingssysteemherstel, applicatielaagsherstel, verificatie van beveiligingscontroles en ISSO-goedkeuring. Een programma dat gelooft dat het een RTO van vier uur heeft via alleen koude back-up, heeft de werkelijke herstelprocedure niet gemodelleerd.

Het RTO-budget moet per fase worden uitgesplitst en opgeteld voordat het als doelstelling wordt vastgesteld:

Herstelfase	Hot standby	Warm standby	Koude back-up
Failover-beslissing en autorisatie	5–15 min	15–30 min	30–60 min
Mediaopvraging / sleutelherstel	N.v.t. (live replica)	15–30 min	60–180 min
Infrastructuur- en OS-herstel	0–15 min	30–60 min	60–120 min
Applicatie- en dataherstel	0–5 min	20–60 min	60–240 min
Verificatie beveiligingscontroles + ISSO-goedkeuring	30–60 min	60–90 min	60–120 min

De verificatiestap van beveiligingscontroles — bevestigen dat classificatiemarkering, auditlogging, toegangscontroles en cryptografische bindingen allemaal correct functioneren op het herstelde systeem — wordt regelmatig weggelaten uit commerciële RTO-modellen. Voor geclassificeerde systemen is het verplicht vóór terugkeer naar operaties. Een nauwkeurige RTO-doelstelling houdt er rekening mee.

Back-uparchitectuur voor geclassificeerde workloads

De back-uparchitectuur voor geclassificeerde workloads vertrekt vanuit twee niet-onderhandelbare beperkingen: isolatie van de classificatiegrens en continuïteit van de accreditatie. Elke classificatie-enclave vereist fysiek gescheiden back-upinfrastructuur — gescheiden opslagknooppunten, gescheiden media, gescheiden back-upsoftware-instanties als de software een gedeeld beheervlak gebruikt. Geconsolideerde back-upinfrastructuur die enclaves overspant is een complianceovertreding, ongeacht of back-updata versleuteld is, omdat het gedeelde beheervlak een potentieel verborgen kanaal en een vergroot aanvalsoppervlak creëert.

Accreditatiecontinuïteit betekent dat de herstelomgeving — de infrastructuur waarnaar geclassificeerde data wordt hersteld tijdens een ramp — een actuele Authorization to Operate (ATO) moet hebben vóór de ramp, niet pas erna. De meest voorkomende geclassificeerde DR-fout in post-incidentbeoordelingen is niet een ontbrekende back-up; het is een back-up die bestaat maar juridisch niet binnen de vereiste termijn kan worden hersteld omdat de ATO van de herstelomgeving is verlopen.

Onveranderlijke back-upopslag is een verplichte maatregel voor geclassificeerde workloads op niveau 1 en niveau 2. Onveranderlijkheid — afgedwongen op hardware- of firmwareniveau via write-once-media of objectvergrendeling in compliance-modus — zorgt ervoor dat een ransomware-actor of kwaadaardige insider die back-upinfrastructuur compromitteert, back-upsets niet kan verwijderen of wijzigen. Softwarematig afgedwongen WORM dat kan worden overschreven door een bevoorrechte account voldoet niet aan deze vereiste. Voor on-premises geclassificeerde opslag is hardware-WORM-tape (LTO met WORM-cassettes) of een schijfapparaat met firmwareniveau-onveranderlijkheid de juiste keuze. Voor soevereine geclassificeerde cloudimplementaties biedt objectopslag met S3-compatibele objectvergrendeling in compliance-modus gelijkwaardige bescherming.

Een drielaagse architectuur voldoet aan het volledige scala aan herstelscenario's:

• Laag 1 — Lokale onveranderlijke back-up. Continue of uurlijkse incrementele back-ups naar lokale WORM-opslag binnen de geaccrediteerde faciliteit. Beschermt tegen operationele fouten: onbedoelde verwijdering, databasecorruptie, ransomware. Snelste herstelpad voor niet-catastrofale storingen.
• Laag 2 — Synchrone replicatie naar warm standby. Voor niveau-1-systemen worden databasetransactielogboeken en kritieke status gerepliceerd naar een secundair knooppunt in dezelfde of een aangrenzende geaccrediteerde faciliteit. Deze laag ondersteunt een RTO van minder dan vier uur. Replicatie vindt plaats binnen de accreditatiegrens — het secundaire knooppunt maakt deel uit van dezelfde geaccrediteerde omgeving.
• Laag 3 — Periodieke offsite-kopie naar DR-faciliteit. Wekelijkse of maandelijkse versleutelde back-upkopieën overgedragen naar een fysiek gescheiden geaccrediteerde faciliteit. Deze laag beschermt tegen catastrofaal verlies van de primaire site. Voor tactische edge cloud disconnected ops is deze overdracht fysiek — versleutelde media getransporteerd door een geautoriseerde koerier — en de koerier-transittijd moet worden opgenomen in de RTO-berekening voor het DR-scenario dat het dekt.

Air-gapped DR-sites introduceren een specifieke ontwerpuitdaging: de offsite-kopie loopt altijd achter op de primaire site met het interval tussen fysieke overdrachten. Een programma dat back-upmedia wekelijks overdraagt naar zijn DR-site heeft een potentieel gegevensverliesvenster van maximaal zeven dagen voor het scenario waarin de primaire site wordt vernietigd. Dit gat moet worden gedocumenteerd, geaccepteerd door de missiebevoegdheid en worden weergegeven in het noodplan van het systeem — niet verborgen in de architectuur.

Back-updata versleutelen: sleutelbeheer tijdens herstel

Elke back-upset voor een geclassificeerde workload moet in rust worden versleuteld met AES-256 (of het nationale equivalent goedgekeurd voor het classificatieniveau van het systeem). Het moeilijkere probleem is niet de versleuteling zelf — het is ervoor zorgen dat de ontsleutelingssleutels een primaire sitefout overleven en toegankelijk zijn op de DR-site binnen het herstellingstijdsbudget.

De aanbevolen sleutelhiërarchie voor geclassificeerde back-upversleuteling heeft drie niveaus:

• Key Encryption Key (KEK). Een hoofdsleutel bewaard in een Hardware Security Module (HSM) binnen de geaccrediteerde faciliteit. De KEK verlaat de HSM nooit in platte tekst. Toegang tot de KEK vereist multi-party-autorisatie — minimaal twee bevoegde personen met afzonderlijke HSM-authenticatiegegevens (een m-van-n-quorumschema, doorgaans 2-van-3 of 3-van-5).
• Data Encryption Key (DEK). Een unieke AES-256-sleutel gegenereerd per back-uptaak. De DEK versleutelt de back-updata. Na voltooiing van de back-uptaak wordt de DEK versleuteld (gewrapped) door de KEK binnen de HSM en de gewrapte DEK wordt opgeslagen naast de back-upmetadata. De DEK in platte tekst wordt nooit naar schijf geschreven.
• Sleutelescrow op de DR-site. De KEK wordt gesynchroniseerd naar een secundaire HSM op de DR-site, ofwel via continue HSM-clusterreplicatie of via een periodieke sleutelback-upprocedure. De secundaire HSM bewaart de KEK in een even beveiligde omgeving en geeft deze vrij aan bevoegde herstelaanbieders tijdens een gedeclareerde ramp, waardoor DEK-uitpakking en back-updecryptie ter plaatse mogelijk wordt.

De escrow-synchronisatiefrequentie bepaalt de maximale veroudering van de DR-site-KEK. Voor roterende KEKs (jaarlijkse of frequentere rotatie) moet de escrow-update plaatsvinden binnen één rotatieperiode. De escrowprocedure — inclusief de authenticatie- en autorisatiestappen die vereist zijn voor de DR-site-HSM om de bijgewerkte sleutel te accepteren — moet worden gedocumenteerd, en de documentatie moet worden opgeslagen op de DR-site (niet alleen op de primaire site).

Voor diepere context over HSM-selectie en post-quantum sleutelbeheer HSM-architecturen die langdurige weerstand bieden tegen quantum-aanvallen op opgeslagen cijfertekst, raadpleeg de gekoppelde behandeling. De bovenstaande sleutelhiërarchie is compatibel met post-quantum KEK-algoritmen (CRYSTALS-Kyber of ML-KEM op CNSA 2.0-niveaus) zonder de structurele relatie tussen de lagen te wijzigen.

Een DR-runbook dat nooit van begin tot eind is geoefend — inclusief de DR-site-HSM-authenticatie en DEK-uitpakking — heeft zijn meest foutgevoelige stap niet gevalideerd. Sleutelherstel moet worden geoefend als een benoemde stap in elke volledige herstelrepetitie, niet als een veronderstelde capability.

Databaseback-upstrategieën voor operationele C2-systemen

Operationele C2-systemen slaan status gewoonlijk op in relationele databases: PostgreSQL is de dominante open-source keuze voor geaccrediteerde defensie-cloudimplementaties. De standaard commerciële back-up van "dagelijkse volledige dump plus nachtelijke differentials" voldoet niet aan de RPO-vereisten van niveau-1-systemen — een RPO van 15 minuten vereist een continu back-upmechanisme dat elke vastgelegde transactie vastlegt.

PostgreSQL's Write-Ahead Log (WAL) biedt dat mechanisme. Elke vastgelegde databasewijziging wordt naar een WAL-segment geschreven voordat het op de gegevensbestanden wordt toegepast. Door WAL-segmenten continu te archiveren naar geaccrediteerde back-upopslag onmiddellijk nadat ze zijn geschreven, accumuleert u een volledig wijzigingslogboek dat vooruit kan worden afgespeeld vanuit elke basisback-up naar elk willekeurig punt in de tijd — tot het laatste gearchiveerde segment vóór een storing. Dit is Point-in-Time Recovery (PITR).

Configuratie in postgresql.conf voor continue WAL-archivering met versleuteling:

wal_level = replica
archive_mode = on
archive_command = '/opt/backup/encrypt-wal.sh %p %f'
archive_timeout = 60        # force segment switch every 60 seconds maximum
restore_command = '/opt/backup/decrypt-wal.sh %f %p'
recovery_target_time = '2026-06-25 14:30:00 UTC'  # set in recovery.conf

Het encrypt-wal.sh-script moet het WAL-segment versleutelen met de HSM-ondersteunde DEK voordat het naar de archieflocatie wordt geschreven. De archive_timeout van 60 seconden zorgt ervoor dat zelfs tijdens periodes met weinig schrijfactiviteit WAL-segmenten minimaal elke minuut worden gearchiveerd, waardoor de RPO onder normale omstandigheden wordt begrensd op ongeveer één minuut.

Voor C2-systemen die bestaan uit meerdere microservices die een gedistribueerde status delen — een veelvoorkomend patroon waarbij targetingdata stroomt tussen een sensorfusieservice, een beslissingsondersteunende service en een communicatiegateway — vereist back-upconsistentie dat momentopnames van alle servicedatabases worden gemaakt op hetzelfde logische punt in de tijd. Een back-upset waarbij de targetingupdate aanwezig is in de fire-control-database maar nog niet in de ISR-fusiedatabase, produceert een logisch inconsistente herstelstatus. Consistente momentopnames over microservices worden bereikt via:

• Een gedistribueerde momentopname-coördinator die een quiesce-signaal uitgeeft aan alle services, wacht tot lopende transacties zijn afgerond, momentopnames op alle databases gelijktijdig activeert en vervolgens de quiesce vrijgeeft.
• Pre-back-uphooks in de containerorchestrator die de quiesce-API van elke service aanroepen voordat de volumemomentopname wordt geactiveerd.
• Een volgnummer of globale transactie-ID die in elke momentopnameset wordt gestempeld, waardoor herstelprocedures kunnen verifiëren dat alle componenten van een herstelset dezelfde logische tijdstempel delen voordat wordt overgegaan tot herstel.

Kubernetes workload back-up

Velero is het standaard open-source hulpmiddel voor Kubernetes workload back-up in zowel commerciële als defensiecontexten. In een geclassificeerd air-gapped cluster vereist de implementatie van Velero specifieke aanpassingen: alle Velero-containerimages, plugin-images (met name de CSI-plugin en eventuele objectopslagprovider-plugins) en de Velero CLI-binaire bestanden moeten vooraf worden gestationeerd in het lokale imageregister van het cluster vóór een ramp, omdat het cluster tijdens herstel niet uit externe registers kan trekken.

Velero maakt back-ups van Kubernetes API-objecten — Deployments, DaemonSets, Services, ConfigMaps, Secrets, PersistentVolumeClaims, NetworkPolicies, RBAC-objecten en aangepaste resources — en activeert CSI-volumemomentopnames voor persistente data. Een Velero back-upschema voor een geclassificeerd cluster:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: classified-cluster-hourly
  namespace: velero
spec:
  schedule: "0 * * * *"          # every hour
  template:
    storageLocation: classified-backup-location
    volumeSnapshotLocations:
      - classified-csi-snapshots
    includedNamespaces:
      - c2-platform
      - isr-fusion
      - comms-gateway
    hooks:
      resources:
        - name: db-quiesce
          includedNamespaces:
            - c2-platform
          labelSelector:
            matchLabels:
              app: postgres
          pre:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_start_backup('velero', true);"
                timeout: 60s
          post:
            - exec:
                command:
                  - /bin/sh
                  - -c
                  - psql -c "SELECT pg_stop_backup();"
                timeout: 60s
    ttl: 720h                    # 30-day retention

Wat Velero niet maakt: etcd-status (Velero leest van de API-server, niet rechtstreeks van etcd), knooppuntniveau-OS-configuratie, control-plane-binaire bestanden en data geschreven naar node-lokale opslag buiten persistente volumes. etcd moet afzonderlijk worden geback-upt. Voor een drie-knooppunts control plane, voer het volgende uit op elk control-plane-knooppunt en versleutel de uitvoer:

ETCDCTL_API=3 etcdctl snapshot save \
  /tmp/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Encrypt snapshot before archiving
gpg --symmetric --cipher-algo AES256 \
  --batch --passphrase-file /etc/backup/etcd-key.txt \
  /tmp/etcd-snapshot-*.db

# Verify snapshot integrity
etcdctl snapshot status /tmp/etcd-snapshot-*.db

etcd-momentopnames moeten uurlijks worden gepland op alle control-plane-knooppunten, waarbij de versleutelde momentopnames worden geschreven naar dezelfde geaccrediteerde back-upopslag die wordt gebruikt voor Velero-back-ups. Een volledige Kubernetes DR-strategie vereist zowel Velero (voor workloadlaagstatus) als etcd-momentopnames (voor clusterlaagstatus). Alleen de ene herstellen produceert een onherstelbaar cluster — de API-objecten in etcd en de persistente data in volumes moeten consistent zijn met elkaar.

PersistentVolumeClaim-momentopnamestrategieën zijn afhankelijk van de gebruikte opslagklasse. Voor CSI-ondersteunde opslag in geclassificeerde omgevingen moet het opslagstuurprogramma de CSI-momentopname-interface implementeren en de momentopnames moeten worden opgeslagen in geaccrediteerde opslag. Voor NFS of legacy-opslag die geen CSI-momentopnames ondersteunt, kan de bestandssysteemback-upmodus van Velero (Kopia-gebaseerd) PVC-data back-uppen door bestanden rechtstreeks te kopiëren van gekoppelde volumes — langzamer dan CSI-momentopnames maar toepasbaar op elk opslagtype.

Hersteltesten in geclassificeerde omgevingen

Hersteltesten in geclassificeerde omgevingen zijn meer beperkt dan in commerciële omgevingen: u kunt geen willekeurige publieke cloudomgeving opzetten als hersteldoel, u kunt niet testen met productiedata buiten de accreditatiegrens, en u kunt geen herstelrepetities uitvoeren tijdens operationele uren zonder voorafgaande autorisatie en een getest terugdraaiplan.

Het DR-oefenschema voor een geclassificeerd programma moet een driefasen cadans volgen:

• Tabletop-oefening — per kwartaal. Het herstelteam doorloopt het runbook mondeling en identificeert stappen die onduidelijk zijn, rollen die niet bezet zijn of afhankelijkheden die niet zijn gedocumenteerd. Er worden geen systemen aangeraakt. Resultaat: een bijgewerkt runbook en een lijst met hiaten om te verhelpen.
• Functionele oefening — halfjaarlijks. Een deelverzameling van de herstelprocedure wordt uitgevoerd in een live omgeving: bijvoorbeeld het herstellen van één database van back-up en het verifiëren van gegevensintegriteit, of het herstellen van een Velero-back-up van één namespace en bevestigen dat de toepassing opstart. Gedeeltelijke dekking tegen lagere kosten en risico dan een volledige repetitie.
• Volledige herstelrepetitie — minimaal jaarlijks, halfjaarlijks voor niveau 1. Een volledig end-to-end herstel van back-up naar een in quarantaine geplaatste herstelomgeving. Alle herstelfasen worden uitgevoerd, inclusief sleutelherstel, verificatie van beveiligingscontroles en ISSO-goedkeuring. Werkelijke RTO en RPO worden gemeten en vergeleken met doelstellingen.

Gegevensintegriteitsverificatie na herstel vereist meer dan bevestigen dat de database start. Voor relationele databases omvat integriteitsverificatie:

# PostgreSQL post-restore integrity checks
# 1. Verify row counts match expected values from pre-backup audit log
psql -c "SELECT schemaname, tablename, n_live_tup
         FROM pg_stat_user_tables ORDER BY schemaname, tablename;"

# 2. Check for constraint violations after restore
psql -c "SELECT conname, conrelid::regclass
         FROM pg_constraint WHERE NOT convalidated;"

# 3. Verify WAL replay reached the target recovery time
psql -c "SELECT pg_last_xact_replay_timestamp();"

# 4. Run application-layer health check
curl -sf https://c2-platform.internal/health/deep | jq '.checks'

De RTO-meetmethodologie moet nauwkeurig zijn: de klok begint wanneer een ramp formeel wordt verklaard (niet wanneer de storing voor het eerst wordt gedetecteerd — incidentdetectie en -aangifte kunnen 15–30 minuten duren en moeten worden afgetrokken van het resterende budget). De klok stopt wanneer de ISSO formeel de gereedheid van het herstelde systeem voor geclassificeerde operaties ondertekent — niet wanneer de applicatie zijn eerste succesvolle gezondheidscontrole retourneert. Het verschil tussen deze twee interpretaties kan 60–90 minuten bedragen, wat kan bepalen of een programma zijn contractuele of regulatoire RTO-verplichting nakomt.

Cryptografische continuïteit na herstel

Een systeem dat van back-up is hersteld, is cryptografisch niet identiek aan het systeem waarvan een back-up werd gemaakt. Afhankelijk van wanneer de back-up is gemaakt ten opzichte van de laatste sleutelrotatie, certificaatuitgifte of sessie-instelling, kan het herstelde systeem werken met verouderd cryptografisch materiaal dat verlopen, ingetrokken of inconsistent is met de huidige status van verbonden systemen. Cryptografische continuïteit is de set procedures die de cryptografische status van het herstelde systeem na herstel in lijn brengt met de operationele omgeving.

HSM-failover hersleuteling. Wanneer de primaire HSM uitvalt en de DR-site secundaire HSM het overneemt, is de eerste stap het verifiëren dat de sleutelinventaris van de secundaire HSM actueel is. Voor HSMs die continue clusterreplicatie gebruiken, zou de secundaire actueel moeten zijn vanaf het laatste replicatie-heartbeat — doorgaans binnen enkele seconden. Voor HSMs die periodieke sleutelback-up gebruiken, kan de secundaire achterliggen met het back-upinterval. Sleutels die zijn aangemaakt of geroteerd na de laatste back-up zijn niet aanwezig in de secundaire en moeten opnieuw worden afgeleid of uitgegeven voordat de systemen die ervan afhankelijk zijn, kunnen werken. Een sleutelinventarisaudit — het vergelijken van de sleutellijst van de secundaire HSM met het laatste auditlogboek van de primaire — is de eerste cryptografische actie na HSM-failover.

Certificaatstatus na herstel. Kubernetes-clustercertificaten en applicatie-TLS-certificaten hebben vervaldatums die voortschrijden ongeacht of het systeem draait. Een cluster hersteld vanuit een back-up die 30 dagen oud is, wordt hersteld in een staat waarbij 30 dagen zijn verbruikt van de resterende geldigheid van elk certificaat. Als een certificaat binnen 30 dagen van verlopen was op het moment van de back-up, is het verlopen in het herstelde cluster. De certificaatauditprocedure:

# Audit all Kubernetes control-plane certificate expiry
kubeadm certs check-expiration

# Renew expired or near-expiry control-plane certificates
kubeadm certs renew all

# For cert-manager application certificates: force re-issuance
# by deleting Certificate resources and letting cert-manager re-issue
kubectl get certificates -A -o json | \
  jq -r '.items[] | select(.status.notAfter < now | todate) |
         "\(.metadata.namespace)/\(.metadata.name)"' | \
  xargs -I{} kubectl delete certificate -n $(echo {} | cut -d/ -f1) \
                                           $(echo {} | cut -d/ -f2)

# Verify cert-manager issues new certificates
kubectl get certificaterequests -A --watch

Sessiesleutel herinrichting. Sessiesleutels — de efemere symmetrische sleutels onderhandeld tijdens TLS-handshakes en versleuteld-kanaaltotstandkomingen — worden nooit opgeslagen in de HSM en worden nooit geback-upt. Ze bestaan alleen in het geheugen van de communicerende processen. Na een herstel dat een systeem van back-up herstelt, zijn alle actieve sessies van de back-upmomentopname verdwenen; het herstelde systeem heeft geen sessiestatus. Verbonden systemen — andere clusterknooppunten, externe sensoren, C2-peers — zullen proberen sessies opnieuw tot stand te brengen met behulp van de langetermijncertificaten van het herstelde systeem (certificaten en HSM-ondersteunde sleutels). Als die certificaten actueel en geldig zijn, is sessieherinrichting automatisch en transparant. Als ze verouderd of verlopen zijn, mislukt sessieherinrichting en moet elke verbinding handmatig opnieuw worden geïnitialiseerd nadat het certificaatprobleem is opgelost.

Hersleutelingsprocedures na herstel. Voor systemen waarbij de herstelgebeurtenis zelf wordt behandeld als een potentiële sleutelcompromissindicator — met name als de storing werd veroorzaakt door een beveiligingsincident in plaats van een hardware- of stroomstoring — kan de ISSO een volledige hersleutelingscyclus vereisen voordat het systeem terugkeert naar geclassificeerde operaties. Hersleuteling omvat het genereren van nieuwe KEKs in de herstelde HSM, het opnieuw versleutelen van alle data-DEKs onder de nieuwe KEK en het distribueren van nieuwe certificaten naar alle verbonden systemen. Dit is een langdurig proces dat binnen de hersteltijdlijn moet worden begroot als er enige mogelijkheid bestaat dat het vereist zal zijn. Planningsdocumenten moeten expliciet ingaan op de beslissing hersleutelen versus hervatten op bestaande sleutels en de criteria voor elk pad definiëren.

Het snijpunt van back-upengineering, sleutelbeheer en Kubernetes-operaties dat geclassificeerde cloud-DR vereist, wordt niet bediend door een enkel hulpmiddel of framework. Het is opgebouwd uit een combinatie van platformniveau back-uphulpmiddelen (Velero, etcdctl, pg_basebackup), HSM-geïntegreerd sleutelbeheer en operationele procedures die zijn geoefend onder omstandigheden die echte rampen benaderen. Programma's die investeren in de oefencadans — en in de eerlijke After-Action-rapporten die volgen — presteren consistent beter dan programma's die DR behandelen als een documentatieoefening.