Identifiera och minska risker vid PKI-bedömning

Din PKI -design och certifikatpolicy påverkar säkerheten för ditt nätverk och dina enheter som helhet. Du bör utforma och implementera din PKI för att avvärja typiska faror, ungefär som du skulle garantera att ditt hem har en jordbävningssäker grund eller ett orkansäkert tak.

Många av dessa val måste göras i förväg , under designen och utvecklingen av din programvara eller produkt. Även om det kräver arbete att implementera de nödvändiga säkerhetsåtgärderna i din PKI, kommer nödvändiga försiktighetsåtgärder att hjälpa dig att minska säkerhetsproblem i framtiden.

Tänk på detta. Vilken säkerhetsrisk skulle ett komprometterat certifikat i ditt nätverk utgöra? Kan en server nås med hjälp av certifikatets autentisering? Kan det användas mot dina användare i en man-in-the-middle-attack?

När man skapar ett program eller en enhet som använder certifikat för autentisering eller säker kommunikation bör dessa frågor noggrant övervägas. Tekniska val måste göras gällande hur er produkt ska hantera certifikat och hur er PKI ska utformas och hanteras.

Den här artikeln är avsedd för designers och producenter som arbetar med privata klient- eller enhetscertifikat, till exempel de som finns i programvara eller enheter för sakernas internet (IoT) .

Snabbt svar: Vilka är riskerna med PKI-bedömning?

PKI-bedömningsrisker är design- och driftsluckor i certifikatens giltighetstid, skydd av privata nycklar och återkallelse som gör att en angripare missbrukar ett komprometterat certifikat. Att bedöma dem innebär att kontrollera hur länge certifikat förblir giltiga, om privata nycklar finns i ett TPM-, HSM- eller krypterat arkiv istället för klartext, och om CRL- eller OCSP-återkallelse faktiskt fungerar från början till slut.

Senast uppdaterad: augusti 2026 · Senast verifierad: augusti 2026 · Rekommenderad uppdateringskadens: kvartalsvis, eftersom riktlinjer för certifikatgiltighet, tidslinjer för algoritmutfasning och krav för CA/Browser Forum ändras enligt ett liknande schema.

Sammanfattning: Viktiga slutsatser

• Tre risker, ett system: Certifikatgiltighet, skydd av privata nycklar och återkallelse fungerar bara tillsammans; att försvaga det ena undergräver de andra två.
• Långa giltighetstider ökar insatserna: Certifikat med längre livslängd skapar fler måltavlor för angripare och kräver ett mer kapabelt återkallelsesystem.
• Klartextnycklar är det vanligaste felet: en privat nyckel lagrad utan hårdvara eller krypterat skydd kan extraheras och användas för att imitera en enhet eller dekryptera trafik.
• Återkallelse kräver inte konstant anslutning: Cachade CRL:er och OCSP-häftning stöder båda enheter med begränsad eller intermittent internetåtkomst.
• Algoritmutfasning är ett schemaläggningsproblem: SHA-1 och korta RSA-nycklar var en gång säkra; SHAttered-kollisionen (23 februari 2017) bevisade att teoretiska svagheter så småningom blev praktiska.

Vem borde bry sig om riskerna med PKI-bedömningar

Dessa risker dyker upp i designbeslut långt innan en incident sker. Här är vad varje roll bör äga.

PKI-administratörer

Ansvara för den dagliga konfigurationen av certifikatgiltighet, nyckellagring och återkallelse, och håll certifikatinventeringen tillräckligt aktuell för att kunna köra en riskbedömning på begäran.

Säkerhetsarkitekter

Utforma riskkontrollerna i PKI:n före lansering: giltighetsperioder, hårdvara för nyckellagring och återkallningsmekanism, snarare än att eftermontera dem efter att en produkt levererats.

Plattformsteam

Implementera nyckellagring och återkallningskontroll i den faktiska produkten eller enheten, inklusive CRL-cachning eller OCSP-häftning för intermittent ansluten hårdvara.

