Spolehlivost ve spravovaném HSM služby Azure Key Vault

Azure Key Vault managed HSM je plně spravovaná, vysoce dostupná cloudová služba kompatibilní s jedním tenantem, která umožňuje chránit kryptografické klíče pro vaše cloudové aplikace pomocí modulů hardwarového zabezpečení (HSM), které jsou ověřeny pro FIPS 140–3 úroveň 3. Spravovaný HSM poskytuje řadu integrovaných funkcí spolehlivosti, které vám pomůžou zajistit, aby vaše klíče zůstaly dostupné.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak je Managed HSM odolný vůči různým možným výpadkům a problémům, včetně přechodných chyb, selhání partition a výpadků regionů. Popisuje také, jak používat zálohy a doménu zabezpečení pro zotavení po havárii, jak funkce obnovení chrání před náhodným odstraněním, a informace o smlouvě SLA (Managed HSM Service Level Agreement).

Doporučení pro nasazení do produkčního prostředí

Pro produkční úlohy doporučujeme:

  • Okamžitě po zřízení spravovaného HSM stáhněte a bezpečně uložte doménu zabezpečení . Pro zotavení po havárii potřebujete doménu zabezpečení.
  • Nastavte pro bezpečnostní doménu vícečlenné kvorum s nejméně třemi držiteli klíčů.
  • Povolte ochranu před vymazáním , abyste zabránili náhodnému nebo škodlivému odstranění.
  • Implementujte pravidelné zálohy do účtu služby Azure Storage a v podporovaných oblastech používejte geograficky redundantní úložiště.
  • Povolte replikaci do více oblastí pro kriticky důležité úlohy, které vyžadují vyšší úroveň SLA.

Přehled architektury spolehlivosti

Při použití spravovaného HSM nasadíte instanci, která se někdy označuje jako fond.

Architektura spravovaného HSM je navržená pro zajištění vysoké dostupnosti a odolnosti.

  • Izolace s jedním tenantem: Každá spravovaná instance HSM je vyhrazená jednomu zákazníkovi a skládá se z clusteru několika oddílů HSM, které jsou kryptograficky izolované.

  • Trojnásobně redundantní oddíly: Spravovaný fond HSM se skládá ze tří oddílů HSM s vyrovnáváním zatížení distribuovaných napříč samostatnými racky v rámci datacentra. Tato distribuce poskytuje redundanci proti selhání hardwaru a zajišťuje, že ztráta jedné komponenty, jako je napájecí zdroj racku nebo síťový přepínač, nemá vliv na všechny oddíly.

  • Důvěrné výpočetní operace: Každá instance služby běží v důvěryhodném spouštěcím prostředí (TEE), které používá enklávy Intel SGX. Microsoft pracovníci, včetně jednotlivců s fyzickým přístupem k serverům, nemají přístup k vašemu kryptografickému klíči.

  • Automatické opravy: Pokud selhání hardwaru nebo jiný problém ovlivní jeden ze tří oddílů, služba automaticky znovu sestaví ovlivněný oddíl na funkčním hardwaru bez zásahu zákazníka a bez vystavení tajných kódů.

Informace o tom, jak spravované HSM tyto funkce implementuje, najdete v tématu Klíčová suverenita, dostupnost, výkon a škálovatelnost spravovaného HSM.

Doména zabezpečení

Doména zabezpečení je důležitou součástí spravovaného HSM pro účely zotavení po havárii. Jedná se o šifrovaný objekt blob, který obsahuje všechny přihlašovací údaje potřebné k opětovnému sestavení spravované instance HSM od začátku, včetně klíče vlastníka oddílu, přihlašovacích údajů oddílu, klíče pro zabalení dat a počáteční zálohy HSM.

Important

Bez domény zabezpečení není zotavení po havárii možné. Microsoft nemá žádný způsob, jak obnovit doménu zabezpečení a nemá přístup k vašim klíčům bez ní.

