En detaljerad guide till att bygga din egen PKI

Beskrivning

Med den ständigt föränderliga och expanderande företagsinfrastrukturen har det blivit oerhört viktigt att varje organisation har sin egen robusta och mogna Public Key Infrastructure (PKI) som kan skapa förtroende mellan deras system, applikationer, användare och enheter på otillförlitliga nätverk. Införandet av privata moln, publika moln, DevOps, mikrotjänster och tillägget av IoT- och nätverksanslutna enheter presenterar ett brett spektrum av områden att skydda. En Public Key Infrastructure ger inte bara betrodda identiteter till användare och enheter, utan tillhandahåller också en säker kanal för att skydda kommunikation under överföring.

Idag är de flesta PKI-system i organisationer årtionden gamla och behöver moderniseras och uppgraderas för att passa det föränderliga IT-landskapet. Det största behovet för de flesta organisationer är att tillhandahålla en mycket säker och robust PKI-system som snabbt kan utfärda och hantera digitala certifikat genom självprovisionerade system. En intern PKI-system i organisationen bör också stödja både lokala och molnbaserade system för att uppfylla DevOps-krav. Men hur fungerar en PKI?

Snabbt svar: Hur bygger man sin egen PKI?

Att bygga din egen infrastruktur för publika nycklar innebär att upprätthålla en rot-CA (som hålls offline), en eller flera utfärdande certifikatutfärdare för att hantera den dagliga certifikatutfärdandet, och de stödjande komponenterna: HSM-skyddade privata nycklar, en certifikatpolicy och certifikatpraxis, och en fungerande CRL-/återkallningsprocess. De flesta organisationer väljer en tvåskiktsarkitektur för rätt balans mellan säkerhet och driftsenkelhet.

Senast uppdaterad: augusti 2026 · Senast verifierad: augusti 2026 · Rekommenderad uppdateringskadens: 6 månader, eftersom detta är en ständigt återkommande förklaring av PKI-arkitekturgrunderna.

Sammanfattning

• Två arkitekturer dominerar: En tvåskiktad PKI (rot-CA + utfärdande CA) täcker de flesta behov; en treskiktad PKI lägger till mellanliggande CA:er för organisationer som behöver ett extra lager av isolering mellan rot-CA:n och utfärdande.
• Root-CA:ns säkerhet är hela PKI:ns säkerhet: hålla den offline, skydda dess privata nyckel i en HSM, och en enda kompromiss där ogiltigförklarar alla certifikat som PKI någonsin har utfärdat.
• Hantering av certifikatlivscykeln är inte valfritt: Registrering, utfärdande, giltighetskontroll, återkallelse och förnyelse måste alla automatiseras, annars blir manuella luckor till avbrott och attackyta.
• Modern PKI måste stödja hybridmiljöer: Lokala och molnbaserade arbetsbelastningar, DevOps-pipelines och IoT-enheter behöver alla certifikat utfärdas och förnyas utan manuell inblandning.

Vem borde bry sig om att bygga sin egen PKI

Att etablera en PKI är ett tvärfunktionellt beslut. Här är vad varje roll bör äga.

PKI-administratörer

Driva den dagliga CA-verksamheten: certifikatutfärdande, förnyelse, återkallelse och CRL-publicering, och hålla certifikatinventeringen aktuell.

Säkerhetsarkitekter

Välj PKI-arkitektur (tvånivå vs. trenivå), bestäm vilken CA-leverantör som passar organisationens ekosystem och utforma HSM- och nyckelskyddsstrategin för rot- och utfärdande CA:er.

Plattformsteam

Automatisera certifikatprovisionering och avprovisionering för DevOps, CI/CD och molnarbetsbelastningar så att certifikatåtgärder sker med noll kontakt snarare än manuella ärenden.

Compliance-team

Äga certifikatpolicyn (CP) och certifikatpraxisutlåtandet (CPS) och bekräfta PKI:s operativa beviskarta mot organisationens efterlevnadsramverk.

CISO: er

Ta ansvar för beslutet om den kvarvarande risken gällande rot-CA-säkerhet, arkitekturnivå och huruvida man ska bygga internt eller använda PKI-as-a-Service, eftersom en komprometterad rot-CA innebär att PKI:n måste byggas om från grunden.

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. En PKI byggd utan automatiserad hantering av certifikatlivscykeln är precis den uppställning som producerar denna typ av avbrott: manuella förnyelse- och återkallningsprocesser missar så småningom ett certifikat.

