Dedikerade kontra delade HSM:er i PKIaaS: Avvägningar mellan säkerhet och efterlevnad

När en PKIaaS-leverantör säger att deras tjänst använder FIPS-validerade HSM:er, har de berättat om minimumkraven. Vad de inte har berättat är om dessa HSM:er är dedikerade till din organisation, om dina CA-nycklar delar en fysisk enhet med andra kunders nycklar, hur partitionsisoleringsmodellen ser ut på firmwarenivå och om en säkerhetsincident som påverkar en annan kunds partition kan ha någon operativ inverkan på din.

Detta är inte teoretiska skillnader. HSM-arkitekturen under en PKIaaS-tjänst avgör din faktiska nyckelisolering, din exponering för sprängradie, din förmåga att uppfylla reglerade branschkrav och försvarbarheten av ditt PKI-program i en revision. Ändå beskriver de flesta PKIaaS-marknadsföringssidor FIPS-validering i en enda mening och går vidare.

Det här inlägget förklarar de tekniska och efterlevnadsrelaterade avvägningarna mellan dedikerade och delade HSM-modeller i PKIaaS-distributioner, täcker de kontroller som är viktiga (partitionering, M-of-N, BYOK, isolering av revisionsloggar) och ger säkerhetsarkitekter och efterlevnadsteam ramverket för att utvärdera vad deras specifika krav faktiskt kräver.

Snabbt svar: Vad är kärnskillnaden?

En dedikerad HSM innebär att den fysiska enheten som lagrar dina privata CA-nycklar är exklusivt allokerad till din organisation. Inget annat kryptografiskt material eller operationer från kunder finns på den hårdvaran. En delad HSM innebär att flera kunders nycklar lagras i separata logiska partitioner på samma fysiska enhet. Partitionsisolering tillämpas i firmware, inte i separat hårdvara. Båda kan uppfylla FIPS 140-2- eller 140-3 nivå 3-validering. Valet mellan dem avgör sprängradie, isolering av revisionsloggar, efterlevnad av regelverk och vissa kategorier av risker i leveranskedjan.

Key Takeaways

• FIPS 140-2 Nivå 3 och FIPS 140-3 Nivå 3 är de relevanta valideringsnivåerna för CA-nyckellagring. Båda kräver fysiskt manipuleringsskydd som nollställer nycklar om höljet bryts. FIPS 140-3 är den nuvarande standarden då NIST övergår från 140-2; verifiera alltid den specifika valideringsstatusen via NIST CMVP-databasen.
• Delad HSM-partitionering är kryptografiskt sund i väl implementerade företags-HSM:er. Isoleringsgränsen tillämpas på HSM-firmwarenivå och är samma mekanism som används i moln-HSM-tjänster från större leverantörer. Risken är inte en bruten isoleringsgräns; det är den delade fysiska sprängradien och kraven på efterlevnadsbevis för vissa reglerade ramverk.
• M-of-N-kontroller (kvorumautentisering) är den kritiska åtkomstkontrollmekanismen för rot-CA-operationer oavsett om HSM är dedikerad eller delad. De förhindrar att en enskild leverantörsadministratör ensidigt utför obehöriga operationer med hög behörighet.
• BYOK (Bring Your Own Key) låter kunder generera CA-rotnyckelmaterial i sin egen kontrollerade miljö och importera det till leverantörens HSM, vilket säkerställer att leverantören aldrig har haft förvaring över en nyckel som inte redan var under kundens kontroll.
• Reglerade miljöer som FedRAMP High, CMMC Level 3, vissa DORA- och NIS2-implementeringar och ITAR/DFARS-relaterade försvarsindustriella basorganisationer kan ha efterlevnadskrav som i praktiken kräver dedikerad HSM-hårdvara snarare än partitionsisolering. Juridiska rådgivare och efterlevnadsrådgivare bör bekräfta det specifika kravet innan en delad modell accepteras.

HSM-grunder för PKIaaS-köpare

En hårdvarusäkerhetsmodul är en manipulationssäker kryptografisk enhet som genererar, lagrar och skyddar kryptografiska nycklar. I ett PKI-sammanhang skyddar HSM:er de privata nycklar från CA som signerar varje certifikat som PKI utfärdar. Om en privat nyckel från CA extraheras från HSM:n av en angripare kan angriparen utfärda bedrägliga certifikat under din CA-hierarki på obestämd tid tills CA återkallas och hierarkin återuppbyggs. Det är därför nyckellagring och nyckelisolering är de säkerhetsegenskaperna med högsta prioritet för alla PKI-distributioner.

FIPS 140-2 och FIPS 140-3 definierar fyra säkerhetsnivåer för kryptografiska moduler. Nivå 3, den relevanta nivån för CA-nyckellagring, kräver fysiskt manipuleringsskydd och manipuleringsbevismekanismer som nollställer alla klartext-CSP:er (kritiska säkerhetsparametrar, som inkluderar CA:s privata nycklar) om modulens hölje penetreras. Nivå 3 kräver också identitetsbaserad autentisering, vilket innebär att HSM associerar specifika autentiseringsuppgifter med specifika roller innan åtgärder tillåts. Nivå 4 lägger till ytterligare skydd mot miljöfel och förekommer sällan i kommersiella PKI-distributioner.

