Bästa praxis för hantering av publika och privata nycklar år 2026

Publika och privata nycklar är den kryptografiska grunden för varje säkert digitalt system: de ligger till grund för HTTPS, digitala signaturer, kodsignering, SSH-åtkomst, e-postkryptering och identitet. Att hantera dem korrekt år 2026 kräver mer än säker lagring: nycklarna blir större (postkvantalgoritmer), livslängderna krymper (TLS-certifikat närmar sig 47 dagar) och hotet från Harvest-Now-, Decrypt-Later-attacker gör långvarig nyckelexponering till en framåtblickande risk. Den rekommenderade åtgärden: lagra privata nycklar i FIPS-validerade HSM:er, definiera och tillämpa kryptoperioder för alla nyckeltyper, automatisera rotation och återkallelse samt granska nyckelinventeringen kontinuerligt.

Snabbt svar: Vilka är de viktigaste metoderna för hantering av privata och offentliga nycklar?

För privata nycklar: generera inuti FIPS 140-2 Level 3+ HSM-hårdvara; lagra aldrig i klartext; tillämpa syftesbunden användning (en nyckel per funktion); implementera M-of-N-kvorum för känsliga operationer; rotera vid definierad kryptoperiod eller omedelbart vid kompromiss; testa återställning av säkerhetskopior årligen. För publika nycklar: distribuera via PKI-certifikat från betrodda certifikatutfärdare; upprätthåll en komplett inventering av alla certifikat- och publika nycklardistributioner; övervaka utgångsdatum och återkallelse; använd kortlivade certifikat för att begränsa exponeringen. För båda: automatisera livscykeloperationer; underhåll granskningsloggar; dokumentera och testa en hanteringsplan för nyckelkompromitterade incidenter. För det kompletterande ramverket för företagsnyckelhantering, se 10 bästa praxis för företagskrypteringsnyckelhantering.

Förstå offentliga och privata nycklar

För att hantera nycklar effektivt är det viktigt att först förstå vilka roller varje komponent spelar. Offentliga och privata nycklar är matematiskt sammanlänkade: operationer med en nyckel kan bara verifieras eller reverseras med den andra.

Vad är en privat nyckel?

En privat nyckel är den konfidentiella delen av ett asymmetriskt nyckelpar. Den måste förbli hemlig hela tiden och bör aldrig delas. Även om den är matematiskt relaterad till dess motsvarande offentliga nyckel, är det beräkningsmässigt ogenomförbart att härleda den privata nyckeln från den offentliga nyckeln med nuvarande algoritmer. Innehav av en privat nyckel ger kryptografiskt bevis på identitet: den används för att dekryptera data, skapa digitala signaturer eller autentisera mot system. Den som får en privat nyckel får i praktiken möjligheten att utge sig för att vara dess ägare. Det är därför privata nycklar är de mest värdefulla säkerhetstillgångarna i alla kryptografiska system.

Vad är en offentlig nyckel?

En offentlig nyckel är den delbara motsvarigheten till en privat nyckel. Den är utformad för att distribueras fritt utan att kompromissa med säkerheten. Vem som helst kan använda en offentlig nyckel för att kryptera data för nyckelägaren eller för att verifiera digitala signaturer som skapats med motsvarande privata nyckel. Säkerhetsmodellen bygger på det envägs matematiska förhållandet: data som krypterats med den offentliga nyckeln kan bara dekrypteras med den matchande privata nyckeln; signaturer som skapats med den privata nyckeln kan bara verifieras med motsvarande offentliga nyckel. Detta gör att förtroende kan upprättas över otillförlitliga nätverk utan att utbyta hemligheter i förväg, vilket är grunden för HTTPS, SSH, kodsignering och certifikatbaserad autentisering.

Hur offentliga och privata nycklar fungerar tillsammans

De två nycklarna bildar ett samordnat par där var och en utför en specifik, kompletterande roll:

• kryptering: Avsändaren använder mottagarens offentliga nyckel för att låsa data; endast mottagarens privata nyckel kan låsa upp den. Detta skyddar sekretessen utan att det krävs en tidigare delad hemlighet.
• Digitala signaturer: Undertecknaren använder den privata nyckeln för att skapa en signatur; vem som helst med den publika nyckeln kan verifiera att den kommer från den förväntade källan och inte har ändrats. Detta ger integritet och autentisering.
• Autentisering (SSH, TLS): Klienten bevisar innehav av den privata nyckeln genom ett utmanings- och svarsutbyte; servern verifierar med den betrodda publika nyckeln. Den privata nyckeln lämnar aldrig klienten.

