Förenkla granskning och åtgärd av nycklar och certifikat

Publicerad: december 2023. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och nyckelhanteringsrådgivningsteam.

Varför ackumulerar nycklar och certifikat revisionsskuld från första början?

Kryptografiska tillgångar ackumulerar revisionsskulder eftersom de skapas snabbare än de spåras. En utvecklare begär ett TLS-certifikat för en staging-server och den går till produktion. Ett team genererar ett SSH-nyckelpar för att skripta en distribution och roterar det aldrig. En molntjänst skapar en ny krypteringsnyckel och säkerhetsteamet får reda på det under nästa efterlevnadscykel, om det alls görs. Inget av detta är skadligt; de är den vanliga friktionen hos distribuerade team som provisionerar kryptografi snabbare än styrning kan följa.

Resultatet blir en lucka mellan vad ditt certifikat och din nyckelinventering säger existerar och vad som faktiskt finns i produktion. Den luckan är vad en granskare hittar, och det är vad en angripare utnyttjar: en föräldralös nyckel med överskridande behörighet, ett utgånget certifikat som tyst inaktiverar en återkallningskontroll, eller ett självsignerat certifikat som någon litade på "tillfälligt" för tre år sedan. Att stänga det är inte ett engångsprojekt. Det är en cykel av upptäckt, klassificering, åtgärd och verifiering som måste pågå kontinuerligt eftersom den underliggande miljön aldrig slutar förändras.

Vem äger livscykeln för en nyckel kontra ett certifikat?

Ägarskap måste tilldelas per tillgångstyp, eftersom nycklar och certifikat misslyckas på olika sätt och är skyldiga olika intressenter. En nyckel utan namngiven ägare kan inte roteras på ett säkert sätt eftersom ingen kan bekräfta vad som går sönder om det ändras. Ett certifikat utan namngiven ägare förnyar sig självt till ett avbrott den dag ingen märker att det har löpt ut.

Livscykelstadiet	Kryptografiska nycklar	Certifieringar
Generation	Nyckelförvaltare eller säkerhetsteam, inuti ett HSM eller ett godkänt nyckelhanteringssystem, aldrig på en utvecklarbärbar dator	Begärt av en applikations-/tjänsteägare, utfärdat av en godkänd intern eller offentlig CA
Registrering	Inloggad i en nyckelinventering med algoritm, längd, ägare och avsedd användning	Inloggad i ett certifikatregister med SAN, utfärdande CA, giltighetsfönster och distributionsplats
Aktiv användning	Åtkomst begränsad av roll; ingen direkt administratörsåtkomst till rått nyckelmaterial	Distribueras till exakt de slutpunkter som behöver det; identifieringsskanningar bekräftar att distributionen matchar inventeringen
Rotation/förnyelse	Roteras i slutet av sin definierade kryptoperiod eller vid en utlösande händelse	Förnyas före utgångsdatum, i allt högre grad genom automatiserad registrering (ACME/EST) i takt med att giltighetsfönstren krymper
Pensionering	Förstört eller arkiverat enligt en dokumenterad procedur för nyckelförstöring med granskningsloggpost	Återkallad om den komprometteras eller ersätts; borttagen från betrodda butiker och lager
Typisk ägare	Säkerhets-/kryptografiteam (nyckelförvaltarmodell)	Applikations- eller infrastrukturägare, med ett centralt PKI/CLM-team som styrande myndighet

Den praktiska lösningen är en namngiven ansvarig ägare för varje nyckel och varje certifikat i det ögonblick det utfärdas, inte upptäckt i efterhand. Både plattformar för hantering av certifikatlivscykeln och nyckelhanteringssystem stöder ägarmetadata som ett förstklassigt fält just för att "vem äger detta" är den enskilt vanligaste flaggan för gap-revisorer.

Vad utlöser egentligen en nyckelrotation eller certifikatförnyelse?

