Erweiterungsunterstützung für die Verwaltung einer Infrastruktur, für die Windows Defender Application Control (WDAC) erzwungen wird

  • Artikel

Gilt für: Windows Admin Center, Windows Admin Center-Vorschau

Windows Admin Center unterstützt die Verwaltung von Infrastrukturen, für die Windows Defender Application Control (WDAC) erzwungen wird, auf der Plattformebene. Erfahren Sie mehr über die Verwaltung von Infrastrukturen, für die WDAC erzwungen wird, in Windows Admin Center.

Die Unterstützung für diese Verwaltungsfunktion auf der Plattformebene bedeutet nicht, dass für Windows Admin Center entwickelte Erweiterungen die Verwaltung von Infrastrukturen, für die WDAC erzwungen wird, standardmäßig auch unterstützen. In diesem Leitfaden werden die Anforderungen beschrieben, die eine Erweiterung erfüllen muss, um die Verwaltung einer Infrastruktur zu unterstützen, für die WDAC erzwungen wird.

Anforderungen an die Erweiterungsstruktur

Zum Verwalten einer Infrastruktur, für die WDAC erzwungen wird, muss Windows Admin Center PowerShell-Skripts auf bestimmte Weise erfassen und ausführen, um bewährte Sicherheitsmethoden einzuhalten. Um sicherzustellen, dass die Skripts Ihrer Erweiterung korrekt ausgeführt werden, muss Ihre Erweiterung den folgenden Anforderungen entsprechen.

Alle PowerShell-Skripts müssen in einer Datei gespeichert werden.

Zuvor haben sich Entwickler von WAC-Erweiterungen (Windows Admin Center) möglicherweise entschieden, benutzerdefinierten PowerShell-Code als Zeichenfolge in die Datei „manifest.json“ ihrer Erweiterung einzuschließen. Die Bedingungen für die Sichtbarkeit einer Toolerweiterung können beispielsweise definiert werden, indem ein PowerShell-Skript in der script-Eigenschaft bereitgestellt wird. Damit PowerShell-Skripts mit WDAC kompatibel sind, müssen sie signiert sein. Zeichenfolgen können nicht signiert werden.

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass diese Anforderung erfüllt ist:

  1. Identifizieren Sie alle PowerShell-Skripts in Ihrer Datei „manifest.json“.
  2. Nachdem Sie Skriptinhalte in der Datei „manifest.json“ definiert haben, entfernen Sie den Skriptinhalt, und speichern Sie ihn in einer PS1-Datei im Verzeichnis resources/scripts Ihrer Erweiterung. Für den Skriptcode im Erweiterungsmanifest gelten nun die gleichen Regeln wie für andere Windows Admin Center-PowerShell-Skripts.
  3. Aktualisieren Sie die conditions-Eigenschaft im Erweiterungsmanifest mit dem folgenden Format: 
    "conditions": [
    {
        "powerShell": {
            "command": "Script-File-Name",
            "module": "powerShellModuleName",
            "script": "Your script text goes here."
        }
    }
]
    Der Name des PowerShell-Moduls ist bereits in Ihrem Erweiterungsmanifest vorhanden. Der Wert im Manifest und der Wert im PowerShell-Feld müssen übereinstimmen.
  4. Ermitteln Sie alle anderen Stellen, an denen PowerShell-Skripts dynamisch erstellt werden. Das dynamische Erstellen eines PowerShell-Skripts mithilfe der Zeichenfolgenverkettung kann es Angreifer*innen ermöglichen, beliebige PowerShell-Skripts zur Ausführung einzufügen. Diese Methode kann verwendet werden, um erzwungene Einschränkungen für Remotebenutzer*innen zu umgehen, die einen eingeschränkten Runspace verwenden. Sie kann auch verwendet werden, um Standardbefehle in beliebige Anwendungen einzuschleusen, die PowerShell-Skripts mit Benutzereingaben erstellen und ausführen.

Beispiel eines Skriptblocks, der mit Zeichenfolgenverkettung erstellt wurde:

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

Beispiel des gleichen Skriptblocks, der ohne Zeichenfolgenverkettung erstellt wurde:

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

Skriptdateien sollten auch nicht mithilfe der Zeichenfolgenverkettung erstellt werden. Das folgende Beispiel zeigt, wie Skriptdateien nicht erstellt werden sollten:

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

Erstellen Sie Ihre Skriptdateien stattdessen wie folgt:

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

Der gesamte PowerShell-Code muss signiert und am richtigen Speicherort gespeichert werden.

Als Teil der Änderungen, die in Windows Admin Center vorgenommen wurden, um die Verwaltung von Infrastrukturen mit WDAC-Erzwingung zu unterstützen, werden signierte PowerShell-Skripts für eine Erweiterung jetzt vor ihrer Ausführung auf den Knoten übertragen, mit dem Windows Admin Center derzeit verbunden ist. Zudem führt eine Infrastruktur, für die WDAC erzwungen wird, wie in der vorherigen Anforderung erwähnt nur signierte PowerShell-Skripts aus. Aufgrund dieser Anforderungen muss Ihr gesamter PowerShell-Code signiert sein. Außerdem muss sich Ihr gesamter PowerShell-Code an einem einheitlichen Speicherort befinden, damit die Windows Admin Center-Plattform die signierten Module einer Erweiterung wie erwartet finden kann.

Wenn Ihr Erweiterungsrepository kein Verzeichnis powershell-module mit signierten PowerShell-Modulen enthält, kann die Windows Admin Center-Plattform übertragbaren Code nicht identifizieren. Dies führt dazu, dass Vorgänge in einer Umgebung, für die WDAC erzwungen wird, fehlschlagen.

Der Windows Admin Center-Befehl gulp build aktualisiert den Ordner /dist in Ihrem Repository und generiert Ihre nicht signierten PSD1- und PSM1-Dateien in einem Modulordner. Diese Dateien müssen mit einem Signaturzertifikat signiert sein, das in der Liste „Zulassen“ der WDAC-Richtlinie aufgeführt ist.

Um diese Änderung vorzunehmen, wird dringend empfohlen, eine Buildpipeline zu erstellen, die das Signieren des PowerShell-Codes umfasst.

Ihnen stehen zwei Methoden zur Verfügung, um zu überprüfen, ob Ihr PowerShell-Code das richtige Format aufweist:

  1. Wenn Ihre Erweiterung installiert ist, können Sie das Verzeichnis ProgramData\Server Management Experience\UX\modules auf dem Gatewaycomputer anzeigen (der Computer, auf dem Windows Admin Center ausgeführt wird). Dort sollten der Ordner powershell-module und die signierten PowerShell-Module angezeigt werden.
  2. Extrahieren Sie den Inhalt des NUPKG-Artefakts Ihrer Erweiterung. Der Ordner powershell-module sollte vorhanden sein und die signierten PowerShell-Module enthalten.

In beiden Fällen können Sie überprüfen, ob die PSD1- und PSM1-Dateien signiert sind, indem Sie den Befehl Get-AuthenticodeSignature für die Datei ausführen oder mit der rechten Maustaste auf die Datei klicken und die digitale Signatur anzeigen.

Arbeitselemente (WorkItems), die die powerShellScript-Eigenschaft verwenden, sollten zur Verwendung der powerShellCommand-Eigenschaft aktualisiert werden.

Die Windows Admin Center-Plattform muss bestimmen können, zu welchem Modul ein PowerShell-Befehl gehört. Aufgrund dieser Anforderung führen WorkItems mit einem PowerShell-Befehl mit der powerShellScript-Eigenschaft zu einem Fehler.

Sie können dieses Verhalten vermeiden, indem Sie die powerShellCommand-Eigenschaft zusammen mit der createCommand-Methode verwenden, um ein gültiges Befehlsobjekt zu erstellen.

Hier sehen Sie ein Beispiel für ein WorkItem mit der alten Methode:

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

Das folgende Beispiel zeigt das gleiche WorkItem mit der neuen Methode:

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

Sicherstellen, dass PowerShell-Skripts im eingeschränkten Sprachmodus ausgeführt werden

