Cloudgebaseerde vs. on-premises HSM's

De keuze tussen cloudgebaseerde en on-premises HSM's is bepalend voor wie de fysieke controle heeft over de meest gevoelige cryptografische processen van uw organisatie. Een Hardware Security Module (HSM) is een speciaal, fraudebestendig hardwareapparaat dat cryptografische sleutels genereert, opslaat en beheert binnen een beveiligde omgeving die is gevalideerd volgens FIPS 140-2 niveau 3. De keuze tussen het implementeren van HSM's in uw eigen datacenter of het afnemen ervan als een beheerde cloudservice heeft gevolgen voor uw sleutelbeheermodel, latentieprofiel, compliance, totale eigendomskosten en operationele overhead. Deze handleiding behandelt alle aspecten van die beslissing, zodat beveiligings- en infrastructuurteams het juiste model voor hun specifieke behoeften kunnen kiezen.

Kort antwoord: Cloudgebaseerd HSM of HSM op locatie?

Voor de meeste organisaties geldt: cloudgebaseerde HSM-services bieden een gelijkwaardige cryptografische beveiliging als on-premises HSM's, maar tegen lagere totale eigendomskosten, snellere implementatie en zonder de operationele last van het beheren van fysieke hardware. Kies voor on-premises HSM's wanneer uw applicatie een latentie van minder dan een milliseconde vereist die een netwerk-roundtrip niet kan halen, wanneer wettelijke voorschriften vereisen dat sleutels een specifieke fysieke locatie of jurisdictie nooit verlaten zonder beschikbare cloud-HSM-service, of wanneer u opereert in een air-gapped omgeving zonder cloudconnectiviteit. Voor multi-cloud- en hybride omgevingen die gecentraliseerd sleutelbeheer vereisen, is een HSM-as-a-Service van een derde partij die meerdere providers omvat vaak de meest praktische keuze.

Key Takeaways

• De cryptografische technologie is hetzelfde: Zowel cloudgebaseerde als on-premises HSM's gebruiken FIPS 140-2 Level 3-gecertificeerde hardware die dezelfde cryptografische bewerkingen uitvoert. Het implementatiemodel bepaalt wie de hardware beheert, niet wat de hardware doet.
• Cloud HSM verlaagt de operationele overhead, maar niet de beveiliging: Cloud HSM-services nemen de verantwoordelijkheid voor hardware-aanschaf, datacenterruimte, firmware-updates en HSM-clusterbeheer weg bij uw team. De cryptografische beveiliging blijft hardwarematig gewaarborgd, ongeacht wie de bediening verzorgt.
• BYOK en HYOK vereisen door HSM gegenereerd sleutelmateriaal: Zowel BYOK (Bring Your Own Key) als HYOK (Hold Your Own Key) implementaties maken doorgaans gebruik van een on-premises of dedicated cloud HSM als bron voor sleutelgeneratie. De keuze voor een HSM is daarmee een onderdeel van de cloudstrategie voor sleutelbeheer, en niet iets dat daar los van staat.
• Latentie is de meest voorkomende technische beperking die de voorkeur geeft aan on-premises oplossingen: Applicaties die een responstijd van minder dan een milliseconde van de HSM vereisen, kunnen de netwerklatentie van een cloud-HSM-API-aanroep niet tolereren. Hoogfrequent handelen, grootschalige betalingsverwerking en sommige PKI-ondertekeningsbewerkingen vallen in deze categorie.
• FIPS 140-2 Niveau 3 is beschikbaar in beide modellen: AWS CloudHSM, Azure Dedicated HSM en GCP Cloud HSM gebruiken allemaal hardware die is gevalideerd volgens FIPS 140-2 niveau 3. Gedeelde cloud-KMS-services zonder een dedicated HSM-laag gebruiken niveau 2, niet niveau 3. Controleer de exacte servicelaag wanneer niveau 3 vereist is.

Wat is een Hardware Security Module (HSM)?

Een hardwarebeveiligingsmodule (HSM) is een speciaal ontworpen fysiek computerapparaat dat cryptografische sleutels beschermt en cryptografische bewerkingen uitvoert binnen een fraudebestendige hardwareomgeving. HSM's zijn specifiek gebouwd voor sleutelbeveiliging: ze genereren sleutels met behulp van hardwarematige willekeurige getallengeneratoren, slaan sleutels op in een niet-exporteerbare vorm binnen de hardwareomgeving, voeren cryptografische bewerkingen (versleuteling, ontsleuteling, ondertekening, verificatie) uit binnen die omgeving zodat het sleutelmateriaal het apparaat nooit in onversleutelde vorm hoeft te verlaten, en detecteren en reageren op pogingen tot fysieke manipulatie door het sleutelmateriaal te wissen.

De beveiliging van een HSM wordt formeel gevalideerd via het NIST FIPS 140-2 (Federal Information Processing Standard) certificeringsprogramma. FIPS 140-2 definieert vier beveiligingsniveaus: Niveau 1 (basissoftware cryptografische module), Niveau 2 (manipulatiebestendige fysieke beveiliging), Niveau 3 (manipulatiebestendige fysieke beveiliging met identiteitsgebaseerde authenticatie en het op nul zetten van kritieke beveiligingsparameters bij detectie van manipulatie) en Niveau 4 (volledige fysieke beveiliging die beschermt tegen aanvallen vanuit de omgeving). FIPS 140-2 Niveau 3 is de standaardvereiste voor HSM-implementaties in bedrijven en gereguleerde omgevingen. NIST is momenteel bezig met de overgang naar FIPS 140-3, dat aansluit op ISO/IEC 19790; bestaande FIPS 140-2-validaties blijven tijdens de overgangsperiode geldig.

