Consideraciones de seguridad de JEA

JEA le ayuda a mejorar su postura de seguridad al reducir la cantidad de administradores permanentes en sus máquinas. JEA utiliza una configuración de sesión de PowerShell para crear un nuevo punto de entrada para que los usuarios administren el sistema. A los usuarios que necesitan acceso elevado, pero no ilimitado, a la máquina para realizar tareas administrativas se les puede otorgar acceso al punto final JEA. Dado que JEA permite a estos usuarios ejecutar comandos administrativos sin tener acceso completo de administrador, puede eliminar a esos usuarios de grupos de seguridad con privilegios elevados.

Cuenta de ejecución

Cada terminal JEA tiene una cuenta ejecutar designada bajo la cual se ejecutan las acciones del usuario que se conecta. Esta cuenta se puede configurar en el archivo de configuración de la sesión y la cuenta que elija tiene una influencia significativa en la seguridad de su punto final.

Las cuentas virtuales son la forma recomendada de configurar la cuenta ejecutar como. Las cuentas virtuales son cuentas locales temporales únicas que se crean para que el usuario que se conecta las use durante la duración de su sesión JEA. Tan pronto como finaliza su sesión, la cuenta virtual se destruye y ya no se puede utilizar. El usuario que se conecta no conoce las credenciales de la cuenta virtual. La cuenta virtual no se puede utilizar para acceder al sistema a través de otros medios como Escritorio remoto o un punto final de PowerShell sin restricciones.

De forma predeterminada, las cuentas virtuales son miembros del grupo Administradores local en la máquina. Esta membresía les otorga plenos derechos para administrar cualquier cosa en el sistema, pero ningún derecho para administrar los recursos en la red. Cuando el usuario se conecta a otras máquinas desde la sesión JEA, el contexto del usuario es el de la cuenta de la computadora local, no la cuenta virtual.

Los controladores de dominio son un caso especial ya que no existe un grupo de Administradores local. En cambio, las cuentas virtuales pertenecen a administradores de dominio y pueden administrar los servicios de directorio en el controlador de dominio. La identidad del dominio todavía está restringida para su uso en el controlador de dominio donde se creó una instancia de la sesión JEA. Cualquier acceso a la red parece provenir del objeto de computadora del controlador de dominio.

En ambos casos, puede asignar la cuenta virtual a grupos de seguridad específicos, especialmente cuando la tarea se puede realizar sin privilegios de administrador local o de dominio. Si ya tiene un grupo de seguridad definido para sus administradores, otorgue la membresía de la cuenta virtual a ese grupo. La membresía grupal para cuentas virtuales está limitada a grupos de seguridad locales en estaciones de trabajo y servidores miembros. En los controladores de dominio, las cuentas virtuales deben ser miembros de grupos de seguridad de dominio. Una vez que la cuenta virtual se ha agregado a uno o más grupos de seguridad, ya no pertenece a los grupos predeterminados (administradores locales o de dominio).

La siguiente tabla resume las posibles opciones de configuración y los permisos resultantes para cuentas virtuales:

Cuando observa la auditoría de seguridad y los registros de eventos de la aplicación, ve que cada sesión de usuario de JEA tiene una cuenta virtual única. Esta cuenta única le ayuda a realizar un seguimiento de las acciones del usuario en un punto final JEA hasta el usuario original que ejecutó el comando. Los nombres de las cuentas virtuales siguen el formato WinRM Virtual Users\WinRM_VA___ Por ejemplo, si el usuario Alice en el dominio Contoso reinicia un servicio en un punto final JEA, el nombre de usuario asociado con cualquier evento del administrador de control de servicios sería WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Las cuentas de servicio administradas por grupo (gMSA) son útiles cuando un servidor miembro necesita tener acceso a los recursos de la red en la sesión JEA. Por ejemplo, cuando se utiliza un punto final JEA para controlar el acceso a un servicio API REST alojado en una máquina diferente. Es fácil escribir funciones para invocar las API REST, pero necesita una identidad de red para autenticarse con la API. El uso de una cuenta de servicio administrada por grupo hace posible el segundo salto mientras se mantiene el control sobre qué computadoras pueden usar la cuenta. Las membresías del grupo de seguridad (local o de dominio) de gMSA definieron los permisos efectivos para la cuenta de gMSA.

Cuando un terminal JEA está configurado para utilizar un gMSA, las acciones de todos los usuarios de JEA parecen provenir del mismo gMSA. La única forma de rastrear acciones hasta un usuario específico es identificar el conjunto de comandos ejecutados en una transcripción de sesión de PowerShell.

Las credenciales de paso se utilizan cuando no se especifica una cuenta ejecutada. PowerShell utiliza la credencial del usuario que se conecta para ejecutar comandos en el servidor remoto. Para utilizar credenciales de paso, debe otorgar al usuario que se conecta acceso directo a grupos de administración privilegiados. Esta configuración NO se recomienda para JEA. Si el usuario que se conecta ya tiene privilegios de administrador, puede omitir JEA y administrar el sistema utilizando otros métodos de acceso.

Las cuentas de ejecución estándar le permiten especificar cualquier cuenta de usuario bajo la cual se ejecuta toda la sesión de PowerShell. Las configuraciones de sesión que utilizan cuentas ejecutar como fijas (con el parámetro -RunAsCredential) no son compatibles con JEA. Las definiciones de roles ya no funcionan como se esperaba. A cada usuario autorizado para acceder al punto final se le asigna el mismo rol.

No debe utilizar RunAsCredential en un punto final JEA porque es difícil rastrear acciones hasta usuarios específicos y carece de soporte para asignar usuarios a roles.

ACL de punto final de WinRM

Al igual que con los puntos finales remotos de PowerShell habituales, cada punto final JEA tiene una lista de control de acceso (ACL) separada que controla quién puede autenticarse con el punto final JEA. Si se configura incorrectamente, es posible que los usuarios confiables no puedan acceder al punto final JEA, y los usuarios que no son confiables pueden tener acceso. La ACL de WinRM no afecta la asignación de usuarios a roles JEA. La asignación está controlada por el campo RoleDefinitions en el archivo de configuración de la sesión utilizado para registrar el punto final.

De forma predeterminada, cuando un punto final JEA tiene múltiples funciones, la ACL de WinRM está configurada para permitir el acceso a todos los usuarios asignados. Por ejemplo, una sesión JEA configurada mediante los siguientes comandos otorga acceso completo a CONTOSO\JEA_Lev1 y 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'

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

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

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

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