Molnbaserad PKI – GCP, AWS och Azure

Molnbaserad PKI kör delar av eller hela en certifikatutfärdarhierarki (CA) på AWS-, Azure- eller GCP-infrastruktur istället för lokal hårdvara. Detta är viktigt eftersom certifikatens livslängd krymper snabbt under CA/Browser Forums giltighetsschema, och manuell, hårdvarubunden PKI kan inte hålla jämna steg. Den rekommenderade åtgärden: håll din rot-CA (och helst din policy-CA) offline oavsett vilket moln du använder och välj den hybridarkitektur som matchar hur mycket kontroll du behöver över den utfärdande CA:n.

Publicerad: oktober 2020. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI-rådgivningsteam.

Om du hellre inte vill bygga och driva den här arkitekturen själv jämför vår guide för PKIaaS-distributionsmodeller det helt hanterade alternativet. Och om HSM-förvaring är den del du fortfarande funderar på, går dedikerade kontra delade HSM:er i PKIaaS djupare in på den avvägningen enbart.

Vad är molnbaserad PKI?

Public Key Infrastructure (PKI) är den uppsättning hårdvara, programvara, policyer och procedurer som behövs för att skapa, distribuera och återkalla digitala certifikat, vilka bevisar identiteten för en person, enhet eller tjänst i ett nätverk. En PKI:s kärnuppgift är autentisering och konfidentialitet: den låter två parter lita på varandras identitet och kryptera det de utbyter, och den levererar detta genom tre egenskaper som kallas CIA-triaden : konfidentialitet (endast den avsedda mottagaren kan läsa informationen), integritet (informationen ändrades inte under överföringen) och tillgänglighet (de system som utfärdar och validerar certifikat är aktiva när det behövs).

Molnbaserad PKI betyder helt enkelt en eller flera nivåer i den CA-hierarkin, oftast den utfärdande CA:n, som körs på AWS-, Azure- eller GCP-infrastruktur snarare än på hårdvara som du äger och lagrar själv. Några termer återkommer i denna jämförelse: en rot-CA är hierarkins förtroendeankare och hålls normalt offline; en utfärdande CA (ibland kallad en underordnad CA) är den CA som faktiskt signerar slut-entitetscertifikat; en policy-CA är en valfri mellanliggande nivå som begränsar vad en utfärdande CA får utfärda; en HSM (Hardware Security Module) är den manipulationssäkra hårdvara som genererar och skyddar en CA:s privata nyckel; och CDP, AIA och OCSP är återkallnings- och certifikatkedjningstjänster (CRL Distribution Point, Authority Information Access och Online Certificate Status Protocol) som låter förlitande parter kontrollera om ett certifikat fortfarande är giltigt.

Varför flyttar organisationer PKI till molnet?

Organisationer flyttar utfärdande certifikatutfärdare till molnet för att byta kapitalintensiv, praktisk hårdvaruhantering mot en tjänst som skalar på begäran och tar bort det mesta av underhållsbördan. Till skillnad från en lokal driftsättning kräver en molnbaserad utfärdande certifikatutfärdare inte att du rackar en HSM, patchar ett operativsystem eller planerar hårdvaruuppdateringscykler själv. Molnleverantören hanterar tillgänglighet, skalning och den underliggande infrastrukturen, medan du fokuserar på certifikatpolicy och utfärdande. Den förändringen är viktigast för organisationer vars certifikatvolym växer oförutsägbart, eftersom en molnbaserad utfärdande certifikatutfärdare kan absorbera en topp i registreringen (en ny affärsenhet, en IoT-flotta, ett Kubernetes-kluster som skalas ut) utan en hårdvaruanskaffningscykel mitt i den.

Vilka är de vanliga utmaningarna med molnbaserad PKI?

De flesta problem med moln-PKI kan spåras tillbaka till fem återkommande brister: otydlig design, att ignorera HSM:er, att välja fel moln för kravet, dålig integration med befintlig infrastruktur och ingen riktig certifikatlivscykelprocess.

