Windows Defender アプリケーション制御 (WDAC) が適用されたインフラストラクチャの管理に対する拡張機能のサポート

[アーティクル]
06/30/2023
適用対象:

✅ Windows Admin Center, ✅ Windows Admin Center Preview

Windows Admin Center では、Windows Defender アプリケーション制御 (WDAC) が適用されたインフラストラクチャのプラットフォームレベルでの管理がサポートされます。 Windows Admin Center での WDAC が適用されたインフラストラクチャの管理に関する詳細を確認してください。

この管理に対するプラットフォームレベルでのサポートは、Windows Admin Center 用に構築された拡張機能が既定で WDAC が適用されたインフラストラクチャの管理もサポートすることを意味するわけではありません。このガイドでは、WDAC が適用されたインフラストラクチャの管理をサポートするための拡張機能の要件について説明します。

拡張機能の構造の要件

WDAC が適用されたインフラストラクチャを管理するには、Windows Admin Centerが PowerShell スクリプトを取り込んで実行し、セキュリティに関するベストプラクティスに従う必要があります。拡張機能のスクリプトが正しく実行されるようにするには、拡張機能が次の要件に準拠していることを確認します。

すべての PowerShell スクリプトをファイルに格納する必要がある

これまで、WAC 拡張機能の開発者は、拡張機能 manifest.json ファイルにカスタム PowerShell コードを文字列として含める選択をしたことがあるかもしれません。たとえば、"script" プロパティに PowerShell スクリプトを指定することで、ツール拡張機能の可視性の条件を定義できます。 PowerShell スクリプトが WDAC と互換性を持つようにするには、署名する必要があります。文字列には署名できません。

この要件が満たされていることを確認するには、こちらの手順に従います。

manifest.json ファイル内の PowerShell スクリプトを特定します。
manifest.json ファイルでスクリプトコンテンツを定義したら、スクリプトコンテンツを削除し、拡張機能の resources/scripts ディレクトリの .ps1 ファイルに格納します。これで、拡張機能マニフェストのスクリプトコードは、その他の Windows Admin Center PowerShell と同じ規則に従うようになりました。
拡張機能マニフェストの conditions プロパティを次の形式に更新します。
```
"conditions": [
    {
        "powerShell": {
            "command": "Script-File-Name",
            "module": "powerShellModuleName",
            "script": "Your script text goes here."
        }
    }
]
```
PowerShell モジュール名は、拡張機能マニフェストに既に存在します。 マニフェストと PowerShell フィールドの値が一致している必要があります。
PowerShell スクリプトが動的に作成されている他の場所を特定します。文字列連結を使用して PowerShell スクリプトを動的に作成すると、攻撃者が任意の PowerShell スクリプトを挿入して実行する可能性があります。このメソッドを使用すると、制限された実行領域を使用しているリモートユーザーに適用される制限を回避できます。また、ユーザー入力を使用して PowerShell スクリプトをビルドして実行するアプリケーションに対して標準のコマンドインジェクションを実現するためにも使用できます。

文字列連結を使用して作成されたスクリプトブロックの例:

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

文字列連結なしで構築された同じスクリプトブロックの例:

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

スクリプトファイルは、文字列連結を使用して構築しないでください。ここに、スクリプトファイルを構築しない方法の例を示します。

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

代わりに、このようなスクリプトファイルを構築します。

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

すべての PowerShell コードに署名し、適切な場所に格納する必要がある

WDAC が適用されたインフラストラクチャの管理をサポートするために行われたWindows Admin Center の変更の一環として、拡張機能の署名された PowerShell スクリプトが、実行前に、Windows Admin Center が現在接続されているノードに転送されるようになりました。さらに、前の要件で説明したように、WDAC が適用されたインフラストラクチャでは、署名された PowerShell スクリプトのみが実行されます。これらの要件があるため、すべての PowerShell コードに署名する必要があります。また、Windows Admin Center プラットフォームが拡張機能の署名付きモジュールを予測可能な方法で見つけられるように、すべての PowerShell を一貫した場所に配置する必要があります。

拡張機能リポジトリに、署名付きの PowerShell モジュールを含む powershell-module ディレクトリが含まれていない場合、Windows Admin Center プラットフォームは転送可能なコードを識別できず、WDAC が適用された環境では操作が失敗します。

Windows Admin Center の gulp build コマンドはリポジトリ内の /dist フォルダーを更新し、モジュールフォルダー内に署名されていない .psd1 および .psm1 ファイルを生成します。これらのファイルは、WDAC ポリシーの許可リストに登録されているものと一致する署名証明書を使用して署名する必要があります。

