Säkerhetsöverväganden för JEA

JEA hjälper dig att förbättra din säkerhetsstatus genom att minska antalet permanenta administratörer på dina datorer. JEA använder en PowerShell-sessionskonfiguration för att skapa en ny startpunkt för användare att hantera systemet. Användare som behöver förhöjd, men inte obegränsad, åtkomst till datorn för att utföra administrativa uppgifter kan beviljas åtkomst till JEA-slutpunkten. Eftersom JEA tillåter dessa användare att köra administrativa kommandon utan fullständig administratörsåtkomst kan du sedan ta bort dessa användare från säkerhetsgrupper med hög behörighet.

Kör som-konto

Varje JEA-slutpunkt har ett särskilt kör som-konto där den anslutande användarens åtgärder körs. Det här kontot kan konfigureras i sessionskonfigurationsfilen och det konto du väljer har stor betydelse för säkerheten för slutpunkten.

Virtuella konton är det rekommenderade sättet att konfigurera kör som-kontot . Virtuella konton är enstaka, tillfälliga lokala konton som skapas för den anslutande användaren att använda under jea-sessionen. Så snart sessionen avslutas förstörs det virtuella kontot och kan inte användas längre. Den anslutande användaren känner inte till autentiseringsuppgifterna för det virtuella kontot. Det virtuella kontot kan inte användas för att komma åt systemet på andra sätt som Fjärrskrivbord eller en obehindrat PowerShell-slutpunkt.

Som standard är virtuella konton medlemmar i den lokala gruppen Administratörer på datorn. Det här medlemskapet ger dem fullständig behörighet att hantera allt i systemet, men inga rättigheter att hantera resurser i nätverket. När användaren ansluter till andra datorer från JEA-sessionen är användarkontexten för det lokala datorkontot, inte det virtuella kontot.

Domänkontrollanter är ett specialfall eftersom det inte finns någon lokal administratörsgrupp. I stället tillhör virtuella konton domänadministratörer och kan hantera katalogtjänsterna på domänkontrollanten. Domänidentiteten är fortfarande begränsad för användning på domänkontrollanten där JEA-sessionen instansierades. All nätverksåtkomst verkar komma från domänkontrollantens datorobjekt i stället.

I båda fallen kan du tilldela det virtuella kontot till specifika säkerhetsgrupper, särskilt när uppgiften kan utföras utan behörighet som lokal administratör eller domänadministratör. Om du redan har en säkerhetsgrupp som har definierats för dina administratörer beviljar du det virtuella kontomedlemskapet till den gruppen. Gruppmedlemskap för virtuella konton är begränsat till lokala säkerhetsgrupper på arbetsstations- och medlemsservrar. På domänkontrollanter måste virtuella konton vara medlemmar i domänsäkerhetsgrupper. När det virtuella kontot har lagts till i en eller flera säkerhetsgrupper tillhör det inte längre standardgrupperna (lokala administratörer eller domänadministratörer).

I följande tabell sammanfattas möjliga konfigurationsalternativ och resulterande behörigheter för virtuella konton:

Datortyp	Konfiguration av virtuell kontogrupp	Kontext för lokal användare	Nätverksanvändarkontext
Domänkontrollant	Standardvärde	Domänanvändare, medlem i <DOMAIN>\Domain Admins	Datorkonto
Domänkontrollant	Domängrupper A och B	Domänanvändare, medlem i <DOMAIN>\A, <DOMAIN>\B	Datorkonto
Medlemsserver eller arbetsstation	Standardvärde	Lokal användare, medlem i BUILTIN\Administrators	Datorkonto
Medlemsserver eller arbetsstation	Lokala grupper C och D	Lokal användare, medlem i <COMPUTER>\C och <COMPUTER>\D	Datorkonto

