Obnova po havárii během několika minut s protokolováním HSM Write-Behind Log

Jak zkrátit dobu obnovy po havárii: Naše cesta v Solutii

Existuje oblíbené rčení: Každá vteřina se počítá.

V cloud compute byznysu to pro nás v Solutii opravdu je: Každá mikrosekunda se počítá.

S touto mantrou vždy na mysli, pracovali jsme na řadě kritických projektů. Zkoumali jsme chaotický svět jader operačních systémů, rychle rozmotávali cesty volání ovladačů, abychom našli jednořádkové řešení pro složité soubojové podmínky. Také jsme prosazovali hyperškálovatelný upgrade s nulovými prostoji, kde byla hlavním problémem hrubá rychlost. Naší prací je zlepšování načasování.

Výzva KMS: Zkrácení doby obnovy

Když jsme se připojili k týmu, který spravuje Key Management Service (KMS), byli jsme požádáni, abychom znovu uvedli do praxe svou známou mantru: Zkrátit dobu obnovy po havárii. Jako služba úrovně 0 stojí KMS u kořene bezpečnostního řetězce. Je to rozsáhlá síť distribuovaných systémů, které řídí všechny šifrovací klíče používané k ochraně podnikových dat. Takže… v sázce je hodně a vzájemných závislostí je mnoho – žádný tlak!

Díky provozu služby pod živou palbou (půlnoční stránky, kaskádové chyby a tak dále) jsme byli schopni objevit režimy selhání, které se v učebnicích nenacházejí. Tyto objevy nás přiměly rozebrat naši replikační vrstvu a zapojit nový kanál snapshotů, aniž bychom ohrozili náš standard latence pod $-10\text{ ms}$, a integrovali jsme logiku rychlého přepnutí po selhání.

Tato nová instalace zkrátila dobu obnovy po havárii z několika dnů na pouhých patnáct minut.

Tento blog podrobně popisuje práci na snapshotech, která nám i našim zákazníkům ušetřila značné množství času. Probereme okrajové případy, kompromisy a opravy, které nám umožnily obnovit flotilu systémů během několika minut.

Základy KMS a bezpečnostní model HSM

Takže, co je KMS?

Každá cloudová úloha závisí na šifrování a šifrování závisí na klíčích. KMS je služba, která tyto klíče chrání před nebezpečím.

Kde jsou klíče?

Uvnitř hardwarových bezpečnostních modulů (HSM) – hardwarové „trezory“, které generují a ukládají klíče a nedovolí úniku bitů prostého textu.

Proč ten extra hardware?

Moduly HSM splňují vládní standardy, jako je FIPS 140-2. Jsou skvělé z hlediska zabezpečení, ale jsou malé, drahé a trochu náročné: pokud jeden odpojíte v nesprávnou chvíli, sám se vymaže.

Co znamená „Úroveň 0“?

Mnoho dalších služeb (Block Storage, Kubernetes, Object Storage atd.) šifruje svá data pomocí klíčů držených KMS. Pokud KMS selže, nadřazený stack má špatný den – takže musíme dosáhnout velmi vysokých laťek pro dostupnost a latenci.

Zábavné části

Protože se KMS nemůže spoléhat na služby vyšší úrovně, museli jsme si vytvořit vlastní řešení:

• Replikace napříč uzly
• Protokoly pro zápis na pozadí (Write-Behind Log)
• Snímky a rychlé obnovení
• Ukládání do mezipaměti, které nikdy neuniká klíčům

Jedním záludným problémem byly asynchronní snapshoty HSM. Obnova dřívějších verzí po selhání trvala hodiny. Po přehodnocení jsme to zkrátili na minuty.

Bezpečnostní model HSM (a proč je důležitý)

Model vrstveného vlastnictví umožňuje replikovat a obnovovat klíče napříč zařízeními (a datovými centry), aniž by se snižovala bezpečnostní úroveň pro zákaznická data.

Na obrázku vidíte, jak probíhá vrstvené vlastnictví – klíč lze rozbalit pouze na kartě, kde se vlastnictví dodavatele a adaptéru přesně shoduje, a každá oblast používá jinou sadu certifikátů adaptéru, což brání klíčům v překračování hranic oblasti.

Proč používáme Write-Behind Log (WBL)

Většina databázových a úložných systémů se spoléhá na protokol Write-Ahead Log (WAL): nejprve se změna zaznamená a poté se použije v hlavním úložišti. My to obracíme a používáme protokol Write-Behind Log (WBL) – a důvodem je bezpečnost.

