Molnbaserade kontra lokala HSM:er

Molnbaserade kontra lokala HSM:er är det distributionsbeslut som avgör vem som har fysisk kontroll över organisationens mest känsliga kryptografiska operationer. En hårdvarusäkerhetsmodul (HSM) är en dedikerad, manipulationssäker hårdvaruenhet som genererar, lagrar och hanterar kryptografiska nycklar inom en gräns som är validerad enligt FIPS 140-2 nivå 3. Valet mellan att distribuera HSM:er i ditt eget datacenter eller att använda dem som en hanterad molntjänst påverkar din nyckelkontrollmodell, latensprofil, efterlevnadsstatus, total ägandekostnad och driftskostnader. Den här guiden täcker alla dimensioner av det beslutet så att säkerhets- och infrastrukturteam kan välja rätt modell för sina specifika behov.

Snabbt svar: Molnbaserad HSM eller lokal HSM?

För de flesta organisationer erbjuder molnbaserade HSM-tjänster motsvarande kryptografisk säkerhet som lokala HSM:er till lägre total ägandekostnad, snabbare distribution och utan den operativa bördan av att hantera fysisk hårdvara. Välj lokala HSM:er när din applikation har latenskrav på under en millisekund som en nätverksrundtur inte kan uppfylla, när myndighetskrav kräver att nycklar aldrig lämnar en specifik fysisk anläggning eller jurisdiktion utan tillgänglig moln-HSM-tjänst, eller när du arbetar i en miljö med begränsat utrymme utan molnanslutning. För multimoln- och hybridmiljöer som kräver centraliserad nyckelstyrning är en tredjeparts-HSM som en tjänst som omfattar flera leverantörer ofta det mest praktiska valet.

Key Takeaways

• Kryptografitekniken är densamma: Både molnbaserade och lokala HSM:er använder FIPS 140-2 nivå 3-validerad hårdvara som utför samma kryptografiska operationer. Distributionsmodellen avgör vem som använder hårdvaran, inte vad den gör.
• Moln-HSM minskar driftskostnader, inte säkerhet: Molnbaserade HSM-tjänster eliminerar ansvaret för hårdvaruanskaffning, rackutrymme i datacenter, firmware-patchning och hantering av HSM-kluster. Den kryptografiska gränsen förblir hårdvarubaserad oavsett vem som driver den.
• BYOK och HYOK kräver HSM-genererat nyckelmaterial: Både BYOK (Bring Your Own Key) och HYOK (Hold Your Own Key) implementeringar använder vanligtvis en lokal eller dedikerad moln-HSM som nyckelgenereringskälla, vilket gör HSM-valet till en del av molnnyckelhanteringsstrategin, inte separat från den.
• Latens är den vanligaste tekniska begränsningen som gynnar lokal drift: Applikationer som kräver HSM-svarstider på under en millisekund kan inte tolerera nätverkslatensen för ett moln-HSM API-anrop. Högfrekvent handel, betalningsbehandling i stor skala och vissa PKI-signeringsoperationer faller inom denna kategori.
• FIPS 140-2 Nivå 3 finns tillgänglig i båda modellerna: AWS CloudHSM, Azure Dedicated HSM och GCP Cloud HSM använder alla FIPS 140-2 nivå 3-validerad hårdvara. Delade moln-KMS-tjänster utan en dedikerad HSM-nivå använder nivå 2, inte nivå 3. Verifiera den exakta tjänstnivån när nivå 3 är ett krav.

Vad är en hårdvarusäkerhetsmodul (HSM)?

En hårdvarusäkerhetsmodul (HSM) är en dedikerad fysisk datorenhet utformad för att skydda kryptografiska nycklar och utföra kryptografiska operationer inom en manipulationssäker hårdvarugräns. HSM:er är specialbyggda för nyckelsäkerhet: de genererar nycklar med hjälp av hårdvarugeneratorer för slumptal, lagrar nycklar i icke-exporterbar form inom hårdvarugränsen, utför kryptografiska operationer (kryptering, dekryptering, signering, verifiering) inom den gränsen så att nyckelmaterialet aldrig behöver lämna enheten i klartext, och upptäcker och reagerar på fysiska manipuleringsförsök genom att nollställa nyckelmaterialet.

Säkerheten för en HSM valideras formellt genom NIST FIPS 140-2-certifieringsprogrammet (Federal Information Processing Standard). FIPS 140-2 definierar fyra säkerhetsnivåer: Nivå 1 (grundläggande programvarukryptografisk modul), Nivå 2 (manipulationssäker fysisk säkerhet), Nivå 3 (manipulationssäker fysisk säkerhet med identitetsbaserad autentisering och nollställning av kritiska säkerhetsparametrar vid manipuleringsdetektering) och Nivå 4 (komplett fysiskt säkerhetshölje som skyddar mot miljöattacker). FIPS 140-2 Nivå 3 är standardkravet för företags- och reglerade HSM-distributioner. NIST övergår för närvarande till FIPS 140-3, vilket överensstämmer med ISO/IEC 19790; befintliga FIPS 140-2-valideringar förblir accepterade under övergångsperioden.

