Compatibilidad de extensiones para la administración de la infraestructura aplicada de Control de aplicaciones de Windows Defender (WDAC)

Artículo
06/30/2023

Se aplica a: Windows Admin Center, versión preliminar de Windows Admin Center

Windows Admin Center admite la administración de la infraestructura aplicada de Control de aplicaciones de Windows Defender (WDAC) en el nivel de plataforma. Obtenga más información sobre la administración de la infraestructura aplicada de WDAC en Windows Admin Center.

La compatibilidad con esta administración en el nivel de plataforma no significa que las extensiones creadas para Windows Admin Center también admitan la administración de la infraestructura aplicada por WDAC de forma predeterminada. En esta guía se describen los requisitos de una extensión para admitir la administración de la infraestructura aplicada de WDAC.

Requisitos de la estructura de extensiones

Para administrar la infraestructura aplicada de WDAC, Windows Admin Center debe ingerir y ejecutar scripts de PowerShell de una manera determinada para cumplir los procedimientos de seguridad recomendados. Para asegurarse de que los scripts de la extensión se ejecutan correctamente, asegúrese de que la extensión se ajusta a los siguientes requisitos.

Todos los scripts de PowerShell deben almacenarse en un archivo

Históricamente, los desarrolladores de extensiones WAC pueden haber elegido incluir código personalizado de PowerShell como una cadena en su archivo manifest.json de extensión. Por ejemplo, puede optar por definir las condiciones para la visibilidad de una extensión de herramienta proporcionando un script de PowerShell en la propiedad "script". Para que los scripts de PowerShell sean compatibles con WDAC, deben estar firmados. Las cadenas no se pueden firmar.

Para asegurarse de que se cumple este requisito, siga estos pasos:

Identifique los scripts de PowerShell en el archivo manifest.json.
Después de definir cualquier contenido de script en el archivo manifest.json, quite el contenido del script y almacénelo en un archivo .ps1 en el directorio de la extensión resources/scripts. El código de script del manifiesto de extensión ahora sigue las mismas reglas que otro PowerShell de Windows Admin Center.
Actualice la propiedad de condiciones en el manifiesto de extensión al siguiente formato:
```
"conditions": [
    {
        "powerShell": {
            "command": "Script-File-Name",
            "module": "powerShellModuleName",
            "script": "Your script text goes here."
        }
    }
]
```
El nombre del módulo de PowerShell ya existe en el manifiesto de extensión. Su valor en el manifiesto y en el campo de PowerShell debe coincidir.
Identifique cualquier otro lugar en el que los scripts de PowerShell se creen dinámicamente. La creación de un script de PowerShell de forma dinámica mediante la concatenación de cadenas puede permitir que un atacante inserte un script arbitrario de PowerShell para ejecutarse. Este método se puede usar para omitir las limitaciones que se aplican a un usuario remoto que usa un espacio de ejecución restringido. También se puede usar para lograr la inserción de comandos estándar en cualquier aplicación que compile scripts de PowerShell con entrada de usuario y lo ejecute.

Ejemplo de bloque de script creado con concatenación de cadenas:

param($UserInputVar)
$DynamicScript = "Get-ChildItem $UserInputVar"
$ScriptBlock = [ScriptBlock]::Create($DynamicScript)
Invoke-Command $ScriptBlock

Ejemplo de este mismo bloque de script construido sin concatenación de cadenas:

param($UserInputVar)
 [ScriptBlock]$ScriptBlock = {
Param($SafeUserInput)
Get-ChildItem $ SafeUserInput
 }
 Invoke-Command -ScriptBlock $ScriptBlock -ArgumentList @($UserInputVar)

# OR, alternatively
param($UserInputVar)
 Invoke-Command -ScriptBlock {
 param(
    [String] $SafeUserInput
 )
Get-ChildItem $SafeUserInput

} -ArgumentList $UserInputVar

Los archivos de script tampoco deben construirse mediante la concatenación de cadenas. Este es un ejemplo de cómo no construir archivos de script:

$Script=@'
    Get-ChildItem $UserInputVar
'@
$Script = '$ UserInputVar =' + "'$ UserInputVar;"+$Script 
$path = “C:\temp”
$Script | Out-File $path

Construya los archivos de script de esta manera:

Function test {
    param(
        [String] $userInputVar
     )
    Get-ChildItem $UserInputVar
    }
   
    $path = “C:\temp”
    (Get-Command test).ScriptBlock | Set-Content -path $path

Todo el código de PowerShell debe estar firmado y almacenado en la ubicación adecuada

Como parte de los cambios que Windows Admin Center realizó para admitir la administración de la infraestructura aplicada de WDAC, los scripts de PowerShell firmados para una extensión ahora se transfieren al nodo al que Windows Admin Center está conectado actualmente antes de ejecutarse. Además, como se mencionó en el requisito anterior, la infraestructura aplicada por WDAC solo ejecuta scripts de PowerShell firmados. Debido a estos requisitos, se debe firmar todo el código de PowerShell. Toda la instancia de PowerShell también debe encontrarse en una ubicación coherente para que la plataforma de Windows Admin Center pueda localizar de forma predecible los módulos firmados de una extensión.

Si el repositorio de extensiones no contiene un directorio powershell-module que contenga módulos de PowerShell firmados, la plataforma Windows Admin Center no podrá identificar el código transferible y se producirá un error en las operaciones en un entorno aplicado por WDAC.

El comando Windows Admin Center gulp build actualiza la carpeta /dist dentro del repositorio, generando los archivos .psd1 y .psm1 sin firmar dentro de una carpeta de módulo. Estos archivos deben firmarse con un certificado de firma que coincida con uno que esté en la lista de permitidos de la directiva WDAC.

Para realizar este cambio, se recomienda encarecidamente crear una canalización de compilación que incorpore la firma de PowerShell.

Puede validar que PowerShell tiene el formato adecuado de una de estas dos maneras:

Cuando se instala la extensión, puede ver el directorio ProgramData\Server Management Experience\UX\modules en el equipo de puerta de enlace (donde se ejecuta Windows Admin Center). Aquí debería ver la carpeta powershell-module y los módulos de PowerShell firmados.
Extraiga el contenido del artefacto .nupkg de la extensión. La carpeta powershell-module debe estar presente y contener los módulos de PowerShell firmados.

En ambos casos, para comprobar que los propios archivos .psd1 y .psm1 están firmados, ejecute el comando Get-AuthenticodeSignature en el archivo o haga clic con el botón derecho en el propio archivo y valide la firma digital.

WorkItems que usa la propiedad "powerShellScript" debe actualizarse para usar la propiedad "powerShellCommand"

La plataforma Windows Admin Center debe poder determinar a qué módulo pertenece un comando de PowerShell. Debido a este requisito, WorkItems que especifica un comando de PowerShell mediante la propiedad powerShellScript produce un error.

Para mitigar este comportamiento, use la propiedad powerShellCommand, junto con el método createCommand, para formar un objeto de comando válido.

Este es un ejemplo de WorkItem usando el método anterior:

    const workItem : WorkItemSubmitRequest = {
      typeId: "SampleWorkItem",
      title: "Title",
      powerShellScript: PowerShellScripts.[scriptName],
      successMessage: "Success",
      errorMessage: "Error",
      progressMessage: "In progress..."
    }

Y este es el mismo WorkItem usando el nuevo método:

    const workItem : WorkItemSubmitRequest = {
      typeId: "SampleWorkItem",
      title: "Title",
      powerShellCommand: PowerShell.createCommand(PowerShellScripts.[scriptName]),
      successMessage: "Success",
      errorMessage: "Error",
      progressMessage: "In progress..."
    }

Asegurarse de que los scripts de PowerShell se ejecutan en modo de lenguaje restringido

