Capacidades de rol de JEA

Al crear un punto de conexión de JEA, tiene que definir una o varias funcionalidades de rol que describan lo que puede hacer un usuario en una sesión de JEA. Una funcionalidad de rol es un archivo de datos de PowerShell con la .psrc extensión que enumera todos los cmdlets, funciones, proveedores y programas externos que están disponibles para conectar a los usuarios.

Determinar qué comandos se van a permitir

El primer paso para crear un archivo de funcionalidad de rol es tener en cuenta a qué necesitan acceder los usuarios. El proceso de recopilación de requisitos puede tardar un tiempo, pero es importante. Proporcionar a los usuarios acceso a demasiado pocos cmdlets y funciones puede impedir que se realicen sus trabajos. Permitir el acceso a demasiados cmdlets y funciones puede permitir a los usuarios hacer más de lo que usted tenía intencionado y debilitar su nivel de seguridad.

La forma de realizar este proceso depende de la organización y los objetivos. Las siguientes sugerencias pueden ayudar a asegurarte de que estás en el camino correcto.

1. Identifique los comandos que usan los usuarios para realizar sus trabajos. Esto puede implicar la encuesta al personal de TI, la comprobación de scripts de automatización o el análisis de transcripciones y registros de sesión de PowerShell.
2. Actualice el uso de herramientas de línea de comandos a equivalentes de PowerShell, siempre que sea posible, para obtener la mejor experiencia de personalización de JEA y auditoría. Los programas externos no se pueden restringir con tanto detalle como los cmdlets y las funciones nativas de PowerShell en JEA.
3. Restrinja el ámbito de los cmdlets para permitir solo parámetros específicos o valores de parámetro. Esto es especialmente importante si los usuarios solo deben administrar parte de un sistema.
4. Cree funciones personalizadas para reemplazar comandos complejos o aquellos que son difíciles de restringir en JEA. Una función sencilla que encapsula un comando complejo o aplica lógica de validación adicional puede ofrecer control adicional para los administradores y la simplicidad del usuario final.
5. Pruebe la lista definida de los comandos permitidos con sus usuarios o servicios de automatización, ajustándola según sea necesario.

Ejemplos de comandos potencialmente peligrosos

Es importante seleccionar cuidadosamente los comandos para asegurarse de que el punto de conexión de JEA no permite al usuario elevar sus permisos.

Importante

La información esencial necesaria para el éxito del usuario en una sesión de JEA suele ejecutarse con privilegios elevados.

La lista siguiente contiene ejemplos de comandos que se pueden usar de forma malintencionada si se permiten en un estado sin restricciones. Esta no es una lista exhaustiva y solo debe usarse como punto de partida de precaución.

• Riesgo: Concesión de privilegios de administrador al usuario que se conecta para eludir JEA

  Ejemplo:

  Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators'
  

  Comandos relacionados:

  • Add-ADGroupMember
  • Add-LocalGroupMember
  • net.exe
  • dsadd.exe

• Riesgo: Ejecución de código arbitrario, como malware, vulnerabilidades de seguridad o scripts personalizados para omitir las protecciones

  Ejemplo:

  Start-Process -FilePath '\\san\share\malware.exe'
  

  Comandos relacionados:

  • Start-Process
  • New-Service
  • Invoke-Item
  • Invoke-WmiMethod
  • Invoke-CimMethod
  • Invoke-Expression
  • Invoke-Command
  • New-ScheduledTask
  • Register-ScheduledJob

Creación de un archivo de funcionalidad de rol

Puede crear un archivo de funcionalidad de rol de PowerShell con el cmdlet New-PSRoleCapabilityFile.

New-PSRoleCapabilityFile -Path .\MyFirstJEARole.psrc

Debe editar el archivo de funcionalidad de rol creado para permitir solo los comandos necesarios para el rol. La documentación de ayuda de PowerShell contiene varios ejemplos de cómo configurar el archivo.

Permitir los cmdlets y funciones de PowerShell