Rotation bör aldrig vara enbart kalenderstyrd. Ett försvarbart program kombinerar tidsbaserade gränser med händelsebaserade utlösare, och för certifikat, en extern begränsning som förändras snabbt: CA/Browser Forums krympande maximala giltighetsperiod.

Tidsbaserad rotation

NIST SP 800-57 Del 1, Revision 5 definierar kryptoperioden som den tidsperiod som en specifik nyckel är auktoriserad för användning, och balanserar risken för att en nyckel komprometteras ju längre den förblir aktiv mot driftskostnaden för att rotera den. Det finns inget enda korrekt nummer; NIST överlåter det exakta intervallet till organisationens riskbedömning, algoritm och nyckelstyrka, men principen är fast: varje nyckel behöver en definierad maximal livslängd som är satt i förväg, inte lämnas öppen.

Händelsebaserad rotation

En nyckel eller ett certifikat bör roteras omedelbart, utanför sitt normala schema, när:

• En administratör med åtkomst till den privata nyckeln byter roll eller lämnar organisationen.
• En misstänkt eller bekräftad kompromiss inträffar var som helst i kedjan, inklusive hos den utfärdande CA:n.
• En algoritm eller nyckellängd är föråldrad enligt NIST-riktlinjer eller intern policy.
• En leverantör, molnleverantör eller tredjeparts CA rapporterar en incident som kunde ha exponerat viktigt material.
• En granskning visar att tillgången utfärdades utanför den godkända processen (ett självsignerat certifikat eller skuggcertifikat, en oregistrerad nyckel).

Den certifikatspecifika utlösaren: krympande maximal giltighet

Certifikat har en ytterligare, externt pålagd rotationsutlösare som nycklar inte har: CA/Browser Forums Ballot SC-081v3 fasar ner den maximala giltighetsperioden för offentliga TLS-certifikat enligt ett fast schema:

Giltigt datum	Maximal giltighetstid för TLS-certifikat
Till och med 14 mars 2026	398 DAYS
15 mars 2026 till 14 mars 2027	200 DAYS
15 mars 2027 till 14 mars 2029	100 DAYS
Från och med 15 mars 2029	47 DAYS

Perioderna för återanvändning av domänvalidering krymper enligt samma schema, så småningom till 10 dagar. Det betyder att ett gransknings- och åtgärdsprogram som bygger på årliga eller till och med kvartalsvisa manuella certifikatgranskningar inte kommer att hålla jämna steg. År 2029 kommer ett certifikat som utfärdas idag att behöva bytas ut ungefär åtta gånger om året istället för en gång. Vi går igenom den operativa matematiken för den övergången mer ingående i Förberedelser för 47-dagars TLS-certifikat.

Vem ska ha behörighet att granska och åtgärda nycklar och certifikat?

Revisions- och saneringsbefogenheter måste separeras från den dagliga utfärdandebefogenheten, annars är revisionen inte riktigt oberoende. En fungerande åtkomstmodell ser ut så här:

• Viktiga förvaltare ha operativt ansvar för specifika nycklar men inte ha oövervakad åtkomst till rånyckelmaterial; dubbel kontroll och delad kunskap gäller för alla operationer som kan exponera eller missbruka en nyckel.
• Certifikat-/CA-administratörer kan utfärda och återkalla certifikat inom policyn men kan inte ändra granskningsloggen för sina egna åtgärder.
• revisorer (intern säkerhet eller extern QSA/bedömare) har skrivskyddad åtkomst till hela inventeringen, utfärdandeloggar och policykonfiguration, utan möjlighet att ändra det de granskar.
• Omstridda För åtgärdsåtgärder (återkalla ett certifikat, rotera en produktionsnyckel) är en separat roll från den person som identifierade fyndet, så ingen enskild person kan både flagga och åtgärda ett kritiskt problem utan en andra uppsättning ögon.