FIPS 140-3, publicerad 2019 och anpassad till ISO/IEC 19790:2012, ersätter FIPS 140-2. NIST började acceptera 140-3-inlämningar i september 2020 och slutade acceptera 140-2-inlämningar i september 2021 (även om moduler som validerats enligt 140-2 behåller sin valideringsstatus). De flesta HSM:er som för närvarande finns i PKIaaS-produktionsmiljöer har FIPS 140-2 nivå 3-validering; 140-3 nivå 3-certifieringar finns för nyare modeller från stora leverantörer inklusive Thales, Utimaco och andra. Verifiera eventuella leverantörspåståenden genom att söka upp NIST CMVP-certifikatnumret i den offentliga databasen snarare än att förlita sig på ett marknadsföringsuttalande.

Dedikerade HSM:er: Vad de är och vad de faktiskt tillhandahåller

I en dedikerad HSM-distribution allokeras en specifik fysisk enhet (eller uppsättning enheter) exklusivt till en kund. Enheten är rackad i leverantörens datacenter, men inga andra kunders nycklar, partitioner eller kryptografiska operationer finns på den hårdvaran. Kundens CA-privata nycklar är de enda nycklarna på enheten.

Säkerhetsegenskaper hos dedikerade HSM:er

Den primära säkerhetsfördelen med en dedikerad HSM är fysisk inneslutning av sprängradien. Om enheten är fysiskt komprometterad (manipulerad, utsatt för en sidokanalattack som kräver fysisk närhet, eller utsatt för en sårbarhet i firmware som gör att en partitions nyckelmaterial kan läsas av en annan partitions process), är effekten begränsad till din organisation. Det finns ingen risk att en säkerhetshändelse som påverkar en annan kunds partition sprider sig till ditt nyckelmaterial.

En sekundär fördel är granskningsbarhet. Med en dedikerad enhet kan varje operation som loggas i HSM:s revisionslogg hänföras till dina CA-operationer. Det finns inget brus från andra kunders operationer i samma logg, och det råder ingen tvetydighet om huruvida en loggad händelse orsakades av ditt system eller en annan hyresgästs. Detta förenklar både rutinmässig efterlevnadsrapportering och incidentutredning.

En tredje fördel är driftsexklusivitet. Uppdateringar av firmware, HSM-underhåll och alla leverantörsinitierade administrativa åtgärder på enheten kan endast påverka din infrastruktur. En firmwareuppdatering som krävs för en annan kunds användningsfall kan inte tillämpas på din enhet utan din medverkan.

Kostnads- och tillgänglighetsavvägningar för dedikerade HSM:er

Dedikerade HSM:er är dyrare. Leverantören kan inte amortera hårdvarukostnaden över flera kunder, så kostnaden per kund är högre. FIPS 140-3 Level 3 HSM-enheter i företagsklass från större leverantörer kostar 20 000 till 60 000 dollar eller mer per enhet, och en PKI-distribution i produktion kräver vanligtvis flera enheter (offline-rot-CA, online-utfärdande CA:er, standby med hög tillgänglighet). När en kund betalar för en dedikerad HSM i ett PKIaaS-engagemang betalar de i praktiken för exklusiv användning av hårdvara som leverantören annars skulle dela.

Hög tillgänglighet med dedikerade HSM:er kräver även dedikerad standby-hårdvara. En enda dedikerad HSM för en utfärdande CA utan hot standby är en enda felpunkt (SFC). Väl utformade dedikerade HSM-distributioner för PKIaaS inkluderar minst en primär enhet och en redundansenhet, båda dedikerade till kunden, vilket ytterligare ökar kostnaden.

Delade HSM:er och partitionering: Hur isoleringen faktiskt fungerar

I en delad HSM-distribution hanterar en enda fysisk enhet flera kundmiljöer i separata logiska partitioner. Varje partition har sin egen oberoende nyckellagring, sina egna åtkomstuppgifter och sin egen granskningslogg. HSM-firmwaren upprätthåller partitionsgränserna: åtgärder som utförs under autentiseringsuppgifterna för en partition kan inte komma åt nyckelmaterialet från en annan partition.

Hur partitionsisolering upprätthålls

Moderna företags-HSM:er (produkter från Thales, Utimaco och liknande leverantörer) implementerar partitionsisolering på firmwarenivå med hjälp av en kombination av separata nyckellagrar per partition och autentiseringsbehörig åtkomst till varje partitions operationer. HSM-operativsystemet framtvingar att autentiseringstokens för partition A inte kan användas för att komma åt eller hantera nycklar i partition B. Denna isolering valideras som en del av FIPS 140-certifieringsprocessen för modulen.

Partitionsmodellen är samma arkitektur som används av moln-HSM-tjänster från stora molnleverantörer, där tusentals kunders nyckelmaterial isoleras i partitioner inom leverantörens HSM-flotta. När den är korrekt implementerad är partitionsisolering kryptografiskt sund på programvaru- och firmwarenivå. Riskprofilen skiljer sig från en dedikerad HSM inte för att partitionsgränsen kan korsas av normal drift, utan på grund av följande kvarvarande risker.

Kvarvarande risker i delade HSM-distributioner

De kvarvarande riskerna i en delad HSM-modell som inte finns i en dedikerad modell är specifika och värda att namnge exakt.

