Consideraciones de seguridad de JEA

JEA le ayuda a mejorar la posición de seguridad al reducir el número de administradores permanentes en las máquinas. JEA usa 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 privilegios elevados, pero no ilimitados, se puede conceder acceso a la máquina para realizar tareas administrativas al punto de conexión de JEA. Puesto que JEA permite a estos usuarios ejecutar comandos administrativos sin tener acceso de administrador completo, puede quitar esos usuarios de grupos de seguridad con privilegios elevados.

Cuenta Run-As

Cada punto de conexión de JEA tiene una cuenta de ejecución como 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 sesión y la cuenta que elija tiene un impacto significativo en la seguridad del punto de conexión.

Las cuentas virtuales son la manera recomendada de configurar la cuenta run-as. Las cuentas virtuales son cuentas locales temporales de un solo uso que se crean para que el usuario que se conecte use durante la sesión de JEA. En cuanto finalice la sesión, la cuenta virtual se destruye y ya no se puede usar. El usuario que se conecta no conoce las credenciales de la cuenta virtual. La cuenta virtual no se puede usar para acceder al sistema a través de otros medios, como Escritorio remoto o un punto de conexión de PowerShell sin restricciones.

De forma predeterminada, las cuentas virtuales son miembros del grupo administradores local en la máquina. Esta pertenencia les da derechos completos para administrar cualquier cosa en el sistema, pero no tiene derechos para administrar recursos en la red. Cuando el usuario se conecta a otras máquinas desde la sesión de JEA, el contexto de usuario es el de la cuenta de equipo local, no la cuenta virtual.

Los controladores de dominio son un caso especial, ya que no hay un grupo de administradores local. En su lugar, las cuentas virtuales pertenecen a administradores de dominio y pueden administrar los servicios de directorio en el controlador de dominio. La identidad de dominio todavía está restringida para su uso en el controlador de dominio donde se inició la sesión de JEA. En su lugar, parece que cualquier acceso a la red procede del objeto de equipo 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 de dominio o local. Si ya tiene un grupo de seguridad definido para los administradores, conceda la pertenencia a la cuenta virtual a ese grupo. La pertenencia a grupos para cuentas virtuales está limitada a grupos de seguridad locales en servidores miembros y estaciones de trabajo. En los controladores de dominio, las cuentas virtuales deben ser miembros de grupos de seguridad de dominio. Una vez agregada la cuenta virtual a uno o varios grupos de seguridad, ya no pertenece a los grupos predeterminados (administradores de dominio o locales).

En la tabla siguiente se resumen las posibles opciones de configuración y los permisos resultantes para las cuentas virtuales:

Tipo de equipo	Configuración del grupo de cuentas virtuales	Contexto de usuario local	Contexto de usuario de red
Controlador de dominio	Predeterminado	Usuario de dominio, miembro de <DOMAIN>\Domain Admins	Cuenta de equipo
Controlador de dominio	Grupos de dominio A y B	Usuario de dominio, miembro de <DOMAIN>\A, <DOMAIN>\B	Cuenta de equipo
Servidor miembro o estación de trabajo	Predeterminado	Usuario local, miembro de BUILTIN\Administrators	Cuenta de equipo
Servidor miembro o estación de trabajo	Grupos locales C y D	Usuario local, miembro de <COMPUTER>\C y <COMPUTER>\D	Cuenta de equipo

Al examinar los registros de eventos de auditoría de seguridad y aplicación, verá 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 de conexión de JEA al usuario original que ejecutó el comando. Los nombres de cuenta virtual siguen el formato WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> Por ejemplo, si el usuario Alice en el dominio Contoso reinicia un servicio en un punto de conexión de JEA, el nombre de usuario asociado a cualquier evento del administrador de control de servicios sería WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Las cuentas de servicio administradas por grupos (gMSA) son útiles cuando un servidor miembro necesita tener acceso a los recursos de red en la sesión de JEA. Por ejemplo, cuando se usa un punto de conexión de JEA para controlar el acceso a un servicio de API REST hospedado en otra máquina. 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 grupos permite que el segundo salto sea posible al tiempo que mantiene el control sobre qué equipos pueden usar la cuenta. Las pertenencias a grupos de seguridad (locales o de dominio) de la gMSA definieron los permisos efectivos para la cuenta de gMSA.

Cuando se configura un punto de conexión de JEA para usar una gMSA, las acciones de todos los usuarios de JEA parecen proceder de la misma gMSA. La única manera de realizar un seguimiento de las acciones a 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 usan cuando no se especifica una cuenta como. PowerShell usa la credencial del usuario de conexión para ejecutar comandos en el servidor remoto. Para usar credenciales de paso a través, debe conceder al usuario que conecta el acceso directo a los grupos de administración con privilegios. No se recomienda esta configuración para JEA. Si el usuario que se conecta ya tiene privilegios de administrador, puede omitir JEA y administrar el sistema mediante otros métodos de acceso.

Las cuentas de ejecución estándar permiten especificar cualquier cuenta de usuario con la que se ejecute toda la sesión de PowerShell. Las configuraciones de sesión que usan cuentas de run-as fijas (con el -RunAsCredential parámetro) no son compatibles con JEA. Las definiciones de roles ya no funcionan según lo previsto. A cada usuario autorizado para acceder al punto de conexión se le asigna el mismo rol.

No debe usar runAsCredential en un punto de conexión de JEA porque es difícil realizar un seguimiento de las acciones a usuarios específicos y carece de compatibilidad con la asignación de usuarios a roles.

ACL de punto de conexión de WinRM

Al igual que con los puntos de conexión remoto de PowerShell normales, cada punto de conexión de JEA tiene una lista de control de acceso (ACL) independiente que controla quién puede autenticarse con el punto de conexión de JEA. Si no está configurado correctamente, es posible que los usuarios de confianza no puedan acceder al punto de conexión de JEA y es posible que los usuarios que no sean de confianza tengan acceso. La ACL de WinRM no afecta a la asignación de usuarios a roles de JEA. La asignación se controla mediante el campo RoleDefinitions del archivo de configuración de sesión que se usa para registrar el punto de conexión.

De forma predeterminada, cuando un punto de conexión de JEA tiene varias funcionalidades de rol, la ACL de WinRM está configurada para permitir el acceso a todos los usuarios asignados. Por ejemplo, una sesión de JEA configurada mediante los siguientes comandos concede 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'

Puede auditar los permisos de usuario con el cmdlet Get-PSSessionConfiguration .

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

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

Para cambiar qué usuarios tienen acceso, ejecute Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI para un aviso interactivo o Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> para actualizar los permisos. Los usuarios necesitan al menos derechos de invocación para acceder al punto de conexión de JEA.

Es posible crear un punto de conexión de JEA que no asigne un rol definido a cada usuario que tenga acceso. Estos usuarios pueden iniciar una sesión de JEA, pero solo tienen acceso a los cmdlets predeterminados. Puede auditar los permisos de usuario en un punto de conexión de JEA ejecutando Get-PSSessionCapability. Para obtener más información, consulte Auditoría e informes sobre JEA.

Roles con privilegios mínimos

Al diseñar roles de JEA, es importante recordar que las cuentas de servicio administradas por grupos y virtuales que se ejecutan en segundo plano pueden tener acceso sin restricciones a la máquina local. Las funcionalidades de rol de JEA ayudan a limitar los comandos y las aplicaciones que se pueden ejecutar en ese contexto con privilegios. Los roles diseñados incorrectamente pueden permitir comandos peligrosos que puedan permitir que un usuario salga de los límites de JEA o obtenga acceso a información confidencial.

Por ejemplo, considere la siguiente entrada de funcionalidad de rol:

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

Esta funcionalidad de rol permite a los usuarios ejecutar cualquier cmdlet de PowerShell con el nombre Process desde el módulo Microsoft.PowerShell.Management . Es posible que los usuarios necesiten acceder a cmdlets como Get-Process para ver qué aplicaciones se ejecutan en el sistema y Stop-Process eliminar las aplicaciones que no responden. Sin embargo, esta entrada también permite Start-Process, que se puede usar para iniciar un programa arbitrario con permisos de administrador completos. No es necesario instalar el programa localmente en el sistema. Un usuario conectado podría iniciar un programa desde un recurso compartido de archivos que proporcione a los usuarios privilegios de administrador local, ejecuta malware y mucho más.

Una versión más segura de esta misma funcionalidad de rol tendría el siguiente aspecto:

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

Evite usar caracteres comodín en las funcionalidades de rol. Asegúrese de auditar periódicamente los permisos de usuario efectivos para ver qué comandos son accesibles para un usuario. Para obtener más información, consulte la sección Comprobar derechos efectivos del artículo Auditoría e informes sobre JEA .

Mejores prácticas recomendadas

A continuación se muestran recomendaciones de procedimientos recomendados para garantizar la seguridad de los puntos de conexión de JEA:

Limitar el uso y las funcionalidades de los proveedores de PowerShell

Revise cómo se usan los proveedores permitidos para asegurarse de que no cree vulnerabilidades en la sesión configurada.

Advertencia

No permite al proveedor FileSystem. Si los usuarios pueden escribir en cualquier parte del sistema de archivos, es posible omitir completamente la seguridad.

No permita el proveedor de certificados . Con el proveedor habilitado, un usuario podría obtener acceso a las claves privadas almacenadas.

No permita comandos que puedan crear nuevos espacios de ejecución.

Advertencia

Los *-Job cmdlets pueden crear nuevos espacios de ejecución sin restricciones.

No permita el Trace-Command comando.

Advertencia

El uso de Trace-Command trae todos los comandos de rastreo a la sesión.

No cree sus propias implementaciones de proxy para los comandos restringidos.

PowerShell tiene un conjunto de comandos de proxy para escenarios de comandos restringidos. Estos comandos de proxy garantizan que los parámetros de entrada no puedan poner en peligro la seguridad de la sesión. Los siguientes comandos tienen restricción de proxy.

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

Si crea su propia implementación de estos comandos, puede permitir accidentalmente que los usuarios ejecuten código prohibido por los comandos proxy de JEA.

JEA no protege contra los administradores

Uno de los principios básicos de JEA es que permite a los no administradores realizar algunas tareas administrativas. JEA no protege contra los usuarios que ya tienen privilegios de administrador. Los usuarios que pertenecen a administradores de dominio, administradores locales u otros grupos con privilegios elevados pueden eludir las protecciones de JEA de otras maneras. Por ejemplo, podrían iniciar sesión con RDP, usar consolas MMC remotas o conectarse a puntos de conexión de PowerShell sin restricciones. Además, el administrador local de un sistema puede modificar las configuraciones de JEA para agregar más usuarios o cambiar una funcionalidad de rol para ampliar el ámbito de lo que un usuario puede hacer en su sesión de JEA. Es importante evaluar los permisos extendidos de los usuarios de JEA para ver si hay otras formas de obtener acceso con privilegios al sistema.

Además de usar JEA para el mantenimiento diario normal, es habitual tener un sistema de administración de acceso con privilegios Just-In-Time. Estos sistemas permiten a los usuarios designados convertirse temporalmente en un administrador local solo después de completar un flujo de trabajo que documente su uso de esos permisos.