Integrita kódu platformy
Důležitým problémem 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 jakoukoli 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ů v případě, že 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 čelíme stejné výzvě a při značné složitosti. Máme tisíce serverů, na kterých běží software vyvinutý a udržovaný tisíci inženýrů. To představuje velký prostor pro útoky, který nelze spravovat prostřednictvím samotných obchodních procesů.
Přidání autorizační brány
Azure využívá bohatý technický proces, který implementuje brány na zabezpečení, dodržování předpisů a kvalitu 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 SDL (Security Development Lifecycle) společnosti Microsoft a provádění funkčního a kvalitního testování. 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 dostupná od Windows Serveru 2016. Integrita kódu může použít striktní zásady řízení provádě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, například DM-Verity, existují pro Linux. Zásada integrity kódu se skládá ze sady indikátorů autorizace, buď podpisových certifikátů kódu, nebo hodnot hash souborů SHA256 , které jádro odpovídá před načtením nebo spuštěním binárního souboru nebo skriptu.
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í zadaným hodnotám hash SHA256. Jádro vynucuje tuto zásadu tím, že blokuje spuštění všeho, co nesplňuje nastavené zásady.
Problém se zásadami integrity kódu spočívá v tom, že pokud zásada není úplně správná, může blokovat kritický software v produkčním prostředí a způsobit výpadek. Vzhledem k tomuto problému se můžete zeptat, proč není dostatečné používat monitorování zabezpečení ke zjištění, kdy byl spuštěn neautorizovaný software. Integrita kódu má režim auditu, který může místo zabránění spuštění výstrahovat při spuštění neautorizovaného softwaru. Upozorňování může jistě při řešení rizik dodržování předpisů přidat velkou hodnotu, ale v případě bezpečnostních rizik, jako je ransomware nebo vlastní malware, může prodleva odezvy dokonce o několik sekund představovat rozdíl mezi ochranou a nežádoucí osoba, která ve vašem vozovém parku získá trvalou oporu. V Azure jsme významně investovali do správy jakéhokoli rizika integrity kódu, která přispívá k výpadku zákazníka.
Proces sestavení
Jak je popsáno výše, systém sestavení Azure má bohatou sadu testů, aby se zajistilo, že změny softwaru jsou zabezpečené a vyhovující. Jakmile sestavení projde ověření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). Sdílený svazek clusteru 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 nezpůsobíme výpadek zákazníka kvůli nesprávně podepsaným binárním souborům. Pokud sdílený svazek clusteru najde problém, zalomí se sestavení a příslušní technici se na stránce prošetří a opraví problém.
Bezpečnost během nasazování
I když pro každé sestavení provádíme sdílený svazek clusteru, stále existuje šance, že dojde k nějaké změně nebo nekonzistence v produkčním prostředí, může dojít k výpadku souvisejícímu 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. (Ve velkém měřítku Azure jsme všechno viděli.) Proto musíme pokračovat v ochraně před rizikem výpadku během nasazování.
Všechny změny v Azure se vyžadují k nasazení prostřednictvím řady fází. První z nich je 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. Při nasazení změny se postupně přesune do každé z těchto fází a pozastaví se, aby se změřila 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, zjistí se tato změna během tohoto fázovaného nasazení a vrátí se zpět.
Reakce na incidenty
I při této vrstvené ochraně 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, což je jeden z našich nejhorších scénářů. Naší poslední vrstvou obrany je lidské vyšetřování. Pokaždé, když integrita kódu zablokuje soubor, vyvolá výstrahu, která inženýři na volání prošetří. Výstraha nám umožňuje zahájit šetření zabezpečení a intervenovat, jestli je problém indikátorem skutečného útoku, falešně pozitivní nebo jiné situace, která má dopad na zákazníka. Tím se minimalizuje doba potřebnou ke zmírnění problémů souvisejících s integritou kódu.
Další kroky
Další informace o tom, co děláme pro zajištění integrity a zabezpečení platformy, najdete tady: