Skydda Windows-containrar

Gäller för: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Containrar har sin minskade bildstorlek tack vare att de kan förlita sig på värdsystemet för att ge begränsad åtkomst till olika resurser. Om containern vet att värden kommer att kunna tillhandahålla de funktioner som behövs för att utföra en specifik uppsättning åtgärder behöver containern inte inkludera relevant programvara i sin basavbildning. Omfattningen av resursdelning som sker kan dock ha en betydande inverkan på både containerns prestanda och säkerhet. Om för många resurser delas kan programmet lika gärna köras som en process på värddatorn. Om resurserna delas för lite blir containern oskiljaktig från en virtuell dator. Båda konfigurationerna gäller för många scenarier, men de flesta som använder containrar väljer vanligtvis något i mitten.

Säkerheten för en Windows-container härleds från graden av delning som sker med dess värd. Säkerhetsgränsen för en container utgörs av de isoleringsmekanismer som skiljer containern från värden. Viktigast av allt är att dessa isoleringsmekanismer definierar vilka processer i containern som kan interagera med värden. Om utformningen av en container tillåter att en förhöjd process (administratör) interagerar med värden, anser Microsoft inte att den här containern har en robust säkerhetsgräns.

Windows Server-containrar jämfört med Linux-containrar

Processisolerade Windows Server-containrar och Linux-containrar delar liknande grad av isolering. För båda containertyperna måste utvecklaren anta att alla attacker som kan utföras via en förhöjd process på värdmaskinen också kan utföras via en förhöjd process i containern. Båda fungerar via de primitiva funktioner som erbjuds av respektive värdkärnor. Containeravbildningarna skapas och innehåller binärfiler i användarläge som utnyttjar de API:er som tillhandahålls av värdkärnan. Värdkärnan tillhandahåller samma resursisolerings- och hanteringsfunktioner för varje container som körs i användarutrymmet. Om kerneln har komprometterats, så är det även varje container som delar den kerneln.

Den grundläggande designen av Linux- och Windows-servercontainrar handlar om säkerhet för flexibilitet. Windows Server- och Linux-containrar bygger på de primitiva komponenter som tillhandahålls av operativsystemet. Detta ger flexibiliteten att dela resurser och namnområden mellan containrar, men det ger ytterligare komplexitet som öppnar dörren för exploatering. Allmänt sagt vi inte anser att kerneln är en tillräcklig säkerhetsgräns för fientliga arbetsbelastningar med flera klientorganisationer.

Kernelisolering med hypervisorisolerade containrar

Hypervisorisolerade containrar ger en högre grad av isolering än processisolerade Windows Server- eller Linux-containrar och anses vara robusta säkerhetsgränser. Hypervisor-isolerade containrar består av en Windows Server-container omsluten i en ultralätt virtuell dator och körs sedan tillsammans med värdoperativsystemet via Microsofts hypervisor-program. Hypervisor-programmet tillhandahåller isolering på maskinvarunivå som innehåller en mycket robust säkerhetsgräns mellan värden och andra containrar. Även om en exploatering skulle fly från Windows Server-containern skulle den finnas i den hypervisorisolerade virtuella datorn.

Varken Windows Server-containrar eller Linux-containrar tillhandahåller vad Microsoft anser vara en robust säkerhetsgräns och bör inte användas i fientliga scenarier med flera klientorganisationer. En container måste vara begränsad till en dedikerad virtuell maskin för att förhindra att en skadlig containerprocess interagerar med värden eller andra hyresgäster. Hypervisor-isolering möjliggör denna grad av separation samtidigt som det ger flera prestandavinster jämfört med traditionella virtuella datorer. Därför rekommenderar vi starkt att hypervisor-isolerade containrar i fientliga multi-klient scenarier bör vara det självklara valet.

Servicevillkor för containersäkerhet

Microsoft har åtagit sig att korrigera alla kryphål och undantag som bryter den etablerade isoleringsgränsen för alla Windows-containertyper. Men endast sårbarheter som bryter en säkerhetsgräns hanteras via MsRC-processen (Microsoft Security Response Center). Endast hypervisorisolerade containrar ger en säkerhetsgräns, och processisolerade containrar har inte det. Det enda sättet att generera en bugg för en processisolerad containerflykt är om en process som inte är administratör kan få åtkomst till värden. Om en exploatering använder en administratörsprocess för att undkomma containern anser Microsoft att den är en icke-säkerhetsfel och kommer att korrigera den enligt den normala serviceprocessen. Om en exploatering använder en icke-administratörsprocess för att utföra en åtgärd som bryter mot en säkerhetsgräns kommer Microsoft att undersöka den enligt de etablerade kriterierna för säkerhetsservice.