När du tittar på säkerhetsgransknings- och programhändelseloggar ser du att varje JEA-användarsession har ett unikt virtuellt konto. Det här unika kontot hjälper dig att spåra användaråtgärder i en JEA-slutpunkt tillbaka till den ursprungliga användaren som körde kommandot. Namn på virtuella konton följer till exempel formatet WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> om användaren Alice i domänen Contoso startar om en tjänst i en JEA-slutpunkt, skulle användarnamnet som är associerat med eventuella händelser för Service Control Manager vara WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Grupphanterade tjänstkonton (gMSAs) är användbara när en medlemsserver behöver ha åtkomst till nätverksresurser i JEA-sessionen. Till exempel när en JEA-slutpunkt används för att styra åtkomsten till en REST API-tjänst som finns på en annan dator. Det är enkelt att skriva funktioner för att anropa REST-API:er, men du behöver en nätverksidentitet för att autentisera med API:et. Med hjälp av ett grupphanterat tjänstkonto blir det andra hoppet möjligt samtidigt som du behåller kontrollen över vilka datorer som kan använda kontot. Medlemskap i säkerhetsgruppen (lokal eller domän) i gMSA definierade de gällande behörigheterna för gMSA-kontot.

När en JEA-slutpunkt har konfigurerats för att använda en gMSA verkar åtgärderna för alla JEA-användare komma från samma gMSA. Det enda sättet att spåra åtgärder tillbaka till en specifik användare är att identifiera vilken uppsättning kommandon som körs i en PowerShell-sessionsavskrift.

Direktautentiseringsuppgifter används när du inte anger ett kör som-konto . PowerShell använder den anslutande användarens autentiseringsuppgifter för att köra kommandon på fjärrservern. Om du vill använda direktautentiseringsuppgifter måste du ge den anslutande användaren direkt åtkomst till privilegierade hanteringsgrupper. Den här konfigurationen rekommenderas INTE för JEA. Om den anslutande användaren redan har administratörsbehörighet kan de kringgå JEA och hantera systemet med hjälp av andra åtkomstmetoder.

Med vanliga kör som-konton kan du ange alla användarkonton under vilka hela PowerShell-sessionen körs. Sessionskonfigurationer med fasta kör som-konton (med parametern -RunAsCredential ) är inte JEA-medvetna. Rolldefinitioner fungerar inte längre som förväntat. Varje användare som har behörighet att komma åt slutpunkten tilldelas samma roll.

Du bör inte använda en RunAsCredential på en JEA-slutpunkt eftersom det är svårt att spåra åtgärder tillbaka till specifika användare och saknar stöd för att mappa användare till roller.

WinRM-slutpunkts-ACL

Precis som med vanliga PowerShell-fjärrkommunikationsslutpunkter har varje JEA-slutpunkt en separat åtkomstkontrollista (ACL) som styr vem som kan autentisera med JEA-slutpunkten. Om det är felaktigt konfigurerat kanske betrodda användare inte kan komma åt JEA-slutpunkten och ej betrodda användare kan ha åtkomst. WinRM ACL påverkar inte mappningen av användare till JEA-roller. Mappningen styrs av fältet RoleDefinitions i sessionskonfigurationsfilen som används för att registrera slutpunkten.

Som standard, när en JEA-slutpunkt har flera rollfunktioner, konfigureras WinRM ACL för att tillåta åtkomst till alla mappade användare. Till exempel ger en JEA-session som konfigurerats med följande kommandon fullständig åtkomst till CONTOSO\JEA_Lev1 och CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Du kan granska användarbehörigheter med cmdleten Get-PSSessionConfiguration .

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Om du vill ändra vilka användare som har åtkomst kör du antingen Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI för en interaktiv fråga eller Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> för att uppdatera behörigheterna. Användarna behöver minst anropa rättigheter för att få åtkomst till JEA-slutpunkten.

Det går att skapa en JEA-slutpunkt som inte mappar en definierad roll till alla användare som har åtkomst. Dessa användare kan starta en JEA-session, men har bara åtkomst till standard-cmdletarna. Du kan granska användarbehörigheter i en JEA-slutpunkt genom att köra Get-PSSessionCapability. Mer information finns i Granskning och rapportering om JEA.

Minst privilegierade roller

