Skillnaden mellan olika Public Key Infrastructure (PKI)

Beskrivning

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA och Google Cloud Certificate Authority Service löser alla samma underliggande problem, att utfärda och hantera betrodda digitala certifikat, men de löser det på väldigt olika sätt. Att välja fel certifikat, eller att köra alla utan en dokumenterad beslutsprocess, är orsaken till att organisationer får duplicerade CA-hierarkier, inkonsekvent nyckelskydd och certifikatavbrott som ingen förutspådde. Det här inlägget går igenom vad en PKI är gjord av, hur var och en av dessa fyra plattformar implementerar den, en fullständig sida-vid-sida-jämförelse över elva kategorier, och en praktisk beslutsmatris och checklista för att välja (eller granska) rätt lösning för ett givet användningsfall.

Snabbt svar: Vad är skillnaden mellan dessa PKI-plattformar?

Leverantörer av Public Key Infrastructure (PKI) skiljer sig huvudsakligen åt i var CA-nycklar finns och vem som hanterar hierarkin: Microsoft PKI (ADCS) körs lokalt med en offline-rot-CA, AWS Certificate Manager automatiserar offentliga TLS-certifikat och AWS ACM Private CA och Google Cloud CAS kör privata CA-hierarkier direkt i molnet med HSM-baserade nycklar och inbyggd granskningsloggning.

Key Takeaways

• Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA och Google Cloud CAS löser olika problem: lokal CA-kontroll, automatiserad publik TLS, molnbaserade privata CA-hierarkier respektive GCP-integrerade CA-pooler.
• Alla fyra plattformar konvergerar kring samma kärnsäkerhetspraxis: offline- eller skyddade rot-CA:er, HSM-baserade privata nycklar, SHA-256- eller bättre hashing och granskningsloggning.
• AWS har flyttat ACM Private CA:s HSM-skydd till FIPS 140-3 nivå 3. NIST avslutar FIPS 140-2-valideringar till historisk status den 21 september 2026, så alla Microsoft PKI- eller lokala distributioner som fortfarande hänvisar till 140-2 behöver en uppdateringsplan.
• Krympande giltighetstid för offentliga TLS-certifikat, ner till 47 dagar år 2029 enligt CA/Browser Forum Ballot SC-081v3, gör automationsvänliga plattformar som ACM och molnbaserade CAS allt viktigare även för organisationer som började med Microsoft PKI.
• Rätt val är sällan en enda plattform. De flesta företag använder en hybridmix och behöver en dokumenterad beslutsmatris, inte ett ad hoc-val, för att undvika dubblerade CA-hierarkier och inkonsekvent nyckelskydd.

Varför detta är viktigt nu

DigiCerts Trust Pulse Survey, publicerad den 2 juli 2025, visade att nästan hälften av företagen upplevde ett certifikatrelaterat avbrott under det senaste året, där 37.5 % av incidenterna var specifikt kopplade till utgångna certifikat och 18.5 % av de drabbade organisationerna rapporterade förluster som översteg 250 000 dollar. Att köra Microsoft PKI-, AWS- och Google Cloud CA-hierarkier sida vid sida utan en konsekvent övervaknings- och förnyelseprocess är precis den typ av inkonsekvens som producerar dessa avbrott.

Marginalen för manuella fel krymper också snabbt. Enligt CA/Browser Forum Ballot SC-081v3 , godkänd den 11 april 2025, sjunker giltighetstiden för offentligt betrodda TLS-certifikat från 398 dagar till 200 dagar från och med den 15 mars 2026, sedan till 100 dagar från och med den 15 mars 2027 och till 47 dagar från och med den 15 mars 2029. Ett plattformsval som är beroende av manuell utfärdande, vanligt i äldre Microsoft PKI-distributioner, kommer inte att hålla jämna steg med det schemat på samma sätt som AWS Certificate Manager eller Google Cloud CAS-automation kan.

På längre sikt slutförde NIST sina post-kvantkryptografistandarder, FIPS 203, 204 och 205, den 13 augusti 2024. Varje plattform som jämförs i det här inlägget signerar fortfarande certifikat med RSA eller ECDSA, så oavsett vilken leverantör en organisation standardiserar sig på idag, hör en kryptoagilitetsplan för den slutliga PQC-övergången hemma på färdplanen oavsett vilken CA-hierarki som är på plats.

Vad är offentlig nyckelinfrastruktur (PKI)?

