JEA-beveiligingsoverwegingen

JEA helpt u uw beveiligingspostuur te verbeteren door het aantal permanente beheerders op uw computers te verminderen. JEA maakt gebruik van een PowerShell-sessieconfiguratie om een nieuw toegangspunt te maken voor gebruikers om het systeem te beheren. Gebruikers die verhoogde, maar niet onbeperkte toegang tot de computer nodig hebben om beheertaken uit te voeren, kunnen toegang krijgen tot het JEA-eindpunt. Omdat JEA deze gebruikers toestaat om beheerdersopdrachten uit te voeren zonder volledige beheerderstoegang te hebben, kunt u deze gebruikers vervolgens verwijderen uit beveiligingsgroepen met hoge bevoegdheden.

Run-As-account

Elk JEA-eindpunt heeft een aangewezen uitvoeren als-account . Dit is het account waaronder de acties van de gebruiker die verbinding maken, worden uitgevoerd. Dit account kan worden geconfigureerd in het sessieconfiguratiebestand en het account dat u kiest, heeft een aanzienlijke invloed op de beveiliging van uw eindpunt.

Virtuele accounts zijn de aanbevolen manier om het uitvoeren als-account te configureren. Virtuele accounts zijn eenmalige, tijdelijke lokale accounts die worden gemaakt voor de verbinding die de gebruiker kan gebruiken tijdens de DUUR van de JEA-sessie. Zodra de sessie is beëindigd, wordt het virtuele account vernietigd en kan het niet meer worden gebruikt. De verbinding makende gebruiker kent de referenties voor het virtuele account niet. Het virtuele account kan niet worden gebruikt voor toegang tot het systeem via andere middelen, zoals Extern bureaublad of een niet-verbonden PowerShell-eindpunt.

Virtuele accounts behoren standaard tot de lokale groep Administrators op de computer. Hierdoor hebben ze volledige rechten om alles op het systeem te beheren, maar geen rechten om resources in het netwerk te beheren. Bij verificatie met andere machines is de gebruikerscontext die van het lokale computeraccount, niet het virtuele account.

Domeincontrollers zijn een speciaal geval omdat er geen lokale groep Administrators is. In plaats daarvan behoren virtuele accounts tot domeinadministratoren en kunnen de adreslijstservices op de domeincontroller beheren. De domeinidentiteit is nog steeds beperkt voor gebruik op de domeincontroller waar de JEA-sessie is geïnstantieerd. Alle netwerktoegang lijkt afkomstig te zijn van het computerobject van de domeincontroller.

In beide gevallen kunt u expliciet definiëren tot welke beveiligingsgroepen het virtuele account behoort. Dit is een goede gewoonte wanneer de taak kan worden uitgevoerd zonder lokale of domeinbeheerdersbevoegdheden. Als u al een beveiligingsgroep hebt gedefinieerd voor uw beheerders, verleent u het lidmaatschap van het virtuele account aan die groep. Groepslidmaatschap van virtuele accounts is beperkt tot lokale beveiligingsgroepen op werkstation- en lidservers. Op domeincontrollers moeten virtuele accounts lid zijn van domeinbeveiligingsgroepen. Zodra het virtuele account is toegevoegd aan een of meer beveiligingsgroepen, behoort het niet meer tot de standaardgroepen (lokale of domeinadministratoren).

De volgende tabel bevat een overzicht van de mogelijke configuratieopties en resulterende machtigingen voor virtuele accounts:

Type computer	Configuratie van virtuele accountgroep	Lokale gebruikerscontext	Netwerkgebruikerscontext
Domeincontroller	Standaard	Domeingebruiker, lid van DOMEIN\Domeinadministratoren	Computeraccount
Domeincontroller	Domeingroepen A en B	Domeingebruiker, lid van DOMEIN\A, DOMEIN\B	Computeraccount
Lidserver of werkstation	Standaard	Lokale gebruiker, lid van 'BUILTIN\Administrators'	Computeraccount
Lidserver of werkstation	Lokale groepen C en D	Lokale gebruiker, lid van 'COMPUTER\C' en 'COMPUTER\D'	Computeraccount

