Google Cloud Platform (GCP) – Introduktion till Google Cloud HSM

Google Cloud HSM är en hanterad tjänst på Google Cloud Platform (GCP) som tillhandahåller FIPS 140-2 nivå 3-validerade hårdvarusäkerhetsmoduler (HSM) som kryptografisk backend för Google Cloud KMS (Key Management Service). Detta är viktigt eftersom FIPS 140-2 nivå 3-hårdvaruvalidering är ett obligatoriskt krav för FedRAMP High-, PCI DSS- och eIDAS-kvalificerade signaturarbetsbelastningar, och standard Cloud KMS-programvaruskyddade nycklar uppfyller inte den tröskeln. Den rekommenderade åtgärden är att skapa Cloud KMS-nycklar med HSM-skyddsnivån för alla reglerade arbetsbelastningar, aktivera automatisk nyckelrotation och konfigurera Cloud Audit Logs för att registrera varje kryptografisk operation mot en autentiserad identitet.

Snabbt svar: Vad är Google Cloud HSM och när behöver du det?

Google Cloud HSM är den HSM-baserade nyckelskyddsnivån inom Cloud KMS. När du skapar en Cloud KMS-nyckel med skyddsnivå HSM genereras nyckeln inuti FIPS 140-2 nivå 3-validerad hårdvara, kryptografiska operationer utförs innanför HSM-gränsen och nyckelmaterialet lämnar aldrig HSM i klartext. Du behöver Cloud HSM när ditt efterlevnadsramverk kräver FIPS 140-2 nivå 3-nyckelskydd (FedRAMP High, PCI DSS för högvärdiga nycklar, eIDAS), när du behöver hårdvaruattestering som bevisar att nyckelmaterialet genererades i en manipulationssäker enhet, eller när din organisations säkerhetspolicy kräver dedikerad hårdvara för krypteringsnycklars förvaring på GCP. För arbetsbelastningar som inte kräver hårdvaruvalidering på nivå 3 är Cloud KMS-programvaruskyddade nycklar på FIPS 140-2 nivå 1 enklare och betydligt billigare.

Key Takeaways

• Cloud HSM använder FIPS 140-2 nivå 3-validerade HSM:er: Nycklar som skapats med HSM-skyddsnivån i Cloud KMS genereras och används exklusivt inom HSM-klustret. Nyckelmaterial lämnar aldrig HSM i klartext. HSM-klustret är regionalt bundet; nycklar kan inte flyttas utanför GCP-regionen där de skapades.
• Cloud HSM nås via samma Cloud KMS API som programvaruskyddade nycklar: Inga programändringar krävs för att växla från nyckelskydd på programnivå till nyckelskydd på HSM-nivå. Skyddsnivån ställs in när nyckeln skapas och kan inte ändras efteråt.
• HSM-firmware kontrolleras av leverantören och Google kan inte ändra den: All HSM-firmware signeras digitalt av hårdvaruleverantören. Denna leverantörskontroll över firmware är en viktig säkerhetsinvariant som förhindrar att Google introducerar obehöriga kodändringar i HSM-miljön.
• Cloud HSM stöder BYOK via Cloud KMS-importjobb: Du kan generera nyckelmaterial i ditt eget HSM eller nyckelhanteringssystem, omsluta det och importera det till Cloud KMS med HSM-skyddsnivån. Cloud External Key Manager (Cloud EKM) stöder HYOK, där nyckeln aldrig går in i GCP alls.
• Cloud HSM-nyckelversioner kostar 2.50 USD per månad per aktiv version: Detta är betydligt högre än programvaruskyddade nyckelversioner (0.06 USD per månad). Använd HSM-skydd endast där det krävs enligt föreskrifter eller policy för att undvika onödiga kostnader.

Vad är Google Cloud HSM?

Google Cloud HSM är en hanterad molntjänst inom Google Cloud Platform som tillhandahåller infrastruktur för hårdvarusäkerhetsmoduler (HSM) som kryptografisk nyckellagring och driftbackend för Google Cloud KMS. En HSM (Hardware Security Module) är en dedikerad fysisk datorenhet utformad för att skydda kryptografiska nycklar inom en manipulationssäker hårdvarugräns, generera nycklar med hjälp av hårdvarugeneratorer för slumptalsnummer och utföra kryptografiska operationer (kryptering, dekryptering, signering, verifiering) inom den gränsen så att nyckelmaterial aldrig behöver lämnas i klartext.

När du skapar en nyckel i Cloud KMS och anger HSM-skyddsnivån, instruerar du Cloud KMS att generera och lagra nyckeln inuti Cloud HSM-klustret snarare än i programvarubaserade kryptografiska moduler. Cloud HSM-tjänsten nås via samma Cloud KMS API och klientbibliotek som programvaruskyddade nycklar. Befintliga applikationer som använder Cloud KMS kräver inga kodändringar för att använda Cloud HSM; endast parametern för skyddsnivån vid nyckelskapandet ändras.

