AWS-certifikathanterare Privat CA

AWS Private CA (tidigare ACM Private CA) är en helt hanterad privat certifikatutfärdartjänst som låter säkerhetsteam bygga och driva en privat PKI-hierarki inuti AWS utan att köpa eller hantera CA-hårdvara. Den utfärdar X.509-certifikat för intern TLS, mTLS, kodsignering, IoT-enhetsidentitet och användarautentisering. Den rekommenderade utgångspunkten för de flesta team är en tvånivåhierarki med en rot-CA inuti AWS Private CA och en eller flera underordnade CA:er per miljö, med hjälp av AWS KMS kundhanterade nycklar för CA-nyckelskydd, med en hybridmodell (lokal rot, AWS underordnad CA) för organisationer med strikta krav på nyckelsuveränitet.

Snabbt svar: Vad är AWS Private CA och när ska du använda det?

AWS Private CA är rätt val när du behöver utfärda privata X.509-certifikat för interna arbetsbelastningar, behöver en CA-hierarki som ditt team inte behöver köra på fysisk hårdvara och huvudsakligen arbetar i AWS. Det ersätter inte publika TLS-certifikat (AWS Certificate Manager hanterar dessa gratis för integrerade tjänster). Använd AWS Private CA för intern tjänstautentisering, mTLS mellan mikrotjänster, IoT-enhetscertifikat, användar-VPN-certifikat och kodsigneringsscenarier där en offentligt betrodd CA är onödig och oönskad. Tjänsten kostar 400 USD per CA per månad för allmän användning och 50 USD per CA per månad för kortlivade certifikat (giltiga 7 dagar eller färre), med nivåindelade avgifter per certifikat utöver det.

Key Takeaways

• AWS erbjuder två olika tjänster: AWS Certificate Manager (ACM) för kostnadsfria publika TLS-certifikat som används med integrerade AWS-tjänster, och AWS Private CA för privata, internt betrodda X.509-certifikat som kan exporteras med sin privata nyckel och användas var som helst.
• Två CA-hierarkimodeller finns tillgängliga: Privat moln (root- och underordnade CA:er båda i AWS Private CA, nycklar skyddade av AWS KMS) och hybridmoln (root-CA lokalt i din egen HSM, underordnade CA:er i AWS Private CA). Hybridmodellen ger dig direkt hantering av rot-CA-nyckeln; den privata molnmodellen ger dig fullständig molnautomation.
• Två driftslägen förändrar kostnaden avsevärt: Allmänt läge för 400 USD/CA/månad stöder alla giltighetsperioder för certifikat. Kortlivat certifikatläge för 50 USD/CA/månad stöder endast certifikat som är giltiga i 7 dagar eller färre, vilket gör det specialbyggt och kostnadseffektivt för service mesh, SPIFFE-liknande arbetsbelastningsidentitet och högfrekventa mTLS-miljöer.
• Nyckelkontroll är ett designbeslut, inte en standard: AWS Private CA använder AWS KMS för att skydda CA-nycklar. Med standard AWS-hanterade nycklar har AWS den operativa förvaringen. Med kundhanterade KMS-nycklar (BYOK) innehar du källnyckelmaterialet och kan återkalla CA:ns möjlighet att signera direkt genom att ta bort den importerade nyckeln. En fullständig HYOK-modell kräver en hybridmolnarkitektur med en lokal rot-CA.
• CA/B Forum SC-081v3 förespråkar kortlivat läge för offentliga certifikat: Maximal giltighetstid för offentliga TLS sjunker till 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029. Privata CA som utfärdas via AWS Private CA kan redan anpassas till vilken giltighetsperiod som helst; att para ihop det med automatisering av certifikatlivscykeln är avgörande i takt med att förnyelsefrekvensen ökar.

AWS Certificate Manager vs. AWS Private CA: Två olika tjänster

Förväxlingen mellan dessa två tjänster är vanlig och avgörande. De tjänar olika syften, har olika prismodeller och är inte utbytbara.

AWS Certificate Manager (ACM) tillhandahåller och förnyar offentliga SSL/TLS-certifikat för användning med AWS-integrerade tjänster, inklusive Amazon CloudFront, Application Load Balancer, Amazon API Gateway och AWS Elastic Beanstalk. Offentliga certifikat via ACM är gratis att använda med dessa integrerade tjänster. ACM hanterar förnyelse automatiskt. Den kritiska begränsningen: du kan inte exportera ett ACM-hanterat offentligt certifikat eller dess privata nyckel. ACM-certifikat kan inte installeras direkt på EC2-instanser, lokala servrar eller icke-AWS-system. De kan inte heller utfärda certifikat för interna värdnamn eller privata IP-adresser som inte skulle klara validering av allmän egendom.

AWS Private CA är en hanterad tjänst för att köra en privat certifikatutfärdare. Certifikat som utfärdas är privat betrodda (din organisations enheter och tjänster måste konfigureras för att lita på CA-hierarkin). Den privata nyckeln kan exporteras med certifikatet, vilket möjliggör installation var som helst: EC2-instanser, lokala servrar, containrar, IoT-enheter, anpassade applikationer. AWS Private CA stöder privata värdnamn, interna IP-adresser och anpassade ämnesfält som offentliga CA:er inte kan utfärda. Den tar ut en månatlig CA-driftsavgift plus avgifter per certifikatutfärdande.