Domény zabezpečení jsou důležitou součástí zabezpečení a spolehlivosti spravovaného HSM. Doporučujeme postupovat podle těchto osvědčených postupů:

  • Bezpečné generování klíčů: V produkčních prostředích vygenerujte páry klíčů RSA, které chrání doménu zabezpečení v prostředí s mezerou vzduchu, jako je místní HSM nebo izolovaná pracovní stanice.

  • Uložit offline: Ukládejte klíče domény zabezpečení na šifrovaných usb discích nebo na jiném offline úložišti, přičemž každý sdílený klíč je na samostatném zařízení v samostatných geografických umístěních.

  • Vytvoření kvora s více osobami: Používejte aspoň tři vlastníky klíčů, abyste zabránili všem osobám v přístupu ke všem klíčům kvora a vyhnuli se závislosti na jakékoli osobě.

Další informace najdete v tématu Přehled domény zabezpečení ve spravovaném HSM.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Pokud používáte služby Azure, které se integrují se spravovaným HSM, tyto služby zpracovávají přechodné chyby automaticky.

Pokud vytváříte vlastní aplikace, které se integrují se spravovaným HSM, zvažte následující osvědčené postupy pro zpracování přechodných chyb, ke kterým může dojít:

  • Použijte sady SDK poskytované Microsoftem pro Azure Key Vault, které zahrnují integrované mechanismy opakování. Sady SDK jsou k dispozici pro .NET, Python a JavaScript.

  • Implementujte logiku opakování pokusů, včetně exponenciálního prodlužování intervalů, u veškerého kódu, který pracuje přímo se službou Managed HSM.

  • Snižte počet přímých závislostí na spravovaném HSM. Ukládejte výsledky kryptografických operací do mezipaměti, pokud je to možné, aby se snížily přímé požadavky na spravované HSM. Místně proveďte operace veřejného klíče, jako je šifrování, zabalení a ověření, uložením do mezipaměti materiálu veřejného klíče. Provádění operací místně snižuje závislost na spravovaném HSM a snižuje pravděpodobnost přerušení těchto operací přechodnými chybami.

Pokud spravované HSM používáte ve scénářích s vysokou propustností, spravovaný HSM neomezuje kryptografické operace. Využívá svůj hardware HSM k plné kapacitě. Každá spravovaná instance HSM má tři oddíly. Během operací údržby nebo opravy může být jeden oddíl nedostupný. Při plánování kapacity je třeba předpokládat, že jsou k dispozici dva oddíly. Pokud požadujete zaručenou propustnost, naplánujte plán na základě dostupného jednoho oddílu. Monitorujte metriku dostupnosti spravovaného HSM , abyste porozuměli stavu služby.

Pokud chcete škálovat šifrování pro velké objemy dat, použijte hierarchii klíčů. Ve spravovaném HSM uložte pouze šifrovací klíč klíče (KEK) a použijte ho k zabalení šifrovacích klíčů nižší úrovně uložených jinde v zabezpečeném úložišti klíčů.

Další informace o srovnávacích testech výkonu a plánování kapacity najdete v tématu Azure pokyny ke škálování spravovaného HSM.

Odolnost vůči selháním při rozdělení systému

Spravovaný HSM dosahuje vysoké dostupnosti prostřednictvím trojité redundantní architektury, kde se každý fond HSM skládá ze tří oddílů HSM distribuovaných mezi samostatné serverové racky v rámci datacentra. Tato distribuce na úrovni racku poskytuje redundanci vůči lokalizovaným selháním hardwaru.

Diagram zobrazující tři oddíly fondu Managed HSM, každý na samostatném fyzickém serveru a v jiném serverovém stojanu.

Pokud dojde k selhání hardwaru nebo lokalizovaným výpadkům, spravovaný HSM automaticky přesměruje vaše požadavky na oddíly, které jsou v pořádku, a znovu sestaví ovlivněné oddíly prostřednictvím procesu označovaného jako oprava důvěrných služeb. Selhané oddíly se automaticky znovu vytvářejí na funkčním hardwaru s využitím atestovaného protokolu TLS a enkláv Intel SGX k ochraně tajných údajů během obnovy.

