Molnbaserad certifikathantering

Molnbaserad certifikathantering är praxisen att upptäcka, utfärda, förnya, återkalla och granska digitala certifikat över molninfrastruktur, containrar och hybridmiljöer från en centraliserad plattform. Detta är viktigt eftersom molnmiljöer genererar certifikat i en skala och hastighet som manuell spårning inte kan hålla jämna steg med, och ett enda utgånget certifikat i en lastbalanserare eller API-gateway orsakar ett fullständigt serviceavbrott. Den rekommenderade åtgärden är att distribuera en centraliserad plattform för certifikatlivscykelhantering (CLM) med automatiserad ACME-baserad förnyelse innan CA/Browser Forums SC-081v3-schema minskar TLS-certifikatets giltighetstid till 47 dagar senast i mars 2029.

Snabbt svar: Vad kräver molnbaserad certifikathantering?

Molnbaserad certifikathantering kräver fyra funktioner som arbetar tillsammans: kontinuerlig identifiering av alla certifikat över varje molnkonto, region och tjänst så att inget certifikat är osynligt för säkerhetsteamet; automatiserad förnyelse via ACME eller molnbaserade API:er innan certifikaten löper ut; skydd av privata nycklar i hårdvarubaserade nyckellagrar snarare än i applikationskonfiguration eller miljövariabler; och en centraliserad granskningslogg för varje utfärdande, förnyelse och återkallelsehändelse kopplad till en autentiserad identitet. Var och en av dessa är nödvändig oberoende av varandra; ingen är tillräcklig ensam.

Key Takeaways

• Certifikatspridning är den primära risken för moln-CLM: Molnautomatisk skalning, containrar och mikrotjänster genererar certifikat programmatiskt, ofta utan IT-insyn. De flesta organisationer upptäcker att de har tre till fem gånger fler certifikat än de trodde när de kör en fullständig molnidentifieringsskanning.
• Kortare giltighetsfrister gör automatisering obligatorisk: CA/Browser Forum SC-081v3-schemat minskar den maximala giltighetstiden för TLS-certifikat till 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029. Vid 47 dagars giltighetstid är manuell förnyelse operativt omöjlig i någon meningsfull skala.
• Inbyggt molnbaserat CLM och tredjeparts-CLM har olika omfattningar: Inbyggda tjänster (AWS Certificate Manager, Azure App Service-certifikat, GCP Certificate Manager) automatiserar förnyelse inom en molnleverantörs ekosystem. Tredjeparts CLM-plattformar ger enhetlig insyn och policytillämpning över alla molnleverantörer, lokala system och certifikattyper.
• Skydd av privata nycklar är lika viktigt som certifikatförnyelse: En automatiserad förnyelseprocess som lagrar den nya privata nyckeln i klartext i en miljövariabel eller konfigurationsfil skapar en sämre säkerhetsställning än det utgångna certifikatet som den ersatte.
• Regelverk för efterlevnad kräver nu uttryckligen certifikatstyrning: PCI DSS v4.0.1 (obligatorisk mars 2025), DORA (gäller från och med januari 2025), HIPAA, FedRAMP och GDPR kräver alla dokumenterade kontroller av certifikatens livscykel, inte bara kryptering under överföring.

Vad är molnbaserad certifikathantering?

Ett digitalt certifikat är en kryptografisk autentiseringsuppgift som binder en offentlig nyckel till en identitet (ett domännamn, en tjänst, en enhet eller en person) och signeras av en certifikatutfärdare (CA) för att göra den bindningen trovärdig för förlitande parter. TLS/SSL-certifikat är den vanligaste typen i molnmiljöer: de autentiserar webbservrar, API-slutpunkter, lastbalanserare och interna mikrotjänster till klienter, och de krypterar anslutningen mellan dem.

Molnbaserad certifikathantering täcker hela livscykeln för dessa certifikat i molnmiljöer: identifiering (hitta alla certifikat i varje molnkonto och region), utfärdande (begäran av certifikat från en offentlig eller privat certifikatutfärdare), distribution (installation av certifikat på rätt slutpunkter), förnyelse (ersättning av certifikat innan de löper ut), återkallelse (ogiltigförklaring av komprometterade eller inaktiverade certifikat) och granskning (loggning av varje livscykelhändelse för att bevisa efterlevnad). Att hantera denna livscykel manuellt via kalkylblad och kalenderpåminnelser misslyckas i molnmiljöer där certifikaten antalet är tusentals och deras giltighetsperioder förkortas till mot 47 dagar.

