JEA beveiligingsoverwegingenJEA Security Considerations

Van toepassing op: Windows PowerShell 5.0Applies to: Windows PowerShell 5.0

JEA helpt u bij uw beveiligingspostuur verbeteren door het aantal permanente beheerders op uw computers te verminderen.JEA helps you improve your security posture by reducing the number of permanent administrators on your machines. Dit gebeurt door het maken van een nieuw toegangspunt voor gebruikers voor het beheren van het systeem (een PowerShell-sessie configuration) nauw standaard om te voorkomen dat misbruik wordt vergrendeld.It does so by creating a new entry point for users to manage the system (a PowerShell session configuration) which is tightly locked down by default to prevent misuse. Gebruikers die sommige, maar niet nodig hebben onbeperkte toegang tot de computer voor het uitvoeren van beheertaken kan toegang tot het eindpunt JEA worden verleend.Users who need some, but not unlimited, access to the machine to perform administrative tasks can be granted access to the JEA endpoint. JEA kunnen deze opdrachten uit te voeren admin zonder rechtstreeks beheerderstoegang, kunt u vervolgens die gebruikers verwijderen uit maximaal bevoorrechte beveiligingsgroepen (zodat ze kunnen gebruikers standaard).Because JEA allows them to run admin commands without directly having admin access, you can then remove those users from highly privileged security groups (make them standard users).

Dit onderwerp beschrijft de JEA beveiligingsmodel en best practices in meer detail.This topic describes the JEA security model and best practices in more detail.

Run As-accountRun As account

Elk eindpunt JEA heeft een aangewezen 'uitvoeren als'-account, dat het account waaronder de gebruiker verbinding maakt acties worden uitgevoerd.Each JEA endpoint has a designated "run as" account, which is the account under which the connecting user's actions are performed. Dit account is geconfigureerd in de sessie configuratiebestand, en het account dat u kiest een grote invloed heeft op de beveiliging van uw eindpunt.This account is configurable in the session configuration file, and the account you choose has a significant bearing on the security of your endpoint.

Virtuele accounts zijn de aanbevolen manier van het configureren van het run as-account.Virtual accounts are the recommended way of configuring the run as account. Virtuele accounts zijn eenmalige, tijdelijke lokale accounts die zijn gemaakt voor de gebruiker verbinding probeert te maken voor gebruik tijdens de duur van hun JEA-sessie.Virtual accounts are one-time, temporary local accounts that are created for the connecting user to use during the duration of their JEA session. Zodra de sessie wordt beëindigd, wordt de virtuele-account wordt vernietigd en kan niet meer worden gebruikt.As soon as their session is terminated, the virtual account will be destroyed and cannot be used anymore. De gebruiker verbinding maakt niet de referenties voor de virtuele account weet en virtueel account toegang tot het systeem via andere middelen, zoals Extern bureaublad of een onbeperkte PowerShell-eindpunt niet gebruiken.The connecting user does not know the credentials for the virtual account and cannot use the virtual account to access the system via other means, such as Remote Desktop or an unconstrained PowerShell endpoint.

Standaard worden virtuele accounts behoren tot de lokale groep administrators op de machine.By default, virtual accounts belong to the local administrators group on the machine. Dit geeft ze volledige rechten voor het beheren van op het systeem, maar geen rechten voor het beheren van bronnen op het netwerk.This gives them full rights to manage anything on the system, but no rights to manage resources on the network. Bij de verificatie met andere virtuele machines, worden de context van de gebruiker die het lokale computeraccount niet de virtueel account.When authenticating with other machines, the user context will be that of the local computer account, not the virtual account.

Domeincontrollers zijn een speciaal geval, omdat er geen concept van een lokale groep administrators.Domain controllers are a special case since there is no concept of a local administrators group. In plaats daarvan virtuele accounts in plaats daarvan behoren tot Domeinadministrators en de directoryservices op de domeincontroller kunnen beheren.Instead, virtual accounts belong to Domain Admins instead and can manage the directory services on the domain controller. De identiteit van het domein is nog steeds beperkt tot het op de domeincontroller waar de sessie JEA is geïnstantieerd en toegang tot het netwerk wordt weergegeven in plaats daarvan afkomstig zijn van de computer van het domeincontrollerobject gebruiken.The domain identity is still restricted to use on the domain controller where the JEA session was instantiated, and any network access will appear to come from the domain controller computer object instead.