CA/Browser Forums omröstning SC-081v3 (godkänd 11 april 2025) förkortar den maximala giltighetstiden för TLS-certifikat till 200 dagar från och med den 15 mars 2026, 100 dagar från och med den 15 mars 2027 och 47 dagar från och med den 15 mars 2029. En PKI utformad kring dagens längre giltighetsperioder och manuella förnyelse kommer att behöva betydligt frekventare certifikatoperationer enligt detta schema, vilket gör automatisering till ett designkrav snarare än en bra egenskap för alla PKI som byggs nu.

På algoritmsidan slutförde NIST sina tre första postkvantstandarder , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), den 13 augusti 2024. En PKI som byggs idag bör planera för eventuellt stöd för PQC-algoritmer i sin CA-programvara och HSM:er, eftersom en hierarki utformad med kryptoagilitet i åtanke kommer att migrera mycket lättare än en som inte gjorde det.

Ordlista: Viktiga PKI-termer

Termin	Definition
Rot-CA	Den viktigaste komponenten i en PKI; utfärdar certifikat till utfärdande (och, i en trenivåmodell, mellanliggande) certifikatutfärdare och etablerar förtroendet för hela hierarkin. Normalt sett hålls den offline.
Mellanliggande CA	En certifikatutfärdare placerad mellan rot-CA och utfärdande CA, används endast i en trenivåarkitektur för att lägga till ett extra isoleringslager.
Utfärdande CA	Den certifikatutfärdare som faktiskt utfärdar certifikat till slutanvändare, enheter och applikationer; används i både två- och trenivåarkitekturer.
Certifikatåterkallningslista (CRL)	En publicerad lista över återkallade certifikat och orsaken till varje återkallelse, kontrollerad av klienter för att bekräfta att certifikatet fortfarande är betrott.
Certifikatpolicy (CP)	Dokumentet som definierar vad en CA kan göra: vem den kan utfärda certifikat till och de gränser den verkar inom.
Certifikatpraxisutlåtande (CPS)	Dokumentet som definierar hur en CA implementerar de standarder som anges i dess certifikatpolicy.
HSM (Hårdvarusäkerhetsmodul)	En manipulationssäker hårdvaruenhet som används för att säkert generera och lagra privata nycklar för rot- och utfärdande CA:er.

Vad är en PKI och hur fungerar en PKI?

En PKI är en infrastruktur som tillhandahåller digitala certifikat till slutanvändare, system, enheter och applikationer för att ge dem betrodda identiteter. Dessa identiteter används för autentisering av certifikatinnehavaren, samt för att upprätta säker kommunikation med andra certifikatinnehavare inom nätverket. En PKI-infrastruktur är baserad på asymmetrisk nyckelkryptografi som använder en publik nyckel och ett privat nyckelpar associerat med ett digitalt certifikat utfärdat av en utfärdande certifikatutfärdare (CA) . Denna certifikatutfärdare upprättar förtroende mellan två certifikatinnehavare med hjälp av dessa digitala certifikat. Förutom att förse certifikatinnehavarna med sin identitet ger dessa certifikat också åtkomsträttigheter och gör det möjligt för certifikatinnehavaren att upprätta en säker kanal mellan två certifikatinnehavare för att kommunicera.

Komponenter i PKI

1. Rot-CARot-CA:n är den viktigaste komponenten i en PKI-infrastrukturRot-CA:n utfärdar certifikat och etablerar förtroendet mellan identiteter som den utfärdar ett digitalt certifikat till. Rot-CA:n utfärdar även certifikat till utfärdande certifikatutfärdare, vilket ger dem befogenhet att utfärda certifikat för rot-CA:n, eftersom den normalt sett hålls offline.
2. Mellanliggande CAEn mellanliggande CA, även känd som en underordnad CA, är en certifikatutfärdare som är placerad mellan den utfärdande CA:n, som utfärdar certifikat för rot-CA:ns räkning. Rot-CA:er kan ha många mellanliggande CA:er under sig i PKI-hierarkin, men varje mellanliggande CA kan bara ha en rot-CA. Den mellanliggande CA:n används normalt endast i en trenivås PKI-arkitektur.
3. Utfärdande CADen utfärdande certifikatutfärdaren utfärdar certifikat till slutanvändare, enheter och andra certifikatbegäranden. Utfärdande certifikatutfärdare fungerar som online-rot-certifikatutfärdare och utfärdar certifikat till användare som behöver dem. Utfärdande certifikatutfärdare används i både tvånivå- och trenivå-certifikatutfärdare.
4. Public KeyEn kryptografisk nyckel som skapas av en asymmetrisk nyckelalgoritm, såsom RSA, och som kan utfärdas till allmänheten tillsammans med ett digitalt certifikat. En offentlig nyckel behöver inte lagras säkert och används för offentlig distribution. Den offentliga nyckeln är ena hälften av det asymmetriska nyckelpar som skapas med en asymmetrisk nyckelalgoritm.
5. privat nyckelEn kryptografisk nyckel som är den andra halvan av ett asymmetriskt nyckelpar. Den privata nyckeln är den viktigaste komponenten i autentisering och bör förvaras säkert.
6. CertifikatbutikEtt certifikatarkiv används för att lagra rotcertifikat utfärdade från flera certifikatutfärdare. Certifikatarkiv innehåller även mellanliggande certifikatutfärdares rotcertifikat och slutanvändarcertifikat. Certifikatarkivet talar om för en dator vilka certifikatutfärdare som är betrodda certifikatutfärdare.
7. Certifikatåterkallningslista (CRL)En CRL är en lista som innehåller information om återkallade certifikat, inklusive deras certifikatinformation och orsaken till certifikatets återkallelse. CRL:er publiceras med vissa tidsintervall, vilket kan orsaka problem med certifikat som återkallas mellan CRL:ernas publiceringstillfällen.
8. Delta CRLDelta-CRL:er är CRL:er som publiceras under tidsintervallet mellan CRL:er som publiceras. Detta täcker risken för att ett certifikat som återkallats kan förbises innan nästa CRL publiceras.
9. HSM (Hårdvarusäkerhetsmodul): En HSM är en mycket viktig komponent i en säker PKI-installation och rekommenderas att användas för att lagra rot-CA:ns privata nyckel. HSM:er kan också användas för att lagra privata nycklar från mellanliggande certifikatutfärdare. HSM:er är extremt säkra, med manipulationssäkra och manipulationssäker säkerhetsmekanismer.
10. Certifikathantering: Certifikathantering är en viktig aspekt av en PKI-infrastruktur, eftersom den hjälper till att hålla certifikat uppdaterade och säkra. Följande är olika faser i certifikatlivscykeln som används för certifikathantering.
    1. CertifikatregistreringDenna fas avser den initiala skapandet av ett certifikat för certifikatbegäraren. En onlineanvändare, organisation eller enhet skickar ut en certifikatsigneringsbegäran, eller CSR, till certifikatutfärdaren. CSR:n innehåller den begärande partens publika nyckel och annan information om begärande part. CA verifierar sedan den angivna informationen och, om den är legitim, skapar certifikatet och registrerar användaren i PKI:n. Certifikatutfärdaren som används för att skapa certifikatet kan ägas av den organisation som önskar certifikatet, eller av en tredje part. Om certifikatet erhålls från en tredje part måste det köpas från dem.
    2. Utfärdande av certifikatNär certifikatet har skapats och användaren har registrerats i PKI:n utfärdas certifikatet till användaren. Som tidigare nämnts använder användaren nu detta certifikat för att identifiera sig inom nätverket. Detta säkerställer att varje medlem i PKI:n litar på certifikatinnehavaren.
    3. Certifikatets giltighetCertifikatgiltighet innebär att certifikatets giltighet kontrolleras vid interaktion med en annan medlem i nätverket. Certifikatet verifieras genom att följa certifikatets förtroendekedja. Denna förtroendekedja, eller certifieringsväg, visar certifikatet för den utfärdande certifikatutfärdaren som utfärdade certifikatet som verifieras. Certifieringsvägen för den utfärdande certifikatutfärdarens certifikat kontrolleras sedan hela vägen upp till rot-certifikatutfärdarens certifikat har nåtts. När förtroendekedjan har verifierats upp till rot-certifikatutfärdaren ses det certifikat som ursprungligen verifierades nu som giltigt.
    4. Återkallande av certifikatDetta steg sker endast om certifikatet löper ut och inte längre behövs, om certifikatet blir stulet och missbrukat, eller om certifikatet i allmänhet inte längre behövs. Om någon av dessa situationer inträffar återkallas certifikatet och kan inte längre användas. Det återkallade certifikatet läggs sedan till i CRL:n.
    5. CertifikatförnyelseNär ett certifikat löper ut måste det förnyas. Denna process utfärdar certifikatet på nytt med samma nyckelpar och information, men med ett nyligen uppdaterat utgångsdatum.
