Dela via

Säkerhetsfunktioner i PowerShell

PowerShell har flera funktioner som är utformade för att förbättra säkerheten i din skriptmiljö.

Körningspolicy

PowerShells körningsprincip är en säkerhetsfunktion som styr under vilka förhållanden PowerShell läser in konfigurationsfiler och kör skript. Den här funktionen hjälper till att förhindra körning av skadliga skript. Du kan använda en grupprincip inställning för att ange körningsprinciper för datorer och användare. Körningsprinciper gäller endast för Windows-plattformen.

Mer information finns i about_Execution_Policies.

Användning av klassen SecureString

PowerShell har flera cmdletar som stöder användningen av System.Security.SecureString klassen. Och precis som med alla .NET-klasser kan du använda SecureString i dina egna skript. Microsoft rekommenderar dock inte att du använder SecureString för ny utveckling. Microsoft rekommenderar att du undviker att använda lösenord och förlitar dig på andra sätt för att autentisera, till exempel certifikat eller Windows-autentisering.

PowerShell fortsätter att stödja Klassen SecureString för bakåtkompatibilitet. Att använda en SecureString är fortfarande säkrare än att använda en oformaterad textsträng. PowerShell förlitar sig fortfarande på typen SecureString för att undvika att oavsiktligt exponera innehållet för konsolen eller i loggar. Använd SecureString noggrant eftersom det enkelt kan konverteras till en oformaterad textsträng. En fullständig diskussion om hur du använder SecureString finns i klassdokumentationen System.Security.SecureString.

Loggning av modul- och skriptblock

Med modulloggning kan du aktivera loggning för valda PowerShell-moduler. Den här inställningen gäller för alla sessioner på datorn. PowerShell registrerar pipelinekörningshändelser för de angivna modulerna i Windows PowerShell-händelseloggen.

Loggning av skriptblock möjliggör loggning för bearbetning av kommandon, skriptblock, funktioner och skript – oavsett om de anropas interaktivt eller via automatisering. PowerShell loggar den här informationen till händelseloggen Microsoft-Windows-PowerShell/Operational .

Mer information finns i följande artiklar:

AMSI-support

Windows Antimalware Scan Interface (AMSI) är ett API som gör att program kan skicka åtgärder till en skanner för program mot skadlig kod, till exempel Windows Defender, för att söka efter skadliga nyttolaster. Från och med PowerShell 5.1 skickar PowerShell som körs på Windows 10 (och senare) alla skriptblock till AMSI.

PowerShell 7.3 utökar de data som skickas till AMSI för inspektion. Den innehåller nu alla .NET-metodanrop.

Mer information om AMSI finns i Så här hjälper AMSI.

Begränsat språkläge

Läget ConstrainedLanguage skyddar systemet genom att begränsa de cmdletar och .NET-typer som tillåts i en PowerShell-session. En fullständig beskrivning finns i about_Language_Modes.

Programkontroll

Windows 10 innehåller två tekniker, App Control for Business och AppLocker som du kan använda för att styra program. PowerShell identifierar om en systemomfattande programkontrollprincip tillämpas. Principen tillämpar vissa beteenden när du kör skriptblock, skriptfiler eller läser in modulfiler för att förhindra godtycklig kodkörning i systemet.

App Control for Business är utformad som en säkerhetsfunktion enligt de underhållskriterier som definieras av Microsoft Security Response Center (MSRC). Appkontroll är det föredragna programkontrollsystemet för Windows.

Mer information om hur PowerShell stöder AppLocker och App Control finns i Använda App Control för att skydda PowerShell.

Programvarudokumentation (SBOM)

Från och med PowerShell 7.2 innehåller alla installationspaket en SBOM (Software Bill of Materials). PowerShell-teamet producerar även SBOM:er för moduler som de äger men levererar oberoende av PowerShell.

Du hittar SBOM-filer på följande platser:

  • I PowerShell hittar du SBOM på $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
  • För moduler hittar du SBOM i modulens mapp under _manifest/spdx_2.2/manifest.spdx.json.

Skapandet och publiceringen av SBOM är det första steget för att modernisera federal myndighets cybersäkerhet och förbättra säkerheten i programvaruförsörjningskedjan. Mer information om det här initiativet finns i blogginlägget Generating SBOMs with SPDX at Microsoft (Generera SBOM:er med SPDX på Microsoft).

Säker dataöverföring i PowerShell-fjärrkommunikation

Före PowerShell v7.6-preview5 används en Session_Key för att kryptera en SecureString innan den skickas till en PowerShell-fjärrsession. PSRP (PowerShell Remoting Protocol) utför ett nyckelutbyte mellan klient och server när ett SecureString objekt måste överföras. Utbytet omfattar följande steg:

  1. Klientsidan genererar ett offentligt/privat nyckelpar och skickar den offentliga nyckeln till servern.
  2. Servern genererar en sessionsnyckel för symmetrisk kryptering.
  3. Servern använder den offentliga nyckeln för att kryptera sessionsnyckeln och skickar den till klienten.
  4. Både klienten och servern använder den nya sessionsnyckeln för att kryptera ett SecureString-objekt .

PowerShell Remoting Protocol (PSRP) använder algoritmen RSAEncryptionPadding.Pkcs1 under nyckelutbytet. Algoritmen är INTE säker, så nyckelutbytet ger ingen extra säkerhet.

Viktigt!

Du måste använda ett säkert transportlager för att säkerställa säker dataöverföring via PSRP.

Från och med PowerShell v7.6-preview.5 var nyckelutbytet inaktuellt. Versionen av PSRP ökades till v2.4 och innehåller följande ändringar:

  • Följande PSRP-meddelanden är inaktuella när både klienten och servern är v2.4 eller senare:

    • PUBLIC_KEY
    • PUBLIC_KEY_REQUEST
    • ENCRYPTED_SESSION_KEY

  • Krypterings- och dekrypteringsstegen för SecureString hoppas över när både klienten och servern är v2.4 eller senare.

Den här ändringen är bakåtkompatibel.

  • För gamla klienter eller servrar (v2.3 eller lägre) används nyckelutbytet fortfarande när det behövs.
  • PSRP kan använda en namngiven pipe-fjärrsession när både klienten och servern finns på samma dator. Eftersom det är möjligt för en fjärrklient att ansluta till namngiven pipe och data inte längre krypteras med en sessionsnyckel, avvisar det namngivna röret (används för Enter-PSHostProcess) fjärrklienten.

Villkor för säkerhetsunderjäning

PowerShell följer Microsofts servicevillkor för säkerhet för Windows. Endast säkerhetsfunktioner uppfyller kriterierna för service.

Säkerhetsfunktioner

  • Systemlåsning med App Control för företag
  • Begränsat språkläge med App Control för företag

Djupskyddsfunktioner

  • Systemlåsning med AppLocker
  • Begränsat språkläge med AppLocker
  • Körningsprincip
  • Last updated on