Den första är fysisk explosionsradie. Om en angripare uppnår fysisk åtkomst till HSM-enheten (och därmed omintetgör datacentrets fysiska säkerhetskontroller) är alla partitioner på den enheten i fara samtidigt. En lyckad fysisk attack som utlöser manipuleringssvarsnollställning raderar alla kunders nycklar på den enheten, inte bara en. En lyckad fysisk attack som på något sätt kringgår nollställning (en extremt svår men teoretiskt relevant attackvektor för mycket sofistikerade hotaktörer) kan exponera alla partitionsinnehavares nyckelmaterial samtidigt.

Den andra är sårbarhetssprängningsradie för firmware. En nolldagarssårbarhet i HSM-firmware som tillåter åtkomst till nycklar över partitioner, om en sådan upptäcktes och utnyttjades, skulle påverka alla partitionsinnehavare på enheten samtidigt. Ingen sådan sårbarhet är känd i för närvarande validerade företags-HSM:er, men den teoretiska risken finns och är anledningen till att vissa miljöer med hög säkerhet kräver dedikerad hårdvara.

Det tredje är sammanblandning av revisionsloggar. I en delad HSM utan korrekt loggisolering per partition kan en leverantörs operativa revisionslogg innehålla händelser från flera kunders partitioner i en enda ström. Detta påverkar inte nyckelsäkerheten men kan komplicera produktionen av revisionsbevis och incidentutredning. Väl utformade delade distributioner underhåller revisionsloggar per partition som är åtkomliga för kunden oberoende av varandra.

Den fjärde är koppling mellan leveranskedjan och underhåll. En firmwareuppdatering som tillämpas på en delad apparat för en kunds driftskrav tillämpas på alla partitioner på den apparaten. Detta skapar ett beroendeförhållande mellan kunder som delar en apparat som inte existerar med dedikerad hårdvara.

M-of-N-kontroller: Den kritiska mekanismen oavsett HSM-modell

Oavsett om en HSM är dedikerad eller delad, är M-of-N-kontroll (även kallad kvorumautentisering eller hemlig delning) den åtkomstkontrollmekanism som förhindrar att en enskild administratör utför obehöriga åtgärder med hög behörighet. Det krävs för nyckelceremonier för rot-CA och bör krävas för alla åtgärder som kan äventyra CA-hierarkin: generering av rot-CA-nycklar, nyckelexport, partitionsinitiering och vissa åtgärder på firmware-nivå.

I en M-av-N-konfiguration kräver HSM att minst M av N utsedda nyckelinnehavare autentiserar sig innan operationen kan fortsätta. En vanlig konfiguration för rot-CA-ceremonier är 3-av-5: 3 av 5 utsedda förvaltare måste presentera sina autentiseringstokens (vanligtvis smartkort eller kryptografiska tokens) innan HSM tillåter operationen. En 3-av-5-konfiguration innebär:

• Ingen enskild administratör kan utföra en rot-CA-ceremoni ensidigt, vilket eliminerar risken för insiderhot för operationer med högst behörighet.
• Ceremonin kan fortsätta så länge minst 3 av de 5 vårdnadshavarna är tillgängliga, vilket ger operativ motståndskraft även om 2 vårdnadshavare inte är tillgängliga.
• Ceremonin dokumenteras, bevittnas och loggas med identiteterna på de specifika vårdnadshavare som autentiserade, vilket skapar en revisionslogg som uppfyller CP/CPS-kraven.

När du utvärderar PKIaaS-leverantörer, bekräfta om M-of-N-kontroller tillämpas på alla HSM-operationer med hög behörighet, vilka de utsedda förvaltarna är (endast leverantörspersonal eller även kundnominerade förvaltare) och om ceremonibevispaketet är tillgängligt för dina revisorer. En leverantör som inte kan beskriva sin M-of-N-konfiguration eller som endast tillämpar kvorumkontroller för generering av rot-CA men inte för andra operationer med hög behörighet, arbetar inte enligt den standard som krävs för en PKI på företagsnivå.

BYOK: När viktig ursprungsinformation spelar roll

Bring Your Own Key (BYOK) är en driftsättningsmodell där kunden genererar CA-nyckelmaterial i sin egen hårdvara eller kontrollerade miljö och sedan importerar det till leverantörens HSM-infrastruktur. Detta ger kunden en försäkran om nyckelns ursprung: den privata nyckeln för rot-CA:n genererades av kunden, under kundens kontroll, innan den någonsin laddades in i ett system de inte fysiskt använder.

Nyckelns ursprung är viktigt av två skäl. Det första är regulatoriskt och avtalsenligt. Vissa regelverk, särskilt de inom försvars- och finanssektorn, kräver att generering av kryptografiska nycklar sker i utrustning som den reglerade enheten kontrollerar direkt. Om PKIaaS-leverantören genererar rot-CA-nyckelparet i sin HSM-infrastruktur finns det en period (om än kort) under vilken nyckeln finns i hårdvara som kunden inte kontrollerar och kunden inte kan självständigt verifiera genereringsproceduren. BYOK eliminerar detta fönster.

Det andra skälet är organisationsförtroende. Vissa organisationers säkerhetspolicyer kräver att privata nycklar aldrig genereras i tredjepartshårdvara, oavsett hårdvarans tekniska säkerhetsegenskaper. Detta är ett policyval snarare än en teknisk nödvändighet, men det är ett legitimt sådant för miljöer med hög tillförlitlighet. BYOK uppfyller detta.