Cloud HSM hanteras helt av Google: den fysiska HSM-hårdvaran, firmware, nätverk och hög tillgänglighet är Googles operativa ansvar. Google förser HSM:er med auktoriseringskontroller för flera parter, logiska och fysiska skyddsåtgärder samt separation av uppgifter mellan Cloud HSM-administratörer och loggningsadministratörer. Kundens ansvar är konfiguration av nyckelpolicyer, IAM-åtkomstkontroll, schemaläggning av nyckelrotation och övervakning av revisionsloggar.

FIPS 140-2 Nivå 3-validering och vad det innebär

FIPS 140-2 (Federal Information Processing Standard 140-2) är NIST-standarden som definierar säkerhetskrav för kryptografiska moduler. Den specificerar fyra säkerhetsnivåer:

Nivå 1 kräver grundläggande kryptografiska algoritmer. Nivå 2 lägger till manipulationssäker fysisk säkerhet (förseglingar eller beläggningar som visar tecken på manipulering). Nivå 3 lägger till manipulationssäker fysisk säkerhet som aktivt förstör känsliga säkerhetsparametrar när manipulering upptäcks och kräver identitetsbaserad autentisering innan kryptografiska operationer utförs. Nivå 4 ger ett komplett fysiskt säkerhetshölje som skyddar mot miljöattacker.

Standard Cloud KMS-programvaruskyddade nycklar valideras på FIPS 140-2 nivå 1. Cloud HSM-skyddade nycklar valideras på FIPS 140-2 nivå 3. Det här är den skillnad som är viktig för reglerade arbetsbelastningar: FedRAMP High, PCI DSS-distributioner med hög säkerhet och eIDAS-kvalificerade enheter för att skapa signaturer (QSCD) kräver nivå 3, inte nivå 1.

En kritisk säkerhetsegenskap hos Cloud HSM är att HSM:s firmware är digitalt signerad av hårdvaruleverantören och Google kan inte skapa eller ändra den. Denna leverantörskontroll över firmware förhindrar att Google introducerar kodändringar som kan försvaga HSM:s säkerhetsgränser, exportera nyckelmaterial eller kringgå manipuleringsskyddsmekanismerna. Alla firmwareuppdateringar från leverantören är signerade, inklusive utvecklingsfirmware som används för testning. Det är denna egenskap som gör det möjligt för kunder att kryptografiskt intyga att deras nycklar genererades och förblir exklusivt inom hårdvarugränsen.

Cloud HSM-nyckelhierarki och lagringsarkitektur

Google Cloud HSM använder en nyckelhierarki i flera lager för att skydda kundens nyckelmaterial i hela Cloud KMS-infrastrukturen.

Rotnyckel: En rotnyckel genereras på HSM:en och lämnar under hela sin livslängd aldrig HSM-klustrets väldefinierade gränser. Kloning av rotnyckeln mellan HSM:er inom samma regionkluster är tillåten för hög tillgänglighet; rotnyckeln exporteras aldrig utanför det regionala HSM-klustret.

Kundnyckelomslag: Rotnyckeln används för att omsluta (kryptera) kundnycklar i vila. Kundnycklar lagras i omsluten form i Cloud KMS nyckeldatalager. När en kundnyckel behövs för en kryptografisk operation laddas den i HSM, packas upp av rotnyckeln innanför HSM-gränsen, används för operationen, och sedan tas nyckelmaterialet i klartext bort från HSM-minnet. HSM returnerar aldrig en omsluten kundnyckel till någon anropare. HSM:er kan endast använda kundnycklar för operativa ändamål.

Cloud KMS-nyckeldatalager: HSM:er används inte som permanent nyckellagring (HSM-lagringskapaciteten är begränsad). Kundnycklar krypteras av HSM-rotnyckeln och lagras i Cloud KMS nyckeldatalager, vilket tillhandahåller egenskaper för tillgänglighet, hållbarhet, residens och skydd. Datalagret använder autentiserad kryptering för att lagra kundnyckelmaterial, och all metadata autentiseras med HMAC för att upptäcka korruption. Varje timme skannar ett batchjobb allt nyckelmaterial och verifierar HMAC-giltighet och lyckad dekryptering. Datalagret upprätthåller timvisa ögonblicksbilder som sparas i fyra dagar, dagliga fullständiga säkerhetskopior till disk och band, och en ändringshistorik på radnivå för nödåterställning. Säkerhetskopior i datalagret finns inom den associerade GCP-regionen och krypteras i vila. Datalagrets ingenjörer har ingen åtkomst till kundnyckelmaterial i klartext.

Molnbaserad HSM-provisionering och säkerhetsinvarianter på systemnivå

Google tillhandahåller Cloud HSM:er i ett labb utrustat med fysiska och logiska skyddsåtgärder, inklusive flerpartsauktoriseringskontroller som förhindrar att en enskild administratör komprometterar HSM-konfigurationen. Följande systemnivåinvarianter gäller för varje Cloud HSM-kluster:

• Kundnycklar kan inte extraheras som klartext: Ingen Cloud HSM-åtgärd returnerar kundnyckelmaterial i klartext till någon som ringer, inklusive Google-anställda.
• Kundnycklar kan inte flyttas utanför ursprungsregionen: Nycklar som skapas i en Cloud KMS-nyckelring är bundna till GCP-regionen för den nyckelringen och kan inte migreras till en annan region.
• Alla konfigurationsändringar skyddas genom flera säkerhetsåtgärder: Ändringar i HSM-konfigurationen kräver auktorisering av flera parter, vilket förhindrar kompromisser mellan en aktör.
• Administrativa operationer loggas med separation av arbetsuppgifter: Cloud HSM-administratörer och loggningsadministratörer är separata roller. Administratörer kan inte ändra eller ta bort sina egna granskningsloggar.
• HSM:er är skyddade mot manipulering under hela sin livscykel: Fysiska manipuleringsskyddsmekanismer är aktiva från etablering till avveckling, och detektering och respons på försök att infoga skadlig hårdvara eller programvara eller extrahera hemligheter.

Viktiga kontrollmodeller: Native Cloud HSM, BYOK och HYOK

Cloud HSM stöder tre viktiga kontrollmodeller med betydande olika säkerhets- och suveränitetsegenskaper.

Native Cloud HSM (Google-genererat nyckelmaterial)

I standardmodellen för Cloud HSM genererar Google nyckelmaterialet inuti HSM-klustret. Du skapar en Cloud KMS-nyckel med skyddsnivå HSM, och Cloud KMS genererar nyckeln inuti HSM, omsluten av HSM-rotnyckeln, och lagrar den i Cloud KMS-datalagret. Du styr vem som kan använda nyckeln (via IAM och nyckelpolicy), när den roteras och om den inaktiveras eller förstörs. Google hanterar HSM-hårdvaran och genereringen av nyckelmaterialet, men kan inte använda nyckeln åt dig utan ett autentiserat API-anrop under din IAM-policy.

Den här modellen är lämplig för de flesta reglerade GCP-arbetsbelastningar. Du får FIPS 140-2 nivå 3-hårdvaruskydd, regional nyckelregistrering, hårdvaruattestering och molngranskningsloggar per operation, utan någon driftsbörda för HSM-hårdvaruhantering.

BYOK (Bring Your Own Key) via molnbaserade KMS-importjobb

Cloud KMS Import Jobs stöder import av externt genererat nyckelmaterial till Cloud KMS med HSM som målskyddsnivå. Du genererar 256-bitars AES-nyckelmaterial (eller RSA/ECC-nyckelmaterial för asymmetriska nycklar) i din egen HSM eller nyckelhanteringssystem, omsluter det med importjobbets omslutningsnyckel (en RSA-OAEP- eller AES-KWP-omsluten nyckel som laddats ner från importjobbet) och laddar upp det omslutna materialet till Cloud KMS. När importjobbet tar emot det omslutna materialet packas det upp i Cloud HSM-klustret med importjobbets privata nyckel och lagrar det kundlevererade nyckelmaterialet under HSM-skydd.

BYOK uppfyller efterlevnadskrav som kräver kundgenererat nyckelmaterial. Du behåller det ursprungliga nyckelmaterialet i din egen HSM och kan ta bort den importerade kopian från Cloud KMS för att omedelbart återkalla GCP:s möjlighet att använda nyckeln. Observera att GCP har operativ åtkomst till nyckelmaterialet under användning (det måste läsas in i HSM för kryptografiska operationer); BYOK tillhandahåller provenienskontroll och återkallningsfunktion, men inte noll-GCP-åtkomst.

HYOK (Håll din egen nyckel) via Cloud External Key Manager

Cloud External Key Manager (Cloud EKM) är GCP-tjänsten som implementerar HYOK för Cloud KMS. Med Cloud EKM går krypteringsnyckeln aldrig in i GCP-infrastrukturen. När en Cloud KMS-åtgärd kräver nyckeln (till exempel kryptera en BigQuery-kolumn eller ett Cloud Storage-objekt) anropar Cloud KMS ditt externa nyckelhanteringssystem via en TLS-autentiserad anslutning, utför nyckelåtgärden i din externa KMS och returnerar endast resultatet till GCP. GCP lagrar endast chiffertext; den kan inte dekryptera dina data utan en live-anslutning till ditt externa nyckelhanteringssystem.

Cloud EKM är lämpligt för data som omfattas av suveränitetskrav där GCP-infrastrukturen i sig ligger utanför din förtroendegräns, eller för arbetsbelastningar där din hotmodell inkluderar Google som en potentiell åtkomstpunkt. Driftskostnaden är att varje krypterings- och dekrypteringsoperation kräver en anslutning med låg latens och hög tillgänglighet till ditt externa nyckelhanteringssystem. Eventuella avbrott i ditt externa KMS gör GCP-resurser som använder den nyckeln oåtkomliga. Encryption Consultings HSM as a Service tillhandahåller den externa FIPS 140-2 Level 3-nyckelhanteringsinfrastruktur som behövs för Cloud EKM-baserade HYOK-implementeringar.