WAL vs. WBL ve světě HSM

• WAL $\to$ „nejprve zaloguj, pak piš.“ Funguje skvěle, když systém sám vidí data v prostém textu.
• KMS $\to$ klíče se vytvářejí uvnitř HSM a nikdy je nenechávají nešifrované. HSM musí dokončit zápis (vygenerovat klíč) předtím, než lze cokoli zaznamenat ven. To nás posouvá do modelu WBL – „nejprve zapsat, pak zaznamenat“.

Protože objekt blob je již zašifrovaný, když narazí na WBL, protokol nikdy neobsahuje klíč v prostém textu. Hranice zabezpečení zůstává nedotčena. WBL je navrženo tak, aby KMS splňovalo přísné pravidlo „klíče nikdy nenechávají HSM nechráněné“ a zároveň nám poskytovalo auditovatelný a opakovaně přehrávatelný protokol pro odolnost a obnovu.

WBL také plní dva úkoly:

1. Replikuje konfigurace oddílů, takže každý HSM v clusteru zná stejné „rozložení“.
2. Ukládá zašifrované objekty blob klíčů a metadata pro přehrání a obnovení.

Díky řetězeným kontrolním součtům a HMAC na klíčových blobech je protokol neměnný a ověřitelný – žádné tiché poškození, žádné nepovšimnuté úpravy.

Problém se souběžností a naše řešení: Postupné snímky

Nejprve zkuste snímek přímo z HSM

Náš první postup zálohování se ukázal být nespolehlivý kvůli souběžnosti. Představte si vytvoření klíče, které se spustí během vytváření snapshotu:

T0 node-1: start snapshot T1 node-2: create-key T2 node-1: HSM dump done T3 node-2: quorum commit

Cluster nyní má snímek, který neví o nově vytvořeném klíči na uzlu 2. Náš rychlý nápad, hash-and-vote, často selhával v rušné oblasti. Snapshoty mohly selhávat celé dny a jakákoli obnova znamenala přehrání celého WBL od posledního dobrého snapshotu – hodiny nebo dny fluktuace.

Nová strategie: Postupné snímky s WBL

Potřebovali jsme způsob, jak zachytit konzistentní pohled, aniž bychom blokovali vytváření klíčů nebo se spoléhali na jednomyslné hashe. Přesunuli jsme logiku snímků do samotného WBL.

Místo globálního zmrazení clusteru každý uzel průběžně komprimuje svůj lokální WBL a vytváří indexovaný soubor klíč-hodnota. Tento soubor reprezentuje jeho zobrazení až do aktuálního maxLSN_node.

Kompakce na uzel:

• Starší záznamy pro stejný klíč jsou odstraněny.
• Logika zaručuje, že snímek s nejvyšším LSN (maxLSN_cluster) vždy zvítězí.

Protože WBL je kompletně seřazený, snímek s vyšším LSN je vždy kompletní a aktuální nadmnožinou snímku s nižším LSN. To je stejná vlastnost, jakou používají logaritmicky strukturovaná úložiště, jako je Kafka nebo RocksDB, k bezpečnému odstranění starých segmentů.

Vrstvená obnova

Tato volba nám poskytuje tři vrstvy obnovy, protože každý uzel si uchovává vlastní zhuštěný snímek:

Co z toho máme a závěr

Přechod na snapshoty protokolů s funkcí Write-Behind Log není jen o zaškrtnutí políčka pro odolnost, ale zásadně přepisuje náš postup pro obnovu dat.

• Žádná globální pauza: Uzly během zhušťování nadále obsluhují generované klíče.
• Konzistentní sémantika mazání: Náhrobky zajišťují, že smazané klíče zmizí ze všech snímků.
• Zkrácení doby obnovy: Dny přehrávání protokolů se zkrátily na minuty a zmenšila se velikost snapshotů 5krát.

Pro zákazníky to znamená rychlejší přepnutí na další služby a neochvějnou jistotu, že jejich nejcitlivější kryptografický materiál zůstane chráněn, i když dojde k nečekaným událostem.

Jsme připraveni na další vrstvu? Ve 2. části se podíváme na vícevrstvé kontroly integrity a šifrování založené na TPM, které tyto snímky chrání před všemi problémy, od úniku dat až po velké výpadky. Zůstaňte s námi!