Muchas directivas WDAC obligan a que todos los scripts de PowerShell se ejecuten en modo de lenguaje restringido. Para mantener la funcionalidad completa en todo Windows Admin Center, debe asegurarse de que todos los scripts de la extensión sigan estos procedimientos recomendados:

Si los archivos de script se exportan mediante módulos de PowerShell, deben exportar explícitamente las funciones por nombre sin el uso de caracteres comodín. Este requisito es para evitar la exposición involuntaria de funciones auxiliares que pueden no estar pensadas para usarse públicamente.
Usar scripts prefijados por puntos en el archivo de script trae todas las funciones, variables, alias de ese script al ámbito actual. Esta funcionalidad impide que un script de confianza se convierta en un script que no es de confianza y exponga todas sus funciones internas. De forma similar, se impide que un script que no sea de confianza se convierta en un script de confianza para que no pueda contaminar el ámbito de confianza.
Se recomienda evitar el uso del comando Start-Job para ejecutar bloques de script a menos que ese bloque de script ya se pueda ejecutar correctamente en modo de lenguaje restringido.

Se ha sugerido control de errores para que no se admita la administración de infraestructura aplicada por WDAC

Si no tiene previsto admitir la ejecución de la extensión en máquinas aplicadas por WDAC, se recomienda agregar una interfaz de usuario que explique que la administración de la infraestructura aplicada de WDAC es un escenario no admitido en la extensión para evitar confusiones del usuario. Se recomienda utilizar un diseño como nuestras páginas de servicios híbridos de Azure existentes, que incluye el icono de extensión y el texto centrados en la extensión iFrame.

Para esta página, se recomienda el siguiente texto:

"Esta extensión no admite actualmente la ejecución en máquinas con el control de aplicaciones de Windows Defender (WDAC) aplicado".

Este texto es solo una sugerencia. Si no está seguro acerca del texto que quiere usar, envíe un correo electrónico al equipo de Windows Admin Center en wacextensionrequests@microsoft.com.

Detección del cumplimiento de WDAC desde la extensión

Para seguir las instrucciones de la sección anterior, debe determinar si se ha aplicado WDAC al nodo al que está conectado. Windows Admin Center expone un método denominado getPsLanguageMode, definido como parte de las operaciones WDAC de Windows Admin Center, para determinar la aplicación de WDAC.

Este método tiene dos salidas:

Estado: tipo HTTPStatusCode
psLanguageMode : tipo PsLanguageMode (enum)

Puede considerar que WDAC se aplicará si PowerShell se ejecuta en modo de lenguaje restringido, que corresponde a un valor psLanguageMode de 3.

El siguiente código de ejemplo de TypeScript proporciona un ejemplo de cómo usar este método:

import { Component, OnInit } from '@angular/core';
import { AppContextService } from '@microsoft/windows-admin-center-sdk/angular';
import { WdacOperations } from '@microsoft/windows-admin-center-sdk/core';
import { PSLanguageMode, PsLanguageModeResult } from '@microsoft/windows-admin-center-sdk/core/data/wdac-operations';

@Component({
  selector: 'default-component',
  templateUrl: './default.component.html',
  styleUrls: ['./default.component.css']
})
export class DefaultComponent implements OnInit {
wdacEnforced: boolean;

  constructor(private appContextService: AppContextService) {
    //
  }

  public ngOnInit(): void {

  }

  public checkWDACEnforced(): void {
    const wdacOperations = new WdacOperations(this.appContextService);
    wdacOperations.getPsLanguageMode(this.appContextService.activeConnection.nodeName).subscribe(
      (response: PsLanguageModeResult) => {
          if (response.psLanguageMode.toString() === PSLanguageMode[PSLanguageMode.ConstrainedLanguage]) {
            this.wdacEnforced = true;
          }
          else {
            this.wdacEnforced = false;
          }
      }
    );
  }
}

Prueba de la extensión en la infraestructura aplicada por WDAC

Obtenga más información sobre los requisitos de la directiva de control de aplicaciones de Windows Defender para Windows Admin Center para empezar a probar la extensión en la infraestructura aplicada por WDAC.