Administratörer ska aldrig ha direkt åtkomst till privata nyckelmaterial utanför ett hanterat system, och alla undantag måste loggas och tidsbestämmas. Denna modell för separation av uppgifter är också vad PCI DSS 4.0- och SOC 2-bedömare förväntar sig att se dokumenterad, inte antagen.

Vilka bevis vill revisorerna egentligen se?

Detta är kärnan i problemet som de flesta team gör fel på: de behandlar "vi har en policy" som bevis. Revisorer vill ha bevis på att policyn följs, är aktuell och upprätthålls. Vid en granskning av kryptografiska tillgångar delas dessa bevis vanligtvis in i fyra kategorier.

En komplett, aktuell inventering

PCI DSS 4.0-krav 4.2.1.1 kräver att organisationer som hanterar kortinnehavardata ska ha en uppdaterad inventering av alla kryptografiska nycklar och certifikat, inklusive algoritm, nyckelstyrka, utgångsdatum och de specifika data som var och en skyddar. En inventering som var korrekt vid den senaste revisionen men som inte har stämts av mot en live discovery-skanning sedan dess är inte aktuell, och bedömare frågar allt oftare efter skanningsdatumet, inte bara kalkylbladet.

Dokumenterad, daterad policygranskning

PCI DSS-krav 12.3.3 kräver att organisationer dokumenterar och granskar sina kryptografiska chiffersviter och protokoll som används minst en gång per år, inklusive en dokumenterad motivering för fortsatt användning av eventuella föråldrade algoritmer och en plan för att migrera bort från dem. Revisorer vill ha ett daterat dokument, en namngiven granskare och en ändringslogg, inte en policy som inte har ändrats sedan den skrevs.

Åtkomst- och driftloggar

Varje händelse av nyckelgenerering, rotation, export och förstörelse, och varje utfärdande, förnyelse och återkallelse av certifikat, behöver en säker, manipulationssäker loggpost: vem utförde åtgärden, när och under vilket godkännande. För SOC 2-uppdrag är denna logg ofta det enda beviset som avgör om en kontroll bedöms som fungerande effektivt eller som en lucka i rapporten.

Slutna slingor för sanering

Ett fynd utan ett dokumenterat åtgärds- och omverifieringsdatum är ett öppet fynd, oavsett hur gammalt det är. Revisorer letar specifikt efter bevis på att ett tidigare flaggat problem (ett utgånget certifikat som fortfarande finns i en förtroendelagring, en nyckel som passerat sin kryptoperiod) faktiskt åtgärdades och bekräftades som åtgärdat, inte bara noterades i ett kalkylblad och glömdes bort.

Hur ser ett praktiskt arbetsflöde för revision och åtgärdande ut?

Kör samma femstegscykel oavsett om utlösaren är en schemalagd internrevision, en kommande PCI DSS-bedömning eller en SOC 2-förnyelse.

1. Inventera och upptäck. Kör nätverks- och slutpunktsskanningar för att hitta alla nycklar och certifikat som används och avstäm sedan resultaten mot befintligt lager. Upprätta en definierad process för att registrera alla nycklar eller certifikat som skanningen inte kan upptäcka, till exempel de som är inbäddade i offline-system eller hårdvaruenheter.
2. Klassificera efter risk. Poängsätt varje tillgång efter vad den skyddar, var den befinner sig (produktion kontra icke-produktion, internet-orienterad kontra intern), hur nära den är utgångsdatumet eller slutet av kryptoperioden, och om dess algoritm eller nyckellängd fortfarande uppfyller gällande policy.
3. Åtgärda. Åtgärda de högst riskfyllda resultaten först: återkalla eller ersätt svaga eller obehöriga certifikat, rotera nycklar efter deras kryptoperiod, korrigera saknat ägarskap och ta bort test- eller icke-produktionsnycklar och certifikat som migrerat till produktionsmiljöer.
4. Kontrollera. Bekräfta att korrigeringen faktiskt trädde i kraft i produktionen, inte bara i hanteringskonsolen. Ett certifikat markerat som "förnyat" som aldrig omdistribuerades till lastbalanseraren är fortfarande ett fynd.
5. Rapportera. Ta fram en daterad rapport som visar vad som upptäcktes, vad som åtgärdades, vad som fortfarande är öppet med ett måldatum och vem som godkände varje åtgärd. Denna rapport är den artefakt som en revisor granskar, så den måste stå på egna ben.