Wanneer u beveiligingscontrolegebeurtenissen en toepassingsgebeurtenissenlogboeken bekijkt, ziet u dat elke JEA-gebruikerssessie een uniek virtueel account heeft. Dit unieke account helpt u bij het bijhouden van gebruikersacties in een JEA-eindpunt naar de oorspronkelijke gebruiker die de opdracht heeft uitgevoerd. Namen van virtuele accounts volgen de indeling WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> , bijvoorbeeld als gebruiker Alice in het domein Contoso een service opnieuw start in een JEA-eindpunt, is WinRM Virtual Users\WinRM_VA_1_contoso_alicede gebruikersnaam die is gekoppeld aan gebeurtenissen van servicebeheerbeheer.

Door groepen beheerde serviceaccounts (gMSA's) zijn handig wanneer een lidserver toegang moet hebben tot netwerkresources in de JEA-sessie. Wanneer bijvoorbeeld een JEA-eindpunt wordt gebruikt om de toegang tot een REST API-service te beheren die op een andere computer wordt gehost. Het is eenvoudig om functies te schrijven om de REST API's aan te roepen, maar u hebt een netwerkidentiteit nodig om te verifiëren met de API. Met behulp van een door groepen beheerd serviceaccount wordt de tweede hop mogelijk, terwijl u de controle behoudt over welke computers het account kunnen gebruiken. De effectieve machtigingen van de gMSA worden gedefinieerd door de beveiligingsgroepen (lokaal of domein) waartoe het gMSA-account behoort.

Wanneer een JEA-eindpunt is geconfigureerd voor het gebruik van een gMSA, lijken de acties van alle JEA-gebruikers afkomstig te zijn van dezelfde gMSA. De enige manier om acties terug te traceren naar een specifieke gebruiker is door de set opdrachten te identificeren die worden uitgevoerd in een PowerShell-sessietranscriptie.

Passthru-referenties worden gebruikt wanneer u geen uitvoeren als-account opgeeft. PowerShell gebruikt de referenties van de gebruiker om opdrachten uit te voeren op de externe server. Hiervoor moet u de gebruiker directe toegang verlenen tot bevoegde beheergroepen. Deze configuratie wordt niet aanbevolen voor JEA. Als de gebruiker die verbinding maakt al beheerdersbevoegdheden heeft, kan hij JEA vermijden en het systeem beheren via andere, niet-getrainde middelen. Zie de sectie hieronder voor meer informatie over hoe JEA niet beschermt tegen beheerders.

Met Standaard uitvoeren als-accounts kunt u een gebruikersaccount opgeven waaronder de volledige PowerShell-sessie wordt uitgevoerd. Sessieconfiguraties met vaste run-as-accounts (met de -RunAsCredential parameter) zijn niet JEA-bewust. Roldefinities werken niet meer zoals verwacht. Aan elke gebruiker die gemachtigd is om toegang te krijgen tot het eindpunt, wordt dezelfde rol toegewezen.

U moet geen RunAsCredential gebruiken op een JEA-eindpunt, omdat het moeilijk is om acties terug te traceren naar specifieke gebruikers en geen ondersteuning voor het toewijzen van gebruikers aan rollen.

WinRM-eindpunt-ACL

Net als bij reguliere externe PowerShell-eindpunten heeft elk JEA-eindpunt een afzonderlijke ACL (Access Control List) die bepaalt wie kan verifiëren met het JEA-eindpunt. Als deze onjuist is geconfigureerd, hebben vertrouwde gebruikers mogelijk geen toegang tot het JEA-eindpunt en hebben niet-vertrouwde gebruikers mogelijk toegang. De WinRM ACL heeft geen invloed op de toewijzing van gebruikers aan JEA-rollen. Toewijzing wordt bepaald door het veld RoleDefinitions in het sessieconfiguratiebestand dat wordt gebruikt om het eindpunt te registreren.

Wanneer een JEA-eindpunt meerdere rolmogelijkheden heeft, is de WinRM ACL standaard geconfigureerd om toegang te verlenen tot alle toegewezen gebruikers. Een JEA-sessie die is geconfigureerd met behulp van de volgende opdrachten verleent bijvoorbeeld volledige toegang tot CONTOSO\JEA_Lev1 en 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'

U kunt gebruikersmachtigingen controleren met de Get-PSSessionConfiguration-cmdlet .

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

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

Als u wilt wijzigen welke gebruikers toegang hebben, voert u een Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI interactieve prompt uit of Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> werkt u de machtigingen bij. Gebruikers hebben ten minste aanroeprechten nodig om toegang te krijgen tot het JEA-eindpunt.

Het is mogelijk om een JEA-eindpunt te maken dat geen gedefinieerde rol toe wijst aan elke gebruiker die toegang heeft. Deze gebruikers kunnen een JEA-sessie starten, maar hebben alleen toegang tot de standaard-cmdlets. U kunt gebruikersmachtigingen in een JEA-eindpunt controleren door uit te voeren Get-PSSessionCapability. Zie Controle en rapportage over JEA voor meer informatie.

Rollen met minimale bevoegdheden

Bij het ontwerpen van JEA-rollen is het belangrijk om te onthouden dat de virtuele en door groepen beheerde serviceaccounts achter de schermen onbeperkte toegang hebben tot de lokale machine. MET JEA-rolmogelijkheden kunt u de opdrachten en toepassingen beperken die kunnen worden uitgevoerd in die bevoegde context. Onjuist ontworpen rollen kunnen gevaarlijke opdrachten toestaan waarmee een gebruiker de JEA-grenzen kan verbreken of toegang kan krijgen tot gevoelige informatie.

Denk bijvoorbeeld aan de volgende vermelding voor rolmogelijkheden:

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

Met deze functie kunnen gebruikers elke PowerShell-cmdlet uitvoeren met het zelfstandig naamwoordproces vanuit de module Microsoft.PowerShell.Management . Gebruikers moeten mogelijk toegang krijgen tot cmdlets om Get-Process te zien welke toepassingen op het systeem worden uitgevoerd en Stop-Process om toepassingen te beëindigen die niet reageren. Deze vermelding staat echter ook toe Start-Process, dat kan worden gebruikt om een willekeurig programma te starten met volledige beheerdersmachtigingen. Het programma hoeft niet lokaal op het systeem te worden geïnstalleerd. Een verbonden gebruiker kan een programma starten vanuit een bestandsshare die de gebruiker lokale beheerdersbevoegdheden geeft, malware uitvoert en meer.

Een veiligere versie van dezelfde functiefunctie ziet er als volgt uit:

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

Vermijd het gebruik van jokertekens in functiemogelijkheden. Zorg ervoor dat u regelmatig effectieve gebruikersmachtigingen controleert om te begrijpen welke opdrachten toegankelijk zijn voor de gebruiker.

JEA beschermt niet tegen beheerders

Een van de belangrijkste principes van JEA is dat niet-beheerders bepaalde beheertaken kunnen uitvoeren. JEA beschermt niet tegen gebruikers die al beheerdersbevoegdheden hebben. Gebruikers die domeinadministratoren, lokale beheerders of andere groepen met hoge bevoegdheden zijn, kunnen de beveiliging van JEA omzeilen via een andere methode. Ze kunnen zich bijvoorbeeld aanmelden met RDP, externe MMC-consoles gebruiken of verbinding maken met niet-getrainde PowerShell-eindpunten. Lokale beheerders op een systeem kunnen OOK JEA-configuraties wijzigen om extra gebruikers toe te staan of een functiefunctie te wijzigen om het bereik van wat een gebruiker in zijn JEA-sessie kan doen, uit te breiden. Het is belangrijk om de uitgebreide machtigingen van uw JEA-gebruikers te evalueren om te zien of er andere manieren zijn om bevoegde toegang tot het systeem te krijgen.

Een veelvoorkomende gewoonte is om JEA te gebruiken voor regelmatig dagelijks onderhoud en een Just-In-Time-oplossing voor bevoegde toegangsbeheer te hebben waarmee gebruikers tijdelijk lokale beheerders kunnen worden in noodgevallen. Dit helpt ervoor te zorgen dat gebruikers geen permanente beheerders op het systeem zijn, maar deze rechten kunnen verkrijgen als en alleen wanneer ze een werkstroom voltooien die hun gebruik van deze machtigingen documenteert.