Dimensionera	Native Cloud HSM (genererad av Google)	BYOK (Importjobb)	HYOK (Cloud EKM)
Nyckel genererad av	Moln-HSM-kluster	Kundens HSM (importerad till Cloud HSM)	Kund (kommer aldrig in i GCP)
FIPS 140-2 Nivå 3	Ja	Ja (importerat material lagrat i HSM)	Beror på externt KMS
GCP-åtkomst till nyckeln under användning	Ja (inom HSM-gränsen)	Ja (inom HSM-gränsen)	Nej
GCP kan dekryptera data om det tvingas	Ja	Ja (medan nyckeln finns i Cloud KMS)	Nej
Oberoende återkallelse	Inaktivera eller förstör nyckel via API	Ta bort importerat material omedelbart	Återkalla vid extern KMS
Automatisk nyckelrotation	Ja	Nej (manuell återimport krävs)	Hanteras av externt KMS
Operationell komplexitet	Låg	Medium	Hög
Extra kostnad	2.50 USD/nyckelversion/månad	2.50 USD/nyckelversion/månad + HSM-kostnad	0.04 USD/10 000 operationer + extern KMS-kostnad
Bäst för	De flesta reglerade GCP-arbetsbelastningar	Arbetsbelastningar som kräver kundnyckelns ursprung	Suveränitetsmandaterade miljöer med noll förtroende

IAM-modell för Google Cloud HSM-åtkomstkontroll

Åtkomstkontroll för Cloud HSM-verksamhet hanteras via Google Cloud IAM, Cloud KMS nyckelresurspolicyer och organisationspolicybegränsningar. IAM-modellen för Cloud HSM separerar tre operativa roller som inte får överlappa varandra.

Nyckeladministratör (cloudkms.admin): Skapar nyckelringar och nycklar, hanterar nyckelversioner, konfigurerar scheman för nyckelrotation, aktiverar och inaktiverar nyckelversioner och schemalägger nyckelversioner för förstöring. Rollen nyckeladministratör får inte beviljas något applikationstjänstkonto eller automatiserad pipeline. Nyckeladministratörsåtgärder loggas i Cloud Audit Logs som administratörsaktivitetshändelser, vilka inte kan inaktiveras.

Nyckeloperatör eller kryptoanvändare (cloudkms.cryptoKeyEncrypterDecrypter): Använder den molnbaserade HSM-skyddade nyckeln för att utföra krypterings- och dekrypteringsåtgärder. Detta är den roll som tilldelas applikationstjänstkonton som behöver kryptera eller dekryptera data med hjälp av HSM-nyckeln. Mer detaljerad uppdelning: cloudkms.cryptoKeyEncrypter tillåter endast kryptering, och cloudkms.cryptoKeyDecrypter beviljar endast dekryptering. Använd alltid lägsta behörighet: en tjänst som skriver krypterad data behöver Encrypter; en tjänst som läser krypterad data behöver Decrypter; endast tjänster som gör båda behöver EncrypterDecrypter.

Nyckelvisare (cloudkms.viewer): Kan visa nyckelmetadata (skyddsnivå, rotationsschema, nyckelstatus, skapandedatum) men kan inte använda nyckeln för kryptografiska operationer eller hantera dess livscykel. Lämplig för säkerhetsrevision, övervakning och efterlevnadsroller som behöver insyn i nyckelkonfigurationen utan operativ åtkomst.

Begränsningar i organisationspolicyn: Med GCP Organization Policy Service kan du tillämpa begränsningar på organisations-, mapp- eller projektnivå som gäller för alla Cloud KMS-nycklar inom omfattningen. Viktiga begränsningar inkluderar constraints/cloudkms.allowedProtectionLevels (kräva att alla nycklar måste använda HSM-skyddsnivån i specifika projekt), constraints/gcp.resourceLocations (tvinga fram att nyckelringar endast kan skapas i angivna regioner för datalagring), och inaktivera import eller export av nyckelmaterial på organisationsnivå. Dessa begränsningar ger ett skyddslager för policyer ovanför individuella IAM-behörigheter, liknande AWS Service Control Policies.

Nyckelrotation för moln-HSM-nycklar

Cloud KMS stöder automatisk nyckelrotation för HSM-skyddade nycklar. När du aktiverar automatisk rotation på en Cloud KMS-nyckel genererar Cloud KMS en ny HSM-baserad nyckelversion enligt det konfigurerade schemat. Den nya versionen blir den primära versionen och används för alla nya krypteringsåtgärder. Tidigare versioner behålls i aktiverat tillstånd och fortsätter att användas för dekryptering av data som krypterats med dessa versioner. Nyckelns resursnamn förblir oförändrat; rotationen är transparent för applikationer.

Nyckelrotationsperioder kan konfigureras med minst 24 timmar för de flesta symmetriska nyckeländamål. Den rekommenderade rotationsperioden för symmetriska HSM-nycklar är 90 dagar för miljöer med hög efterlevnad (i linje med PCI DSS-krav 3.7.4-riktlinjer för kryptoperioder) eller årligen för standardreglerade arbetsbelastningar. Varje rotationshändelse genererar en ny FIPS 140-2 nivå 3 HSM-genererad nyckelversion och loggar en händelse för att skapa nyckelversion i Cloud Audit Logs.