11. Certifikatpolicy (CP): Certifikatpolicyn är ett dokument som anger standarder för PKI. CP:n låter användare och PKI-ansvariga veta hur man ansöker om ett certifikat, namngivningsstandarderna för certifikat och mer. CPS:n följer standarderna som anges i CP:n.
12. Certifieringspraktikutlåtande (CPS): Certifikatpraxispolicyn anger de procedurer som används i PKI. Dessa procedurer är baserade kring certifikatpolicyns standarder. CP:n informerar en användare eller underhållare vad att göra, medan socialtjänsten säger åt dem hur att göra det.

Intygsinformation

Ett digitalt certifikat innehåller följande information för att styrka certifikatinnehavarens identitet:

• Information om certifikatutfärdaren: Informationen om utfärdaren inkluderar namnet på den utfärdande certifikatutfärdaren, vilket visas på fliken Allmänt under fältet "Utfärdad av" och på fliken Detaljer under fältet "Utfärdare". Fältet "Utfärdare" visar inte bara namnet på den utfärdande certifikatutfärdaren, utan även certifikatutfärdarens vanliga namn, organisationsnamn och land.

  

• Uppgifter om certifikatinnehavarenCertifikatinnehavarens uppgifter i certifikatet inkluderar innehavarens publika nyckel, dennes publika nyckel och certifikatinnehavarens namn.
  

• Certifieringssökväg : I ett digitalt certifikat ingår även certifikatets certifieringssökväg. Detta hjälper andra användare, applikationer eller enheter inom nätverket att verifiera certifikatets giltighet.

  

• Publik nyckel : Som nämnts lagras certifikatinnehavarens publika nyckel i certifikatet. Detta, tillsammans med deras egen privata nyckel, verifierar att nyckelinnehavaren matchar den publika nyckeln i certifikatet.

  

• Nyckelanvändning och utökad nyckelanvändning : Fältet ”Nyckelanvändning” anger vad nyckeln används till. Det finns också en möjlighet att certifikatet har ett fält för ”Utökad nyckelanvändning” som anger andra användningsområden för nyckeln, men som inte ingår i fältet ”Nyckelanvändning”.

  

• Utfärdarens digitala signatur: En annan viktig del av ett digitalt certifikat är utfärdarens digitala signatur. Detta hjälper till med verifiering av certifikatet, eftersom det låter läsaren veta vem som utfärdat certifikatet.

  

Vanliga användningsfall för digitala certifikat

Fältet ”Nyckelanvändning” kan erbjuda många olika användningsområden för det digitala certifikatet. Följande är några av de vanligaste användningsområdena för certifikat:

• SSL/TLS-certifikat för att säkra kommunikationskanaler – En av de huvudsakliga användningsområdena för certifikat är för SSL/TLS-kommunikation. Detta innebär att hålla kommunikationen säker mellan en klient och en server eller en klient och en annan klient.
• Digitala signaturer för dokument – ​​Certifikat kan också användas som digitala signaturer för dokument. Att signera ett dokument digitalt låter mottagaren av dokumentet veta att undertecknaren har skickat dokumentet och att det inte finns något skadligt i dokumentet.
• Kodsignering – Kodsignering med certifikat är mycket likt dokumentsignering. När kod skapas signerar koddesignern koden för att verifiera att de har skapat den och att ingen skadlig kod är dold inuti.
• Klient-server-autentisering – Klient-server-autentisering verifierar identiteten för både klienten och servern gentemot den andra parten i kommunikationen. Respektive kommunikatörer kontrollerar certifieringssökvägen för den andra partens certifikat och verifierar att deras certifikat är giltigt.
• VPN-autentisering – I likhet med klient-server-autentisering verifierar VPN-autentisering identiteten för varje medlem i anslutningen med hjälp av deras certifikats certifieringsväg.
• E-post och datakryptering – E-post och data kryptering använder avsändarens privata nyckel för att kryptera data. När e-postmeddelandet väl har mottagits, eftersom certifikatet är allmänt känt och innehåller avsändarens offentliga nyckel, kan meddelandet dekrypteras och mottagaren vet att avsändaren är den de utger sig för att vara.
• Wifi-autentisering – Wifi-autentisering verifierar även identiteten för varje medlem i anslutningen med hjälp av deras certifikats certifieringsväg.

