Just Enough Administration (JEA) paso a paso

El pilar de seguridad de PowerShell mostraba un ejemplo de JEA de cinco líneas. Basta para entender la idea, pero no para llevarla a producción. Esta guía va más allá: cómo diseñar roles de los que no se pueda escapar, cómo elegir la identidad de ejecución, cómo desplegar puntos de conexión en muchos servidores y cómo demostrar que hacen lo que usted cree.

Just Enough Administration es un punto de conexión de comunicación remota de PowerShell con tres propiedades. El usuario que se conecta solo puede ejecutar un conjunto de comandos de una lista de permitidos, los comandos se ejecutan con una identidad privilegiada temporal en lugar de con la cuenta del propio usuario, y todo queda transcrito. Bien hecho, permite que el soporte técnico reinicie un servicio o vacíe una cola de impresión sin que nadie tenga derechos de administrador local en el servidor. Consulte la entrada del glosario sobre JEA para la definición breve.

Cómo encajan las piezas

Las funcionalidades de rol se cargan al iniciarse una sesión, así que editar un .psrc afecta de inmediato a las sesiones nuevas. Los cambios en un .pssc solo se aplican después de volver a registrarlo.

Qué se rompe

Las sesiones JEA son incómodas a propósito. Tenga en cuenta:

• Sin variables ni bloques de script. Las sesiones RestrictedRemoteServer usan por defecto el modo NoLanguage. Los usuarios ejecutan comandos; no pueden escribir $x = Get-Service ni ForEach-Object { }. Ponga la lógica en funciones dentro de su módulo.
• Sin doble salto. Una cuenta virtual es local al servidor. Todo lo que deba llegar a un recurso compartido, a SQL o a AD desde dentro de la sesión necesita en su lugar una gMSA.
• Sin copia de archivos por defecto. Copy-Item -ToSession solo funciona con una unidad de usuario (MountUserDrive), y solo hacia esa unidad.
• Las herramientas gráficas no lo usan. El Administrador del servidor, los complementos de MMC y RDP ignoran los puntos de conexión JEA. Los operadores necesitan scripts o comunicación remota implícita.

Paso 1: inventariar las tareas

Parta de los tickets, no de los cmdlets. Para cada tarea recurrente, anote el comando exacto y los valores de parámetro que necesita:

• Reiniciar la cola de impresión en los servidores de impresión.
• Eliminar los trabajos atascados de una cola determinada.
• Leer los 50 últimos eventos del sistema.

Si una tarea necesita entradas arbitrarias (cualquier servicio, cualquier ruta), es una señal de alarma. Cada parámetro de formato libre es una posible vía de escape.

Paso 2: construir el módulo de funcionalidad de rol

Cree un módulo pequeño que contenga el rol. El módulo necesita un manifiesto, aunque el .psm1 esté vacío:

$mod = "C:\Program Files\WindowsPowerShell\Modules\CorpJEA"
New-Item -ItemType Directory -Path "$mod\RoleCapabilities" -Force | Out-Null
New-Item -ItemType File -Path "$mod\CorpJEA.psm1" -Force | Out-Null
New-ModuleManifest -Path "$mod\CorpJEA.psd1" -RootModule 'CorpJEA.psm1'

Ahora el rol. Restrinja los parámetros con ValidateSet o ValidatePattern siempre que pueda:

New-PSRoleCapabilityFile -Path "$mod\RoleCapabilities\PrintOperator.psrc" `
  -VisibleCmdlets @(
    @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-Service';     Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-PrintJob';    Parameters = @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' } },
    @{ Name = 'Remove-PrintJob'; Parameters = @(
         @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' },
         @{ Name = 'ID' }) }
  ) `
  -VisibleFunctions 'Get-CorpSystemEvents'

Get-CorpSystemEvents es una función que usted escribe en CorpJEA.psm1, por ejemplo un envoltorio de Get-WinEvent -LogName System -MaxEvents 50. Las funciones de su módulo son el lugar adecuado para todo lo que necesite variables o bucles: los usuarios pueden llamarlas, pero no ver ni cambiar su contenido.

Deje fuera de todos los roles lo siguiente, salvo que entienda exactamente por qué está ahí, porque cada elemento vuelve a convertir el punto de conexión en un acceso de administrador completo:

• Invoke-Expression, Invoke-Command, Start-Process, New-Service, Register-ScheduledTask, Add-Type.
• Cualquier cosa que cambie la pertenencia a grupos (Add-LocalGroupMember, Add-ADGroupMember).
• Los proveedores de archivos y del registro mediante VisibleProviders, y Set-Content, Copy-Item o New-Item sin restricciones de ruta.
• VisibleExternalCommands que apunten a cmd.exe, powershell.exe o cualquier intérprete.

Un cmdlet con un parámetro -ScriptBlock, -FilePath o -ComputerName sin restricciones merece la misma desconfianza.

Paso 3: escribir la configuración de sesión

New-PSSessionConfigurationFile -Path .\PrintOps.pssc `
  -SessionType RestrictedRemoteServer `
  -RunAsVirtualAccount `
  -RunAsVirtualAccountGroups 'JEA-PrintSvc' `
  -TranscriptDirectory 'C:\ProgramData\JEA\Transcripts' `
  -RoleDefinitions @{ 'CORP\JEA-PrintOps' = @{ RoleCapabilities = 'PrintOperator' } } `
  -RequiredGroups @{ And = 'CORP\JEA-PrintOps', 'CORP\SmartCardUsers' }

Test-PSSessionConfigurationFile -Path .\PrintOps.pssc