Hur postkvantkryptografi påverkar nyckelhantering år 2026

Postkvantkryptografi (PQC) introducerar nya algoritmer utformade för att motstå attacker från kvantdatorer. NIST slutförde de första PQC-standarderna 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204) och SLH-DSA (FIPS 205). PQC förändrar nyckelhanteringen på flera sätt:

1. Större nycklar och artefakter: De flesta PQC-algoritmer använder betydligt större nyckelstorlekar än RSA eller ECC. Publika nycklar, privata nycklar och signaturer kan vara flera gånger större, vilket påverkar certifikatstorlekar, HSM-lagring, nätverkets handskakningslatens, säkerhetskopiering och arkiveringssystem samt logginfrastruktur. Nyckelhanteringssystem måste valideras för att hantera större kryptografiska objekt.
2. Prestanda och operativ påverkan: PQC introducerar högre beräkningskostnader för vissa operationer. Signeringssystem med hög volym (kodsignering, utfärdande av CA-certifikat), TLS-distributioner under hög belastning och resursbegränsade IoT- eller edge-enheter kräver modellering av prestandapåverkan före migrering.
3. Hybrida kryptografiska modeller: Branschen övergår till hybridkryptografi: man använder klassiska och postkvantumalgoritmer tillsammans. Hybridmodeller upprätthåller förtroende så länge minst en algoritm förblir säker, vilket minskar migreringsrisken. Nyckelhanteringssystem måste stödja flera algoritmer per nyckel eller certifikat, parallella rotationsstrategier och en tydlig policy för hybridanvändning.
4. Risk med Harvest Now, Decrypt Later: Motståndare som registrerar krypterad trafik idag kan dekryptera den retroaktivt när kvantdatorer anländer. Långlivade krypteringsnycklar och arkiverade data som skyddas av asymmetrisk kryptering löper hög risk. Organisationer bör förkorta nyckellivslängder, prioritera PQC-migrering för långsiktigt konfidentiell data och upprätthålla inventeringar som identifierar kvantumsårbara nycklar. Se Skörda nu, dekryptera senare för den fullständiga hotmodellen.
5. Kryptografisk flexibilitet som ett kärnkrav: PQC-standarder kommer att fortsätta att utvecklas; vissa algoritmer kan komma att förfinas eller ersättas. Nyckelhanteringsplattformar måste stödja algoritmisk smidighet: policydrivet algoritmval, sömlös rotation mellan algoritmer och samexistens av äldre, hybrid- och postkvantnycklar utan omskrivningar av applikationer.

Varför nyckelhantering är viktigt: De vanligaste fallgroparna

Även den starkaste krypteringen misslyckas om nycklarna hanteras felaktigt. De vanligaste nyckelhanteringsfelen, som var och en representerar en verklig attackvektor:

• Hårdkodade nycklar: Att bädda in nycklar i källkod, konfigurationsfiler eller automatiseringsskript exponerar dem för alla med åtkomst till arkivet. År 2024 rapporterade GitHub att över 39 miljoner läckta hemligheter upptäcktes i offentliga arkiv. Hårdkodade nycklar kan inte roteras utan en kodändring; när de väl upptäckts har angriparen permanent åtkomst tills nyckeln roteras.
• Överdelade privata nycklar: Att dela en privat nyckel mellan flera användare, team eller system mångfaldigar exponeringsytan. Varje ytterligare kopia ökar sannolikheten för stöld eller missbruk och eliminerar ansvaret för varje användare.
• Återanvändning av nyckel: Att använda en enda nyckel för kryptering, signering och autentisering innebär att en enda kompromiss bryter mot flera säkerhetskontroller samtidigt. Separera nycklar efter syfte.
• Svag nyckelgenerering: Otillräcklig entropi producerar förutsägbara nycklar. Debians OpenSSL-sårbarhet visade detta: dålig slumpmässighet gjorde nycklar trivialt brute-forcebara. Hårdvaru-TRNG:er eliminerar denna risk.
• Överblivna nycklar: Nycklar som förblir aktiva efter att anställda slutat, roller byts eller system tas ur drift ackumuleras i tysthet. De blir attackmål eller källor till efterlevnadsresultat när de upptäcks i granskningar.
• Ingen rotation eller återkallelse: Nycklar som är betrodda på obestämd tid förblir betrodda även efter kompromettering. Tidsbaserad och händelsebaserad rotation krävs båda.
• Manuell nyckelhantering i stor skala: Manuella processer för generering, distribution, rotation och återkallelse skalas inte upp och introducerar mänskliga fel. Missade utgångsdatum och glömda återkallelser är de vanligaste orsakerna till undvikbara nyckelhanteringsincidenter.
• Felkonfigurerade certifikatutfärdare eller nyckelkataloger: Om en CA eller nyckelkatalog är felaktigt konfigurerad kan system lita på falska nycklar eller blockera legitima. Regelbunden granskning av CA-konfigurationen och granskningar av förtroendeankare förhindrar detta.