Dimensionera	AWS-certifikathanterare (ACM)	AWS Privat CA
Certifikatförtroende	Offentligt betrodd (webbläsar- och operativsystemsförtroendebutiker)	Privat betrodd (endast din CA-hierarki)
Export av privat nyckel	Inte tillåtet	Tillåtet (certifikat + nyckel exporterbart)
Giltigt för interna värdnamn	Nej	Ja
Pris	Gratis för ACM-integrerade tjänster	400 USD/CA/månad (allmänt bruk) eller 50 USD/CA/månad (kortvarigt)
Automatisk förnyelse	Ja (hanteras av AWS)	Kräver CLM-automatisering eller manuell förnyelse
Användningsområden	Offentligt HTTPS för webbplatser och API:er på AWS-tjänster	Intern TLS, mTLS, IoT, kodsignering, VPN, användarautentisering
CA-nyckelförvaring	AWS-hanterad (ingen kundåtkomst)	AWS KMS (kundhanterade nycklar stöds)

CA-hierarkimodeller: Privat moln kontra hybridmoln

AWS Private CA stöder två grundläggande CA-hierarkiarkitekturer. Att välja mellan dem är det mest betydelsefulla designbeslutet eftersom det avgör vem som innehar vårdnaden om rot-CA-nyckeln och hur mycket driftskomplexitet du accepterar.

Modell 1: Privat moln (både rot- och underordnade certifikatutfärdare i AWS)

I den här modellen skapar du en rot-CA inuti AWS Private CA och en eller flera underordnade (utfärdande) CA:er under den, allt inuti AWS. Rot-CA-nyckeln skyddas av AWS KMS. AWS hanterar hög tillgänglighet, replikering och nyckelskydd. Du interagerar med CA:n helt och hållet via AWS-konsolen, SDK och CLI.

Den här modellen ger fullständiga fördelar med molnautomation: ingen hårdvara att hantera, ingen HSM att etablera, automatisk hög tillgänglighet över tillgänglighetszoner och API-driven certifikatutfärdande som integreras direkt med AWS-tjänster. Avvägningen är att rot-CA-nyckeln finns i AWS KMS under den delade ansvarsmodellen. AWS har operativ åtkomst till nyckelmaterialet som en del av den hanterade tjänsten. För organisationer med myndighetskrav som kräver att rot-CA-nyckeln innehas exklusivt av kunden, uppfyller den här modellen inte dessa krav om du inte använder kundhanterade KMS-nycklar (BYOK).

AWS Private CA stöder upp till fem nivåer i en CA-hierarki: en rot-CA med upp till fyra nivåer av underordnade CA:er under den. Du kan skapa flera oberoende hierarkier, var och en med sin egen rot. För de flesta företag är en tvånivåhierarki (rot-CA plus en utfärdande CA per miljö) tillräcklig och enklare att granska.

Modell 2: Hybridmoln (lokal rot-CA, underordnad AWS-CA)

I den här modellen finns rot-CA:n lokalt, vanligtvis i en dedikerad HSM under din direkta fysiska och logiska kontroll. Den underordnade CA:n skapas i AWS Private CA, och du signerar den underordnade CA:ns certifikatsigneringsbegäran (CSR) med din lokala rot-CA. Det resulterande signerade underordnade CA-certifikatet importeras tillbaka till AWS Private CA, vilket aktiverar den underordnade CA:n för utfärdande av operativa certifikat.

Den här modellen ger dig direkt hantering av rot-CA-nyckeln. Rot-CA-nyckeln går aldrig in i AWS. Om den underordnade AWS Private CA:n komprometteras kan en angripare inte utfärda nya certifikat från rotnivån, och du kan återkalla det underordnade CA-certifikatet med hjälp av din lokala rot-CA utan något beroende av AWS. Avvägningarna är verkliga: du måste driva och underhålla den lokala rot-CA-infrastrukturen, genomföra dokumenterade rot-CA-ceremonier för alla rot-CA-nyckeloperationer och hantera den fysiska och logiska säkerheten för den lokala HSM:en. För organisationer med en befintlig lokal PKI som delvis migrerar till AWS, tillhandahåller Hybrid Cloud-modellen en naturlig brygga utan att kräva en fullständig ändring av förtroendemodellen.

Nyckelkontroll: Inbyggd KMS, BYOK och HYOK för AWS privat CA

AWS Private CA skyddar CA:s privata nycklar med hjälp av AWS KMS. Valet av KMS-nyckeltyp avgör din kontrollnivå över CA-nyckelmaterialet och din möjlighet att självständigt återkalla åtkomst.

Alternativ 1: AWS-hanterad KMS-nyckel (standard)

När du skapar en privat CA utan att ange en KMS-nyckel skapar och hanterar AWS Private CA en KMS-nyckel åt dig. Denna nyckel är dedikerad till din CA men hanteras helt av AWS. Du kan inte visa nyckelmaterialet, rotera det oberoende eller ta bort det utan att ta bort CA:n. Detta är det enklaste alternativet och uppfyller de flesta operativa krav, men det ger dig inte möjlighet att oberoende återkalla CA:ns signeringsfunktion förutom att ta bort CA:n via AWS-konsolen eller API:et.