HSM:er används inom en mängd olika kryptografiska arbetsbelastningar: skydda privata nycklar för certifikatutfärdare (CA:er) i PKI-infrastruktur, generera och skydda krypteringsnycklar som används för databastransparent datakryptering (TDE), säkra privata nycklar för TLS-certifikat på värdefulla slutpunkter, utföra signeringsåtgärder för kodsignering och dokumentsignering, skydda nycklar som används för kryptering och verifiering av PIN-koder för betalkort och generera BYOK-nyckelmaterial som importeras till molntjänster för nyckelhantering.

Lokala HSM:er: Full kontroll, fullt ansvar

En lokal HSM är en fysisk apparat som din organisation köper in, installerar i ditt eget datacenter eller samlokaliseringsanläggning, konfigurerar, driver och underhåller. HSM-hårdvaran ansluter till dina applikationer och nyckelhanteringsinfrastruktur över ditt interna nätverk, vanligtvis via PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) eller REST API:er beroende på HSM-modellen och applikationens integrationskrav.

Vad lokala HSM:er ger dig: Fysisk besittning och kontroll över den kryptografiska hårdvaran och de nycklar som lagras i den. Inget beroende av en molnleverantörs tillgänglighet eller API för kryptografiska operationer. Lokal nätverkslatens på under en millisekund för högfrekventa kryptografiska operationer. Möjligheten att utföra nyckelceremonier i en fysiskt kontrollerad miljö för generering av privata nycklar från CA. Fullständig efterlevnad av krav på datasuveränitet eller lokalisering som kräver att nycklar förblir inom en specifik fysisk anläggning eller jurisdiktion där ingen moln-HSM-tjänst finns.

Vad lokala HSM:er kostar dig: Förskottsköp av hårdvara (vanligtvis 20 000 till 40 000 USD per enhet beroende på modell och datakapacitet). Ytterligare enheter för kluster med hög tillgänglighet (HA) och katastrofåterställning, vilket vanligtvis kräver minst två enheter för produktionsåterhämtningsförmåga. Licenser för hanteringsprogramvara. Rackutrymme, strömförsörjning och kylning i datacentret. Kompetent personaltid för initial konfiguration, firmwareuppdateringar, partitionshantering, distribution av klientprogramvara och löpande drift. Cykler för utbyte av hårdvara (vanligtvis 5 till 7 år). Fysiska säkerhetskontroller för datacentret som inrymmer HSM:en.

När lokala HSM:er är rätt val: Applikationer med strikta latenskrav som inte kan tolerera en nätverksresa till en molntjänst (kryptografiska operationer på under en millisekund för högfrekvent handel, PIN-blockeringsbehandling för betalningsterminaler eller signeringspipelines i realtid); myndighetskrav som kräver fysisk nyckelförvaring i en specifik anläggning eller ett specifikt land där ingen moln-HSM-tjänst är verksam; miljöer med airgapp eller klassificerade miljöer utan internetanslutning; organisationer med mycket höga kryptografiska transaktionsvolymer där prissättningen för moln-API-anrop är betydligt dyrare än ägd hårdvara; och nyckelceremonier för generering av CA-rotnycklar där fysisk närvaro och vittnesförfaranden krävs.

Molnbaserade HSM:er: Hanterad hårdvara, delad eller dedikerad

Molnbaserade HSM:er är FIPS-validerad HSM-hårdvara som drivs av en molnleverantör eller tredjepartstjänst, och som dina applikationer har åtkomst till via ett autentiserat API. HSM-hårdvaran finns fysiskt i tjänsteleverantörens datacenter. Dina applikationer interagerar aldrig direkt med HSM-hårdvaran; de anropar tjänstens API, som dirigerar den kryptografiska operationen till den underliggande HSM-hårdvaran och returnerar resultatet.

Molnbaserade HSM-tjänster delas in i två kategorier med betydligt olika säkerhetsmodeller:

Dedikerade (enkelhyresgäst) moln-HSM-tjänster

Dedikerade molnbaserade HSM-tjänster tillhandahåller fysisk HSM-hårdvara exklusivt till din organisation. Inga andra kunders nycklar eller kryptografiska operationer delar hårdvaran eller HSM-partitionerna med din. Exempel inkluderar AWS CloudHSM (använder Luna Network HSM-hårdvara, FIPS 140-2 nivå 3, cirka 1.45 USD per timme och instans), Azure Dedicated HSM (använder Entrust nShield Connect-hårdvara, FIPS 140-2 nivå 3) och Azure Payments HSM (använder Utimaco-hårdvara för betalnings-HSM-arbetsbelastningar). I en dedikerad molnbaserad HSM hanterar molnleverantören den fysiska infrastrukturen men har ingen åtkomst till dina nycklar eller HSM-partitionerna; du hanterar HSM-programvaran, partitionerna och nyckelmaterialet själv via HSM:s eget hanteringsgränssnitt.