Compliance-team

Mappa giltighet, nyckelskydd och återkallningskontroller till relevant ramverk (ISO/IEC 27001, PCI DSS, WebTrust/ETSI) och bekräfta att revisionsbevis finns för var och en.

CISO: er

Ta ansvar för beslutet om kvarvarande risk: hur länge certifikat är giltiga, hur väl nycklar skyddas och hur snabbt ett komprometterat certifikat faktiskt kan återkallas i hela flottan.

Varför detta är viktigt: Data och deadlines

Enligt DigiCerts Trust Pulse-undersökning (publicerad 2 juli 2025) upplevde nästan hälften av företagen ett certifikatrelaterat avbrott under det senaste året, och 18.5 % av de drabbade organisationerna rapporterade förluster på över 250 000 dollar. Obedömd PKI-risk, en alltför lång giltighetsperiod, en oskyddad nyckel eller ett återkallelsesystem som aldrig testades är precis det som förvandlar ett enskilt komprometterat certifikat till ett avbrott av den storleken.

CA/Browser Forums omröstning SC-081v3 (godkänd 11 april 2025) låser in krympande giltighet för TLS-certifikat: 200 dagar från och med 15 mars 2026, 100 dagar från och med 15 mars 2027 och 47 dagar från och med 15 mars 2029. Varje riskbedömning av giltighetstiden måste ta hänsyn till detta schema nu, eftersom en certifikatpolicy skriven kring en maximal giltighetstid på 398 dagar redan kommer att vara oöverensstämmande år 2026.

På algoritmsidan slutförde NIST sina tre första post-kvantstandarder , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), den 13 augusti 2024. SHA-1-utfasningen som den här artikeln använder som exempel är inte en engångshändelse: det är samma kryptoagilitetsproblem som organisationer kommer att möta igen när PQC-kompatibla certifikat blir obligatoriska.

PKI-riskmatris

Använd den här matrisen för att poängsätta och dokumentera de tre riskområden som den här artikeln behandlar, plus två relaterade risker som framkommer i samma bedömning.

Risk	Sannolikhet	Inverkan	Detekteringsmetod	Mitigation	Kontrollmappning	Bevis
Certifikatets giltighetstid är för lång	Medium	Hög	Granskning av certifikatinventering; giltighets-/utgångsrapport	Förkorta giltighetsperioderna; anpassa till CA/Browser Forum-schemat; automatisera förnyelse	NIST SP 800-57 vägledning för nyckelanvändning; CA/Browser Forums grundläggande krav	Export av certifikatinventering som visar giltighetsperioder och utfärdandedatum
Privat nyckel lagrad i klartext eller oskyddad	Hög	Kritisk	Granskning av nyckellagring; inspektion av enhet/firmware; penetrationstest	Flytta nycklar till ett TPM-, HSM- eller krypterat nyckellager; skicka aldrig nycklar i klartext-firmware	ISO/IEC 27001 A.8.24 (hantering av kryptografiska nycklar); NIST SP 800-57	Granskning av konfigurationen för nyckellagring; HSM/TPM-attesteringsloggar
Ingen fungerande återkallelsesekanism	Hög	Kritisk	Återkallningskontrolltest mot ett känt återkallat certifikat; CRL/OCSP-slutpunktstest	Implementera CRL och/eller OCSP, med OCSP-häftning där anslutningen tillåter; testa återkallelse från början till slut	RFC 5280 (CRL); RFC 6960 (OCSP); ISO/IEC 27001 A.8.24	Loggar för återkallningstest; register över drifttid för CRL/OCSP-slutpunkter
Föråldrad algoritm används fortfarande (t.ex. SHA-1, RSA-1024)	Medium	Kritisk	Kryptografisk algoritminventering; CBOM-skanning	Migrera till nuvarande algoritmer (SHA-256+, RSA-2048+/ECC); följa en kryptoagilitetsfärdplan mot PQC	NIST SP 800-131A algoritmövergångar; FIPS 186-5	CBOM/kryptoinventeringsrapport; granskning av algoritmanvändning
CRL/OCSP-slutpunkten är oåtkomlig eller inaktuell	Medium	Hög	Slutpunktsövervakning; CRL NextUpdate-kontroll	Övervaka drifttiden för slutpunkter; cache-CRL:er på lämpligt sätt för intermittent anslutna enheter; varna om inaktuella CRL:er	RFC 5280; intern certifikatpolicy/CPS	Kontrollpanel för drifttid; CRL-uppdateringsrapport
Ingen dokumenterad certifikatpolicy eller CP/CPS	Medium	Medium	Granskning av policydokument; bedömning av brister	Utarbeta och underhålla en certifikatpolicy/certifieringspraxis som omfattar giltighet, nyckelskydd och återkallelse.	WebTrust/ETSI EN 319 411 CP/CPS-krav; ISO/IEC 27001 A.5.31	Godkänt CP/CPS-dokument; versionshistorik