Mekaniken bakom BYOK i ett HSM-sammanhang innebär vanligtvis att kunden genererar nyckelparet i sin egen HSM med hjälp av en dokumenterad ceremoni; att nyckeln packas in för säker transport (med hjälp av leverantörens HSM:s publika nyckel eller en transportnyckel som etablerats i en nyckelpackningsceremoni); att den packade nyckeln överförs till leverantören; och att leverantörens HSM packar upp och lagrar nyckeln i kundens partition. Leverantörens HSM:s packningsnyckel säkerställer att nyckelmaterialet är skyddat under transport och endast kan packas upp av rätt destinations-HSM.

Inte alla PKIaaS-leverantörer stöder BYOK. För organisationer där nyckelursprung är ett krav är detta ett icke-förhandlingsbart utvärderingskriterium. Fråga om BYOK stöds, vad den dokumenterade proceduren är och om en nyckelinpackningsceremoni kan genomföras med teamets utsedda vårdnadshavare närvarande som vittnen.

Isolering av granskningslogg: Vad du borde kunna se

CA-granskningsloggar är en av de primära beviskällorna för efterlevnadsramverk, inklusive SOC 2, CMMC, FedRAMP, PCI DSS och ISO/IEC 27001. En CA-granskningslogg måste registrera: varje certifikatutfärdande, förnyelse och återkallelsehändelse; varje administrativ åtgärd på CA-konfigurationen och certifikatprofilerna; varje HSM-åtgärd (nyckelgenerering, signeringsåtgärder, nyckelexportförsök); och varje åtkomsthändelse av leverantörens driftspersonal till din partition eller CA-miljö.

I en delad HSM-miljö är frågorna att ställa sig: loggas din partitions HSM-händelser separat från andra kunders partitioner; vem hos leverantören har åtkomst till din partitions granskningslogg; kan du komma åt din granskningslogg oberoende av varandra via ett självbetjäningsgränssnitt eller API-export; och vad är logglagringsperioden. En leverantör som blandar flera kunders HSM-händelser i en enda driftslogg, eller som gör åtkomst till granskningsloggar till en supportärendeprocess, skapar efterlevnadsproblem precis vid den punkt där du behöver maximal insyn.

I en dedikerad HSM-miljö förenklas frågorna i granskningsloggen: varje händelse i HSM:s logg kan hänföras till din CA-verksamhet, och det finns ingen tvetydighet kring händelseattributionen. Frågorna blir enklare: kan du komma åt loggen direkt, hur länge sparas den och kan den vidarebefordras till din SIEM i realtid.

För båda modellerna, bekräfta om leverantörens driftspersonals åtkomst till din partition eller CA-miljö i sig är loggad och granskningsbar. De starkaste implementeringarna kräver att all leverantörs administrativa åtkomst till en kunds partition genererar en händelse i den kundåtkomliga granskningsloggen, vilket ger fullständig insyn i leverantörens åtgärder som påverkar din CA-infrastruktur.

Kravet på offline-rot-CA och interaktionen mellan HSM-modellen

Oavsett om de utfärdande CA-HSM:erna är dedikerade eller delade, bör rot-CA:n lagras på en HSM som är air-gappad (fysiskt frånkopplad från nätverk) och endast kopplad online för de specifika, dokumenterade operationer som kräver rot-CA-signering (utfärdande eller förnyelse av underordnade CA-certifikat). Detta är ett PKI-arkitekturkrav som existerar oberoende av frågan om delad kontra dedikerad.

I ett PKIaaS-sammanhang innebär att rot-CA:ns HSM är airgappad att leverantören upprätthåller en fysiskt isolerad HSM i en säker anläggning, med dokumenterade procedurer för att koppla den online, utföra operationer under M-of-N-kontroll och återföra den till offline-lagring. Vissa leverantörer implementerar detta med en dedikerad fysisk apparat som aldrig är nätverksansluten; andra använder en moln-HSM:s offline-nyckelfunktion. De kritiska frågorna är om rot-CA:n verkligen är airgappad (inte bara "offline enligt policy" utan faktiskt frånkopplad), vad den dokumenterade proceduren för rot-CA-operationer är och om ceremonibevispaketet är tillgängligt för dina revisorer.

En väl utformad PKIaaS-tjänst separerar rot-CA:ns HSM (alltid offline, endast åtkomlig för CA-ceremonier) från utfärdande CA-HSM:er (online, som betjänar certifikatförfrågningar). Frågan om delad kontra dedikerad gäller främst de utfärdande CA-HSM:erna. Rot-CA-HSM:n är mest försvarbar som en dedikerad offline-enhet oavsett den utfärdande CA-modellen.

Ta med din egen HSM: Ett tredje arkitekturalternativ

Vissa PKIaaS-plattformar stöder en BYOH-modell (Bring Your Own HSM), där kunden tillhandahåller och underhåller HSM-hårdvaran medan leverantörens PKI-programvara och hanteringslager fungerar ovanpå den. I den här modellen kontrollerar kunden den fysiska enheten, HSM-autentiseringsuppgifterna och partitionskonfigurationen, medan leverantören hanterar CA-programvara, automatisering av certifikatutfärdande, CLM-integration och driftssupport.

BYOH är inte detsamma som BYOK. BYOH innebär att kunden äger och kontrollerar den fysiska hårdvaran; BYOK innebär att kunden genererar nyckelmaterialet men hårdvaran kan fortfarande drivas av leverantören. BYOH uppfyller de mest krävande kraven på nyckelkontroll eftersom kunden behåller den fysiska vårdnaden om enheten som lagrar nycklarna.