• Svaga PKI-grunder. Team som hoppar över en riktig designfas tenderar också att missa efterlevnadskrav som NIST SP 800-57:s riktlinjer för kryptografisk nyckelhantering, vilka är avsedda att tillämpas före driftsättning, inte upptäckas efteråt.
• Behandla HSM:er som valfria. Att hoppa över HSM-baserad nyckellagring för en CA:s privata nyckel innebär att CA:n inte är FIPS 140 nivå 3-kompatibel, punkt, endast programvarubaserad nyckellagring kan inte göra det påståendet oavsett molnleverantör.
• Att välja ett moln utifrån bekvämlighet snarare än passform. AWS, Azure och GCP stöder betydligt olika CA-tjänster och HSM-alternativ; rätt val beror på var dina arbetsbelastningar redan finns och vilken efterlevnadsordning som gäller, inte vilken konsol ditt team råkar känna till bäst.
• Dålig integration med befintlig PKI. En molnutfärdig certifikatutfärdare som inte är korrekt kopplad till dina befintliga rot- och policy-certifikatutfärdare skapar en andra, frånkopplad hierarki istället för att utöka den du redan litar på.
• Ingen certifikatlivscykelprocess. Att välja rätt verktyg för identifiering, utfärdande, förnyelse och återkallelse är lika viktigt som själva CA-arkitekturen; en ohanterad certifikatlivscykel orsakar avbrott oavsett hur väl den underliggande PKI:n är utformad.

Hur står sig nativa kontra externa nyckelkontrollmodeller för Cloud PKI i jämförelse?

Använd inbyggd molnbaserad HSM-förvaring för den utfärdande certifikatutfärdaren som behöver skalas och integreras med molntjänster, och behåll extern, lokal förvaring för rot- (och vanligtvis policy-) certifikatutfärdaren vars privata nyckel aldrig ska kunna nås via ett nätverk alls.

Modell	Var den privata nyckeln finns	Typisk användning
Inbyggd (HSM-förvaring i molnet)	Genereras och lagras inuti AWS CloudHSM (bakom ACM Private CA), Azure Managed HSM eller GCP Cloud HSM	Utfärdande CA som behöver skalas, integreras med molnbaserade tjänster och utfärdas i stor skala
Importerad (BYOK-motsvarande)	Nyckelmaterial genererat på din egen HSM, sedan importerat till moln-HSM, eller en CA installerad på en virtuell molnmaskin som backas upp av en lokal HSM	Migrera en befintlig CA:s identitet till molnet utan att återskapa förtroende eller uppfylla en policy som kräver kundgenererat nyckelmaterial
Extern (HYOK-ekvivalent)	Importeras aldrig till molnet; stannar kvar på en lokal HSM med luftgap som endast används under schemalagda signeringsceremonier.	Rot-CA, och ofta policy-CA, i varje arkitektur nedan

Avvägningen speglar nyckelhantering generellt: inbyggd molnförvaring ger dig elastisk skalbarhet och tät integration med moln-IAM och loggning, medan extern förvaring ger dig den starkaste garantin. Ett komprometterat molnkonto kan fortfarande inte röra din rot-CA:s nyckel, på bekostnad av en manuell, ceremonidriven process varje gång nyckeln behöver användas. Vår ceremoniguide för rot-CA:n beskriver hur den processen faktiskt ser ut i praktiken.

Hur kontrollerar IAM åtkomst till privata nycklar i Cloud PKI?

En moln-PKI:s IAM-design måste separera de personer som administrerar själva certifikatutfärdaren från de personer och system som bara behöver begära ett certifikat, med hjälp av det identitetssystem som det underliggande molnet redan tillhandahåller.

• AWS: IAM-policyer styr vem som kan anropa ACM Private CA och CloudHSM API:er, medan CloudHSM dessutom tillämpar sina egna roller för kryptoansvarig och kryptoanvändare inuti HSM, så enbart en AWS IAM-behörighet räcker inte för att använda nyckeln.
• Azurblå: Azure RBAC styr vem som kan hantera certifikatutfärdarens stödjande resurser, medan Managed HSM tillämpar en separat, lokal RBAC-modell som inte ens Azure-prenumerationsadministratörer kan åsidosätta av design.
• GCP: Cloud IAM-roller som är kopplade till Cloud HSM och Certificate Authority Service styr både administrativa åtgärder (skapa eller inaktivera en CA) och utfärdandeåtgärder (begäran av ett certifikat), och Google rekommenderar att hålla dessa två rolluppsättningar separata.

En praktisk installation med minsta privilegier följer samma fem steg på vilket som helst av de tre molnen:

1. Inventera varje identitet, människa eller tjänst, som för närvarande har behörighet att beröra CA eller dess HSM.
2. Dela upp "kan administrera certifikatutfärdaren" (skapa, inaktivera, rotera) från "kan begära ett certifikat" i separata roller, och tilldela ingen identitet till båda.
3. Omfånga varje beviljande till den specifika CA- eller HSM-resursen, aldrig ett jokertecken över alla CA:er i kontot, prenumerationen eller projektet.
4. Kräv ett arbetsflöde med privilegierad åtkomst, och helst godkännande från flera parter, för alla åtgärder som kan inaktivera eller ta bort en certifikatutfärdare.
5. Granska CA-relaterade IAM-tilldelningar med en fast kvartalsvis kadens, eftersom åtkomstavvikelser här är en direkt väg till felaktigt certifikatutfärdande.