Vad gör en multitenant-arbetsbelastning problematisk?

Miljöer med flera hyresgäster finns när flera arbetslaster körs på delad infrastruktur och resurser. Om det inte går att lita på en eller flera arbetsbelastningar som körs på en infrastruktur, anses multi-tenant-miljön vara fientlig. Både Windows Server- och Linux-containrar delar värdkärnan, så alla exploateringar som utförs på en enda container kan påverka alla andra arbetsbelastningar som körs på den delade infrastrukturen.

Du kan vidta åtgärder för att minska risken för att en exploatering inträffar, till exempel genom att använda poddsäkerhetsprinciper, AppArmor och rollbaserad åtkomstkontroll (RBAC), men de ger inte garanterat skydd mot en angripare. Vi rekommenderar att du följer våra metodtips för klusterisolering för alla scenarion med flera klientorganisationer.

När du ska använda ContainerAdmin- och ContainerUser-användarkonton

Windows Server-containrar erbjuder två standardanvändarkonton, ContainerUser och ContainerAdministrator, var och en med sitt eget specifika syfte. Med ContainerAdministrator-kontot kan du använda containern för administrativa ändamål: installera tjänster och programvara (till exempel aktivera IIS i en container), göra konfigurationsändringar och skapa nya konton. Dessa uppgifter är viktiga för ett antal IT-scenarier som kan köras i anpassade, lokala distributionsmiljöer.

ContainerUser-kontot finns för alla andra scenarier där administratörsbehörigheter i Windows inte behövs. I Kubernetes om användaren till exempel är ContainerAdministrator och värdvolumer tillåts monteras i podden kan användaren montera mappen .ssh och lägga till en offentlig nyckel. Som ContainerUser skulle det här exemplet inte vara möjligt. Det är ett begränsat användarkonto som utformats enbart för applikationer som inte behöver interagera med värden. Vi rekommenderar starkt att, när du distribuerar en Windows-servercontainer till en miljö med flera klientorganisationer, ditt program körs via ContainerUser-kontot. I en miljö med flera klientorganisationer är det alltid bäst att följa principen om lägsta behörighet, för om en angripare komprometterar din arbetsbelastning har den delade resursen och närliggande arbetsbelastningar också en mindre sannolikhet att påverkas. Om du kör containrar med ContainerUser-kontot minskar risken för att miljön komprometteras som helhet. Detta ger dock fortfarande ingen robust säkerhetsgräns, så när säkerheten är ett problem bör du använda hypervisorisolerade containrar.

Om du vill ändra användarkontot kan du använda USER-instruktionen i dockerfile:

USER ContainerUser

Du kan också skapa en ny användare:

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

Windows-tjänster

Med Microsoft Windows-tjänster, som tidigare kallades NT-tjänster, kan du skapa tidskrävande körbara program som körs i sina egna Windows-sessioner. Dessa tjänster kan startas automatiskt när operativsystemet startar, kan pausas och startas om och inte visa något användargränssnitt. Du kan också köra tjänster i säkerhetskontexten för ett specifikt användarkonto som skiljer sig från den inloggade användaren eller standarddatorkontot.

När du containeriserar och skyddar en arbetsbelastning som körs som en Windows-tjänst finns det några ytterligare saker att tänka på. För det första kommer containerns ENTRYPOINT inte att vara arbetsbelastningen eftersom tjänsten körs som en bakgrundsprocess, vanligtvis är ENTRYPOINT ett verktyg som tjänstövervakaren) eller loggövervakaren). För det andra konfigureras det säkerhetskonto som arbetsbelastningen körs under av tjänsten, inte av ANVÄNDAR-direktivet i dockerfile. Du kan kontrollera vilket konto tjänsten kommer att köras under genom att köra Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Till exempel, när du värdar ett IIS-webbprogram med ASP.NET-bilden (Microsoft Artifact Registry) är containerns ENTRYPOINT"C:\\ServiceMonitor.exe", "w3svc". Det här verktyget kan användas för att konfigurera IIS-tjänsten och övervakar sedan tjänsten för att säkerställa att den fortfarande körs och avslutas, vilket stoppar containern, om tjänsten av någon anledning stoppas. Som standard körs IIS-tjänsten och därmed webbprogrammet under ett konto med låg behörighet i containern, men verktyget för tjänstövervakning kräver administratörsbehörighet för att konfigurera och övervaka tjänsten.