Dedikerade molnbaserade HSM-tjänster ger en säkerhetsställning som ligger mycket nära lokala HSM:er: FIPS 140-2 Nivå 3-validering, hårdvara med en enda hyresgäst och molnleverantörsundantag från nyckelåtkomst. De viktigaste skillnaderna mot lokala tjänster är nätverkslatensen för API-anrop (vanligtvis 1 till 5 millisekunder kontra sub-millisekunder för lokala tjänster), ansvaret för den operativa hanteringen (du hanterar HSM-programvaran och partitionerna men inte den fysiska hårdvaran) och prissättningsmodellen (timkapital kontra initialt kapital).

Delade (flera hyresgäster) moln-HSM-tjänster

Delade moln-HSM-tjänster använder HSM-hårdvara som är partitionerad och delad mellan flera kunder. Dina nycklar är logiskt isolerade från andra kunders nycklar inom HSM, men den fysiska hårdvaran delas. Exempel inkluderar AWS KMS med HSM-skydd (FIPS 140-2 nivå 2-validerad), GCP Cloud KMS med HSM-skyddsnivå (FIPS 140-2 nivå 3-validerad för HSM-baserade nycklar) och Azure Key Vault Premium-nivå (HSM-skyddade nycklar). Dessa tjänster hanteras fullständigt: molnleverantören hanterar hårdvaran, HSM-programvaran och nyckelhanteringsplattformen. Ditt ansvar är begränsat till konfiguration av nyckelpolicyer, åtkomstkontroll och nyckellivscykelhantering via molnleverantörens API.

Delade moln-HSM-tjänster erbjuder de lägsta driftskostnaderna och omkostnaderna. Avvägningen är att molnleverantören driver HSM-hårdvaran och har möjlighet att komma åt eller migrera den underliggande infrastrukturen, även om den logiska nyckelisoleringen är stark. För de flesta efterlevnadsramverk räcker det med en molnleverantörs delade HSM-tjänst, som backas upp av en BAA, DPA eller annan avtalskontroll. För arbetsbelastningar där ingen molnleverantörsåtkomst till nyckelmaterial krävs krävs en dedikerad moln-HSM eller lokal HSM.

Nyckelkontrollmodeller: Native, BYOK och HYOK

Beslutet om HSM-distribution är nära kopplat till den nyckelkontrollmodell som dina efterlevnadskrav eller säkerhetspolicy föreskriver. Det finns tre nyckelkontrollmodeller, och var och en har olika HSM-implikationer.

Native Cloud Key Management (leverantörshanterade nycklar)

Molnleverantören genererar och hanterar alla krypteringsnycklar i sin egen nyckelhanteringsinfrastruktur. Dina nycklar skyddas av HSM-hårdvara som drivs av leverantören, men du har ingen insyn i eller kontroll över det fysiska nyckelmaterialet. Du kan använda, rotera, inaktivera och ta bort nycklar via leverantörens API, men du kan inte oberoende verifiera att nyckelmaterialet genererades med det ursprung som din policy kräver. Den här modellen kräver ingen HSM-investering eller drift från din sida och är lämplig för de flesta allmänna molnarbetsbelastningar där leverantörens granskningslogg för nyckelhantering är tillräcklig för dina efterlevnadskrav.

BYOK (Ta med egen nyckel)

BYOK innebär att du genererar krypteringsnyckelmaterial i en HSM som du kontrollerar (lokal eller en dedikerad moln-HSM), exporterar nyckelmaterialet (inpackat för säker transport) och importerar det till molnleverantörens nyckelhanteringstjänst (AWS KMS, Azure Key Vault eller GCP Cloud KMS). Molnleverantören använder ditt importerade nyckelmaterial för att generera datakrypteringsnycklarna som skyddar dina molndata. Du behåller källnyckelmaterialet i din HSM och kan ta bort det från molnleverantörens KMS för att omedelbart återkalla leverantörens möjlighet att dekryptera dina data.

BYOK uppfyller myndighetskrav som föreskriver kundgenererat nyckelmaterial. Det kräver antingen en lokal HSM eller en dedikerad moln-HSM-tjänst som nyckelgenereringskälla. Molnleverantörens KMS har operativ åtkomst till nyckelmaterialet under användning; BYOK ger dig möjlighet till proveniens och återkallelse, men inte noll leverantörsåtkomst.

HYOK (Håll din egen nyckel)

HYOK innebär att krypteringsnyckeln aldrig kommer in i molnleverantörens infrastruktur. Din applikation eller ett klientsidesbibliotek krypterar data innan de laddas upp till molnlagring med hjälp av en nyckel som genereras och lagras i din egen HSM (lokal eller en tredjeparts moln-HSM-tjänst som inte är samma leverantör som din datalagring). Molnleverantören lagrar endast chiffertext och kan inte dekryptera dina data under några driftsförhållanden. HYOK kräver antingen en lokal HSM eller en tredjeparts-HSM som en tjänst som fungerar oberoende av dina molnlagringsleverantörer. Den ger den starkaste datasuveräniteten till bekostnad av den högsta driftskomplexiteten.

