PKI-rampherstel: planning, procedures en failoverpatronen

De meeste organisaties investeren aanzienlijke inspanningen in het opzetten van een PKI, het ontwerpen van de certificeringsinstantie (CA)-hiërarchie, het beveiligen van root-sleutels in een HSM, het inrichten van OCSP-responders en het configureren van certificaatsjablonen. Veel minder organisaties besteden dezelfde grondigheid aan het plannen van wat er gebeurt als die PKI uitvalt.

Een storing bij een certificeringsinstantie (CA) is geen hypothetisch uitzonderingsgeval. Hardware kan uitvallen, datacenters kunnen overstromen en ransomware slaat beveiligingsinfrastructuur niet over. Wanneer een CA offline gaat, volgen de gevolgen snel: er kunnen geen nieuwe certificaten meer worden uitgegeven, VPN-tunnels kunnen niet tot stand worden gebracht, webservers gebruiken onbetrouwbare certificaten en, cruciaal, certificaatintrekkingslijsten (CRL's) worden niet meer bijgewerkt. Zodra een CRL verloopt, zullen alle applicaties die intrekkingscontroles uitvoeren, geldige certificaten weigeren, waardoor systemen die niets met de CA zelf te maken hebben, plat komen te liggen.

Deze handleiding behandelt alles, van de reikwijdte van back-ups en noodprocedures tot failover-architecturen en testhandleidingen voor disaster recovery, met praktische richtlijnen voor zowel zelfbeheerde als beheerde PKI-omgevingen.

Waarom is PKI-rampherstel anders?

PKI-rampherstel heeft een eigenschap die de meeste andere rampenherstelscenario's niet hebben: de tijd begint al te lopen voordat je weet dat er iets mis is.

Wanneer een certificeringsinstantie (CA) uitvalt, kan deze geen CRL's meer ondertekenen of publiceren. Reeds gepubliceerde CRL's blijven echter geldig gedurende de geconfigureerde geldigheidsperiode, doorgaans 7 dagen voor een basis-CRL en 24 uur voor een delta-CRL. Dit betekent dat u vanaf het moment dat een CA offline gaat, een vast tijdsvenster hebt om de CA te herstellen of noodprocedures te gebruiken voordat applicaties beginnen te falen.

Overweeg twee scenario's:

Scenario A: Uw uitgevende certificeringsinstantie (CA) publiceert elke 7 dagen een basis-CRL en elke 24 uur een delta-CRL. De delta-CRL is 2 uur geleden verlopen toen de CA offline ging. U hebt nog ongeveer 22 uur voordat vertrouwende partijen de delta-CRL niet meer kunnen valideren en 5 dagen voordat de basis-CRL verloopt.

Scenario B: Uw certificeringsinstantie publiceert elke 7 dagen een basis-CRL en geen delta-CRL. De basis-CRL is 4 dagen geleden gepubliceerd. U hebt nog 3 dagen voordat de certificaatvalidatie in de hele organisatie mislukt.

De opzet van uw CRL-publicatieschema bepaalt direct uw budget voor noodherstel. Dit is niet zomaar een configuratiedetail, maar een beslissing die direct bij noodherstel wordt genomen.

De tweede unieke eigenschap van PKI DR is het beheer van de sleutels. Het herstellen van een CA zonder de originele privésleutel is onmogelijk. De back-up van die sleutel, en de procedure voor toegang daartoe, moet worden gepland en getest voordat u deze ooit nodig hebt.

Wat gaat er mis als een CA uitvalt?

Voordat je een herstelstrategie ontwerpt, is het handig om precies te begrijpen wat er kapot gaat en in welke volgorde:

Onmiddellijk (minuten):

• De uitgifte van nieuwe certificaten stopt.
• OCSP-responders die afhankelijk zijn van de live database van de CA, geven geen gezaghebbende antwoorden meer.
• Alle inschrijfdiensten (NDES, online inschrijving, SCEP) zijn niet meer beschikbaar.

Binnen enkele uren tot dagen (afhankelijk van de geldigheidsperiode van de CRL):

• Delta CRL's verlopen: applicaties die intrekkingscontroles uitvoeren met behulp van delta CRL's beginnen te falen.
• De basis-CRL's verlopen: alle applicaties van de vertrouwende partij die controleren op intrekking, beginnen certificaten te weigeren.

Langetermijn:

• Het CA-certificaat zelf kan verlopen als het herstel gedurende een langere periode wordt uitgesteld.
• De vertrouwensketens voor kruisgecertificeerde of ondergeschikte certificeringsinstanties worden verstoord.

Door deze tijdlijn te begrijpen, kunt u een OCSP-storing zonder bijbehorende CA-storing prioriteren. Dit is urgent, maar niet catastrofaal. Een CA-storing met een verlopen delta-CRL is daarentegen een incident dat onmiddellijk alle beschikbare middelen vereist.

Omvang van de back-up: Wat moet er beschermd worden?

Een CA-back-up is alleen bruikbaar als deze alles bevat wat nodig is om de CA naar een andere server te herstellen. De volgende componenten moeten allemaal aanwezig zijn:

Root- en uitgevende CA-privésleutels

De privésleutel is het meest cruciale en gevaarlijkste onderdeel van uw PKI. Deze moet in rusttoestand worden beschermd met behulp van een HSM of, minimaal, een met een wachtwoord beveiligd PKCS#12-archief dat is opgeslagen op een fysiek beveiligde locatie met toegangscontrole. Verlies van de privésleutel betekent dat de CA nooit meer kan worden hersteld. Er moet een volledig nieuwe CA-hiërarchie worden opgebouwd.

Organisaties die een HSM gebruiken, dienen de procedures voor het maken van back-ups en het herstellen van sleutels van hun leverancier te volgen (Luna, nShield en Utimaco hebben elk specifieke workflows voor het maken van back-ups van HSM-sleutels). Een back-up van de HSM-sleutel moet op een aparte fysieke locatie worden bewaard, gescheiden van de primaire HSM.

Certificaat Database

De CA-database bevat een overzicht van elk certificaat dat ooit is uitgegeven of ingetrokken. Zonder deze database gaat de volledige uitgiftegeschiedenis verloren en is het niet mogelijk om intrekkingsinformatie te reconstrueren. Voor op ADCS gebaseerde CA's is dit de Jet/ESE-database, te vinden op:

%SystemRoot%\System32\CertLog

Registerconfiguratie

De configuratie van de CA — inclusief CRL-instellingen, certificaatextensies, geldigheidsperioden en publicatiepunten — wordt opgeslagen in het Windows-register onder:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuratie

Exporteer dit als een .reg-bestand bij elke back-up.

CAPolicy.inf

Dit bestand definieert het certificaatbeleid van de CA tijdens de installatie. Hoewel het niet nodig is om een ​​werkende CA te herstellen, is het essentiële documentatie voor het opnieuw opbouwen van een CA als de privésleutel is gecompromitteerd.

Certificaatsjablonen

In een Active Directory-omgeving worden certificaatsjablonen opgeslagen in de AD-configuratiepartitie, niet op de CA-server zelf. Aangepaste sjabloondefinities moeten echter per attribuut worden gedocumenteerd, zodat ze opnieuw kunnen worden aangemaakt als Active Directory zelf opnieuw moet worden opgebouwd.

CRL-bestanden

Maak een back-up van de huidige basis-CRL- en delta-CRL-bestanden. In geval van nood kunnen deze bestanden opnieuw worden gepubliceerd naar een nieuw distributiepunt of worden gebruikt als basis voor een CRL-herondertekeningsprocedure.

Het CA Backup Script van Encryption Consulting automatiseert dit hele proces in één geplande PowerShell-uitvoering, inclusief het inkorten van logbestanden en het vastleggen van gebeurtenissen.

Noodprocedure: Herondertekening CRL

Het opnieuw ondertekenen van een CRL is de allerbelangrijkste noodprocedure die elke PKI-beheerder moet kennen en tevens de procedure die het vaakst ontbreekt in noodherstelplannen.

Wanneer een certificeringsinstantie (CA) uitvalt en een certificaatherroepingslijst (CRL) bijna verloopt, hoeft u niet per se de volledige CA te herstellen om een ​​intrekkingsprobleem te voorkomen. Als u een back-up hebt van de privésleutel van de CA, kunt u die sleutel gebruiken om een ​​bestaande CRL opnieuw te ondertekenen en de geldigheidsperiode te verlengen. Dit geeft u extra tijd (uren of dagen) om de volledige CA te herstellen zonder de certificaatvalidatie binnen de gehele organisatie te beïnvloeden.

Wanneer te gebruiken: Wanneer een certificeringsinstantie (CA) offline is en een CRL zich binnen het overlappende venster bevindt of al is verlopen.

Wat u nodig hebt:

• Een back-up van het publieke/private sleutelpaar van de CA (PKCS#12 of HSM-ondersteund sleutelmateriaal)
• Het meest recente CRL-bestand van uw distributiepunt of back-up.

Stappen op hoog niveau:

1. Importeer het CA-sleutelpaar naar een beveiligd, tijdelijk werkstation.
2. Gebruik certutil -sign (ADCS) of een equivalent daarvan in uw PKI-platform om de CRL opnieuw te ondertekenen met een verlengde geldigheidsperiode.
3. Publiceer de opnieuw ondertekende CRL naar alle geconfigureerde distributiepunten (HTTP, LDAP).
4. Controleer OCSP en CRL-controleapplicaties om te bevestigen dat ze de vernieuwde CRL accepteren.
5. Ga parallel verder met het volledig herstellen van de CA-waarden.

Het opnieuw ondertekenen van een CRL is geen vervanging voor CA-herstel, maar een overbrugging die een intrekkingsprobleem voorkomt terwijl het herstelproces gaande is.

RTO en RPO per PKI-component

Niet alle PKI-componenten hebben dezelfde herstelvereisten. Het definiëren van een RTO (Recovery Time Objective) en een RPO (Recovery Point Objective) per component helpt bij het prioriteren van inspanningen en investeringen.

Bestanddeel	Typisch RTO-doel	Typisch RPO-doel	Notes
OCSP-responder	<15 minuten	Bijna nul	Direct grote impact; overweeg actieve-actieve OCSP.
Uitgevende CA	<1 uur	Laatste back-up (dagelijks of vaker)	Het CRL-venster bepaalt de kritikaliteit.
Root-CA	<4 uur	Laatste back-up	Offline Root CA voegt ceremonietijd toe
CA-database	Laatste back-up	Laatste back-up	Dagelijkse of continue replicatie
Certificaatsjablonen	Lage urgentie	Gedocumenteerde configuratie	Opgeslagen in AD; herstelbaar indien AD gezond is.

Voor organisaties met een formele SLA of wettelijke verplichting moeten deze doelstellingen worden vastgelegd in een PKI-specifiek bedrijfscontinuïteitsplan en jaarlijks worden herzien.

Failover-architecturen

Actieve-passieve DR CA's

Het meest voorkomende patroon voor PKI binnen een onderneming is een actieve-passieve implementatie: een primaire certificeringsinstantie (CA) verzorgt alle certificaatuitgifte tijdens normale bedrijfsvoering, terwijl een of meer nood-CA's (DR-CA's) in een standby-status verkeren, vooraf geconfigureerd en getest zijn, maar geen certificaten uitgeven.

Belangrijkste ontwerpprincipes voor deze architectuur:

• DR-CA's moeten vooraf geïnstalleerd en geconfigureerd zijn met dezelfde certificaatsjablonen, CRL-distributiepunten en AIA-extensies als de primaire CA. De kosten voor het opzetten van een DR-CA tijdens een incident, onder druk, zijn onevenredig hoog.
• Configuratiesynchronisatie moet expliciet zijn. Wanneer sjablonen of beleidsregels op de primaire server wijzigen, moeten die wijzigingen worden gerepliceerd naar de DR CA's. Een veelvoorkomend probleem is dat een DR CA een configuratie heeft die zes maanden geleden afweek van de productieconfiguratie.
• Test de failover regelmatig. Geef minstens elk kwartaal een testcertificaat af van de DR CA om te bevestigen dat deze operationeel is. Een DR CA die nooit is getest, is geen DR CA, maar een risico.

Actieve-actieve uitgevende certificeringsinstanties

Voor organisaties met een hoog volume aan certificaatuitgiften of strikte beschikbaarheids-SLA's is een actief-actief model de voorkeurswijze. In dit model delen twee of meer uitgevende certificeringsinstanties (CA's) de belasting via DNS round-robin of een load balancer, en kan elk van hen onafhankelijk certificaten uitgeven.

Deze aanpak vereist een zorgvuldige databasestrategie: elke CA beheert zijn eigen certificaatdatabase, wat betekent dat de uitgiftegeschiedenis over verschillende CA's is verdeeld. Bij de publicatie van CRL's moet hiermee rekening worden gehouden door elke CA zijn eigen CRL te laten publiceren, en OCSP-responders moeten zo worden geconfigureerd dat ze beide CRL's kunnen opvragen.

Overwegingen met betrekking tot offline root-CA's

In de meeste PKI-ontwerpen voor bedrijven wordt de root-CA offline gehouden, uitgeschakeld en fysiek beveiligd wanneer deze niet in gebruik is. Dit verkleint het aanvalsoppervlak aanzienlijk, maar brengt wel extra aandachtspunten met zich mee voor noodhersteloperaties.

Een goed ontworpen offline Root CA DR-procedure omvat:

• Integriteit tussen twee personen (M-van-N sleuteltoegang): Gebruik Shamir's Secret Sharing of HSM-afgedwongen quorumcontroles (bijv. "M van de N beheerders moeten aanwezig zijn") zodat geen enkele persoon toegang heeft tot de privésleutel van de Root CA.
• Documentatie van de fysieke sleutelceremonie: Telkens wanneer de Root CA wordt ingeschakeld, moeten de uitgevoerde stappen worden vastgelegd, bekrachtigd en gearchiveerd voor controledoeleinden.
• Getest herstelproces: Doorloop minstens één keer per jaar de volledige herstelprocedure voor de Root CA op geïsoleerde hardware om te bevestigen dat de offline media, belangrijke back-ups en documentatie voldoende zijn om de CA opnieuw op te bouwen.

