Características de seguridad de PowerShell

PowerShell tiene varias características diseñadas para mejorar la seguridad del entorno de scripting.

Directiva de ejecución

La directiva de ejecución de PowerShell es una característica de seguridad que controla las condiciones en las que PowerShell carga archivos de configuración y ejecuta scripts. Esta característica ayuda a evitar la ejecución de scripts malintencionados. Puede usar una configuración de directiva de grupo para establecer directivas de ejecución para equipos y usuarios. Las directivas de ejecución solo se aplican a la plataforma Windows.

Para obtener más información, vea about_Execution_Policies.

Uso de la clase SecureString

PowerShell tiene varios cmdlets que admiten el uso de la clase System.Security.SecureString. Además, al igual que con cualquier clase de .NET, puede usar SecureString en sus propios scripts. Sin embargo, Microsoft no recomienda usar SecureString para el nuevo desarrollo. Microsoft recomienda evitar el uso de contraseñas y confiar en otros medios para autenticarse, como certificados o autenticación de Windows.

PowerShell sigue admitiendo la clase SecureString para la compatibilidad con versiones anteriores. El uso de una SecureString sigue siendo más seguro que usar una cadena de texto sin formato. PowerShell todavía se basa en el tipo SecureString para evitar exponer accidentalmente el contenido a la consola o en los registros. Use SecureString cuidadosamente, ya que se puede convertir fácilmente en una cadena de texto sin formato. Para obtener una explicación completa sobre el uso de SecureString, consulte la documentación de Clase System.Security.SecureString.

Registro de módulos y bloques de scripts

El registro de módulos permite habilitar el registro de módulos de PowerShell seleccionados. Este valor es eficaz en todas las sesiones del equipo. PowerShell registra eventos de ejecución de la canalización para los módulos especificados en el registro de eventos de Windows PowerShell.

El registro de bloques de scripts habilita el registro para el procesamiento de comandos, bloques de scripts, funciones y scripts, tanto si se invocan de forma interactiva como mediante automatización. PowerShell registra esta información en el registro de eventos Microsoft-Windows-PowerShell/Operational.

Vea los siguientes artículos para más información:

• acerca_de_Configuraciones_de_Política_de_Grupo
• about_Logging_Windows
• about_Logging_Non Windows

Compatibilidad con AMSI

Windows Antimalware Scan Interface (AMSI) es una API que permite a las aplicaciones pasar acciones a un escáner antimalware, como Windows Defender, para buscar cargas malintencionadas. A partir de PowerShell 5.1, si PowerShell se ejecuta en Windows 10 (y superior) pasa todos los bloques de script a AMSI.

PowerShell 7.3 amplía los datos que envía a AMSI para su inspección. Ahora incluye todas las invocaciones de método de .NET.

Para obtener más información sobre AMSI, consulte Cómo ayuda AMSI.

Modo de lenguaje restringido

El modo ConstrainedLanguage protege el sistema mediante la limitación de los cmdlets y los tipos de .NET permitidos en una sesión de PowerShell. Para obtener una descripción completa, vea about_Language_Modes.

Control de la aplicación

Windows 10 incluye dos tecnologías, App Control para empresas y AppLocker que puedes usar para controlar las aplicaciones. PowerShell detecta si se aplica una directiva de control de aplicaciones en todo el sistema. La directiva aplica ciertos comportamientos al ejecutar bloques de script, archivos de script o cargar archivos de módulo para evitar la ejecución arbitraria de código en el sistema.

El Control de aplicaciones para empresas está diseñado como una característica de seguridad en los criterios de mantenimiento definidos por el Centro de respuesta de seguridad de Microsoft (MSRC). App Control es el sistema de control de aplicaciones preferido para Windows.

Para obtener más información sobre cómo PowerShell admite AppLocker y App Control, consulte Uso del control de aplicaciones para proteger PowerShell.

Lista de materiales de software (SBOM)

A partir de PowerShell 7.2, todos los paquetes de instalación contiene una lista de materiales de software (SBOM). El equipo de PowerShell también produce SBOM para los módulos que son suyos pero se envían independientemente de PowerShell.

Encontrará estos archivos SBOM en la ubicación siguiente:

• En PowerShell, busque la SBOM en $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
• En el caso de los módulos, encontrará SBOM en la carpeta del módulo que hay en _manifest/spdx_2.2/manifest.spdx.json.

Crear y publicar la SBOM es el primer paso para modernizar la ciberseguridad del Gobierno federal y mejorar la seguridad de la cadena de suministros de software. Para obtener más información sobre esta iniciativa, vea la entrada de blog Generating SBOMs with SPDX at Microsoft (Generación de SBOM con SPDX en Microsoft).

Transferencia segura de datos en la remotización de PowerShell

Antes de PowerShell v7.6-preview5, Session_Key se usa para cifrar secureString antes de enviarlo a una sesión remota de PowerShell. El Protocolo de comunicación remota de PowerShell (PSRP) realiza un intercambio de claves entre el cliente y el servidor cuando es necesario transferir un SecureString objeto. El intercambio implica los pasos siguientes:

1. El lado cliente genera un par de claves pública y privada y envía la clave pública al servidor.
2. El servidor genera una clave de sesión para el cifrado simétrico.
3. El servidor usa la clave pública para cifrar la clave de sesión y enviarlo al cliente.
4. Tanto el cliente como el servidor usan la nueva clave de sesión para cifrar un objeto SecureString .

El protocolo de comunicación remota de PowerShell (PSRP) usa el RSAEncryptionPadding.Pkcs1 algoritmo durante el intercambio de claves. El algoritmo NO es seguro, por lo que el intercambio de claves no proporciona ninguna seguridad adicional.

A partir de PowerShell v7.6-preview.5, el intercambio de claves está en desuso. La versión de PSRP se incrementó a v2.4 e incluye los cambios siguientes:

• Los siguientes mensajes PSRP están en desuso cuando tanto el cliente como el servidor son v2.4 o superior:

  • PUBLIC_KEY
  • PUBLIC_KEY_REQUEST
  • CLAVE_DE_SESIÓN_ENCRIPTADA

• Los pasos de cifrado y descifrado de SecureString se omiten cuando el cliente y el servidor son v2.4 o posteriores.

Este cambio es compatible con versiones anteriores.

• En el caso de los clientes o servidores antiguos (v2.3 o inferior), el intercambio de claves se sigue usando cuando sea necesario.
• PSRP puede usar sesiones remotas de canalización con nombre cuando el cliente y el servidor están en la misma máquina. Dado que es posible que un cliente remoto se conecte a la canalización con nombre y los datos ya no se cifren con una clave de sesión, la canalización con nombre (usada para Enter-PSHostProcess) rechaza el cliente remoto.

Criterios de servicio de seguridad

PowerShell sigue los criterios de servicio de seguridad de Microsoft para Windows. Solo las características de seguridad cumplen los criterios de mantenimiento.

Características de seguridad

• Bloqueo del sistema con El control de aplicaciones para empresas
• Modo de idioma restringido con App Control para empresas

Características de defensa en profundidad

• Bloqueo del sistema con AppLocker
• Modo de lenguaje restringido con AppLocker
• Directiva de ejecución