PKI, förkortningen för Public Key Infrastructure , är en uppsättning roller, procedurer och policyer som behövs för att skapa, distribuera, hantera, använda och återkalla digitala certifikat och hantera kryptering med publika nycklar. PKI bekräftar en användares identitet genom att verifiera äganderätten till en privat nyckel och fungerar som en betrodd tjänst som verifierar att en avsändare eller mottagare av data är exakt den de utger sig för att vara.

Vilka är kärnkomponenterna i en PKI?

PKI är uppbyggt kring komponenter och procedurer för att hantera nyckelpar (publika och privata nyckelpar). En typisk PKI består av följande komponenter:

1. Certifikatutfärdare (CA): En betrodd CA är den enda enheten inom PKI som kan utfärda betrodda digitala certifikat. CA:n accepterar certifikatförfrågningar och verifierar informationen som lämnas av sökande baserat på certifikathantering policyn, signerar sedan certifikat med sin privata nyckel och utfärdar dem om informationen är giltig.
2. Registreringsmyndighet (RA): En RA ansvarar för att ta emot certifikatsigneringsförfrågningar för den första registreringen eller förnyelsen av certifikat från användare, servrar och andra applikationer. RA verifierar identiteten på en slutenhet och vidarebefordrar begäran till en certifikatutfärdare (CA).
3. Offentlig nyckel: En offentlig nyckel kan distribueras brett och kräver inte säker lagring. Dess motsvarande privata nyckel kan dekryptera meddelanden eller data som krypterats med den offentliga nyckeln.
4. Privat nyckel: Privata nycklar används av mottagaren för att dekryptera meddelandet eller data som krypterats med motsvarande publika nyckel. Detta fastställer äganderätten till det privata och publika nyckelparet, vilket säkerställer att meddelandet endast läses av godkända parter.
5. Rotcertifikatutfärdare (Root CA): Ett certifikat anses giltigt när en betrodd rot-CA signerar det. En rot-CA har rätt att verifiera en persons identitet och signerar rotcertifikatet som distribueras till en användare.
6. Mellanliggande certifikatutfärdare: En mellanliggande certifikatutfärdare är också en betrodd certifikatutfärdare och används som en kedja mellan rot-certifikatutfärdaren och klientcertifikatet som användaren registrerar sig för. Eftersom rot-certifikatutfärdaren har signerat och litar på den mellanliggande certifikatutfärdaren är certifikat som genereras från den mellanliggande certifikatutfärdaren också betrodda.
7. Hårdvarusäkerhetsmodul (HSM): A Hårdvarusäkerhetsmodul är inte en obligatorisk del av en PKI, men den förbättrar säkerheten när den implementeras. Den här enheten skyddar och hanterar digitala nycklar och fungerar som grunden för att bygga en säker företags-PKI infrastruktur, hantera hela livscykeln för kryptografiska nycklar, inklusive skapande, rotation, radering, granskning och support för API: er att integrera med olika applikationer.

Hur implementerar stora PKI-leverantörer dessa komponenter?

Nu när de viktigaste PKI-komponenterna är tydliga, här är hur fyra vanligt förekommande plattformar implementerar dem, tillsammans med de bästa praxis som rekommenderas för var och en.

Microsoft PKI

Nedan följer några rekommenderade metoder för att använda Microsoft PKI (Active Directory Certificate Services) effektivt.

• Gör en detaljerad plan för din PKI-infrastruktur före driftsättning.
• Undvik att installera ADCS på en domänkontrollant.
• Rot-CA:n bör vara fristående och offline.
• Utfärda inte certifikat till slutenheter från en rot-CA.
• Aktivera granskningshändelser för både rot- och utfärdande certifikatutfärdare.
• Säkra den privata nyckeln med en HSM (FIPS 140-3 Nivå 3; FIPS 140-2-valideringar flyttas till historisk status den 21 september 2026).
• Installera endast Enterprise CA om din CA utfärdar certifikat för enheter eller användare.
• Det rekommenderas inte att använda standardcertifikatmallar.
• CRL-distributionspunkten bör ha hög tillgänglighet.
• Publicera rot-CA:s CRL till Active Directory.
• Hashalgoritmen bör vara minst SHA-2 (SHA-256 eller högre).
• Giltighetsperioden för slutgiltighetscertifikatet bör vara högst två år.

AWS certifikathanterare

Här är de bästa metoderna för AWS Certificate Manager (ACM):