Alternativ 2: Kundhanterad KMS-nyckel (BYOK)

BYOK (Bring Your Own Key) för AWS Private CA innebär att du skapar en kundhanterad nyckel (CMK) i AWS KMS, antingen genererad av AWS KMS eller importerad från en extern nyckelkälla, och anger den CMK:n när du skapar den privata CA:n. AWS Private CA använder din CMK för att skydda CA:ns privata nyckel.

Med en kundhanterad CMK kan du inaktivera nyckeln för att omedelbart förhindra att CA:n utför några signeringsåtgärder, utan att ta bort CA:n. Du kan se nyckelanvändningen i AWS CloudTrail. Du styr nyckelrotationen för CMK:n. Om du använder importerat nyckelmaterial (genererar nyckeln externt och importerar den till KMS) behåller du källnyckelmaterialet och kan ta bort det importerade nyckelmaterialet från KMS för att permanent och omedelbart återkalla CA:ns möjlighet att signera, även utan inblandning från AWS-support.

BYOK är rätt val för organisationer som behöver en oberoende kill switch för CA-nyckeln, som har myndighetskrav för kundgenererat nyckelmaterial, eller som behöver visa för revisorer att organisationen behåller proveniensen över alla kryptografiska nycklar som skyddar sin CA-infrastruktur.

Alternativ 3: HYOK (Hold Your Own Key) via hybridarkitektur

Sann HYOK för en rot-CA, där CA-nyckeln aldrig under några omständigheter går in i AWS, kräver den hybridmolnarkitektur som beskrivs ovan: rot-CA:n och dess nyckel finns i en lokal HSM som du kontrollerar, och endast underordnade CA:er finns i AWS Private CA. Den underordnade CA:n inuti AWS Private CA använder fortfarande en KMS-baserad nyckel (som du kan göra till en kundhanterad CMK), men nyckeln på rotnivå ligger helt utanför AWS infrastruktur.

Detta ger den starkaste nyckelsuveräniteten på rot-CA-nivå. AWS kan inte komma åt eller utöva rot-CA-nyckeln under några omständigheter, inklusive juridisk tvång riktad mot AWS. Avvägningen är den ökade operativa komplexiteten i att upprätthålla en lokal rot-CA och latensen i arbetsflödet för signering mellan olika miljöer för underordnade CA-operationer.

Dimensionera	AWS-hanterad KMS-nyckel	Kundhanterad KMS-nyckel (BYOK)	HYOK (lokal rot-CA)
CA-nyckelns plats	AWS KMS (AWS-hanterad)	AWS KMS (kundhanterat)	Rotnyckel: din lokala HSM; Underordnad nyckel: AWS KMS
AWS-åtkomst till rotnyckel	Ja (i drift)	Ja (driftsstyrd, kunden kontrollerar rotation och borttagning)	Nej för rot-CA-nyckel
Oberoende dödsbrytare	Ta bort endast CA (AWS-medierad)	Inaktivera eller ta bort CMK (omedelbar, oberoende)	Återkalla underordnat CA-certifikat från lokal rot (omedelbart)
Kontroll av viktig proveniens	AWS genererar viktigt material	Kunden genererar eller importerar nyckelmaterial	Kunden genererar och innehar rotnyckeln exklusivt
Operationell komplexitet	Låg	Medium	Hög (kräver lokal HSM och ceremoniinfrastruktur)
Bäst för	De flesta AWS-baserade arbetsbelastningar; prioritet för enkel drift	Reglerade sektorer; krav på oberoende nyckelkontroll	Strikta suveränitetsmandat; hemligstämplade eller avskärmade miljöer

IAM-modell för AWS privat CA: Design med lägsta privilegium

AWS Private CA-åtkomstkontroll använder IAM-identitetspolicyer och resursbaserade policyer. Att utforma åtkomst med lägsta behörighet kräver att man separerar de roller som hanterar CA:n från de roller som utfärdar certifikat under den.

CA-administratörsroll: Behöver behörighet för att skapa, uppdatera, tagga och ta bort certifikatutfärdare, samt för att importera certifikatutfärdarcertifikat. Nyckelbehörigheter: acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority, acm-pca:ImportCertificateAuthorityCertificate, acm-pca:TagCertificateAuthorityDenna roll får inte beviljas acm-pca:IssueCertificate att upprätthålla arbetsuppdelning.

Certifikatutfärdarens roll: Behöver behörighet för att utfärda och hämta certifikat och för att konfigurera återkallelse. Nyckelbehörigheter: acm-pca:IssueCertificate, acm-pca:GetCertificate, acm-pca:RevokeCertificate, acm-pca:ListCertificateAuthoritiesDenna roll får inte beviljas behörigheter för hantering av certifikatutfärdare.

Utfärdande av certifikat för flera konton: När en underordnad CA i ett AWS-konto behöver utfärda certifikat för arbetsbelastningar i ett annat AWS-konto, måste en resursbaserad policy på den privata CA:n uttryckligen bevilja acm-pca:IssueCertificate till huvudpersonen i det begärande kontot. Detta är det korrekta mönstret för plattformsteam som driver en delad PKI-tjänst över flera AWS-konton i en AWS-organisationsstruktur.