Bästa praxis för hantering av privata nycklar

1. Säker nyckelgenerering: Generera privata nycklar inuti FIPS 140-2 nivå 3+ HSM:er med hjälp av en certifierad hårdvaru-TRNG. Nycklar som genereras inuti en HSM-gräns finns aldrig i värdminnet eller på disken. Använd RSA-3072 eller högre för RSA; Ed25519 eller ECDSA P-256+ för elliptisk kurva; AES-256 för symmetrisk. Hårdkoda inte nycklar i källkoden.
2. Ändamålsbunden nyckelanvändning: Varje nyckel måste ha en enda kryptografisk funktion. Krypteringsnycklar, signeringsnycklar, autentiseringsnycklar och CA-nycklar har olika roller och får aldrig återanvändas omväxlande. Att separera nycklar efter syfte begränsar explosionsradien för varje enskild kompromiss.
3. Säker förvaring: lagra privata nycklar i FIPS 140-3-kompatibla HSM:er eller motsvarande säkra nyckelvalv. Nycklar får aldrig finnas i klartext utanför hårdvarugränsen, inklusive konfigurationsfiler, miljövariabler eller minnesdumpar. Hårdvarubaserade, icke-exporterbara nyckelkonfigurationer förhindrar extrahering även av privilegierade användare.
4. Begränsa åtkomst: Tillämpa rollbaserad åtkomstkontroll (RBAC) och principen om minsta behörighet för all nyckelåtkomst. Kräva flerfaktorsautentisering för nyckelhanteringsåtgärder. Endast auktoriserade identiteter med ett dokumenterat affärsbehov bör ha åtkomst till nyckelåtgärder.
5. Uppdelning av arbetsuppgifter: Ingen enskild användare eller ett enskilt system bör kontrollera hela nyckellivscykeln. Separera nyckelgenerering, godkännande, distribution och återkallelse mellan olika roller. Detta är särskilt viktigt i reglerade miljöer och för CA- och HSM-masternycklar.
6. Viktigt förvarings- och tillsynsarbete: Utse dedikerade nyckelförvaltare som ansvarar för styrning och tillsyn. Förvaltare godkänner åtkomst, tillämpar policyer, övervakar användning och säkerställer snabb rotation och återkallelse. Separera kontroll- och verkställanderoller för att förbättra ansvarsskyldigheten.
7. Riskbaserad nyckelsegmentering: Klassificera nycklar efter känslighet och tillämpa proportionellt skydd. CA-rotnycklar och betalningsnycklar kräver HSM-hårdvara på nivå 3+; nycklar med lägre känslighet kan använda moln-KMS. Fokusera de högsta kontrollerna där de har störst inverkan.
8. Livscykeldriven rotation och återkallelse: Definiera kryptoperioder enligt NIST SP 800-57 baserat på algoritm, användning och risk. Signeringsnycklar med hög volym roterar oftare än CA-nycklar med låg volym. Automatisera rotationen för att minska mänskliga fel och säkerställa konsekvent policytillämpning. Återkalla omedelbart vid kompromettering.
9. Säker säkerhetskopiering och återställning: underhåll krypterade säkerhetskopior av nyckeln på geografiskt separata platser skyddade av M-of-N-förvaltaruppgifter. testa återställning till en sekundär HSM minst en gång per år. En otestad säkerhetskopia motsvarar ingen säkerhetskopia för katastrofåterställning.
10. Kontinuerlig övervakning och revision: logga alla nyckeloperationer: generering, åtkomst, användning, rotation, återkallelse, förstörelse. Underhåll en komplett nyckelinventering med ägarskap, algoritm, skapandedatum, utgångsdatum och distributionsomfattning. Varna för avvikande åtkomstmönster. Underhåll inventering med hjälp av CBOM-säkerhet för upptäckt av kryptografiska tillgångar.
11. Responsplan för incidenter: Dokumentera en procedur för hantering av nyckelkompromisser innan en incident inträffar. Täck in: omedelbar återkallelse, generering av ersättningsnyckel, konsekvensbedömning av data, meddelande till intressenter och granskning efter incidenten. Testa planen minst en gång per år.
12. End-to-end-automatisering: automatisera nyckelgenerering, rotation, återkallelse och säkerhetskopiering. Använd automatiserad CLM för TLS-certifikat (se CertSecure-hanterare) och hantering av SSH-nyckellivscykeln (se SSH-säker).