Överensstämmelsekartläggning

Riskområde	Relevant ramverk/kontroll	Vad revisorer letar efter
Certifikatets giltighetstid och livscykel	NIST SP 800-57, CA/Browser Forum Baseline Requirements, ISO/IEC 27001 A.8.24	Dokumenterade giltighetsperioder, bevis på automatisering av förnyelse
Privat nyckelskydd	FIPS 140-3, ISO/IEC 27001 A.8.24, PCI DSS-krav 3	HSM/TPM-valideringscertifikat, diagram för nyckellagringsarkitektur
Återkallande	RFC 5280, RFC 6960, ISO/IEC 27001 A.8.24	Resultat av återkallningstest, CRL/OCSP-tillgänglighets-SLA:er
Kryptoagilitet och algoritmvaluta	NIST SP 800-131A, NIST PQC-standarder (FIPS 203/204/205)	Algoritminventering (CBOM), migreringsfärdplan
Styrning och certifikatpolicy	WebTrust, ETSI EN 319 411	Godkända policydokument, granska kadensregister

Skapa en PKI med långvarig säkerhet

Vi pratar ofta med utvecklare som inte känner till sina alternativ för att skapa PKI- och certifikatpolicyer. Du har stor flexibilitet med privat betrodd PKI när det gäller dina klient- och enhetscertifikat, vilket gör att du kan öka säkerheten för ditt program eller din enhet.

Vi kommer att gå in på detaljer om tre avgörande faktorer som du bör ta hänsyn till för att förbättra din PKI. Att välja giltighetstider och ersättning av certifikat, skydda privata nycklar och använda återkallelse av certifikat – samt hur man använder dessa kontroller effektivt för att minska risken – är de tre första ämnena.

Även om certifikat erbjuder autentisering och kryptering är det inte så enkelt att bara installera och sluta använda dem. Båda dessa egenskaper kan äventyras, men med rätt åtgärder kan de också stärkas.

Den enklaste lösningen skulle kunna vara att ställa in en slarvig PKI och aldrig oroa dig för att hantera dina certifikat, men detta medför säkerhetsrisker som du kanske inte har tänkt på.

Låt oss använda den senaste nedläggningen av SHA-1 som en illustration. Forskare var medvetna om svagheten hos SHA-1-hashmetoden, som var utformad för att ge kryptografiska signaturer för att unikt identifiera certifikat. Förra året visade Google två olika filer med samma hash i en verklig kollision.

SHA-1-algoritmen utrotades effektivt av denna kollision, och många certifikat ersattes med den säkrare SHA-2-algoritmen för att upprätthålla säkerheten. Långlivade certifikat inkluderades också, vilka skulle bli mer exponerade med tiden (ökad datorkraft gör det lättare att utnyttja dem). Även om en SHA-1-kollision skulle verka omöjlig just nu, hur är det om 5 år? 20 år? Dessa är avgörande faktorer att ta hänsyn till om dina produkter kommer att användas under en längre tid.