Para autorizar a los usuarios a ejecutar cmdlets o funciones de PowerShell, agregue el nombre de cmdlet o función a los campos VisibleCmdlets o VisibleFunctions . Si no está seguro de si un comando es un cmdlet o una función, puede ejecutar Get-Command <name> y comprobar la propiedad CommandType en la salida.

VisibleCmdlets = @('Restart-Computer', 'Get-NetIPAddress')

A veces, el ámbito de un cmdlet o función específico es demasiado amplio para las necesidades de los usuarios. Un administrador dns, por ejemplo, puede que solo necesite acceso para reiniciar el servicio DNS. En entornos multiinquilino, los inquilinos tienen acceso a herramientas de administración de autoservicio. Los inquilinos deben limitarse a administrar sus propios recursos. En estos casos, puede restringir los parámetros que se exponen desde el cmdlet o la función.

VisibleCmdlets = @{
    Name       = 'Restart-Computer'
    Parameters = @{ Name = 'Name' }
}

En escenarios más avanzados, es posible que también tenga que restringir los valores que un usuario puede usar con estos parámetros. Las funcionalidades de rol permiten definir un conjunto de valores o un patrón de expresión regular que determine qué entrada se permite.

VisibleCmdlets = @(
    @{
        Name       = 'Restart-Service'
        Parameters = @{ Name = 'Name'; ValidateSet = @('Dns', 'Spooler') }
    }
    @{
        Name       = 'Start-Website'
        Parameters = @{ Name = 'Name'; ValidatePattern = 'HR_*' }
    }
)

Nota:

Los parámetros comunes de PowerShell siempre se permiten, aunque restrinja los parámetros disponibles. No debe enumerarlos explícitamente en el campo Parámetros.

En la lista siguiente se describen las distintas formas de personalizar un cmdlet o una función visibles. Puede mezclar y hacer coincidir cualquiera de los siguientes elementos en el campo VisibleCmdlets .

• Caso de uso: Permitir que el usuario ejecute My-Func sin restricciones en los parámetros.

  @{ Name = 'My-Func' }
  

• Caso de uso: Permitir que el usuario se ejecute My-Func desde el módulo MyModule sin restricciones en los parámetros.

  @{ Name = 'MyModule\My-Func' }
  

• Caso de uso: Permitir al usuario ejecutar cualquier cmdlet o función con el verbo My.

  @{ Name = 'My-*' }
  

• Caso de uso: Permitir al usuario ejecutar cualquier cmdlet o función con el nombre Func.

  @{ Name = '*-Func' }
  

• Caso de uso: Permitir que el usuario ejecute My-Func con los parámetros Param1 y Param2. Cualquier valor se puede proporcionar a los parámetros.

  @{ Name = 'My-Func'; Parameters = @{ Name = 'Param1'}, @{ Name = 'Param2' }}
  

• Caso de uso: Permitir que el usuario ejecute My-Func con el parámetro Param1. Solo Value1 y Value2 se pueden proporcionar al parámetro .

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidateSet = @('Value1', 'Value2') }
  }
  

• Caso de uso: Permitir que el usuario ejecute My-Func con el parámetro Param1. Cualquier valor a partir de contoso se puede proporcionar al parámetro .

  @{
      Name       = 'My-Func'
      Parameters = @{ Name = 'Param1'; ValidatePattern = 'contoso.*' }
  }
  

Advertencia

Para seguir las mejores prácticas de seguridad, no se recomienda usar caracteres comodín al definir cmdlets o funciones visibles. En su lugar, debe enumerar explícitamente cada comando de confianza para asegurarse de que ningún otro comando que comparta el mismo esquema de nomenclatura esté autorizado involuntariamente.

No se puede aplicar ValidatePattern y ValidateSet al mismo cmdlet o función.

Si lo hace, ValidatePattern invalida ValidateSet.

Para obtener más información sobre ValidatePattern, consulte esta entrada Hey, Scripting Guy! y el contenido de referencia de expresiones regulares de PowerShell.

