Beveiligingsoverwegingen voor JEA

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 beheeropdrachten uit te voeren zonder volledige beheerderstoegang te hebben, kunt u deze gebruikers vervolgens verwijderen uit beveiligingsgroepen met hoge bevoegdheden.

Uitvoeren als-account

Elk JEA-eindpunt heeft een aangewezen run-as-account waaronder de acties van de verbindende gebruiker 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 zijn standaard lid van de lokale groep Beheer istrators op de computer. Dit lidmaatschap geeft hen volledige rechten om alles op het systeem te beheren, maar geen rechten om resources in het netwerk te beheren. Wanneer de gebruiker verbinding maakt met andere machines vanuit de JEA-sessie, is de gebruikerscontext die van het lokale computeraccount, niet het virtuele account.

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

In beide gevallen kunt u het virtuele account toewijzen aan specifieke beveiligingsgroepen, met name 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 voor 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 domeinbeheerders).

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

Computertype	Configuratie van virtuele accountgroep	Lokale gebruikerscontext	Netwerkgebruikerscontext
Domeincontroller	Standaardinstelling	Domeingebruiker, lid van <DOMAIN>\Domain Admins	Computeraccount
Domeincontroller	Domeingroepen A en B	Domeingebruiker, lid van <DOMAIN>\A, <DOMAIN>\B	Computeraccount
Lidserver of werkstation	Standaardinstelling	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 beveiligingscontrole- en toepassingsgebeurtenislogboeken 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> . Als de gebruiker Alice in het domein Contoso bijvoorbeeld 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 een groep beheerd serviceaccount wordt de tweede hop mogelijk, terwijl u de controle behoudt over welke computers het account kunnen gebruiken. De lidmaatschappen van de beveiligingsgroep (lokaal of domein) van de gMSA hebben de effectieve machtigingen voor het gMSA-account gedefinieerd.

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 Transcriptie van een PowerShell-sessie.

Passthrough-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. Als u passthrough-referenties wilt gebruiken, moet u de gebruiker directe toegang verlenen tot bevoorrechte beheergroepen. Deze configuratie wordt NIET aanbevolen voor JEA. Als de gebruiker die verbinding maakt al beheerdersbevoegdheden heeft, kan deze JEA omzeilen en het systeem beheren met behulp van andere toegangsmethoden.

Met standard 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. Elke gebruiker die gemachtigd is voor toegang tot het eindpunt, krijgt dezelfde rol.

U moet geen RunAsCredential op een JEA-eindpunt gebruiken omdat het lastig 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) waarmee wordt bepaald wie zich 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 functiemogelijkheden heeft, is de WinRM ACL standaard geconfigureerd om toegang tot alle toegewezen gebruikers toe te staan. 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 Cmdlet Get-PSSessionConfiguration .

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 Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI u een interactieve prompt uit of Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> werkt u de machtigingen bij. Gebruikers hebben ten minste toegangsrechten 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 deze 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. UA-rolmogelijkheden helpen de opdrachten en toepassingen te beperken die in die bevoorrechte context kunnen worden uitgevoerd. Onjuist ontworpen rollen kunnen gevaarlijke opdrachten toestaan waarmee een gebruiker de GRENZEN van jeA kan verbreken of toegang kan krijgen tot gevoelige informatie.

Denk bijvoorbeeld aan de volgende vermelding van de functiefunctie:

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

Met deze functie kunnen gebruikers elke PowerShell-cmdlet uitvoeren met het zelfstandig naamwoordproces vanuit de microsoft.PowerShell.Management-module. 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 lokale beheerdersbevoegdheden van de gebruiker 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 zien welke opdrachten toegankelijk zijn voor een gebruiker. Zie de sectie Effectieve rechten controleren van het artikel Controle en rapportage over JEA voor meer informatie.

Aanbevelingen voor best practices

Hier volgen best practice-aanbevelingen om de beveiliging van uw JEA-eindpunten te garanderen:

Het gebruik en de mogelijkheden van PowerShell-providers beperken

Controleer hoe de toegestane providers worden gebruikt om ervoor te zorgen dat u geen beveiligingsproblemen maakt in uw geconfigureerde sessie.

Waarschuwing

Sta de bestandssysteemprovider niet toe. Als gebruikers naar een deel van het bestandssysteem kunnen schrijven, is het mogelijk om de beveiliging volledig te omzeilen.

Sta de certificaatprovider niet toe. Als de provider is ingeschakeld, kan een gebruiker toegang krijgen tot opgeslagen persoonlijke sleutels.

Sta geen opdrachten toe die nieuwe runspaces kunnen maken.

Waarschuwing

De *-Job cmdlets kunnen nieuwe runspaces maken zonder de beperkingen.

Sta de Trace-Command cmdlet niet toe.

Waarschuwing

Door Trace-Command alle traceringsopdrachten in de sessie te gebruiken.

Maak geen eigen proxy-implementaties voor de beperkte opdrachten.

PowerShell heeft een set proxyopdrachten voor beperkte opdrachtscenario's. Deze proxyopdrachten zorgen ervoor dat invoerparameters geen inbreuk kunnen maken op de beveiliging van de sessie. De volgende opdrachten hebben beperkte proxy's:

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

Als u uw eigen implementatie van deze opdrachten maakt, kunt u per ongeluk toestaan dat gebruikers code uitvoeren die niet is toegestaan door de JEA-proxyopdrachten.

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 lid zijn van domein Beheer s, lokale Beheer istrators of andere groepen met hoge bevoegdheden kunnen de beveiliging van JEA op andere manieren omzeilen. Ze kunnen zich bijvoorbeeld aanmelden met RDP, externe MMC-consoles gebruiken of verbinding maken met niet-verbonden PowerShell-eindpunten. Lokale beheerder op een systeem kan OOK JEA-configuraties wijzigen om meer gebruikers toe te voegen of een rolmogelijkheid te wijzigen om het bereik van wat een gebruiker kan doen in hun JEA-sessie 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.

Naast het gebruik van JEA voor regelmatig dagelijks onderhoud, is het gebruikelijk om een Just-In-Time Privileged Access Management-systeem te hebben. Met deze systemen kunnen aangewezen gebruikers tijdelijk een lokale beheerder worden nadat ze een werkstroom hebben voltooid die hun gebruik van deze machtigingen documenteert.