Cost

Integrovaná vysoká dostupnost ve spravovaném HSM nepřidá žádné další náklady. Ceny vycházejí z počtu fondů HSM a počtu operací, které provádíte. Další informace najdete v tématu Ceny spravovaného HSM v Azure.

Chování, když jsou všechny oddíly zdravé

Tato část popisuje, co očekávat, když jsou spravované fondy HSM funkční a nejsou k dispozici žádné oddíly.

  • Směrování provozu: Spravovaný HSM automaticky spravuje směrování provozu napříč třemi oddíly. Během normálních operací transparentně distribuuje požadavky napříč oddíly.

  • Replikace dat: Spravovaný HSM synchronně replikuje všechna data, včetně klíčů, přiřazení rolí a zásad řízení přístupu, napříč všemi třemi oddíly. Tento přístup zajišťuje konzistenci a dostupnost i v případě, že oddíl přestane být dostupný.

Chování při selhání oddílu

Tato část popisuje, co očekávat, když jeden nebo více oddílů není dostupný.

  • Detekce a odpověď: Spravovaná služba HSM detekuje selhání oddílů a automaticky na ně reaguje. Během selhání oddílu nemusíte provádět žádnou akci.

  • Aktivní požadavky: Během selhání oddílu mohou požadavky právě zpracovávané v postiženém oddílu selhat a klientské aplikace je budou muset zopakovat. Aby se minimalizovaly dopady výpadků oddílů, klientské aplikace by měly uplatňovat postupy pro řešení přechodných chyb.

  • Očekávaná ztráta dat: Během selhání oddílu se neočekává žádná ztráta dat díky synchronní replikaci napříč oddíly.

  • Očekávaný výpadek: Při operacích čtení a většině kryptografických operací by během selhání oddílu měl být výpadek minimální nebo žádný. Zbývající oddíly, které jsou v pořádku, nadále obsluhují požadavky.

  • Přesměrování provozu: Spravovaný HSM automaticky směruje provoz z ovlivněného oddílu na oddíly, které jsou v pořádku, aniž by vyžadoval zásah zákazníka.

Obnovení oddílů

Když se ovlivněný oddíl obnoví, spravovaný HSM automaticky obnoví operace prostřednictvím opravy důvěrných služeb. Tento proces:

  1. Vytvoří novou instanci služby na hardwaru, který je v pořádku.
  2. Navazuje ověřené připojení TLS s primární partí.
  3. Bezpečně vyměňuje přihlašovací údaje a kryptografický materiál.
  4. Uzamkne data služby pro nový procesor.

Platforma Azure tento proces plně spravuje a nevyžaduje žádný zásah zákazníka.

Odolnost proti chybám zóny dostupnosti

Vysoká dostupnost ve spravovaném HSM je založená na distribuci na úrovni racku v rámci datacentra, nikoli explicitním nasazením zóny dostupnosti. Každý oddíl běží na samostatném serveru v jiném racku, který chrání před selháními na úrovni racku, jako jsou problémy s napájením nebo síťovým přepínačem.

Pokud chcete chránit před výpadky v celé zóně datového centra nebo v celé zóně dostupnosti, použijte jeden z přístupů popsaných v oblasti odolnosti vůči selháním v celé oblasti.

Odolnost proti selháním v celé oblasti

Spravované prostředky HSM se nasazují do jedné oblasti Azure. Pokud se oblast stane nedostupnou, váš spravovaný HSM je také nedostupný. Existují ale přístupy, které vám pomůžou zajistit odolnost vůči výpadkům oblastí.

Replikace ve více oblastech

Managed HSM podporuje volitelnou replikaci ve více oblastech, kterou můžete použít k rozšíření spravovaného fondu HSM z jedné Azure oblasti (primární oblasti) do druhé Azure oblasti (rozšířené oblasti). Při konfiguraci této funkce:

  • Obě oblasti jsou aktivní a můžou obsluhovat žádosti.
  • Klíčové materiály, role a oprávnění se mezi oblastmi automaticky replikují.
  • Azure Traffic Manager směruje požadavky do nejbližší dostupné oblasti.
  • Úroveň kombinované SLA se zvyšuje.