För importerat BYOK-nyckelmaterial är automatisk rotation inte tillgänglig eftersom Cloud KMS inte kan generera nya versioner av en externt ursprunglig nyckel. Du måste hantera BYOK-rotation manuellt: generera nytt nyckelmaterial i din externa HSM, skapa ett nytt importjobb för nyckeln, importera det nya materialet som en ny nyckelversion och ange den nya versionen som primär. Denna manuella process måste planeras och utföras inom din definierade kryptoperiod för att upprätthålla efterlevnad.

Förstöring av nyckelversioner har en obligatorisk schemalagd raderingsperiod på 24 timmar (konfigurerbar upp till 120 dagar). Under detta fönster kan förstöringen avbrytas. När den schemalagda tiden har gått förstörs nyckelversionen och allt nyckelmaterial permanent och kan inte återställas. Schemalagd förstöring av en HSM-nyckelversion genererar omedelbart en Cloud Audit Log Admin Activity-händelse, vilket gör det möjligt för säkerhetsteam att upptäcka och potentiellt avbryta oavsiktlig eller obehörig förstöring.

Molngranskningsloggar för moln-HSM-åtgärder

Varje Cloud KMS- och Cloud HSM-operation genererar en molnrevisionsloggpost. GCP:s molnrevisionsloggar är den primära revisionsloggen för all nyckelhantering och kryptografiska operationer på GCP, och de är ett efterlevnadskrav enligt PCI DSS-krav 10, HIPAA:s revisionskontrollstandard (45 CFR 164.312(b)) och FedRAMP AU-kontroller.

Aktivitetsloggar för administratörer (alltid aktiverade, kan inte inaktiveras): Registrera skapande av nycklar, skapande av nyckelversioner, ändringar av nyckelversionstillstånd (aktivera, inaktivera, schemalägg förstöring, återställning), uppdateringar av nyckelpolicyer (ändringar av IAM-bindningar) och skapande och slutförande av importjobb. Dessa loggar skrivs alltid och kan inte stängas av av någon användare, inklusive projektägare.

Dataåtkomstloggar (explicit aktiverade): Registrera kryptografiska operationer: Kryptera, Dekryptera, AsymmetricSign, AsymmetricDecrypt, MacSign, MacVerify. Dataåtkomstloggar måste aktiveras explicit på projekt- eller organisationsnivå för Cloud KMS. När detta är aktiverat registrerar varje krypterings- och dekrypteringsanrop det begärande tjänstekontot, nyckelversionens ARN, tidsstämpeln och den anropande IP-adressen eller tjänstenätverket. För reglerade arbetsbelastningar är det obligatoriskt att aktivera granskningsloggar för Dataåtkomst för Cloud KMS.

Dirigera molngranskningsloggar till molnloggning (standard) och exportera dem dessutom till molnlagring för långsiktig lagring (PCI DSS kräver 12 månaders logglagring, med 3 månader omedelbart tillgänglig). Konfigurera loggbaserade aviseringar i molnövervakning för följande händelser: schemaläggning av nyckelversionsförstörelse för produktionsnycklar (avisering omedelbart); ändringar av IAM-bindningar på en Cloud KMS-nyckelring eller nyckel; dekrypteringsåtgärder från ett tjänstkonto som inte finns med i den godkända listan för den nyckeln; och krypterings- eller dekrypteringsåtgärder som kommer från ett oväntat källnätverk.

Google Cloud HSM-prissättning

Prissättning för moln-HSM har två komponenter: lagring av nyckelversioner och anrop av kryptografiska operationer.

Lagring av nyckelversioner: HSM-skyddade nyckelversioner kostar 2.50 USD per aktiv nyckelversion per månad. Programvaruskyddade nyckelversioner kostar 0.06 USD per aktiv nyckelversion per månad. Prisskillnaden återspeglar kostnaden för dedikerad HSM-hårdvaruinfrastruktur. Nyckelversioner i tillståndet Schemalagd för förstöring eller Förstörd faktureras inte.

Kryptografiska operationer: Symmetriska krypterings- och dekrypteringsoperationer med HSM-skyddade nycklar kostar 0.03 USD per 10 000 operationer, samma som programvaruskyddade nycklar. Asymmetriska signerings- och dekrypteringsoperationer kostar mellan 0.03 USD och 0.15 USD per 10 000 operationer beroende på nyckeltyp och algoritm. Moln-EKM-operationer (för HYOK) medför ytterligare 0.04 USD per 10 000 operationer utöver den externa KMS:ens egna avgifter.