In beide gevallen kunt u ook expliciet welke beveiligingsgroepen virtueel account tot behoren moet definiëren.In both cases, you can also explicitly define which security groups the virtual account should belong to. Dit is een goede gewoonte wanneer de taak die u uitvoert zonder lokale/of domein beheerdersbevoegdheden kan worden gedaan.This is a good practice when the task you are performing can be done without local/domain admin privileges. Als u al een beveiligingsgroep die is gedefinieerd voor uw beheerders hebt, kunt u gewoon het lidmaatschap van de virtueel account verlenen aan die groep hieraan de machtigingen die nodig is.If you already have a security group defined for your admins, you can simply grant the virtual account membership to that group to give it the permissions it needs. Virtueel account lidmaatschap is beperkt tot lokale beveiligingsgroepen op werkstation en servers, maar op een domeincontroller alleen kan worden lid van domein, beveiligingsgroepen.Virtual account group membership is limited to local security groups on workstation and member servers, but on a domain controller they can only be members of domain security groups. Wanneer u een of meer beveiligingsgroepen voor de virtuele-account om u te behoren tot opgeeft, wordt deze niet langer hoort bij de standaardgroepen (lokale Administrators of domeinbeheerder).Once you specify one or more security groups for the virtual account to belong to, it will no longer belong to the default groups (local admin or domain admin).

De onderstaande tabel bevat een overzicht van de mogelijke configuratie-opties en de resulterende machtigingen voor virtuele accountsThe table below summarizes the possible configuration options and resulting permissions for virtual accounts

Het computertypeComputer type Configuratie van virtueel accountVirtual account group configuration Lokale gebruikerscontextLocal user context Netwerk gebruikerscontextNetwork user context
DomeincontrollerDomain controller StandaardinstellingDefault Domeingebruiker, lid is van 'domein\Domain Admins'Domain user, member of 'DOMAIN\Domain Admins' ComputeraccountComputer account
DomeincontrollerDomain controller Domeingroepen A en BDomain groups A and B Domeingebruiker, lid is van 'domein\A ','domein\ber 'Domain user, member of 'DOMAIN\A', 'DOMAIN\B' ComputeraccountComputer account
Lidserver of werkstationMember server or workstation StandaardinstellingDefault Lokale gebruiker, lid is van 'BUILTIN\Administrators'Local user, member of 'BUILTIN\Administrators' ComputeraccountComputer account
Lidserver of werkstationMember server or workstation Lokale groepen C en DLocal groups C and D Lokale gebruiker, lid is van 'COMPUTER\C' en 'COMPUTER\D'Local user, member of 'COMPUTER\C' and 'COMPUTER\D' ComputeraccountComputer account

Als u gebeurtenissen voor beveiligingscontrole en de gebeurtenislogboeken van toepassingen bekijkt, ziet u dat elke gebruiker JEA sessie een uniek virtueel account heeft.When you look at security audit events and application event logs, you will see that each JEA user session has a unique virtual account. Zo kunt u gebruikersacties in een eindpunt JEA terug naar de oorspronkelijke gebruiker die de opdracht uitvoert.This helps you track user actions in a JEA endpoint back to the original user who ran the command. Virtueel account namen volgt u de indeling ' WinRM virtuele gebruikers\WinRM_VA_ACCOUNTNUMBER_domein _ sAMAccountName' als gebruiker "Els' in 'Contoso' domein opnieuw wordt opgestart een service in een eindpunt JEA, de gebruikersnaam die is gekoppeld aan de service control manager gebeurtenissen zou bijvoorbeeld ' WinRM virtuele gebruikers\WinRM_ VA_1_contoso_Els '.Virtual account names follow the format "WinRM Virtual Users\WinRM_VA_ACCOUNTNUMBER_DOMAIN_sAMAccountName" For example, if user "Alice" in domain "Contoso" restarts a service in a JEA endpoint, the username associated with any service control manager events would be "WinRM Virtual Users\WinRM_VA_1_contoso_alice".