Vilka är de molnbaserade PKI-arkitekturmodellerna?

Fyra arkitekturer täcker de flesta moln-PKI-distributioner, och de skiljer sig främst åt i hur många nivåer som finns och hur mycket av hierarkin som finns lokalt.

Modell	Structure	Bästa passform
Enkel modell	Rot-CA lokalt och offline; en enda utfärdande CA i molnet, backad av en moln-HSM	Småskaliga implementeringar där en utfärdande certifikatutfärdare kan hantera varje certifikatförfrågan
Tvånivåhybridmodell	Rot-CA lokalt och offline; två utfärdande CA:er, en lokalt och en i molnet, båda online	Organisationer som fortfarande har betydande lokal infrastruktur (arbetsstationsautentisering, domäncertifikat) vid sidan av molnarbetsbelastningar
Trenivåmodell	Rot-CA lokalt och offline; en policy-CA (även offline) begränsar explicit vad den molnutfärdande CA:n kan utfärda	Team som behöver strikt, granskningsbar kontroll över utgivningspolicyn samtidigt som de fortfarande använder molninfrastruktur för den utfärdande CA:n
Trenivåhybridmodell	Rot-CA och policy-CA lokalt och offline; två utfärdande CA:er, en lokal och en i molnet, var och en styrd av samma policy-CA	Organisationer som behöver kontroll på policynivå över både lokal och molnbaserad utfärdande samtidigt

Enkel modell:

Tvåstegs hybridmodell:

Trenivåmodell:

Trestegs hybridmodell:

Till exempel lagrar en utfärdande CA byggd på AWS Certificate Manager Private CA sin privata nyckel i AWS CloudHSM bakom kulisserna; den modell du väljer avgör om det är den enda CA:n i hierarkin (Enkel) eller en av flera, var och en med ett definierat omfång (hybrid- och trenivåvarianterna).

Hur ska man hantera certifikat- och CA-nyckelrotation i Cloud PKI?

Giltighetstid för Leaf-certifikat och rotation av CA-nyckel körs på helt olika klockor, och att behandla dem som samma problem är ett vanligt planeringsmisstag.

• Giltighetstid för Leaf-certifikat fastställs av CA/Browser Forums publicerade glidbana: maximalt 200 dagar idag, minskande till 100 dagar den 15 mars 2027 och till 47 dagar den 15 mars 2029. Vid 47 dagars giltighetstid är manuell förnyelse inte genomförbar i någon egentlig skala, vilket är anledningen till att ACME-baserad automatisering i praktiken är obligatorisk för alla utfärdande CA enligt detta schema.
• CA-nyckelrotation arbetar med en mycket längre cykel, knuten till rot- eller utfärdande CA:s egen giltighetsperiod (vanligtvis 10 till 20 år för en rot, 3 till 5 år för en utfärdande CA) och till kostnaden för att köra en ny nyckelceremoni, inte till CA/Browserforumets schema för lövcertifikat. Att rotera en CA-nyckel innebär att generera ett nytt nyckelpar, utfärda ett nytt CA-certifikat och kedja om varje beroende certifikat, så det planeras medvetet snarare än automatiseras på samma sätt som lövförnyelse.

Vad bör du logga och övervaka i en molnbaserad PKI?

Varje lager av en moln-PKI, själva CA:n, HSM:en som skyddar dess nyckel och molnplattformen som värdar båda, behöver sin egen loggning aktiverad innan det första certifikatet någonsin utfärdas.

• Loggar på CA-nivå: Varje utfärdande, återkallelse och policyändring bör registreras med den begärande identiteten, oberoende av vilket moln som är värd för CA.
• HSM-nivåloggar: AWS CloudTrail samlar in CloudHSM- och ACM Private CA API-anrop, Azure Monitor samlar in hanterade HSM-åtgärder genom sina diagnostiska inställningar, och GCP Cloud Audit Logs samlar in aktivitet i Cloud HSM och Certificate Authority Service. I alla tre fallen måste detta explicit dirigeras till en SIEM och inte lämnas kvar i standardfönstret för kvarhållning.
• Offentliga kontroller: Loggar för certifikattransparens ger dig en oberoende, endast tilläggsbaserad registrering av alla offentligt betrodda certifikat som utfärdats under dina domäner, vilket är värt att övervaka även för certifikat som du inte avsåg att utfärda.