Requirements

  • Podpora oblastí: Všechny oblasti, které podporují spravovaný HSM, je možné použít jako primární oblasti. Není žádná závislost na párování oblastí Azure.

    Managed HSM nepodporuje všechny oblasti jako rozšířené oblasti. Další informace najdete v tématu Podpora oblastí Azure.

  • Maximální počet oblastí: Pro maximálně dvě oblasti můžete přidat jednu rozšířenou oblast.

Cost

Replikace ve více oblastech způsobuje další fakturaci, protože rozšířená oblast spotřebovává druhý fond HSM. Další informace najdete v tématu Ceny spravovaného HSM v Azure.

Konfigurace replikace ve více oblastech

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat při konfiguraci replikace ve více oblastech, a obě oblasti jsou funkční.

  • Směrování provozu: Požadavky mohou být obslouženy ze všech oblastí. Azure Traffic Manager směruje požadavky do oblasti s nejbližší geografickou blízkostí nebo nejnižší latencí.

    Pokud pro přístup ke spravovanému HSM používáte Azure Private Link, nakonfigurujte privátní koncové body v obou oblastech pro optimální směrování během převzetí služeb při selhání. Další informace najdete v tématu Chování služby Private Link s replikací více oblastí.

  • Replikace dat: Všechny změny klíčů, definic rolí a přiřazení rolí se replikují asynchronně do rozšířené oblasti během šesti minut. Před použitím klíče v rozšířené oblasti počkejte šest minut po vytvoření nebo aktualizaci klíče.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když nakonfigurujete replikaci ve více oblastech a v jedné z oblastí repliky dojde k výpadku.

  • Detekce a odpověď: Azure Traffic Manager detekuje oblast, která není v pořádku, a směruje budoucí požadavky do oblasti, která je v pořádku. Záznamy DNS mají dobu životnosti (TTL) pět sekund, i když u klientů, kteří ukládají DNS dotazy do mezipaměti, může docházet k o něco delší době převzetí služeb při selhání.
  • Oznámení: Microsoft vás při výpadku oblasti automaticky neoznámí. Můžete ale použít Azure Service Health, abyste porozuměli celkovému stavu služby, včetně jakýchkoli selhání oblastí, a můžete nastavit upozornění služby Služba Health, která vás upozorní na problémy.
  • Aktivní požadavky: Probíhající požadavky směřující do zasažené oblasti mohou selhat a bude nutné je opakovat.

  • Očekávaná ztráta dat: Změny provedené během šesti minut před selháním oblasti nemusí být replikovány do rozšířené oblasti. Tyto změny můžou být ztraceny, pokud primární oblast není obnovitelná.

  • Očekávaný výpadek: Operace čtení i zápisu zůstanou dostupné v neporušené oblasti během převzetí služeb při selhání.

    Klientské aplikace, které jsou blízko oblasti, které nejsou v pořádku, můžou být dál směrovány do této oblasti, dokud se neaktualizují záznamy DNS, ale tato aktualizace probíhá přibližně během pěti sekund. Aby se minimalizovala doba při selhání, klienti by se měli vyhnout ukládání výsledků vyhledávání DNS do mezipaměti na dobu delší, než je TTL záznamu DNS.

  • Přesměrování: Azure Traffic Manager automaticky směruje požadavky do oblasti, která je v pořádku.

Obnovení oblasti

Když se ovlivněná oblast obnoví, spravovaný HSM automaticky obnoví operace. Azure Traffic Manager začne znovu směrovat požadavky do obou oblastí na základě blízkosti.

Testování selhání regionů

Spravovaný HSM plně spravuje směrování provozu, převzetí služeb při selhání a obnovení služeb pro selhání regionů, takže nemusíte ověřovat procesy selhání regionů ani poskytovat další vstup.

Vlastní řešení pro více regionů pro zajištění odolnosti