Varför molnmiljöer gör certifikathantering svårare

Lokala miljöer har vanligtvis en begränsad, relativt statisk inventering av servrar och tjänster, där var och en kör certifikat med giltighetsperioder på ett till två år. Molnmiljöer skiljer sig fundamentalt åt på fyra sätt som vart och ett förvärrar problemet med certifikathantering.

Skalning och hastighet: Autoskalningsgrupper, containerorkestreringsplattformar (Kubernetes), serverlösa funktioner och mikrotjänstdistributioner genererar och konsumerar certifikat programmatiskt. Ett enda Kubernetes-kluster kan köra hundratals poddar, var och en med sitt eget tjänstcertifikat, där poddar skapas och förstörs kontinuerligt. Certifikatinventeringen i en molnmiljö förändras snabbare än någon manuell process kan spåra.

Distribuerat ägande: I molnmiljöer tillhandahålls certifikat av applikationsteam, DevOps-pipelines, plattformsteknikteam och ibland enskilda utvecklare, ofta utan central IT-inblandning. Detta skapar skuggcertifikatinventarier som säkerhetsteamet inte kan se, vilket innebär att certifikat löper ut utan förvarning och privata nycklar lagras osäkert i applikationsdatabaser.

Multimoln- och hybridkomplexitet: De flesta företag kör arbetsbelastningar över AWS, Azure och GCP samtidigt, tillsammans med lokal infrastruktur. Varje molnleverantör har sina egna inbyggda certifikattjänster med olika API:er, olika certifikattyper och olika förnyelsemekanismer. Att hantera certifikatpolicyn konsekvent i detta landskap kräver ett hanteringslager ovanför de enskilda molnleverantörerna.

Krympande giltighetsfönster: CA/Browser Forum Ballot SC-081v3 minskar den maximala giltigheten för offentligt betrodda TLS-certifikat i ett stegvis schema: 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. Vid 47 dagars giltighet måste varje certifikat i en stor molnmiljö förnyas ungefär åtta gånger per år. Detta gör automatiserad förnyelse inte till bästa praxis utan till en operativ nödvändighet.

Native Cloud CLM kontra tredjeparts CLM-plattform: Vad varje plattform täcker

Varje större molnleverantör erbjuder en inbyggd certifikathanteringstjänst. Det är viktigt att förstå vad varje tjänst täcker och var den slutar innan man väljer en CLM-strategi.

AWS Certificate Manager (ACM): Utfärdar och förnyar automatiskt publika TLS-certifikat för AWS-resurser (Elastic Load Balancers, CloudFront-distributioner, API Gateway, Elastic Beanstalk). Privata nycklar hanteras av AWS i HSM-baserad lagring och exponeras aldrig; du kan inte exportera dem. ACM stöder också ett privat CA-tillägg för att utfärda privata certifikat. ACM hanterar inte certifikat på icke-AWS-infrastruktur, ger inte insyn i certifikat som distribuerats direkt till EC2-instanser och hanterar inte certifikat från tredjeparts-CA:er utanför ACM-ekosystemet.

Azure Key Vault-certifikat: Lagrar, hanterar och förnyar automatiskt certifikat i Azure Key Vault, med integration med Azure-tjänster (App Service, Application Gateway, Front Door). Stöder certifikat från DigiCert och GlobalSign via Key Vaults CA-partnerintegrationer och stöder import av certifikat från andra CA:er. Azure Key Vault hanterar inte certifikat i AWS- eller GCP-miljöer, och insyn i certifikat utanför Key Vault kräver ytterligare verktyg.

GCP Certificate Manager: Hanterar SSL-certifikat för Google Cloud-belastningsutjämnare och Cloud CDN, med ACME-baserad automatisk förnyelse för Google-hanterade certifikat. GCP Certificate Authority Service (CAS) tillhandahåller en hanterad privat CA för att utfärda interna certifikat. GCP Certificate Manager hanterar inte certifikat i miljöer som inte är GCP.

Omfattningsbegränsningen för varje native tjänst är densamma: den hanterar certifikat inom sin egen molnleverantörs ekosystem. En organisation som kör arbetsbelastningar över alla tre leverantörer har tre separata certifikatsilos utan enhetlig inventering, ingen konsekvent policytillämpning och ingen gemensam granskningslogg.

