Dela via

Använda App Control för att skydda PowerShell

  • Artikel

Windows 10 innehåller två tekniker, App Control for Business och AppLocker, som du kan använda för att styra program. De gör att du kan skapa en låsningsupplevelse för att skydda din PowerShell-miljö.

AppLocker bygger på funktionerna för programkontroll i principer för begränsning av programvara. Med AppLocker kan du skapa regler för att tillåta eller neka appar för specifika användare eller grupper. Du identifierar apparna baserat på unika egenskaper för filerna.

Med Programkontroll för företag, som introducerades i Windows 10 som Windows Defender Application Control (WDAC), kan du styra vilka drivrutiner och program som tillåts köras i Windows.

Principidentifiering för låsning

PowerShell identifierar både AppLocker- och App Control for Business-systemomfattande principer. AppLocker kan inte köra frågor mot principens tvingande status. För att identifiera om en systemomfattande programkontrollprincip tillämpas av AppLocker skapar PowerShell två temporära filer och tester om de kan köras. Filnamnen använder följande namnformat:

  • $env:TEMP/__PSAppLockerTest__<random-8dot3-name>.ps1
  • $env:TEMP/__PSAppLockerTest__<random-8dot3-name>.psm1

App Control for Business är det föredragna programkontrollsystemet för Windows. App Control tillhandahåller API:er som gör att du kan identifiera principkonfigurationen. App Control är utformad som en säkerhetsfunktion enligt de underhållskriterier som definieras av Microsoft Security Response Center (MSRC). Mer information finns i Programkontroller för Windows och App Control och AppLocker-funktionstillgänglighet.

Kommentar

När du väljer mellan App Control eller AppLocker rekommenderar vi att du implementerar programkontroll med appkontroll för företag i stället för AppLocker. Microsoft investerar inte längre i AppLocker. Även om AppLocker kan fortsätta att få säkerhetskorrigeringar får det inte några funktionsförbättringar.

Tillämpning av appkontrollprincip

När PowerShell körs under en appkontrollprincip ändras dess beteende baserat på den definierade säkerhetsprincipen. Under en App Control-princip kör PowerShell betrodda skript och moduler som tillåts av principen i FullLanguage läge. Alla andra skript och skriptblock är inte betrodda och körs i ConstrainedLanguage läge. PowerShell utlöser fel när de obetrodda skripten försöker utföra åtgärder som inte tillåts i ConstrainedLanguage läge. Det kan vara svårt att veta varför ett skript inte kunde köras korrekt i ConstrainedLanguage läge.

Granskning av appkontrollprincip

PowerShell 7.4 har lagt till en ny funktion som stöder App Control-principer i granskningsläge . I granskningsläge kör PowerShell de ej betrodda skripten i läge utan fel, men loggar meddelanden till händelseloggen i ConstrainedLanguage stället. Loggmeddelandena beskriver vilka begränsningar som skulle gälla om principen var i framtvinga läge.

Ändringshistorik

Windows PowerShell 5.1 var den första versionen av PowerShell som hade stöd för App Control. Säkerhetsfunktionerna i App Control och AppLocker förbättras med varje ny version av PowerShell. I följande avsnitt beskrivs hur det här stödet har ändrats i varje version av PowerShell. Ändringarna är kumulativa, så de funktioner som beskrivs i de senare versionerna inkluderar de från tidigare versioner.

Ändringar i PowerShell 7.4

När PowerShell körs under en App Control-princip i Windows ändras beteendet baserat på den definierade säkerhetsprincipen. Under en App Control-princip kör PowerShell betrodda skript och moduler som tillåts av principen i FullLanguage läge. Alla andra skript och skriptblock är inte betrodda och körs i ConstrainedLanguage läge. PowerShell utlöser fel när de ej betrodda skripten försöker utföra otillåtna åtgärder. Det är svårt att veta varför ett skript inte kan köras korrekt i ConstrainedLanguage läge.

PowerShell 7.4 stöder nu appkontrollprinciper i granskningsläge . I granskningsläge kör PowerShell de ej betrodda skripten i ConstrainedLanguage läge men loggar meddelanden till händelseloggen i stället för att utlösa fel. Loggmeddelandena beskriver vilka begränsningar som skulle gälla om principen var i framtvinga läge.

Ändringar i PowerShell 7.3

  • PowerShell 7.3 stöder nu möjligheten att blockera eller tillåta PowerShell-skriptfiler via App Control API.

Ändringar i PowerShell 7.2

  • Det fanns ett hörnfallsscenario i AppLocker där du bara har Neka-regler och begränsat läge inte används för att tillämpa principen som gör att du kan kringgå körningsprincipen. Från och med PowerShell 7.2 gjordes en ändring för att säkerställa att AppLocker-regler har företräde framför ett Set-ExecutionPolicy -ExecutionPolicy Bypass kommando.

  • PowerShell 7.2 tillåter nu inte att cmdleten Add-Type används i en NoLanguage PowerShell-lägessession på en låst dator.

  • PowerShell 7.2 tillåter nu inte skript från att använda COM-objekt i AppLocker-systemlåsningsvillkor. Cmdletar som använder COM eller DCOM internt påverkas inte.

Ytterligare läsning