Dimensionera	Native Cloud Key Management	BYOK (kundgenererad nyckel i moln-KMS)	HYOK (nyckel helt utanför molnleverantör)
HSM krävs	Nej (leverantörens HSM)	Ja (för att generera och lagra källnyckelmaterial)	Ja (för att generera och använda nyckel vid varje operation)
HSM-distributionsmodell	ej tillämplig	Lokal HSM eller dedikerad moln-HSM	Lokal HSM eller HSM som en tjänst från tredje part
Leverantörsåtkomst till nyckel under användning	Ja	Ja (operativ åtkomst)	Nej
Leverantörsåtkomst till klartextdata	Ja (via nyckel)	Ja (via tangent under användning)	Nej
Oberoende nyckelåterkallelse	Endast via leverantörens API	Ja (ta bort källmaterial från din HSM)	Ja (återkalla omedelbart på din HSM)
Operationell komplexitet	Låg	Medium	Hög
Bäst för	Allmänna molnarbetsbelastningar	Reglerade sektorer som kräver viktig proveniens	Hemligstämplat, suveränitetsmandat, nollförtroende

Molnbaserade kontra lokala HSM:er: Fullständig jämförelse

Dimensionera	Lokal HSM	Dedikerad moln-HSM	Delad moln-HSM-tjänst
FIPS 140-2 Nivå 3	Ja	Ja	Beror på servicenivå (nivå 2 eller 3)
Fysisk nyckelförvaring	Din organisation	Molnleverantör (endast hårdvara; ingen nyckelåtkomst)	Molnleverantör (hårdvara och infrastruktur)
Hårdvaruhantering	Din organisation	Molnleverantör (hårdvara); du hanterar HSM-programvara	Molnleverantör (fullständigt hanterad)
Förskottskapitalkostnad	20 000 till 40 000 dollar+ per apparat	Ingen	Ingen
Löpande kostnadsmodell	Personaltid, licenser, datacenterkostnader	Timpris per instans (ca 1.45 USD/timme för AWS CloudHSM)	Per API-anrop + nyckellagringsavgift
Implementeringstid	Veckor till månader (upphandling, inventering, konfiguration)	Minuter till timmar	minuter
Latens	Sub-millisekunden (lokalt nätverk)	1 till 5 ms (nätverks-API tur och retur)	1 till 10 ms (API för delad tjänst)
Hög tillgänglighet	Kräver flera apparater och HA-konfiguration	Tillgängligt via kluster med flera instanser eller över hela AZ	Inbyggd i hanterad tjänst
Operationell overhead	Hög (firmware, partitioner, klusterhantering, personal)	Medium (HSM-programvara och partitionshantering)	Låg (endast nyckelpolicy och åtkomsthantering)
Skalbarhet	Begränsad av hårdvarukapacitet; expansion kräver upphandling	Lägg till instanser på begäran	Skalar automatiskt
Stöd för flera moln	Ja (alla applikationer kan ansluta)	Begränsat till den leverantörens ekosystem	Leverantörsspecifik
Ansvar för efterlevnad	Helt din organisation	Delad (leverantören hanterar hårdvaruefterlevnad)	Primärt leverantör
Luftgapiga miljöer	Ja	Nej	Nej
BYOK-källfunktion	Ja	Ja	Begränsad (vissa leverantörer stöder det)
Bäst för	Låg latens, luftgap, strikt lokalisering, HYOK	FIPS nivå 3, BYOK, multimoln med dedikerad hårdvara	Allmänna molnarbetsbelastningar, hanterad enkelhet

IAM-modell för HSM-åtkomstkontroll

Oavsett om du distribuerar lokala eller molnbaserade HSM:er är åtkomstkontroll lika viktig som själva hårdvarugränserna. En FIPS 140-2 nivå 3 HSM med tillåtande åtkomstkontroller är inte säkrare än en programvarunyckellagring. IAM-modellen för HSM:er separerar tre distinkta roller som inte får överlappa varandra.

HSM-administratörsroll: Skapar och hanterar HSM-partitioner, anger partitionspolicyer, hanterar HSM-klustermedlemskap, utför firmwareuppdateringar och hanterar viktiga ceremoniprocedurer. Lokalt är detta vanligtvis en dedikerad medlem i HSM-driftsteamet som använder HSM:s hårdvaruautentisering (PED eller smartkort). I moln-HSM-tjänster autentiserar administratören till HSM-hanterings-API:et med hårdvarutokens eller starka autentiseringsuppgifter. Administratörsrollen får aldrig användas av applikationer eller automatiserade pipelines.

Roll som nyckelförvaltare (kryptoansvarig): Skapar, importerar, exporterar (där det är tillåtet), roterar och tar bort nyckelobjekt inom en tilldelad partition. Denna roll ansvarar för nyckellivscykeln inom HSM. I en moln-HSM-kontext mappas detta till den roll som hanterar nyckelpolicyer i AWS KMS, Azure Key Vault eller GCP Cloud KMS. Åtgärder för nyckelförvaltare bör kräva dubbel kontroll för nyckelåtgärder med högt värde (generering av CA-rotnyckel, borttagning av huvudnyckel) och måste loggas.