Permitir comandos externos y scripts de PowerShell

Para permitir que los usuarios ejecuten ejecutables y scripts de PowerShell (.ps1) en una sesión de JEA, debe agregar la ruta de acceso completa a cada programa en el campo VisibleExternalCommands .

VisibleExternalCommands = @(
    'C:\Windows\System32\whoami.exe'
    'C:\Program Files\Contoso\Scripts\UpdateITSoftware.ps1'
)

Siempre que sea posible, use los cmdlets de PowerShell o los equivalentes de función para los ejecutables externos que autorice, ya que tiene control sobre los parámetros permitidos con cmdlets y funciones de PowerShell.

Muchos ejecutables permiten leer el estado actual y, a continuación, cambiarlo proporcionando parámetros diferentes.

Por ejemplo, considere el rol de un administrador de servidor de archivos que administra los recursos compartidos de red hospedados en un sistema. Una manera de administrar recursos compartidos es usar net share. Sin embargo, permitir net.exe es peligroso porque el usuario podría usar el comando para obtener privilegios de administrador con el comando net group Administrators unprivilegedjeauser /add. Una opción más segura es permitir el cmdlet Get-SmbShare , que logra el mismo resultado, pero tiene un ámbito mucho más limitado.

Al poner comandos externos a disposición de los usuarios en una sesión de JEA, especifique siempre la ruta de acceso completa al archivo ejecutable. Esto evita la ejecución de programas potencialmente malintencionados y con nombre similares ubicados en otro lugar del sistema.

Permitir el acceso a proveedores de PowerShell

De forma predeterminada, ningún proveedor de PowerShell está disponible en las sesiones de JEA. Esto reduce el riesgo de que la información confidencial y las opciones de configuración se revelen al usuario que se conecta.

Cuando sea necesario, puede permitir el acceso a los proveedores de PowerShell mediante el VisibleProviders comando . Para obtener una lista completa de proveedores, ejecute Get-PSProvider.

VisibleProviders = 'Registry'

Para tareas sencillas que requieren acceso al sistema de archivos, al registro, al almacén de certificados u otros proveedores confidenciales, considere la posibilidad de escribir una función personalizada que funcione con el proveedor en nombre del usuario. Las funciones, cmdlets y programas externos disponibles en una sesión de JEA no están sujetas a las mismas restricciones que JEA. Pueden acceder a cualquier proveedor de forma predeterminada. Considere también la posibilidad de usar la unidad de usuario cuando los usuarios necesiten copiar archivos hacia o desde un punto de conexión de JEA.

Creación de funciones personalizadas

Puede crear funciones personalizadas en un archivo de funcionalidad de rol para simplificar tareas complejas para los usuarios finales. Las funciones personalizadas también son útiles cuando se requiere lógica de validación avanzada para los valores de parámetro de cmdlet. Puede escribir funciones simples en el campo FunctionDefinitions :

VisibleFunctions = 'Get-TopProcess'

FunctionDefinitions = @{
    Name        = 'Get-TopProcess'
    ScriptBlock = {
        param($Count = 10)

        Get-Process |
            Sort-Object -Property CPU -Descending |
            Microsoft.PowerShell.Utility\Select-Object -First $Count
    }
}

Importante

No olvide agregar el nombre de las funciones personalizadas al campo VisibleFunctions para que los usuarios de JEA puedan ejecutarlo.

El cuerpo (bloque de script) de las funciones personalizadas se ejecuta en el modo de lenguaje predeterminado para el sistema y no está sujeto a restricciones de idioma de JEA. Esto significa que las funciones pueden acceder al sistema de archivos y al registro y ejecutar comandos que no se hicieron visibles en el archivo de funcionalidad de rol. Tenga cuidado de evitar ejecutar código arbitrario al usar parámetros. Evite la canalización de las entradas de usuario directamente en los cmdlets como Invoke-Expression.

