Win32 app isolation er en smart sikkerhedsfunktion, som Microsoft introducerede i Windows 11 i sidste måned, sådan fungerer det.
På sin årlige Build-konference i sidste måned annoncerede Microsoft muligheden for at køre Win32-apps isoleret på Windows 11. Virksomheden gik ikke i detaljer i sit første blogindlæg, men det fremhævede muligheden for at køre Win32 apps i et sandkassemiljø, så resten af operativsystemet er beskyttet mod potentielt skadelig software. Nu har den afsløret flere oplysninger om denne særlige evne, herunder hvordan den fungerer og passer ind i resten af sikkerhedsinfrastrukturen i Windows.
Microsofts vicepræsident for OS Security og Enterprise David Weston har skrevet en lang blogindlæg, der forklarer karakteren af Win32-app-isolering. Funktionen er endnu en sandkassesikkerhedsmulighed ligesom Windows sandkasse og Microsoft Defender Application Guard, men den er baseret på AppContainers, ikke virtualiseringsbaseret software som de to andre sikkerhedsforanstaltninger. For dem, der ikke er klar over, tjener AppContainers som en måde at kontrollere udførelsen af en proces ved at indkapsle den og sikre, at den kører på meget lave privilegie- og integritetsniveauer.
Microsoft har stærkt anbefalet at bruge Smart App Control (SAC) og Win32 app-isolering i tandem, mens du sikrer dit Windows-miljø mod upålidelige apps, der udnytter 0-dages sårbarheder. Den førstnævnte sikkerhedsmekanisme stopper angreb ved kun at installere betroede apps, mens sidstnævnte kan være det bruges til at køre apps i et isoleret og sikkert miljø for at begrænse potentiel skade og beskytte brugeren privatliv. Dette skyldes, at en Win32-app, der kører isoleret, ikke har det samme privilegieniveau som brugeren af systemet.
Teknologifirmaet Redmond har identificeret flere nøglemål for Win32-app-isolering. For det første begrænser det virkningen fra en kompromitteret app, da angribere har lavt privilegeret adgang til en del af operativsystem, og de ville være nødt til at kæde et komplekst angreb i flere trin for at bryde igennem deres sandkasse. Selvom de lykkes, giver dette også mere indsigt i deres proces, hvilket gør det meget hurtigere at implementere og levere afhjælpningspatches.
Måden dette fungerer på er, at en app først lanceres på lavt integritetsniveau gennem AppContainer, hvilket betyder at de har adgang til udvalgte Windows API'er og ikke kan udføre ondsindet kode, som kræver højere privilegier niveauer. I det næste og sidste trin håndhæves principperne for mindste privilegium ved at give en app autoriseret adgang til Windows-sikrede objekter, hvilket svarer til implementering af en Diskretionær adgangskontrolliste (DACL) på Windows.
En anden fordel ved Win32 app-isolering er reduceret udviklerindsats, da app-skabere kan udnytte Application Capability Profiler (ACP) tilgængelig på GitHub for at forstå, hvilke tilladelser de præcist har brug for. De kan aktivere ACP og køre deres app i en "indlæringstilstand" i Win32 app-isolation for at få logfiler om de yderligere funktioner, de har brug for for at køre deres software. ACP er drevet af Windows Performance Analyzer (WPA) datalags backend og Event Trace Logs (ETL'er). Oplysningerne fra logfilerne, der genereres af denne proces, kan simpelthen tilføjes til en applikations pakkemanifestfil.
Endelig sigter Win32 app-isolering på at tilbyde en problemfri brugeroplevelse. Win32 app-isolering letter dette ved at kræve, at apps bruger "isolatedWin32-promptForAccess"-kapaciteten for at bede brugeren i tilfælde af, at de har brug for adgang til deres data, såsom .NET-biblioteker og beskyttet register nøgler. Spørgsmålet skal være meningsfuldt for den bruger, fra hvem der indhentes samtykke. Når først der er givet adgang til en ressource, sker der følgende:
Når brugeren giver samtykke til en specifik fil for den isolerede applikation, har den isolerede applikation grænseflader med Windows Mægler filsystem (BFS) og giver adgang til filerne via en minifilterdriver. BFS åbner blot filen og fungerer som grænsefladen mellem den isolerede applikation og BFS.
Fil- og registrerings-virtualisering hjælper med at sikre, at apps fortsætter med at fungere, mens de ikke opdaterer basisfilen eller registreringsdatabasen. Dette minimerer også enhver brugeroplevelsesfriktion, samtidig med at applikationskompatibiliteten bevares. Beskyttede navnerum er oprettet for kun at tillade adgang til appen og kræver ikke brugerens samtykke. For eksempel kan der gives adgang til en mappe, der har en egenskab, som kun kendes af Win32-appen og kræves for app-kompatibilitet.
Microsoft har understreget, at for at have funktionsparitet mellem isolerede og ikke-isolerede Win32 apps, førstnævnte kan interagere med filsystemet og andre Windows API'er ved at udnytte Windows BFS. Desuden sikrer poster i applikationens manifest også, at appen sikkert kan interagere med Windows-elementer som shell-meddelelser og ikoner i systembakken. Du kan læs mere om initiativet på GitHub her.