Komplexiteten i PKI-säkerhet demonstreras snabbt av detta enkla exempel. Du skulle behöva en teknik för att återutfärda och ersätta certifikat på dina enheter, en återkallningsmekanism för att hantera certifikat som du vet har komprometterats, och en försäkran om att ditt nätverk och dina användare inte längre är exponerade för att minska säkerhetsriskerna med en felaktig hashalgoritm.

Giltighetstid för ett certifikat

Inom SSL/TLS- området är komprometterade tekniker ett oundvikligt problem. Protokollets grundläggande kryptografiska tekniker är byggda med ett utfasningsdatum i åtanke eftersom vi förutser att starkare datorer i framtiden så småningom kan äventyra deras säkerhet.

Stora förändringar har skett under de senaste tio åren, såsom att hashalgoritmerna MD5 och SHA-1 har övergetts och att man har övergått till 2048-bitarsnycklar. Vi kommer så småningom att få slut på 2048-bitarsnycklar och behöva ersätta dem. Det kommer att bli mycket lättare att hantera dessa förändringar om man har en plan på plats.

Du måste väga fördelarna med ett långvarigt certifikat mot svårigheten att skydda långvariga nycklar när du bestämmer giltighetstiden för dina certifieringar. Att skydda dessa nycklar blir svårare med tiden i takt med att krypteringsstandarder försämras, ersätts och din samling av certifikat utökas. En bristfällig algoritm kan så småningom kräva att certifikat snabbt byts ut för att bibehålla säkerheten, som i fallet med vårt SHA-1-exempel.

Det är viktigt att tänka på både utgångsdatumet och processen för att ersätta dina certifieringar. För det mesta har vi upptäckt att det innebär för många säkerhetsavvägningar att försöka använda ett enda certifikat under hela enhetens livstid.

Genom att välja längre giltighetsperioder skapar du en större variation av certifikat (och tillhörande privata nycklar) som behöver hållas säkra. Eftersom det ger dem åtkomst under längre tidsperioder utökar detta antalet mål för angripare och motiverar dem att kompromettera ett certifikat. Detta gör i sin tur att det är viktigare att ha ett återkallelsesystem och kräver att man håller återkallelsedata till hands under längre tidsperioder, vilket resulterar i större återkallelsesfiler och större nätverksaktivitet.

Att skapa en säker PKI kräver dock inte att certifikat ändras varje år. Långlivade certifikat kan fortfarande användas samtidigt som effektiva planer för dessa ändringar görs. När du ersätter och förnyar enhetscertifikat kan du välja den giltighetstid som fungerar bäst för dig utan att behöva oroa dig för att du kommer att behöva ersätta dem i framtiden.

Håller privata nycklar säkert

Nyckelkompromettering delar många av samma säkerhetsfaktorer som certifikatgiltighet. Angripare kan imitera en enhet, dekryptera och läsa data och autentisera sig mot ett nätverk om de kan få tag på en privat nyckel.

Nycklar måste skyddas mot kompromettering, återkallas och ersättas om de någonsin komprometteras om du vill erbjuda verklig autentisering och kryptering. Det betyder att det inte är en bra idé att lägga nycklar på en enhet i klartext, där de lätt kan extraheras. Tänk istället på ett hårdvaruförsvar som ett säkert chip (TPM) eller en mjukvarulösning som ett krypterat nyckellager, vilket erbjuder verkligt försvar mot angripare.

Även om du tror att dina nycklar är tillräckligt skyddade är det avgörande att ha ett fungerande återkallelsesystem. Angripare kan bli intresserade av att hitta ett sätt att kringgå dina säkerhetsåtgärder om de upptäcker att det inte finns något praktiskt sätt att stoppa dem när de stjäl en nyckel. En ytterligare försvarslinje som kallas återkallelse tjänar till att neutralisera och avskräcka inkräktare.

Dessa hinder har mycket gemensamt. Ett pålitligt återkallelsesystem – ett som kan hantera en hög andel återkallelser – blir viktigare och dyrare om dina nycklar är enkla att kompromettera.

Återkallande