Programroll (kryptoanvändare): Använder nycklar inom HSM för att utföra kryptografiska operationer (kryptera, dekryptera, signera, verifiera) men kan inte skapa, ta bort eller exportera nycklar. I molnbaserade KMS-tjänster mappas detta till att ge programmets tjänstkonto eller IAM-roll endast de specifika kryptografiska operationsbehörigheter som behövs (kms:Decrypt för dekrypteringsbaserade applikationer; kms:Sign för signeringsbaserade applikationer) utan nyckelhanteringsbehörigheter. Programroller bör begränsas till specifika nycklar, inte beviljas bred åtkomst till alla nycklar i en partition eller nyckelarkiv.

Nyckelrotation med HSM:er

Nyckelrotation i ett HSM-sammanhang innebär att man genererar nytt nyckelmaterial inom HSM:n för att ersätta befintliga nycklar enligt ett definierat schema. Hur rotationen fungerar beror på om HSM:n skyddar en huvudnyckel (som omsluter andra nycklar) eller en datakrypteringsnyckel (som direkt krypterar data).

Huvudnyckelrotation i moln-KMS med HSM-säkerhetskopiering: När du aktiverar automatisk rotation på en kundhanterad nyckel i AWS KMS eller Azure Key Vault genererar tjänsten nytt HSM-säkerhetskopierat nyckelmaterial enligt det konfigurerade schemat (vanligtvis årligen). Befintlig data som krypterats med den tidigare nyckelversionen förblir dekrypterbar; KMS behåller tidigare nyckelversioner. Nya krypteringsåtgärder använder det nya nyckelmaterialet. Nyckel-ID och ARN förblir desamma; rotationen är transparent för applikationer.

Nyckelrotation för lokala HSM:er och BYOK: Lokal HSM-nyckelrotation kräver att nytt nyckelmaterial genereras inom HSM:en, distribueras till alla system eller applikationer som använder nyckeln, ompaketeras eller krypteras om alla datakrypteringsnycklar som skyddas av den gamla huvudnyckeln och arkiveras det gamla nyckelmaterialet enligt din lagringspolicy. För BYOK-nycklar med importerat material i ett moln-KMS är automatisk rotation inte tillgänglig. Du måste generera nytt material i din HSM, exportera och importera det igen till moln-KMS:en, ange det som primärversion och hantera övergångstidslinjen för alla beroende arbetsbelastningar.

CA-nyckelrotation för PKI: HSM:er som skyddar CA:s privata nycklar kräver särskild hantering för rotation eftersom rotation av en CA-privat nyckel kräver att ett nytt CA-certifikat utfärdas och det nya förtroendeankaret distribueras till alla förlitande parter. CA-nyckelrotation är en planerad PKI-händelse, inte en rutinmässig automatiserad operation, och kräver samordning med alla system som litar på CA:n. HSM:s nyckelceremoniprocedurer (dubbel kontroll, M-of-N-kvorumautentisering) gäller för CA-nycklargenerering.

Granskningsloggning för HSM-åtgärder

HSM-granskningsloggar är ett efterlevnadskrav enligt PCI DSS, FedRAMP, HIPAA och de flesta andra ramverk som specificerar kryptografiska kontroller. Loggen måste registrera alla administrativa åtgärder (skapande av partitioner, skapande av nycklar, borttagning av nycklar, policyändringar) och alla kryptografiska åtgärder (signera, verifiera, kryptera, dekryptera, radera, packa upp) som utförs av eller via HSM, kopplade till en autentiserad identitet.

Lokal HSM-granskningsloggning: Fysiska HSM:er genererar granskningsloggar internt och kan vidarebefordra dem till en SIEM- eller syslog-server. HSM:ens granskningslogg signeras av HSM:en själv för att upptäcka manipulering. Att säkerställa att granskningsloggar vidarebefordras utanför enheten till ett manipuleringssäkert loggarkiv innan HSM:ens interna logg fylls är ett operativt krav som lokala HSM-team måste hantera explicit.

Moln-HSM-granskningsloggning: Moln-HSM- och moln-KMS-tjänster integreras med molnleverantörens inbyggda granskningsloggning. I AWS visas varje KMS API-anrop i CloudTrail, inklusive den begärande identiteten, nyckel-ARN, åtgärdstyp och tidsstämpel. I Azure loggas Key Vault- och dedikerade HSM-åtgärder i Azure Monitor. I GCP visas moln-KMS- och moln-HSM-åtgärder i molngranskningsloggar. Molngranskningsloggar är automatiskt manipulationssäkra (leverantören upprätthåller loggintegriteten) och dirigeras enkelt till SIEM-plattformar genom inbyggda integrationer.

Aviseringar om följande HSM-granskningshändelser oavsett distributionsmodell: borttagning eller schemaläggning av nycklar; policyändringar på en nyckel eller partition med högt värde; kryptografiska åtgärder av en identitet som inte finns i den godkända programrolllistan; misslyckade autentiseringsförsök mot HSM; och försök att exportera nyckelmaterial från en partition som konfigurerats som icke-exporterbar.

Multi-Cloud HSM-arkitektur

Organisationer som verkar över flera molnleverantörer står inför en specifik HSM-utmaning: varje molnleverantörs dedikerade HSM-tjänst är kopplad till den leverantörens infrastruktur, och molnleverantörens HSM-tjänster federerar inte mellan leverantörer. En AWS CloudHSM-instans kan inte direkt hantera GCP-arbetsbelastningar, och en Azure Dedicated HSM kan inte generera nycklar för AWS KMS-import utan ytterligare verktyg. Tre mönster hanterar HSM-arkitektur för flera moln:

• Lokal HSM som central nyckelauktoritet: Ett lokalt HSM-kluster fungerar som auktoritet för generering och lagring av huvudnycklar för alla miljöer. Nycklar som genereras i den lokala HSM:n exporteras (omsluts) och importeras till varje molnleverantörs KMS som BYOK-nycklar. Den lokala HSM:n är den auktoritativa källan för allt nyckelmaterial; molnleverantörens KMS-tjänster är konsumenter av det materialet. Denna modell ger den starkaste centraliserade kontrollen men kräver att den lokala HSM:n är mycket tillgänglig och åtkomlig för alla molnmiljöer.
• Tredjeparts HSM som en tjänst som omfattar molnleverantörer: En tredjeparts HSM-tjänst som är oberoende av alla tre stora molnleverantörer tillhandahåller centraliserad HSM-infrastruktur som är tillgänglig för arbetsbelastningar i alla molnmiljöer. HSM-tjänsten genererar nycklar och gör dem tillgängliga för applikationer i alla moln via ett enhetligt API. Detta eliminerar problemet med HSM-silo per leverantör utan att kräva lokal hårdvara, och den fungerar som nyckelgenereringskälla för BYOK över alla molnleverantörer. Encryption Consultings HSM som en tjänst förser denna modell med FIPS 140-2 nivå 3 HSM-infrastruktur som är tillgänglig i alla molnmiljöer.
• Dedikerad HSM per moln med centraliserad nyckelstyrning: Distribuera en dedikerad moln-HSM-tjänst i varje molnleverantör (AWS CloudHSM i AWS, Azure Dedicated HSM i Azure) och hantera dem som separata nyckelutfärdare för arbetsbelastningar i varje moln. Använd en centraliserad plattform för nyckelhantering för att upprätthålla insyn i alla nycklar över alla HSM-instanser, tillämpa konsekventa nyckelpolicyer och aggregera granskningsloggar. Denna modell är den mest operativt komplexa men undviker molnöverskridande nätverksberoenden för kryptografiska operationer.

Efterlevnadsöverväganden för HSM-distribution

Olika efterlevnadsramverk anger olika HSM-krav. Att matcha din HSM-distribution med den specifika kravformuleringen förhindrar både underefterlevnad (användning av nivå 2 där nivå 3 krävs) och överinvestering (distribution av lokala HSM:er där en hanterad moln-HSM-tjänst uppfyller kravet).

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025): Kräver att kryptografiska nycklar som används för att skydda kortinnehavardata lagras på så få platser som möjligt. Nyckelhanteringsprocesser måste inkludera skydd av nycklar mot avslöjande och missbruk (krav 3.7.1). HSM:er anges uttryckligen som en acceptabel nyckelhanteringsteknik. PCI DSS kräver inte en specifik FIPS-nivå för HSM men kräver att nyckelhanteringssystemet är säkert och granskat. Moln-HSM-tjänster som används för PCI-omfattning måste finnas inom leverantörens PCI DSS-certifierade infrastruktur.

FedRAMP (NIST SP 800-53 Rev. 5): SC-12-kontrollen (Cryptographic Key Establishment and Management) kräver att nycklar produceras, kontrolleras och distribueras med hjälp av NSA-godkänd eller NIST-rekommenderad nyckelhanteringsteknik. FedRAMP High kräver dessutom FIPS 140-2- eller FIPS 140-3 nivå 3-validerade kryptografiska moduler. AWS CloudHSM, Azure Dedicated HSM och GCP Cloud HSM med HSM-skyddsnivå uppfyller alla detta krav. Standard delade moln-KMS-tjänster på FIPS 140-2 nivå 2 uppfyller inte FedRAMP Highs nivå 3-krav.

eIDAS och kvalificerade signaturer (EU): Kvalificerade elektroniska signaturer enligt eIDAS kräver kvalificerade signaturskapande enheter (QSCD), som måste uppfylla krav som minst motsvarar FIPS 140-2 nivå 3 eller Common Criteria EAL4+. För EU-organisationer som utfärdar kvalificerade certifikat eller kvalificerade signaturer krävs lokala HSM:er eller EU-lokaliserade dedikerade moln-HSM:er med lämpliga valideringar.

HIPAA: Föreskriver inget specifikt HSM-krav men kräver lämpliga skyddsåtgärder för krypteringsnycklar som skyddar ePHI. En molnbaserad HSM-tjänst med dokumenterade åtkomstkontroller, granskningsloggning och ett undertecknat Business Associate Agreement (BAA) med leverantören uppfyller HIPAA:s tekniska skyddskrav för nyckelskydd.

Beslutsguide för HSM-distribution

Använd följande kriterier för att identifiera rätt HSM-distributionsmodell för din organisations krav.