Groep beheerde serviceaccounts (gmsa's) zijn nuttig wanneer er een lidserver moet toegang hebben tot netwerkbronnen in de sessie JEA.Group managed service accounts (gMSAs) are useful when a member server needs to have access to network resources in the JEA session. Een voorbeeld gebruiksvoorbeeld voor dit is een JEA-eindpunt dat wordt gebruikt voor toegang tot een REST-API die worden gehost op een andere computer beheren.An example use case for this is a JEA endpoint that is used to control access to a REST API hosted on a different machine. Het is gemakkelijk om te schrijven functies om de gewenste aanroepen in de REST-API, maar om te verifiëren met de API die u moeten een netwerk-id.It is easy to write functions to make the desired invocations on the REST API, but in order to authenticate with the API you need a network identity. Met behulp van een groep beheerd serviceaccount, maakt de 'tweede hop' mogelijk en toch hebben besturingselement gedurende welke computers de account kunnen gebruiken.Using a group managed service account makes the "second hop" possible while still having control over which computers can use the account. De effectieve machtigingen van de gMSA worden gedefinieerd door de beveiligingsgroepen (lokaal of domeinbeheerder) waarbij het gMSA-account hoort.The effective permissions of the gMSA are defined by the security groups (local or domain) to which the gMSA account belongs.

Wanneer een JEA-eindpunt is geconfigureerd voor gebruik van een beheerd serviceaccount, verschijnt de acties van gebruikers met alle JEA afkomstig zijn van dezelfde groep beheerd serviceaccount.When a JEA endpoint is configured to use a gMSA account, the actions of all JEA users will appear to come from the same group managed service account. De enige manier kunt u acties terug naar een specifieke gebruiker traceren is het identificeren van de reeks opdrachten uitvoert in de tekst van een PowerShell-sessie.The only way you can trace actions back to a specific user is to identify the set of commands run in a PowerShell session transcript.

-Passthrough referenties worden gebruikt wanneer u niet opgeven van een run as-account en wilt dat PowerShell te gebruiken referenties van de gebruiker van de verbindende opdrachten uit te voeren op de externe server.Pass-thru credentials are used when you do not specify a run as account and want PowerShell to use the connecting user's credential to run commands on the remote server. Deze configuratie is niet voor JEA wordt aanbevolen als u de verbindende gebruiker direct toegang verlenen tot bevoegde beheergroepen zou moeten.This configuration is not recommended for JEA as it would require you to grant the connecting user direct access to privileged management groups. Als de gebruiker verbinding maakt al beheerdersbevoegdheden, kunnen JEA helemaal te voorkomen en beheren van het systeem via andere, onbeperkte middelen.If the connecting user already has admin privileges, they can avoid JEA altogether and manage the system via other, unconstrained means. Zie de sectie hieronder voor het JEA biedt geen bescherming tegen admins voor meer informatie.See the section below on how JEA does not protect against admins for more information.

Standaard run as-accounts kunt u opgeven van een gebruikersaccount op waaronder de gehele PowerShell-sessie wordt uitgevoerd.Standard run as accounts allow you to specify any user account under which the entire PowerShell session will run. Dit is een belangrijk verschil, omdat een sessieconfiguratie is ingesteld op een vaste run as-account gebruiken (met de -RunAsCredential parameter) is niet JEA-bewust.This is an important distinction, because a session configuration set to use a fixed run as account (with the -RunAsCredential parameter) is not JEA-aware. Dat betekent dat roldefinities niet meer werkt zoals verwacht, en elke gebruiker die toegang hebben tot het eindpunt wordt dezelfde rol worden toegewezen.That means that role definitions no longer function as expected, and every user authorized to access the endpoint will be assigned the same role.

U moet een RunAsCredential niet gebruiken op een eindpunt JEA vanwege de problemen bij het traceren van acties weer voor specifieke gebruikers en het ontbreken van ondersteuning voor het toewijzen van gebruikers aan rollen.You should not use a RunAsCredential on a JEA endpoint because of the difficulty in tracing actions back to specific users and the lack of support for mapping users to roles.

WinRM ACL voor eindpuntenWinRM Endpoint ACL

Als met de reguliere PowerShell remoting eindpunten, elk eindpunt JEA een afzonderlijke toegangsbeheerlijst (ACL heeft) instellen in de WinRM-configuratie die bepaalt kunnen die worden geverifieerd met het eindpunt JEA.As with regular PowerShell remoting endpoints, each JEA endpoint has a separate access control list (ACL) set in the WinRM configuration that controls who can authenticate with the JEA endpoint. Als u niet goed geconfigureerd, vertrouwde gebruikers wellicht geen toegang krijgen tot het eindpunt JEA en/of niet-vertrouwde gebruikers toegang kunnen krijgen.If improperly configured, trusted users may not be able to access the JEA endpoint and/or untrusted users may gain access. De WinRM-ACL bepaalt echter niet het geval is, de toewijzing van gebruikers aan rollen JEA.The WinRM ACL does not, however, affect the mapping of users to JEA roles. Die wordt beheerd door de RoleDefinitions veld in het configuratiebestand van de sessie die is geregistreerd op het systeem.That is controlled by the RoleDefinitions field in the session configuration file that was registered on the system.

Standaard, wanneer u registreert een JEA-eindpunt met een configuratiebestand sessie als een of meer mogelijkheden voor rol, wordt de WinRM-ACL worden geconfigureerd, zodat alle gebruikers toewijzen aan een of meer rollen-toegang tot het eindpunt.By default, when you register a JEA endpoint using a session configuration file and one or more role capabilities, the WinRM ACL will be configured to allow all users mapping to one or more roles access to the endpoint. Bijvoorbeeld, een JEA-sessie die is geconfigureerd met behulp van de volgende opdrachten wordt volledige toegang verlenen tot CONTOSO\JEA_Lev1 en CONTOSO\JEA_Lev2.For example, a JEA session configured using the following commands will grant full access to CONTOSO\JEA_Lev1 and 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 controleren de machtigingen van gebruiker met de Get-PSSessionConfiguration cmdlet.You can audit user permissions with the Get-PSSessionConfiguration cmdlet.

PS C:\> Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

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

Als u wilt wijzigen welke gebruikers toegang hebben, voer een Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI voor een interactieve prompt of Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> de machtigingen bijwerken.To change which users have access, run either Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI for an interactive prompt or Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> to update the permissions. Gebruikers moeten ten minste Invoke rechten voor toegang tot het eindpunt JEA.Users need at least Invoke rights to access the JEA endpoint.

Als extra gebruikers toegang tot het eindpunt JEA krijgen maar niet in een van de rollen gedefinieerd in het configuratiebestand van de sessie vallen, worden ze kunnen een JEA-sessie starten, maar hebben alleen toegang tot de standaard-cmdlets.If additional users are granted access to the JEA endpoint but do not fall into any of the roles defined in the session configuration file, they will be able to start a JEA session but only have access to the default cmdlets. U kunt de gebruikersmachtigingen in een eindpunt JEA controleren door te voeren Get-PSSessionCapability.You can audit user permissions in a JEA endpoint by running Get-PSSessionCapability. Bekijk de controle en rapportage over JEA artikel voor meer informatie over controle en die opdrachten van een gebruiker toegang heeft tot in een JEA-eindpunt.Check out the Auditing and Reporting on JEA article for more information about auditing which commands a user has access to in a JEA endpoint.

Minimale bevoegdheid rollenLeast privilege roles

Bij het ontwerpen van JEA rollen, is het belangrijk te weten dat de virtuele of groep beheerde service-account met achter de schermen vaak onbeperkte toegang tot het beheer van de lokale computer heeft.When designing JEA roles, it is important to remember that the virtual or group managed service account running behind the scenes often has unrestricted access to manage the local machine. JEA rol mogelijkheden te beperken waarvoor dat account kan worden gebruikt door het beperken van de opdrachten en toepassingen die kunnen worden uitgevoerd met behulp van die bevoegde context.JEA role capabilities help restrict what that account can be used for by limiting the commands and applications that can be run using that privileged context. Onjuist ontworpen rollen kunt gevaarlijke opdrachten die een gebruiker kan opsplitsen buiten de grenzen JEA of toegang krijgen tot gevoelige informatie.Improperly designed roles can allow dangerous commands to run that may allow a user to break out of the JEA boundaries or obtain access to sensitive information.

Neem bijvoorbeeld de volgende vermelding van de rol-functionaliteit:For example, consider the following role capability entry:

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

Deze mogelijkheid rol kan gebruikers een PowerShell-cmdlet uitvoeren met het zelfstandig naamwoord 'Proces' van de module Microsoft.PowerShell.Management.This role capability allows users to run any PowerShell cmdlet with the noun "Process" from the Microsoft.PowerShell.Management module. Gebruikers hebben mogelijk nodig voor toegang tot cmdlets, zoals Get-Process om te begrijpen welke toepassingen worden uitgevoerd op het systeem en Stop-Process afsluiten een vastgelopen toepassingen.Users may need to access cmdlets like Get-Process to understand what applications are running on the system and Stop-Process to kill any hung applications. Deze vermelding ook kan echter Start-Process, die kan worden gebruikt om op te starten met volledige administrator-machtigingen van een willekeurige programma.However, this entry also allows Start-Process, which can be used to start up an arbitrary program with full administrator permissions. Het programma niet moet lokaal op het systeem worden geïnstalleerd zodat een adversary kan een programma te starten op een bestandsshare waarmee de verbindende gebruikersbevoegdheden voor lokale beheerder en schadelijke software wordt uitgevoerd.'The program doesn't need to be installed locally on the system, so an adversary could simply start a program on a file share that gives the connecting user local admin privileges, runs malware, and more.'

Een beter beveiligde versie van deze mogelijkheid met dezelfde functie eruit als:A more secure version of this same role capability would look like:

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

Vermijd het gebruik van jokertekens in de mogelijkheden van de rol en zorg ervoor dat effectieve machtigingen van de audit regelmatig om te begrijpen die opdrachten van een gebruiker toegang heeft tot.Avoid using wildcards in role capabilities, and be sure to audit effective user permissions regularly to understand which commands a user has access to.

JEA biedt geen bescherming tegen beheerdersJEA does not protect against admins

Een van de belangrijkste principes van JEA is dat kunnen niet-beheerders om uit te voeren sommige beheertaken.One of the core principles of JEA is that it allows non-admins to perform some admin tasks. JEA biedt geen bescherming tegen mensen die al administrator-bevoegdheden hebben.JEA does not protect against those who already have administrator privileges. Gebruikers die deel uitmaken van 'Domeinadministrators', 'lokale beheerders,' of andere maximaal bevoorrechte groepen in uw omgeving nog steeds mogelijk om op te halen om de bescherming van JEA wanneer u zich aanmeldt bij de computer via een andere manier.Users who belong "domain admins," "local admins," or other highly privileged groups in your environment will still be able to get around JEA's protections by signing into the machine via another means. Ze kunnen bijvoorbeeld aanmelden met RDP, externe MMC-consoles gebruiken of verbinding maken met onbeperkte PowerShell-eindpunten.They could, for example, sign in with RDP, use remote MMC consoles, or connect to unconstrained PowerShell endpoints. Lokale beheerder zijn op het systeem kunt JEA configuraties als u extra gebruikers beheren van het systeem of wijzigen van een rol mogelijkheid om uit te breiden het bereik van wat een gebruiker in hun sessie JEA doen kan mogen ook wijzigen.Local admins on the system can also modify JEA configurations to allow additional users to manage the system or change a role capability to extend the scope of what a user can do in their JEA session. Daarom is het belangrijk om te bepalen van uw gebruikers JEA uitgebreide machtigingen om te zien of er andere manieren ze kunnen bevoorrechte toegang krijgen tot het systeem.It is therefore important to evaluate your JEA users' extended permissions to see if there are other ways they could gain privileged access to the system.

Een gebruikelijk is JEA voor regelmatig onderhoud van de dagelijkse en hebben een 'just-in tijd' uitgebreide oplossing voor het beheer van toegang kunnen gebruikers zich tijdelijk worden lokale beheerders in noodsituaties.A common practice is to use JEA for regular day-to-day maintenance and have a "just in time" privileged access management solution allow users to temporarily become local admins in emergency situations. Dit zorgt ervoor gebruikers geen permanente beheerders op het systeem, maar deze rechten kunnen krijgen als en alleen wanneer ze een werkstroom die het gebruik van deze machtigingen documenten voltooien.This helps ensure users are not permanent admins on the system, but can get those rights if, and only when, they complete a workflow that documents their use of those permissions.