En el ejemplo anterior, observe que se usó el nombre completo del módulo (FQMN) Microsoft.PowerShell.Utility\Select-Object en lugar de la abreviatura Select-Object. Las funciones definidas en los archivos de funcionalidad de rol siguen estando sujetas al ámbito de las sesiones de JEA, que incluye las funciones de proxy que JEA crea para restringir los comandos existentes.

De forma predeterminada, Select-Object es un cmdlet restringido en todas las sesiones de JEA que no permite la selección de propiedades arbitrarias en objetos. Para usar las funciones sin restricciones Select-Object , debe solicitar explícitamente la implementación completa mediante el FQMN. Cualquier cmdlet restringido en una sesión de JEA tiene las mismas restricciones cuando se invoca desde una función. Para obtener más información, vea about_Command_Precedence.

Si va a escribir varias funciones personalizadas, es más conveniente colocarlas en un módulo de script de PowerShell. Estas funciones se hacen visibles en la sesión de JEA mediante el campo VisibleFunctions como lo haría con módulos integrados y de terceros.

Para que la finalización de tabulación funcione correctamente en las sesiones de JEA, debe incluir la función integrada TabExpansion2 en la lista de VisibleFunctions.

Hacer que las funcionalidades de rol estén disponibles para una configuración

Antes de PowerShell 6, para que PowerShell encuentre un archivo de funcionalidad de rol, debe almacenarse en una RoleCapabilities carpeta de un módulo de PowerShell. El módulo se puede almacenar en cualquier carpeta incluida en la $Env:PSModulePath variable de entorno, pero no debe colocarlo en $Env:SystemRoot\System32 o en una carpeta donde usuarios no confiables podrían modificar los archivos.

En el ejemplo siguiente se crea un módulo de script de PowerShell denominado ContosoJEA en el $Env:ProgramFiles directorio para hospedar el archivo de capacidades de rol.

# Create a folder for the module
$modulePath = Join-Path $Env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
New-Item -ItemType Directory -Path $modulePath

# Create an empty script module and module manifest.
# At least one file in the module folder must have the same name as the folder itself.
$rootModulePath = Join-Path $modulePath "ContosoJEAFunctions.psm1"
$moduleManifestPath = Join-Path $modulePath "ContosoJEA.psd1"
New-Item -ItemType File -Path $RootModulePath
New-ModuleManifest -Path $moduleManifestPath -RootModule "ContosoJEAFunctions.psm1"

# Create the RoleCapabilities folder and copy in the PSRC file
$rcFolder = Join-Path $modulePath "RoleCapabilities"
New-Item -ItemType Directory $rcFolder
Copy-Item -Path .\MyFirstJEARole.psrc -Destination $rcFolder

Para obtener más información sobre los módulos de PowerShell, consulte Descripción de un módulo de PowerShell.

A partir de PowerShell 6, la propiedad RoleDefinitions se agregó al archivo de configuración de sesión. Esta propiedad le permite especificar la ubicación de un archivo de configuración de roles para la definición de roles. Consulte los ejemplos de New-PSSessionConfigurationFile.

Actualización de las funcionalidades de rol

Puede editar un archivo de funcionalidad de rol para actualizar la configuración en cualquier momento. Las nuevas sesiones de JEA iniciadas después de actualizar la funcionalidad de rol reflejarán las funcionalidades revisadas.

Este es el motivo por el que controlar el acceso a la carpeta de funcionalidades de rol es tan importante. Solo se debe permitir que los administradores de alta confianza cambien los archivos de funcionalidad de rol. Si un usuario que no es de confianza puede cambiar los archivos de funcionalidad de rol, puede concederse fácilmente acceso a cmdlets que les permitan elevar sus privilegios.

Para los administradores que buscan restringir el acceso a las capacidades de rol, asegúrense de que el Sistema Local tenga acceso de solo lectura a los archivos de capacidades de rol y módulos que los contengan.

Cómo se combinan las capacidades de rol