Avvägningen med BYOH är driftskomplexitet. Kunden har nu hårdvara att anskaffa, underhålla och så småningom uppdatera. Uppdateringar av HSM-firmware blir kundens ansvar. HA-redundansväxling mellan kundägda HSM:er kräver att kunden tillhandahåller redundant hårdvara. BYOH är lämpligt för organisationer där fysisk nyckelförvaring inte är förhandlingsbar och där den operativa omkostnaden för att hantera hårdvaran är acceptabel med tanke på den efterlevnad eller riskposition som den uppfyller.

Encryption Consultings HSM as a Service- erbjudande tillhandahåller FIPS 140-3-certifierad HSM-kapacitet för organisationer som behöver dedikerad, kundanpassad HSM-infrastruktur utan att själva hantera hårdvaruanskaffning, datacenter och underhållscykel.

Reglerade branschkrav: Vad ramverk faktiskt kräver

Den efterlevnadsfråga som de flesta säkerhetsarkitekter ställer sig är om deras specifika regelverk kräver en dedikerad HSM eller om en delad modell med FIPS-validerad partitionsisolering är tillräckligt. Svaret är ramverksspecifikt, och nyanserna spelar roll.

FedRAMP Hög

FedRAMP High kräver FIPS 140-2 nivå 3 (eller 140-3 nivå 3) validerade kryptografiska moduler för nyckellagring. Det föreskriver inte uttryckligen dedikerade fysiska HSM:er kontra partitionerade delade HSM:er. De gräns- och isoleringskontroller som krävs enligt FedRAMP High, i kombination med kravet att visa kontrolleffektivitet för en tredjepartsbedömningsorganisation (3PAO), skapar dock en praktisk preferens för dedikerad hårdvara i många FedRAMP High-implementeringar. Infrastruktur med flera hyresgäster som betjänar både FedRAMP- och icke-FedRAMP-arbetsbelastningar från samma apparat skapar komplikationer med auktoriseringsgränser som dedikerad hårdvara eliminerar. Om din PKIaaS-distribution måste vara inom en FedRAMP-auktoriserad auktoriseringsgräns, bekräfta med din 3PAO om leverantörens delade HSM-modell ligger inom ramen och om partitionsisolering uppfyller de specifika kontrollkraven för SC-28 (Skydd av information i vila) och IA-7 (Autentisering av kryptografisk modul).

CMMC Nivå 2 och Nivå 3

CMMC Nivå 2, baserat på NIST SP 800-171 revision 3, kräver skydd av kontrollerad oklassificerad information (CUI) med hjälp av FIPS-validerade kryptografiska moduler. De relevanta kontrollerna (3.13.10 för etablering och hantering av kryptografiska nycklar, 3.13.11 för användning av FIPS-validerad kryptografi) refererar till FIPS 140-2/3-validering utan att specificera dedikerad kontra delad hårdvara. CMMC Nivå 3 lägger till krav hämtade från NIST SP 800-172 för förbättrat skydd mot avancerade ihållande hot (APT), vilket introducerar strängare gränskontroller. För CUI-hanterande PKI-infrastruktur på nivå 3 gynnar det starkare isoleringsargumentet dedikerade apparater, men det specifika kontrollspråket föreskriver inte uttryckligen dem. Bekräfta med en CMMC tredjepartsbedömningsorganisation (C3PAO) för din specifika bedömningsgräns.

DORA och NIS2

EU:s lag om digital operativ motståndskraft (DORA), som trädde i kraft i januari 2025, och direktivet om nätverks- och informationssäkerhet (NIS2), som trädde i kraft i oktober 2024, ställer båda krav på IKT-riskhantering och IKT-beroenden hos tredje part för reglerade finansiella enheter respektive operatörer av kritisk infrastruktur. Artikel 9 i DORA kräver användning av krypteringsstandarder som är lämpliga för risken, vilket inkluderar nyckelskydd i hårdvarusäkerhetsmoduler, men föreskriver inte dedikerad kontra delad arkitektur. NIS2 hänvisar på liknande sätt till lämpliga tekniska säkerhetsåtgärder utan att specificera HSM-hyresmodellen. Vissa medlemsstaters nationella implementeringar av NIS2 inkluderar dock krav på datalokalisering som, i kombination med behovet av att visa kontroll över kryptografiskt nyckelmaterial, skapar praktiska krav för dedikerade eller BYOH HSM-konfigurationer. Granska den specifika nationella implementeringen som gäller för din verksamhet.

ITAR och DFARS

Organisationer som omfattas av ITAR (International Traffic in Arms Regulations) eller DFARS (Defense Federal Acquisition Regulation Supplement) för försvarsrelaterat kontraktsarbete står inför de strängaste praktiska begränsningarna för lagring av nyckelringar med flera hyresgäster. ITAR förbjuder obehörigt avslöjande av försvarsartiklar och tekniska data till utländska medborgare. En PKIaaS-leverantör som driver en HSM med flera hyresgäster där leverantörens driftspersonal (som kan vara utländska medborgare) har administrativ åtkomst till den fysiska enheten som är värd för dina CA-nycklar skapar en potentiell ITAR-exponering som dedikerad hårdvara (med dokumenterade åtkomstkontroller som begränsar fysisk åtkomst till godkända amerikanska medborgare) kan hantera. Organisationer som omfattas av ITAR bör låta exportkontrollrådgivare granska alla PKIaaS-distributioner, delade eller dedikerade, före implementering.

