Integrita kódu platformy
Významnou výzvou při provozování složitého systému, jako je Microsoft Azure, je zajistit, aby v systému běžel jenom autorizovaný software. Neautorizovaný software představuje pro každou firmu několik rizik:
- Bezpečnostní rizika, jako jsou vyhrazené nástroje pro útoky, vlastní malware a software třetích stran se známými ohroženími zabezpečení
- Rizika dodržování předpisů, pokud se schválený proces správy změn nepoužívá k uvedení nového softwaru
- Riziko kvality z externě vyvinutého softwaru, který nemusí splňovat provozní požadavky podniku
V Azure se potýkáme se stejným problémem a se značnou složitostí. Máme tisíce serverů se softwarem vyvinutým a udržovaným tisíci inženýrů. To představuje rozsáhlou plochu útoku, kterou nelze spravovat pouze prostřednictvím obchodních procesů.
Přidání autorizační brány
Azure používá bohatý technický proces, který implementuje brány týkající se zabezpečení, dodržování předpisů a kvality softwaru, který nasazujeme. Tento proces zahrnuje řízení přístupu ke zdrojovému kódu, provádění kontrol partnerských kódů, provádění statických analýz ohrožení zabezpečení, sledování životního cyklu vývoje zabezpečení (SDL) od Microsoftu a testování funkčnosti a kvality. Musíme zaručit, že software, který nasadíme, prošel tímto procesem. Integrita kódu nám pomáhá dosáhnout této záruky.
Integrita kódu jako autorizační brána
Integrita kódu je služba na úrovni jádra, která byla k dispozici od Windows Server 2016. Integrita kódu může použít zásadu striktního řízení spouštění při každém načtení ovladače nebo dynamicky propojené knihovny (DLL), spuštění spustitelného binárního souboru nebo spuštění skriptu. Podobné systémy, jako je DM-Verity, existují i pro Linux. Zásady integrity kódu se skládají ze sady indikátorů autorizace, buď certifikátů pro podepisování kódu, nebo hodnot hash souborů SHA256 , které jádro před načtením nebo spuštěním binárního souboru nebo skriptu odpovídá.
Integrita kódu umožňuje správci systému definovat zásadu, která autorizuje pouze binární soubory a skripty podepsané konkrétními certifikáty nebo odpovídající zadaným hodnotám hash SHA256. Jádro tuto zásadu vynucuje tak, že blokuje provádění všeho, co nesplňuje nastavené zásady.
Zásady integrity kódu se týkají toho, že pokud nejsou zcela správné, můžou blokovat kritický software v produkčním prostředí a způsobit výpadek. Vzhledem k této obavě se můžete ptát, proč nestačí používat monitorování zabezpečení k detekci spuštění neoprávněného softwaru. Integrita kódu má režim auditu, který místo toho, aby bránil spuštění, může při spuštění neautorizovaného softwaru upozorňovat. Upozorňování může samozřejmě přidat velkou hodnotu při řešení rizik dodržování předpisů, ale u bezpečnostních rizik, jako je ransomware nebo vlastní malware, může zpoždění odezvy i o několik sekund představovat rozdíl mezi ochranou a nežádoucím uživatelem, který získá trvalé oporu ve vaší flotile. V Azure jsme významně investovali do řízení rizika, že integrita kódu přispívá k ovlivnění výpadku zákazníka.
Proces sestavení
Jak je popsáno výše, buildovací systém Azure má bohatou sadu testů, které zajišťují, že změny softwaru jsou zabezpečené a dodržují předpisy. Jakmile sestavení pokračuje ověřováním, systém sestavení ho podepíše pomocí certifikátu sestavení Azure. Certifikát označuje, že sestavení prošlo celým procesem správy změn. Poslední test, kterým sestavení prochází, se nazývá Ověření podpisu kódu (CSV). Csv potvrzuje, že nově vytvořené binární soubory splňují zásady integrity kódu před nasazením do produkčního prostředí. To nám dává vysokou jistotu, že kvůli nesprávně podepsaným binárním souborům nedojde k výpadku zákazníka. Pokud csv najde problém, sestavení se přeruší a příslušní technici budou stránkovat, aby problém prošetřili a opravili.
Bezpečnost během nasazování
I když provádíme csv pro každé sestavení, stále existuje možnost, že nějaká změna nebo nekonzistence v produkčním prostředí může způsobit výpadek související s integritou kódu. Počítač může například používat starou verzi zásad integrity kódu nebo může být ve špatném stavu, který vytváří falešně pozitivní výsledky v integritě kódu. (Na úrovni Azure jsme viděli všechno.) Proto musíme i nadále chránit před rizikem výpadku během nasazení.
Všechny změny v Azure se vyžadují k nasazení v řadě fází. První z nich jsou interní testovací instance Azure. Další fáze slouží pouze k poskytování dalších produktových týmů Microsoftu. Poslední fáze slouží zákazníkům třetích stran. Když se změna nasadí, postupně se přesune do každé z těchto fází a pozastaví se, aby se změřil stav fáze. Pokud se zjistí, že změna nemá žádný negativní dopad, přesune se do další fáze. Pokud provedeme špatnou změnu zásad integrity kódu, během tohoto fázovaného nasazení se tato změna zjistí a vrátí zpět.
Reakce na incidenty
I s touto vrstvenou ochranou je stále možné, že některý server v vozovém parku může blokovat správně autorizovaný software a způsobit problém zákazníka, který je jedním z nejhorších scénářů. Naší poslední vrstvou obrany je lidské vyšetřování. Pokaždé, když integrita kódu zablokuje soubor, vyvolá upozornění, aby je mohli pracovníci na volání prozkoumat. Výstraha nám umožňuje zahájit šetření zabezpečení a intervenovat bez ohledu na to, jestli je problém indikátorem skutečného útoku, falešně pozitivní situace nebo jiné situace ovlivňující zákazníka. Tím se minimalizuje doba potřebná ke zmírnění problémů souvisejících s integritou kódu.
Další kroky
Zjistěte, jak Windows 10 používá konfigurovatelnou integritu kódu.
Další informace o tom, co děláme pro zajištění integrity a zabezpečení platformy, najdete tady: