Compartir a través de

Funcionalidades de rol de JEA

  • Artículo

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 extensión .psrc que enumera los cmdlets, las funciones, los proveedores y los programas externos que se ponen a disposición de los usuarios que se conectan.

Determinar los comandos permitidos

El primer paso al crear un archivo de funcionalidad de rol es tener en cuenta a qué necesitan acceso los usuarios. El proceso de recopilación de requisitos puede tardar un tiempo, pero es importante. Conceder acceso a los usuarios a muy pocos cmdlets y funciones puede impedirles llevar a cabo su trabajo. Permitir el acceso a demasiados cmdlets y funciones puede permitir que los usuarios realicen más operaciones de las previstas y debilitar la posición en materia de seguridad.

La manera de realizar este proceso depende de la organización y los objetivos. Las sugerencias siguientes pueden ayudarle a asegurarse de tomar el camino correcto.

  1. Identifique los comandos que usan los usuarios para realizar su trabajo. Esto puede implicar encuestar al personal de TI, comprobar los scripts de automatización o analizar registros y transcripciones de sesión de PowerShell.
  2. Actualice el uso de herramientas de línea de comandos por equivalentes de PowerShell, siempre que sea posible, para tener la mejor experiencia de personalización de JEA y auditoría. En JEA, los programas externos no se pueden restringir con la misma minuciosidad que los cmdlets y las funciones nativos de PowerShell.
  3. Restrinja el ámbito de los cmdlets para permitir solo parámetros o valores de parámetro específicos. Esto es especialmente importante si los usuarios solo deben administrar una parte de un sistema.
  4. Cree funciones personalizadas para reemplazar comandos complejos o que son difíciles de restringir en JEA. Una función sencilla que encapsule un comando complejo o aplique lógica de validación adicional puede ofrecer un mayor control para simplificar los administradores y usuarios finales.
  5. Pruebe la lista con ámbito de los comandos permitidos con los usuarios o los servicios de automatización, y ajústela según sea necesario.

Ejemplos de comandos potencialmente peligrosos

Es importante seleccionar los comandos para asegurarse de que el punto de conexión de JEA no permita que el usuario eleve sus permisos.

Importante

La información esencial necesaria para successCommands de usuario en una sesión de JEA se suele ejecutar 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 lista no es exhaustiva y solo se debe usar como punto inicial de advertencia.

  • Riesgo: conceder los privilegios de administrador del usuario de conexión para omitir JEA

    Ejemplo:

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

    Comandos relacionados:

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

  • Riesgo: ejecutar 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

Crear 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 funciones y cmdlets de PowerShell

Para autorizar a los usuarios a ejecutar funciones o cmdlets de PowerShell, agregue el nombre del cmdlet o de la función en 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 una función específicos es demasiado amplio para las necesidades de los usuarios. Un administrador de 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 se deben limitar a la administración de sus propios recursos. En estos casos, puede restringir los parámetros que se exponen mediante la función o el cmdlet.

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 utilizar con estos parámetros. Las funcionalidades de rol permiten definir un conjunto de valores o un patrón de expresión regular para determinar 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 se permiten siempre, incluso si restringe los parámetros disponibles. No debería enumerarlos de forma explícita en el campo Parameters.

En la lista siguiente se describen las distintas formas de personalizar un cmdlet o una función visibles. Puede combinar cualquiera de los siguientes 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 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. Para estos parámetros, se puede proporcionar cualquier valor.

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

  • Caso de uso: permitir que el usuario ejecute My-Func con el parámetro Param1. Solo se pueden proporcionar Value1 y Value2 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 conocer los procedimientos recomendados de seguridad, no se recomienda usar caracteres comodín al definir cmdlets o funciones visibles. En su lugar, debe enumerar de forma explícita cada comando de confianza para asegurarse de que ningún otro comando que comparta el mismo esquema de nombre se autorice de forma involuntaria.

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

Si lo hace, ValidatePattern invalidará a ValidateSet.

Para obtener más información sobre ValidatePattern, consulte esta publicación de 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 archivos 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, después, proporcionar otros parámetros para cambiarlo.

Por ejemplo, considere la función de un administrador de servidor de archivos que administra recursos compartidos de red hospedados en un sistema. Una manera de administrar los recursos compartidos consiste en 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 impide la ejecución de programas con nombres similares y potencialmente malintencionados ubicados en otro lugar en el sistema.

Permitir el acceso a proveedores de PowerShell

De manera predeterminada, no hay ningún proveedor de PowerShell disponible en las sesiones de JEA. Esto reduce el riesgo de que se revele información confidencial y opciones de configuración al usuario que se conecta.

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

VisibleProviders = 'Registry'