Eftersom återkallelse av certifikat är en "högkostnadstjänst" som kräver en aktiv internetanslutning och hög tillgänglighet, tror flera tillverkare och utvecklare att de inte kan stödja den. Så är inte fallet. Du kan kontrollera återkallningsinformation med hjälp av branschstandardteknik utan att ansluta till en server eller använda internet alls.

CRL (Certificate Revocation Lists) och OCSP är två tekniker som används flitigt inom branschen för att verifiera återkallningsinformation (Online Certificate Status Protocol). En CRL är jämförbar med en svart lista med serienummer för certifikat för personer som inte är bekanta med dessa system. Med OCSP skickar klienten en begäran över internet till en central tjänst för att få reda på statusen för ett visst certifikats återkallelse – ungefär som att anropa ett API. Certifikatprotokollet X.509 inkluderar både CRL- och OCSP-protokollen.

Det enklare alternativet, CRL, ger dig flexibilitet i situationer där din enhet kanske inte har en pålitlig eller snabb internetanslutning. Traditionellt signerar den utfärdande CA:n en CRL-fil varje dag, som klienten kan komma åt online. CRL:n kan dock cachas och lagras i situationer där enheten inte snabbt eller rutinmässigt kan ansluta till internet.

CRL:er är signerade och har en giltighetsperiod, precis som certifikat. CRL:er är tillförlitliga eftersom de är signerade av CA:n. En CRL behöver inte skickas direkt från CA:n till enheten. Istället kan de distribueras via ett nätverk, till exempel ett internt nätverk eller en centraliserad molnserver. Detta har en fördel jämfört med en enkel svartlista eller vitlista. Om en CRL-fil har en giltig signatur kan du ladda ner den från vilken plats som helst utan att oroa dig för manipulation.

När en CRL löper ut, vilket kan vara inställt på veckor eller mer, kan den cacha på en enhet och användas fram till dess. På grund av detta är det ett lämpligt val för enheter med ojämna eller oregelbundna internetanslutningar. Detta gör att du kan behålla fördelarna med återkallningskontroll i många situationer utan att ådra dig de tekniska kostnaderna för att upprepade gånger hämta ny data.

Så länge enheterna har tillgång till en gateway eller server som har det, kan OCSP även användas när enheterna själva inte har internetanslutning. Återkallningsinformationen kan överföras under TLS-handskakningen tack vare en valfri OCSP-funktion som kallas "häftning", vilket förbättrar nätverksprestanda. Både OCSP och CRL:er kan implementeras, där den senaste CRL:n fungerar som säkerhetskopia.

Att en kommersiell CA redan stöder en av dessa standardmetoder är en fördel med att använda den. De är flexibla standarder som kan anpassas för att möta dina unika behov eftersom de stöder ett brett spektrum av möjligheter.

Exempel på incidenter

Två verkliga händelser visar vad som händer när dessa risker inte hanteras.

• SHAttered SHA-1 kollision (23 februari 2017): Google och forskningsinstitutet CWI Amsterdam producerade två separata PDF-filer som delade en identisk SHA-1-hash, vilket förvandlade en teoretisk svaghet till ett demonstrerat, praktiskt avbrott. Branschen accelererade sin övergång till SHA-256, och alla organisationer som fortfarande använder SHA-1-signerade certifikat idag bär en risk som redan har bevisats vara utnyttjad.
• DigiNotar CA-kompromiss (2011): Angripare bröt sig in i den holländska certifikatutfärdaren DigiNotar och utfärdade hundratals bedrägliga certifikat, inklusive för större domäner. Eftersom DigiNotars detekterings- och återkallningsrespons var för långsam, återkallade webbläsare slutligen allt förtroende för själva certifikatutfärdaren, ett resultat som visar vad som händer när nyckelskydd och återkallningsinfrastruktur misslyckas samtidigt.

Tabell för revisionsbevis