Utvärderingsramverk: Matcha HSM-modellen med dina krav

Tabellen nedan sammanfattar de viktigaste faktorerna och deras konsekvenser för att välja mellan dedikerade och delade HSM-modeller i en PKIaaS-distribution.

Faktor	Delad HSM med partitionering	Dedikerad HSM
Fysisk explosionsradie	Delas med andra partitionshållare på samma apparat	Begränsat till endast din organisation
Sårbarhet i firmware explosionsradie	Delad mellan alla partitioner på enheten	Begränsat till endast din organisation
Kryptografisk nyckelisolering	Partitionsgränser som förstärks av firmware (validerade i FIPS-certifiering)	Fysisk hårdvarugräns; inga andra nycklar finns
Isolering av granskningslogg	Loggar per partition är tillgängliga i väl utformade distributioner; verifiera explicit	Alla logghändelser som endast kan hänföras till dina CA-åtgärder
Beroende på firmwareuppdatering	Delad; uppdateringar som tillämpas på enheten påverkar alla partitioner	Oberoende; uppdateringar tillämpas endast med din medverkan
M-of-N-kontrollens tillämpbarhet	Krävs oavsett; gäller på partitionsnivå	Krävs oavsett; gäller på apparatnivå
BYOK-stöd	Möjligt; beror på leverantörens implementering	Möjligt; beror på leverantörens implementering
BYOH-alternativ	Ej tillämpligt (leverantören äger hårdvaran)	Möjligt; kunden äger och använder apparaten
Kostnad i PKIaaS	Lägre; hårdvarukostnaden amorteras över kunderna	Högre; full hårdvarukostnad allokerad till en kund
Hög tillgänglighet	Leverantören hanterar HA över hela flottan; din partition gynnar	Kräver dedikerad standby-hårdvara för samma kund
FedRAMP Hög efterlevnad	Möjligt med korrekta gränskontroller; bekräfta med 3PAO	Renare auktoriseringsgränser; generellt föredraget
CMMC nivå 3	Möjligt; bekräfta med C3PAO för specifik gräns	Starkare hållning för APT-relevanta gränser
ITAR/DFARS-relaterade organisationer	Kräver noggrann analys; fysisk åtkomst med flera hyresgäster är en riskfaktor	Föredras med dokumenterade fysiska åtkomstkontroller

Frågor att ställa alla PKIaaS-leverantörer om deras HSM-modell

När man utvärderar en PKIaaS-leverantör är det dessa specifika frågor att ställa om deras HSM-arkitektur snarare än att acceptera ett generellt uttalande om FIPS-efterlevnad.

• Dedikerad eller delad? Lagras mina CA-nycklar i en dedikerad fysisk HSM-enhet eller i en logisk partition inom en delad enhet? Om de delas, hur många andra kunder delar enheten?
• FIPS-valideringsdetaljer: Vad är NIST CMVP-certifikatnumret för den HSM-modell som används? Är valideringen FIPS 140-2 eller 140-3? Vilken är den specifika valideringsnivån (nivå 3 eller nivå 4)? Finns den aktuella modulen på NIST:s aktiva valideringslista?
• M-av-N-konfiguration: Vad är M-of-N-konfigurationen för rot-CA-operationer? Vilka är de utsedda förvaltarna (leverantörspersonal, kundpersonal eller en blandning)? Kan kundnominerade förvaltare ingå i kvorumet? Vilka operationer kräver M-of-N-autentisering?
• BYOK-stöd: Stöds BYOK? Vilken är den dokumenterade proceduren för nyckelimport? Kan en nyckelinpackningsceremoni genomföras med kundens vittnen närvarande?
• BYOH-stöd: Kan jag tillhandahålla min egen HSM-hårdvara för CA-nyckellagringslagret? Vilka integrationskrav gäller?
• Isolering av granskningslogg: Är min partitions HSM-granskningslogg isolerad från andra kunders loggar? Vem hos leverantören har åtkomst till min partitions logg? Kan jag komma åt den separat via en instrumentpanel eller ett API? Hur länge sparas loggar? Kan loggar vidarebefordras till min SIEM?
• Administrativ åtkomst till leverantören: När leverantörens driftpersonal får åtkomst till min partition eller CA-miljö för support eller underhåll, loggas själva den åtkomsten i min revisionslogg?
• Root CA offline-status: Är rot-CA:ns HSM verkligen fysiskt frånkopplad (air-gapped), inte bara logiskt offline? Vilken är den dokumenterade proceduren för rot-CA-ceremonier?
• Process för uppdatering av firmware: Hur hanteras uppdateringar av HSM-firmware? Får jag ett meddelande innan uppdateringar installeras? Krävs godkännande?

Hur krypteringskonsulting kan hjälpa