HSM's worden gebruikt voor een breed scala aan cryptografische taken: het beschermen van privésleutels voor certificeringsinstanties (CA's) in PKI-infrastructuren, het genereren en beschermen van encryptiesleutels die worden gebruikt voor transparante dataversleuteling (TDE) van databases, het beveiligen van privésleutels voor TLS-certificaten op waardevolle eindpunten, het uitvoeren van ondertekeningsbewerkingen voor codeondertekening en documentondertekening, het beschermen van sleutels die worden gebruikt voor de versleuteling en verificatie van pincodes van betaalkaarten, en het genereren van het BYOK-sleutelmateriaal dat wordt geïmporteerd in cloudgebaseerde sleutelbeheerservices.

HSM's op locatie: volledige controle, volledige verantwoordelijkheid

Een on-premises HSM is een fysiek apparaat dat uw organisatie aanschaft, installeert in uw eigen datacenter of colocatiecentrum, configureert, beheert en onderhoudt. De HSM-hardware maakt via uw interne netwerk verbinding met uw applicaties en sleutelbeheerinfrastructuur, doorgaans via PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) of REST API's, afhankelijk van het HSM-model en de integratievereisten van de applicatie.

Wat on-premises HSM's u bieden: Fysiek bezit en controle over de cryptografische hardware en de daarin opgeslagen sleutels. Geen afhankelijkheid van de beschikbaarheid of API van een cloudprovider voor cryptografische bewerkingen. Lokale netwerklatentie van minder dan een milliseconde voor cryptografische bewerkingen met hoge frequentie. De mogelijkheid om sleutelceremonies uit te voeren in een fysiek gecontroleerde omgeving voor het genereren van CA-privésleutels. Volledige naleving van vereisten inzake gegevenssoevereiniteit of lokalisatie die voorschrijven dat sleutels binnen een specifieke fysieke locatie of jurisdictie moeten blijven, waar geen cloud-HSM-service aanwezig is.

Wat on-premises HSM's u kosten: Aanschaf van de hardware (doorgaans $ 20,000 tot $ 40,000 per apparaat, afhankelijk van het model en de doorvoercapaciteit). Extra units voor high availability (HA) en disaster recovery-clusters, meestal minimaal twee units voor een productiebestendige omgeving. Licenties voor beheersoftware. Rackruimte, stroom en koeling in het datacenter. Tijd van gekwalificeerd personeel voor initiële configuratie, firmware-updates, partitiebeheer, implementatie van clientsoftware en doorlopend beheer. Vervangingscycli van de hardware (doorgaans 5 tot 7 jaar). Fysieke beveiligingsmaatregelen voor het datacenter waarin de HSM is gehuisvest.

Wanneer on-premises HSM's de juiste keuze zijn: Toepassingen met strenge latentie-eisen die geen netwerk-roundtrip naar een cloudservice tolereren (cryptografische bewerkingen met een latentie van minder dan een milliseconde voor hoogfrequent handelen, verwerking van PIN-blokken voor betaalterminals of realtime ondertekeningspipelines); wettelijke vereisten die fysieke sleutelbewaring in een specifieke faciliteit of land vereisen waar geen cloud-HSM-service beschikbaar is; geïsoleerde of geclassificeerde omgevingen zonder internetverbinding; organisaties met zeer hoge cryptografische transactievolumes waar de kosten voor cloud-API-aanroepen aanzienlijk hoger liggen dan die van eigen hardware; en sleutelceremonies voor het genereren van CA-rootsleutels waarbij fysieke aanwezigheid en getuigenprocedures vereist zijn.

Cloudgebaseerde HSM's: beheerde hardware, gedeeld of dedicated

Cloudgebaseerde HSM's zijn FIPS-gecertificeerde HSM-hardware die wordt beheerd door een cloudprovider of een externe dienstverlener, en die toegankelijk is voor uw applicaties via een geauthenticeerde API. De HSM-hardware bevindt zich fysiek in het datacenter van de serviceprovider. Uw applicaties communiceren nooit rechtstreeks met de HSM-hardware; ze roepen de API van de service aan, die de cryptografische bewerking doorstuurt naar de onderliggende HSM-hardware en het resultaat retourneert.

Cloudgebaseerde HSM-services vallen in twee categorieën met wezenlijk verschillende beveiligingsmodellen:

Toegewijde (enkele tenant) cloud-HSM-services

Speciale cloud-HSM-services leveren fysieke HSM-hardware exclusief aan uw organisatie. De sleutels of cryptografische bewerkingen van andere klanten delen de hardware of de HSM-partities niet met die van u. Voorbeelden hiervan zijn AWS CloudHSM (gebruikt Luna Network HSM-hardware, FIPS 140-2 Level 3, circa $ 1.45 per uur per instantie), Azure Dedicated HSM (gebruikt Entrust nShield Connect-hardware, FIPS 140-2 Level 3) en Azure Payments HSM (gebruikt Utimaco-hardware voor HSM-workloads voor betalingen). Bij een speciale cloud-HSM beheert de cloudprovider de fysieke infrastructuur, maar heeft geen toegang tot uw sleutels of de HSM-partities; u beheert zelf de HSM-software, partities en sleutelmateriaal via de eigen beheerinterface van de HSM.

Speciale cloud-HSM-services bieden een beveiligingsniveau dat zeer dicht in de buurt komt van on-premises HSM's: FIPS 140-2 Level 3-validatie, hardware voor één gebruiker en uitsluiting van de cloudprovider van sleuteltoegang. De belangrijkste verschillen met on-premises zijn de netwerklatentie van API-aanroepen (doorgaans 1 tot 5 milliseconden versus minder dan een milliseconde voor lokale oplossingen), de verantwoordelijkheid voor het operationeel beheer (u beheert de HSM-software en -partities, maar niet de fysieke hardware) en het prijsmodel (uurtarief versus eenmalige investering).