Riskområde	Bevis som en revisor bör begära	Där den vanligtvis lever
Certifikatets giltighetstid	Certifikatförteckning med utfärdande- och utgångsdatum	Plattform för hantering av certifikatlivscykel eller export av CA
Privat nyckelskydd	HSM/TPM-attestering, dokumentation av nyckellagringsarkitektur	Säkerhetsarkitekturförråd, leverantörsintyg
Återkallande	Loggar för återkallningstest, drifttidsposter för CRL/OCSP-slutpunkter	Övervakningsplattform, incidenthanteringsregister
Algoritmvaluta	Kryptografisk algoritminventering (CBOM)	CBOM Secure eller motsvarande kryptoinventeringsverktyg
Styrning av certifikatpolicy	Godkänt CP/CPS-dokument med versionshistorik	Arkiv för efterlevnadsdokument

Checklista för åtgärdande

• Inventera varje certifikat och dess giltighetstid; flagga allt som utfärdats längre än vad nuvarande CA/Browser Forum-riktlinjer stöder.
• Bekräfta att privata nycklar lagras i ett TPM-, HSM- eller krypterat nyckelarkiv, aldrig i klartext-firmware eller konfigurationsfiler.
• Teståterkallelse från början till slut: återkalla ett testcertifikat och bekräfta att beroende klienter avvisar det via CRL eller OCSP.
• Kör en kryptografisk algoritminventering (CBOM) och flagga alla certifikat som fortfarande använder SHA-1-, MD5- eller RSA-nycklar under 2048 bitar.
• Dokumentera en certifikatpolicy/CPS som täcker giltighetsperioder, nyckelskydd och återkallelse, och granska den minst en gång per år.
• Ställ in övervakning och aviseringar om CRL/OCSP-slutpunktens drifttid och CRL-aktualitet.

Certifikatlivscykelhantering och PKI-modernisering

Giltighet, nyckelskydd och återkallelse är i grunden frågor om hantering av certifikats livscykel: giltighetsperioder styr förnyelsetakten, nyckelskydd styr hur säkert varje certifikats privata nyckel överlever från utfärdande till utgångsdatum, och återkallelse styr hur livscykeln avslutas i förtid när något går fel. CertSecure Manager automatiserar hanteringen av certifikats livscykel, inklusive certifikatautomation för förnyelse och återkallelsekontroll, så dessa tre risker är inte beroende av ett manuellt kalkylblad. Organisationer som utformar PKI för nya produkter eller IoT-flottor bör också utvärdera PKI-as-a-Service för PKI-modernisering med dessa kontroller inbyggda från början.

Eftersom algoritmdeprecering (den här artikelns SHA-1-exempel) är ett återkommande problem, bygg en bredare kryptoagilitetsplan utöver denna riskbedömning: PQC Center of Excellence erbjuder praktisk postkvanttestning, och en PQC- beredskapsbedömning kan identifiera vilka certifikat och nycklar som behöver bytas ut härnäst. Koppla båda med CBOM Secure för kontinuerlig certifikatidentifiering och maskinidentitetsinventering, så att nästa algoritmövergång börjar från dokumenterade data istället för en ny manuell granskning.

För mer information om den omgivande livscykeln, se Vilka är stegen i en certifikatlivscykel? och Hur man undviker certifikatavbrott.

Mätning av framgång och pågående revisioner

Framgång innebär att varje certifikats giltighetstid matchar aktuell algoritm och CA/Browser Forum-riktlinjer, inga privata nycklar lagras utan hårdvara eller krypterat skydd, ett återkallningstest som godkänns från början till slut och en dokumenterad certifikatpolicy som granskas minst en gång per år.

Uppdatera certifikat- och algoritminventeringen, konfigurationen för övervakning av återkallningsslutpunkter och själva riskmatrisen kvartalsvis, eftersom regler för giltighetstider, tidslinjer för föråldrade algoritmer och krav för CA/Browser Forum alla ändras enligt ett liknande schema.

Slutsats

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från att identifiera och minska PKI-bedömningsrisker?

