Zabezpečení kontejnerů Windows

Platí pro: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Kontejnery přispívají ke snížení velikosti image tím, že se mohou spolehnout na hostitele, který zajišťuje omezený přístup k různým prostředkům. Pokud kontejner ví, že hostitel bude moct poskytovat funkce potřebné k provedení konkrétní sady akcí, nemusí kontejner do své základní image zahrnout příslušný software. Rozsah sdílení prostředků, ke kterému ale dochází, může mít významný dopad na výkon i zabezpečení kontejneru. Pokud je sdíleno příliš mnoho prostředků, může aplikace stejně dobře běžet jako proces na hostiteli. Pokud jsou prostředky sdíleny příliš málo, kontejner se stane nerozlišitelným od virtuálního počítače. Obě konfigurace platí pro mnoho scénářů, ale většina lidí, kteří používají kontejnery, se obecně rozhodnou něco uprostřed.

Zabezpečení kontejneru Windows je odvozeno od stupně sdílení, ke kterému dochází s jeho hostitelem. Hranice zabezpečení kontejneru tvoří mechanismy izolace, které oddělují kontejner od hostitele. Nejdůležitější je, že tyto mechanismy izolace definují, které procesy v kontejneru mohou komunikovat s hostitelem. Pokud návrh kontejneru umožňuje interakci s hostitelem procesem se zvýšenými oprávněními (správce), Microsoft tento kontejner nepovažuje za robustní hranici zabezpečení.

Kontejnery Windows Serveru vs. linuxové kontejnery

Kontejnery Windows Serveru izolované procesem a linuxové kontejnery sdílejí podobné stupně izolace. U obou typů kontejnerů musí vývojář předpokládat jakýkoli útok, který je možné provést prostřednictvím procesu se zvýšenými oprávněními na hostiteli, lze také provést prostřednictvím procesu se zvýšenými oprávněními v kontejneru. Oba fungují prostřednictvím primitivních funkcí nabízených příslušnými jádry hostitele. Obrazy kontejnerů jsou sestaveny tak, aby obsahovaly binární soubory v uživatelském režimu, které využívají API rozhraní poskytnuté jádrem hostitelského systému. Jádro hostitele poskytuje stejné možnosti izolace prostředků a správy pro každý kontejner spuštěný v uživatelském prostoru. Pokud dojde k ohrožení zabezpečení jádra, znamená to, že každý kontejner sdílí toto jádro.

Základní návrh kontejnerů Linuxu a Windows Serveru obchoduje se zabezpečením pro flexibilitu. Kontejnery Windows Serveru a Linuxu jsou založené na primitivních součástech poskytovaných operačním systémem. Díky tomu získáte flexibilitu pro sdílení prostředků a oborů názvů mezi kontejnery, ale tím se zvyšuje složitost, která otevírá dveře ke zneužití. Obecně řečeno, nepovažujeme jádro za dostatečnou hranici zabezpečení pro zatěžující víceúčelové úlohy.

Izolace jádra s kontejnery izolovanými hypervisorem

Kontejnery izolované hypervisorem poskytují vyšší stupeň izolace než kontejnery Windows Serveru nebo Linuxu, které jsou považovány za robustní hranice zabezpečení. Izolované kontejnery Hypervisoru se skládají z kontejneru Windows Serveru zabaleného ve virtuálním počítači ultralight a pak běží společně s hostitelským operačním systémem prostřednictvím hypervisoru Microsoftu. Hypervisor poskytuje izolaci na úrovni hardwaru, která zahrnuje vysoce robustní hranici zabezpečení mezi hostitelem a dalšími kontejnery. I kdyby exploit unikl z kontejneru Windows Serveru, byl by obsažen v hypervizorem izolovaném virtuálním počítači.

Kontejnery Windows Serveru ani linuxové kontejnery neposkytují, co Microsoft považuje za robustní hranici zabezpečení a neměl by se používat v nepřátelských scénářích s více tenanty. Kontejner musí být omezen na vyhrazený virtuální počítač, aby se zabránilo neoprávněnému procesu kontejneru v interakci s hostitelem nebo jinými tenanty. Izolace hypervisoru umožňuje tento stupeň oddělení a zároveň nabízí několik zvýšení výkonu oproti tradičním virtuálním počítačům. Proto je důrazně doporučeno, aby v nepřátelských scénářích s více tenanty měly být kontejnery izolované hypervisorem upřednostňovanou volbou.

Kritéria údržby zabezpečení kontejneru

Společnost Microsoft se zavazuje opravovat všechna zneužití a úniky, které narušují zavedenou hranici izolace libovolného typu kontejnerů Windows. Prostřednictvím procesu Microsoft Security Response Center (MSRC) se však obsluhují pouze zneužití, které přeruší hranice zabezpečení. Hranici zabezpečení poskytují pouze kontejnery izolované hypervisorem, zatímco kontejnery izolované procesem ji neposkytují. Jediný způsob, jak vygenerovat chybu pro únik z procesu izolovaného kontejneru, je v případě, že neadministrátorský proces může získat přístup k hostiteli. Pokud zneužití používá proces správce k úniku kontejneru, Microsoft ho považuje za chybu nesouvisenou se zabezpečením a opraví ho podle normálního procesu údržby. Pokud zneužití používá proces bez oprávnění správce k provedení akce, která porušuje hranice zabezpečení, microsoft ho prošetří podle zavedených kritérií údržby zabezpečení.

