Nyckelsuveränitet, tillgänglighet, prestanda och skalbarhet i Hanterad HSM
Kryptografiska nycklar är roten till förtroende för att skydda moderna datorsystem, både lokalt eller i molnet. Därför är det viktigt att kontrollera vem som har behörighet över dessa nycklar för att skapa säkra och kompatibla program.
I Azure är vår vision om hur nyckelhantering ska göras i molnet viktig suveränitet. Nyckelsuveränitet innebär att en kunds organisation har fullständig och exklusiv kontroll över vem som kan komma åt nycklar och ändra principer för nyckelhantering samt över vilka Azure-tjänster som använder dessa nycklar. När dessa beslut har fattats av kunden hindras Microsofts personal på tekniska sätt från att ändra dessa beslut. Koden för nyckelhanteringstjänsten kör kundens beslut tills kunden säger åt kunden att göra något annat och Microsofts personal kan inte ingripa.
Samtidigt är det vår övertygelse att alla tjänster i molnet måste hanteras fullt ut. Tjänsten måste tillhandahålla nödvändiga krav på tillgänglighet, återhämtning, säkerhet och grundläggande löften för molnet, med stöd av serviceavtal (SLA). För att leverera en hanterad tjänst måste Microsoft korrigera nyckelhanteringsservrar, uppgradera inbyggd programvara för maskinvarusäkerhetsmoduler (HSM), reparera maskinvara som inte fungerar, utföra redundans och utföra andra högprivilegier. Som de flesta säkerhetspersonal vet är det ett svårt problem att neka någon med hög behörighet eller fysisk åtkomst till ett systemåtkomst till data i systemet.
Den här artikeln förklarar hur vi löste det här problemet i Azure Key Vault Managed HSM-tjänsten, vilket ger kunderna både fullständig nyckelsuveränitet och fullständigt hanterade serviceavtal med hjälp av konfidentiell databehandlingsteknik i kombination med HSM.
Hanterad HSM-maskinvarumiljö
En kunds Managed HSM-pool i alla Azure-regioner finns i ett säkert Azure-datacenter. Tre instanser är spridda över flera servrar. Varje instans distribueras i ett annat rack för att säkerställa redundans. Varje server har en FIPS 140-2 Level 3-validerad Marvell LiquidSecurity HSM-adapter med flera kryptografiska kärnor. Kärnorna används för att skapa fullständigt isolerade HSM-partitioner, inklusive fullständigt isolerade autentiseringsuppgifter, datalagring och åtkomstkontroll.
Den fysiska uppdelningen av instanserna i datacentret är avgörande för att säkerställa att förlusten av en enskild komponent (till exempel rackuppkopplaren eller en energisparenhet i ett rack) inte kan påverka alla instanser av en pool. Dessa servrar är dedikerade till Azure Security HSM-teamet. Servrarna delas inte med andra Azure-team och inga kundarbetsbelastningar distribueras på dessa servrar. Fysiska åtkomstkontroller, inklusive låsta rack, används för att förhindra obehörig åtkomst till servrarna. Dessa kontroller uppfyller FedRAMP-High, PCI, SOC 1/2/3, ISO 270x och andra säkerhets- och sekretessstandarder och verifieras regelbundet oberoende som en del av Azures efterlevnadsprogram. HSM:erna har förbättrad fysisk säkerhet som verifierats för att uppfylla KRAVEN på FIPS 140-2 Nivå 3. Hela Managed HSM-tjänsten bygger på den standard säkra Azure-plattformen, inklusive betrodd start, som skyddar mot avancerade beständiga hot.
HSM-korten har stöd för dussintals isolerade HSM-partitioner. Körs på varje server är en kontrollprocess som kallas Node Service. Node Service tar över ägarskapet för varje kort och installerar autentiseringsuppgifterna för kortägaren, i det här fallet Microsoft. HSM är utformad så att ägarskapet för adaptern inte ger Microsoft åtkomst till data som lagras i kundpartitioner. Det gör att endast Microsoft kan skapa, ändra storlek på och ta bort kundpartitioner. Den har stöd för att ta blinda säkerhetskopior av valfri partition för kunden. I en blind säkerhetskopia omsluts säkerhetskopian av en nyckel som tillhandahålls av kunden och som endast kan återställas av tjänstkoden i en Hanterad HSM-instans som ägs av kunden och vars innehåll inte kan läsas av Microsoft.
Arkitektur för en hanterad HSM-pool
Bild 1 visar arkitekturen för en HSM-pool, som består av tre virtuella Linux-datorer som var och en körs på en HSM-server i ett eget datacenterrack för att stödja tillgänglighet. De viktiga komponenterna är:
- HSM-infrastrukturstyrenheten (HFC) är kontrollplanet för tjänsten. HFC kör automatisk korrigering och reparationer för poolen.
- En FIPS 140-2 Nivå 3-kompatibel kryptografisk gräns, exklusiv för varje kund, inklusive tre konfidentiella Intel Secure Guard-tillägg (Intel SGX), var och en ansluten till en HSM-instans. Rotnycklarna för den här gränsen genereras och lagras i de tre HSM:erna. Som vi beskriver senare i den här artikeln har ingen person som är associerad med Microsoft åtkomst till de data som finns inom den här gränsen. Endast tjänstkod som körs i Intel SGX-enklaven (inklusive Node Service-agenten), som agerar för kundens räkning, har åtkomst.
Betrodd körningsmiljö (TEE)
En hanterad HSM-pool består av tre tjänstinstanser. Varje tjänstinstans implementeras som en betrodd körningsmiljö (TEE) som använder Intel SGX-funktioner och Open Enclave SDK. Körning inom en TEE säkerställer att ingen person på den virtuella datorn (VM) som är värd för tjänsten eller den virtuella datorns värdserver har åtkomst till kundhemligheter, data eller HSM-partitionen. Varje TEE är dedikerad till en specifik kund och kör TLS-hantering, hantering av begäranden och åtkomstkontroll till HSM-partitionen. Inga autentiseringsuppgifter eller kundspecifika datakrypteringsnycklar finns i klartext utanför denna TEE, förutom som en del av säkerhetsdomänpaketet. Paketet krypteras till en nyckel som tillhandahålls av kunden och laddas ned när deras pool först skapas.
Tees kommunicerar sinsemellan med hjälp av intygad TLS. Attesterad TLS kombinerar fjärrattesteringsfunktionerna i Intel SGX-plattformen med TLS 1.2. På så sätt kan Hanterad HSM-kod i TEE begränsa kommunikationen till endast annan kod som är signerad av samma kodsigneringsnyckel för Managed HSM-tjänsten för att förhindra man-in-the-middle-attacker. Den hanterade HSM-tjänstens kodsigneringsnyckel lagras i Microsoft Product Release and Security Service (som också används för att lagra, till exempel windows-kodsigneringsnyckeln). Nyckeln styrs av Managed HSM-teamet. Som en del av våra regel- och efterlevnadsskyldigheter för ändringshantering kan den här nyckeln inte användas av något annat Microsoft-team för att signera dess kod.
De TLS-certifikat som används för TEE-till-TEE-kommunikation utfärdas själv av tjänstkoden i TEE. Certifikaten innehåller en plattformsrapport som genereras av Intel SGX-enklaven på servern. Plattformsrapporten är signerad med nycklar som härleds från nycklar som intel har smält in i processorn när den tillverkas. Rapporten identifierar koden som läses in i Intel SGX-enklaven med dess kodsigneringsnyckel och binära hash. I den här plattformsrapporten kan tjänstinstanser fastställa att en peer också är signerad av kodsigneringsnyckeln för Managed HSM-tjänsten, och med viss kryptosammanflätning via plattformsrapporten kan den också fastställa att den självutfärdade certifikatsigneringsnyckeln också måste ha genererats i TEE för att förhindra extern personifiering.
Erbjuda tillgänglighets serviceavtal med fullständig kundhanterad nyckelkontroll
För att säkerställa hög tillgänglighet skapar HFC-tjänsten tre pooler i den kundvalda Azure-regionen.
Skapa en hanterad HSM-pool
Egenskaperna för hög tillgänglighet för hanterade HSM-pooler kommer från automatiskt hanterade, trippelredundanta HSM-instanser som alltid hålls synkroniserade (eller, om du använder replikering i flera regioner, från att hålla alla sex instanserna synkroniserade). Skapande av pool hanteras av HFC-tjänsten, som allokerar pooler över den tillgängliga maskinvaran i Den Azure-region som kunden väljer.
När en ny pool begärs väljer HFC tre servrar i flera rack som har tillgängligt utrymme på sina HSM-kort och sedan börjar den skapa poolen:
HFC instruerar Node Service-agenterna på var och en av de tre TEE:erna att starta en ny instans av tjänstkoden med hjälp av en uppsättning parametrar. Parametrarna identifierar kundens Microsoft Entra-klientorganisation, det interna virtuella nätverkets IP-adresser för alla tre instanserna och några andra tjänstkonfigurationer. En partition tilldelas slumpmässigt som primär.
De tre instanserna startar. Varje instans ansluter till en partition på sitt lokala HSM-kort, och sedan nollställs och initieras partitionen med hjälp av slumpmässigt genererade användarnamn och autentiseringsuppgifter (för att säkerställa att partitionen inte kan nås av en mänsklig operator eller av en annan TEE-instans).
Den primära instansen skapar ett rotcertifikat för partitionsägare med hjälp av den privata nyckel som genereras i HSM. Den etablerar ägarskapet för poolen genom att signera ett certifikat på partitionsnivå för HSM-partitionen med hjälp av det här rotcertifikatet. Den primära genererar också en datakrypteringsnyckel som används för att skydda alla kunddata i vila i tjänsten. För nyckelmaterial används en dubbel omslutning eftersom HSM också skyddar själva nyckelmaterialet.
Därefter synkroniseras ägarskapsdata till de två sekundära instanserna. Varje sekundär kontaktar den primära med hjälp av attesterad TLS. Primärt delar partitionsägarens rotcertifikat med den privata nyckeln och datakrypteringsnyckeln. Sekundärfilerna använder nu partitionsrotcertifikatet för att utfärda ett partitionscertifikat till sina egna HSM-partitioner. När detta är klart har du HSM-partitioner på tre separata servrar som ägs av samma partitionsrotcertifikat.
Via den verifierade TLS-länken delar den primära HSM-partitionen med den genererade dataomslutningsnyckeln (används för att kryptera meddelanden mellan de tre HSM:erna) med hjälp av ett säkert API som tillhandahålls av HSM-leverantören. Under det här utbytet bekräftar HSM:erna att de har samma partitionsägarcertifikat och använder sedan ett Diffie-Hellman-schema för att kryptera meddelandena så att Microsoft-tjänstkoden inte kan läsa dem. Allt som tjänstkoden kan göra är att transportera ogenomskinliga blobar mellan HSM:erna.
Nu är alla tre instanserna redo att exponeras som en pool i kundens virtuella nätverk. De delar samma partitionsägarcertifikat och privata nyckel, samma datakrypteringsnyckel och en gemensam dataomslutningsnyckel. Varje instans har dock unika autentiseringsuppgifter för sina HSM-partitioner. Nu har de sista stegen slutförts.
Varje instans genererar ett RSA-nyckelpar och en certifikatsigneringsbegäran (CSR) för sitt offentliga TLS-certifikat. CSR signeras av Microsofts PKI-system (Public Key Infrastructure) med hjälp av en offentlig Microsoft-rot och det resulterande TLS-certifikatet returneras till instansen.
Alla tre instanserna får en egen Intel SGX-tätningsnyckel från sin lokala CPU. Nyckeln genereras med hjälp av PROCESSORns egen unika nyckel och TEE:s kodsigneringsnyckel.
Poolen härleder en unik poolnyckel från Intel SGX-tätningsnycklarna, krypterar alla sina hemligheter med hjälp av den här poolnyckeln och skriver sedan de krypterade blobarna till disken. Dessa blobar kan endast dekrypteras genom kodsignering av samma Intel SGX-tätningsnyckel som körs på samma fysiska PROCESSOR. Hemligheterna är bundna till den specifika instansen.
Den säkra bootstrap-processen är nu klar. Den här processen har möjliggjort både skapandet av en trippelredundant HSM-pool och skapandet av en kryptografisk garanti för kundens suveränitet.
Underhåll av tillgänglighets serviceavtal vid körning med hjälp av konfidentiell tjänståterställning
Artikeln om att skapa pooler som beskrivs i den här artikeln kan förklara hur den hanterade HSM-tjänsten kan leverera sina serviceavtal med hög tillgänglighet genom att hantera servrarna som ligger till grund för tjänsten på ett säkert sätt. Anta att en server, ett HSM-kort eller till och med strömförsörjningen till racket misslyckas. Målet med managed HSM-tjänsten är, utan någon kundintervention eller möjligheten att hemligheter exponeras i klartext utanför TEE, att återställa poolen till tre felfria instanser. Detta uppnås genom konfidentiell tjänståterställning.
Det börjar med att HFC identifierar vilka pooler som hade instanser på den misslyckade servern. HFC hittar nya, felfria servrar i poolens region för att distribuera ersättningsinstanserna till. Den startar nya instanser, som sedan behandlas exakt som en sekundär under det första etableringssteget: initiera HSM, hitta dess primära, utbyta hemligheter på ett säkert sätt över attesterad TLS, signera HSM i ägarhierarkin och sedan försegla sina tjänstdata till sin nya PROCESSOR. Tjänsten har nu reparerats, helt automatiskt och helt konfidentiellt.
Återställa från haveri med hjälp av säkerhetsdomänen
Säkerhetsdomänen är en skyddad blob som innehåller alla autentiseringsuppgifter som behövs för att återskapa HSM-partitionen från grunden: partitionens ägarnyckel, partitionens autentiseringsuppgifter, dataomslutningsnyckeln plus en första säkerhetskopia av HSM. Innan tjänsten blir live måste kunden ladda ned säkerhetsdomänen genom att tillhandahålla en uppsättning RSA-krypteringsnycklar för att skydda den. Säkerhetsdomändata kommer från TEE:erna och skyddas av en genererad symmetrisk nyckel och en implementering av Shamirs algoritm för hemlig delning, som delar upp nyckelresurserna mellan de offentliga RSA-nycklar som tillhandahålls av kunden enligt kundvalda kvorumparametrar. Under den här processen exponeras ingen av tjänstnycklarna eller autentiseringsuppgifterna i klartext utanför tjänstkoden som körs i TEE:erna. Endast kunden kan dekryptera säkerhetsdomänen under ett återställningsscenario genom att presentera ett kvorum för sina RSA-nycklar för TEE.
Säkerhetsdomänen behövs bara när en hel Azure-region går förlorad på grund av en katastrof och Microsoft förlorar alla tre instanserna av poolen samtidigt. Om endast en instans, eller till och med två instanser, går förlorade återställs den konfidentiella tjänståterställningen i tysthet till tre felfria instanser utan kundintervention. Om hela regionen går förlorad, eftersom Intel SGX-tätningsnycklar är unika för varje processor, kan Microsoft inte återställa HSM-autentiseringsuppgifterna och partitionsägarnycklarna. De finns bara i kontexten för instanserna.
Om den här katastrofen inträffar kan kunden återställa sitt tidigare pooltillstånd och sina data genom att skapa en ny tom pool, mata in den i säkerhetsdomänen och sedan presentera sitt RSA-nyckelkvorum för att bevisa ägarskap för säkerhetsdomänen. Om en kund har aktiverat replikering i flera regioner, skulle den ännu mer osannolika katastrofen i båda regionerna med samtidiga, fullständiga fel behöva inträffa innan kundintervention skulle behövas för att återställa poolen från säkerhetsdomänen.
Kontrollera åtkomsten till tjänsten
Enligt beskrivningen är vår tjänstkod i TEE den enda entitet som har åtkomst till själva HSM:n eftersom de nödvändiga autentiseringsuppgifterna inte ges till kunden eller någon annan. I stället är kundens pool bunden till sin Microsoft Entra-instans, och den används för autentisering och auktorisering. Vid den första etableringen kan kunden välja en första uppsättning anställda för att tilldela administratörsrollen för poolen. Dessa personer, och de anställda i kundens globala administratörsroll för Microsoft Entra-klientorganisationen, kan ange principer för åtkomstkontroll i poolen. Alla principer för åtkomstkontroll lagras av tjänsten i samma databas som de maskerade nycklarna, som också är krypterade. Endast tjänstkoden i TEE har åtkomst till dessa principer för åtkomstkontroll.
Sammanfattning
Hanterad HSM tar bort behovet av att kunder gör kompromisser mellan tillgänglighet och kontroll över kryptografiska nycklar med hjälp av avancerad, maskinvarubaserad, konfidentiell enklavteknik. Som beskrivs i den här artikeln kan ingen Microsoft-personal eller representant i den här implementeringen komma åt kundhanterat nyckelmaterial eller relaterade hemligheter, även med fysisk åtkomst till hanterade HSM-värddatorer och HSM:er. Den här säkerheten har gjort det möjligt för våra kunder inom finansiella tjänster, tillverkning, den offentliga sektorn, försvaret och andra vertikaler att påskynda sina migreringar till molnet med fullt förtroende.