Kryptering är enkelt, nyckelhantering är också enkelt?

Krypteringsalgoritmer är matematiskt bevisade och allmänt tillgängliga. De faktiska felen sker i nyckelhanteringen: hur nycklar genereras, var de lagras, vem som har åtkomst till dem, när de roterar och om de återkallas korrekt. En hårdvarusäkerhetsmodul (HSM) är som motorn i en bil: högpresterande och specialbyggd. Nyckelhantering är resten av bilen: människorna som använder den, processerna som styr den och tekniken som kopplar samman alla delar. Den rekommenderade åtgärden: bedöm din organisations mognadsnivå för nyckelhantering ärligt och bygg sedan en systematisk plan för att täppa till luckorna.

Snabbt svar: Varför är nyckelhantering lika viktigt som kryptering?

Kryptering skyddar data genom att göra den oläslig utan nyckeln. Nyckelhantering skyddar själva nycklarna. En komprometterad nyckel gör den starkaste krypteringen oanvändbar: angriparen kan dekryptera allt som nyckeln skyddar, signera dokument eller programvara i ditt namn, utge sig för att vara dina system och gå igenom ditt nätverk. De flesta verkliga kryptografiska incidenter är inte algoritmfel; de är nyckelhanteringsfel: hårdkodade nycklar i källkodsdatabaser, nycklar lagrade på utvecklarnas arbetsstationer, nycklar som aldrig roteras och nycklar som inte återkallas efter att anställda slutat. För de 10 bästa praxis som kan åtgärdas för att åtgärda dessa fel, se 10 bästa praxis för företagskrypteringsnyckelhantering.

Att förstå nyckelhantering och dess betydelse för er övergripande säkerhetssituation är grundläggande för att etablera den bästa kryptografiska infrastrukturen för ert företag. Nycklar och certifikat används för många olika uppgifter och är avgörande för er organisations datasäkerhet. Som NIST SP 800-57 del 1 Rev. 5 anger beror säkerheten för information som skyddas av kryptografi direkt på nycklarnas styrka, effektiviteten hos tillhörande mekanismer och protokoll samt det skydd som ges till nycklarna.

Bedömning av din mognad inom nyckelpositioner

Det första steget är att ärligt bedöma organisationens mognadsnivå för nyckelpersoner. I bedömningen av mognadsnivån för nyckelpersoner ber man organisationer att överväga:

• Hur förvaras nycklarna?
• Var är nycklarna indexerade?
• Hur upprätthålls livscykeln?
• Hur utförs revisioner av viktigt material?
• Hur är din förmåga att implementera kryptoagilitetskoncept?
• Hur tillämpas policyn för viktigt material?

Ärliga svar avslöjar var organisationen befinner sig för närvarande och vilka prioriterade förbättringar som är. Målet är inte att uppnå den teoretiska maximala mognadsnivån omedelbart utan att identifiera nästa konkreta förbättring och genomföra den.

Nivåer för mognadsmatris för nyckelhantering

• Ingen nyckelhanteringsmodell

  Denna modell upptäcks vanligtvis efter att en applikation redan är utvecklad, när någon inser att kryptografiska operationer som kräver nyckelmaterial är nödvändiga. Nycklar lagras ofta på utvecklarnas arbetsstationer eller är hårdkodade i källkoden. Detta medför en betydande risk: alla utvecklare med åtkomst till arkivet kan läsa nyckeln. Bristande medvetenhet är den främsta drivkraften för denna nivå. Organisationer här har ofta inget dedikerat säkerhetsteam och ingen insikt om att nyckelhantering är ett tydligt problem som kräver dedikerade kontroller. Utbildning är den viktigaste åtgärden på denna nivå.

• Applikationsspecifik nyckelhanteringsmodell

  Applikationer utvecklar sina egna verktyg eller använder applikationsspecifika nyckelhanteringslösningar från tredje part. På denna nivå kan HSM:er användas för att säkra nyckelmaterial för specifika applikationer, men det finns ingen företagsomfattande styrning. Nyckelhanteringsmetoder varierar beroende på applikationsteam, vilket skapar inkonsekvens, efterlevnadsluckor och driftskostnader. Användare är beroende av vad varje applikations utvecklare har byggt in i den.