Bästa praxis för hantering av publika nycklar

1. Validera och verifiera publika nycklar: Publika nycklar måste få sin äkthet verifierad genom betrodda mekanismer: certifikatkedjor, betrodda rot-CA:er eller fingeravtrycksverifiering. Endast nycklar från godkända CA:er som uppfyller organisatoriska kryptografiska standarder bör vara betrodda. När PQC- och hybridcertifikat introduceras måste valideringslogiken uppdateras för att korrekt tolka nya algoritmer och certifikatstrukturer.
2. Centraliserad synlighet och lagerhållning: upprätthålla en komplett inventering av alla publika nycklar och certifikat som används: vilka system litar på dem, för vilket ändamål, när de löper ut och vem som äger dem. Utan insyn ackumuleras oanvända eller föråldrade nycklar och blir källor till efterlevnadsresultat och säkerhetsrisker. Se. CBOM-säkerhet för kryptografisk inventering.
3. Övervaka utgångsdatum och återkallelse: Certifikat måste ha tydligt definierade livslängder och återkallningsmekanismer. System måste verifiera utgångsdatum och återkallningsstatus med hjälp av CRL:er eller OCSP. Utgångna eller återkallade certifikat får aldrig litas på. Se CRL-risker och Jämförelse av OCSP och CRL.
4. Använd kortlivade certifikat: CA/Browser Forum kräver en minskning av livslängden för TLS-certifikat: 200 dagar senast i mars 2026, 100 dagar senast 2027 och 47 dagar senast 2029. Kortlivade certifikat begränsar exponeringsfönstret om en privat nyckel komprometteras och minskar beroendet av långsamma återkallningsmekanismer. Automatisera utfärdande och förnyelse av certifikat nu för att vara redo. Se 47 dagars TLS-certifikat och CertSecure-hanterare.
5. Revisionsförtroendeförhållanden: granska regelbundet förtroendeankare, CA-hierarkier och auktoriserade nyckellager. Ta bort föråldrade förtroendeankare, felkonfigurerade CA:er och obehöriga publika nycklar innan de utnyttjas. Regelbundna granskningar upptäcker avvikelser mellan policy och faktisk konfiguration.
6. Integrera med DevOps och molnet: bädda in hantering av publika nycklar och certifikat i CI/CD-pipelines, molntjänster och API-integrationer. Automatisera certifikatutfärdande och distribution för att eliminera manuell hantering i dynamiska miljöer. Tillämpa policybaserade kontroller över CA-utfärdandebehörigheter och förtroendeankare i molnbaserade distributioner.

Tabell för nyckellivscykelägande

Livscykelstadiet	Privat nyckelåtgärd	Åtgärd för offentlig nyckel	Ägare
Generation	Skapa inuti HSM med TRNG; definiera algoritm och nyckellängd	Exportera offentlig nyckel för distribution	Nyckeladministratör eller automatiserat KMS
Distribution	Distribueras aldrig; förblir i HSM	Distribuera via PKI-certifikat signerat av betrodd CA	PKI / CA
lagring	Inuti HSM eller säkert valv; aldrig klartext utanför gränsen	I authorized_nycklar, certifikatarkiv och förtroendeankare	Nyckelförvaltare; KMS; CA
Använda	Dekryptera, signera, autentisera; operationer inom HSM-gränsen	Kryptera, verifiera signaturer, auktorisera åtkomst	Auktoriserad applikation eller system
Rotation	Generera ny nyckel inuti HSM; distribuera ny publik nyckel; återkalla gammal	Utfärda nytt certifikat; uppdatera förtroendearkiv; inaktivera gammalt	Automatiserad KMS; nyckelförvaltare
Återkallande	Nollställ i HSM; ta bort från alla auktoriserade butiker	Utfärda CRL-post; uppdatera OCSP; ta bort från authorized_nycklar	Nyckelförvaltare; PKI-administratör
Förstörelse	FIPS 140-kompatibel nollställning; förstörelsegranskningsregister	Ta bort från alla betrodda arkiv; arkivera certifikat för granskning	Nyckelförvaltare; KMS