Kostnadsoptimering: Cloud KMS har ingen motsvarighet till AWS KMS S3 Bucket Key-funktion för att minska API-anropskostnader. För GCP-arbetsbelastningar med hög volym som använder Cloud Storage, BigQuery eller andra tjänster med KMS-anrop per objekt, använd DEK-cachning (data encryption key) på applikationslagret där din säkerhetspolicy tillåter det. DEK-cachning innebär att applikationen hämtar klartext-DEK från Cloud KMS en gång per session eller tidsfönster och använder den lokalt för flera krypterings-/dekrypteringsoperationer, vilket avsevärt minskar Cloud KMS API-anropsvolymen. Riskavvägningen är att klartext-DEK lagras i applikationsminnet under cachefönstrets varaktighet.

Moln-HSM i multimoln- och hybridarkitekturer

Cloud HSM är en GCP-nativ tjänst som är avsedd för GCP-infrastruktur. Organisationer som arbetar med GCP och andra molnleverantörer eller lokala miljöer behöver en tydlig strategi för konsekvent nyckelstyrning över hela infrastrukturen. Tre mönster åtgärdar detta:

• Inbyggd HSM per moln med enhetlig styrning: Använd Cloud HSM för GCP-arbetsbelastningar, AWS CloudHSM för AWS-arbetsbelastningar och Azure Dedicated HSM för Azure-arbetsbelastningar, men distribuera en centraliserad plattform för nyckellivscykelhantering som aggregerar nyckelinventering, rotationsstatus, efterlevnadsposition och granskningsloggar över alla tre. Detta bevarar inbyggd molnprestanda och FIPS Level 3-validering i varje moln samtidigt som det ger molnövergripande insyn för insamling av efterlevnadsbevis.
• Centraliserad BYOK från en extern HSM: Generera allt nyckelmaterial från en enda extern HSM eller HSM som en tjänst som är oberoende av alla molnleverantörer. Importera härledda nycklar till Cloud KMS som BYOK-nycklar (med HSM-skyddsnivå) för GCP-arbetsbelastningar, till AWS KMS för AWS-arbetsbelastningar och till Azure Key Vault för Azure-arbetsbelastningar. All kryptering i alla moln spåras tillbaka till en enda auktoritativ nyckelkälla med en enda återkallningspunkt. Krypteringskonsultföretag HSM som en tjänst tillhandahåller den externa FIPS 140-2 nivå 3 HSM-infrastrukturen för den här modellen, åtkomlig från GCP, AWS och Azure samtidigt.
• Moln-EKM med en delad extern nyckel (HYOK över alla moln): Använd GCP Cloud EKM för GCP-arbetsbelastningar och motsvarande externa nyckelreferenser i AWS och Azure, där alla moln pekar till samma externa nyckelhanteringssystem. GCP, AWS och Azure lagrar var och en endast chiffertext; den externa KMS-tjänsten innehåller nycklarna och hanterar alla dekrypteringsoperationer. Detta är den starkaste suveränitetsmodellen över flera moln, men kräver att den externa KMS-tjänsten har hög tillgänglighet för alla molnarbetsbelastningar.

Efterlevnad: PCI DSS, FedRAMP, HIPAA och eIDAS

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025): Cloud HSM uppfyller krav 3.7.1 (nyckelgenerering med HSM eller annan branschgodkänd teknik) när nycklar som skyddar kortinnehavardata skapas med HSM-skyddsnivå. Molngranskningsloggar för Cloud KMS-dataåtkomsthändelser uppfyller krav 10 (loggning och övervakning). Cloud KMS-nyckelrotationsscheman stöder krav 3.7.4 (periodisk nyckelrotation). GCP:s PCI DSS-certifierade infrastruktur (Google Cloud är listad på PCI SSC:s webbplats som en nivå 1-tjänsteleverantör) täcker Cloud HSM-infrastrukturlagret; kunden förblir ansvarig för IAM-konfiguration, nyckelpolicy och kontroller på applikationslagret.

FedRAMP: Cloud HSM-skyddade nycklar uppfyller FedRAMP Highs krav för FIPS 140-2 Nivå 3-validerade kryptografiska moduler enligt SC-12 (Cryptographic Key Establishment and Management) och SC-28 (Protection of Information at Rest). Google Cloud-tjänster inklusive Cloud KMS och Cloud HSM är auktoriserade enligt FedRAMP High. Standard Cloud KMS-programvaruskyddade nycklar (Nivå 1) uppfyller inte FedRAMP Highs Nivå 3-krav; HSM-skydd krävs för FedRAMP High-data.

HIPAA: Cloud HSM uppfyller HIPAA:s tekniska skyddsåtgärd för kryptering och dekryptering (45 CFR 164.312(a)(2)(iv)) för ePHI i vila när GCP-tjänster som krypterar ePHI använder Cloud HSM-skyddade nycklar. Googles Business Associate Agreement (BAA) täcker Cloud KMS och Cloud HSM, vilket gör dem berättigade till ePHI-arbetsbelastningar. Cloud Audit Logs Data Access-händelser för Cloud KMS uppfyller HIPAA:s Audit Control-standard (45 CFR 164.312(b)).