• Semicentralt hanterad nyckelhanteringsmodell

  En organisation på denna nivå har implementerat ett centraliserat nyckelhanteringssystem. Två vanliga fellägen uppstår här. Det första: det implementerade verktyget har begränsad kompatibilitet och kan inte hantera alla applikationer som behöver det, så team fortsätter att hantera nycklar oberoende för arbetsbelastningar som verktyget inte stöder. Det andra: verktyget har bred kompatibilitet men organisationen migrerar fortfarande applikationer från äldre nyckelhanteringsmetoder, vilket skapar en period där vissa applikationer använder det centrala systemet och andra inte.

  Det är här effekten av "förtvivlanens dal" uppstår. Det finns ofta en klyfta mellan arkitekterna som designade systemet och de team som ansvarar för den dagliga driften. Teknologi ensam för inte en organisation uppåt på mognadskurvan; processförändring och utbildning är lika viktiga.

  Säkerhetsarkitekters och teknikledares jobb är att göra nyckelhantering praktisk, inte bara tekniskt korrekt. En teoretiskt ideal arkitektur som inget team faktiskt använder ger ingen säkerhetsförbättring.

• Hårdvarubaserad, centralt hanterad nyckelhanteringsmodell

  På denna nivå har en organisation implementerat en robust, serviceorienterad arkitektur för sin kryptografiska infrastruktur. Nyckelhanteringen är hårdvarubaserad med hjälp av FIPS 140-2 nivå 3 eller FIPS 140-3-validerade HSM:er. Alla applikationer använder det centrala nyckelhanteringssystemet snarare än att hantera nycklar separat. Policyer tillämpas på hårdvarunivå. Organisationen har kryptoagilitet: den kan rotera algoritmer och nyckeltyper mellan applikationer utan akut omstrukturering. Efterlevnadsbevis (granskningsloggar, dokumentation för nyckelceremonier, rotationsregister) är tillgängliga och aktuella.

Vad driver mognad inom nyckelhantering?

Flera faktorer styr ett företags mognadsnivå för nyckelpersoner:

• Organisationskultur från ledningen och neråt gällande applikationssäkerhet och kryptografi.
• Myndighets- och revisionskrav som föreskriver specifika viktiga hanteringskontroller.
• Applikationsbehov: utvecklare som förstår kryptografiska risker kommer att eskalera kraven för nyckelhantering till säkerhetsteamet.

Applikationsbehov och -krav är vanligtvis den primära drivkraften: i takt med att utvecklare begär kryptografiska nycklar för nya applikationer och stöter på begränsningarna med ad hoc-nyckelhantering, blir behovet av en mer mogen modell konkret. Att till exempel hjälpa organisationer att separera nyckelhantering från sin transaktionshanteringsinfrastruktur för att uppnå centraliserad säkerhet och hantering av nyckellivscykeln är ett av de vanligaste åtagandena inom nyckelhantering för företag. Med rätt kunskap och verktyg kan alla organisationer gå vidare till en hårdvarubaserad, centralt hanterad infrastruktur.

Bästa praxis för nyckelhantering som flyttar mognadsnålen

Flera metoder krävs konsekvent för att främja mognad i nyckelhantering:

• Hårdvarubaserad lagring för känsliga nycklar: FIPS 140-2 nivå 3 eller FIPS 140-3-validerade HSM:er krävs för CA:s privata nycklar, betalningsnycklar och kodsigneringsnycklar. Nycklar inom en FIPS-validerad HSM-gräns visas aldrig i klartext oavsett kompromiss på OS-nivå.
• Enhetlig policy för alla viktiga typer: Fragmenterade nyckelhanteringspolicyer gör det möjligt för team att hantera nycklar oberoende, vilket skapar efterlevnadsluckor och operativ inkonsekvens. Ett enda policyramverk som täcker alla nyckeltyper förhindrar fragmentering i takt med att komplexiteten ökar.
• Granulära men hanterbara åtkomstkontroller: Åtkomstkontroller måste vara tillräckligt specifika för att genomdriva minsta möjliga behörighet utan att vara så komplexa att administratörer kringgår dem. RBAC och MFA på nyckelhanteringssystemnivå, i kombination med hårdvarutillämpning i HSM, ger rätt balans.
• Livscykeltillämpning: Livscykeln för varje nyckel varierar beroende på användningsfall. Privata TLS-nycklar är på väg mot en livslängd på 47 dagar år 2029 enligt CA/Browser Forum-mandat. SSH-nycklar kräver minst årlig rotation. CA-rotnycklar kan ha flera års livslängd men kräver formella ceremoniprocedurer. Livscykelpolicyn måste definiera kryptoperioder för varje nyckeltyp och tillämpa dem automatiskt.
• Kryptoagilitet från dag ett: Att utforma system som stöder algoritmförändringar utan fullständig omstrukturering är avgörande. NIST:s avveckling av SHA-1, RSA-1024 och DSA visade att algoritmövergångar sker inom branschen enligt en definierad tidslinje. Post-kvantalgoritmmigrering är den nuvarande versionen av denna utmaning.

Vilka applikationsintegrationer är viktigast?

Applikationsintegrationer med databaskryptering (Oracle TDE, Microsoft SQL TDE), virtualiseringsplattformar (VMware vSphere), applikationsservrar (Apache Tomcat), molntjänster (Google Workspace, AWS, Azure) och anpassade dataskyddsprogram måste alla beaktas när man bestämmer vad en centraliserad nyckelhanteringsinfrastruktur behöver stödja.

Migreringsplaneringsprocessen innefattar: konfigurering av nyckelhanteringsservern; definition av vilka slutpunkter som har åtkomst till nyckelmaterial och hur den åtkomsten beviljas (via en extern identitetsleverantör eller direkt genererade autentiseringsuppgifter); och konfigurering av varje applikation för att använda det centrala nyckelhanteringssystemet snarare än sitt eget nyckelarkiv. Att migrera alla applikationer samtidigt är sällan praktiskt; en etappvis metod som prioriterar de nyckelhanteringsluckor som har högst risk först är mer effektiv.

Viktigt ägarskap i livscykeln: Vem är ansvarig i varje steg?

Livscykelstadiet	Aktivitet	Ägare	kontroll
Generation	Skapa nyckelmaterial med TRNG; välj algoritm och nyckellängd per policy	Nyckeladministratör eller automatiserat KMS	Algoritmpolicy; HSM-gränskrav för känsliga nycklar
Distribution	Leverera publika nycklar till betrodda system; distribuera symmetriska nycklar via KEK-omslagning	KMS; PKI för certifikatbaserade publika nycklar	Krypterad kanal; ingen klartextöverföring
lagring	Skydda privata och symmetriska nycklar i HSM eller godkänt valv	HSM-operatör; nyckelförvaltare	FIPS 140-2 Nivå 3+ hårdvara; ingen klartext utanför gränsen
Använda	Kryptera, dekryptera, signera, verifiera med nyckeln	Applikation eller tjänst godkänd av KMS	RBAC; revisionslogg över alla operationer
Rotation	Generera ersättningsnyckel; distribuera; kryptera om eller signera om; återkalla gammal nyckel	Automatiserad KMS eller nyckelförvaltare	Policydefinierad kryptoperiod eller händelseutlösare
Återkallande	Ogiltigförklara nyckel omedelbart vid kompromettering, avvikelse eller algoritmutfasning	Nyckelförvaltare eller automatiserad utlösare	Spridning till alla förlitande system; revisionsregister
Förstörelse	FIPS 140-kompatibel nollställning; förstörelse av revisionsbevis	Nyckelförvaltare; KMS	Nollställning enligt NIST SP 800-88; destruktionslogg

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 kräver omedelbar återkallelse och ersättning oavsett kryptoperiodens schema.
• Algoritmutfasning: NIST-avveckling av en algoritm 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 åtkomsten och rotera berörda nycklar.

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. Konsekvensbedömning av data: Identifiera alla data, system och identiteter som skyddas av den komprometterade nyckeln. Prioritera system med högst känslighet för åtgärd.
4. Meddelande till intressenter: meddela säkerhetsledningen, ägare av berörda applikationer och om reglerade uppgifter var inblandade, potentiellt tillsynsmyndigheter eller berörda individer.
5. 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.

Implementeringsarbetsflöde: Övergång till hårdvarubaserad, centralt hanterad nyckelhantering

1. Inventera alla befintliga nycklar: upptäcka varje nyckel som används i organisationen. Koppla varje nyckel till dess ägare, algoritm, nyckellängd, skapandedatum och de system och data den skyddar. Se CBOM-säkerhet för automatiserad kryptografisk inventering.
2. Klassificera nycklar efter risk: segmentera efter känslighet (CA-nycklar, betalningsnycklar, TLS-nycklar, SSH-nycklar, databas-DEK:er) och tilldela skyddskrav och rotationsscheman till varje klass.
3. Implementera ett centraliserat KMS: implementera ett nyckelhanteringssystem som upprätthåller policyer, spårar livscykelstadier och tillhandahåller revisionsloggning.
4. Skydda högkänsliga nycklar i HSM-hårdvara: Migrera CA-nycklar, KEK:er, betalningsnycklar och kodsigneringsnycklar till FIPS 140-2 nivå 3+ HSM-lagring. Se HSM som en tjänst.
5. Definiera åtkomstkontroller och roller: tilldela nyckelförvaltare; dokumentera roller och ansvar; tillämpa RBAC och MFA för alla nyckelhanteringsoperationer; tillämpa separation av arbetsuppgifter.
6. Automatisera livscykel och rotation: konfigurera KMS för att tillämpa kryptoperioder; automatisera certifikatlivscykeln med CertSecure-hanterare och SSH-nyckellivscykel med SSH-säker.
7. Upprätta revisionsloggning och övervakning: logga alla viktiga operationer; varna för avvikande mönster; centralisera loggar i SIEM.
8. Testa incidenthanteringsplanen: genomföra bordsövningar årligen; verifiera att återkallelsen sprider sig till alla förlitande system.