Rotationsutlösare: När man ska rotera utanför schemat

• Anställds avgång eller rollbyte: rotera och återkalla alla nycklar som individen innehade eller hade tillgång till, omedelbart vid avgång eller rollövergång.
• Bekräftad eller misstänkt kompromettering: Varje indikation på nyckelexponering utlöser omedelbar återkallelse och ersättning, oavsett var i sin kryptoperiod nyckeln befinner sig.
• Algoritmutfasning: NIST-utfasning av en algoritm (SHA-1 för signering, RSA-1024, DSA) kräver omedelbar ersättning av alla nycklar som använder den algoritmen.
• Avveckling av systemet: Nycklar som är kopplade till avställda system måste återkallas och inte återanvändas.
• Uppsägning av tredjepartsrelation: När en leverantör eller entreprenör med nyckelåtkomst avslutar sitt uppdrag, återkalla deras åtkomst och rotera berörda nycklar.
• Exponering av kodförråd: Om en privat nyckel är committad till ett källkodsarkiv (även ett privat sådant), behandla den som komprometterad och rotera omedelbart.

Incidenthanteringsplan för viktiga komprometter

1. Omedelbar återkallelse: ogiltigförklara den komprometterade nyckeln i alla betrodda system; uppdatera CRL och OCSP för certifikat; ta bort från authorized_keys för SSH-nycklar; markera som återkallad i KMS.
2. Generering av ersättningsnyckel: generera ett nytt nyckelpar med hjälp av godkänd algoritm och nyckellängd; genomföra en nyckelceremoni om nyckeln är en CA-nyckel eller HSM-huvudnyckel; distribuera den nya publika nyckeln till alla förlitande system.
3. Bedömning av omkryptering eller omsignering: Om den komprometterade nyckeln användes för att kryptera data, bedöm om omkryptering med den nya nyckeln krävs. Om den användes för signering (kodsignering, CA), avgör om tidigare utfärdade signaturer eller certifikat fortfarande är tillförlitliga.
4. Konsekvensbedömning av data och system: Identifiera alla data, system och identiteter som förlitade sig på den komprometterade nyckeln. Prioritera system med högsta känslighet för åtgärd.
5. Meddelande till intressenter: underrätta säkerhetsledningen, ägare av berörda applikationer och om reglerade uppgifter var inblandade, potentiellt tillsynsmyndigheter eller berörda individer per krav på anmälan av intrång.
6. Granskning efter händelsen: dokumentera grundorsak, tidslinje och påverkan; uppdatera viktiga hanteringskontroller för att förhindra upprepning; revidera incidenthanteringsplanen baserat på dragna lärdomar.

Moderna nyckelhanteringsöverväganden år 2026

1. Kryptografisk smidighet och PQC-beredskap: Utforma nyckelhanteringssystem för att stödja algoritmisk smidighet nu. Introducera ML-KEM och ML-DSA tillsammans med klassiska algoritmer i hybridläge. Se PQC-rådgivningstjänster.
2. Automatiserad hantering av nyckellivscykeln: Manuell spårning skalas inte. Automatisera generering, rotation, återkallelse och säkerhetskopiering med hjälp av centraliserade plattformar. Automatisering minskar mänskliga fel och tillämpar policyn konsekvent.
3. Molnbaserade och kortlivade arbetsbelastningar: Containrar, serverlösa funktioner och dynamisk infrastruktur kräver kortlivade nycklar som provisioneras och roteras automatiskt. Statiska nycklar med lång livslängd passar inte för molnbaserade distributionsmodeller.
4. Zero-trust och DevSecOps-integration: bädda in nyckelhantering i CI/CD-pipelines. Kräv kontinuerlig verifiering för nyckelåtkomst baserat på identitet, kontext och policy.
5. Hårdvarubaserad förtroende: Använd FIPS 140-3-kompatibla HSM:er eller TPM:er för lagring av privata nycklar. Se HSM som en tjänst för hanterade hårdvarualternativ.
6. Konsistens mellan olika miljöer: tillämpa enhetliga nyckelhanteringspolicyer i lokala, moln- och multimolnmiljöer. Centraliserade styrningsplattformar ger policy och insyn samtidigt som de möjliggör flexibilitet vid distribution.
7. Efterlevnad och granskningsbarhet: underhålla revisionsloggar, åtkomstloggar, policybevis och automatiserad rapportering för NIST, HIPAA, PCI DSS och andra tillämpliga ramverk.