PKI-tjänster för företag

Få komplett konsultstöd från början till slut för alla dina PKI-behov!

Läs mer

Viktiga element för att konfigurera din egen PKI

• Identifiera dina certifikatkrav – Du måste först identifiera alla nuvarande och framtida krav för digitala certifikat. Detta hänvisar till vad dina certifikat inom din PKI används och kommer att användas till. Se avsnittet Vanliga användningsområden för digitala certifikat ovan för mer information.
• Att välja rätt certifikatutfärdare – Baserat på dina krav måste du välja vilken typ av certifikatutfärdare du vill konfigurera. Om du vanligtvis använder din PKI för att stödja dina företagskrav, som mestadels är baserade på Microsoft-tjänster, skulle det vara ett bra alternativ för din organisation att konfigurera en Microsoft CA. Andra typer av CA:er är Googles och Amazons CA:er.
• Moln- kontra lokal hosting – Traditionellt sett konfigureras alla interna PKI:er lokalt. Allt oftare migrerar dock applikationer och tjänster till molnet, så det är viktigt att stödja molnkraven. I situationer där majoriteten av tjänster och produkter finns i molnet är det viktigt att se till att den CA du konfigurerar stöder molnbaserade krav.
• Certifikathantering – Att bara konfigurera en intern PKI-infrastruktur garanterar inte att din organisation kommer att kunna uppfylla och hantera alla PKI-relaterade krav. Ett av de viktigaste kraven för en PKI-infrastruktur är att automatisera certifikathanteringsåtgärder. Med DevOps, kontinuitet och CI/CD-pipeline är det också mycket viktigt att göra provisionering och avprovisionering av certifikat direkt och omedelbar. Detta säkerställer att alla nödvändiga certifikatåtgärder kan slutföras snabbt och att mänskliga fel inte påverkar dem.
• Säkra din rot och utfärda CA:s privata nycklar – De privata nycklarna för rot- och utfärdande CA:er måste lagras med största möjliga säkerhet eftersom de utgör roten för förtroendet. Därför är det viktigt att dessa privata nycklar lagras säkert på en HSM. Vanligtvis lagras rot- och utfärdande CA:ers privata nycklar på HSM:en, vilket ger maximal säkerhet och förhindrar manipulation eller missbruk av dessa nycklar.
• Skapa CP (Certificate Policy) och CPS (Certificate Policy Statement) – CP och CPS för PKI definierar policyerna för dina certifikatutfärdare och hjälper dig att utforma din PKI-infrastruktur. Dessa dokument fungerar också som ramverk och omfattning för din certifikatutfärdare och anger vem den kan utfärda certifikat till, vilka gränser inom vilka certifikatutfärdaren kommer att arbeta och vilka procedurer som används för att hantera din certifikatutfärdare.
• Återkallelse av certifikat och kontroll av CRL – Ett annat viktigt steg i att skapa din PKI är att säkerställa att certifikat återkallas vid behov, och att när de återkallas placeras de i CRL:n. Det är också viktigt att dina certifikatutfärdare regelbundet kontrollerar om det finns nya CRL:er, så att de kan vara uppdaterade om de senaste återkallade certifikaten.

Grundläggande arkitekturer

De två vanligaste PKI-arkitekturerna är tvånivå- och trenivåarkitekturen. Nedan följer de PKI-komponenter som utgör varje typ av PKI-arkitektur:

Tvånivåarkitektur