Integrering av KMS-nyckelpolicy: Om du använder en kundhanterad KMS-nyckel för CA-nyckelskydd måste KMS-nyckelpolicyn ge AWS Private CA-tjänstens huvudperson behörighet att använda nyckeln för kms:Sign Genom att separera KMS-nyckeladministratören (som kan hantera nyckelpolicyn) från KMS-nyckelanvändaren (den privata CA-tjänsten) förhindras att en enskild principal både kontrollerar nyckeln och utfärdar certifikat.

Allmänt läge kontra kortlivat certifikatläge

AWS Private CA har introducerat ett andra driftläge specifikt för högfrekventa certifikatarbetsbelastningar med kort giltighetstid. Att välja rätt läge för varje CA i din hierarki påverkar både kostnad och arkitektur avsevärt.

Allmänt läge (400 USD/CA/månad) stöder certifikatutfärdande med valfri giltighetsperiod, från sekunder till år. Det är lämpligt för traditionella PKI-användningsfall: TLS-servercertifikat, användarautentiseringscertifikat, kodsigneringscertifikat och enhetsidentitetscertifikat med giltighetsperioder på flera år eller flera månader. Det stöder alla certifikatmallar och hela utbudet av nyckelalgoritmer (RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384).

Kortlivat certifikatläge ($50/CA/månad) begränsar certifikatets giltighet till 7 dagar eller färre. Denna begränsning är en funktion för miljöer som använder SPIFFE/SPIRE-liknande arbetsbelastningsidentitet, service mesh mTLS (Istio, Linkerd) eller certifikatbaserade efemära autentiseringsuppgifter där kort giltighet eliminerar behovet av återkallningskontroll helt. Med en åttondel av kostnaden för allmänt läge är kortlivat läge en betydande kostnadsoptimering för högfrekventa, automatiserade certifikatutfärdandemiljöer. Att para ihop en kortlivad CA med ett ACME- eller EST-registreringsprotokoll och en CLM-plattform för certifikatautomation är produktionsarkitekturen för modern molnbaserad PKI.

Vad AWS Private CA kan utfärda: Certifikattyper och användningsfall

AWS Private CA stöder följande certifikattyper genom konfigurerbara mallar som tillämpar korrekt nyckelanvändning och utökade nyckelanvändningstillägg:

• TLS-servercertifikat: Interna webbservrar, API:er och mikrotjänster som kräver HTTPS med privat förtroende. Certifikatet inkluderar TLS Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1) och valideras av klienter som litar på din privata CA-hierarki.
• mTLS-klientcertifikat: Ömsesidig TLS-autentisering mellan tjänster i mikrotjänstarkitekturer och tjänstnät. Båda sidor presenterar certifikat; TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) ingår. Kortlivat certifikatläge är optimalt för mTLS-arbetsbelastningsidentitetscertifikat som förnyas med en cykel under 24 timmar.
• IoT-enhetscertifikat: Tillhandahållande av enhetsidentitet vid tillverkningstid och autentisering av enheter i fält. AWS Private CA integreras med AWS IoT Core för utfärdande av certifikat i stor skala. IEEE 802.1AR IDevID- och LDevID-mönster kan uppnås via API:et.
• Kodsigneringscertifikat: Intern signering av programvaruartefakter för CI/CD-pipelines och distribution av firmware. Kodsignering via AWS Private CA kräver kodsignerings-EKU (OID 1.3.6.1.5.5.7.3.3) och lämpligt nyckelskydd för signeringsnyckeln.
• E-postskydd (S/MIME): Intern krypterad e-post via certifikat med Email Protection EKU (OID 1.3.6.1.5.5.7.3.4). För storskalig S/MIME för företag, Encryption Consultings CertSecure-hanterare tillhandahåller CLM-lagret för registrering och livscykelhantering.
• OCSP-signeringscertifikat: Krävs om du konfigurerar AWS Private CA:s hanterade OCSP-responder. OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) inkluderas automatiskt i OCSP-signeringscertifikat som utfärdas av tjänsten.

OCSP och återkallelse av certifikat i AWS privata CA

AWS Private CA stöder två återkallningsmekanismer som kan aktiveras oberoende av varandra per CA.

Managed OCSP är AWS hostade Online Certificate Status Protocol-responder. När den är aktiverad utfärdar AWS Private CA automatiskt OCSP-signeringscertifikat, publicerar OCSP-responder-URL:en i Authority Information Access (AIA)-tillägget för utfärdade certifikat och svarar på OCSP-frågor om certifikatstatus. Managed OCSP debiterar 0.06 USD per certifikat per månad om OCSP-svar genererades för det certifikatet, plus 0.20 USD per 100 000 OCSP-frågor. För mTLS-miljöer med hög volym där varje anslutning utlöser en OCSP-kontroll ackumuleras dessa kostnader snabbt. Kortlivat certifikatläge undviker OCSP helt, eftersom certifikaten löper ut innan återkallelse blir relevant.