Hur krypteringskonsulting kan hjälpa

• PQC-rådgivningstjänster: bedöma kryptografisk risk, identifiera kvantumsårbara algoritmer och designa kryptoagila arkitekturer. Se Rådgivningstjänster inom postkvantkryptografi.
• Krypteringsrådgivningstjänster: bedöma kryptering och nyckelhantering, identifiera luckor och utforma strategier i linje med NIST, GDPR, PCI DSS och HIPAA. Se Krypteringsrådgivningstjänster.
• HSM-tjänster: säker nyckelgenerering, lagring och användning i FIPS 140-3-kompatibla miljöer. Se HSM-tjänster.
• PKI-tjänster: designa, driftsätta och driva PKI-miljöer med säker certifikatutfärdande, rotation, återkallelse och förtroendestyrning. Se PKI-tjänster och PKI som en tjänst.

Slutsats

Publika och privata nycklar är grunden för digitalt förtroende. Att hantera dem korrekt år 2026 innebär att behandla privata nycklar som de mest värdefulla säkerhetstillgångarna i organisationen, distribuera publika nycklar genom pålitlig PKI-infrastruktur, automatisera rotation och återkallelse för alla nyckeltyper, upprätthålla kontinuerlig granskningssynlighet och planera för övergången efter kvantkryptografin nu. Kombinationen av förkortade certifikatlivslängder, växande nyckelstorlekar och HNDL-hotmodellen gör disciplinerad, automatiserad och kryptoagil nyckelhantering till en affärsnödvändighet snarare än en rekommendation för bästa praxis. För det kompletterande ramverket för företagsnyckelhantering, se 10 bästa praxis för företagskrypteringsnyckelhantering.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan en offentlig nyckel och en privat nyckel?

En privat nyckel är den konfidentiella komponenten i ett asymmetriskt par: den används för att dekryptera data eller skapa digitala signaturer och måste förbli hemlig hela tiden. En offentlig nyckel är den delbara komponenten: den distribueras fritt för att möjliggöra kryptering för nyckelägaren eller verifiering av deras signaturer. De är matematiskt länkade; att härleda den privata nyckeln från den offentliga nyckeln är beräkningsmässigt ogenomförbart.

Hur ska privata nycklar förvaras säkert?

Inuti en FIPS 140-2 nivå 3 eller högre HSM eller motsvarande säkert nyckelvalv. Nycklar får aldrig finnas i klartext på disk, i konfigurationsfiler, i källkod eller i miljövariabler. HSM:er förvarar nycklar inom en manipulationssäker hårdvarugräns från vilken de aldrig kommer ut i klartext, även om värdoperativsystemet är komprometterat.

Vad är kryptografisk agilitet och varför är det viktigt år 2026?

Kryptografisk agilitet är möjligheten att byta kryptografiska algoritmer utan att applikationer behöver skrivas om. Det är viktigt eftersom NIST har slutfört postkvantstandarder (ML-KEM, ML-DSA, SLH-DSA) som kräver migrering; vissa klassiska algoritmer är redan föråldrade; och TLS-certifikatens livslängd krymper mot 47 dagar. System utan agilitet står inför akut omstrukturering under övergångar.

Vad är en Harvest-Now, Decrypt-Later-attack?

En motståndare registrerar krypterad kommunikation idag för dekryptering efter att en kvantdator blir tillgänglig. Långlivade krypteringsnycklar som skyddar hälsojournaler, finansiella data, regeringshemligheter och känsliga TLS-sessioner löper störst risk. Åtgärder: migrera långlivade datakrypteringsnycklar till postkvantalgoritmer och förkorta nyckelns livslängd.

Hur ofta bör publika och privata nycklar roteras år 2026?

CA-privata nycklar: 1–10 år per nivå. TLS-certifikat: 398 dagar nu, minskat till 200 dagar i mars 2026, 100 dagar i 2027, 47 dagar i 2029. SSH-nycklar: minst årligen, omedelbart vid avgång eller kompromettering. Valfri nyckel: omedelbart vid bekräftad eller misstänkt kompromettering oavsett schema.

Vad bör en hanteringsplan för incidenter med komprometterad privat nyckel innehålla?

Omedelbar återkallelse i alla betrodda system; generering av ersättningsnyckel (med ceremoni om en CA-nyckel); bedömning av omkryptering eller omsignering; konsekvensbedömning av data och system; meddelande till intressenter; och granskning efter incidenten för att dokumentera grundorsak och uppdatera kontroller.