När du utformar JEA-roller är det viktigt att komma ihåg att de virtuella och grupphanterade tjänstkonton som körs i bakgrunden kan ha obegränsad åtkomst till den lokala datorn. JEA-rollfunktioner hjälper till att begränsa de kommandon och program som kan köras i den privilegierade kontexten. Felaktigt utformade roller kan tillåta farliga kommandon som kan göra det möjligt för en användare att bryta sig ur JEA-gränserna eller få åtkomst till känslig information.

Tänk till exempel på följande rollfunktionspost:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Med den här rollfunktionen kan användare köra valfri PowerShell-cmdlet med substantivprocessen från modulen Microsoft.PowerShell.Management. Användare kan behöva komma åt cmdletar som för att se vilka program som Get-Process körs på systemet och Stop-Process för att avsluta program som inte svarar. Men den här posten tillåter Start-Processockså , som kan användas för att starta ett godtyckligt program med fullständig administratörsbehörighet. Programmet behöver inte installeras lokalt i systemet. En ansluten användare kan starta ett program från en filresurs som ger användaren lokala administratörsbehörigheter, kör skadlig kod med mera.

En säkrare version av samma rollfunktion skulle se ut så här:

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Undvik att använda jokertecken i rollfunktioner. Se till att regelbundet granska gällande användarbehörigheter för att se vilka kommandon som är tillgängliga för en användare. Mer information finns i avsnittet Kontrollera gällande rättigheter i artikeln Granskning och rapportering om JEA .

Rekommendationer för bästa praxis

Följande är rekommenderade metodtips för att säkerställa säkerheten för dina JEA-slutpunkter:

Begränsa användningen och funktionerna för PowerShell-leverantörer

Granska hur de tillåtna leverantörerna används för att säkerställa att du inte skapar säkerhetsrisker i den konfigurerade sessionen.

Varning

Tillåt inte FileSystem-providern . Om användarna kan skriva till någon del av filsystemet är det möjligt att helt kringgå säkerheten.

Tillåt inte certifikatprovidern . När providern är aktiverad kan en användare få åtkomst till lagrade privata nycklar.

Tillåt inte kommandon som kan skapa nya runspaces.

Varning

Cmdletarna *-Job kan skapa nya runspaces utan begränsningar.

Tillåt inte cmdleten Trace-Command .

Varning

Med hjälp av Trace-Command tas alla spårade kommandon in i sessionen.

Skapa inte egna proxyimplementeringar för de begränsade kommandona.

PowerShell har en uppsättning proxykommandon för begränsade kommandoscenarier. Dessa proxykommandon säkerställer att indataparametrar inte kan äventyra sessionens säkerhet. Följande kommandon har begränsade proxyservrar:

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Om du skapar en egen implementering av dessa kommandon kan du oavsiktligt tillåta användare att köra kod som är förbjuden av JEA-proxykommandona.

JEA skyddar inte mot administratörer

En av huvudprinciperna för JEA är att det gör det möjligt för icke-administratörer att utföra vissa administrativa uppgifter. JEA skyddar inte mot användare som redan har administratörsbehörighet. Användare som tillhör domänadministratörer, lokala administratörer eller andra grupper med hög behörighet kan kringgå JEA:s skydd på andra sätt. De kan till exempel logga in med RDP, använda mmc-fjärrkonsoler eller ansluta till obegränsade PowerShell-slutpunkter. Den lokala administratören i ett system kan också ändra JEA-konfigurationer för att lägga till fler användare eller ändra en rollfunktion för att utöka omfattningen för vad en användare kan göra i sin JEA-session. Det är viktigt att utvärdera dina JEA-användares utökade behörigheter för att se om det finns andra sätt att få privilegierad åtkomst till systemet.

Förutom att använda JEA för regelbundet dagligt underhåll är det vanligt att ha ett just-in-time-system för privilegierad åtkomsthantering. Dessa system gör det möjligt för utsedda användare att tillfälligt bli lokal administratör först när de har slutfört ett arbetsflöde som dokumenterar deras användning av dessa behörigheter.