eIDAS (EU): Kvalificerade elektroniska signaturer enligt eIDAS kräver kvalificerade enheter för att skapa signaturer (QSCD) som uppfyller minst FIPS 140-2 nivå 3 eller Common Criteria EAL4+. Cloud HSM:s FIPS 140-2 nivå 3-validering är kompatibel med detta krav för HSM-skyddsgränsen. EU-organisationer som implementerar kvalificerade signaturer eller kvalificerade sigill på GCP bör verifiera att den specifika GCP-regionen som används har Cloud HSM-tillgänglighet och att den övergripande arkitekturen uppfyller deras nationella tillsynsmyndighets krav för QSCD-klassificering.

Skydd av molnbaserad HSM kontra molnbaserad KMS: Beslutsguide

Använd följande kriterier för att avgöra om en nyckel ska använda HSM eller programvaruskyddsnivå i Cloud KMS.

Kriterium	Använd moln-HSM (HSM-skyddsnivå)	Använd Cloud KMS-programvara (programvaruskyddsnivå)
FIPS 140-2 Nivå 3 krävs	Ja (FedRAMP High, vissa PCI DSS, eIDAS)	Nej (Nivå 1 tillräcklig)
Hårdvarucertifiering krävs	Ja	Nej
Nyckelmaterial måste finnas i dedikerad hårdvara	Ja	Nej
Data typ	ePHI, PAN, sekretessbelagd, reglerad	Allmänna arbetsbelastningar, interna data
Kostnadskänslighet	Högre (2.50 USD/nyckelversion/månad)	Lägre (0.06 USD/nyckelversion/månad)
BYOK-krav	Stöds (via molnbaserade KMS-importjobb)	Stöds (via molnbaserade KMS-importjobb)
HYOK-krav	Använd Cloud EKM (nyckeln går aldrig in i GCP)	Använd Cloud EKM (nyckeln går aldrig in i GCP)

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 designa, implementera och granska Google Cloud HSM-konfigurationer för GCP-arbetsbelastningar, från initial arkitektur till kontinuerlig generering av efterlevnadsbevis.

• GCP-nyckelhanteringsarkitektur: Vi utformar er Cloud KMS- och Cloud HSM-arkitektur, inklusive val av skyddsnivå per nyckeltyp, nyckelring och placeringsstrategi för nyckelring för datalagring, IAM-rollstruktur med separation av uppgifter, organisationspolicybegränsningar för att upprätthålla HSM-skyddskrav, BYOK-importarbetsflöden och Cloud EKM-integration för HYOK-arbetsbelastningar. Se vår molntjänster för dataskydd.
• HSM som en tjänst för molnbaserad EKM och BYOK: För HYOK-implementeringar som använder Cloud EKM, eller BYOK-implementeringar som kräver FIPS 140-2 Level 3-nyckelgenerering utanför GCP, Encryption Consultings HSM som en tjänst tillhandahåller den externa HSM-infrastrukturen. Nycklar som genereras i HSM as a Service kan importeras till Cloud KMS via importjobb för BYOK, eller fungera som den externa nyckel som refereras av Cloud EKM för HYOK, vilket bibehåller FIPS 140-2 nivå 3-skyddsgränsen utanför GCP.
• CBOM Secure för GCP-nyckelidentifiering: GCP-miljöer med många projekt har ofta inkonsekventa nyckelskyddsnivåer över Cloud Storage-buckets, BigQuery-dataset, GKE-kluster och Compute Engine-diskar. Encryption Consulting's CBOM-säkerhet upptäcker och inventerar alla Cloud KMS-nyckelkonfigurationer, skyddsnivåer, rotationsstatusar och IAM-policybindningar över GCP-projekt, och genererar en kryptografisk materiallista (CBOM) i CycloneDX-format som identifierar nycklar med hjälp av programvaruskydd där HSM krävs, nycklar utan rotationsscheman och övertillåtna IAM-bindningar.
• PCI DSS och FedRAMP-efterlevnadsrådgivning: Vi mappar er Cloud HSM-konfiguration till de specifika kraven i PCI DSS v4.0.1 (krav 3.7.1, 3.7.4 och 10), FedRAMP High (SC-12, SC-28), HIPAA Technical Safeguards och eIDAS QSCD-krav. Vi identifierar luckor, tar fram ett paket med bevis för efterlevnad och stöder förfrågningar från QSA och FedRAMP-bedömare. Se våra Rådgivning om efterlevnad.
• PQC-beredskap för moln-HSM: 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 avvecklas för nya användningsområden runt 2030. GCP Cloud HSM stöder för närvarande asymmetriska RSA- och ECDSA-nycklar som kommer att behöva migreras till postkvantalgoritmer före den tidslinjen. Google Clouds postkvantberedskapsplan för Cloud HSM och Cloud KMS utvecklas. Encryption Consultings PQC-beredskap Tjänsten mappar din GCP-nyckelegendom mot tidslinjen efter kvantmigreringen och utformar nyckelrotation och algoritmövergångssekvens.

För att diskutera er GCP Cloud HSM-arkitektur eller efterlevnadskrav, kontakta Encryption Consulting.

Slutsats