Encryption Consulting designar och driver PKI-infrastruktur över dedikerade och delade HSM-modeller och tillhandahåller oberoende rådgivningsuppdrag för att hjälpa säkerhetsarkitekter och compliance-team att utvärdera HSM-arkitektur mot deras specifika regel- och riskkrav.

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande använder FIPS 140-3 nivå 3 HSM-baserade CA-nycklar i dedikerade partitioner per kund, med en alltid offline rot-CA, M-of-N-nyckelceremoni med fullständig bevisdokumentation och kundkontrollerad nyckeldeposition. Kontakta oss på Krypteringskonsulting för att diskutera era HSM-krav och hur de matchar vår tjänstearkitektur.
• HSM som en tjänst: För organisationer som behöver dedikerad FIPS 140-3-certifierad HSM-kapacitet utan att hantera hårdvaruanskaffning, datacenter och underhållscykler, erbjuder Encryption Consultings HSM som en tjänst tillhandahåller dedikerad hårdvara med fullständig kundkontroll över partitionskonfiguration, autentiseringsuppgifter och åtkomst till granskningsloggar.
• PKI-bedömningstjänst: För organisationer med en befintlig PKIaaS-distribution som behöver validera om deras leverantörs HSM-modell uppfyller deras efterlevnadskrav, kan Encryption Consultings PKI-bedömningstjänst utvärderar HSM-arkitekturen, partitionskonfigurationen, M-of-N-kontrollerna, isoleringen av granskningsloggar och efterlevnadsstatus mot de specifika ramverk som gäller för din organisation.
• PKI-tjänster: För organisationer som bygger eller moderniserar en självhanterad PKI och behöver expertvägledning om val av HSM, design av rot-CA-ceremonier, CP/CPS-utveckling och löpande operativ styrning, är Encryption Consultings PKI-tjänster täcka hela engagemanget från initial arkitektur till liveförsäljning.
• PQC-beredskap: Postkvantövergången påverkar HSM-infrastrukturen direkt: HSM:er måste stödja de NIST-slutgiltiga algoritmerna (ML-KEM från FIPS 203, ML-DSA från FIPS 204, SLH-DSA från FIPS 205, allt slutfört i augusti 2024) antingen genom firmwareuppdateringar eller hårdvaruutbyte. Encryption Consultings PQC-beredskap Tjänsten utvärderar din nuvarande HSM-infrastrukturs kvantumexponering och tar fram en migreringsfärdplan som är anpassad till NIST IR 8547-tidslinjen.

Slutsats

Valet mellan dedikerade och delade HSM:er i en PKIaaS-distribution är inte en binär fråga om säker kontra osäker. Båda modellerna kan implementeras säkert. De praktiska skillnaderna ligger i fysisk explosionsradie, isolering av revisionsloggar, efterlevnad av regelverk och kostnad. För de flesta PKIaaS-distributioner för företag utanför de mest krävande reglerade miljöerna ger FIPS 140-2 eller 140-3 nivå 3-validerade delade HSM:er med korrekt partitionsisolering, revisionsloggar per kund, M-of-N-kontroller för åtgärder med hög behörighet och kundåtkomlig nyckeldeposition en sund säkerhetsställning.

De fall som verkligen kräver dedikerad hårdvara är specifika: FedRAMP High Authorization Borders där fysisk infrastruktur med flera hyresgäster komplicerar ATO-gränsen, CMMC Level 3-distributioner som skyddar CUI i miljöer med höga hot, ITAR/DFARS-relaterade organisationer där administrativ åtkomst med flera hyresgäster skapar regelmässig exponering, och organisationer vars säkerhetspolicy kräver fysisk nyckelförvaring oavsett kryptografisk isoleringsstyrka.

De frågor som alltid gäller, oavsett modell: vad är NIST CMVP-certifikatnumret för HSM, vad är M-of-N-konfigurationen för rot-CA-operationer, hur upprätthålls och verifieras rot-CA:ns offline-status, vad är isoleringsmodellen för revisionsloggar och hur ser BYOK- eller nyckelspärrproceduren ut. En leverantör som inte kan svara specifikt och skriftligen på dessa frågor använder inte den nivå av HSM-styrning som företags-CA:ns nyckellagring kräver.

Om du utvärderar PKIaaS-leverantörer och behöver hjälp med att kartlägga deras HSM-arkitektur mot dina specifika efterlevnadskrav, kontakta Encryption Consulting . Vi har utvärderat HSM-implementeringar i FedRAMP-, CMMC-, DORA-, PCI DSS- och HIPAA-miljöer och kan hjälpa dig att få fram ett dokumenterat, försvarbart svar snabbare än att behöva arbeta dig igenom det från grunden.

Detta inlägg granskas var sex månader och omedelbart när NIST uppdaterar övergångsriktlinjerna för FIPS 140-3, CMVP uppdaterar valideringsstatus för relevanta HSM-modeller, eller ny regulatorisk vägledning från FedRAMP, CMMC, DORA eller NIS2 direkt adresserar HSM-hyreskrav.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan en dedikerad HSM och en delad HSM i PKIaaS?

I en dedikerad HSM-distribution allokeras den fysiska HSM-enheten exklusivt till en kund. Inga andra kunders nycklar eller kryptografiska operationer bearbetas på den hårdvaran. I en delad HSM-distribution lagras flera kunders nyckelmaterial i separata logiska partitioner på samma fysiska enhet. De kryptografiska gränserna mellan partitioner upprätthålls av HSM-firmwaren, men själva hårdvaran delas. Dedikerade HSM:er eliminerar sprängradie på hårdvarunivå helt och hållet; delade HSM:er är beroende av att partitionsupprätthållandet på firmwarenivå är korrekt.

Vilken FIPS-valideringsnivå bör en PKIaaS HSM uppfylla?