Den viktigaste slutsatsen är att PKI-risken kommer från tre sammankopplade beslut: certifikatgiltighetsperioder, skydd av privata nycklar och återkallelse, och att försvaga någon av dem undergräver de andra två. Ett snabbt återkallelsesystem betyder lite om nycklarna finns i klartext, och väl skyddade nycklar lämnar dig fortfarande exponerad utan ett fungerande sätt att återkalla ett komprometterat certifikat.

Varför är detta viktigt för PKI-team på stora företag?

Företags-PKI-team ärver ofta beslut om certifikat- och nyckelhantering som fattas tidigt i en produkts eller ett systems design, så det är mycket dyrare att identifiera dessa risker efter driftsättning än att designa kring dem i förväg. Ett enda svagt beslut, som en oskyddad privat nyckel eller en giltighetsperiod som överlever algoritmen som stöder den, kan äventyra alla enheter eller tjänster som bygger på den PKI:n.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell spårning av certifikatgiltighet, nyckellagring och återkallningsstatus ökar risken för att certifikat med för lång livslängd går obemärkt förbi, privata nycklar skickas i klartext utan att någon upptäcker dem under granskningen, och att återkallelseglapp gör att komprometterade certifikat är betrodda mycket längre än de borde vara.

Vilka lag borde ta över den här förändringen?

PKI-administratörer äger den dagliga giltigheten, nyckellagringen och konfigurationen av återkallelse; säkerhetsarkitekter utformar riskkontrollerna i PKI:n direkt; plattformsteam implementerar kontroll av nyckellagring och återkallelse i produkten eller enheten; efterlevnadsteam mappar dessa kontroller till relevant ramverk; och CISO:er äger beslutet om kvarvarande risk.

Hur kopplas detta till hantering av certifikatlivscykeln?

Dessa tre riskområden, giltighet, nyckelskydd och återkallelse, är frågor om hantering av certifikatlivscykeln: giltighetsperioder styr förnyelsetakten, nyckelskydd styr hur säkert varje certifikats privata nyckel överlever från utfärdande till utgångsdatum, och återkallelse styr hur livscykeln avslutas i förtid när ett certifikat komprometteras.

Hur bör organisationer mäta framgång?

Framgång innebär att varje certifikats giltighetstid matchar aktuell algoritmisk vägledning, inga privata nycklar lagras utan hårdvara eller krypterat skydd, ett återkallningstest som godkänns från början till slut och en dokumenterad certifikatpolicy som granskas minst en gång per år.

Vad bör granskas eller övervakas regelbundet?

Organisationer bör granska certifikatens giltighetstid och algoritmernas aktualitet kvartalsvis, testa återkallelsekontroller från början till slut med ett återkommande schema, kontinuerligt övervaka drifttiden för CRL/OCSP-slutpunkter och granska certifikatpolicyn/CPS minst en gång per år.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

Moln- och hybrid-PKI-distributioner lägger till tredjepartsinfrastruktur för nyckelhantering och återkallelse som behöver samma riskgranskning som en lokal CA, och miljöer med flera CA kräver att varje utfärdande CA:s giltighet, nyckelskydd och återkallningsstatus bedöms individuellt, eftersom en svag CA i hierarkin kan undergräva förtroendet för resten.

Vilka vanliga misstag bör team undvika?

Vanliga misstag inkluderar att välja den längsta tillgängliga giltighetsperioden för certifikat utan en förnyelseplan, lagra privata nycklar i klartext på en enhet eftersom det är enklare att implementera, anta att återkallelse inte behövs eftersom enheter är offline för det mesta, och att aldrig dokumentera den resulterande certifikatpolicyn så att besluten går förlorade när teamet byts ut.

Vad bör uppdateras kvartalsvis?

Certifikat- och algoritminventeringen, konfigurationen för övervakning av återkallningsslutpunkter och själva riskmatrisen bör uppdateras kvartalsvis, eftersom certifikatgiltighetsperioder, tidslinjer för föråldrade algoritmer och krav för CA/Browser Forum alla ändras i liknande takt.