Gedeelde (multi-tenant) cloud-HSM-services

Gedeelde cloud-HSM-services maken gebruik van HSM-hardware die is gepartitioneerd en gedeeld door meerdere klanten. Uw sleutels zijn logisch geïsoleerd van de sleutels van andere klanten binnen de HSM, maar de fysieke hardware wordt gedeeld. Voorbeelden hiervan zijn AWS KMS met HSM-bescherming (gevalideerd volgens FIPS 140-2 niveau 2), GCP Cloud KMS met HSM-bescherming (gevalideerd volgens FIPS 140-2 niveau 3 voor HSM-beveiligde sleutels) en Azure Key Vault Premium (HSM-beveiligde sleutels). Deze services worden volledig beheerd: de cloudprovider beheert de hardware, de HSM-software en het sleutelbeheerplatform. Uw verantwoordelijkheid beperkt zich tot het configureren van sleutelbeleid, toegangscontrole en het beheer van de sleutellevenscyclus via de API van de cloudprovider.

Gedeelde cloud-HSM-services bieden de laagste operationele overhead en kosten. Het nadeel is dat de cloudprovider de HSM-hardware beheert en toegang heeft tot de onderliggende infrastructuur, of deze kan migreren, zelfs als de logische sleutelisolatie sterk is. Voor de meeste compliance-frameworks is een gedeelde HSM-service van een cloudprovider, ondersteund door een BAA, DPA of andere contractuele controle, voldoende. Voor workloads waarbij de cloudprovider geen toegang mag hebben tot sleutelmateriaal, is een dedicated cloud-HSM of een on-premises HSM noodzakelijk.

Belangrijkste besturingsmodellen: Native, BYOK en HYOK

De beslissing over de inzet van een HSM is nauw verbonden met het sleutelbeheermodel dat uw compliance-eisen of beveiligingsbeleid voorschrijven. Er bestaan ​​drie sleutelbeheermodellen, elk met verschillende implicaties voor HSM.

Native cloud-sleutelbeheer (door de provider beheerde sleutels)

De cloudprovider genereert en beheert alle encryptiesleutels in zijn eigen infrastructuur voor sleutelbeheer. Uw sleutels worden beschermd door HSM-hardware die door de provider wordt beheerd, maar u hebt geen inzicht in of controle over het fysieke sleutelmateriaal. U kunt sleutels gebruiken, roteren, uitschakelen en verwijderen via de API van de provider, maar u kunt niet onafhankelijk verifiëren of het sleutelmateriaal is gegenereerd met de herkomst die uw beleid vereist. Dit model vereist geen investering in of beheer van HSM van uw kant en is geschikt voor de meeste algemene cloudworkloads waarbij het auditspoor van het sleutelbeheer van de provider voldoende is voor uw compliancevereisten.

BYOK (Bring Your Own Key)

BYOK betekent dat u encryptiesleutels genereert in een HSM die u beheert (on-premises of een dedicated cloud-HSM), de sleutels exporteert (verpakt voor veilig transport) en importeert in de sleutelbeheerservice van de cloudprovider (AWS KMS, Azure Key Vault of GCP Cloud KMS). De cloudprovider gebruikt uw geïmporteerde sleutels om de data-encryptiesleutels te genereren die uw cloudgegevens beschermen. U behoudt de originele sleutels in uw HSM en kunt deze verwijderen uit de KMS van de cloudprovider om de provider onmiddellijk de mogelijkheid te ontnemen uw gegevens te decoderen.

BYOK voldoet aan de wettelijke vereisten die vereisen dat het sleutelmateriaal door de klant zelf wordt gegenereerd. Het vereist een on-premises HSM of een speciale cloud-HSM-service als bron voor sleutelgeneratie. Het KMS van de cloudprovider heeft operationele toegang tot het sleutelmateriaal tijdens gebruik; BYOK biedt u de mogelijkheid tot herkomstcontrole en intrekking, maar geen volledige toegang van de provider.

HYOK (Houd je eigen sleutel vast)

HYOK betekent dat de encryptiesleutel nooit in de infrastructuur van de cloudprovider terechtkomt. Uw applicatie of een clientbibliotheek versleutelt gegevens voordat deze naar de cloudopslag worden geüpload, met behulp van een sleutel die wordt gegenereerd en opgeslagen in uw eigen HSM (on-premises of een HSM-service van een derde partij die niet dezelfde provider is als uw gegevensopslag). De cloudprovider slaat alleen de versleutelde gegevens op en kan uw gegevens onder geen enkele operationele omstandigheid decoderen. HYOK vereist een on-premises HSM of een HSM-service van een derde partij die onafhankelijk van uw cloudopslagproviders opereert. Het biedt de sterkste gegevenssoevereiniteit ten koste van de hoogste operationele complexiteit.

Afmeting	Native cloud-sleutelbeheer	BYOK (Customer-Generated Key in Cloud KMS)	HYOK (Key Entirely Outside Cloud Provider)
HSM vereist	Nee (HSM van de zorgverlener)	Ja (om broncodemateriaal te genereren en te bewaren)	Ja (om bij elke bewerking een sleutel te genereren en te gebruiken)
HSM-implementatiemodel	Niet van toepassing	HSM op locatie of een dedicated cloud-HSM	HSM op locatie of HSM als service van een derde partij
Toegang van de provider tot de sleutel tijdens gebruik	Ja	Ja (operationele toegang)	Nee
Toegang van de provider tot gegevens in platte tekst	Ja (via sleutel)	Ja (via toets tijdens gebruik)	Nee
Onafhankelijke sleutelintrekking	Alleen via de API van de provider.	Ja (verwijder het bronmateriaal uit uw HSM)	Ja (onmiddellijk intrekken bij uw HSM)
Operationele complexiteit	Laag	Medium	Hoge
Best voor	Algemene cloudworkloads	Gereguleerde sectoren die een belangrijke herkomst vereisen.	Geheim, soevereiniteitsbevel, nultrust