Varna specifikt för exportförsök till CA-nyckel, oväntad certifikatutfärdande utanför ditt normala registreringsarbetsflöde och alla ändringar av en policy-CA:s utfärdandebegränsningar. Det är dessa händelser som förvandlar rutinmässig PKI-åtgärd till en incident.

Hur jämför sig AWS, Azure och GCP vad gäller kostnad för molnbaserad PKI?

Molnbaserad PKI ersätter det mesta av den stora initiala kostnaden för en lokal distribution med återkommande HSM- och CA-serviceavgifter som skalas med användning snarare än med antalet anställda eller hårdvaruuppdateringscykler.

Kostnadsdrivare	Ungefärlig modell
AWS (ACM privat CA + CloudHSM)	ACM Private CA fakturerar per CA per månad plus avgifter per certifikatutfärdande; CloudHSM fakturerar per HSM-instans per timme om du behöver dedikerad HSM-kontroll utöver ACM PCAs hanterade alternativ.
Azure (Hanterad HSM)	Faktureras per HSM-pool per timme snarare än per nyckel, vanligtvis runt 3 till 3.20 USD per timme för standardnivån, oavsett certifikatvolym
GCP (Cloud HSM + Certifikatutfärdartjänst)	En molnbaserad HSM med en enda hyresgäst kostar ungefär 3 500 dollar per månad och inkluderar ett stort antal nyckelversioner utan extra kostnad; Certificate Authority Service lägger till sina egna avgifter per CA och per certifikat.
Lokal PKI (för jämförelse)	Våra egna uppdelning av interna PKI-kostnader gör att gapet totalt sett blir ungefär 300 000 dollar mer än för en jämförbar hanterad tjänst, när HSM:er, PKI-tekniker, rotceremonier och revisioner räknas in.

Behandla molnsiffrorna ovan som riktlinjer och bekräfta aktuell regional prissättning innan budgetering; den mer hållbara jämförelsen är strukturell, molnbaserad PKI omvandlar de flesta PKI-kostnaderna till en förutsägbar, användningskopplad avgift, medan lokal PKI koncentrerar kostnaden till stora, sällsynta kapitalhändelser (HSM-inköp, rotceremonier, hårdvaruuppdateringar).

Hur ser en molnbaserad PKI-arkitektur för flera moln ut?

Att köra PKI över GCP, AWS och Azure samtidigt utökar trenivåhybridmodellen snarare än att ersätta den: en offline rot-CA och policy-CA förankrar fortfarande hierarkin, och varje moln får sin egen utfärdande CA under, anpassad till de arbetsbelastningar som faktiskt körs där.

Det felläge vi oftast ser är inte arkitektur, utan styrning: tre utfärdande certifikatutfärdare som provisioneras oberoende av tre olika molnteam, vart och ett med sina egna certifikatprofiler, rotationsvanor och loggningsinställningar, som glider isär tills en granskare (eller ett avbrott) tvingar fram avstämning. För den fullständiga referensarkitekturen och hur man undviker den avvikelsen, se vår Multi-Cloud PKIaaS Architecture Guide för AWS, Azure och GCP.

Vilka är begränsningarna med molnbaserad PKI?

• Root CA-säkerhet beror fortfarande på processen, inte molnet. Att flytta en utfärdande CA till molnet gör ingenting för att säkra en rot-CA som fortfarande hanteras slarvigt lokalt; den offline, ceremonidrivna disciplinen måste gälla oavsett var resten av hierarkin finns.
• Konsekvens mellan moln är inte automatisk. AWS, Azure och GCP exponerar CA- och HSM-tjänster på olika sätt, så certifikatprofiler, rotationspolicy och loggformat måste medvetet standardiseras över moln; ingenting tvingar fram det för dig.
• Leverantörslåsning på HSM-lagret. En CA:s nyckelmaterial som genereras inuti ett molns HSM kan inte bara överföras till ett annat molns HSM. Att migrera senare innebär en ny nyckelceremoni, inte ett lyft-och-förskjutning-projekt.
• 47-dagars glidbanan är ett hårt automatiseringskrav, inte en preferens. Alla moln-PKI-designer som förutsätter manuell certifikatförnyelse kommer att misslyckas när CA/Browser Forums kortare giltighetsperioder träder i kraft.

Beslutschecklista: Att välja en molnbaserad PKI-arkitektur