CRL (Certificate Revocation List) är den alternativa återkallningsmekanismen. AWS Private CA kan publicera CRL:er till en Amazon S3-bucket enligt ett konfigurerbart schema. CRL-distribution kräver att S3-bucket är tillgänglig för alla certifikatförlitande parter, vilket vanligtvis innebär att bucket konfigureras för offentlig eller begränsad åtkomst. CRL-kontroll lägger till latens vid anslutningsupprättning motsvarande den tid som krävs för att ladda ner och verifiera CRL:en.

För de flesta privata PKI-distributioner på företag är hanterad OCSP den föredragna återkallningsmekanismen eftersom den ger status i realtid utan att klienter behöver ladda ner och cachelagra potentiellt stora CRL-filer. För miljöer med begränsat giltighet eller mycket känsliga miljöer där utgående OCSP-frågor är oönskade är CRL med en kort giltighetsperiod (daglig eller timvis publicering) det lämpliga alternativet.

Kostnadsfördelning för AWS privat CA

För att förstå den fullständiga kostnaden för AWS Private CA krävs redovisning av CA-drift, certifikatutfärdande, OCSP och KMS-nyckeloperationer som skyddar CA:ns privata nyckel. Den ursprungliga siffran på 400 USD/månad inkluderar endast CA-driftskostnaden för generellt läge.

Kostnadskomponent	Allmänt läge	Kortlivat certifikatläge
CA-operation (per CA per månad)	$400	$50
Certifikat 1 001 till 10 000 (per intyg)	$0.75	0.058 dollar (fast pris)
Certifikat 1 001 till 10 000 (per intyg)	$0.35	0.058 dollar (fast pris)
Certifikat 10 001 och högre (per certifikat)	$0.001	0.058 dollar (fast pris)
OCSP (per certifikat per månad, om det efterfrågas)	$0.06	Ej tillämpligt (certifikat upphör att gälla innan OCSP behövs)
OCSP-frågor (per 100 000)	$0.20	-
fri rättegång	30 dagar för första CA per konto per region (endast CA-drift; certifikatavgifter tillkommer fortfarande)	30 dagar för första CA per konto per region

För ett praktiskt exempel: en hierarki med två CA-enheter (rot-CA plus en utfärdande CA) i generellt läge som utfärdar 2 000 certifikat per månad med OCSP aktiverat kostar cirka 800 USD (CA-drift) plus 1 025 USD i certifikatavgifter (1 000 x 0.75 USD plus 1 000 x 0.35 USD) plus OCSP-kostnader (2 000 x 0.06 USD = 120 USD), totalt cirka 1 945 USD per månad före KMS-avgifter. CA-spridning, där varje miljö får sin egen underordnade CA, multiplicerar CA-driftsavgiften på 400 USD/månad över alla CA:er. Att konsolidera miljöer under en enda underordnad CA där säkerhetspolicyn tillåter minskar kostnaderna avsevärt.

För den aktuella prissidan, se aws.amazon.com/private-ca/pricing/.

Integrering av certifikatlivscykelhantering

AWS Private CA tillhandahåller CA-infrastrukturen, men certifikatlivscykelhantering (CLM) kräver ytterligare verktyg. Eftersom CA/B Forum SC-081v3 minskar den maximala giltighetstiden för publika TLS-certifikat till 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029, är automatisk förnyelse inte längre valfri, inte ens för privata certifikat som fungerar tillsammans med publika certifikat.

AWS Private CA integreras direkt med flera registreringsmekanismer:

• Integrering med AWS Certificate Manager: ACM kan använda en privat CA som utfärdande CA för certifikat som automatiskt distribueras till ACM-integrerade tjänster. Detta ger dig privat förtroende med ACM:s hanterade förnyelse- och distributionsautomation.
• ACME-protokoll: AWS Private CA Connector för ACME (släppt 2023) låter ACME-kompatibla klienter (cert-manager, certbot, acme.sh) begära certifikat från din privata CA med hjälp av standardprotokollet ACME. Detta är rätt integrationsväg för Kubernetes-native certifikatautomation och DevOps-verktygskedjor.
• Active Directory (AD CS)-integration: AWS Private CA Connector för Active Directory integreras med Microsoft AD-anslutna Windows-miljöer, vilket gör det möjligt för domänanslutna maskiner och användare att ta emot certifikat från AWS Private CA via de välbekanta registreringsmekanismerna för AD Certificate Services (automatisk registrering, SCEP).
• Direkt API och SDK: AWS Private CA API stöder programmatisk certifikatutfärdande via SDK:et på alla språk som AWS stöder, vilket möjliggör anpassade registreringsarbetsflöden för icke-standardiserade system.

För organisationer som hanterar certifikat över AWS Private CA och andra CA-källor (Microsoft AD CS, lokala PKI, molnleverantörs-CA:er) tillhandahåller Encryption Consultings CertSecure Manager CA-agnostisk enhetlig certifikatidentifiering, livscykelautomation och utgångsövervakning över alla källor. AWS Private CA-volymerna bör inkluderas i alla företags-CLM-inventeringar.

Multimoln- och hybrid-PKI-arkitektur

Organisationer som använder AWS Private CA tillsammans med Azure, GCP eller lokala miljöer står inför samma problem med molnöverskridande konsistens som med alla molnbaserade nyckelhanteringstjänster: AWS Private CA är AWS-specifik. Certifikat som utfärdas är betrodda av system som litar på din privata CA-hierarki, men CA-hanteringsplanet, revisionsspåret och livscykelautomationen är AWS-nativa och utökas inte automatiskt till andra moln.