Cloudgebaseerde versus on-premises HSM's: een volledige vergelijking

Afmeting	HSM op locatie	Speciaal voor de cloud bestemde HSM	Gedeelde cloud-HSM-service
FIPS 140-2 niveau 3	Ja	Ja	Afhankelijk van het serviceniveau (niveau 2 of 3)
Fysieke sleutelbewaring	Uw organisatie	Cloudprovider (alleen hardware; geen sleuteltoegang)	Cloudprovider (hardware en infrastructuur)
Hardwarebeheer	Uw organisatie	Cloudprovider (hardware); u beheert de HSM-software.	Cloudprovider (volledig beheerd)
Initiële kapitaalkosten	$20,000 tot $40,000+ per apparaat	Geen	Geen
Doorlopend kostenmodel	Personeelskosten, licenties, datacenterkosten	Uurtarief per instantie (ongeveer $ 1.45/uur voor AWS CloudHSM)	Per API-aanroep + kosten voor sleutelopslag
Implementatie tijd	Weken tot maanden (inkoop, installatie, configuratie)	Minuten tot uren	minuten
Wachttijd	Minder dan een milliseconde (lokaal netwerk)	1 tot 5 ms (rendement van de netwerk-API)	1 tot 10 ms (gedeelde service-API)
Hoge beschikbaarheid	Vereist meerdere apparaten en een HA-configuratie.	Beschikbaar via een multi-instance cluster of cross-AZ.	Geïntegreerd in de beheerde service.
Operationele overhead	Hoog (firmware, partities, clusterbeheer, personeel)	Gemiddeld (HSM-software en partitiebeheer)	Laag (alleen sleutelbeleid en toegangsbeheer)
Schaalbaarheid	Beperkt door hardwarecapaciteit; uitbreiding vereist aanschaf.	Voeg instanties toe wanneer nodig.	Weegt automatisch
Ondersteuning voor meerdere clouds	Ja (elke applicatie kan verbinding maken)	Beperkt tot het ecosysteem van die aanbieder.	Providerspecifiek
Verantwoordelijkheid voor naleving	Uw organisatie volledig	Gedeeld (de provider beheert de hardwareconformiteit)	Voornamelijk aanbieder
Luchtspleetomgevingen	Ja	Nee	Nee
BYOK-bronfunctionaliteit	Ja	Ja	Beperkt (sommige aanbieders ondersteunen het)
Best voor	Lage latentie, luchtgeïsoleerd, strikte lokalisatie, HYOK	FIPS Level 3, BYOK, multi-cloud met dedicated hardware	Algemene cloudworkloads, beheerde eenvoud

IAM-model voor HSM-toegangscontrole

Of u nu on-premises of cloudgebaseerde HSM's implementeert, toegangscontrole is net zo belangrijk als de hardwarebeveiliging zelf. Een FIPS 140-2 Level 3 HSM met permissieve toegangscontrole is niet veiliger dan een softwarematige sleutelopslag. Het IAM-model voor HSM's onderscheidt drie verschillende rollen die elkaar niet mogen overlappen.

De beheerdersrol van de HSM: Deze rol omvat het aanmaken en beheren van HSM-partities, het instellen van partitiebeleid, het beheren van het lidmaatschap van het HSM-cluster, het uitvoeren van firmware-updates en het afhandelen van sleutelceremonies. In een on-premises omgeving is dit doorgaans een toegewijd lid van het HSM-operationsteam dat gebruikmaakt van de hardware-authenticatie van de HSM (PED of smartcard). Bij cloud-HSM-services authenticeert de beheerder zich bij de HSM-management-API met hardwaretokens of sterke referenties. De beheerdersrol mag nooit worden gebruikt door applicaties of geautomatiseerde pipelines.

De sleutelbeheerderrol (crypto-officier): Deze rol creëert, importeert, exporteert (indien toegestaan), roteert en verwijdert sleutelobjecten binnen een toegewezen partitie. Deze rol is verantwoordelijk voor de levenscyclus van de sleutel binnen de HSM. In een cloud-HSM-context komt dit overeen met de rol die het sleutelbeleid beheert in AWS KMS, Azure Key Vault of GCP Cloud KMS. Voor belangrijke sleutelbewerkingen (zoals het genereren van CA-hoofdsleutels en het verwijderen van hoofdsleutels) is dubbele controle vereist en moeten acties van de sleutelbeheerder worden vastgelegd.

De applicatierol (crypto-gebruiker): gebruikt sleutels binnen de HSM om cryptografische bewerkingen uit te voeren (versleutelen, ontsleutelen, ondertekenen, verifiëren), maar kan geen sleutels aanmaken, verwijderen of exporteren. In cloud-KMS-services komt dit overeen met het toekennen van alleen de specifieke cryptografische bewerkingsrechten aan het serviceaccount of de IAM-rol van de applicatie (kms:Decrypt voor applicaties die alleen ontsleutelen; kms:Sign voor applicaties die alleen ondertekenen), zonder rechten voor sleutelbeheer. Applicatierollen moeten beperkt zijn tot specifieke sleutels en mogen geen brede toegang krijgen tot alle sleutels in een partitie of sleutelarchief.

Sleutelrotatie met HSM's