Capability	Native Cloud CLM (per leverantör)	Tredjeparts CLM-plattform
Omfattning av certifikatidentifiering	Endast inom en molnleverantör	Alla molnleverantörer, lokalt, SaaS
Hanterade certifikattyper	TLS för den leverantörens resurser	TLS, kodsignering, S/MIME, enhet, SSH
CA-integrationer	Leverantörens egen CA (och kommanditdelägare)	Alla offentliga CA, alla privata CA, ACME
Automatiserad förnyelse	Ja (inom den leverantören)	Ja (för alla leverantörer via ACME/API)
Enhetlig policytillämpning	Nej (endast per leverantör)	Ja (enda policy för alla miljöer)
Centraliserad granskningslogg	Nej (endast loggar per leverantör)	Ja (en enda revisionslogg för efterlevnad)
Synlighet för privat nyckel	Hanteras av leverantör (kan inte exporteras i ACM)	Konfigurerbar; HSM-stödda alternativ tillgängliga
Bäst för	Enkelt moln, enkla arbetsbelastningar	Multimoln, reglerade, storskaliga fastigheter

Skydd av privata nycklar i molncertifikathantering

Att en privat nyckel komprometteras är en allvarligare säkerhetshändelse än att certifikatet löper ut. Ett utgånget certifikat orsakar ett avbrott; en komprometterad privat nyckel kan göra det möjligt för en angripare att utge sig för att vara din tjänst, dekryptera historisk trafik eller signera skadligt innehåll. Molnmiljöer skapar flera risker för exponering av privata nycklar som lokala distributioner vanligtvis inte står inför.

De vanligaste molnexponeringsvektorerna för privata nycklar är: privata nycklar som lagras i klartext i programkonfigurationsfiler eller miljövariabler som är synliga i versionskontroll; privata nycklar som ingår i containeravbildningar som skickas till offentliga eller delade register; privata nycklar som lagras i S3-buckets, Azure Blob-containrar eller GCS-buckets med alltför tillåtande åtkomstprinciper; och privata nycklar i CI/CD-pipelinehemligheter som är tillgängliga för alla pipelines i en databas utan omfångsbegränsning.

Den korrekta arkitekturen för skydd av privata nycklar i molnmiljöer beror på om den privata nyckeln behöver vara tillgänglig för applikationen vid körning eller inte.

Nycklar som hanteras av moln-CLM-tjänsten (inte tillgängliga för programmet): För TLS-certifikat på lastutjämnare, API-gatewayer och CDN-slutpunkter, använd molnleverantörens inbyggda certifikathanteringstjänst. AWS ACM, Azure Key Vault Certificate integration och GCP Certificate Manager lagrar privata nycklar i HSM-baserad infrastruktur och presenterar certifikatet för tjänsten utan att exponera den privata nyckeln för programmet eller för någon IAM-principal. Detta är den säkraste modellen och bör användas överallt där programmet inte behöver direkt nyckelåtkomst.

