Win32 app-isolering er en kjekk sikkerhetsfunksjon som Microsoft introduserte i Windows 11 forrige måned, slik fungerer det.
På sin årlige Build-konferanse forrige måned kunngjorde Microsoft muligheten til å kjør Win32-apper isolert på Windows 11. Selskapet gikk ikke i detalj i det første blogginnlegget, men det fremhevet muligheten for å kjøre Win32 apper i et sandkassemiljø slik at resten av operativsystemet er sikret mot potensielt skadelig programvare. Nå har den avslørt mer informasjon om denne spesielle funksjonen, inkludert hvordan den fungerer og passer inn i resten av sikkerhetsinfrastrukturen til Windows.
Microsofts visepresident for OS Security and Enterprise David Weston har skrevet en lang blogg innlegg, som forklarer naturen til Win32-appisolasjon. Funksjonen er enda et sikkerhetsalternativ for sandkasse akkurat som Windows Sandbox og Microsoft Defender Application Guard, men den er basert på AppContainers, ikke virtualiseringsbasert programvare som de to andre sikkerhetstiltakene. For de som ikke er klar over, fungerer AppContainers som en måte å kontrollere utførelsen av en prosess ved å innkapsle den og sikre at den kjører på svært lave privilegie- og integritetsnivåer.
Microsoft har sterkt anbefalt å bruke Smart App Control (SAC) og Win32 app-isolasjon samtidig mens du sikrer Windows-miljøet ditt fra upålitelige apper som bruker 0-dagers sårbarheter. Den tidligere sikkerhetsmekanismen stopper angrep ved å installere bare pålitelige apper mens sistnevnte kan være det brukes til å kjøre apper i et isolert og sikkert miljø for å begrense potensiell skade og beskytte brukeren personvern. Dette er fordi en Win32-app som kjører isolert ikke har samme rettighetsnivå som brukeren av systemet.
Teknologifirmaet Redmond har identifisert flere nøkkelmål for Win32-appisolering. For det første begrenser det virkningen fra en kompromittert app siden angripere har lavt privilegium tilgang til en del av operativsystem, og de må kjede et komplekst angrep i flere trinn for å bryte gjennom sandkassen deres. Selv om de lykkes, gir dette også mer innsikt i prosessen deres, noe som gjør det mye raskere å implementere og levere avbøtende oppdateringer.
Måten dette fungerer på er at en app først lanseres med lave integritetsnivåer gjennom AppContainer, som betyr at de har tilgang til utvalgte Windows APIer og ikke kan kjøre skadelig kode som krever høyere rettigheter nivåer. I det neste og siste trinnet håndheves prinsippene for minste privilegium ved å gi en app autorisert tilgang til Windows-sikrede objekter, som tilsvarer implementering av en Diskresjonær tilgangskontrollliste (DACL) på Windows.
En annen fordel med Win32-appisolering er redusert utviklerinnsats ettersom appskapere kan utnytte Application Capability Profiler (ACP) tilgjengelig på GitHub for å forstå hvilke tillatelser de trenger. De kan aktivere ACP og kjøre appen sin i en "læringsmodus" i Win32 app-isolasjon for å få logger om tilleggsmulighetene de trenger for å kjøre programvaren. ACP drives av Windows Performance Analyzer (WPA) datalagsbackend og Event Trace Logs (ETLs). Informasjonen fra loggene som genereres av denne prosessen kan ganske enkelt legges til en applikasjons pakkemanifestfil.
Til slutt har Win32 app-isolering som mål å tilby en sømløs brukeropplevelse. Win32 app-isolering forenkler dette ved å kreve at apper bruker "isolatedWin32-promptForAccess"-funksjonen for å spørre brukeren i tilfelle de trenger tilgang til dataene sine, for eksempel .NET-biblioteker og beskyttet register nøkler. Spørsmålet skal være meningsfullt for brukeren som samtykke innhentes fra. Når tilgang til en ressurs er gitt, skjer dette videre:
Når brukeren gir samtykke til en spesifikk fil for den isolerte applikasjonen, grensesnitter den isolerte applikasjonen med Windows Megler filsystem (BFS) og gir tilgang til filene via en minifilterdriver. BFS åpner ganske enkelt filen og fungerer som grensesnittet mellom den isolerte applikasjonen og BFS.
Fil- og registervirtualisering bidrar til å sikre at apper fortsetter å fungere uten å oppdatere basisfilen eller registret. Dette minimerer også friksjon av brukeropplevelsen samtidig som applikasjonskompatibiliteten opprettholdes. Beskyttede navneområder opprettes for kun å gi tilgang til appen og krever ikke brukersamtykke. For eksempel kan tilgang til en mappe som har en egenskap som kun er kjent for Win32-appen og som kreves for appkompatibilitet, gis.
Microsoft har lagt vekt på at for å ha funksjonsparitet mellom isolert og ikke-isolert Win32-apper, førstnevnte kan samhandle med filsystemet og andre Windows APIer ved å utnytte Windows BFS. Dessuten sikrer oppføringer i applikasjonens manifest også at appen trygt kan samhandle med Windows-elementer som skallvarsler og ikoner i systemstatusfeltet. Du kan lær mer om initiativet på GitHub her.