• Kontroll av ACM-certifikatets utgångsdatum: säkerställ att utgångna certifikat tas bort SSL/TLS-certifikat hanteras av ACM. Detta eliminerar risken att distribuera ett ogiltigt certifikat på resurser som möter front-end, vilket också kan skada företagets trovärdighet.
• ACM-certifikatgiltighetskontroll: säkerställ att förfrågningar som inkommer under utfärdandet eller förnyelseprocessen av SSL/TLS-certifikat valideras regelbundet.
• Användning av rotcertifikatutfärdare (CA): det är alltid en god idé att minimera användningen av rotcertifikatutfärdaren. AWS rekommenderar att man skapar ett separat konto för rotcertifikatutfärdaren.
• Transportlagerskydd är avgörande för säkerheten. Använd endast TLS version 1.2 eller senare; SSL är inte längre säkert.
• När du importerar certifikat istället för att använda ACM-utfärdade certifikat, se till att nycklarna som används för att generera privata SSL/TLS-nycklar har hög nyckelstyrka för att undvika dataintrång.
• Undvik jokerteckensdomäncertifikat. Utfärda istället ett ACM-certifikat för en enda domän för varje domän och underdomän med en egen privat nyckel.
• Tillåt endast importerade certifikat från autentiserade och betrodda partners i din organisation. Jokerteckencertifikat som importeras till ACM innebär en säkerhetsrisk eftersom en användare kan ha en okrypterad kopia av certifikatets privata nyckel.
• Använd alltid ett fullständigt kvalificerat domännamn (FQDN) i SSL/TLS ACM-certifikat.
• För att undvika missbruk av genererade certifikat, utför regelbundna granskningar av AWS-miljön för betrodda certifikat och validera granskningsrapporter.
• Aktivera AWS CloudTrail- och CloudWatch-larm: CloudTrail-loggning spårar historiken för AWS API-anrop och övervakar AWS-distributioner, och kan integreras med applikationer för automatiserad loggning. CloudWatch-larm meddelar dig när konfigurerade mätvärden överskrider tröskelvärden.

AWS ACM Privat CA (ACM PCA)

Nedan följer rekommenderade bästa praxis som kan hjälpa dig att använda AWS ACM Private CA mer effektivt.

• AWS rekommenderar att du dokumenterar alla dina policyer och rutiner för att driva din CA, inklusive CA-hierarki, arkitekturdiagram och CA-valideringsperiodpolicyer. Detta kan samlas in i en certifikatpolicy (CP) och en certifikatpraxis (CPS); se RFC 3647 för ett ramverk för att samla in denna information.
• Rot-CA:n bör i allmänhet endast användas för att utfärda certifikat för mellanliggande CA:er.
• Att skapa en rot-CA och en underordnad CA i två olika AWS-konton är en rekommenderad bästa praxis.
• CA-administratörsrollen bör vara separat från användare som bara behöver åtkomst för att utfärda slutenhetscertifikat.
• Aktivera CloudTrail-loggning innan du skapar och börjar driva en privat CA, så att du kan hämta en historik över AWS API-anrop för att övervaka dina distributioner.
• Uppdatera den privata nyckeln för din privata certifikatutfärdare regelbundet, antingen genom att importera ett nytt certifikatutfärdarcertifikat eller genom att ersätta den privata certifikatutfärdaren med en ny.
• Ta bort alla oanvända privata certifikatutfärdare permanent.
• Använd Amazon S3 Block Public Access (BPA)-funktionen på buckets som innehåller CRL:er för att undvika att i onödan exponera detaljer om din privata PKI. BPA är en god S3-praxis och är aktiverad som standard på nya buckets.

Google Cloud-certifikatutfärdartjänst

Det här avsnittet beskriver några av de bästa metoderna som hjälper dig att använda Google Clouds certifikatutfärdartjänst (CAS) mer effektivt.

• Roll- och åtkomstkontroll: individer bör inte tilldelas mer än en roll åt gången, och alla som innehar en roll bör vara tillräckligt informerade om sina ansvarsområden. För att tilldela en mångsidig uppsättning behörigheter, skapa en anpassad roll med hjälp av IAM.
• I de flesta fall använder du Enterprise-nivån för att skapa en CA-pool som utfärdar certifikat till andra CA:er och slutenheter.
• När du skapar en CA-pool, överväg noga DevOps-nivån, eftersom den inte stöder återkallelse av certifikat.
• Säkra CA-signeringsnycklar genom att utnyttja Cloud HSM.
• Aktivera molngranskningsloggar för att övervaka åtkomst till och användning av Cloud HSM-signeringsnycklar.
• Undvik att importera en befintlig extern certifikatutfärdare med redan utfärdade certifikat till certifikatutfärdartjänsten.
• För en rot-CA och en underordnad CA, använd den största nyckelstorleken som är tillgänglig för den algoritmfamiljen: för RSA är den största nyckelstorleken som stöds 4096 bitar; för ECDSA är den största nyckelstorleken som stöds 384 bitar. Underordnade CA:er med kortare livslängd kan använda mindre nyckelstorlekar, till exempel 2048 bitar för RSA eller 256 bitar för ECDSAObservera att Ed25519-signeringsnycklar inte stöds för CA-tjänster, och ingen post-kvantumsigneringsalgoritm stöds för CA-nycklar i skrivande stund.
• Ge endast rollen CA-tjänstanvändare till organisationsmedlemmar som behöver använda en given certifikatmall.