Tre mönster åtgärdar detta för PKI i flera moln:

• Enkel AWS Private CA-hierarki som företagsrot: Alla miljöer (AWS, Azure, GCP, lokala) litar på samma rot-CA som finns i AWS Private CA. Underordnade CA:er utfärdar certifikat för varje miljö. Distribution av molnbaserade certifikat hanteras genom att rot-CA-certifikatet distribueras till alla systems förtroendelagrar. Detta är den enklaste modellen för organisationer som huvudsakligen är AWS-baserade och behandlar andra miljöer som satellitdistributioner.
• Lokal rot-CA med underordnade moln-CA:er: En lokal rot-CA signerar underordnade CA-certifikat för AWS privata CA (för AWS-arbetsbelastningar), Azure-baserade underordnade CA:er (för Azure-arbetsbelastningar) och andra molnmiljöer. Alla underordnade CA:er delar samma förtroenderot men fungerar oberoende inom sina respektive molnplattformar. Detta är hybridmolnmodellen utökad till flera moln. Den lokala rot-CA:n är det ultimata förtroendeankaret.
• CLM-enhetlig multi-CA-egendom: Varje moln använder sin egen CA-tjänst (AWS Private CA för AWS, Azure Active Directory Certificate Services eller Azure-integrerade CA:er för Azure, GCP Certificate Authority Service för GCP), och en moln-agnostisk CLM-plattform aggregerar certifikatinventeringen, övervakar utgångsdatum och tillämpar rotationspolicy över alla källor. Detta undviker komplexitet i CA-hierarkin mellan molnen på bekostnad av att kräva en CLM-plattform som kan integreras med flera CA-API:er. Encryption Consultings CertSecure-hanterare integreras med AWS Private CA och andra CA-källor för att tillhandahålla detta enhetliga synlighetslager.

Bästa praxis för ACM Private CA

1. Utforma din CA-hierarki innan du etablerar: Bestäm hur många CA-nivåer du behöver (två nivåer rekommenderas för de flesta företag: rot-CA plus utfärdande CA per miljö), hur många underordnade CA:er du ska skapa och vilka miljöer som delar en utfärdande CA kontra att skaffa dedikerade CA:er. CA-spridning mångdubblar dina månatliga CA-driftskostnader och komplicerar återkallelse.
2. Dokumentera er certifikatpolicy och era rutiner: Definiera maximala giltighetsperioder per certifikattyp, tillåtna nyckelalgoritmer och storlekar, tillåten utökad nyckelanvändning per certifikatmall och godkännandearbetsflödet för varje certifikatkategori. AWS Private CA tillämpar dessa genom mallar och API-kontroller; policydokumentet är vad revisorer granskar.
3. Använd kundhanterade KMS-nycklar för CA-nyckelskydd: Standard AWS-hanterade nycklar fungerar men ger dig mindre kontroll. Kundhanterade nycklar ger en oberoende inaktiverings-/borttagningsfunktion och en tydligare revisionslogg för nyckelåtgärder i CloudTrail.
4. Aktivera CloudTrail för all privat CA API-aktivitet: Varje certifikatutfärdande, återkallelse, CA-skapande och CA-konfigurationsändring genererar en CloudTrail-händelse. Dirigera dessa till en SIEM och konfigurera aviseringar för certifikatutfärdande från oväntade principaler, CA-borttagningsbegäranden och KMS-nyckelinaktiveringshändelser för nycklar som skyddar CA:s privata nycklar.
5. Automatisera certifikatförnyelse före utgångsdatum: AWS Private CA förnyar inte automatiskt de certifikat som utfärdas (till skillnad från ACM för publika certifikat). Använd ACME-anslutningen, ACM-integrationen eller en CLM-plattform för att automatisera förnyelsen. Vid 47 dagars certifikatgiltighet (gäller från och med mars 2029 för publika certifikat) är manuell förnyelse operativt omöjlig. Bygg automatiseringen nu.
6. Separata CA-administratörs- och certifikatutfärdar-IAM-roller: Ingen enskild IAM-principal bör ha både behörigheter för CA-hantering och behörigheter för certifikatutfärdande. Konfigurera separata roller och, för känsliga CA:er, kräv MFA för alla CA-hanteringsåtgärder.
7. Låt rot-CA:n vara inaktiv när den inte används: Om din rot-CA i AWS Private CA inte behöver utfärda underordnade CA-certifikat regelbundet, inaktivera den efter den initiala hierarkin. En inaktiverad rot-CA kan inte användas för att utfärda certifikat, vilket minskar attackytan. Återaktivera den endast vid förnyelse eller hierarkiändringar av underordnade CA.
8. Plan för distribution i flera regioner: AWS Private CA är en regional tjänst. Om din certifikattillgång sträcker sig över flera AWS-regioner, skapa underordnade CA:er i varje region där certifikatutfärdandefördröjningen är viktig. Rot-CA:n kan finnas kvar i en region; underordnade CA:er i andra regioner debiteras var och en sin egen CA-driftsavgift på 400 USD/månad (eller 50 USD/månad).

