Klíčová suverenita, dostupnost, výkon a škálovatelnost ve spravovaném HSM
Kryptografické klíče jsou kořenem důvěryhodnosti pro zabezpečení moderních počítačových systémů bez ohledu na to, jestli jsou místní nebo v cloudu. Řízení, kdo má nad těmito klíči autoritu, je proto důležité pro vytváření zabezpečených a vyhovujících aplikací.
V Azure je naše vize, jak by měla být správa klíčů provedena v cloudu, klíčovou suverenitou. Klíčová suverenita znamená, že organizace zákazníka má plnou a výhradní kontrolu nad tím, kdo může přistupovat ke klíčům a měnit zásady správy klíčů a jaké služby Azure tyto klíče využívají. Po provedení těchto rozhodnutí zákazníkem se pracovníkům Microsoftu zabrání, aby se tato rozhodnutí změnila technickými prostředky. Kód služby správy klíčů provede rozhodnutí zákazníka, dokud mu zákazník neudělí, aby to jinak udělal, a pracovníci Microsoftu nemůžou zasahovat.
Zároveň jsme přesvědčeni, že každá služba v cloudu musí být plně spravovaná. Služba musí poskytovat požadované přísliby dostupnosti, odolnosti, zabezpečení a cloudu, které jsou zajištěné smlouvami o úrovni služeb (SLA). Aby microsoft mohl poskytovat spravovanou službu, musí opravovat servery pro správu klíčů, upgradovat firmware modulu hardwarového zabezpečení (HSM), opravit selhávající hardware, provést převzetí služeb při selhání a provádět další operace s vysokými oprávněními. Jak vědí většina odborníků na zabezpečení, odepření vysokého oprávnění nebo fyzického přístupu k systémovému přístupu k datům v daném systému je obtížné.
Tento článek vysvětluje, jak jsme tento problém vyřešili ve službě Azure Key Vault Managed HSM, což zákazníkům poskytuje úplnou suverenitu klíčů i plně spravované smlouvy SLA služby pomocí důvěrných výpočetních technologií spárovaných s moduly HARDWAROVÉHO ZABEZPEČENÍ.
Hardwarové prostředí spravovaného HSM
Fond spravovaných HSM zákazníka v jakékoli oblasti Azure je v zabezpečeném datacentru Azure. Tři instance jsou rozloženy na několik serverů. Každá instance je nasazená v jiném racku, aby se zajistila redundance. Každý server má adaptér FIPS 140-2 Level 3 ověřený adaptér Marvell LiquidSecurity HSM s několika kryptografickými jádry. Jádra se používají k vytvoření plně izolovaných oddílů HSM, včetně plně izolovaných přihlašovacích údajů, úložiště dat a řízení přístupu.
Fyzické oddělení instancí uvnitř datacentra je důležité k zajištění toho, aby ztráta jedné komponenty (například přepínače top-of-rack nebo jednotky řízení spotřeby v racku) nemohla ovlivnit všechny instance fondu. Tyto servery jsou vyhrazené pro tým HSM zabezpečení Azure. Servery nejsou sdílené s jinými týmy Azure a na těchto serverech nejsou nasazené žádné úlohy zákazníků. Fyzické řízení přístupu, včetně uzamčených racků, slouží k zabránění neoprávněnému přístupu k serverům. Tyto kontroly splňují standard FedRAMP-High, PCI, SOC 1/2/3, ISO 270x a další standardy zabezpečení a ochrany osobních údajů a pravidelně se ověřují jako součást programu dodržování předpisů Azure. Moduly hardwarového zabezpečení mají vylepšené fyzické zabezpečení, které je ověřené tak, aby splňovaly požadavky FIPS 140-2 úrovně 3. Celá spravovaná služba HSM je postavená na standardní zabezpečené platformě Azure, včetně důvěryhodného spuštění, která chrání před pokročilými trvalými hrozbami.
Adaptéry HSM můžou podporovat desítky izolovaných oddílů HSM. Spuštění na každém serveru je řídicí proces s názvem Node Service. Služba Node Service převezme vlastnictví každého adaptéru a nainstaluje přihlašovací údaje vlastníka adaptéru, v tomto případě Microsoftu. MODUL HARDWAROVÉHO ZABEZPEČENÍ je navržený tak, aby vlastnictví adaptéru neuděluje Microsoftu přístup k datům uloženým v oddílech zákazníka. Umožňuje pouze Microsoftu vytvářet, měnit velikost a odstraňovat oddíly zákazníků. Podporuje pořizování slepých záloh libovolného oddílu pro zákazníka. Ve slepé záloze je záloha zabalena klíčem poskytnutým zákazníkem, který je možné obnovit kódem služby pouze uvnitř spravované instance HSM vlastněné zákazníkem a jehož obsah není čitelný společností Microsoft.
Architektura spravovaného fondu HSM
Obrázek 1 znázorňuje architekturu fondu HSM, který se skládá ze tří virtuálních počítačů s Linuxem, z nichž každý běží na serveru HSM ve vlastním racku datacentra pro podporu dostupnosti. Důležité součásti jsou:
- Kontroler prostředků infrastruktury HSM (HFC) je řídicí rovina služby. HFC řídí automatizované opravy a opravy fondu.
- Kryptografické hranice kompatibilní se standardem FIPS 140-2 Level 3, které jsou exkluzivní pro každého zákazníka, včetně tří důvěrných enkláv Intel Secure Guard Extensions (Intel SGX), z nichž každý je připojený k instanci HSM. Kořenové klíče pro tuto hranici se vygenerují a ukládají ve třech modulech HSM. Jak popisujeme dále v tomto článku, žádná osoba přidružená k Microsoftu nemá přístup k datům, která jsou v této hranici. Přístup má pouze kód služby spuštěný v enklávě Intel SGX (včetně agenta Node Service), který funguje jménem zákazníka.
Důvěryhodné spouštěcí prostředí (TEE)
Spravovaný fond HSM se skládá ze tří instancí služby. Každá instance služby se implementuje jako důvěryhodné spouštěcí prostředí (TEE), které používá funkce Intel SGX a sadu Open Enclave SDK. Provádění v rámci TEE zajišťuje, že žádná osoba na virtuálním počítači, který je hostitelem služby, nebo hostitelský server virtuálního počítače má přístup k tajným kódům zákazníků, datům nebo oddílu HSM. Každý TEE je vyhrazený pro konkrétního zákazníka a spouští správu protokolu TLS, zpracování žádostí a řízení přístupu k oddílu HSM. Mimo tento TEE neexistují žádné přihlašovací údaje ani šifrovací klíče dat specifické pro zákazníky, s výjimkou části balíčku domény zabezpečení. Tento balíček se zašifruje na klíč poskytnutý zákazníkem a stáhne se při prvním vytvoření fondu.
TEE mezi sebou komunikují pomocí atestovaného protokolu TLS. Atestovaný protokol TLS kombinuje možnosti vzdáleného ověření identity platformy Intel SGX s protokolem TLS 1.2. To umožňuje spravovanému kódu HSM v TEE omezit komunikaci jenom na jiný kód podepsaný stejným podpisovým klíčem služby HSM, aby se zabránilo útokům typu man-in-the-middle. Podpisový klíč spravované služby HSM je uložený ve službě Microsoft Product Release and Security Service (který se také používá k ukládání, například podpisového klíče kódu systému Windows). Klíč řídí tým spravovaného HSM. Tento klíč nemůže podepisovat žádný jiný tým Microsoftu jako součást našich zákonných a dodržování předpisů pro správu změn.
Certifikáty TLS používané pro komunikaci TEE-to-TEE jsou samostatně vystavené kódem služby uvnitř TEE. Certifikáty obsahují sestavu platformy vygenerovanou enklávem Intel SGX na serveru. Sestava platformy je podepsána klíči, které jsou odvozeny od klíčů, které intel při výrobě využívají do procesoru. Sestava identifikuje kód načtený do enklávy Intel SGX podpisovým klíčem kódu a binární hodnotou hash. Z této sestavy platformy můžou instance služby určit, že partnerský vztah je také podepsaný podpisovým klíčem spravované služby HSM a s některými kryptografickými propleteními prostřednictvím sestavy platformy může také určit, že se musí vygenerovat také klíč pro podpis certifikátu vydaný svým držitelem uvnitř TEE, aby se zabránilo externí zosobnění.
Nabídka smluv SLA dostupnosti s úplným řízením klíčů spravovaných zákazníkem
Aby se zajistila vysoká dostupnost, služba HFC vytvoří ve vybrané oblasti Azure tři fondy.
Vytvoření spravovaného fondu HSM
Vlastnosti s vysokou dostupností spravovaných fondů HSM pocházejí z automaticky spravovaných třikrát redundantních instancí HSM, které jsou vždy synchronizované (nebo pokud používáte replikaci ve více oblastech), aby se všech šest instancí synchronizovaly. Vytvoření fondu spravuje služba HFC, která přiděluje fondy napříč dostupným hardwarem v oblasti Azure, kterou si zákazník zvolí.
Když se požaduje nový fond, HFC vybere tři servery v několika rackech, které mají volné místo na adaptérech HSM, a pak začne vytvářet fond:
HFC dává agentům služby Node Service na každém ze tří TEE pokyn, aby pomocí sady parametrů spustili novou instanci kódu služby. Parametry identifikují tenanta Microsoft Entra zákazníka, IP adresy interní virtuální sítě všech tří instancí a některé další konfigurace služeb. Jeden oddíl je náhodně přiřazený jako primární.
Spustí se tři instance. Každá instance se připojí k oddílu na místním adaptéru HSM a pak oddíl vynuluje a inicializuje pomocí náhodně vygenerovaných uživatelských jmen a přihlašovacích údajů (aby k oddílu nemohl získat přístup lidský operátor nebo jiná instance TEE).
Primární instance vytvoří kořenový certifikát vlastníka oddílu pomocí privátního klíče, který je vygenerovaný v modulu HSM. Vytvoří vlastnictví fondu podepsáním certifikátu na úrovni oddílu pro oddíl HSM pomocí tohoto kořenového certifikátu. Primární server také vygeneruje šifrovací klíč dat, který slouží k ochraně všech neaktivních uložených zákaznických dat ve službě. U klíčového materiálu se používá dvojité zabalení, protože HSM chrání také samotný materiál klíče.
Dále se tato data vlastnictví synchronizují se dvěma sekundárními instancemi. Každá sekundární kontaktuje primární pomocí atestovaného protokolu TLS. Primární sdílí kořenový certifikát vlastníka oddílu s privátním klíčem a šifrovacím klíčem dat. Sekundární certifikát teď použije kořenový certifikát oddílu k vydání certifikátu oddílu pro vlastní oddíly HSM. Až to uděláte, budete mít oddíly HSM na třech samostatných serverech, které vlastní stejný kořenový certifikát oddílu.
Prostřednictvím ověřeného propojení TLS sdílí oddíl HSM primárního serveru s sekundárním vygenerovaným klíčem pro zabalení dat (používaným k šifrování zpráv mezi třemi moduly HSM) pomocí zabezpečeného rozhraní API, které poskytuje dodavatel HSM. Během této výměny moduly hardwarového zabezpečení potvrdí, že mají stejný certifikát vlastníka oddílu, a pak pomocí schématu Diffie-Hellman zašifrují zprávy, aby je kód služby Microsoft nemohl přečíst. Veškerý kód služby může provádět přenos neprůhlených objektů blob mezi moduly HARDWAROVÉHO ZABEZPEČENÍ.
V tomto okamžiku jsou všechny tři instance připravené k zveřejnění jako fond ve virtuální síti zákazníka. Sdílejí stejný certifikát vlastníka oddílu a privátní klíč, stejný šifrovací klíč dat a společný klíč pro zabalení dat. Každá instance ale má jedinečné přihlašovací údaje pro své oddíly HSM. Teď jsou dokončeny poslední kroky.
Každá instance vygeneruje pár klíčů RSA a žádost o podepsání certifikátu (CSR) pro svůj veřejně přístupný certifikát TLS. CSR je podepsán systémem infrastruktury veřejných klíčů Microsoftu (PKI) pomocí veřejného kořenového adresáře Microsoftu a výsledný certifikát TLS se vrátí do instance.
Všechny tři instance získají svůj vlastní klíč těsnicího klíče Intel SGX z místního procesoru. Klíč se generuje pomocí vlastního jedinečného klíče procesoru a podpisového klíče TEE.
Fond odvozuje jedinečný klíč fondu z klíčů zapečetění Intel SGX, zašifruje všechny jeho tajné kódy pomocí tohoto klíče fondu a pak zapíše šifrované objekty blob na disk. Tyto objekty blob je možné dešifrovat pouze tím, že jsou podepsané kódem stejného klíče těsnicího klíče Intel SGX, který běží na stejném fyzickém procesoru. Tajné kódy jsou vázané na danou konkrétní instanci.
Proces zabezpečené metody bootstrap je teď dokončený. Tento proces umožnil vytvoření trojitého redundantního fondu HSM i vytvoření kryptografické záruky suverenity zákaznických dat.
Udržování smluv SLA dostupnosti za běhu pomocí opravy důvěrných služeb
Scénář vytvoření fondu, který je popsaný v tomto článku, vysvětluje, jak spravovaná služba HSM dokáže poskytovat smlouvy SLA s vysokou dostupností zabezpečenou správou serverů, které jsou základem služby. Představte si, že server, adaptér HSM nebo dokonce napájecí zdroj do racku selže. Cílem spravované služby HSM je bez zásahu zákazníka nebo možnosti zveřejnění tajných kódů v prostém textu mimo TEE, aby se fond vyléčil zpět do tří instancí, které jsou v pořádku. Toho se dosahuje prostřednictvím opravy důvěrných služeb.
Začíná HFC zjistit, které fondy měly instance na neúspěšném serveru. HFC najde nové a zdravé servery v oblasti fondu pro nasazení náhradních instancí. Spustí nové instance, které se pak při počátečním kroku zřizování považují za sekundární: inicializují HSM, najdou primární, bezpečně vyměňují tajné kódy přes potvrzené TLS, podepíší HSM do hierarchie vlastnictví a pak zapečetí data služby do nového procesoru. Služba je nyní zcela automaticky a plně důvěrně vyléčena.
Zotavení po havárii pomocí domény zabezpečení
Doména zabezpečení je zabezpečený objekt blob, který obsahuje všechny přihlašovací údaje potřebné k opětovnému sestavení oddílu HSM od začátku: klíč vlastníka oddílu, přihlašovací údaje oddílu, klíč pro zabalení dat a počáteční zálohu HSM. Než bude služba aktivní, zákazník si musí stáhnout doménu zabezpečení tím, že poskytne sadu šifrovacích klíčů RSA, aby ji zabezpečil. Data domény zabezpečení pocházejí z TEE a jsou chráněna vygenerovaným symetrickým klíčem a implementací algoritmu Shamirova tajného sdílení tajných kódů, který rozdělí klíčové sdílené složky mezi veřejné klíče RSA poskytované zákazníkem podle parametrů kvora vybraných zákazníkem. Během tohoto procesu se žádné klíče služby ani přihlašovací údaje nezpřístupní v prostém textu mimo kód služby spuštěný v TEE. Doménu zabezpečení může během scénáře obnovení dešifrovat pouze zákazník tím, že předá kvorum svých klíčů RSA TEE.
Doména zabezpečení je nutná pouze v případě, že kvůli určité katastrofě dojde ke ztrátě celé oblasti Azure a Microsoft současně ztratí všechny tři instance fondu. Pokud dojde ke ztrátě pouze jedné instance nebo dokonce dvou instancí, opravy důvěrných služeb se tiše obnoví na tři instance, které jsou v pořádku, bez zásahu zákazníka. Pokud dojde ke ztrátě celé oblasti, protože klíče zapečetění Intel SGX jsou jedinečné pro každý procesor, microsoft nemá způsob, jak obnovit přihlašovací údaje HSM a klíče vlastníka oddílu. Existují pouze v kontextu instancí.
V extrémně nepravděpodobném případě, že k této katastrofě dojde, může zákazník obnovit svůj předchozí stav fondu a data vytvořením nového prázdného fondu, vložením do domény zabezpečení a následným předložením kvora klíče RSA k prokázání vlastnictví domény zabezpečení. Pokud zákazník povolil replikaci ve více oblastech, muselo by dojít k úplnému selhání ještě nepravděpodobněji v obou oblastech, než bude potřeba provést zásah zákazníka k obnovení fondu z domény zabezpečení.
Řízení přístupu ke službě
Jak je popsáno, náš kód služby v TEE je jediná entita, která má přístup k samotnému hsM, protože nezbytné přihlašovací údaje nejsou uděleny zákazníkovi ani komukoli jinému. Místo toho je fond zákazníka svázaný s jeho instancí Microsoft Entra a používá se k ověřování a autorizaci. Při počátečním zřizování může zákazník zvolit počáteční sadu zaměstnanců, kteří přiřadí roli Správa istrator pro fond. Tito jednotlivci a zaměstnanci v globální roli tenanta Microsoft Entra zákazníka Microsoft Entra Správa istrator mohou nastavit zásady řízení přístupu v rámci fondu. Všechny zásady řízení přístupu jsou uloženy službou ve stejné databázi jako maskované klíče, které jsou také šifrované. K těmto zásadám řízení přístupu má přístup pouze kód služby v TEE.
Shrnutí
Spravovaný HSM eliminuje potřebu zákazníků provádět kompromisy mezi dostupností a kontrolou nad kryptografickými klíči pomocí špičkové technologie založené na hardwaru a důvěrné enklávě. Jak je popsáno v tomto článku, v této implementaci nemají pracovníci ani zástupci Microsoftu přístup k materiálům klíčů spravovaným zákazníkem nebo souvisejícím tajným kódům, a to ani s fyzickým přístupem k hostitelským počítačům a modulům HSM spravovaného HSM. Toto zabezpečení umožnilo našim zákazníkům v oblasti finančních služeb, výroby, veřejného sektoru, obrany a dalších vertikálních instancí urychlit migraci do cloudu s plnou jistotou.