Två ytterligare kontroller hör hemma i varje cykel oavsett tillgångstyp: att förhindra migrering av icke-produktionsnycklar och certifikat till produktion genom att begränsa användningen av test-CA till icke-produktionssystem, och att upprätthålla en dokumenterad åtgärdsplan för CA-kompromettering som anger vem som ersätter vilka certifikat, i vilken ordning, om en betrodd rot- eller mellanliggande CA någonsin komprometteras.

Manuella kalkylbladsgranskningar eller automatiserade verktyg för identifiering och inventering?

Det ärliga svaret beror på skala, men övergångspunkten kommer tidigare än de flesta lag förväntar sig.

Faktor	Manuell/kalkylbladsrevision	Automatiserade verktyg för identifiering och inventering
Discovery-täckning	Begränsat till vad teamen själva rapporterar; missar skugg- och föräldralösa tillgångar	Kontinuerlig nätverks-, slutpunkts- och moln-API-skanning hittar tillgångar som ingen rapporterat
Datans valuta	Noggrann endast från och med den senaste manuella granskningen	Uppdateras enligt schema eller kontinuerligt, i linje med vad revisorer förväntar sig av 4.2.1.1
Skala	Hanterbar upp till ett fåtal hundratals tillgångar; bryts ner bortom det	Skalbar till tiotusentals nycklar och certifikat i hybrid- och multimolnmiljöer
47 dagars giltighetstid	Kan inte hålla jämna steg med 8+ förnyelser per certifikat per år senast 2029	Automatiserad förnyelse och registrering (ACME/EST) byggd för högfrekventa cykler
Granskningsloggens integritet	Beror på manuell disciplin; lätt att hamna på efterkälken eller redigera i efterhand	Systemgenererade, manipulationssäkra loggar kopplade till varje åtgärd
Kostnadsprofil	Låg verktygskostnad, hög och växande arbetskraftskostnad i takt med att lagret expanderar	Förskottskostnad för plattformen, väsentligt lägre löpande arbetskraftskostnader i stor skala

Ett kalkylblad är en rimlig utgångspunkt för en liten, mestadels statisk tillgång. Det slutar vara rimligt i det ögonblick då certifikatförnyelsefrekvensen tredubblas under det förkortade giltighetsschemat, eller i det ögonblick en revisor ber om ett datum för en upptäcktsskanning snarare än en självrapporterad lista. Plattformar som CBOM Secure är specifikt byggda för att täppa till det gapet genom att kontinuerligt upptäcka och inventera kryptografiska tillgångar, inklusive nycklar och certifikat som en manuell process aldrig skulle hitta.

Vad händer när en revision visar ett kritiskt fynd?

Inte alla fynd är rutinmässiga. När en granskning avslöjar något som ser ut som en aktiv kompromettering, ett falskt certifikat utfärdat utanför den godkända certifikatutfärdaren, eller en privat nyckel exponerad i ett offentligt arkiv eller en loggfil, måste ovanstående reparationsarbetsflöde överlämnas till incidenthantering snarare än att hamna i den vanliga reparationskön.