FIPS 140-2 Nivå 3 är den lägsta acceptabla standarden för CA-nycklarlagring i en PKIaaS-miljö. Den kräver fysiskt manipuleringsskydd som nollställer nycklarna om höljet öppnas. FIPS 140-3 Nivå 3 är den nuvarande standarden, publicerad 2019 och i linje med ISO/IEC 19790:2012. NIST började acceptera FIPS 140-3-inlämningar i september 2020. De flesta företags-HSM:er som för närvarande är i produktion har FIPS 140-2 Nivå 3-validering; 140-3-certifieringar finns tillgängliga för nyare modeller. Verifiera alltid valideringsstatus via NIST CMVP-databasen snarare än att lita på marknadsföringspåståenden.

Vad är HSM-partitionering i ett PKIaaS-sammanhang?

HSM-partitionering skapar isolerade logiska gränser inom en enda fysisk HSM-enhet. Varje partition har sin egen nyckellagring, åtkomstuppgifter och granskningslogg. Nycklar i en partition är inte tillgängliga för processer som körs under en annan partitions autentiseringsuppgifter, och HSM tillämpar denna gräns i firmware. I en delad PKIaaS-distribution får varje kund vanligtvis en eller flera dedikerade partitioner på en delad enhet. Isoleringen tillämpas kryptografiskt på hårdvarunivå, men sprängradien från en fysisk kompromiss av enheten delas mellan alla partitionsinnehavare.

Vad är M-of-N-kontroll för HSM:er?

M-of-N-kontroll (även kallad hemlig delning eller kvorumautentisering) kräver att minst M av N utsedda nyckelinnehavare måste vara närvarande och autentisera innan vissa HSM-operationer med hög behörighet kan fortsätta. Till exempel kräver en 3-av-5-konfiguration att 3 av 5 utsedda vårdnadshavare tillhandahåller sina autentiseringstokens innan HSM tillåter en nyckelceremoni för rot-CA, nyckelexport eller partitionsinitiering. M-of-N-kontroller är ett standardkrav för rot-CA-operationer och är dokumenterade i CP/CPS-styrningsramverk. De förhindrar att en enskild administratör ensidigt utför obehöriga operationer med hög behörighet.

Vad är BYOK (Bring Your Own Key) i ett PKIaaS HSM-sammanhang?

Med Bring Your Own Key (BYOK) kan kunden generera sitt CA-rotnyckelmaterial i sin egen hårdvara eller kontrollerade miljö och sedan importera det till leverantörens HSM-infrastruktur. Detta ger kunden en försäkran om att rotnyckeln aldrig genererades i ett system de inte kontrollerar. I PKIaaS kombineras BYOK vanligtvis med kundkontrollerad nyckeldeponering så att kunden behåller en oberoende kopia av rotnyckeln utanför leverantörens infrastruktur. Inte alla PKIaaS-leverantörer stöder BYOK; för organisationer med strikta krav på nyckelursprung är detta ett icke-förhandlingsbart utvärderingskriterium.

Vilka reglerade branscher kräver dedikerade HSM:er för PKIaaS?

Ingen enskild global reglering föreskriver universellt dedikerade (icke-partitionerade) HSM:er för PKIaaS, men flera ramverk skapar starka praktiska krav för fysisk nyckelisolering. FedRAMP High kräver FIPS 140-2 Nivå 3 HSM:er och inför strikta gränskontroller som i praktiken gynnar dedikerade apparater. CMMC Nivå 3-krav för CUI-skydd skapar liknande påtryckningar. Vissa EU-medlemsstaters implementeringar av NIS2 och DORA inkluderar krav på datalagring och fysisk kontroll som i praktiken kräver dedikerad infrastruktur. Krav på försvarsindustriell bas enligt DFARS och ITAR kan helt förbjuda nyckellagringsmiljöer med flera hyresgäster. Organisationer som omfattas av dessa ramverk bör ha juridisk rådgivning som bekräftar om logisk partitionsisolering är tillräckligt eller om fysisk dedikation krävs.

Kan granskningsloggar från en delad HSM isoleras per kund?

De flesta HSM:er i företagsklass har stöd för granskningsloggar per partition som registrerar kryptografiska operationer, åtkomsthändelser och administrativa åtgärder för den partitionen oberoende av varandra. I en väl utformad delad PKIaaS-distribution bör varje kunds partitionsgranskningslogg endast vara tillgänglig för den kunden och deras utsedda granskare, inte för andra partitionsinnehavare eller för leverantörens allmänna driftspersonal. Fråga vilken PKIaaS-leverantör som helst specifikt om din partitions granskningslogg är tillgänglig för deras driftspersonal utöver vad som krävs för support, hur länge granskningsloggar sparas och om loggar kan exporteras till din SIEM i realtid.

Använder Encryption Consultings PKIaaS dedikerade eller delade HSM:er?

Encryption Consultings PKIaaS använder dedikerade HSM-partitioner per kundengagemang, med FIPS 140-3 Level 3 HSM-baserade CA-nycklar, alltid offline rot-CA med en dokumenterad M-of-N-nyckelceremoni och kundkontrollerad nyckeldeposition. Kunder behåller åtkomst till sina partitions granskningsloggar. För organisationer med krav som överstiger standardpartitionsisolering kan Encryption Consulting diskutera dedikerade enhetskonfigurationer som en del av engagemangets omfattning. Kontakta oss för att diskutera era specifika HSM- och efterlevnadskrav.