Leverantörsjämförelse i korthet

Tabellen nedan jämför alla fyra plattformar inom elva kategorier som är viktigast när man väljer eller granskar en PKI-leverantör.

#	Kategori	Microsoft PKI	AWS-certifikathanterare (ACM)	AWS ACM Privat CA (ACM PCA)	Google Cloud-certifikatutfärdartjänst (CAS)
1	Rot-CA	Rot-CA distribueras lokalt och förvaras offline.	AWS Certificate Manager är en tjänst för att tillhandahålla, hantera och distribuera publika/privata SSL/TLS-certifikat för AWS-tjänster och anslutna resurser.	Rot-CA kan distribueras i AWS-molnet, eller så kan den utfärdande CA-CSR:n signeras av en extern rot-CA.	Rot-CA kan distribueras i Google Cloud CAS, eller så kan den utfärdande CA-CSR:n signeras av en extern rot-CA.
2	Certifikatmall	Standardmallar för certifikat rekommenderas inte; mallar kan konfigureras.	Använd AWS CloudFormation-mallar för att utfärda privata certifikat med ACM.	ACM Private CA stöder fyra varianter av certifikatmall: Base-, CSRPassthrough-, APIPassthrough- och APICSRPassthrough-mallar.	En ny certifikatmall kan skapas i varje projekt och plats i Google Cloud CAS.
3	Nyckelalgoritm och nyckelstorlek	Stöder nyckelstorlekar enligt NIST SP 800-57. Minsta nyckelstorlek är 2048 bitar; för CA:er med certifikatutgångsdatum mer än 15 år tidigare måste RSA vara 4096 bitar eller högre, eller så måste ECC-nycklar använda P-384- eller P-521-kurvan.	Stöder 2048-bitars RSA, 3072-bitars RSA, 4096-bitars RSA och ECDSA P-256 och P-384.	Stöder RSA 2048, RSA 4096, ECDSA P-256 och ECDSA P-384 för certifikat som utfärdats direkt av ACM Private CA.	Stöder 2048-bitars RSA, 3072-bitars RSA, 4096-bitars RSA, ECDSA P-256 och ECDSA P-384. För långlivade rot- eller underordnade CA:er rekommenderar Google den största nyckelstorleken som är tillgänglig för den valda algoritmfamiljen. Ed25519 och post-quantum CA-signeringsnycklar stöds för närvarande inte.
4	Hashing-algoritm	SHA-256 eller högre rekommenderas för nya distributioner och befintliga PKI.	ACM-hanterade certifikat använder RSA-nycklar med en 2048-bitars modul och SHA-256; ACM hanterar för närvarande inte ECDSA-certifikat.	Stöder SHA256WITHECDSA, SHA384WITHECDSA, SHA512WITHECDSA, SHA256WITHRSA, SHA384WITHRSA och SHA512WITHRSA för certifikat som utfärdats direkt av ACM Private CA.	Stöder SHA-256 och SHA-384.
5	RFC-efterlevnad	CA-certifikat måste vara X.509 v3 och överensstämma med RFC 5280 (fortfarande den nuvarande basprofilen för X.509/PKIX-certifikat) och de nuvarande baskraven för CA/Browser Forum.	AWS skyddar infrastrukturen som kör ACM i AWS-molnet; effektiviteten testas av tredjepartsrevisorer under AWS Compliance Programs.	Tillämpar urvalsbegränsningar enligt RFC 5280, men inte alla begränsningar som definieras i RFC 5280 tillämpas.	Använder ZLint-verktyget för att validera X.509-certifikat mot RFC 5280, även om det inte tillämpar alla RFC 5280-krav.
6	CRL-distributionspunkt	Microsoft PKI lagrar CRL:n under LDAP och HTTP.	Återkallelse av certifikat för ACM hanteras via AWS Support; ett supportärende måste upprättas.	ACM Private CA placerar automatiskt CRL:n i en avsedd Amazon S3-bucket.	CRL-publicering måste vara explicit aktiverad på en CA-pool, vilket kan göras vid skapandet av poolen.
7	Lagring av privata nycklar	Det rekommenderas att lagra privata nycklar i en FIPS 140-3 nivå 3-kompatibel HSM (FIPS 140-2-valideringar flyttas till historisk status den 21 september 2026).	ACM lagrar certifikatet och dess motsvarande privata nyckel med hjälp av AWS Key Management Service (KMS) för att skydda den privata nyckeln.	Som standard lagras privata nycklar för privata CA:er i AWS-hanterade HSM:er som uppfyller FIPS PUB 140-3 nivå 3-säkerhetskrav för kryptografiska moduler.	CA-nycklar lagras i Cloud HSM, FIPS 140-2 nivå 3-validerade, tillgängliga i Nord- och Sydamerika, Europa och Asien och Stillahavsområdet.
8	Revisionsrapporter	Granskning kan aktiveras på en certifikatutfärdare i Windows Server för att tillhandahålla en granskningslogg för alla hanteringsuppgifter för certifikattjänster.	ACM är integrerat med AWS CloudTrail, som registrerar åtgärder som vidtas av en användare, roll eller AWS-tjänst och är aktiverat som standard.	Granskningsrapporter listar alla certifikat som ACM Private CA har utfärdat eller återkallat, sparade i en ny eller befintlig S3-bucket.	Molngranskningsloggar täcker granskningsloggar för administratörsaktivitet, dataåtkomst, systemhändelser och policyavvisade policyer för varje projekt, mapp och organisation.
9	Bästa praxis (övergripande)	Planera före distribution, håll rot-CA offline, undvik att utfärda slut-entitetscertifikat från rot-CA:n, aktivera granskning och säkra nycklar med en FIPS 140-3 nivå 3 HSM.	Kontrollera certifikatets utgångsdatum och giltighet regelbundet, minimera användningen av rot-CA och tillämpa TLS 1.2 eller senare.	Dokumentera CA-struktur och policyer, minimera användningen av rot-CA, separera administratörs- och utfärdarroller, aktivera CloudTrail och rotera CA-privata nycklar regelbundet.	Tillämpa rolltilldelning med lägst behörighet, använd Enterprise-nivån för pooler med flera CA-konton, säkra signeringsnycklar med Cloud HSM och aktivera granskningsloggning.
10	CA-hierarki	Hierarkiska PKI-distributioner använder vanligtvis en-, två- eller tre-nivåhierarkier.	ACM tillhandahåller, hanterar och distribuerar certifikat för AWS-tjänster och anslutna resurser snarare än att driva sin egen CA-hierarki.	Stöder utformning av en hierarki av certifikatutfärdare med upp till fem nivåer.	När en underordnad CA är kopplad till en extern rot-CA måste egenskaper i CSR:n som genereras av CAS bevaras i det signerade CA-certifikatet, inklusive eventuella begränsningar av sökvägslängden.
11	Redundans och katastrofåterställning	Redundans- och katastrofåterställningsplaner bör byggas in i design- och implementeringsplaneringsfasen av en PKI-implementering.	ACM har inget dedikerat SLA, men det har den hanterade tjänsten ACM Private Certificate Authority.	Tillgänglig i flera AWS-regioner för redundanta CA:er, med ett SLA-mål på 99.9 % tillgänglighet.	Tillgänglig i flera Google Cloud-regioner för redundans, med ett SLA-mål på 99.9 % tillgänglighet.