Nycklar som är tillgängliga för programmet vid körning: För ömsesidig TLS (mTLS) mellan tjänster, kodsignering eller certifikattyper där programmet måste utföra kryptografiska operationer direkt, lagra den privata nyckeln i en molnhemlighetshanterare (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Rotera hemligheten enligt samma schema som certifikatförnyelsen. Lagra aldrig nyckeln som en Kubernetes-hemlighet i klartext-YAML; använd en extern hemlighetsoperator för att injicera den från hemlighetshanteraren vid podstart.

För de högsta kraven på nyckelskydd (FIPS 140-2 nivå 3, FedRAMP High eller klassificerade arbetsbelastningar), använd en dedikerad Hardware Security Module (HSM) för att generera och lagra privata nycklar. Molnleverantörer erbjuder HSM-baserad nyckellagring via AWS CloudHSM, Azure Dedicated HSM och GCP Cloud HSM, och Encryption Consultings HSM as a Service tillhandahåller dedikerad FIPS 140-2 nivå 3 HSM-infrastruktur som integreras med arbetsflöden för molncertifikathantering.

IAM-modell för molncertifikathantering

Åtkomstkontroll för molncertifikathantering bör tillämpa minsta möjliga behörighet på tre nivåer, vilket separerar vem som kan utfärda certifikat, vem som kan komma åt privata nycklar och vem som kan hantera själva CLM-plattformen.

Certifikatutgivningsbehörigheter: Endast auktoriserade identiteter (applikationsdistributionspipelines, CLM-tjänstkonton eller godkända DevOps-roller) ska kunna begära certifikatutfärdande från CA. I AWS ACM innebär detta att IAM-policyer beviljar acm:RequestCertificate endast till specifika roller. I Azure Key Vault innebär detta att rollen Key Vault Certificates Officer tilldelas specifika tjänstens huvudnamn. Utvecklare och programkörningsroller bör inte ha behörighet att utfärda certifikat.

Åtkomstbehörigheter för privata nycklar: Åtkomst till privata nycklar som lagras i hemlighetshanterare eller Key Vault bör begränsas till den specifika applikationsidentitet som behöver nyckeln, med hjälp av behörigheter på resursnivå snarare än bred läsåtkomst för hemlighetshanteraren. Använd resursprinciper för hemlighetshanteraren i AWS för att begränsa secretsmanager:GetSecretValue till programmets specifika IAM-roll. I Azure, använd Key Vault-åtkomstprinciper eller RBAC för att bevilja Key Vault Secrets User endast till applikationens specifika hanterade identitet.

CLM-plattformsadministration: Möjligheten att konfigurera CA-integrationer, ställa in certifikatpolicyer, godkänna utfärdande för känsliga certifikattyper och komma åt CLM-granskningsloggen bör kräva en separat, granskad CLM-administratörsroll som är skild från de roller som används av applikationspipelines. Inget CI/CD-tjänstkonto bör ha CLM-administratörsbehörigheter. Tillämpa MFA för all CLM-administratörsåtkomst.

ACME Automation: Så fungerar automatiserad certifikatförnyelse i molnet

ACME (Automatic Certificate Management Environment) är ett IETF-protokoll definierat i RFC 8555 som automatiserar utfärdandet och förnyelsen av certifikat. En ACME-klient bevisar för en ACME-kompatibel CA att den kontrollerar en domän (eller, för IP-certifikat, en IP-adress) genom en av flera utmaningstyper och tar sedan emot ett signerat certifikat utan mänsklig inblandning. ACME är protokollet bakom Let's Encrypts kostnadsfria offentliga certifikatutfärdande och stöds av ett ökande antal företags-CA:er.

I molnmiljöer arbetar ACME genom tre primära utmaningstyper:

• HTTP-01-utmaning: ACME-klienten placerar en token på en välkänd HTTP-URL på domänen som valideras. CA hämtar URL:en och verifierar token. Detta fungerar för internetåtkomliga slutpunkter men inte för interna tjänster eller jokerteckencertifikat.
• DNS-01-utmaning: ACME-klienten skapar en TXT-post i DNS-zonen för domänen som valideras. CA:n frågar DNS för att verifiera posten. Detta fungerar för jokerteckenscertifikat och för interna tjänster där HTTP-validering inte är möjlig. Moln-DNS-leverantörer (Route 53, Azure DNS, Cloud DNS) stöder alla skapande av programmatisk DNS-post, vilket gör DNS-01 till den föredragna utmaningstypen för molnautomation.
• TLS-ALPN-01-utmaning: ACME-klienten svarar på en TLS-handskakning på port 443 med ett särskilt certifikat som innehåller valideringstoken. Detta används mindre vanligt i molnmiljöer på grund av lastbalanserarens komplexitet.

En ACME-distribution i produktion för hantering av molncertifikat kör ACME-klientagenter (som Certbot, acme.sh eller en CLM-plattforms inbyggda ACME-klient) enligt ett schema som förnyar certifikat när de når cirka 30 dagars återstående giltighetstid. Med SC-081v3-schemat som går över till 47-dagars certifikat i mars 2029, innebär förnyelse vid 30 dagars återstående giltighetstid att certifikat förnyas var 17:e dag, vilket kräver helt automatiserad förnyelse utan något mänskligt godkännandesteg i den kritiska vägen.

När man ska använda en privat CA i molnmiljöer

Inte alla certifikat i en molnmiljö behöver utfärdas av en offentlig CA. Offentligt betrodda certifikat krävs för alla slutpunkter som tar emot anslutningar från webbläsare eller operativsystem som litar på det offentliga rotarkivet. Intern tjänst-till-tjänst-kommunikation (mikrotjänst mTLS, Kubernetes interna tjänster, API-anrop mellan backend-tjänster), utvecklarverktyg och IoT-enhetsidentitet kan använda certifikat från en privat CA, vilket ger flera fördelar jämfört med offentliga CA-certifikat för dessa användningsfall.

Privata CA-certifikat omfattas inte av CA/Browser Forum-giltighetsbegränsningarna som styr publika certifikat. Du kan utfärda interna certifikat med giltighetsperioder som matchar din distributionscykel. Privata CA:er ger dig full kontroll över certifikatprofilen: du kan inkludera anpassade tillägg, alternativa ämnesnamn för interna DNS-namn och IP-adresser samt värden för utökad nyckelanvändning som är specifika för din applikation (t.ex. clientAuth för mTLS). Utfärdande av privata CA:er är också snabbare och kräver inte domänvalidering mot extern DNS.

Molnbaserade privata CA-alternativ inkluderar AWS Private CA (tidigare ACM Private CA), som tar 400 dollar per CA per månad för en generell CA eller 50 dollar per CA per månad för en kortlivad certifikat-CA, och GCP Certificate Authority Service (CAS), som tillhandahåller en hanterad privat CA med molnbaserad HSM-baserad CA-nyckellagring. För organisationer som behöver en privat CA som spänner över flera molnleverantörer eller integreras med lokala PKI, tillhandahåller Encryption Consultings PKI as a Service en hanterad privat CA med ACME-stöd, AD Connector för Windows-miljöer och integration med alla större molnplattformar.

Granskningsloggning för molncertifikathantering

En komplett granskningslogg för certifikathantering kräver två loggströmmar: händelser i certifikatets livscykel och händelser för åtkomst till privata nycklar. Regelverk för efterlevnad, inklusive PCI DSS v4.0.1, FedRAMP (NIST SP 800-53 AU-kontroller) och DORA, kräver alla dokumenterade bevis på styrning av certifikatets livscykel.

Certifikatets livscykelloggar registrera varje utfärdande-, förnyelse-, återkallelse- och distributionshändelse. På AWS visas ACM-certifikathändelser i AWS CloudTrail under acm: händelsenamnrymd. På Azure loggas Key Vault-certifikatåtgärder i Azure Monitor-diagnostikloggar. På GCP visas Certificate Manager- och CAS-åtgärder i molngranskningsloggar. Dessa loggar måste aktiveras explicit för dataplansåtgärder och dirigeras till en manipulationssäker loggdestination (en skrivskyddad S3-bucket, ett Azure Storage-konto med oföränderlighet eller en GCS-bucket med objektlås).

Åtkomstloggar för privata nycklar registrera varje instans av en hemlighet eller nyckel som läses av en applikation eller identitet. I AWS Secrets Manager, varje GetSecretValue anrop loggas i CloudTrail. I Azure Key Vault loggas varje hemlig läsning i Key Vault-diagnostikloggar. I GCP Secret Manager loggas varje åtkomst i Cloud Audit Logs. Aviseringar om: all nyckelåtkomst från en identitet som inte finns i listan över godkända programroller; all nyckelexport eller nedladdning av en mänsklig identitet; all återkallelse av ett certifikat som inte har förnyats; och alla certifikat som löper ut inom 30 dagar och som inte har någon väntande förnyelse.

Arkitektur för hantering av certifikat i flera moln

Organisationer som kör certifikatarbetsbelastningar över AWS, Azure och GCP står inför samma konsekvensproblem i CLM som gäller för nyckelhantering: varje molnleverantörs inbyggda verktyg är begränsade till den leverantören. Tre arkitekturmönster hanterar certifikathantering i flera moln:

• Centraliserad CLM-plattform med molnbaserade kontakter: Distribuera en CLM-plattform från tredje part som ansluter till alla tre molnleverantörer via deras respektive API:er (ACM, Azure Key Vault, GCP Certificate Manager). CLM-plattformen upprätthåller ett enhetligt certifikatregister, tillämpar konsekventa certifikatpolicyer (minimal nyckellängd, tillåtna certifikatutfärdare, maximal giltighet, obligatoriska SAN:er) och utlöser förnyelse via varje leverantörs inbyggda API:er eller via ACME. Detta är den rekommenderade metoden för organisationer med betydande multimoln-tillgångar och efterlevnadskrav.
• Privat CA som en enda utfärdanderot: Distribuera en privat CA (molnbaserad eller tredjepartsbaserad) som utfärdar certifikat till alla interna tjänster i alla molnmiljöer. Alla tjänst-till-tjänst-certifikat spåras tillbaka till samma privata rot, oavsett vilket moln tjänsten körs i. Publikt riktade slutpunkter använder fortfarande offentliga CA-certifikat via inbyggda molnbaserade CLM-tjänster. Detta ger konsekvens för intern certifikatutfärdande utan att kräva en fullständig tredjeparts CLM-plattform.
• ACME med en delad CA mellan leverantörer: Konfigurera ACME-klienter på tjänster hos alla molnleverantörer för att förnya från samma ACME-kompatibla certifikatutfärdare. Certifikatutfärdaren kan vara en offentlig certifikatutfärdare (för offentliga certifikat) eller en privat ACME-certifikatutfärdare (för interna certifikat). Certifikatpolicyn tillämpas på certifikatutfärdarnivå och gäller enhetligt oavsett vilket moln ACME-klienten körs i. Denna metod ger den enklaste automatiseringen men kräver att certifikatutfärdaren stöder de certifikattyper och profiler som behövs i alla miljöer.

Efterlevnadskrav för hantering av molncertifikat

Flera ramverk för efterlevnad kräver nu uttryckligen kontroller för certifikatlivscykelhantering, inte bara kryptering under överföring.

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025): Krav 4.2.1 kräver att alla certifikat som används för att skydda primärkontonummer (PAN) under överföring bekräftas som giltiga, tillförlitliga och inte utgångna. Krav 12.3.3 kräver en dokumenterad inventering av alla kryptografiska chiffersviter och certifikat som används i Cardholder Data Environment (CDE), som granskas minst en gång var 12:e månad. Detta krav gör en certifikathanteringsplattform som producerar en inventeringsrapport till en direkt efterlevnadskontroll, inte bara bästa praxis.