A los usuarios se les concede acceso a todas las funcionalidades de rol coincidente en el archivo de configuración de sesión cuando entran en una sesión de JEA. JEA intenta proporcionar al usuario el conjunto de comandos más permisivo permitido por cualquiera de los roles.

VisibleCmdlets y VisibleFunctions

La lógica de combinación más compleja en JEA afecta a los cmdlets y funciones, cuyos parámetros y valores de parámetro pueden estar limitados.

Las reglas son las siguientes:

1. Si un cmdlet solo se hace visible en un rol, es visible para el usuario junto con cualquier restricción de parámetros aplicable.
2. Si un cmdlet se hace visible en más de un rol y cada rol tiene las mismas restricciones en el cmdlet, el cmdlet es visible para el usuario con esas restricciones.
3. Si un cmdlet se hace visible en más de un rol y cada rol permite un conjunto diferente de parámetros, el cmdlet y todos los parámetros definidos en cada rol son visibles para el usuario. Si un rol no tiene restricciones en los parámetros, se permiten todos los parámetros.
4. Si un rol define un conjunto de validación o un patrón de validación para un parámetro de cmdlet, y el otro rol permite el parámetro, pero no restringe los valores de parámetro, se omite el conjunto de validación o el patrón.
5. Si se define un conjunto de validación para el mismo parámetro de cmdlet en más de un rol, se permiten todos los valores de todos los conjuntos de validación.
6. Si se define un patrón de validación para el mismo parámetro de cmdlet en más de un rol, se permiten los valores que coincidan con cualquiera de los patrones.
7. Si se define un conjunto de validación en uno o varios roles y se define un patrón de validación en otro rol para el mismo parámetro de cmdlet, el conjunto de validación se omite y la regla (6) se aplica a los patrones de validación restantes.

A continuación se muestra un ejemplo de cómo se combinan los roles según estas reglas:

# Role A Visible Cmdlets
$roleA = @{
    VisibleCmdlets = @(
        'Get-Service'
         @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Client' }
        }
    )
}

# Role B Visible Cmdlets
$roleB = @{
    VisibleCmdlets = @(
        @{
            Name       = 'Get-Service';
            Parameters = @{ Name = 'DisplayName'; ValidatePattern = 'DNS.*' }
        }
        @{
            Name       = 'Restart-Service'
            Parameters = @{ Name = 'DisplayName'; ValidateSet = 'DNS Server' }
        }
    )
}

# Resulting permissions for a user who belongs to both role A and B
# - The constraint in role B for the DisplayName parameter on Get-Service
#   is ignored because of rule #4
# - The ValidateSets for Restart-Service are merged because both roles use
#   ValidateSet on the same parameter per rule #5
$mergedAandB = @{
    VisibleCmdlets = @(
        'Get-Service'
        @{
            Name = 'Restart-Service';
            Parameters = @{
                Name = 'DisplayName'
                ValidateSet = 'DNS Client', 'DNS Server'
            }
        }
    )
}

ComandosExternosVisibles, AliasesVisibles, ProveedoresVisibles, ScriptsParaProcesar

Todos los demás campos del archivo de funcionalidad de rol se agregan a un conjunto acumulativo de comandos externos permitidos, alias, proveedores y scripts de inicio. Cualquier comando, alias, proveedor o script disponible en una funcionalidad de rol está disponible para el usuario de JEA.

Tenga cuidado de asegurarse de que el conjunto combinado de proveedores de una funcionalidad de rol y cmdlets, funciones o comandos de otro no permita que los usuarios accedan involuntariamente a los recursos del sistema. Por ejemplo, si un rol permite el cmdlet Remove-Item y otro permite al proveedor FileSystem, corre el riesgo de que un usuario de JEA elimine archivos arbitrarios en su equipo. Puede encontrar información adicional sobre cómo identificar los permisos efectivos de los usuarios en el artículo auditoría de JEA .

Pasos siguientes

Creación de un archivo de configuración de sesión