En tvåskiktsarkitektur är den vanligaste formen av PKI-hierarki, och även den mest balanserade arkitekturen. Den involverar endast en rot-CA och de utfärdande CA:erna i PKI:n. Detta format gör det enkelt att distribuera en tvåskikts-PKI utan att förlora PKI:ns säkerhet. Bilden nedan visar hur installationen av en tvåskikts-PKI ser ut.




Utformningen av en tvåskiktad PKI-arkitektur fungerar med säkerhet och enkelhet i åtanke, vilket gör att roten av förtroende, rot-CA:n, kan förbli offline och skydda den från attacker. Eftersom rot-CA:n inte kan komprometteras finns det ingen oro för att certifikat missbrukas eller ges till opålitliga användare. Istället för att rot-CA:n ger ut certifikat skapar den certifikaten för sina ursprungliga utfärdande CA:er och låter dem utfärda certifikat till slutanvändare. Tvåskiktade PKI-arkitekturer är den vanligaste typen av hierarki som används.

Trenivåarkitektur



Trenivåarkitekturen är den säkraste, eftersom det finns fler länkar i kedjan som skulle behöva komprometteras av angripare. Att sätta upp en trenivåarkitektur är dock en mycket mer komplicerad process än att sätta upp en tvånivåarkitektur. Med mellanliggande CA:er tillagda i mixen finns det många fler CA:er att ställa in och integrera inom PKI:n, särskilt om ett stort antal utfärdande och mellanliggande CA:er behöver skapas. Ju fler CA:er som behövs i en PKI, desto mer komplicerad är implementeringen och underhållet. En trenivåarkitektur används mycket mer sällan än en tvånivåarkitektur.

Vanliga driftsättningsmisstag

• Brist på planering och uppföljning: Ett av de vanligaste misstagen med en PKI är bristen på planering och spårning. Dålig planering i en PKI kan skada en PKI kritiskt, eftersom det kan finnas säkerhetsluckor som en angripare kan utnyttja. Dålig planering kan också leda till dålig certifikat- och nyckelhantering, vilket erbjuder ytterligare en möjlighet för angripare att utnyttja. Förutom planering kan dålig spårning av PKI-tillgångar också orsaka problem. För att åtgärda dessa problem, se till att korrekt planering utförs av PKI-experter för att säkerställa PKI av bästa kvalitet. Att använda SIEM-verktyg kan också hjälpa till att spåra de olika komponenterna i din PKI, vilket ger dig mer transparens i dess interna funktion.
• Root CA-säkerhet: Som roten för förtroende är rot-CA:n avgörande för PKI:n och måste därför vara väl skyddad. Om rot-CA:n skulle komprometteras skulle hela PKI:n behöva återskapas från grunden, eftersom inga certifikat som utfärdats inom den PKI:n längre skulle vara betrodda. För att åtgärda detta, använd en HSM för att skydda rot-CA:ns nycklar från externa attacker.
• Hantering av livscykeln för felaktigt certifikat: Ett annat vanligt misstag vid PKI-distribution är dålig hantering av certifikatlivscykeln. Om certifikat komprometteras eller lämnas oanvända kan illvilliga användare använda certifikaten för att stjäla eller komma åt känsliga data. Om ett användares eller ett programs certifikat skulle löpa ut utan förnyelse kan det också leda till serviceförlust för den användaren eller programmet. Korrekt automatisering och övervakning av certifikatlivscykeln kan förhindra att detta misstag inträffar.

Praktisk checklista innan du går live

• Identifiera nuvarande och framtida certifikatkrav innan du väljer en CA-leverantör eller arkitektur.
• Välj tvånivå- kontra trenivåarkitektur baserat på hur mycket isolering rot-CA:n behöver från utfärdande.
• Lagra rotnycklarna och den utfärdande CA:ns privata nycklar i en HSM, inte i enbart programvarubaserad nyckellagring.
• Utarbeta och godkänna en certifikatpolicy (CP) och en certifikatpraxis (CPS) innan produktionscertifikat utfärdas.
• Automatisera certifikatregistrering, utfärdande, förnyelse och återkallelse så att DevOps och molnarbetsbelastningar inte är beroende av manuella ärenden.
• Bekräfta att CRL- och återkallningskontrollen fungerar från början till slut, och att CA:er regelbundet kontrollerar efter nya CRL:er.
• Bestäm om du ska bygga internt eller använda PKI-as-a-Service baserat på tillgänglig PKI-expertis och personalstyrka.