Para realizar tareas sencillas que requieren acceso al sistema de archivos, el Registro, el almacén de certificados u otros proveedores de información confidencial, considere la posibilidad de escribir una función personalizada que funcione con el proveedor en nombre del usuario. Los cmdlets, las funciones y los programas externos disponibles en una sesión de JEA no están sujetos a las mismas restricciones que JEA. Pueden acceder a cualquier proveedor de manera 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.

Crear 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 una lógica de validación avanzada para los valores de parámetros 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 en el campo VisibleFunctions para que las puedan ejecutar los usuarios de JEA.

El cuerpo (bloque de script) de las funciones personalizadas se ejecuta en el modo de lenguaje predeterminado del sistema y no está sujeto a las restricciones de lenguaje de JEA. Esto significa que las funciones pueden acceder al sistema de archivos y al Registro, y ejecutar comandos que no se han hecho visibles en el archivo de funcionalidad de rol. Al usar parámetros, tenga cuidado para evitar la ejecución de código arbitrario. Evite canalizar la entrada del usuario directamente a cmdlets como Invoke-Expression.

En el ejemplo anterior, observe que se ha usado el nombre de módulo completo (FQMN) Microsoft.PowerShell.Utility\Select-Object en lugar de la forma abreviada Select-Object. Las funciones definidas en los archivos de funcionalidad de función siguen dependiendo del ámbito de las sesiones de JEA, que incluye las funciones de proxy que crea JEA para restringir 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 Select-Object sin restricciones en las funciones, debe solicitar de forma explícita la implementación completa mediante el FQMN. Cualquier cmdlet sin restricciones 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, resulta más cómodo colocarlas en un módulo de script de PowerShell. Puede hacer visibles esas funciones 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 con tabulación funcione correctamente en las sesiones de JEA, debe incluir la función integrada tabexpansion2 en la lista VisibleFunctions.

Poner las funcionalidades de rol a disposición de una configuración

Antes de PowerShell 6, para que PowerShell encuentre un archivo de funcionalidad de rol, debe almacenarse en una carpeta RoleCapabilities en un módulo de PowerShell. El módulo se puede almacenar en cualquier carpeta incluida en la variable de entorno $env:PSModulePath, pero no se debe colocar en $env:SystemRoot\System32 ni en una carpeta donde los usuarios que no sean de confianza puedan modificar los archivos.

En el siguiente ejemplo se crea un módulo de script de PowerShell llamado ContosoJEA en la ruta de acceso $env:ProgramFiles para hospedar el archivo de funcionalidades 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, vea 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 sesión para su definición de roles. Consulte los ejemplos en New-PSSessionConfigurationFile.

Actualizar funcionalidades de rol

Puede editar un archivo de funcionalidad de rol para actualizar la configuración en cualquier momento. Cualquier sesión de JEA nueva iniciada después de que se haya actualizado la funcionalidad de rol reflejará las funcionalidades revisadas.

Por esto es tan importante controlar el acceso a la carpeta de funcionalidades de rol. Solo los administradores de plena confianza deberían tener permiso para cambiar los archivos de funcionalidad de rol. Si un usuario que no sea de confianza puede cambiar los archivos de funcionalidad de rol, puede proporcionarse acceso fácilmente a cmdlets que le permitan elevar sus privilegios.

Para los administradores que buscan bloquear el acceso a las funcionalidades de rol, asegúrese de que el sistema local tenga acceso de solo lectura a los archivos de funcionalidad de rol y que contengan módulos.

Cómo se combinan las funcionalidades de rol

A los usuarios se les concede acceso a todas las funcionalidades de rol que coinciden 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 afecta a los cmdlets y funciones, que pueden tener sus parámetros y valores de parámetro limitados en JEA.

Estas son las reglas:

  1. Si un cmdlet solo está visible en un rol, es visible para el usuario con cualquier restricción de parámetro correspondiente.
  2. Si un cmdlet está visible en más de un rol, y todos los roles tienen las mismas restricciones en el cmdlet, el cmdlet es visible para el usuario con esas restricciones.
  3. Si un cmdlet está visible en más de un rol, y todos los roles permiten otro conjunto 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 o patrón validado 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 patrón o conjunto validado.
  5. Si se define un conjunto validado para el mismo parámetro de cmdlet en más de un rol, se permiten todos los valores de todos los conjuntos validados.
  6. Si se define un patrón validado para el mismo parámetro de cmdlet en más de un rol, se permiten todos los valores que coincidan con cualquiera de los patrones.
  7. Si se define un conjunto validado en uno o varios roles y se define un patrón validado en otro rol para el mismo parámetro de cmdlet, se omite el conjunto validado y se aplica la regla (6) a los demás patrones validados.

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'
            }
        }
    )
}

VisibleExternalCommands, VisibleAliases, VisibleProviders, ScriptsToProcess

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

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

Pasos siguientes

Crear un archivo de configuración de sesión