1. Identifiera ditt latenskrav: Om din applikation kräver HSM-svarstider på under en millisekund är lokal HSM det enda alternativet. Om du kan tolerera 1 till 10 millisekunder är molnbaserade HSM-tjänster gångbara.
2. Identifiera dina FIPS-nivåkrav: Om FIPS 140-2 nivå 3 krävs (FedRAMP High, vissa PCI, eIDAS-kvalificerade), kontrollera att den specifika molntjänsten du utvärderar uppfyller nivå 3, inte bara nivå 2. Delade moln-KMS-tjänster varierar beroende på leverantör och nivå.
3. Identifiera din nyckelkontrollmodell: Om nyckelhantering från en nativ leverantör är acceptabelt, använd molnleverantörens delade KMS med HSM-skydd. Om BYOK krävs behöver du en lokal HSM eller en dedikerad moln-HSM för att generera nyckelmaterial. Om HYOK krävs behöver du en HSM som fungerar helt utanför molnleverantören som lagrar dina data.
4. Identifiera era krav på datasuveränitet: Om regler kräver att nycklar aldrig lämnar ett specifikt land eller en specifik anläggning, och ingen moln-HSM-tjänst är verksam på den platsen, krävs lokal HSM. Om en moln-HSM-tjänst är verksam i den jurisdiktion som krävs, verifiera de avtalsenliga garantierna för datauppehållstillstånd.
5. Identifiera din multimolnstrategi: Om du arbetar med flera molnleverantörer och behöver centraliserad nyckelstyrning, utvärdera en tredjeparts HSM som en tjänst eller ett lokalt HSM-kluster som central nyckelauktoritet.
6. Beräkna den totala ägandekostnaden: Jämför initiala hårdvaru- och driftskostnader för lokala lösningar med timpriser för molnbaserad HSM vid din förväntade transaktionsvolym. Vid låga till måttliga volymer har molnbaserad HSM lägre total ägandekostnad. Vid mycket höga kryptografiska transaktionshastigheter (miljontals operationer per timme) kan dedikerad lokal hårdvara vara mer kostnadseffektiv.
7. Bedöm operativ förmåga: Lokal HSM kräver personal med HSM-specifik expertis för drift och underhåll. Molnbaserade HSM-tjänster minskar men eliminerar inte detta krav. Om din organisation inte har dedikerad expertis inom HSM-drift, minskar en hanterad molnbaserad HSM-tjänst eller en HSM som en tjänst från en specialiserad leverantör den operativa risken avsevärt.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att välja, driftsätta och driva HSM-infrastruktur för både moln- och lokala miljöer, från initial kravbedömning till löpande generering av efterlevnadsbevis.

• HSM som en tjänst: Krypteringskonsulttjänster HSM som en tjänst Tillhandahåller dedikerad FIPS 140-2 nivå 3 HSM-infrastruktur som en hanterad tjänst, tillgänglig för arbetsbelastningar över molnleverantörer och lokala miljöer. Lämplig som en BYOK- och HYOK-nyckelgenereringskälla, som en centraliserad nyckelauktoritet för flera moln och som ett hanterat alternativ till att distribuera och driva lokal HSM-hårdvara. Stöds av ISO/IEC 27001:2022-certifierad verksamhet.
• PKI som en tjänst: För organisationer som använder HSM:er för att skydda CA:s privata nycklar, Encryption Consultings PKI som en tjänst Tillhandahåller en helt hanterad privat CA med HSM-baserad CA-nycklarlagring, ACME-automatiserad certifikatutfärdande och integration med alla större molnplattformar. Eliminerar kravet på att använda lokala HSM:er enbart för PKI CA-nycklarskydd.
• HSM-rådgivning och implementeringstjänster: Om du distribuerar lokala HSM:er eller utvärderar molnbaserade HSM-tjänster, Encryption Consultings HSM-tjänster täcka HSM-val och storleksbestämning, design av högtillgänglighetskluster, PKCS#11 och REST API-integration med applikationer, nyckelceremoniprocedurer för generering av CA-rotnycklar, dokumentation av FIPS-efterlevnad och löpande operativ support.
• CBOM-säker: Krypteringskonsulttjänster CBOM-säkerhet upptäcker och inventerar alla kryptografiska tillgångar i dina moln- och lokala miljöer, inklusive HSM-baserade nycklar, moln-KMS-nycklar och certifikat. Tillhandahåller en kryptografisk materiallista (CBOM) i CycloneDX-format som identifierar nycklar utan HSM-skydd, nycklar som närmar sig rotationsdeadlines och nycklar som använder föråldrade algoritmer.
• PQC-beredskap: NIST slutförde postkvantkryptografistandarderna FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. NIST IR 8547 pekar mot att RSA och ECC avskrivs för nya användningsområden runt 2030. HSM:er måste stödja postkvantalgoritmer före den övergången, och inte all nuvarande HSM-hårdvara kommer att kunna uppgraderas enbart via firmware. Encryption Consultings PQC-beredskap Tjänsten utvärderar din HSM-egendoms väg efter kvantmigrering och utformar HSM-uppgraderings- eller ersättningssekvensen.

För att diskutera dina HSM-distributionskrav, kontakta Encryption Consulting.

Slutsats