1. Innehålla. Återkalla det berörda certifikatet eller inaktivera den berörda nyckeln omedelbart; vänta inte på det normala rotationsfönstret.
2. Omfattning. Bestäm allt som den komprometterade nyckeln eller certifikatet kan vidröra: vad den autentiserade, vad den krypterade, vad som betrodde den.
3. Meddela. Involvera incidenthanteringsteamet och, där fyndet involverar en kompromiss på CA-nivå eller en reglerad datatyp, de efterlevnads- och juridiska intressenter som fastställer offentliggörandeskyldigheter.
4. Byta ut. Utfärda och distribuera ersättningsnyckeln eller certifikatet, verifierat i produktion, innan du avslutar sökningen.
5. Identifiera grundorsaken och förhindra återfall. Fastställ hur tillgången undkom normal styrning (oregistrerad utfärdande, saknad skanningstäckning, ett policygap) och åtgärda processgapet, inte bara den enskilda tillgången.

Det är just därför en dokumenterad åtgärdsplan för kompromisser mellan CA-kompromitterade aktörer, med en upprätthållen backup-relation mellan CA-aktörer, är viktig innan en incident inträffar snarare än efter. Att bestämma vem som kan ta bort en betrodd rot från produktionslager är inte ett beslut som fattas första gången under press.

Beslutsguide: var bör du fokusera först?

Ditt nuvarande tillstånd	Prioriterad åtgärd
Det finns ingen fullständig inventering av nycklar och certifikat	Kör en upptäcktssökning innan du gör något annat; du kan inte klassificera eller åtgärda det du inte har hittat
Inventarielager finns men är inte kopplat till namngivna ägare	Tilldela en ansvarig ägare till varje tillgång före nästa revisionscykel
Certifikat förnyas manuellt vid utgångsdatumaviseringar	Gå över till automatiserad registrering (ACME/EST) nu, inför giltighetsmilstolparna på 100 dagar och 47 dagar
Nycklar har ingen definierad kryptoperiod	Ange maximala livslängder enligt NIST SP 800-57 riskriktlinjer och tillämpa dem i nyckelhanteringssystemet
Resultaten korrigeras men verifieras inte på nytt	Lägg till ett verifieringssteg i åtgärden innan ett fynd kan markeras som avslutat
Förberedelser inför en PCI DSS- eller SOC 2-bedömning inom 90 dagar	Prioritera bevisgenerering: lagerstatus, policygranskningsdatum och åtkomstloggar

Begränsningar

Inget revisions- och saneringsprogram eliminerar risker helt. Discovery-skanning kan inte hitta varje tillgång; nycklar inbäddade i offline-hårdvara, system med luftgapp eller äldre apparater kräver fortfarande en manuell registreringsprocess, och den processen är beroende av att personer följer den. Automatiserade verktyg minskar men eliminerar inte behovet av definierade roller och arbetsuppdelning; en plattform kan inte ersätta en namngiven nyckelförvaltare eller godkännare. Och ingen kryptoperiod eller giltighetsschema skyddar mot en nyckel eller ett certifikat som hanterades felaktigt innan rotation någonsin skulle ske, vilket är anledningen till att åtkomstpolicy och revisionsloggning är lika viktiga som själva schemat.

Vad skulle krypteringskonsulter rekommendera?

Behandla nycklar och certifikat som två sammankopplade men separata granskningsspår och matcha verktygen till var och en. För kryptografisk upptäckt och inventering över hela din databaser, inklusive nycklar, ger CBOM Secure dig den kontinuerliga, granskningsklara inventering som ett kalkylblad inte kan upprätthålla i stor skala, vilket sluter exakt det gap som PCI DSS 4.2.1.1 efterfrågar. Specifikt för certifikatsidan, särskilt när giltighetsfönstren komprimeras mot 47 dagar, automatiserar CertSecure Manager upptäckt, utfärdande, förnyelse och återkallelse med den distributionsverifiering och granskningsloggning som bedömare förväntar sig att se.

När ett program behöver en extern granskning före nästa bedömning utvärderar våra krypteringsrådgivningstjänster en organisations befintliga nyckel- och certifikatlandskap, förfinar kryptografisk och nyckelhanteringspolicy mot gällande standarder och hjälper till att bygga den beviskedja som revisorer och bedömare faktiskt förväntar sig, med stöd av vår ISO/IEC 27001:2022- och SOC 2-certifierade leveranspraxis.