Sleutelrotatie in een HSM-context betekent het genereren van nieuw sleutelmateriaal binnen de HSM om bestaande sleutels volgens een vast schema te vervangen. Hoe rotatie werkt, hangt af van of de HSM een hoofdsleutel (die andere sleutels omvat) of een dataversleutelingssleutel (die gegevens direct versleutelt) beschermt.

Hoofdsleutelrotatie in cloud-KMS met HSM-ondersteuning: Wanneer u automatische rotatie inschakelt voor een door de klant beheerde sleutel in AWS KMS of Azure Key Vault, genereert de service nieuw HSM-ondersteund sleutelmateriaal volgens het geconfigureerde schema (doorgaans jaarlijks). Bestaande gegevens die zijn versleuteld met de vorige sleutelversie blijven onversleutelbaar; de KMS bewaart eerdere sleutelversies. Nieuwe versleutelingsbewerkingen gebruiken het nieuwe sleutelmateriaal. De sleutel-ID en ARN blijven hetzelfde; de ​​rotatie is transparant voor applicaties.

Sleutelrotatie voor on-premises HSM's en BYOK: Voor sleutelrotatie van on-premises HSM's is het nodig om nieuw sleutelmateriaal binnen de HSM te genereren, dit te distribueren naar alle systemen of applicaties die de sleutel gebruiken, alle dataversleutelingssleutels die door de oude hoofdsleutel worden beschermd opnieuw te versleutelen en het oude sleutelmateriaal te archiveren volgens uw bewaarbeleid. Voor BYOK-sleutels met geïmporteerd materiaal in een cloud-KMS is automatische rotatie niet beschikbaar; u moet nieuw materiaal in uw HSM genereren, exporteren en opnieuw importeren in de cloud-KMS, dit aanwijzen als de primaire versie en de overgangstijdlijn beheren voor alle afhankelijke workloads.

Rotatie van CA-privésleutels voor PKI: HSM's die CA-privésleutels beschermen, vereisen een speciale aanpak voor rotatie, omdat het roteren van een CA-privésleutel het uitgeven van een nieuw CA-certificaat en het distribueren van het nieuwe vertrouwensanker naar alle vertrouwende partijen vereist. CA-sleutelrotatie is een geplande PKI-gebeurtenis, geen routinematige geautomatiseerde bewerking, en vereist coördinatie met alle systemen die de CA vertrouwen. De sleutelceremonieprocedures van de HSM (dubbele controle, M-van-N-quorumauthenticatie) zijn van toepassing op de CA-sleutelgeneratie.

Auditregistratie voor HSM-bewerkingen

HSM-auditlogboeken zijn een compliancevereiste onder PCI DSS, FedRAMP, HIPAA en de meeste andere frameworks die cryptografische controles specificeren. Het logboek moet elke administratieve bewerking (partitieaanmaak, sleutelaanmaak, sleutelverwijdering, beleidswijzigingen) en elke cryptografische bewerking (ondertekenen, verifiëren, versleutelen, ontsleutelen, verpakken, uitpakken) vastleggen die door of via de HSM wordt uitgevoerd en gekoppeld is aan een geauthenticeerde identiteit.

Auditlogboekregistratie van HSM's op locatie: Fysieke HSM's genereren intern auditlogboeken en kunnen deze doorsturen naar een SIEM- of syslog-server. Het auditlogboek van de HSM wordt door de HSM zelf ondertekend om manipulatie te detecteren. Het is een operationele vereiste die HSM-teams op locatie expliciet moeten beheren om ervoor te zorgen dat auditlogboeken extern worden doorgestuurd naar een fraudebestendige logopslag voordat het interne logboek van de HSM vol raakt.

Auditlogboekregistratie voor cloud-HSM: Cloud-HSM- en cloud-KMS-services integreren met de eigen auditlogboekregistratie van de cloudprovider. In AWS wordt elke KMS API-aanroep in CloudTrail vastgelegd, inclusief de aanvragende identiteit, de sleutel-ARN, het bewerkingstype en het tijdstempel. In Azure worden Key Vault- en Dedicated HSM-bewerkingen vastgelegd in Azure Monitor. In GCP worden Cloud KMS- en Cloud-HSM-bewerkingen in cloudauditlogboeken weergegeven. Cloudauditlogboeken zijn automatisch fraudebestendig (de provider waarborgt de integriteit van de logboeken) en kunnen eenvoudig via native integraties naar SIEM-platformen worden doorgestuurd.

Er wordt een waarschuwing gegenereerd voor de volgende HSM-auditgebeurtenissen, ongeacht het implementatiemodel: elke verwijdering van een sleutel of het plannen van een verwijdering; elke beleidswijziging op een waardevolle sleutel of partitie; elke cryptografische bewerking door een identiteit die niet in de lijst met goedgekeurde applicatierollen staat; elke mislukte authenticatiepoging tegen de HSM; en elke poging om sleutelmateriaal te exporteren vanuit een partitie die is geconfigureerd als niet-exporteerbaar.

Multi-cloud HSM-architectuur

Organisaties die gebruikmaken van meerdere cloudproviders staan ​​voor een specifieke HSM-uitdaging: de dedicated HSM-service van elke cloudprovider is beperkt tot de infrastructuur van die provider, en de HSM-services van cloudproviders zijn niet gefedereerd tussen providers. Een AWS CloudHSM-instantie kan geen GCP-workloads rechtstreeks bedienen, en een Azure Dedicated HSM kan zonder extra tools geen sleutels genereren voor AWS KMS-import. Er zijn drie patronen voor het aanpakken van multi-cloud HSM-architectuur:

• De on-premises HSM fungeert als centrale sleutelautoriteit: Een on-premises HSM-cluster fungeert als de centrale autoriteit voor het genereren en opslaan van sleutels voor alle omgevingen. Sleutels die in de on-premises HSM worden gegenereerd, worden geëxporteerd (verpakt) en geïmporteerd in het KMS van elke cloudprovider als BYOK-sleutels. De on-premises HSM is de gezaghebbende bron voor al het sleutelmateriaal; de KMS-services van de cloudproviders gebruiken dit materiaal. Dit model biedt de sterkste gecentraliseerde controle, maar vereist wel dat de on-premises HSM een hoge beschikbaarheid heeft en toegankelijk is voor alle cloudomgevingen.
• HSM als een service van derden, verspreid over verschillende cloudproviders: Een externe HSM-service die onafhankelijk is van de drie grote cloudproviders, biedt een gecentraliseerde HSM-infrastructuur die toegankelijk is voor workloads in alle cloudomgevingen. De HSM-service genereert sleutels en maakt deze via een uniforme API beschikbaar voor applicaties in elke cloud. Dit elimineert het probleem van de HSM-silo per provider, zonder dat er on-premises hardware nodig is, en fungeert als de bron voor sleutelgeneratie voor BYOK (Bring Your Own Key) bij alle cloudproviders. Encryption Consulting's HSM als een service Dit model biedt een FIPS 140-2 Level 3 HSM-infrastructuur die toegankelijk is in cloudomgevingen.
• Per cloud dedicated HSM met gecentraliseerd sleutelbeheer: Implementeer een speciale cloud-HSM-service bij elke cloudprovider (AWS CloudHSM in AWS, Azure Dedicated HSM in Azure) en beheer deze als afzonderlijke sleutelautoriteiten voor workloads in elke cloud. Gebruik een gecentraliseerd platform voor sleutelbeheer om inzicht te behouden in alle sleutels in alle HSM-instanties, consistent sleutelbeleid af te dwingen en auditlogboeken te verzamelen. Dit model is operationeel het meest complex, maar voorkomt afhankelijkheden van netwerken tussen clouds voor cryptografische bewerkingen.

Compliance-overwegingen bij de implementatie van HSM