1. Bekräfta att din rot-CA (och policy-CA, om du har en) förblir lokal, offline och ceremonistyrd, oavsett vilken modell du väljer nedan.
2. Om din infrastruktur är helt molnbaserad, börja med den enkla modellen. Om du fortfarande har meningsfull lokal infrastruktur, använd istället tvånivåhybridmodellen.
3. Lägg till en policy-CA (trenivås- eller trenivåshybridmodell) endast om du behöver explicita, granskningsbara begränsningar för vad en utfärdande CA kan utfärda, inte som standard.
4. Anpassa din certifikatförnyelseprocess till det nuvarande giltighetstaket för CA/Browser Forum och behandla ACME-baserad automatisering som ett krav, inte en framtida förbättring.
5. Om du kör mer än ett moln idag, eller förväntar dig att köra det, utforma styrningslagret för flera moln, delade certifikatprofiler, konsekvent rotationspolicy och enhetlig loggning, innan varje molnteam etablerar sin egen utfärdande certifikatutfärdare oberoende av varandra.

Vad skulle krypteringskonsulter rekommendera?

För de flesta organisationer rekommenderar vi att man utgår från en trenivås hybridmodell: en offline rot- och policy-CA som förankrar hierarkin, med molnbaserade utfärdande-CA:er som är begränsade per arbetsbelastning och per moln. Misstaget vi oftast ser är inte valet av AWS, Azure eller GCP, utan att man hoppar över policy-CA:n och den styrningsdisciplin som följer med den, vilket faktiskt hindrar en multimoln-PKI från att glida in i tre frånkopplade, inkonsekvent hanterade hierarkier. Om du bygger detta själv kan våra PKI-as-a-Service- och HSM-as-a-Service -erbjudanden ta över de delar som medför störst operativ risk, HSM-förvaring, rotceremonier och styrning av certifikatprofiler, medan du behåller kontrollen över utfärdandepolicyn.

Vanliga frågor om partihandel med mat och dryck

Kan jag använda en enda rot-CA för AWS, Azure och GCP?

Ja, och det är den rekommenderade metoden. Din rot-CA förblir lokal och offline oavsett moln; varje moln får sedan sin egen utfärdande CA som är kopplad till samma rot (genom en policy-CA, om du använder en), så förtroendet är enhetligt även om utfärdandet sker på tre separata platser.

Behöver jag en dedikerad HSM om jag redan använder en hanterad CA-tjänst som AWS ACM Private CA?

Inte nödvändigtvis. ACM Private CA lagrar redan sin privata nyckel i AWS CloudHSM bakom kulisserna, så du får HSM-baserad förvaring utan att behöva etablera ett separat CloudHSM-kluster. En dedikerad HSM blir värd att lägga till när du behöver kontroll över själva HSM:en, till exempel ett specifikt efterlevnadsmandat, krav på anpassade nyckelceremonier eller arbetsbelastningar utanför ACM Private CA som behöver dela samma HSM.

Hur ofta ska jag rotera min CA:s privata nyckel kontra mina lövcertifikat?

Dessa körs enligt olika scheman och bör inte slås ihop. Leaf-certifikat följer nu CA/Browser Forums komprimerade giltighetsschema (200 dagar idag, på väg till 47 dagar i mars 2029) och behöver automatisk förnyelse. En CA:s egen nyckel roteras vanligtvis mycket mer sällan, i storleksordningen år, kopplat till certifikatets giltighetstid och kostnaden för att genomföra en ny nyckelceremoni.

Är molnbaserad PKI FIPS 140-3-kompatibel?

Det kan det vara, men efterlevnaden beror på vilket HSM-alternativ du väljer, inte molnleverantören i allmänhet. Att använda en nyckellagring endast för programvara istället för en HSM-baserad CA innebär att CA:n inte är FIPS 140 nivå 3-kompatibel oavsett vilket moln som är värd för den; bekräfta den specifika valideringsnivån för HSM-tjänsten (CloudHSM, Managed HSM eller Cloud HSM) som du faktiskt distribuerar.

Vad händer med min PKI om jag senare lägger till ett fjärde moln, eller flyttar tillbaka en arbetsbelastning lokalt?

Om din rot- (och policy-) certifikatutfärdare (CA) behölls lokalt och offline från början, är det en fråga om att kedja en ny underordnad certifikatutfärdare till din befintliga rot- (rot-) certifikatutfärdare, inte att återuppbygga förtroendet från grunden, för att lägga till en ny utfärdande certifikatutfärdare var som helst, ett fjärde moln eller tillbaka lokalt. Detta är den främsta anledningen till att vi rekommenderar att hålla förtroendeankaret borta från ett enskilt moln från första början.

Har du en specifik fråga om moln-PKI-arkitektur eller migrering? Kontakta vårt team på [email protected].