DR-testen: draaiboek en planning

Een DR-plan dat nog nooit is getest, is een hypothese. Het volgende schema biedt een praktische basis voor PKI DR-testen.

Monthly

• Controleer of de geautomatiseerde CA-backups succesvol zijn voltooid en of de back-upbestanden toegankelijk zijn.
• Controleer of de CRL- en delta-CRL-publicaties actueel zijn op alle distributiepunten.
• Controleer of de OCSP-responders gezond zijn en binnen de SLA reageren.
• Controleer de CA-gebeurtenislogboeken op fouten of waarschuwingen.

Elk kwartaal een

• Voer een volledige CA-herstelbewerking uit in een geïsoleerde testomgeving met behulp van de meest recente back-up.
• Geef een testcertificaat af van elke DR/standby CA
• Controleer of de configuratie tussen de primaire en de DR CA's gesynchroniseerd is.
• Controleer of de CRL-herondertekeningsprocedure succesvol kan worden uitgevoerd (met behulp van een niet-productiesleutel).

Jaarlijks

• Voer een volledige failover-simulatie uit: schakel de primaire uitgevende CA offline en bevestig dat de DR CA de taken overneemt zonder handmatige tussenkomst.
• Doorloop de offline Root CA-herstelceremonie.
• Controleer en actualiseer het DR-draaiboek voor eventuele infrastructuurwijzigingen.
• Evalueer de RTO/RPO-doelstellingen aan de hand van de bedrijfsvereisten en pas deze indien nodig aan.