DORA (Digital Operational Resilience Act, tillämplig från och med den 17 januari 2025): Artikel 9 kräver att finansiella enheter i EU använder stark kryptering och kryptografiska kontroller, och artikel 10 kräver IKT-relaterade incidenter. Avbrott vid certifikatutgång som orsakar otillgänglighet för tjänster är rapporteringspliktiga IKT-incidenter enligt DORA; certifikathanteringskontroller som förhindrar dessa avbrott är därför ett krav på IKT-riskhantering enligt DORA.

HIPAA: HIPAA-säkerhetsregeln Technical Safeguard 164.312(e)(2)(ii) kräver kryptering under överföring för elektronisk skyddad hälsoinformation (ePHI). I molnmiljöer innebär detta att giltiga TLS-certifikat måste upprätthållas på alla slutpunkter som överför ePHI, med dokumenterade bevis på certifikathanteringskontroller.

FedRAMP (NIST SP 800-53 Rev. 5): IA-3-kontrollen (Device Identification and Authentication) kräver att molnsystem hanterar enhetsidentitetsuppgifter, vilket inkluderar certifikat som används för ömsesidig autentisering. SC-17-kontrollen (Public Key Infrastructure Certificates) kräver en certifikatpolicy som täcker utfärdande, förnyelse och återkallelse. FedRAMP High kräver dessutom FIPS 140-2- eller FIPS 140-3-validerade kryptografiska moduler för certifikatoperationer.