Delat ansvar i AWS privata CA

AWS Private CA arbetar enligt AWS modell för delat ansvar, med en tydlig uppdelning av vad AWS äger och vad kunden äger.

AWS-ägda ansvarsområden inkluderar den fysiska säkerheten för datacentren som är värd för de KMS HSM:er som skyddar CA-nycklar, tillgängligheten och hållbarheten för själva AWS Private CA-tjänsten, FIPS 140-2 Level 3-valideringen av de HSM:er som skyddar KMS-hanterade nycklar, automatisk replikering av CA-konfiguration och nycklar över tillgänglighetszoner inom en region, säkerheten för den hanterade OCSP-responderinfrastrukturen samt patchning och underhåll av den underliggande tjänstinfrastrukturen.

Kundägda ansvarsområden inkluderar beslut om hierarkidesign för CA, konfiguration av IAM-policyer (vem som kan utfärda certifikat, vem som kan hantera CA:er), val av KMS-nyckeltyp (AWS-hanterad kontra kundhanterad), val och konfiguration av certifikatmall för varje CA, konfiguration av återkallelse (OCSP-aktivering, CRL S3-bucketåtkomst), övervaknings- och aviseringskonfiguration för certifikathändelser, automatisering av certifikatförnyelse, distribution av det privata CA-rotcertifikatet till alla förlitande parters förtroendelager samt dokumentation om certifikatpolicy och certifieringspraxis som krävs för efterlevnadsprogram.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi och molnsäkerhet med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att designa, implementera och styra AWS Private CA-distributioner från initial hierarkidesign till automatisering av certifikatlivscykeln och insamling av efterlevnadsbevis.

• PKI som en tjänst: För organisationer som vill ha hanterad PKI utan den operativa komplexiteten att själva köra AWS Private CA, erbjuder Encryption Consultings PKI som en tjänst tillhandahåller en helt hanterad privat CA med FIPS-validerat HSM-nyckelskydd, facilitering av rot-CA-ceremonier, CP/CPS-dokumentation och övervakning dygnet runt. Vi kan integrera med AWS-arbetsbelastningar samtidigt som vi besparar ditt team den operativa bördan på CA:n.
• CertSecure-chef (CLM): AWS Private CA tillhandahåller CA-infrastruktur men inte livscykelhantering för de certifikat som utfärdas. Encryption Consultings CertSecure-hanterare tillhandahåller certifikatidentifiering, övervakning av utgångsdatum, automatisering av förnyelser via ACME och EST, och enhetlig certifikatinventering över AWS Private CA, Microsoft AD CS och andra CA-källor. I takt med att CA/B Forum SC-081v3 komprimerar certifikatgiltigheten till 47 dagar blir automatiserad CLM avgörande.
• PKI-tjänster och rådgivning: Om du utformar en CA-hierarki för AWS Private CA, utvärderar avvägningarna mellan privata moln och hybridmoln, eller behöver en certifikatpolicy och ett CPS-dokument för en efterlevnadsgranskning, är Encryption Consultings... PKI-tjänster täcker design av CA-hierarki, facilitering av nyckelceremonier för hybriddistributioner och CP/CPS-utveckling för alla PKI-efterlevnadsramverk (NIST, WebTrust, ETSI).
• HSM som en tjänst: För hybriddistributioner som kräver en lokal rot-CA som backas upp av en dedikerad FIPS-validerad HSM, Encryption Consultings HSM som en tjänst tillhandahåller den hanterade HSM-infrastrukturen för din rot-CA-nyckel utan kapitalutgifter för HSM-hårdvara.
• CBOM-säker: AWS Private CA-distributioner som har vuxit organiskt innehåller ofta fler CA:er, certifikat och nyckeltyper än vad säkerhetsteam kan spåra manuellt. Encryption Consultings CBOM-säkerhet upptäcker och inventerar alla kryptografiska tillgångar i din AWS-miljö, inklusive AWS Private CA-utfärdade certifikat, KMS-nycklar och ACM-certifikat, och genererar en kryptografisk materiallista (CBOM) i CycloneDX-format för efterlevnad och revision.
• PQC-beredskap: NIST slutförde postkvantkryptografistandarderna FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. NIST IR 8547 pekar mot att RSA och ECC avskrivs för nya användningsområden runt 2030. Om er AWS Private CA-hierarki använder RSA- eller ECDSA CA-nycklar idag, bör migreringsplaneringen börja nu. Encryption Consultings PQC-beredskap Tjänsten utvärderar din AWS Private CA-hierarki mot tidslinjen efter kvantmigreringen och utformar algoritmens övergångsväg.

För att diskutera din AWS Private CA-design, CLM-automatisering eller efterlevnadskrav, kontakta Encryption Consulting.

Slutsats

AWS Private CA eliminerar hårdvaruanskaffning, datacenterbehov och den operativa komplexiteten i att driva en privat certifikatutfärdare, samtidigt som alla viktiga säkerhetskontroller bevaras: val av nyckelalgoritm, hierarkidesign för CA, IAM-förstärkt rollseparation, KMS-baserat nyckelskydd med kundkontroll och en komplett CloudTrail-granskningslogg för varje certifikatoperation.