Tabell över problem, påverkan och ägarskap

Utgåva	Business Impact	Rekommenderad åtgärd	Ägare
Rot-CA hålls online eller under svag åtkomstkontroll	En enda kompromiss ogiltigförklarar alla certifikat som PKI någonsin har utfärdat, vilket tvingar fram en fullständig ombyggnad.	Håll rot-CA offline och lagra dess privata nyckel i en HSM	Säkerhetsarkitekt
Ingen planering eller spårning av tillgångar före driftsättning	Oupptäckta säkerhetsluckor och dålig certifikat-/nyckelhantering som angripare kan utnyttja	Komplett arkitekturplanering med PKI-experter och spåra tillgångar med SIEM-verktyg	Säkerhetsarkitekt
Manuell hantering av certifikatlivscykeln	Missade förnyelser orsakar avbrott i tjänsten; oanvända eller komprometterade certifikat upptäcks inte	Automatisera registrering, utfärdande, förnyelse och återkallelse både lokalt och i molnet	Plattformsteamet
Ingen dokumenterad CP/CPS	Inget ramverk för vem som kan begära certifikat eller hur CA:n drivs, vilket komplicerar revisioner	Utarbeta och godkänna en certifikatpolicy och ett certifikatpraxisutlåtande	Efterlevnadsteam
Ingen kontroll av CRL/återkallelse	Komprometterade certifikat förblir betrodda längre än de borde, vilket utökar angriparens åtkomst	Implementera och testa regelbundet CRL-publicering och återkallningskontroll	PKI-administratör

PKI som en tjänst

En form av PKI som blir allt vanligare är PKI som en tjänst. Sättet PKI som en tjänst fungerar på är att en leverantör har PKI-installationen, antingen i sitt eget datacenter eller inom din organisation, och hanterar all hantering och uppdatering i PKI:n. Detta gör att organisationer som köper denna tjänst inte behöver utbilda eller anlita PKI-proffs, vilket sparar pengar och arbetskraft. Om PKI:n konfigureras i leverantörens datacenter kommer organisationen som köper deras tjänster troligtvis att låta PKI:n utfärda certifikat till sina användare, utan att ha en egen utfärdande certifikatutfärdare. PKI som en tjänst är en av de många tjänster som tillhandahålls av Encryption Consulting. Vi hjälper din organisation med design, implementering och driftsättning av din PKI. En del av vår PKI-installation inkluderar användning av en lokal Thales-SafeNet, nCipher eller Utimaco HSM. Vi kan implementera det i vårt datacenter i Dallas, Texas, eller på din webbplats. Oavsett vilken hårdvarusäkerhetsmodul du väljer att använda är de alla kompatibla med FIPS 140-2 nivå 2 och 3, så du bör uppfylla alla dina efterlevnadskrav. Tillsammans med en HSM hjälper vi dig också att bygga och designa en säkerhetskopia för din PKI, för minimal eller ingen förlust av tjänster från osynliga omständigheter. Vi kan också implementera olika SIEM-verktyg i din PKI, så att du kan övervaka certifikat och nycklar, för att hålla dig uppdaterad om återkallade certifikat, oanvända nycklar etc. Vår PKI as a Service kan också konfigureras antingen lokalt eller i molnet.

Certifikatlivscykelhantering och PKI-modernisering

Varje PKI, oavsett om den byggs internt eller levereras som en tjänst, lever eller dör beroende på hur väl den hanterar certifikatlivscykelhantering: registrering, utfärdande, giltighetskontroll, återkallelse och förnyelse, i stor skala, utan manuella åtgärder. CertSecure Manager automatiserar certifikatlivscykelhantering och certifikatautomatisering över lokala och molnbaserade certifikatutfärdare, vilket minskar gapet mellan "PKI är konfigurerad" och "PKI-åtgärder är inte beroende av att en människa kommer ihåg att förnya ett certifikat". Organisationer som överväger att bygga internt eller outsourca bör också utvärdera PKI-as-a-Service för PKI-modernisering med utfärdande, HSM-nyckelskydd och övervakning redan inbyggda.

