HSM-clustering en hoge beschikbaarheid op de juiste manier geïmplementeerd.

Een HSM bewaart de sleutels waar alles van afhangt. De TLS-privésleutels, de ondertekeningssleutels, de hoofdsleutels die alle andere geheimen in uw omgeving beschermen. Dit roept een ongemakkelijke vraag op die in veel architectuurbeoordelingen wordt genegeerd: wat gebeurt er als een van deze sleutels uitvalt? Als het eerlijke antwoord is "we weten het niet helemaal zeker", dan hebt u een single point of failure onder uw belangrijkste cryptografische bewerkingen, en zult u de ernst ervan ontdekken op het slechtst mogelijke moment.

Hoge beschikbaarheid voor HSM's is de manier om dat risico te elimineren, en moderne cloud-HSM-platformen hebben de basisconfiguratie relatief eenvoudig gemaakt. Implementeer meerdere HSM's in een cluster en workloads worden automatisch over de HSM's verdeeld. Verdeel die HSM's over verschillende beschikbaarheidszones en u krijgt veerkracht tegen storingen op zoneniveau. Dat deel is eenvoudig.

Het probleem begint wanneer teams ervan uitgaan dat het inschakelen van een multi-AZ-configuratie voldoende is. Beschikbaarheid en de duurzaamheid van de sleutels zijn niet hetzelfde, en het begrijpen van dat onderscheid is cruciaal. In dit artikel wordt onderzocht hoe HSM-clustering werkt, hoe je veerkrachtige architecturen ontwerpt over zones en regio's heen, en waarom het failover-scenario dat je nooit hebt getest vaak de oorzaak is van de grootste uitval.

Wat een cluster je daadwerkelijk oplevert

Begin bij de mechanica, want de waarde van een cluster komt voort uit twee verschillende eigenschappen die mensen vaak door elkaar halen.

Het eerste aspect is load balancing. Wanneer een cluster meerdere HSM's heeft, verdeelt de client cryptografische bewerkingen over deze HSM's op basis van de beschikbare capaciteit van elke HSM. Dit betreft doorvoer, niet alleen veerkracht. Een enkele HSM kan een beperkt aantal bewerkingen per seconde uitvoeren, en voor een drukke workload met ondertekening of TLS -terminatie is die limiet reëel. Het toevoegen van HSM's aan het cluster verhoogt deze limiet.

Het tweede voordeel is hoge beschikbaarheid. Wanneer de HSM's zich in verschillende beschikbaarheidszones bevinden, is geen enkele HSM, en geen enkele zone, een punt van falen. Als er één uitvalt, blijven de andere functioneren en stopt de client simpelweg met het verzenden van werk naar de uitgevallen HSM. De gangbare aanbeveling is minimaal twee HSM's in twee verschillende zones binnen een regio, en voor alles wat u zich echt niet kunt veroorloven te verliezen, is twee het minimum, niet het streefgetal.

Onder beide eigenschappen schuilt hetgeen wat een cluster tot een cluster maakt: synchronisatie. Wanneer u een sleutel genereert of importeert, repliceert het cluster dat sleutelmateriaal naar elke HSM in het cluster, zodat dezelfde sleutel identiek op elk lid aanwezig is. Die replicatie zorgt ervoor dat elke HSM in het cluster elk verzoek kan verwerken en vormt tevens de stille basis voor duurzaamheid. Een sleutel die slechts op één apparaat aanwezig is, kan door één hardwarefout onbruikbaar worden.

Beschikbaarheid is niet hetzelfde als duurzaamheid, en het onderscheid daartussen is allesbepalend.

Hier schuilt de valkuil. Het is gemakkelijk om aan te nemen dat een cluster met hoge beschikbaarheid automatisch betekent dat uw sleutels veilig zijn. Beschikbaarheid en duurzaamheid beantwoorden echter twee verschillende vragen.

Beschikbaarheid vraagt ​​of u op dit moment een cryptografische bewerking kunt uitvoeren. Een multi-AZ-cluster beantwoordt die vraag goed: als één HSM of zone uitvalt, neemt een andere de aanvraag over en blijft uw applicatie gewoon draaien.

Duurzaamheid roept een belangrijkere vraag op: kan uw belangrijkste materiaal ooit permanent verloren gaan? Dit is de vraag die een architect slapeloze nachten zou moeten bezorgen, want het verliezen van een HSM-sleutel is niet hetzelfde als het verliezen van een server. Als de sleutel die al uw andere geheimen beschermt, verdwenen is en er geen herstelbare kopie bestaat, kunnen de gegevens die door die geheimen werden beschermd, ook onherstelbaar beschadigd raken.