För- och nackdelar per plattform

Microsoft PKI (ADCS)

Fördelar: full kontroll över CA-hierarkin och policyn, tät Active Directory-integration, inga återkommande molnavgifter för själva CA:n, väl förstått av de flesta Windows-administratörer på företag.

Nackdelar: kräver intern HSM-upphandling och offline-root-CA-ceremonier, manuella certifikatlivscykelprocesser om inte automatisering läggs till separat, och den operativa bördan faller helt på intern personal.

AWS-certifikathanterare (ACM)

Fördelar: gratis offentliga TLS-certifikat för användning med integrerade AWS-tjänster, automatisk förnyelse, minimala driftskostnader, tät CloudTrail-integration för granskningsinsyn.

Nackdelar: begränsad till AWS-integrerade resurser och publika/importerade certifikat, ingen egen privat CA-hierarki och inget dedikerat SLA för den kostnadsfria publika certifikattjänsten.

AWS ACM Privat CA

Fördelar: fullständigt hanterad privat CA-hierarki upp till fem nivåer djup, FIPS 140-3 nivå 3 HSM-backade nycklar som standard, inbyggd CloudTrail-granskning, 99.9 % SLA.

Nackdelar: löpande kostnader per CA och per certifikat, AWS-centrerad och tillämpar inte alla RFC 5280-begränsningar automatiskt.