この変更を行うには、PowerShell 署名を組み込んだビルドパイプラインを作成することを強くお勧めします。

PowerShell が適切な形式であることを検証するには、次の 2 つの方法のいずれかを使用します。

拡張機能がインストールされると、ゲートウェイマシン (Windows Admin Center が実行されているもの) で ProgramData\Server Management Experience\UX\modules ディレクトリを表示できます。ここで、powershell-module フォルダーと署名付きの PowerShell モジュールが表示されます。
拡張機能の .nupkg 成果物の内容を抽出します。 powershell-module フォルダーが存在し、署名付きの PowerShell モジュールが含まれているはずです。

どちらの場合も、.psd1 および .psm1 ファイル自体が署名されていることを確認するには、ファイルで Get-AuthenticodeSignature コマンドを実行するか、ファイル自体を右クリックしてデジタル署名を検証します。

"powerShellScript" プロパティを使用する WorkItems を、"powerShellCommand" プロパティを使用するように更新する必要がある

Windows Admin Center プラットフォームは、PowerShell コマンドが属するモジュールを特定できる必要があります。この要件が原因で、powerShellScript プロパティを使用して PowerShell コマンドを指定する WorkItems によってエラーが発生します。

この動作を軽減するには、powerShellCommand プロパティと createCommand メソッドを使用して、有効なコマンドオブジェクトを形成します。

古いメソッドを使用した WorkItem の例をここに示します。

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

そしてこれは、新しいメソッドを使用した同じ WorkItem です。

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

PowerShell スクリプトが制約付き言語モードで実行されるようにする

多くの WDAC ポリシーによって、すべての PowerShell スクリプトが強制的に制約付き言語モードで実行されます。 Windows Admin Center 全体で完全な機能を維持するには、拡張機能内のすべてのスクリプトがこちらのベストプラクティスに従っていることを確認する必要があります。

スクリプトファイルが PowerShell モジュールを使用してエクスポートされる場合は、ワイルドカード文字を使用せずに関数を名前で明示的にエクスポートする必要があります。この要件は、一般に使用されることを意図していない可能性があるヘルパー関数が誤って公開されるのを防ぐためです。
スクリプトファイルをドットソーシングすると、そのスクリプトのすべての関数、変数、エイリアスが現在のスコープに取り込まれます。この機能は、信頼されたスクリプトが信頼されていないスクリプトにドットソースされ、すべての内部関数が公開されるのを防ぎます。同様に、信頼されたスコープを汚染できないように、信頼されていないスクリプトが信頼されたスクリプトにドットソースされることも防ぎます。
Start-Job コマンドを使用してスクリプトブロックを実行することは、そのスクリプトブロックを既に制約付き言語モードで正常に実行できる場合を除き、避けることをお勧めします。

WDAC が適用されたインフラストラクチャ管理のサポートに失敗した場合に推奨されるエラー処理

WDAC が適用されたマシンでの拡張機能の実行をサポートする予定がない場合は、ユーザーの混乱を避けるために、WDAC が適用されたインフラストラクチャの管理が拡張機能でサポートされていないシナリオであることを説明する UI を追加することをお勧めします。拡張機能 iFrame の中央に拡張機能アイコンとテキストが表示されている、既存の Azure ハイブリッドサービスページのようなレイアウトをお勧めします。

このページのテキストについては、次の文言をお勧めします。

「この拡張機能は現在、Windows Defender アプリケーション制御 (WDAC) が適用されているマシンでの実行をサポートしていません。」

このテキストは単なる提案です。使用する文言がわからない場合は、Windows Admin Center チーム (wacextensionrequests@microsoft.com) にメールを送信してください。

拡張機能からの WDAC 適用の検出

前のセクションのガイダンスに従うには、接続しているノードに WDAC が適用されているかどうかを確認する必要があります。 Windows Admin Center は、Windows Admin Center の WDAC 操作の一部として定義される、WDAC の適用を判断するための getPsLanguageMode という名前のメソッドを公開しています。

このメソッドには次の 2 つの出力があります。

Status – HTTPStatusCode 型
psLanguageMode – PsLanguageMode 型 (列挙型)

PowerShell が制約付き言語モード (psLanguageMode 値 3 に対応) で実行されている場合は、WDAC を適用することを検討できます。

次の TypeScript サンプルコードは、このメソッドの使用方法の例を示しています。

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

WDAC が適用されたインフラストラクチャで拡張機能をテストする

WDAC で適用されたインフラストラクチャで拡張機能のテストを開始するには、Windows Admin Center の Windows Defender アプリケーション制御ポリシー要件の詳細を参照してください。

次の方法で共有