Eftersom en ny PKI bör byggas med kryptoagilitet i åtanke från dag ett, kombinera arkitekturbesluten ovan med en bredare inventering: PQC Center of Excellence erbjuder praktisk postkvanttestning, och en PQC- beredskapsbedömning kan identifiera vilka algoritmer och certifikattyper som behöver uppmärksamhet när PQC-krav anländer. Kombinera båda med CBOM Secure för kontinuerlig certifikatidentifiering och maskinidentitetsinventering över hela hierarkin allt eftersom den växer.

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 ser ut som en rot-CA som har förblivit offline och komprometterad, noll certifikatrelaterade avbrott spårbara till en missad förnyelse, en dokumenterad och aktuell CP/CPS, och återkallningskontroll som är testad och fungerar på alla utfärdande CA.

Omgranska PKI-arkitekturen, HSM-nyckelskyddet, CP/CPS-dokumentationen och automatiseringen av certifikatlivscykeln med en 6-månadersperiod, eftersom detta är grundläggande vägledning för PKI-arkitekturen snarare än en policy knuten till en skiftande leverantörsdeadline.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från En detaljerad guide till att bygga din egen PKI?

Den viktigaste slutsatsen är att en PKI:s säkerhet nästan helt vilar på att rot-CA:n förblir offline och HSM-skyddad, medan dess dagliga användbarhet vilar på att automatisera hanteringen av certifikatlivscykeln. De flesta organisationer får den bästa balansen mellan båda med en tvånivåarkitektur.

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

Företags-PKI-team är de som ärver de arkitekturbeslut som fattas när en PKI först byggs, så en dåligt planerad rot-CA, saknad CP/CPS eller manuell certifikatlivscykel blir deras löpande operativa börda och riskexponering.

Vilka risker ökar om detta ämne hanteras manuellt?

Att hantera PKI-åtgärder manuellt ökar risken för missade certifikatförnyelser, vilket orsakar avbrott, oupptäckta komprometterade eller oanvända certifikat och en rot-CA eller utfärdande CA vars säkerhetsstatus förändras över tid utan att någon spårar den.

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

PKI-administratörer sköter den dagliga CA-verksamheten; säkerhetsarkitekter väljer arkitektur och HSM-strategi; plattformsteam automatiserar certifikatprovisionering för DevOps och molnet; efterlevnadsteam äger CP/CPS; och CISO:er äger besluten om bygg- kontra outsourcing och kvarvarande risk.

Hur kopplas detta till hantering av certifikatlivscykeln?

En PKI:s hela syfte är att hantera certifikatslivscykeln i stor skala: registrering, utfärdande, giltighetskontroll, återkallelse och förnyelse är den operativa kärnan i alla PKI, oavsett om de byggs internt eller levereras som PKI-as-a-Service.

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

Framgång ser ut som en rot-CA som har förblivit offline och komprometterad, noll certifikatrelaterade avbrott spårbara till en missad förnyelse, en dokumenterad och aktuell CP/CPS, och återkallningskontroll som är testad och fungerar på alla utfärdande CA.

Vad bör granskas eller övervakas regelbundet?

Organisationer bör kontinuerligt övervaka utfärdande och förnyelse av certifikat och granska rot-CA-säkerhet, HSM-nyckelskydd, CP/CPS-valuta och CRL-/återkallningskontroll med en 6-månadersintervall.

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

En modern PKI behöver stödja både lokala och molnbaserade system för att uppfylla DevOps-krav, och i en miljö med flera CA-leverantörer måste varje utfärdande CA:s automatisering av certifikatlivscykeln och återkallelsestatus verifieras individuellt snarare än att antas vara konsekvent över hela hierarkin.

Vilka vanliga misstag bör team undvika?

Vanliga misstag inkluderar bristande planering och spårning av resurser före driftsättning, otillräcklig säkerhet hos rot-CA (att inte använda en HSM eller hålla den online) och dålig hantering av certifikatlivscykeln som lämnar certifikat oövervakade tills de löper ut eller komprometteras.

Vad bör uppdateras kvartalsvis?

Eftersom detta är grundläggande arkitekturvägledning snarare än en policy knuten till en skiftande deadline, rekommenderas en 6-månaders kadens för omgranskning av PKI-arkitektur, HSM-nyckelskydd, CP/CPS-dokumentation och automatisering av certifikatlivscykeln.