Slutsats

Kryptering är välkänt och allmänt tillgängligt. Det är nyckelhantering som företag faktiskt misslyckas med. Mognadsmatrisen för nyckelhantering ger organisationer ett ramverk för att ärligt bedöma var de står och vad nästa förbättringssteg är. De flesta företag befinner sig på nivå 2 eller nivå 3 och står inför en skillnad mellan vad som implementerades och vad som faktiskt har antagits i hela organisationen. Vägen till hårdvarubaserad, centralt hanterad nyckelhantering är inte ett enda projekt utan en serie konkreta förbättringar: inventering, klassificering, hårdvarulagring för de känsligaste nycklarna, centraliserad styrning, automatiserad livscykelhantering och kontinuerlig revisionsbevis. För nästa steg, se 10 bästa praxis för företagskrypteringsnyckelhantering och bästa praxis för hantering av publika och privata nycklar.

Vanliga frågor om partihandel med mat och dryck

Varför är nyckelhantering svårare än kryptering?

Krypteringsalgoritmer är standardiserade och sällan källan till verkliga fel. Nyckelhantering är där fel uppstår: nycklar lagras i klartext, hårdkodade i kod, roteras aldrig eller återkallas inte när en anställd slutar. Algoritmen må vara AES-256, men en nyckel lagrad i en tillgänglig konfigurationsfil ger föga verkligt skydd.

Vad är mognadsmodellen för nyckelpersoner?

Fyra nivåer: 1) Ingen nyckelhantering (nycklar i kod eller på arbetsstationer). 2) Applikationsspecifik (varje app hanterar sina egna nycklar). 3) Semi-centralt hanterad (centralt verktyg driftsatt men inte helt implementerat). 4) Hårdvarubaserad, centralt hanterad (FIPS-validerade HSM:er, företagsomfattande styrning, kryptoagilitet). De flesta företag befinner sig på nivå 2 eller 3.

Vad bör en nyckelhanteringspolicy innehålla?

Krav för nyckelgenerering (algoritm, nyckellängd, entropikälla); lagringskrav (HSM-hårdvara för känsliga nycklar); åtkomstkontroller (RBAC, MFA, separation av uppgifter); livscykelstadier med kryptoperioder; revisions- och loggningskrav; incidenthanteringsprocedurer; och säkerhetskopierings- och återställningskrav med M-of-N-förvaltarkontroller.

Vilka regelverk kräver formell nyckelhantering?

PCI DSS v4.0 Krav 3.7 (delad kunskap, dubbel kontroll, rotation); HIPAA-säkerhetsregel (hantering av ePHI-krypteringsnycklar); NIST SP 800-57 (refererad av FedRAMP, FISMA, DoD); GDPR Artikel 32 (lämpliga tekniska åtgärder); ISO/IEC 27001:2022 Kontroll 8.24 (användning av kryptografi).

Vad är kryptoagilitet och varför är det viktigt?

Kryptoagilitet är möjligheten att byta kryptografiska algoritmer utan större omskrivningar av applikationer. Det är viktigt eftersom NIST har föråldrade algoritmer (SHA-1, RSA-1024, DSA) och migrering efter kvantkryptografi krävs nu i alla system som använder asymmetrisk kryptografi. Hårdvarubaserad, centralt hanterad nyckelhantering är grunden som gör kryptoagilitet möjlig.

Hur bedömer ni er organisations ranking vad gäller mognad hos nyckelpersoner?

Besvara dessa sex frågor ärligt: ​​Hur lagras nycklar? Var indexeras de? Hur upprätthålls livscykeln? Hur utförs revisioner? Hur är er förmåga att tillämpa kryptoagilitet? Hur tillämpas policyn? Svaren visar nuvarande mognadsnivå och de prioriterade förbättringsområdena.