Co znesměrňuje úlohy s více tenanty?

Prostředí s více tenanty existují v případě, že na sdílené infrastruktuře a prostředcích pracuje více úloh. Pokud jednu nebo více úloh spuštěných v infrastruktuře nelze považovat za důvěryhodné, považuje se prostředí s více tenanty za nepřátelské. Kontejnery Windows Serveru i Linuxu sdílejí jádro hostitele, takže jakékoli zneužití prováděné v jednom kontejneru může mít vliv na všechny ostatní úlohy spuštěné ve sdílené infrastruktuře.

Můžete provést kroky ke snížení pravděpodobnosti, že dojde ke zneužití, například použitím zásad zabezpečení podů, AppArmor a řízením přístupu na základě role (RBAC), ale tyto metody nezaručují ochranu před útočníkem. Doporučujeme dodržovat naše osvědčené postupy pro izolaci clusteru pro všechny scénáře s více tenanty.

Kdy použít uživatelské účty ContainerAdmin a ContainerUser

Kontejnery Windows Serveru nabízejí dva výchozí uživatelské účty, ContainerUser a ContainerAdministrator, z nichž každý má svůj vlastní konkrétní účel. Účet ContainerAdministrator umožňuje používat kontejner pro účely správy: instalace služeb a softwaru (například povolení služby IIS v rámci kontejneru), provádění změn konfigurace a vytváření nových účtů. Tyto úlohy jsou důležité pro řadu scénářů IT, které můžou běžet ve vlastních místních prostředích nasazení.

Účet ContainerUser existuje pro všechny ostatní scénáře, ve kterých nejsou potřebná oprávnění správce ve Windows. Například v Kubernetes, pokud je uživatel ve skupině správce kontejnerů a je povoleno připojit hostované svazky k podu, může připojit složku .ssh a přidat veřejný klíč. Jako ContainerUser by tento příklad nebyl možný. Jedná se o omezený uživatelský účet navržený čistě pro aplikace, které nemusí komunikovat s hostitelem. Důrazně doporučujeme, aby při nasazování kontejneru Windows serveru do libovolného prostředí s více tenanty vaše aplikace běžela prostřednictvím účtu ContainerUser. V prostředí s více tenanty je vždy nejlepší dodržovat princip nejnižších oprávnění, protože pokud útočník kompromituje vaši úlohu, pak sdílený prostředek a sousední úlohy mají také menší šanci být ovlivněny. Spouštění kontejnerů s účtem ContainerUser výrazně snižuje riziko ohrožení prostředí jako celku. Přesto to ale neposkytuje robustní hranici zabezpečení, takže pokud je zabezpečení problém, měli byste použít kontejnery izolované hypervisorem.

Pokud chcete změnit uživatelský účet, můžete použít příkaz USER ve vašem souboru dockerfile:

USER ContainerUser

Případně můžete vytvořit nového uživatele:

RUN net user username ‘<password>’ /ADD
USER username

Služby pro Windows

Služby systému Microsoft Windows, dříve označované jako služby NT, umožňují vytvářet dlouhotrvající spustitelné aplikace, které běží ve vlastních relacích Systému Windows. Tyto služby je možné spustit automaticky při spuštění operačního systému, pozastavit a restartovat a nezobrazí žádné uživatelské rozhraní. Můžete také spouštět služby v kontextu zabezpečení konkrétního uživatelského účtu, který se liší od přihlášeného uživatele nebo výchozího účtu počítače.

Při kontejnerizaci a zabezpečení úlohy, která běží jako služba Windows, je potřeba vzít v úvahu několik dalších aspektů. Za prvé, ENTRYPOINT kontejneru nebude pracovní zátěží, protože služba běží jako proces na pozadí; obvykle bude ENTRYPOINT nástrojem, jako je například monitor služby) nebo monitor protokolů). Za druhé, účet zabezpečení, pod kterým úloha pracuje, bude nakonfigurován službou, nikoli direktivou USER v souboru dockerfile. Spuštěním Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartNamemůžete zkontrolovat, pod jakým účtem bude služba spuštěna.

Například při hostování webové aplikace IIS pomocí ASP.NET (Microsoft Artifact Registry) image ENTRYPOINT kontejneru je "C:\\ServiceMonitor.exe", "w3svc". Tento nástroj lze použít ke konfiguraci služby IIS a následnému monitorování služby, aby se zajistilo, že zůstane spuštěný a ukončený, čímž zastaví kontejner, pokud se služba z nějakého důvodu zastaví. Ve výchozím nastavení služba IIS a webová aplikace běží pod účtem s nízkými oprávněními v rámci kontejneru, ale nástroj pro monitorování služeb vyžaduje oprávnění správce ke konfiguraci a monitorování služby.