Google Cloud-certifikatutfärdartjänst

Fördelar: flexibla Enterprise- och DevOps-nivåer, molnbaserade HSM-baserade signeringsnycklar, detaljerad IAM-baserad rolltilldelning, stark anpassning till GCP-centrerad infrastruktur.

Nackdelar: DevOps-nivån stöder inte återkallelse av certifikat, CRL-publicering måste vara explicit aktiverad och den tillämpar inte alla RFC 5280-krav.

Att välja rätt PKI: Beslutsmatris

Användningsfall	Säkerhetspåverkan	Operativ insats	Automatiseringsanpassning	Rekommenderad ägare
TLS-certifikat för offentliga webbplatser/appar på AWS-infrastruktur	Medium — offentlig förtroendekedja, korta giltighetsfönster	Låg, när den är konfigurerad	Hög — AWS Certificate Manager förnyar automatiskt	Plattforms-/DevOps-team
Helt offline, intern rot-CA med airgapp för regulatoriska eller högkvalitativa krav	Hög — förtroendegrund för hela den interna PKI:n	Hög — manuella ceremonier, HSM-hantering	Låg avsiktlig (avsiktligt offline)	PKI-administratörer, säkerhetsarkitekter
Privat CA-hierarki, helt hostad i AWS för interna tjänster och enhetsidentitet	Hög — skyddar internt förtroende mellan tjänster	Medium — hanterad HSM, men policy- och hierarkidesign krävs fortfarande	Hög — AWS ACM Private CA-automation och CloudTrail	PKI-administratörer, plattformsteam
Multimoln- eller GCP-centrerad infrastruktur som behöver CA-pooler per projekt	Hög — styr förtroendet i GCP-projekt	Medium — IAM-rolldesign och CA-poolnivåer	Hög — Google Cloud CAS med Cloud HSM	Plattformsteam, säkerhetsarkitekter
Hybrid lokal hantering plus multi-moln PKI som behöver ett enda styrningslager	Hög — sträcker sig över alla plattformar ovanför	Medel, när ett hanterat lager används; hög om självintegrerat	Hög med ett hanterat PKI-as-a-Service- och certifikatlivscykelhanteringslager	CISO:er, säkerhetsarkitekter, regelefterlevnad

Praktisk checklista: Granskning av en PKI för flera leverantörer

Utgåva	Business Impact	Rekommenderad åtgärd	Ägare
Ingen dokumenterad beslutsprocess för vilken plattform som utfärdar vilka certifikat	Duplicerade CA-hierarkier, inkonsekvent nyckelskydd mellan team	Anta en dokumenterad beslutsmatris (användningsfall, säkerhetspåverkan, insats, automatiseringsanpassning, ägare) innan en ny CA etableras	Säkerhetsarkitekter, CISO:er
Alla CA-hierarkier som fortfarande förlitar sig på FIPS 140-2-validerade HSM:er	Valideringar flyttas till historisk status 21 september 2026	Planera en migrering till FIPS 140-3 nivå 3-validerade HSM:er där plattformen stöder det	PKI-administratörer, regelefterlevnad
Manuellt utfärdande eller förnyande av certifikat på valfri plattform	Kan inte hålla jämna steg med CA/Browser Forums krympande giltighetsschema	Övergå till plattformsbaserad automatisering (ACM, ACM Private CA eller Google Cloud CAS) eller ett hanterat PKI/CLM-lager	Plattformsteam, PKI-administratörer
Ingen konsekvent granskningsloggning mellan Microsoft PKI, AWS och Google Cloud CA:er	Brister i efterlevnaden uppstår endast vid en incident eller extern revision	Aktivera och centralisera CloudTrail, Cloud Audit Logs och Windows Server-granskning i en övervakningsvy	Efterlevnad, säkerhetsarkitekter
Ingen kryptoagilitetsplan för den slutliga PQC-övergången	Alla fyra plattformar skriver fortfarande på med RSA eller ECDSA idag.	Lägg till PQC-beredskapsbedömning och kryptoagilitetsplanering till PKI-färdplanen	Säkerhetsarkitekter, CISO:er

Vem borde bry sig om detta

Att välja mellan PKI-plattformar är inte bara ett arkitekturbeslut. Här är vad varje intressent bör ta med sig.

PKI-administratörer

Egen daglig drift av den plattform (eller de plattformar) som organisationen kör. Åtgärd: bekräfta att varje CA-hierarki som används, oavsett om det är Microsoft PKI, AWS eller Google Cloud, finns på en FIPS 140-3 nivå 3 HSM-färdplan och har automatisk förnyelse där plattformen stöder det.

Säkerhetsarkitekter

Ansvara för beslutsmatris- och hierarkidesignen över plattformar. Åtgärd: dokumentera varför varje befintlig CA-hierarki finns där den gör, och flagga alla hierarki som endast existerar på grund av historisk tröghet snarare än en avsiktlig användningsfallsanpassning.

Plattformsteam

Ta ansvar för automatiseringslagret som förhindrar att certifikatutfärdande och förnyelse utförs manuellt. Åtgärd: identifiera vilka av dina AWS-, Google Cloud- eller Microsoft PKI-certifikat som fortfarande kräver att en människa klickar sig igenom en konsol snarare än ett automatiserat protokoll.

Compliance-team

Egen bekräftande revisionsloggning och CP/CPS-dokumentation finns för varje CA-hierarki som används. Åtgärd: verifiera att FIPS-valideringsstatus (140-2 vs. 140-3) spåras per HSM och per plattform, inte antas.

CISO: er

Ta ansvar för beslutet om att bygga kontra köpa kontra multimoln för PKI överlag. Åtgärd: väg driftskostnaden för att köra Microsoft PKI, AWS och Google Cloud CA:er oberoende av varandra mot konsolidering under ett hanterat PKI-som-en-tjänst- och certifikatlivscykelhanteringslager.

Vår syn: Hur krypteringskonsulting stöder val av PKI-leverantör

På Encryption Consulting specialiserar vi oss på att designa och migrera PKI-infrastrukturer som är anpassade till en organisations unika säkerhetsbehov, oavsett vilken plattform, eller kombination av plattformar, som passar bäst. Vi erbjuder omfattande PKI-design- och implementeringstjänster för både befintliga och nya PKI-infrastrukturer. Våra lokala lösningar inkluderar Microsoft PKI, medan våra molnbaserade PKI-lösningar fungerar med ledande molntjänstleverantörer, inklusive AWS Certificate Manager, AWS ACM Private CA, Azure PKI och Google Cloud Certificate Authority Service.

För organisationer som hellre inte vill hantera detta beslut, eller den resulterande hierarkin, helt internt, kör vår PKI-as-a-Service- plattform en helt hanterad, molnbaserad PKI med FIPS 140-3 HSM-baserade nycklar från dag ett, så plattformsjämförelsen ovan blir vårt teams jobb snarare än ert. Vårt CertSecure Manager- lager hanterar sedan certifikatlivscykelhantering och automatiserad identifiering över vilken blandning av Microsoft PKI, AWS och Google Cloud CA:er som en organisation redan kör, vilket stänger gapet i manuell utfärdande som nämndes i checklistan ovan. För frågan om kryptoagilitet som togs upp tidigare hjälper vårt PQC Center of Excellence och PQC Readiness Assessment team att planera den slutliga övergången från RSA och ECDSA, och vår CBOM Secure kryptografiska identifierings- och inventeringsplattform ger säkerhetsarkitekter den maskinidentitetsinventering som behövs för att veta exakt vad som körs på varje CA-hierarki idag. För en djupare titt på att automatisera certifikatlivscykelhantering när en plattform har valts, se vårt relaterade inlägg om hur CLM hjälper till att mildra vanliga SSL/TLS-attacker.

Ytterligare läsning

AWS ACM Private CA användarhandbok

Google Cloud-certifikatutfärdartjänst

Microsoft PKI-tjänsters certifikatpolicy

Slutsats

Public Key Infrastructure (PKI) spelar en viktig roll för att säkerställa säker kommunikation genom digitala certifikat, där certifikatutfärdare och registreringsmyndigheter arbetar tillsammans för att autentisera enheter och hantera certifikatlivscykler. Olika leverantörer erbjuder skräddarsydda PKI-lösningar, var och en med olika styrkor för olika användningsfall: Microsoft PKI förespråkar säker lokal nyckelhantering med offline-rot-CA:er och HSM:er, AWS Certificate Manager och ACM Private CA erbjuder automatiserad, molnbaserad certifikathantering med FIPS 140-3 Level 3 HSM-skydd, och Google Clouds Certificate Authority Service betonar rollbaserad åtkomstkontroll och molnbaserade HSM-baserade signeringsnycklar. Det rätta svaret är sällan en plattform i isolering; det är ett dokumenterat beslut, matchat med användningsfall, säkerhetspåverkan, operativa ansträngningar och ägarskap, som uppdateras i takt med att giltighetsfönstren krymper och branschen rör sig mot post-kvantumberedskap.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från att jämföra dessa PKI-plattformar?

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA och Google Cloud CAS utfärdar och hanterar alla betrodda digitala certifikat, men skiljer sig åt i var CA-nycklar finns, hur automatiserad utfärdandet är och vem som bär den operativa bördan. Rätt val beror på användningsfallet, inte en enda "bästa" plattform.

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

Företags-PKI-team kör i allt högre grad mer än en av dessa plattformar samtidigt. Utan en dokumenterad beslutsprocess leder den blandningen till duplicerade CA-hierarkier, inkonsekventa nyckelskyddsnivåer och luckor i granskningsloggningen som bara uppstår under en incident.

Vilka risker ökar om val av PKI-leverantör hanteras utan en dokumenterad process?

Ad hoc-val av leverantörer ökar risken för certifikat som utfärdas från inkonsekventa HSM-skyddsnivåer, CA-hierarkier som ingen kan ta hänsyn till och manuella förnyelseprocesser som inte kan hålla jämna steg med CA/Browser Forums krympande giltighetsschema.

Vilka team bör ta ansvar för beslutet om PKI-leverantörsval?

Säkerhetsarkitekter äger vanligtvis beslutsmatrisen och hierarkin, PKI-administratörer äger den dagliga driften av de plattformar som väljs, plattformsteam äger automatiseringslagret, efterlevnad verifierar dokumentation och FIPS-status, och CISO äger det övergripande bygg-versus-köp-versus-multi-cloud-anropet.

Hur kopplas val av PKI-leverantör till hantering av certifikatlivscykeln?

Varje plattform i denna jämförelse kräver fortfarande att utfärdande, förnyelse och återkallelse sker på ett tillförlitligt sätt. Verktyg för hantering av certifikatlivscykeln som omfattar Microsoft PKI, AWS och Google Cloud är det som gör att certifikatet är tillförlitligt oavsett vilken plattform som utfärdat ett givet certifikat.

Hur bör organisationer mäta om deras val av PKI-leverantör fungerar?

Spåra certifikatrelaterade avbrott och incidenter med utgångna certifikat, om utfärdande och förnyelse är automatiserade snarare än manuella, om granskningsloggning är centraliserad över plattformar och om varje CA-hierarkis HSM-skyddsnivå är aktuell.

Vad bör granskas eller övervakas regelbundet över en PKI med flera leverantörer?

Granska regelbundet dokumentationen för CA-hierarkin (CP/CPS), FIPS-valideringsstatus per HSM, certifikatutgångsdatum för alla plattformar som används och om CloudTrail, Cloud Audit Logs och Windows Server-granskning faktiskt är aktiverade och övervakade.

Hur påverkar valet av PKI-leverantör moln-, hybrid- eller multi-CA-miljöer?

Hybrid- och multimolnmiljöer kör ofta Microsoft PKI lokalt tillsammans med AWS och Google Cloud CA:er, var och en med sin egen konsol, automationsmodell och revisionslogg. Ett enda styrningslager eller en hanterad PKI/CLM-plattform är vanligtvis det som håller den mixen konsekvent snarare än fragmenterad.

Vilka vanliga misstag bör team undvika när de väljer mellan dessa plattformar?

Vanliga misstag inkluderar att välja en plattform baserat på vilket moln resten av arbetsbelastningen körs på snarare än det faktiska användningsfallet, att lämna en rot-CA:s FIPS-valideringsstatus okontrollerad i flera år och att köra parallella CA-hierarkier över plattformar utan en dokumenterad anledning för var och en.

Vad bör uppdateras kvartalsvis för en PKI med flera leverantörer?

Granska instrumentpaneler för certifikatutgång, bekräfta migreringsförloppet för FIPS 140-3 för alla HSM som fortfarande är på 140-2, gå igenom beslutsmatrisen för eventuella nya användningsfall som lagts till sedan den senaste granskningen och bekräfta att ändringar av giltighetstiden för CA/Browser Forum återspeglas i förnyelseautomatiseringen.