DR-overwegingen tijdens CA-migratie

Bij de migratie van de CA ontstaat een tijdelijke periode waarin de DR-status minder goed is. De oude CA kan buiten gebruik worden gesteld voordat de DR-omgeving van de nieuwe CA volledig operationeel is. Specifieke oplossingen:

• Neem de oude CA niet buiten gebruik voordat de DR CA van de nieuwe CA operationeel is. De oude CA moet als back-up blijven bestaan ​​totdat de stabiliteit van de nieuwe CA-hiërarchie is bewezen.
• Zorg voor continuïteit van de CRL tijdens de migratie. Als de CDP/AIA-punten wijzigen, moeten de oude CRL-distributiepunten toegankelijk blijven gedurende de gehele levensduur van alle certificaten die door de oude CA zijn uitgegeven.
• Maak een back-up van de oude CA voordat u met de migratie begint. Een back-up die direct voor aanvang van de migratie is gemaakt, is het belangrijkste herstelmiddel dat u hebt.
• Definieer vooraf de terugdraaicriteria. Spreek vóór de migratie, en niet tijdens de migratie, specifieke voorwaarden af ​​waaronder een terugdraaiing naar de oude CA plaatsvindt.

Het juiste DR-model kiezen

Zelfbeheerde PKI

Als u PKI intern beheert, bieden de richtlijnen in dit artikel u de bouwstenen voor een DR-programma. De minimale vereiste is:

• Een gepland en getest CA-backupproces dat alle bovengenoemde componenten omvat.
• Ten minste één vooraf geconfigureerde DR-uitgevende CA
• Een gedocumenteerde procedure voor het opnieuw ondertekenen van een CRL, inclusief de benodigde documenten.
• Een driemaandelijkse testcyclus

Beheerde PKI (PKIaaS)

Voor organisaties die gegarandeerde noodherstel (DR) willen zonder de bijbehorende operationele kosten, verschuift een beheerde PKI-service de verantwoordelijkheid voor DR naar de provider. De PKI-as-a-Service van Encryption Consulting omvat proactieve monitoring, actieve incidentrespons en een toegewijd team dat beschikbaar is voor DR-scenario's – zoals blijkt uit ons succesverhaal over PKIaaS , waarin alle wereldwijde storingen binnen een uur werden opgelost.

Certificaat Levenscyclusbeheer

Of uw PKI nu zelf wordt beheerd of uitbesteed, realtime inzicht in uw certificaatinventaris is van onschatbare waarde voor noodherstel. CertSecure Manager biedt een gecentraliseerd en altijd actueel overzicht van elk certificaat in uw omgeving, zodat u bij aanvang van het herstelproces precies weet welke certificaten zijn uitgegeven, welke verlopen en welke services risico lopen, zonder dat u dit hoeft te reconstrueren vanuit een oude back-up.

Hoe kan encryptieconsulting u helpen?

Het PKI-team van Encryption Consulting ontwerpt en implementeert DR-ready PKI-architecturen die aansluiten op de RTO/RPO-vereisten en complianceverplichtingen van uw organisatie. Of u nu DR integreert in een bestaande PKI, een migratie plant of de operationele complexiteit volledig wilt uitbesteden met PKIaaS, ons team beschikt over praktische expertise op het gebied van ADCS, cloud-PKI en multi-vendoromgevingen.

• PKI-dienstenEnd-to-end PKI-ontwerp, implementatie en DR-planning.
• PKI-as-a-ServiceVolledig beheerde PKI met ingebouwde disaster recovery en 24/7 monitoring.
• CertSecure ManagerCertificaatlevenscyclusbeheer met realtime inventarisatie en waarschuwingen voor verlopen certificaten.
• CA-back-upscript: Gratis PowerShell-hulpprogramma voor het automatiseren van uitgebreide CA-backups
• HSM-as-a-Service: Zeer betrouwbare sleutelbescherming met een DR-ready HSM-implementatie

Neem contact met ons op om uw PKI DR-vereisten te bespreken, of vraag een demo aan om CertSecure Manager in actie te zien.

Conclusie

PKI- rampherstel is geen eenmalige configuratietaak, maar een doorlopende operationele discipline. De belangrijkste principes:

• Ontwerp CRL-validiteitsperioden met het oog op noodherstel (DR). De periode tussen uw laatst gepubliceerde CRL en de vervaldatum ervan is uw hersteltijd.
• Bescherm de privésleutel boven alles. Alle andere onderdelen kunnen worden gereconstrueerd; de sleutel niet.
• Zorg dat u de CRL-herondertekeningsprocedure kent voordat u deze nodig hebt. Het is de meest waardevolle noodtechniek bij PKI DR en tegelijkertijd de minst toegepaste.
• Test uw DR. Een DR CA die nog nooit een testcertificaat heeft afgegeven, is een ongetoetste aanname.
• Plan noodherstel (DR) in elke migratie. Een migratie is een periode met verhoogd risico; de noodherstelstrategie moet gedurende de hele periode gehandhaafd blijven.