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 för 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 administratörskommandon utan fullständig administratörsåtkomst kan du sedan ta bort dessa användare från högprivilegierade säkerhetsgrupper.

Run-As konto

Varje JEA-slutpunkt har ett särskilt kör som-konto . Det här är det konto under vilket den anslutande användarens åtgärder körs. Det här kontot kan konfigureras i sessionskonfigurationsfilen och det konto som 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 tillfälliga lokala engångskonton som skapas så att den anslutande användaren kan 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 obegränsad PowerShell-slutpunkt.

Som standard tillhör virtuella konton den lokala gruppen Administratörer på datorn. Detta ger dem fullständig behörighet att hantera allt i systemet, men inga rättigheter att hantera resurser i nätverket. När du autentiserar med andra datorer är användarkontexten den 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 uttryckligen definiera vilka säkerhetsgrupper det virtuella kontot tillhör. Det här är en bra idé 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 definierats för dina administratörer beviljar du det virtuella kontomedlemskapet till den gruppen. Medlemskap i virtuella kontogrupper ä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	Lokal användarkontext	Nätverksanvändarkontext
Domänkontrollant	Standardvärde	Domänanvändare, medlem i "DOMÄN\Domänadministratörer"	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äkerhetsgranskningshändelser 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 händelser för tjänstkontrollhanteraren vara WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Grupphanterade tjänstkonton (gMSA) ä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 kontrollen över vilka datorer som kan använda kontot bibehålls. Gällande behörigheter för gMSA definieras av de säkerhetsgrupper (lokala eller domän) som gMSA-kontot tillhör.

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. Detta kräver att du beviljar 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 undvika JEA och hantera systemet via andra, obegränsade medel. Mer information finns i avsnittet nedan om hur JEA inte skyddar mot administratörer.

Med standard-kör som-konton kan du ange alla användarkonton under vilka hela PowerShell-sessionen körs. Sessionskonfigurationer som använder fasta Kör som-konton (med parametern -RunAsCredential ) är inte JEA-medvetna. Rolldefinitioner fungerar inte längre som förväntat. Alla 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 mappning av 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. En JEA-session som konfigurerats med följande kommandon ger till exempel 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 prompt eller Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> för att uppdatera behörigheterna. Användarna behöver minst Behörighet att anropa för att få åtkomst till JEA-slutpunkten.

Det går att skapa en JEA-slutpunkt som inte mappar en definierad roll till varje 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.

Roller med lägsta behörighet

När du utformar JEA-roller är det viktigt att komma ihåg att de virtuella och grupphanterade tjänstkontona 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 tillåta att en användare bryter sig ut från JEA-gränserna eller får åtkomst till känslig information.

Tänk dig till exempel 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 i 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 lokal administratörsbehörighet, 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 förstå vilka kommandon som är tillgängliga för användaren.

JEA skyddar inte mot administratörer

En av huvudprinciperna för JEA är att icke-administratörer kan utföra vissa administratörsuppgifter. 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å ett annat sätt. De kan till exempel logga in med RDP, använda mmc-fjärrkonsoler eller ansluta till obegränsade PowerShell-slutpunkter. Lokala administratörer i ett system kan också ändra JEA-konfigurationer för att tillåta ytterligare 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.

En vanlig praxis är att använda JEA för regelbundet dagligt underhåll och ha en just-in-time-lösning för privilegierad åtkomsthantering som gör att användare tillfälligt kan bli lokala administratörer i nödsituationer. Detta säkerställer att användarna inte är permanenta administratörer i systemet, men kan få dessa rättigheter om och bara när de slutför ett arbetsflöde som dokumenterar deras användning av dessa behörigheter.