JEA-PrintSvc es un grupo local del servidor al que concede solo los derechos que necesita el rol, por ejemplo los derechos de inicio y detención del servicio Spooler (mediante el descriptor de seguridad del servicio) y Manage documents en las colas de impresión. Construir ese grupo cuesta más que aceptar el administrador local, y es precisamente ese esfuerzo lo que hace seguro el punto de conexión.

La identidad de ejecución es la decisión más importante aquí:

El valor por defecto Domain Admins en los controladores de dominio pilla desprevenido a mucha gente. Un punto de conexión JEA en un DC con una cuenta virtual sin acotar y un solo comando del que se pueda escapar es un shell de Domain Admin para cualquiera que pueda conectarse. Acótela siempre o use una gMSA con derechos delegados concretos.

RequiredGroups añade una condición que debe cumplirse sea cual sea el rol, por ejemplo que el usuario haya iniciado sesión además con una tarjeta inteligente (mediante un grupo de garantía del mecanismo de autenticación). Se evalúa en el momento de la conexión.

Paso 4: registrar el punto de conexión

Register-PSSessionConfiguration -Name PrintOps -Path .\PrintOps.pssc -Force

El registro reinicia el servicio WinRM, lo que corta las sesiones remotas existentes. Hágalo en una ventana de mantenimiento en los servidores con mucha actividad.

Después revise los puntos de conexión predeterminados. Get-PSSessionConfiguration enumera todos los puntos de conexión y quién puede usarlos:

Get-PSSessionConfiguration | Select-Object Name, Permission

Los puntos de conexión integrados microsoft.powershell permiten el acceso a Administrators y Remote Management Users. Los usuarios de JEA no deben estar en ninguno de los dos grupos; de lo contrario, pueden saltarse por completo su punto de conexión. Limpie la pertenencia a grupos como parte de la eliminación de los derechos de administrador local.

Paso 5: desplegar a escala

Registrar puntos de conexión a mano no escala más allá de unos pocos servidores. Dos patrones habituales:

• Distribución de software más un script. Empaquete la carpeta del módulo y el .pssc, copie el módulo en C:\Program Files\WindowsPowerShell\Modules y ejecute Register-PSSessionConfiguration. Use la versión del módulo del manifiesto como regla de detección.
• Desired State Configuration. El módulo de recursos de la comunidad JeaDsc declara puntos de conexión y funcionalidades de rol como configuración, lo que además corrige la deriva. Compruebe el estado de mantenimiento actual del módulo antes de depender de él.

Guarde los archivos .psrc y .pssc en control de código fuente con revisión de código. Son configuración privilegiada, igual que una GPO que concede derechos de administrador.

Comprobarlo

Primero, pregunte al servidor qué obtendría un usuario determinado, sin conectarse:

Get-PSSessionCapability -ConfigurationName PrintOps -Username 'CORP\alice'

La salida enumera exactamente los comandos disponibles para ese usuario. Cualquier cosa inesperada ahí es un error de diseño.

Después, conéctese como operador de prueba:

Enter-PSSession -ComputerName prn01.corp.example -ConfigurationName PrintOps
Get-Command                      # solo los comandos permitidos, más los predeterminados
Restart-Service -Name Spooler    # funciona
Restart-Service -Name WinRM      # falla la validación del parámetro
$env:USERNAME                    # falla: sin lenguaje

Revise la transcripción en C:\ProgramData\JEA\Transcripts. El encabezado muestra tanto el usuario conectado como la cuenta de ejecución, y eso es lo que hace auditable a JEA. Reenvíe esas transcripciones, y los eventos 4104 de PowerShell generados dentro de la sesión, como se describe en detectar PowerShell malicioso.

Por último, intente escapar a propósito. Ejecute cada comando visible con argumentos extraños, canalice las salidas hacia otros comandos visibles y busque cualquier cosa que escriba archivos, inicie procesos o cambie grupos. Una breve revisión interna por parte de alguien que no escribió el rol encuentra la mayoría de las vías de escape.

Operar JEA

• Proteja el transporte del punto de conexión. JEA funciona sobre WinRM, así que hereda su configuración. Aplique el endurecimiento de WinRM: Kerberos, sin Basic, sin CredSSP y con el firewall limitado a los equipos de gestión.
• Asigne los roles a niveles. Un punto de conexión JEA en un servidor Tier 0 es un activo Tier 0, y el grupo que concede el rol es un grupo Tier 0. Siga su modelo de administración por niveles.
• Revise cada trimestre. Compare las funcionalidades de rol con el uso real en las transcripciones. Elimine los comandos que nadie ejecuta.
• Alerte sobre los cambios en los puntos de conexión. Una configuración de sesión nueva o modificada aparece como un cambio en WSMan:\localhost\Plugin; supervise eso y la carpeta del módulo con sus herramientas de integridad de archivos o de gestión de la configuración.

Encontrará más contexto sobre JEA y los demás controles de PowerShell en la página temática de seguridad de PowerShell.

Lista de comprobación

• Tareas operativas recurrentes enumeradas con comandos y valores de parámetro exactos
• Módulo de funcionalidad de rol con parámetros restringidos; sin intérpretes, inicio de procesos, cambios de grupos ni acceso a archivos sin restricciones
• La configuración de sesión usa RestrictedRemoteServer y una cuenta virtual acotada o una gMSA
• Ninguna cuenta virtual sin acotar en ningún controlador de dominio
• RequiredGroups usado para los roles sensibles (por ejemplo, garantía de tarjeta inteligente o MFA)
• Usuarios de JEA retirados de Administrators y Remote Management Users
• Salida de Get-PSSessionCapability revisada para cada rol
• Transcripciones y eventos 4104 reenviados y conservados
• Archivos de rol y de sesión en control de código fuente y desplegados automáticamente