Viele WDAC-Richtlinien erzwingen die Ausführung aller PowerShell-Skripts im eingeschränkten Sprachmodus. Um den vollen Funktionsumfang in Windows Admin Center beizubehalten, sollten Sie sicherstellen, dass alle Skripts in Ihrer Erweiterung den folgenden bewährten Methoden entsprechen:

  1. Wenn Ihre Skriptdateien mithilfe von PowerShell-Modulen exportiert werden, müssen die Funktionen ohne Platzhalterzeichen explizit anhand des Namens exportiert werden. Diese Anforderung soll verhindern, dass versehentlich Hilfsfunktionen verfügbar gemacht werden, die nicht zur öffentlichen Verwendung vorgesehen sind.
  2. Durch Dot-Sourcing einer Skriptdatei werden alle Funktionen, Variablen und Aliase aus diesem Skript in den aktuellen Bereich gebracht. Diese Funktion verhindert, dass ein vertrauenswürdiges Skript durch Dot-Sourcing zu einem nicht vertrauenswürdigen Skript wird und all seine internen Funktionen verfügbar gemacht werden. Ebenso wird verhindert, dass ein nicht vertrauenswürdiges Skript durch Dot-Sourcing zu einem vertrauenswürdigen Skript wird, damit es den vertrauenswürdigen Bereich nicht beschädigen kann.
  3. Es wird empfohlen, den Befehl „Start-Job“ nicht zum Ausführen von Skriptblöcken zu verwenden, es sei denn, der jeweilige Skriptblock konnte bereits erfolgreich im eingeschränkten Sprachmodus ausgeführt werden.

Empfohlene Fehlerbehandlung, wenn die Verwaltung von Infrastrukturen mit WDAC-Erzwingung nicht unterstützt wird

Wenn Sie nicht vorhaben, die Ausführung Ihrer Erweiterung auf Computern mit WDAC-Erzwingung zu unterstützen, sollten Sie in der Benutzeroberfläche eine Seite hinzufügen, auf der erläutert wird, dass die Verwaltung einer Infrastruktur, für die WDAC erzwungen wird, in Ihrer Erweiterung ein nicht unterstütztes Szenario ist, um Benutzer*innen nicht zu verwirren. Wir empfehlen ein Layout, das dem unserer vorhandenen Seiten für Azure-Hybriddienste ähnelt, in dem das Erweiterungssymbol und der zugehörige Text auf der iFrame-Erweiterung zentriert sind.

Für den Text auf dieser Seite wird die folgende Formulierung vorgeschlagen:

„Diese Erweiterung unterstützt die Ausführung auf Computern, auf denen Windows Defender Application Control (WDAC) erzwungen wird, derzeit nicht.“

Dieser Text ist nur ein Vorschlag. Falls Sie sich bezüglich der Formulierung nicht sicher sind, wenden Sie sich per E-Mail an wacextensionrequests@microsoft.com an das Windows Admin Center Team.

Erkennen der WDAC-Erzwingung über Ihre Erweiterung

Um den Anweisungen im vorherigen Abschnitt zu folgen, müssen Sie ermitteln, ob für den Knoten, mit dem Sie verbunden sind, WDAC erzwungen wird. Windows Admin Center macht eine Methode namens getPsLanguageModeverfügbar, die als Teil der WDAC-Vorgänge von Windows Admin Center definiert ist, um die WDAC-Erzwingung zu überprüfen.

Diese Methode gibt zwei Werte aus:

  • Status: HTTPStatusCode-Typ
  • psLanguageMode: PsLanguageMode-Typ (enum)

Sie können WDAC als erzwungen betrachten, wenn PowerShell im eingeschränkten Sprachmodus ausgeführt wird, was dem PsLanguageMode-Wert 3 entspricht.

Der folgende TypeScript-Beispielcode zeigt ein Beispiel für die Verwendung dieser Methode:

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

Testen Ihrer Erweiterung in einer Infrastruktur, in der WDAC erzwungen wird

Erfahren Sie mehr über die Richtlinienanforderungen von Windows Defender Application Control für Windows Admin Center, um Ihre Erweiterung in einer Infrastruktur zu testen, in der WDAC erzwungen wird.