Checklista för implementering av molncertifikathantering

1. Kör en fullständig certifikatsökning: Använd din CLM-plattform, molnbaserade identifieringsverktyg eller Encryption Consultings CBOM-säkerhet för att upptäcka alla certifikat i alla molnkonton, regioner och lokala system. Förvänta dig att hitta betydligt fler certifikat än vad ditt nuvarande lager visar.
2. Klassificera certifikat efter typ och ägarskap: För varje upptäckt certifikat, identifiera den utfärdande certifikatutfärdaren, certifikattypen (publik TLS, privat TLS, kodsignering, S/MIME, enhet), ägande teamet, distributionsplatsen och förnyelsemekanismen (manuell, ACME, molnbaserad automatisk förnyelse).
3. Identifiera certifikat utan automatisk förnyelse: Alla certifikat utan en automatisk förnyelsemekanism är ett framtida avbrott. Prioritera implementering av ACME eller molnbaserad automatisk förnyelse för dessa certifikat, med början med de som löper ut närmast.
4. Granska lagring av privata nycklar: Verifiera att privata nycklar för alla upptäckta certifikat lagras på godkända platser (moln-HSM, hemlighetshanterare, CLM-plattform). Identifiera och åtgärda alla nycklar som lagras i versionskontroll, containeravbildningar eller programkonfigurationsfiler.
5. Implementera certifikatpolicy i din CLM-plattform: Definiera minsta acceptabla certifikatparametrar: minsta RSA-nyckellängd (minst 2048 bitar; 4096 bitar för CA-certifikat), tillåtna signaturalgoritmer (SHA-256 eller starkare), maximal giltighet (anpassad till SC-081v3-schemat), obligatoriska SAN (inga jokerteckencertifikat där mer specifika SAN är möjliga) och godkända utfärdande CA:er.
6. Konfigurera utgångsaviseringar: Ställ in aviseringar till 60 dagar, 30 dagar och 14 dagar före utgångsdatum för alla certifikat utan automatisk förnyelse. Skicka aviseringar till ägarteamet och säkerhetsteamet.
7. Aktivera och dirigera granskningsloggar: Aktivera livscykelloggar för certifikat och åtkomstloggar för privata nycklar hos alla molnleverantörer. Dirigera till en manipulationssäker destination. Konfigurera aviseringar för de viktiga säkerhetshändelser som beskrivs i avsnittet om granskningsloggning ovan.
8. Granska och testa förnyelseprocessen varje kvartal: För varje certifikattyp med automatisk förnyelse, verifiera att förnyelseprocessen slutförs och att det förnyade certifikatet har distribuerats korrekt. Testa återkallningsprocedurer för minst ett certifikat per kvartal för att verifiera att återkallningsinfrastrukturen fungerar.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att utforma, implementera och granska program för hantering av molncertifikat, från initial upptäckt till kontinuerlig generering av efterlevnadsbevis.

• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare är en centraliserad plattform för hantering av certifikatlivscykeln som tillhandahåller automatiserad identifiering mellan molnleverantörer och lokala system, ACME-baserad automatiserad förnyelse, skydd av privata nycklar, tillämpning av certifikatpolicyer, aviseringar om utgångsdatum och en enhetlig granskningslogg. CertSecure Manager integreras direkt med AWS, Azure och GCP, har stöd för ACME för alla ACME-kompatibla certifikatutfärdare och inkluderar en AD Connector för Windows-miljöer med Microsoft Auto-Enrollment.
• PKI som en tjänst: För organisationer som behöver en hanterad privat CA för interna molncertifikat, Encryption Consultings PKI som en tjänst tillhandahåller en helt hanterad privat CA med ACME-stöd, integration med alla större molnplattformar och FIPS-validerad nyckellagring. Lämplig för Kubernetes service mesh-certifikat, mTLS mellan mikrotjänster och enhetsidentitetsprogram.
• HSM som en tjänst: För certifikathanteringsscenarier som kräver FIPS 140-2 nivå 3-skydd för privata nycklar, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad HSM-infrastruktur som integreras med CLM-plattformar och molncertifikattjänster, och förvarar CA-privata nycklar och värdefulla privata nycklar för slutenheter i hårdvarubaserad lagring.
• CBOM-säker: Krypteringskonsulttjänster CBOM-säkerhet kör automatiserad identifiering över AWS, Azure, GCP och lokala miljöer för att skapa en kryptografisk materiallista (CBOM) i CycloneDX-format. Detta tillhandahåller den certifikatinventering som krävs av PCI DSS v4.0.1 krav 12.3.3 och FedRAMP IA-3-kontroller, och identifierar skuggcertifikat och certifikat med osäkra konfigurationer.
• Efterlevnadsrådgivning: Vi kartlägger era kontroller för molncertifikathantering enligt de specifika kraven i PCI DSS v4.0.1, DORA, HIPAA, FedRAMP, NIS2 och andra tillämpliga ramverk, identifierar kontrollbrister, bygger en åtgärdsplan och tar fram revisionsbevispaketet. Se vår Rådgivning om efterlevnad.
• 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. Övergången till postkvantalgoritmer kommer att kräva att alla certifikat i er molnmiljö utfärdas på nytt. Encryption Consultings PQC-beredskap Tjänsten mappar ditt fullständiga certifikat och din kryptografiska position mot tidslinjen efter kvantmigreringen och utformar migreringssekvensen för molncertifikattillgångar.

För att diskutera dina behov av hantering av molncertifikat, kontakta Encryption Consulting.

Slutsats

Molnbaserad certifikathantering har gått från en praktisk operativ process till en obligatorisk säkerhets- och efterlevnadskontroll. CA/Browser Forum SC-081v3-schemat gör automatiserad förnyelse till en operativ nödvändighet senast 2029. PCI DSS v4.0.1 och DORA ställer tydliga krav på efterlevnad för dokumenterad certifikatinventering och livscykelstyrning. Och molnbaserad certifikatspridning över autoskalningsgrupper, containrar och multimoln-arbetsbelastningar gör manuell hantering operativt omöjlig i någon meningsfull skala.

