Belangrijkste soevereiniteit, beschikbaarheid, prestaties en schaalbaarheid in beheerde HSM
Cryptografische sleutels vormen de basis van vertrouwen voor het beveiligen van moderne computersystemen, on-premises of in de cloud. Het is dus essentieel om te bepalen wie over deze sleutels beschikt om veilige en compatibele toepassingen te bouwen.
In Azure is onze visie op hoe sleutelbeheer moet worden uitgevoerd in de cloud een belangrijke soevereiniteit is. Sleutelsoevereine betekent dat de organisatie van een klant volledige en exclusieve controle heeft over wie toegang heeft tot sleutels en beleid voor sleutelbeheer kan wijzigen en over welke Azure-services deze sleutels gebruiken. Nadat deze beslissingen door de klant zijn genomen, worden microsoft-medewerkers door technische middelen verhinderd om deze beslissingen te wijzigen. De code van de sleutelbeheerservice voert de beslissingen van de klant uit totdat de klant dit anders moet doen en microsoft-personeel kan niet tussenbeide komen.
Tegelijkertijd is het onze overtuiging dat elke service in de cloud volledig moet worden beheerd. De service moet de vereiste beschikbaarheid, tolerantie, beveiliging en fundamentele cloudbeloften bieden, ondersteund door serviceovereenkomsten (SLA's). Voor het leveren van een beheerde service moet Microsoft patchsleutelbeheerservers uitvoeren, hardwarebeveiligingsmodulefirmware (HSM) upgraden, mislukte hardware herstellen, failovers uitvoeren en andere bewerkingen met hoge bevoegdheden uitvoeren. Zoals de meeste beveiligingsprofessionals weten, is het moeilijk om iemand met hoge bevoegdheden of fysieke toegang tot een systeemtoegang tot de gegevens in dat systeem te weigeren.
In dit artikel wordt uitgelegd hoe we dit probleem hebben opgelost in de beheerde HSM-service van Azure Key Vault, waardoor klanten zowel volledige sleutelsoevereiniteit als volledig beheerde service-SLA's bieden met behulp van confidential computing-technologie die is gekoppeld aan HSM's.
Beheerde HSM-hardwareomgeving
De beheerde HSM-pool van een klant in elke Azure-regio bevindt zich in een beveiligd Azure-datacenter. Drie exemplaren zijn verspreid over verschillende servers. Elk exemplaar wordt geïmplementeerd in een ander rek om redundantie te garanderen. Elke server heeft een FIPS 140-2 Level 3 gevalideerde Marvell LiquidSecurity HSM Adapter met meerdere cryptografische kernen. De kernen worden gebruikt om volledig geïsoleerde HSM-partities te maken, waaronder volledig geïsoleerde referenties, gegevensopslag en toegangsbeheer.
De fysieke scheiding van de exemplaren in het datacenter is essentieel om ervoor te zorgen dat het verlies van één onderdeel (bijvoorbeeld de top-of-rack-switch of een energiebeheereenheid in een rek) niet van invloed kan zijn op alle exemplaren van een pool. Deze servers zijn toegewezen aan het Azure Security HSM-team. De servers worden niet gedeeld met andere Azure-teams en er worden geen workloads van klanten geïmplementeerd op deze servers. Fysieke toegangsbeheer, inclusief vergrendelde rekken, worden gebruikt om onbevoegde toegang tot de servers te voorkomen. Deze controles voldoen aan FedRAMP-High, PCI, SOC 1/2/3, ISO 270x en andere beveiligings- en privacystandaarden en worden regelmatig onafhankelijk geverifieerd als onderdeel van het Azure-nalevingsprogramma. De HSM's hebben verbeterde fysieke beveiliging, gevalideerd om te voldoen aan de FIPS 140-2 Niveau 3-vereisten. De volledige beheerde HSM-service is gebouwd op het standaard beveiligde Azure-platform, inclusief vertrouwde lancering, die beschermt tegen geavanceerde permanente bedreigingen.
De HSM-adapters kunnen tientallen geïsoleerde HSM-partities ondersteunen. Uitvoeren op elke server is een besturingsproces met de naam Node Service. Node Service neemt eigenaar van elke adapter en installeert de referenties voor de eigenaar van de adapter, in dit geval Microsoft. De HSM is zo ontworpen dat het eigendom van de adapter Microsoft geen toegang biedt tot gegevens die zijn opgeslagen in klantpartities. Hiermee kan alleen Microsoft klantpartities maken, het formaat ervan wijzigen en verwijderen. Het ondersteunt het maken van blinde back-ups van elke partitie voor de klant. In een blinde back-up wordt de back-up verpakt door een door de klant geleverde sleutel die alleen kan worden hersteld door de servicecode binnen een beheerd HSM-exemplaar dat eigendom is van de klant en waarvan de inhoud niet kan worden gelezen door Microsoft.
Architectuur van een beheerde HSM-pool
Afbeelding 1 toont de architectuur van een HSM-pool, die bestaat uit drie Virtuele Linux-machines, die elk worden uitgevoerd op een HSM-server in een eigen datacenterrek ter ondersteuning van beschikbaarheid. De belangrijke onderdelen zijn:
- De HSM-infrastructuurcontroller (HFC) is het besturingsvlak voor de service. De HFC stations geautomatiseerd patchen en reparaties voor de pool.
- Een cryptografische grens van FIPS 140-2 Niveau 3, exclusief voor elke klant, inclusief drie vertrouwelijke Intel Secure Guard Extensions (Intel SGX) -enclaves, die elk zijn verbonden met een HSM-exemplaar. De hoofdsleutels voor deze grens worden gegenereerd en opgeslagen in de drie HSM's. Zoals we verderop in dit artikel beschrijven, heeft niemand die is gekoppeld aan Microsoft toegang tot de gegevens die zich binnen deze grens bevinden. Alleen servicecode die wordt uitgevoerd in de Intel SGX-enclave (inclusief de Node Service-agent), die namens de klant fungeert, heeft toegang.
Vertrouwde uitvoeringsomgeving (TEE)
Een beheerde HSM-pool bestaat uit drie service-exemplaren. Elk service-exemplaar wordt geïmplementeerd als een TEE (Trusted Execution Environment) die gebruikmaakt van Intel SGX-mogelijkheden en de Open Enclave SDK. Uitvoering binnen een TEE zorgt ervoor dat niemand op de virtuele machine (VM) die als host fungeert voor de service of de hostserver van de VM toegang heeft tot klantgeheimen, gegevens of de HSM-partitie. Elke TEE is toegewezen aan een specifieke klant en voert TLS-beheer, aanvraagafhandeling en toegangsbeheer uit voor de HSM-partitie. Er bestaan geen referenties of klantspecifieke gegevensversleutelingssleutels in duidelijke tekst buiten deze TEE, behalve als onderdeel van het beveiligingsdomeinpakket. Dat pakket wordt versleuteld naar een door de klant geleverde sleutel en wordt gedownload wanneer de pool voor het eerst wordt gemaakt.
De TEEs communiceren onderling met behulp van geteste TLS. Geteste TLS combineert de mogelijkheden voor externe attestation van het Intel SGX-platform met TLS 1.2. Hierdoor kan beheerde HSM-code in de TEE de communicatie beperken tot alleen andere code die is ondertekend door dezelfde beheerde HSM-servicecode-ondertekeningssleutel, om man-in-the-middle-aanvallen te voorkomen. De codeondertekeningssleutel van de beheerde HSM-service wordt opgeslagen in Microsoft Product Release en Security Service (die ook wordt gebruikt voor het opslaan van bijvoorbeeld de Windows-code-ondertekeningssleutel). De sleutel wordt beheerd door het beheerde HSM-team. Als onderdeel van onze wettelijke en nalevingsverplichtingen voor wijzigingsbeheer kan deze sleutel niet worden gebruikt door een ander Microsoft-team om de code te ondertekenen.
De TLS-certificaten die worden gebruikt voor TEE-to-TEE-communicatie, worden zelf uitgegeven door de servicecode in de TEE. De certificaten bevatten een platformrapport dat wordt gegenereerd door de Intel SGX-enclave op de server. Het platformrapport wordt ondertekend met sleutels die zijn afgeleid van sleutels die zijn samengevoegd door Intel in de CPU wanneer het wordt vervaardigd. Het rapport identificeert de code die wordt geladen in de Intel SGX-enclave door de code-ondertekeningssleutel en binaire hash. Vanuit dit platformrapport kunnen service-exemplaren bepalen dat een peer ook is ondertekend door de beheerde HSM-servicecode-ondertekeningssleutel en, met enige cryptoverstrengeling via het platformrapport, kan ook worden vastgesteld dat de zelf-uitgegeven certificaatondertekeningssleutel ook binnen de TEE moet zijn gegenereerd om externe imitatie te voorkomen.
Sla's voor beschikbaarheid bieden met volledig door de klant beheerde sleutelbeheer
Om hoge beschikbaarheid te garanderen, maakt de HFC-service drie pools in de door de klant geselecteerde Azure-regio.
Beheerde HSM-pool maken
De eigenschappen voor hoge beschikbaarheid van beheerde HSM-pools zijn afkomstig van de automatisch beheerde, drievoudig redundante HSM-exemplaren die altijd synchroon worden gehouden (of, als u replicatie voor meerdere regio's gebruikt, zodat alle zes exemplaren gesynchroniseerd blijven). Het maken van een pool wordt beheerd door de HFC-service, die pools toewijst aan de beschikbare hardware in de Azure-regio die de klant kiest.
Wanneer een nieuwe pool wordt aangevraagd, selecteert de HFC drie servers in verschillende racks met beschikbare ruimte op hun HSM-adapters. Vervolgens wordt de pool gemaakt:
De HFC geeft de Node Service-agents op elk van de drie TEE's opdracht om een nieuw exemplaar van de servicecode te starten met behulp van een set parameters. De parameters identificeren de Microsoft Entra-tenant van de klant, de IP-adressen van het interne virtuele netwerk van alle drie exemplaren en enkele andere serviceconfiguraties. Eén partitie wordt willekeurig toegewezen als primaire partitie.
De drie exemplaren beginnen. Elk exemplaar maakt verbinding met een partitie op de lokale HSM-adapter en vervolgens wordt de partitie nul gemaakt en geïnitialiseerd met behulp van willekeurig gegenereerde gebruikersnamen en referenties (om ervoor te zorgen dat de partitie niet kan worden geopend door een menselijke operator of door een ander TEE-exemplaar).
Het primaire exemplaar maakt een basiscertificaat van de partitieeigenaar met behulp van de persoonlijke sleutel die wordt gegenereerd in de HSM. Hiermee wordt het eigendom van de pool vastgesteld door een certificaat op partitieniveau voor de HSM-partitie te ondertekenen met behulp van dit basiscertificaat. De primaire genereert ook een gegevensversleutelingssleutel, die wordt gebruikt om alle klantgegevens in rust in de service te beveiligen. Voor sleutelmateriaal wordt een dubbele wrapping gebruikt omdat de HSM ook het sleutelmateriaal zelf beveiligt.
Vervolgens worden deze eigendomsgegevens gesynchroniseerd met de twee secundaire exemplaren. Elke secundaire contactpersoon maakt contact met de primaire met behulp van geteste TLS. Het primaire deelt het basiscertificaat van de partitieeigenaar met de persoonlijke sleutel en de gegevensversleutelingssleutel. De secundaire bestanden gebruiken nu het partitiehoofdcertificaat om een partitiecertificaat uit te geven aan hun eigen HSM-partities. Nadat dit is gebeurd, hebt u HSM-partities op drie afzonderlijke servers die eigendom zijn van hetzelfde partitiehoofdcertificaat.
Via de geteste TLS-koppeling worden de HSM-partitieshares van de primaire primaire met de secundaire gegevensterugloopsleutel (gebruikt voor het versleutelen van berichten tussen de drie HSM's) met behulp van een beveiligde API die wordt geleverd door de HSM-leverancier. Tijdens deze uitwisseling bevestigen de HSM's dat ze hetzelfde certificaat voor partitie-eigenaar hebben en gebruiken ze vervolgens een Diffie-Hellman-schema om de berichten te versleutelen, zodat de Microsoft-servicecode ze niet kan lezen. Het enige wat de servicecode kan doen, is het transport van ondoorzichtige blobs tussen de HSM's.
Op dit moment zijn alle drie de exemplaren gereed om beschikbaar te worden gemaakt als een pool in het virtuele netwerk van de klant. Ze delen hetzelfde certificaat van de partitie-eigenaar en de persoonlijke sleutel, dezelfde gegevensversleutelingssleutel en een algemene sleutel voor gegevensterugloop. Elk exemplaar heeft echter unieke referenties voor hun HSM-partities. Nu zijn de laatste stappen voltooid.
Elk exemplaar genereert een RSA-sleutelpaar en een AANVRAAG voor certificaatondertekening (CSR) voor het openbare TLS-certificaat. De CSR wordt ondertekend door het PKI-systeem (Public Key Infrastructure) van Microsoft met behulp van een openbare basis van Microsoft en het resulterende TLS-certificaat wordt geretourneerd naar het exemplaar.
Alle drie de exemplaren verkrijgen hun eigen Intel SGX-verzegelsleutel van hun lokale CPU. De sleutel wordt gegenereerd met behulp van de eigen unieke sleutel van de CPU en de CODE-ondertekeningssleutel van de TEE.
De pool heeft een unieke poolsleutel afgeleid van de Intel SGX-verzegelingssleutels, versleutelt alle geheimen met behulp van deze poolsleutel en schrijft vervolgens de versleutelde blobs naar schijf. Deze blobs kunnen alleen worden ontsleuteld door code te worden ondertekend door dezelfde Intel SGX-verzegelsleutel die wordt uitgevoerd op dezelfde fysieke CPU. De geheimen zijn gebonden aan dat specifieke exemplaar.
Het beveiligde bootstrap-proces is nu voltooid. Dit proces heeft zowel het maken van een drievoudig redundante HSM-pool als het maken van een cryptografische garantie van de soevereiniteit van klantgegevens toegestaan.
Beschikbaarheids-SLA's tijdens runtime onderhouden met behulp van vertrouwelijke serviceherstel
Het verhaal over het maken van pools dat in dit artikel wordt beschreven, kan uitleggen hoe de beheerde HSM-service de SLA's met hoge beschikbaarheid kan leveren door de servers die ten grondslag ligt aan de service veilig te beheren. Stel dat een server, een HSM-adapter of zelfs de voeding van het rek mislukt. Het doel van de beheerde HSM-service is, zonder tussenkomst van de klant of de mogelijkheid dat geheimen worden weergegeven in duidelijke tekst buiten de TEE, om de pool te herstellen naar drie gezonde exemplaren. Dit wordt bereikt via confidential service healing.
Het begint met de HFC die detecteert welke pools exemplaren hadden op de mislukte server. HFC vindt nieuwe, gezonde servers in de regio van de groep om de vervangende exemplaren te implementeren. Er worden nieuwe exemplaren gestart, die vervolgens precies als een secundaire worden behandeld tijdens de eerste inrichtingsstap: initialiseer de HSM, zoek de primaire, wissel veilig geheimen uit via geteste TLS, onderteken de HSM in de eigendomshiërarchie en verzegel de servicegegevens vervolgens naar de nieuwe CPU. De service wordt nu volledig automatisch en volledig vertrouwelijk hersteld.
Herstellen na noodgeval met behulp van het beveiligingsdomein
Het beveiligingsdomein is een beveiligde blob die alle referenties bevat die nodig zijn om de HSM-partitie helemaal opnieuw te bouwen: de sleutel van de partitie-eigenaar, de partitiereferenties, de gegevensterugloopsleutel, plus een eerste back-up van de HSM. Voordat de service live wordt, moet de klant het beveiligingsdomein downloaden door een set RSA-versleutelingssleutels op te geven om deze te beveiligen. De gegevens van het beveiligingsdomein zijn afkomstig uit de TEE's en worden beveiligd door een gegenereerde symmetrische sleutel en een implementatie van het algoritme Voor het delen van geheimen van Shamir, waarmee de sleutelshares worden verdeeld over de door de klant verstrekte OPENBARE RSA-sleutels op basis van door de klant geselecteerde quorumparameters. Tijdens dit proces worden geen van de servicesleutels of referenties ooit weergegeven in tekst zonder opmaak buiten de servicecode die wordt uitgevoerd in de TEE's. Alleen de klant kan het beveiligingsdomein ontsleutelen tijdens een herstelscenario door een quorum van hun RSA-sleutels aan de TEE te presenteren.
Het beveiligingsdomein is alleen nodig wanneer, vanwege een ramp, een hele Azure-regio verloren gaat en Microsoft alle drie de exemplaren van de pool tegelijk verliest. Als slechts één exemplaar, of zelfs twee exemplaren, verloren gaan, herstelt confidential service-herstel stil naar drie gezonde exemplaren zonder tussenkomst van de klant. Als de hele regio verloren gaat, omdat intel SGX-verzegelingssleutels uniek zijn voor elke CPU, kan Microsoft de HSM-referenties en partitieeigenaarsleutels niet herstellen. Ze bestaan alleen binnen de context van de exemplaren.
In het zeer onwaarschijnlijke geval dat deze ramp optreedt, kan de klant de vorige poolstatus en -gegevens herstellen door een nieuwe lege pool te maken, deze in het beveiligingsdomein te injecteren en vervolgens hun RSA-sleutelquorum te presenteren om het eigendom van het beveiligingsdomein te bewijzen. Als een klant replicatie met meerdere regio's heeft ingeschakeld, zou de nog onwaarschijnlijke ramp van beide regio's die gelijktijdig te maken hebben, volledige fouten moeten optreden voordat de tussenkomst van de klant nodig zou zijn om de pool te herstellen van het beveiligingsdomein.
Toegang tot de service beheren
Zoals beschreven, is onze servicecode in de TEE de enige entiteit die toegang heeft tot de HSM zelf, omdat de benodigde referenties niet aan de klant of aan iemand anders worden gegeven. In plaats daarvan is de groep van de klant gebonden aan het Microsoft Entra-exemplaar. Dit wordt gebruikt voor verificatie en autorisatie. Bij de eerste inrichting kan de klant een eerste set werknemers kiezen om de rol van Beheer istrator voor de pool toe te wijzen. Deze personen en de werknemers in de globale Beheer istratorrol van de Microsoft Entra-tenant van de klant kunnen beleidsregels voor toegangsbeheer instellen binnen de pool. Alle beleidsregels voor toegangsbeheer worden door de service opgeslagen in dezelfde database als de gemaskeerde sleutels, die ook worden versleuteld. Alleen de servicecode in het TEE heeft toegang tot dit toegangsbeheerbeleid.
Samenvatting
Met beheerde HSM hoeven klanten geen compromissen te maken tussen beschikbaarheid en controle over cryptografische sleutels met behulp van geavanceerde, door hardware ondersteunde, vertrouwelijke enclave-technologie. Zoals beschreven in dit artikel, heeft geen microsoft-personeel of vertegenwoordiger in deze implementatie toegang tot door de klant beheerd sleutelmateriaal of gerelateerde geheimen, zelfs met fysieke toegang tot de beheerde HSM-hostmachines en HSM's. Dankzij deze beveiliging hebben onze klanten in financiële dienstverlening, productie, de publieke sector, defensie en andere verticalen hun migraties naar de cloud met volledig vertrouwen versneld.