Er bestaat geen supportticket waarmee het apparaat teruggehaald kan worden. Replicatie over een cluster beschermt tegen het verlies van een individueel apparaat, maar replicatie alleen is geen back-upstrategie, omdat sommige storingen zich verspreiden. Een foutieve beheerhandeling, een beschadigde sleutelimport of een verkeerde configuratie kan alle gesynchroniseerde leden tegelijk treffen. Duurzaamheid vereist doelbewuste, afzonderlijke back-ups van sleutelmateriaal, die onafhankelijk van het actieve cluster worden bewaard, zodat één enkele catastrofale gebeurtenis niet zowel de sleutels als hun enige kopieën kan vernietigen.

Bij het ontwerpen voor de veerkracht van HSM's moeten beide aspecten tegelijkertijd in overweging worden genomen. Een cluster dat perfect beschikbaar is, maar geen onafhankelijke, geteste back-up heeft, is een cluster dat slechts één slechte dag verwijderd is van een ramp waarvan het niet meer kan herstellen.

Ontwerpen over zones en regio's heen.

Als die eigenschappen eenmaal bekend zijn, vallen de ontwerpkeuzes vanzelf op hun plaats.

Binnen een regio moet u uw HSM's over ten minste twee beschikbaarheidszones verdelen en de capaciteit uitbreiden tot boven het minimum als uw doorvoer of risicotolerantie dit vereist. Plaats de HSM's, in netwerktermen, dicht bij de applicaties die ze gebruiken, omdat elke cryptografische aanroep een retourtje vereist en de latentie onder belasting toeneemt. Zorg ervoor dat het cluster voldoende reserve heeft, zodat het uitvallen van één lid de overgebleven HSM's niet overbelast. Een failover die de resterende HSM's direct overbelast, heeft immers één probleem in tweeën gesplitst.

