- JEA aplica el principio de menor privilegio en PowerShell remoting, reduciendo el número de cuentas con derechos elevados y limitando los cmdlets disponibles para cada rol.
- La combinación de archivos .psrc y .pssc permite definir capacidades de rol, endpoints restringidos, cuentas virtuales y transcripciones detalladas para una auditoría completa.
- Frente a enfoques como GPO, AppLocker o endpoints genéricos, JEA ofrece un control mucho más granular y un modelo RBAC sólido para delegar tareas sin exponer credenciales privilegiadas.
- Su correcta implantación exige diseño cuidadoso de roles, pruebas y mantenimiento continuo, pero aporta un refuerzo significativo de la seguridad sin sacrificar productividad.
El uso de PowerShell remoting se ha convertido en algo casi imprescindible en cualquier entorno Windows moderno, pero dar acceso remoto sin control es como dejar las llaves del CPD encima de la mesa. Aquí es donde entra en juego Just‑Enough‑Administration (JEA), una capa de seguridad que permite delegar tareas sin regalar derechos de administrador a diestro y siniestro.
Con JEA puedes montar puntos de acceso remotos muy acotados donde determinados usuarios ejecutan solo los comandos que tú has autorizado, bajo cuentas con más privilegios, pero sin conocer las credenciales reales ni poder salirse del guion. Y todo ello quedando registrado en transcripciones y logs detallados que luego te permiten auditar quién ha hecho qué, cuándo y desde dónde.
Qué es Just‑Enough‑Administration (JEA) y por qué importa
Just‑Enough‑Administration es una tecnología de seguridad basada en PowerShell que implementa un modelo de administración delegada con el mínimo privilegio necesario. En la práctica, JEA te deja exponer endpoints remotos en los que solo están disponibles un conjunto cerrado de cmdlets, funciones, scripts y comandos externos definidos por ti.
Gracias a este enfoque, puedes reducir drásticamente el número de cuentas con privilegios elevados en tus servidores, empleando cuentas virtuales o cuentas de servicio administradas por grupo (gMSA) que ejecutan acciones privilegiadas en nombre de usuarios estándar. El usuario entra con sus credenciales normales y, a través de la sesión JEA, lanza comandos que por debajo se ejecutan con más privilegios.
Otro pilar clave de JEA es la capacidad de limitar con precisión qué puede hacer cada rol. Mediante archivos de capacidad de rol defines qué cmdlets, qué funciones personalizadas, qué comandos externos o qué proveedores de PowerShell están visibles. El resto, simplemente, no existe para el usuario: no puede improvisar scripts, no puede navegar libremente por el sistema de archivos y no puede tocar servicios o procesos que no hayas previsto.
Además, todas las sesiones JEA pueden configurarse para generar transcripciones completas y eventos de auditoría, capturando comandos, parámetros, salidas, errores, identidad del usuario y tiempos de ejecución. Esto no solo ayuda a cumplir requisitos normativos, sino que también es oro puro cuando toca investigar un incidente de seguridad o un fallo de operación.
Riesgos de las cuentas privilegiadas y cómo JEA los mitiga
Las cuentas de administrador local, de dominio o de aplicación con permisos elevados suponen uno de los vectores de riesgo más serios en cualquier organización. Si un atacante se hace con una de estas credenciales, puede moverse lateralmente por la red, escalar privilegios y llegar a datos críticos, servicios clave o incluso tumbar sistemas completos.
Quitar privilegios no siempre es trivial. Un ejemplo clásico es el de un servidor que aloja a la vez DNS y un controlador de dominio de Active Directory. El equipo de DNS necesita permisos de administrador local para arreglar problemas en el servicio DNS, pero si los metes en el grupo Domain Admins les estás dando, de facto, control sobre todo el bosque y acceso a cualquier recurso de ese equipo. Es la típica situación en la que, por comodidad operativa, se sacrifica seguridad.
JEA resuelve este dilema aplicando a rajatabla el principio de menor privilegio. En vez de convertir a los administradores de DNS en Domain Admins, puedes crear un endpoint JEA específico para DNS que solo expone los cmdlets necesarios para limpiar caché, reiniciar el servicio, revisar registros o tareas similares. Así, el operador puede hacer su trabajo sin poder examinar Active Directory, sin navegar por el sistema de archivos, sin lanzar scripts aleatorios ni ejecutar utilidades peligrosas.
Cuando configuras las sesiones JEA para usar cuentas virtuales con permisos temporales, la jugada es todavía más interesante: el usuario se conecta con credenciales sin privilegios y, sin embargo, desde esa sesión puede ejecutar tareas que normalmente exigen derechos de administrador. Esto permite sacar a muchos usuarios de grupos de administradores locales o de dominio, manteniendo la operativa pero endureciendo muchísimo la superficie de ataque.
Conceptos de seguridad que sustentan JEA
JEA no surge de la nada: se apoya en varios principios y modelos de seguridad muy asentados que le dan coherencia y robustez. El primero es el ya mencionado principio de menor privilegio, que dicta que tanto usuarios como procesos deben tener solo los permisos imprescindibles para sus funciones.
El segundo gran pilar es el modelo de Role‑Based Access Control (RBAC). JEA implementa RBAC a través de archivos de capacidad de rol, donde defines qué puede hacer un rol específico dentro de una sesión remota. Por ejemplo, un rol de helpdesk puede listar servicios, ver eventos y reiniciar algún servicio concreto, mientras que un rol de administración de SQL Server podrá ejecutar solo cmdlets relacionados con bases de datos y poco más.
La base técnica de JEA es PowerShell y su infraestructura de remoting. PowerShell proporciona el lenguaje, los cmdlets y la capa de comunicación remota (WinRM/WS‑Management), y JEA añade por encima un sistema de puntos de conexión restringidos, cuentas virtuales y control detallado de qué comandos están disponibles.
Otro concepto importante es la administración restringida o constrained administration, similar a un acceso asignado en modo quiosco de Windows 11. En lugar de dar una shell completa a un operador, JEA construye una sesión donde el lenguaje de scripting está recortado (por defecto, NoLanguage), se bloquea la creación de funciones o variables nuevas, se vetan bucles y condicionales, y solo se permite ejecutar el conjunto de cmdlets aprobados. Esto limita mucho la capacidad de un atacante que consiga llegar a esa sesión.
Componentes clave: archivos .psrc y .pssc
El corazón de cualquier despliegue JEA son dos tipos de archivo: los archivos de capacidad de rol (.psrc) y los archivos de configuración de sesión (.pssc). Juntos convierten una shell generalista en un endpoint perfectamente acotado para ciertos usuarios.
En un archivo de capacidad de rol defines exactamente qué comandos están al alcance del rol. Entre los elementos más importantes destacan:
- VisibleCmdlets: lista de cmdlets permitidos, incluso pudiendo restringir parámetros.
- VisibleFunctions: funciones personalizadas que se cargan en la sesión.
- VisibleExternalCommands: ejecutables externos concretos a los que se da acceso.
- VisibleProviders: proveedores de PowerShell (por ejemplo, FileSystem o Registry) visibles en la sesión.
Los archivos de configuración de sesión .pssc, por su parte, describen el endpoint JEA como tal y lo vinculan con los roles. Aquí se declaran elementos como:
- RoleDefinitions: mapeo de usuarios o grupos de seguridad a capacidades de rol.
- SessionType: donde suele establecerse ‘RestrictedRemoteServer’ para endurecer la sesión.
- TranscriptDirectory: carpeta donde se guardan los transcript de cada sesión.
- RunAsVirtualAccount y opciones relacionadas, como si la cuenta virtual se agrega a grupos concretos.
JEA se materializa en forma de puntos de conexión de PowerShell remoting registrados en el sistema. Estos endpoints se crean y habilitan con cmdlets como New‑PSSessionConfigurationFile, Register‑PSSessionConfiguration o herramientas gráficas como el JEA Helper Tool, que facilita generar ficheros .pssc y .psrc sin pelear tanto con la sintaxis.
Ciclo de vida de una sesión JEA
A la hora de levantar un entorno JEA completo, el proceso suele seguir una serie de pasos lógicos que transforman un remoting abierto en uno estrictamente gobernado. La secuencia típica es:
En primer lugar, se crea un grupo de seguridad o varios grupos que representen los roles que quieres delegar (por ejemplo, HelpdeskDNS, OperadoresWeb, OperadoresSQL). No es obligatorio usar grupos, pero hace la administración mucho más sencilla cuando el entorno crece.
Después, se elaboran uno o más archivos de capacidad de rol .psrc que recogen las acciones permitidas: cmdlets, funciones, scripts, comandos externos, alias, proveedores y restricciones adicionales (parámetros concretos, rutas permitidas, etc.). Aquí se puede, por ejemplo, permitir todos los cmdlets que empiecen por Get‑, restringir Restart‑Service al servicio Spooler, y autorizar solo el proveedor FileSystem.
A continuación se genera un archivo de configuración de sesión .pssc usando New‑PSSessionConfigurationFile. En él se definen opciones como SessionType = RestrictedRemoteServer, la ruta de TranscriptDirectory, si se usan cuentas virtuales, y el bloque RoleDefinitions que vincula grupos a capacidades de rol, por ejemplo, ‘DOMINIO\HelpdeskDNS’ = @{ RoleCapabilities = ‘HelpdeskDNSRole’ }.
Con el .pssc ya preparado, se registra el endpoint mediante Register‑PSSessionConfiguration -Name NombreJEASession -Path Ruta\Archivo.pssc. A partir de ese momento, si se listan las configuraciones disponibles con Get‑PSSessionConfiguration, aparecerá el nuevo punto de conexión listo para recibir conexiones.
Los usuarios se conectan a este endpoint desde sus equipos con Enter‑PSSession -ComputerName Servidor -ConfigurationName NombreJEASession o con New‑PSSession y luego Invoke‑Command. Nada más entrar, la sesión aplica automáticamente las restricciones definidas en la capacidad de rol asociada al usuario.
Durante la sesión, PowerShell remoting usa WinRM con canales cifrados, autenticación integrada (normalmente Kerberos en dominio) y las reglas de firewall definidas para el servicio. Por debajo, si RunAsVirtualAccount está activado, se genera una cuenta virtual temporal añadida a los grupos necesarios y que se destruye cuando finaliza la sesión.
Por último, al cerrar la sesión JEA, se guardan las transcripciones y eventos de auditoría correspondientes, lo que deja un rastro claro de comandos ejecutados, resultados y contexto del usuario. Estos registros pueden enviarse o correlacionarse en un SIEM para alertas y análisis posteriores.
PowerShell remoting, control de acceso y endurecimiento
PowerShell Remoting, apoyado en el servicio Windows Remote Management (WinRM) y el protocolo WS‑Management, permite ejecutar comandos y scripts en equipos remotos de forma centralizada. Es una herramienta potentísima para automatización, gestión masiva de servidores, depuración y trabajos de soporte remoto.
Por defecto, los administradores locales y miembros del grupo Remote Management Users pueden usar los endpoints estándar de PowerShell. En muchos entornos, se ha utilizado esta capacidad para que usuarios no administradores ejecuten tareas remotas, lo cual no es peligroso en sí, pero si no se controla bien, abre una vía de abuso nada despreciable.
Para reforzar la postura de seguridad, una estrategia habitual consiste en restringir el acceso remoto de PowerShell solo a cuentas de administrador o, mejor aún, combinar esa limitación con endpoints JEA que den a ciertos usuarios solo el acceso estrictamente necesario. Esto se puede lograr mediante:
- GPOs que definan qué grupos pueden usar WinRM y los endpoints por defecto.
- Reglas de firewall que permitan WinRM solo desde subredes o equipos de administración.
- Eliminación del grupo Remote Management Users de las ACL de los endpoints estándar.
Adicionalmente, se puede optar por bloquear completamente PowerShell para usuarios no administradores utilizando soluciones como AppLocker. De esta manera, evitas que un usuario estándar ejecute scripts maliciosos a nivel local, pero sigues permitiendo a cuentas privilegiadas usar PowerShell para tareas de gestión y automatización.
JEA frente a otros métodos de restricción de PowerShell
Hay varias formas de recortar lo que los usuarios pueden hacer con PowerShell remoting, y JEA encaja como opción más fina y flexible dentro de un abanico que incluye enfoques más gruesos como:
Por un lado, el uso de GPO para controlar quién entra en los endpoints por defecto de PowerShell. Se puede limitar Microsoft.PowerShell a administradores, o incluso desregistrarlo para todo el mundo y obligar a usar endpoints específicos. Esto es útil para cortar acceso “a lo bruto”, pero no soluciona el problema de granularidad: quien accede, lo puede hacer prácticamente todo.
Por otro lado, están herramientas de control de aplicaciones como AppLocker o las Software Restriction Policies, que permiten denegar la ejecución de PowerShell.exe o pwsh.exe para usuarios estándar, ya sea por ruta, editor o hash. Este enfoque viene bien para endurecer estaciones de trabajo y evitar que cualquier usuario lance PowerShell, pero plantea limitaciones cuando quieres que alguien haga administración limitada desde su cuenta de usuario.
Otra opción son los endpoints restringidos (constrained endpoints) sin llegar a JEA completo. Puedes crear configuraciones de sesión personalizadas que restrinjan cmdlets, funciones y módulos, pero sin apalancarte tanto en el modelo de roles, cuentas virtuales o RBAC estructurado que JEA aporta. Es una especie de punto intermedio válido para escenarios sencillos, pero menos escalable en grandes entornos.
JEA combina lo mejor de varios mundos: limitación estricta de comandos, RBAC, ejecución con privilegios elevados controlados y registro exhaustivo. De este modo, se convierte en la solución recomendada cuando necesitas habilitar PowerShell remoting para no administradores, pero sin regalarles un entorno de administración completo.
Características avanzadas: ejecución como otra cuenta y registro
Una de las capacidades más potentes de JEA es el ejecutar comandos como otra cuenta más privilegiada sin exponer sus credenciales. Esto resuelve el típico problema de “te paso la contraseña de este servicio para que hagas X”, que luego nunca se cambia y acaba siendo un riesgo enorme.
En escenarios de dominio se suelen usar Group Managed Service Accounts (gMSA) para que los endpoints JEA ejecuten acciones bajo una identidad de servicio gestionada de forma centralizada, con rotación automática de contraseña y sin que ningún operador conozca nunca el secreto. En otros casos se recurre a cuentas virtuales temporales locales a la máquina, creadas ad hoc cuando un usuario se conecta y destruidas al finalizar la sesión.
En el plano de la auditoría, cada sesión JEA puede configurarse para generar tanto transcripciones de PowerShell como eventos enriquecidos en el registro de sucesos. Entre la información que típicamente se recopila se incluye:
- Histórico completo de comandos y parámetros introducidos.
- Salida generada y mensajes de error.
- Marca temporal de inicio y fin de la sesión, así como duración.
- Identidad del usuario conectado y rol/capacidad asignada.
Si combinas estas trazas con funcionalidades de PowerShell Module Logging y Script Block Logging vía GPO, y además envías los registros a un SIEM, obtienes una visibilidad muy sólida sobre lo que pasa en tus endpoints de administración. Esto es crítico tanto para cumplimiento (auditorías SOX, ISO 27001, etc.) como para detección y respuesta ante incidentes.
Casos de uso típicos de JEA en entornos reales
JEA brilla especialmente cuando necesitas delegar tareas muy concretas a equipos que no deberían ser administradores. Algunos ejemplos muy habituales en la práctica son:
En el área de soporte técnico, puedes dar a los técnicos de primer nivel acceso JEA para reiniciar servicios, consultar registros de eventos y comprobar el estado de procesos en servidores, pero sin que puedan instalar software, modificar configuraciones críticas o tocar Active Directory. Un rol típico de helpdesk podría incluir cmdlets como Get‑Service, Restart‑Service sobre servicios concretos, Get‑EventLog en modo solo lectura y algunos cmdlets de diagnóstico de red.
En equipos de operaciones o desarrollo, puedes configurar roles orientados a tareas específicas como administración de IIS o mantenimiento de webs. Por ejemplo, permitir acceso a cmdlets de gestión de Application Pools, reinicio de sitios web, consulta de logs de un directorio acotado y gestión de certificados para servicios concretos, dejando fuera cualquier capacidad de reiniciar el servidor completo o modificar políticas de seguridad.
En entornos híbridos y cloud, es frecuente usar JEA para limitar qué puede hacer cada equipo sobre máquinas virtuales, almacenamiento o redes. Puedes exponer endpoints que permitan gestionar solo las VMs de un departamento, tocar las reglas de firewall de un segmento concreto o administrar un conjunto determinado de cuentas de servicio, manteniendo separado el acceso del resto de la infraestructura.
Al mismo tiempo, JEA encaja muy bien con estrategias de Privileged Access Management (PAM), donde las sesiones con privilegios se conceden de forma temporal, quedan registradas y se atribuyen a identidades personales, evitando cuentas compartidas y minimizando el riesgo asociado a cada acción privilegiada.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.