Molnbaserade och lokala HSM:er använder samma validerade kryptografiska hårdvaruteknik. Distributionsmodellen avgör vem som använder hårdvaran, vilken latens- och kostnadsstruktur som gäller och hur HSM:en passar in i er nyckelkontrollmodell (native, BYOK eller HYOK). För de flesta organisationer ger molnbaserade HSM-tjänster, särskilt dedikerade tjänster med en enda hyresgäst, motsvarande säkerhet som lokala HSM:er med betydligt lägre driftskostnader och total ägandekostnad. Lokala HSM:er är fortfarande rätt val för latenskrav på under en millisekund, miljöer med begränsat utrymme och jurisdiktioner där ingen molnbaserad HSM-tjänst uppfyller kraven på datalokalisering.

Beslutet är inte helt binärt. Många organisationer kombinerar modeller: en lokal eller tredjeparts HSM som BYOK-nyckelgenereringsauktoritet, molnbaserade KMS-tjänster som det operativa nyckelhanteringslagret för molnarbetsbelastningar och molnbaserade HSM-tjänster för specifika högsäkerhetsarbetsbelastningar som kräver FIPS 140-2 nivå 3 i molnmiljön. Att utforma den arkitekturen korrekt och underhålla IAM-modellen, rotationsschemat och granskningsloggningen över alla lager är där den verkliga operativa komplexiteten ligger.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan molnbaserade HSM:er och lokala HSM:er?

Molnbaserade HSM:er är FIPS-validerade hårdvarusäkerhetsmoduler som drivs av en molnleverantör eller tredjepartstjänst i ett fjärrdatacenter, åtkomliga via ett nätverks-API. Lokala HSM:er är fysiska apparater installerade i din egen anläggning. Båda använder samma underliggande kryptografiska hårdvara och kan uppnå FIPS 140-2 nivå 3-validering. Den viktigaste skillnaden är vem som driver hårdvaran, vem som har fysisk åtkomst, vad latensprofilen är och om kostnaderna är kapital- eller driftskostnader.

Vilket är säkrast: molnbaserade HSM:er eller lokala HSM:er?

Båda kan uppnå FIPS 140-2 nivå 3-validering. Säkerhet beror mer på distributionskonfiguration och nyckelhanteringspraxis än på distributionsmodell. Lokal hantering ger din organisation fysisk nyckelförvaring. Välkonfigurerade dedikerade moln-HSM-tjänster ger jämförbar eller bättre säkerhet än dåligt underhållna lokala kluster. Riskprofilen för en dedikerad moln-HSM med en enda hyresgäst från en större leverantör är jämförbar med en lokal HSM för de flesta hotmodeller.

Vad är BYOK och hur relaterar det till val av HSM?

BYOK (Bring Your Own Key) innebär att du genererar krypteringsnyckelmaterial i din egen HSM och importerar det till en molnleverantörs KMS. En lokal HSM eller en dedikerad moln-HSM fungerar som källa för BYOK-nyckelgenerering. Molnleverantören använder ditt importerade material för krypteringsåtgärder men du behåller källan. HYOK går längre: nyckeln kommer aldrig in i molnleverantörens infrastruktur, vilket kräver kryptering på klientsidan med en nyckel som hanteras helt i din egen HSM.

Vad kostar molnbaserad HSM jämfört med lokal HSM?

AWS CloudHSM tar cirka 1.45 dollar per timme och instans, cirka 1 040 dollar per månad för en enskild instans eller 2 100 dollar per månad för ett HA-kluster med två instanser. Lokala HSM:er kräver 20 000 till 40 000 dollar eller mer per enhet i förskott, plus licenser för hanteringsprogramvara, datacenterkostnader och personaltid. Moln-HSM har lägre total ägandekostnad vid låga till måttliga volymer. Lokala funktioner kan bli mer kostnadseffektiva vid mycket höga kryptografiska transaktionshastigheter där API-anropspriser ackumuleras avsevärt.

Stöder molnbaserade HSM:er FIPS 140-2 nivå 3?

Dedikerade moln-HSM-tjänster gör följande: AWS CloudHSM använder Luna Network HSM-hårdvara på FIPS 140-2 nivå 3, Azure Dedicated HSM använder Entrust nShield Connect på nivå 3 och GCP Cloud HSM tillhandahåller nivå 3-skydd för HSM-baserade nycklar. Delade moln-KMS-tjänster utan en dedikerad HSM-nivå använder nivå 2, inte nivå 3. Verifiera alltid den exakta tjänstenivån och skyddsnivån när nivå 3 är ett specifikt efterlevnadskrav.

När bör en organisation välja lokala HSM:er framför molnbaserade HSM:er?

Välj lokal hantering när: applikationen kräver kryptografiska svarstider på under en millisekund som ett moln-API inte kan uppfylla; myndighetskrav kräver att nycklar stannar på en specifik fysisk plats eller jurisdiktion utan tillgänglig moln-HSM-tjänst; miljön är air-gapad utan internetanslutning; eller volymerna av kryptografiska transaktioner är tillräckligt höga för att prissättningen för moln-API-anrop överstiger kostnaden för ägd hårdvara. För de flesta andra användningsfall ger moln-HSM-tjänster motsvarande säkerhet med lägre driftskostnader.