Google Cloud HSM tillhandahåller hårdvarubaserade nyckelskydd på FIPS 140-2 nivå 3 för GCP-arbetsbelastningar via Cloud KMS API, utan att några programändringar krävs för befintliga Cloud KMS-kunder. HSM-skyddsnivån är rätt val för reglerade arbetsbelastningar som kräver hårdvaruvalidering på nivå 3: användningsfall för FedRAMP High, PCI DSS-kortinnehavardata, HIPAA ePHI och eIDAS-kvalificerade signaturer. För arbetsbelastningar där nivå 3 inte krävs ger programvaruskyddade Cloud KMS-nycklar motsvarande API-upplevelse till en betydligt lägre kostnad.

De viktigaste operativa besluten för Cloud HSM är val av skyddsnivå vid nyckelskapande (kan inte ändras i efterhand), IAM-rolldesign med separering av nyckeladministratör från nyckeloperatör, aktivering av Cloud Audit Logs Data Access-händelser för Cloud KMS (inte aktiverat som standard), konfiguration av rotationsschema och BYOK- eller Cloud EKM-integration om myndighetskrav kräver kundnyckelproveniens eller noll-GCP-åtkomstsuveränitet. Att få dessa rätt vid arkitekturtillfället är betydligt enklare än att eftermontera dem i en distribuerad GCP-miljö när en efterlevnadsrevision identifierar luckor.

Vanliga frågor om partihandel med mat och dryck

Vad är Google Cloud HSM?

Google Cloud HSM är en hanterad molntjänst som tillhandahåller FIPS 140-2 nivå 3-validerade hårdvarusäkerhetsmoduler som nyckellagring och kryptografisk operationsbackend för Google Cloud KMS. Nycklar som skapas med HSM-skyddsnivån genereras inuti HSM-klustret, alla kryptografiska operationer utförs inuti HSM och nyckelmaterial lämnar aldrig HSM-gränsen i klartext. Cloud HSM nås via samma Cloud KMS API som programvaruskyddade nycklar; inga applikationsändringar krävs.

Vilken FIPS-valideringsnivå använder Google Cloud HSM?

Google Cloud HSM använder HSM:er som är validerade enligt FIPS 140-2 nivå 3, vilket lägger till krav på manipulationssäker fysisk säkerhet och identitetsbaserad autentisering utöver nivå 2. HSM-firmware signeras digitalt av hårdvaruleverantören; Google kan inte skapa eller modifiera HSM-firmware. Standard Cloud KMS-programvaruskyddade nycklar valideras på FIPS 140-2 nivå 1. För FedRAMP High, PCI DSS höga säkerhetskrav och eIDAS-kvalificerade signaturer krävs nivå 3, vilket gör Cloud HSM till rätt skyddsnivå.

Vad är skillnaden mellan programvaruskyddade nycklar i Cloud KMS och Cloud HSM-nycklar?

Programvaruskyddade nycklar valideras på FIPS 140-2 nivå 1 och genereras i Cloud KMS programvarukryptografiska moduler. HSM-skyddade nycklar valideras på FIPS 140-2 nivå 3 och genereras inuti HSM-hårdvaruklustret, med alla operationer utförda inom HSM-gränsen. Cloud KMS API är identiskt för båda; endast parametern protection_level som ställs in vid nyckelskapandet skiljer sig åt. HSM-skydd kostar 2.50 USD per nyckelversion per månad jämfört med 0.06 USD för programvaruskydd.

Har Google Cloud HSM stöd för BYOK?

Ja. Med importjobb i Cloud KMS kan du generera nyckelmaterial i din egen HSM och importera det till Cloud KMS med HSM som målskyddsnivå. Det importerade materialet lagras och används i Cloud HSM-klustret. Cloud External Key Manager (Cloud EKM) stöder HYOK, där nyckeln aldrig går in i GCP och alla kryptografiska operationer anropar ditt externa nyckelhanteringssystem vid körning.

Hur fungerar nyckelrotation i Google Cloud HSM?

Cloud KMS stöder automatisk nyckelrotation för HSM-skyddade nycklar. En ny HSM-genererad nyckelversion skapas enligt det konfigurerade schemat (minst 24 timmar; 90 dagar rekommenderas för efterlevnadsarbetsbelastningar). Den nya versionen blir primär för nya krypteringer; tidigare versioner behålls för dekryptering. Nyckelns resursnamn förblir detsamma; rotationen är transparent för applikationer. För BYOK-nycklar med importerat material är automatisk rotation inte tillgänglig; du måste manuellt importera nytt nyckelmaterial som en ny version.

Vad kostar Google Cloud HSM?

HSM-skyddade nyckelversioner kostar 2.50 USD per aktiv nyckelversion per månad. Programvaruskyddade nyckelversioner kostar 0.06 USD per månad. Symmetriska kryptografiska operationer kostar 0.03 USD per 10 000 operationer för båda skyddsnivåerna. Asymmetriska operationer kostar 0.03 USD till 0.15 USD per 10 000 operationer beroende på nyckeltyp. Cloud EKM (HYOK) lägger till 0.04 USD per 10 000 operationer. Nyckelversioner i tillståndet Förstört faktureras inte.