Pokud replikace ve více oblastech není vhodná pro vaše potřeby, můžete implementovat ruční zotavení po havárii. Tento přístup vyžaduje:

  • Doména zabezpečení zdrojového HSM.
  • Privátní klíče (alespoň číslo kvora), které šifrují doménu zabezpečení.
  • Nedávná úplná záloha HSM ze zdrojového HSM.

Postup zotavení po havárii:

  1. Vytvořte novou spravovanou instanci HSM v jiné oblasti.
  2. Aktivujte režim obnovení domény zabezpečení a nahrajte doménu zabezpečení.
  3. Vytvořte zálohu nového HSM (vyžaduje se před obnovením).
  4. Obnovte zálohu ze zdrojového HSM.

Important

Nový HSM má jiný název a identifikátor URI koncového bodu služby. Abyste mohli používat nové umístění, musíte aktualizovat konfiguraci aplikace.

Podrobné postupy zotavení po havárii najdete v tématu Zotavení po havárii spravovaného HSM.

Zálohování a obnovení

Managed HSM podporuje úplné zálohování a obnovení všech klíčů, verzí, atributů, značek a přiřazení rolí. Zálohy se ukládají do účtu Azure Storage. Pokud ji vaše oblast podporuje, doporučujeme zálohovat spravovaný HSM do účtu Azure Storage, který má povolené geograficky redundantní úložiště (GRS).

HSM šifruje zálohy pomocí kryptografických klíčů přidružených k doméně zabezpečení HSM. Zálohy můžete obnovit jenom do HSM se stejnou doménou zabezpečení.

Spravovaný HSM nepodporuje plánování záloh, ale můžete vytvořit vlastní plánovač pomocí služby, jako je Azure Functions nebo Azure Automation.

Zatímco probíhá zálohování, hsm nemusí fungovat s plnou propustností, protože některé oddíly jsou zaneprázdněné prováděním operace zálohování.

Podrobné postupy zálohování a obnovení najdete v tématu Úplné zálohování a obnovení.

Odolnost proti náhodnému odstranění

Managed HSM poskytuje dvě funkce obnovení klíčů, které brání náhodnému nebo škodlivému odstranění.

  • Obnovitelné odstranění: Odstraněné moduly HSM a klíče nejsou okamžitě trvale odstraněny. Zůstanou obnovitelné po dobu konfigurovatelného uchovávání 7 až 90 dnů (výchozí hodnota: 90 dnů). Měkké odstranění je vždy povolené a nelze jej zakázat.

    Note

    Obnovitelné odstraněné spravované prostředky HSM se budou dál účtovat, dokud se nevyprázdní.

  • Ochrana před vymazáním: Pokud je tato možnost povolená, zabrání trvalému odstranění spravovaného HSM a jeho klíčů, dokud neuplyne doba uchovávání. Ochranu před vymazáním nejde zakázat ani přepsat nikdo, včetně Microsoftu.

Důrazně doporučujeme povolit ochranu před vymazáním pro produkční prostředí. Další informace naleznete v článku Měkké odstranění a ochrana proti vymazání u spravovaného HSM.

Odolnost vůči údržbě služeb

Spravovaný HSM zpracovává údržbu služeb, včetně aktualizací firmwaru, oprav a oprav hardwaru bez zásahu zákazníka. Během údržby:

  • Služba může dočasně znepřístupnit oddíly během instalace aktualizací.
  • Během běžné údržby zůstanou k dispozici alespoň dva ze tří oddílů.
  • Klientské aplikace by měly implementovat logiku opakování pro zpracování krátkých přerušení.

Proces obnovy důvěrné služby zajišťuje, že služba během operací údržby nikdy neodhalí žádné tajné údaje.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Managed HSM poskytuje smlouvu SLA standardní dostupnosti pro nasazení v jedné oblasti. Povolení replikace ve více oblastech zvyšuje celkovou očekávanou dostupnost, protože pokud se jedna z oblastí stane nedostupnou, požadavky lze obsloužit z kterékoli z obou oblastí.