Verschillende compliance-frameworks specificeren verschillende HSM-vereisten. Door uw HSM-implementatie af te stemmen op de specifieke vereisten, voorkomt u zowel onderconformiteit (het gebruik van niveau 2 waar niveau 3 vereist is) als overinvestering (het implementeren van on-premises HSM's terwijl een beheerde cloud-HSM-service aan de vereisten voldoet).

PCI DSS v4.0.1 (verplicht sinds 31 maart 2025): Vereist dat cryptografische sleutels die worden gebruikt om kaartgegevens te beschermen, op zo min mogelijk locaties worden opgeslagen. Sleutelbeheerprocessen moeten bescherming van sleutels tegen openbaarmaking en misbruik omvatten (vereiste 3.7.1). HSM's worden expliciet genoemd als een acceptabele technologie voor sleutelbeheer. PCI DSS vereist geen specifiek FIPS-niveau voor de HSM, maar vereist wel dat het sleutelbeheersysteem veilig en gecontroleerd is. Cloud-HSM-diensten die voor PCI-doeleinden worden gebruikt, moeten zich binnen de PCI DSS-gecertificeerde infrastructuur van de provider bevinden.

FedRAMP (NIST SP 800-53 Rev. 5): De SC-12-controle (Cryptographic Key Establishment and Management) vereist dat sleutels worden geproduceerd, beheerd en gedistribueerd met behulp van door de NSA goedgekeurde of door NIST aanbevolen sleutelbeheertechnologie. FedRAMP High vereist bovendien FIPS 140-2 of FIPS 140-3 Level 3 gevalideerde cryptografische modules. AWS CloudHSM, Azure Dedicated HSM en GCP Cloud HSM met HSM-beveiligingsniveau voldoen allemaal aan deze vereiste. Standaard gedeelde cloud-KMS-services op FIPS 140-2 Level 2 voldoen niet aan de Level 3-vereiste van FedRAMP High.

eIDAS en gekwalificeerde handtekeningen (EU): Gekwalificeerde elektronische handtekeningen onder eIDAS vereisen gekwalificeerde apparaten voor het aanmaken van handtekeningen (QSCD's), die moeten voldoen aan eisen die ten minste gelijkwaardig zijn aan FIPS 140-2 niveau 3 of Common Criteria EAL4+. Voor EU-organisaties die gekwalificeerde certificaten of gekwalificeerde handtekeningen uitgeven, zijn on-premises HSM's of in de EU gevestigde, speciaal daarvoor bestemde cloud-HSM's met de juiste validaties vereist.

HIPAA: De wet schrijft geen specifieke HSM-vereisten voor, maar vereist wel passende beveiligingsmaatregelen voor encryptiesleutels die ePHI beschermen. Een cloud-HSM-service met gedocumenteerde toegangscontroles, auditregistratie en een ondertekende Business Associate Agreement (BAA) met de provider voldoet aan de technische beveiligingsvereisten van HIPAA voor sleutelbescherming.

Besluitvormingsgids voor de implementatie van HSM

Gebruik de volgende criteria om het juiste HSM-implementatiemodel voor de behoeften van uw organisatie te bepalen.

1. Bepaal uw latentievereiste: Als uw applicatie HSM-responstijden van minder dan een milliseconde vereist, is een on-premises HSM de enige optie. Als u een responstijd van 1 tot 10 milliseconden kunt accepteren, zijn cloud-HSM-diensten een goede keuze.
2. Bepaal uw FIPS-niveauvereiste: Als FIPS 140-2 niveau 3 vereist is (FedRAMP High, bepaalde PCI-vereisten, eIDAS-kwalificatie), controleer dan of de specifieke cloudservice die u evalueert voldoet aan niveau 3, en niet alleen aan niveau 2. Gedeelde cloud-KMS-services variëren per provider en niveau.
3. Identificeer uw belangrijkste besturingsmodel: Als het sleutelbeheer van de eigen provider acceptabel is, gebruik dan het gedeelde KMS van de cloudprovider met HSM-beveiliging. Als BYOK vereist is, hebt u een on-premises HSM of een dedicated cloud-HSM nodig om sleutelmateriaal te genereren. Als HYOK vereist is, hebt u een HSM nodig die volledig buiten de cloudprovider opereert waar uw gegevens worden opgeslagen.
4. Bepaal uw vereisten op het gebied van gegevenssoevereiniteit: Als de regelgeving voorschrijft dat sleutels een specifiek land of een specifieke locatie nooit mogen verlaten, en er op die locatie geen cloud-HSM-service actief is, is een on-premises HSM vereist. Als er wel een cloud-HSM-service actief is in het betreffende rechtsgebied, controleer dan de contractuele garanties met betrekking tot de gegevensresidentie.
5. Bepaal uw multi-cloudstrategie: Als u met meerdere cloudproviders werkt en gecentraliseerd sleutelbeheer nodig hebt, overweeg dan een HSM-as-a-Service van een derde partij of een on-premises HSM-cluster als centrale sleutelautoriteit.
6. Bereken de totale eigendomskosten: Vergelijk de initiële hardware- en operationele kosten voor een on-premises oplossing met de uurprijs van een cloud-HSM bij uw verwachte transactievolume. Bij lage tot gemiddelde volumes heeft een cloud-HSM lagere totale eigendomskosten (TCO). Bij zeer hoge cryptografische transactiesnelheden (miljoenen bewerkingen per uur) kan dedicated on-premises hardware kosteneffectiever zijn.
7. Beoordeel de operationele capaciteit: Een on-premises HSM-systeem vereist personeel met specifieke HSM-expertise voor de bediening en het onderhoud. Cloud-HSM-diensten verminderen deze behoefte, maar elimineren deze niet volledig. Als uw organisatie geen specifieke expertise heeft op het gebied van HSM-beheer, kan een beheerde cloud-HSM-dienst of een HSM-as-a-Service van een gespecialiseerde aanbieder het operationele risico aanzienlijk verlagen.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is een bedrijf gespecialiseerd in toegepaste cryptografie met ISO/IEC 27001:2022- en SOC 2-certificeringen. Wij helpen organisaties bij het selecteren, implementeren en beheren van HSM-infrastructuur voor zowel cloud- als on-premises omgevingen, van de initiële behoefteanalyse tot het continu genereren van bewijsmateriaal voor naleving.

• HSM als een service: Encryptie Consulting's HSM als een service Biedt een dedicated FIPS 140-2 Level 3 HSM-infrastructuur als beheerde service, toegankelijk voor workloads bij verschillende cloudproviders en in on-premises omgevingen. Geschikt als BYOK- en HYOK-sleutelgeneratiebron, als gecentraliseerde sleutelautoriteit voor meerdere clouds en als beheerd alternatief voor het implementeren en beheren van on-premises HSM-hardware. Ondersteund door ISO/IEC 27001:2022-gecertificeerde activiteiten.
• PKI als een service: Voor organisaties die HSM's gebruiken om de privésleutels van CA's te beschermen, biedt Encryption Consulting de volgende oplossingen. PKI als een service Biedt een volledig beheerde private CA met HSM-ondersteunde CA-sleutelopslag, ACME-geautomatiseerde certificaatuitgifte en integratie met alle belangrijke cloudplatformen. Elimineert de noodzaak om on-premises HSM's te gebruiken uitsluitend voor de bescherming van PKI CA-sleutels.
• Advies- en implementatiediensten voor HSM: Als u on-premises HSM's implementeert of cloud-HSM-diensten evalueert, kan Encryption Consulting u daarbij helpen. HSM-diensten Het programma omvat de selectie en dimensionering van HSM's, het ontwerp van high-availability clusters, PKCS#11- en REST API-integratie met applicaties, sleutelceremonieprocedures voor het genereren van CA-rootsleutels, FIPS-compliance documentatie en doorlopende operationele ondersteuning.
• CBOM Secure: Encryptie Consulting's CBOM Secure Ontdekt en inventariseert alle cryptografische activa in uw cloud- en on-premises omgevingen, inclusief HSM-beveiligde sleutels, cloud-KMS-sleutels en certificaten. Biedt een cryptografische materiaallijst (CBOM) in CycloneDX-formaat die sleutels zonder HSM-beveiliging, sleutels waarvan de rotatietermijn nadert en sleutels die gebruikmaken van verouderde algoritmen identificeert.
• PQC-gereedheid: NIST heeft in augustus 2024 de post-kwantumcryptografiestandaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) afgerond. NIST IR 8547 wijst erop dat RSA en ECC rond 2030 zullen worden uitgefaseerd voor nieuwe toepassingen. HSM's moeten post-kwantumalgoritmen ondersteunen vóór die overgang, en niet alle huidige HSM-hardware zal alleen via firmware te upgraden zijn. Encryption Consulting's PQC-gereedheid Deze service beoordeelt het migratietraject van uw HSM-omgeving na de quantumovergang en ontwerpt de upgrade- of vervangingsvolgorde van de HSM's.

Neem contact op met Encryption Consulting om uw HSM-implementatievereisten te bespreken.

Conclusie

Cloudgebaseerde en on-premises HSM's maken gebruik van dezelfde gevalideerde cryptografische hardwaretechnologie. Het implementatiemodel bepaalt wie de hardware beheert, welke latentie en kostenstructuur van toepassing zijn en hoe de HSM past in uw sleutelbeheermodel (native, BYOK of HYOK). Voor de meeste organisaties bieden cloud-HSM-services, met name dedicated single-tenant services, een vergelijkbare beveiliging als on-premises HSM's, maar met aanzienlijk lagere operationele overhead en totale eigendomskosten. On-premises HSM's blijven de juiste keuze voor latentievereisten van minder dan een milliseconde, air-gapped omgevingen en rechtsgebieden waar geen cloud-HSM-service voldoet aan de vereisten voor datalokalisatie.

De keuze is niet puur binair. Veel organisaties combineren modellen: een on-premises of door een derde partij geleverde HSM als BYOK-sleutelgeneratieautoriteit, cloud KMS-services als operationele sleutelbeheerlaag voor cloudworkloads en cloud-HSM-services voor specifieke, hoogbeveiligde workloads die FIPS 140-2 niveau 3 vereisen binnen de cloudomgeving. Het correct ontwerpen van die architectuur en het onderhouden van het IAM-model, het rotatieschema en de auditregistratie over alle lagen heen, dát is waar de werkelijke operationele complexiteit schuilt.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen cloudgebaseerde HSM's en on-premises HSM's?

Cloudgebaseerde HSM's zijn FIPS-gecertificeerde hardwarebeveiligingsmodules die worden beheerd door een cloudprovider of een externe dienstverlener in een extern datacenter en die toegankelijk zijn via een netwerk-API. On-premises HSM's zijn fysieke apparaten die in uw eigen faciliteit zijn geïnstalleerd. Beide maken gebruik van dezelfde onderliggende cryptografische hardware en kunnen FIPS 140-2 Level 3-validatie behalen. Het belangrijkste verschil zit hem in wie de hardware beheert, wie fysieke toegang heeft, wat het latentieprofiel is en of de kosten investeringskosten of operationele kosten zijn.

Wat is veiliger: cloudgebaseerde HSM's of on-premises HSM's?

Beide kunnen voldoen aan de FIPS 140-2 Level 3-validatie. De beveiliging hangt meer af van de implementatieconfiguratie en het sleutelbeheer dan van het implementatiemodel. Een on-premises oplossing biedt uw organisatie de fysieke bewaring van de sleutels. Goed geconfigureerde, dedicated cloud HSM-services bieden vergelijkbare of betere beveiliging dan slecht onderhouden on-premises clusters. Het risicoprofiel van een dedicated single-tenant cloud HSM van een grote aanbieder is voor de meeste dreigingsmodellen vergelijkbaar met dat van een on-premises HSM.

Wat is BYOK en hoe verhoudt het zich tot de keuze voor een middelbareschooldiploma?

BYOK (Bring Your Own Key) betekent dat u zelf encryptiesleutels genereert in uw eigen HSM en deze importeert in het KMS van een cloudprovider. Een on-premises HSM of een dedicated cloud-HSM fungeert als bron voor de BYOK-sleutelgeneratie. De cloudprovider gebruikt uw geïmporteerde materiaal voor encryptiebewerkingen, maar u behoudt de bron. HYOK gaat nog een stap verder: de sleutel komt nooit in de infrastructuur van de cloudprovider terecht, waardoor client-side encryptie vereist is met een sleutel die volledig in uw eigen HSM wordt beheerd.

Wat zijn de kosten van een cloudgebaseerd HSM-systeem in vergelijking met een on-premises HSM-systeem?

AWS CloudHSM rekent ongeveer $ 1.45 per uur per instantie, circa $ 1,040 per maand voor één instantie of $ 2,100 per maand voor een HA-cluster met twee instanties. On-premises HSM's vereisen een eenmalige investering van $ 20,000 tot $ 40,000 of meer per apparaat, plus licenties voor beheersoftware, datacenterkosten en personeelskosten. Cloud HSM heeft lagere totale eigendomskosten (TCO) bij lage tot gemiddelde volumes. On-premises kan kosteneffectiever worden bij zeer hoge cryptografische transactiesnelheden, waarbij de kosten voor API-aanroepen aanzienlijk oplopen.

Ondersteunen cloud-HSM's FIPS 140-2 niveau 3?

Speciale cloud-HSM-services bieden de volgende beschermingsniveaus: AWS CloudHSM gebruikt Luna Network HSM-hardware met FIPS 140-2 niveau 3, Azure Dedicated HSM gebruikt Entrust nShield Connect met niveau 3 en GCP Cloud HSM biedt niveau 3-bescherming voor HSM-ondersteunde sleutels. Gedeelde cloud-KMS-services zonder een speciale HSM-laag gebruiken niveau 2, niet niveau 3. Controleer altijd het exacte serviceniveau en beschermingsniveau wanneer niveau 3 een specifieke compliance-vereiste is.

Wanneer moet een organisatie kiezen voor on-premises HSM's in plaats van cloud-HSM's?

Kies voor een on-premise oplossing wanneer: de applicatie cryptografische responstijden van minder dan een milliseconde vereist die een cloud-API niet kan leveren; wettelijke voorschriften vereisen dat sleutels op een specifieke fysieke locatie of in een specifiek rechtsgebied blijven waar geen cloud-HSM-service beschikbaar is; de omgeving volledig geïsoleerd is zonder internetverbinding; of het volume aan cryptografische transacties zo hoog is dat de kosten van cloud-API-aanroepen de kosten van eigen hardware overstijgen. Voor de meeste andere toepassingen bieden cloud-HSM-services een gelijkwaardige beveiliging met lagere operationele kosten.