Slutsats

Granskning och åtgärd av nycklar och certifikat är inte längre en årlig efterlevnadsövning. Det är en kontinuerlig cykel av upptäckt, klassificering, åtgärd och verifiering, vilket har blivit mer brådskande av CA/Browser Forums krympande certifikatgiltighetsschema och strängare av vad PCI DSS 4.0 och SOC 2 nu förväntar sig att bedömare faktiskt ska verifiera. De organisationer som behandlar detta som en löpande operativ disciplin, med namngivet ägarskap, definierade rotationsutlösare och bevis som genereras som en biprodukt av arbetsflödet snarare än sammanställts under tidsfristpress, är de som går in i en granskning utan något att kämpa för.

Vanliga frågor och svar

Hur ofta bör vi granska våra nycklar och certifikat?
Avstämning av inventarier och lager bör ske kontinuerligt eller minst månadsvis, med tanke på hur snabbt oregistrerade tillgångar dyker upp. Formell policygranskning krävs minst årligen enligt PCI DSS-krav 12.3.3, men organisationer som förbereder sig för en SOC 2-revision genomför vanligtvis en fullständig åtgärdscykel kvartalsvis för att hålla bevisen aktuella mellan bedömningsfönstren.

Vad är skillnaden mellan granskningsnycklar och granskningscertifikat?
Nycklar styrs av kryptoperioder, algoritm- och längdpolicy, samt strikt åtkomstkontroll enligt NIST SP 800-57; kärnfrågan är vem som kan röra nyckelmaterialet och hur länge det förblir giltigt. Certifikat styrs av CA/Browser Forums giltighetsgränser, utfärdandepolicy och distributionsverifiering; kärnfrågan är om certifikatet som presenteras i produktion matchar vad som faktiskt utfärdades och var det ska vara.

Behöver vi automatiserade verktyg, eller kan vi hantera detta med kalkylblad?
Kalkylblad kan fungera för ett litet, till stor del statiskt lager, men de kan inte hålla jämna steg med kontinuerliga identifieringskrav eller den accelererande takten för certifikatförnyelse som skapats av CA/Browser Forums övergång till 47 dagars giltighetstid. De flesta organisationer når den punkt där automatiserade identifierings- och inventeringsverktyg betalar sig själva i form av undviken arbetskraft och undvikna avbrott långt innan de når den väggen.

Vilka är de största felen som organisationer gör i revisioner?
Oägda tillgångar. En nyckel eller ett certifikat utan namngiven ansvarig ägare kan inte med säkerhet roteras, förnyas eller återkallas, eftersom ingen kan bekräfta vad som är beroende av det. Att tilldela ägarskap vid utfärdandet, inte i efterhand, täcker de flesta av de fynd som vanligtvis framkommer vid en förstagångsrevision.

Vad ska vi göra först om en granskning upptäcker en komprometterad nyckel eller ett komprometterat certifikat?
Först och främst: återkalla certifikatet eller inaktivera nyckeln omedelbart istället för att vänta på ett schemalagt rotationsfönster. Kontrollera sedan vad det påverkade, meddela intressenter för incidenthantering och efterlevnad, ersätt och verifiera den nya tillgången i produktion och åtgärda processluckan som gjorde att den komprometterade tillgången gick obemärkt förbi.

Referensprojekt

• NIST, SP 800-57 Del 1, Revision 5, Rekommendation för nyckelhantering: Del 1, Allmänt
• CA/Webbläsarforum, Omröstning SC-081v3: Inför ett schema för att minska giltigheten och återanvändningsperioder för data
• DigiCert, TLS-certifikatens livslängd kommer officiellt att minskas till 47 dagar
• Röd sikt, Din guide till PCI DSS 4.0 kryptografiska krav