De organisationer som kommer att hantera denna övergång utan avbrott eller brister i efterlevnaden är de som implementerar kontinuerlig certifikatidentifiering nu, driftsätter ACME-automation före 100-dagars giltighetsfristen i mars 2027, etablerar policyer för skydd av privata nycklar som överlever migreringen till certifikat med kortare livslängd och bygger den revisionslogg som regelverk för efterlevnad i allt högre grad kräver. De som väntar tills 47-dagars certifikat är obligatoriska i mars 2029 kommer att möta en komprimerad, högriskåtgärd under tidsfristpress.

Vanliga frågor om partihandel med mat och dryck

Vad är molnbaserad certifikathantering?

Molnbaserad certifikathantering är praxisen att upptäcka, utfärda, förnya, återkalla och granska digitala certifikat över molninfrastruktur, containrar och hybridmiljöer från en centraliserad plattform. Den ersätter manuell certifikatspårning med automatiserad livscykelhantering som förhindrar avbrott vid certifikatutgång, upprätthåller skydd av privata nycklar och genererar bevis för efterlevnadsrevisioner över flera molnområden.

Varför behöver molnmiljöer dedikerad certifikathantering?

Molnmiljöer genererar certifikat i en skala och hastighet som manuell hantering inte kan spåra. Autoskalningsgrupper, containrar, mikrotjänster och API-gateways behöver alla giltiga certifikat, och många tillhandahålls utan central IT-insyn. Ett enda utgånget certifikat i en molnbelastningsutjämnare eller API-gateway orsakar ett fullständigt tjänsteavbrott. Dedikerad CLM ger kontinuerlig identifiering, automatiserad förnyelse och centraliserad insyn i utgångsdatum, utfärdande av certifikatutfärdare, viktiga styrkor och efterlevnadsstatus för alla molnkonton och regioner.

Vad är skillnaden mellan inbyggd molnbaserad certifikathantering och en tredjeparts CLM-plattform?

Inbyggda molntjänster (AWS Certificate Manager, Azure Key Vault Certificates, GCP Certificate Manager) automatiserar förnyelse för resurser inom den enskilda molnleverantörens ekosystem. De ger ingen insyn i certifikat i andra moln, lokala system eller certifikattyper utanför deras omfattning. En tredjeparts CLM-plattform tillhandahåller en enhetlig certifikatinventering och konsekvent policytillämpning över alla molnleverantörer, lokal infrastruktur och certifikattyper, inklusive kodsignering, S/MIME och enhetscertifikat.

Hur bör privata nycklar skyddas i en molnbaserad miljö för hantering av certifikat?

Privata nycklar bör lagras i hårdvarubaserade hemlighetsarkiv, aldrig i klartextkonfigurationsfiler, miljövariabler eller versionskontroll. För belastningsutjämnare och API-gatewaycertifikat, använd molnleverantörens hanterade certifikattjänst där nyckeln aldrig exponeras. För certifikat där applikationen behöver direkt nyckelåtkomst, lagra nyckeln i en molnhemlighetshanterare med automatisk rotation. För FIPS 140-2 nivå 3-krav, använd en dedikerad HSM via moln-HSM-tjänster eller en tredjeparts-HSM som tjänsteleverantör.

Vad är ACME och hur möjliggör det automatisk certifikatförnyelse i molnet?

ACME (Automatic Certificate Management Environment) är ett IETF-protokoll (RFC 8555) som automatiserar utfärdande och förnyelse av certifikat genom att låta en klient bevisa domänkontroll för en CA och ta emot ett certifikat utan mänsklig inblandning. I molnmiljöer körs ACME-klienter som agenter på beräkningsinstanser eller i containrar och förnyar certifikat automatiskt innan de löper ut. Med TLS-certifikat som går över till 47 dagars giltighet i mars 2029 enligt CA/Browser Forum SC-081v3-schemat, är ACME-automatisering avgörande för alla molnmiljöer med mer än en handfull certifikat.

Vilka efterlevnadsramverk kräver kontroller för certifikathantering i molnmiljöer?

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025) kräver en dokumenterad certifikatinventering och giltiga certifikat för kortinnehavardata under överföring. DORA (gäller från och med januari 2025) kräver IKT-riskhanteringskontroller som täcker livscykelstyrning för kryptografiska certifikat. HIPAA kräver giltiga TLS-certifikat på alla slutpunkter som överför skyddad hälsoinformation. FedRAMP (NIST SP 800-53 Rev. 5) kräver en certifikatpolicy som täcker utfärdande, förnyelse och återkallelse. GDPR kräver lämpliga tekniska åtgärder för data under överföring, inklusive certifikathygien.