De berekening verschilt per regio. Een cluster met meerdere beschikbaarheidszones (AZ's) beschermt je tegen het uitvallen van een zone, maar niet tegen het verlies van een hele regio, en ook niet tegen een regionale serviceonderbreking. Voor workloads waar dat wel van belang is, of het nu gaat om noodherstel of om wettelijke vereisten met betrekking tot geografische scheiding, heb je een strategie nodig die meerdere regio's omvat.

Dat betekent doorgaans dat de mogelijkheid behouden moet blijven om een ​​HSM-cluster in een tweede regio op te zetten of te herstellen vanuit back-ups, en dat die back-ups actueel moeten blijven. Het beheer van sleutels tussen regio's brengt eigen beperkingen met zich mee met betrekking tot de locatie van gegevens en hoe sleutelmateriaal mag worden verplaatst. Het ontwerp moet daarom rekening houden met zowel de technische als de compliance-eisen.

De rode draad is capaciteitsplanning in combinatie met faalplanning. Weet hoeveel belasting elke HSM aankan, weet hoeveel verlies je lijdt als een component of een zone uitvalt, en zorg ervoor dat de resterende systemen dit verlies kunnen opvangen.

De failover die je nooit hebt getest, telt niet mee.

Dit is het punt dat een robuust ontwerp op papier onderscheidt van een ontwerp dat in de praktijk standhoudt. Een architectuur met hoge beschikbaarheid doet een belofte: als er iets uitvalt, blijft het systeem werken. De enige manier om te weten of die belofte wordt waargemaakt, is door opzettelijk iets kapot te maken en te observeren.

Het testen van failover wordt vaak uitgesteld omdat het riskant aanvoelt, maar die gedachte is volkomen onjuist. Het risico zit hem niet in het testen van failover tijdens een gecontroleerde periode waarin uw team meekijkt en paraat staat. Het risico zit hem in de ontdekking, tijdens een daadwerkelijke storing, dat de failover waarvan u aannam dat die zou werken, dat niet doet vanwege een verkeerde configuratie aan de clientzijde, een capaciteitstekort, een synchronisatieprobleem of een aanname die vanaf het begin onjuist was. Een failoverpad dat nooit is getest, is een hypothese, geen beveiliging.

Een goede test houdt in dat een HSM doelbewust uit het cluster wordt verwijderd en dat wordt gecontroleerd of de werking foutloos doorgaat. Het betekent dat het verlies van een volledige beschikbaarheidszone wordt gesimuleerd en dat de overgebleven zone de volledige belasting overneemt. Het betekent dat de herstelprocedure wordt geoefend: een vervangende HSM in het cluster plaatsen, controleren of de belangrijkste gegevens correct synchroniseren en verifiëren of het cluster weer volledig operationeel is.

En dat betekent dat je periodiek moet controleren of je back-ups daadwerkelijk hersteld kunnen worden, want een niet-geteste back-up is niets meer dan een bestand waarvan je hoopt dat het goed is. De meest betrouwbare organisaties beschouwen dit als routineoefeningen, geplande testdagen in plaats van eenmalige controles, omdat omgevingen veranderen en een failover die vorig jaar nog werkte, sindsdien stilletjes kan zijn gestopt met werken.

Test de mogelijke storingen waar je bang voor bent, op je eigen tempo, voordat ze zich daadwerkelijk voordoen.

Hoe Encryption Consulting u kan helpen

Het ontwerpen van een HSM-systeem met hoge beschikbaarheid dat de duurzaamheid van sleutels waarborgt, en bewijzen dat het daadwerkelijk werkt, vereist zowel het juiste platform als waardevolle operationele ervaring. Dat is waar wij in beeld komen.

HSM-as-a-Service biedt u hardwarematige sleutelbescherming als een beheerde, veerkrachtige service. Zo profiteert u van de hoge beschikbaarheid en sleutelisolatie die een HSM biedt, zonder dat u zelf de hardware hoeft aan te schaffen, te installeren, te clusteren en te onderhouden. Wij zorgen voor de onderliggende redundantie en het operationele beheer. Dit betekent dat de beschikbaarheids- en duurzaamheidseigenschappen die in dit blog worden beschreven, in de service zijn ingebouwd en niet door uw team hoeven te worden geconfigureerd en beheerd.

Voor organisaties die hun eigen HSM's beheren, of die overwegen een implementatie over zones en regio's heen te ontwerpen, bieden onze Hardware Security Module-services praktische advies- en implementatieondersteuning voor de belangrijkste platformen. We helpen u bij het ontwerpen van de clustertopologie, het plannen van capaciteit en failover, het opzetten van back-up- en disaster recovery-procedures die beschermen tegen permanent sleutelverlies, en het implementeren van gerichte failover-tests zodat uw veerkracht wordt geverifieerd in plaats van aangenomen. Als u een clusterontwerp of een strategie voor sleutelduurzaamheid nodig heeft, dan is dit het team dat het voor u bouwt.

Als u een HSM-systeem ontwerpt dat bestand is tegen storingen, of als u simpelweg een tweede paar deskundige ogen wilt laten kijken naar een implementatie waar uw bedrijf van afhankelijk is, neem dan contact met ons op . We kunnen u helpen een systeem te bouwen dat ervoor zorgt dat geen enkele storing uw sleutels ooit in gevaar brengt.

Conclusie

HSM-high availability is een van die gebieden waar de makkelijke oplossing er al lang klaar uitziet, voordat het echte werk is gedaan. Het opzetten van een multi-AZ-cluster met load balancing is echt waardevol, maar het is ook slechts het begin. De vragen die bepalen of je ontwerp standhoudt, zijn minder voor de hand liggend: heb je beschikbaarheid en duurzaamheid gescheiden, bestaan ​​er onafhankelijke en geteste back-ups, kunnen de overgebleven zones de belasting dragen wanneer een zone uitvalt, en heb je ooit daadwerkelijk een failover meegemaakt?

Sleutels zijn niet te vergelijken met andere infrastructuur. Een verloren server is vervelend, maar een permanent verloren hoofdsleutel kan betekenen dat u uw gegevens nooit meer terugkrijgt. Die asymmetrie verklaart waarom de veerkracht van HSM's meer aandacht verdient dan bij gewone planning voor hoge beschikbaarheid, en waarom de kwestie van duurzaamheid net zo belangrijk is als die van uptime.

Bouw het cluster, verdeel het over zones, plan voor de regio waarvan je hoopt dat die nooit uitvalt, en laat het vervolgens opzettelijk crashen om te controleren of het herstelproces succesvol verloopt. Organisaties die hun failover bewust testen, hoeven nooit midden in een echte storing te ontdekken wat ze hadden moeten controleren.