De viktigaste besluten som avgör om en AWS Private CA-distribution är säker, kostnadseffektiv och granskningsbar är inte standardvärden: hierarkimodellen för privat moln kontra hybridmoln, KMS-nyckeltypen (AWS-hanterad kontra kundhanterad BYOK), driftsläget (allmänt bruk för 400 USD/CA/månad kontra kortlivad för 50 USD/CA/månad för certifikat under 7 dagar), IAM-rollseparationen mellan CA-administratörer och certifikatutfärdare, och CLM-automatiseringslagret som hanterar förnyelse när certifikatgiltighetsperioderna krymper mot 47 dagar.

Organisationer som migrerar från lokala PKI till AWS Private CA bör behandla det som en möjlighet till PKI-omdesign, inte en "lift-and-shift". Hybridmolnmodellen bevarar rot-CA:ns nyckelsuveränitet samtidigt som den får molnoperativa fördelar för certifikatutfärdande. BYOK med kundhanterade KMS-nycklar tillhandahåller en oberoende kill switch och nyckelproveniens som granskare kan verifiera. Kortlivat certifikatläge till en åttondel av CA:ns driftskostnad är rätt arkitektur för alla användningsfall av högfrekventa mTLS eller arbetsbelastningsidentitet.

Vanliga frågor om partihandel med mat och dryck

Vad är AWS Private CA och hur skiljer det sig från AWS Certificate Manager (ACM)?

AWS Private CA (tidigare ACM Private CA) är en hanterad privat certifikatutfärdartjänst för att utfärda privat betrodda X.509-certifikat för interna arbetsbelastningar. AWS Certificate Manager (ACM) tillhandahåller kostnadsfria offentliga TLS-certifikat för användning med ACM-integrerade AWS-tjänster. ACM-certifikat kan inte exporteras; Privata CA-certifikat kan exporteras med sin privata nyckel för användning var som helst. ACM-certifikat är offentligt betrodda; Privata CA-certifikat är endast betrodda av system som du konfigurerar för att lita på din CA-hierarki.

Vad är skillnaden mellan privata moln- och hybridmolnmodeller i AWS Private CA?

I den privata molnmodellen finns både rot- och underordnade certifikatutfärdare (CA) inuti AWS Private CA, med nycklar i AWS KMS. I Hybrid Cloud-modellen finns rot-CA:n lokalt i en HSM som du kontrollerar, och endast underordnade certifikatutfärdare finns i AWS Private CA. Hybridmodellen ger dig direkt hantering av rot-CA-nyckeln; den privata molnmodellen tillhandahåller fullständig molnautomation utan krav på lokal infrastruktur.

Hur mycket kostar AWS Private CA per månad?

AWS Private CA debiterar 400 USD per CA per månad för allmänt läge och 50 USD per CA per månad för kortlivat certifikatläge (certifikat är giltiga i 7 dagar eller färre). Certifikatutfärdandet är nivåindelat: 0.75 USD per CA för de första 1 000, 0.35 USD per CA för 1 001 till 10 000 och 0.001 USD per region per månad för allmänna CA:er. Kortlivade certifikat kostar oförändrat 0.058 USD per certifikat. OCSP lägger till 0.06 USD per certifikat per månad vid förfrågan, plus 0.20 USD per 100 000 förfrågningar. AWS erbjuder en 30-dagars gratis provperiod på CA-drift för den första privata CA:n per konto per region.

Stöder AWS Private CA BYOK (Bring Your Own Key)?

Ja. AWS Private CA använder AWS KMS för att skydda CA-nycklar. Som standard använder den AWS-hanterade KMS-nycklar. Du kan ange en kundhanterad KMS-nyckel (med importerat nyckelmaterial) när du skapar CA:n. Med importerat nyckelmaterial behåller du källnyckeln och kan ta bort den från KMS för att omedelbart förhindra att CA:n signerar nya certifikat. True HYOK (där CA-nyckeln aldrig kommer in i AWS på någon nivå) kräver en hybridmolnarkitektur med en lokal rot-CA.

Vilka IAM-behörigheter kräver AWS Private CA?

CA-administratörer behöver acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority och acm-pca:ImportCertificateAuthorityCertificate. Certifikatutfärdare behöver acm-pca:IssueCertificate, acm-pca:GetCertificate och acm-pca:RevokeCertificate. Dessa roller bör vara separata: ingen enskild principal bör ha både behörigheter för CA-hantering och certifikatutfärdande. Utfärdande över flera konton kräver en resursbaserad policy för den privata CA som beviljar IssueCertificate till den begärande kontoprincipalen.

Vilka certifikattyper kan AWS Private CA utfärda?

AWS Private CA kan utfärda X.509-certifikat för TLS-serverautentisering, TLS-klientautentisering (mTLS), kodsignering, e-postskydd (S/MIME), OCSP-signering och anpassade applikationsspecifika användningar. Den stöder nyckelalgoritmerna RSA 2048, RSA 4096, ECDSA P-256 och ECDSA P-384. Certifikatmallar tillämpar tillåtna nyckelanvändningar och utökade nyckelanvändningar för varje certifikattyp, vilket förhindrar utfärdande av certifikattyper som inte definieras i mallen.