Freigeben über

Windows Defender-Anwendungssteuerung (WDAC) und .NET

.NET-Apps (wie in einer allgemeinen Sprache wie C# geschrieben) werden in eine Intermediate Language (IL) kompiliert. IL ist ein kompaktes Codeformat, das unter jedem Betriebssystem oder jeder Architektur unterstützt werden kann. Die meisten .NET-Apps verwenden APIs, die in mehreren Umgebungen unterstützt werden, sodass nur die .NET-Runtime ausgeführt werden muss. IL muss in nativen Code kompiliert werden, um auf einer CPU ausgeführt werden zu können, z. B. Arm64 oder x64. Wenn .NET IL in ein natives Image (NI) auf einem Gerät mit einer WDAC-Benutzermodusrichtlinie kompiliert, wird zunächst überprüft, ob die ursprüngliche IL-Datei die aktuellen WDAC-Richtlinien übergibt. Falls ja, legt .NET ein erweitertes NTFS-Attribut (EA) für die generierte NI-Datei fest, damit WDAC ihr auch vertrauen kann. Wenn die .NET-App ausgeführt wird, sieht WDAC den EA in der NI-Datei und lässt ihn zu.

Der für die NI-Datei festgelegte EA gilt nur für die derzeit aktiven WDAC-Richtlinien. Wenn eine der aktiven WDAC-Richtlinien aktualisiert oder eine neue Richtlinie angewendet wird, wird der EA in der NI-Datei ungültig gemacht. Wenn die App das nächste Mal ausgeführt wird, blockiert WDAC die NI-Datei. .NET behandelt den Block ordnungsgemäß und greift auf den ursprünglichen IL-Code zurück. Wenn die IL weiterhin die neuesten WDAC-Richtlinien übergibt, wird die App ohne auswirkungen auf die Funktion ausgeführt. Da die IL jetzt zur Laufzeit kompiliert wird, können Sie eine leichte Auswirkung auf die Leistung der App feststellen. Wenn .NET auf IL zurückgreifen muss, plant .NET auch einen Prozess, der im nächsten Wartungsfenster ausgeführt wird, um alle NI-Dateien neu zu generieren, wodurch der WDAC-EA für den gesamten Code, der die neuesten WDAC-Richtlinien übergibt, wiederhergestellt wird.

In einigen Fällen, wenn eine NI-Datei blockiert ist, wird möglicherweise ein "falsch positives" Blockereignis im CodeIntegrity - Operational-Ereignisprotokoll angezeigt, wie unter WDAC-Administratortipps & Bekannte Probleme beschrieben.

So verringern Sie die Auswirkungen auf die Leistung, die verursacht werden, wenn die WDAC EA nicht gültig ist oder fehlt:

  • Vermeiden Sie es, die WDAC-Richtlinien häufig zu aktualisieren.
  • Führen Sie ngen update (auf allen Computerarchitekturen) aus, um zu erzwingen, dass .NET alle NI-Dateien sofort nach dem Anwenden von Änderungen an Ihren WDAC-Richtlinien neu generiert.
  • Migrieren von Anwendungen zu .NET Core (.NET 6 oder höher).

WDAC- und .NET-Härtung

Sicherheitsexperten haben festgestellt, dass einige .NET-Funktionen, mit denen Apps Bibliotheken aus externen Quellen laden oder neuen Code zur Laufzeit generieren können, verwendet werden können, um WDAC-Steuerelemente zu umgehen. Um dieses potenzielle Sicherheitsrisiko zu beheben, enthält WDAC eine Option namens Dynamische Codesicherheit , die mit .NET funktioniert, um zu überprüfen, ob Code zur Laufzeit geladen wurde.

Wenn die Option Dynamische Codesicherheit aktiviert ist, wird die Anwendungssteuerungsrichtlinie auf Bibliotheken angewendet, die .NET aus externen Quellen lädt. Beispielsweise alle Remotequellen, z. B. das Internet oder eine Netzwerkfreigabe.

Wichtig

Die Sicherheitshärtung für dynamischen .NET-Code wird aktiviert und erzwungen , wenn eine WDAC-Richtlinie mit aktivierter UMCI die Option 19 Aktiviert:Dynamische Codesicherheit festgelegt hat. Für dieses Feature gibt es keinen Überwachungsmodus. Sie sollten Ihre Apps mit dieser Option testen, bevor Sie sie auf einer großen Anzahl von Geräten aktivieren.

Darüber hinaus erkennt es Manipulationen an Code, der von .NET auf dem Datenträger generiert wurde, und blockiert das Laden von Code, der manipuliert wurde.

Dynamische Codesicherheit ist standardmäßig nicht aktiviert, da vorhandene Richtlinien möglicherweise keine extern geladenen Bibliotheken berücksichtigen. Darüber hinaus werden einige .NET-Ladefeatures, einschließlich des Ladens nicht signierter Assemblys, die mit System.Reflection.Emit erstellt wurden, derzeit nicht unterstützt, wenn Dynamic Code Security aktiviert ist. Microsoft empfiehlt, dynamische Codesicherheit im Überwachungsmodus zu testen, bevor Sie sie erzwingen, um zu ermitteln, ob neue Bibliotheken in die Richtlinie einbezogen werden sollen.

Darüber hinaus können Kunden die Bereitstellung nur vorkompilieren, um zu verhindern, dass eine zulässige ausführbare Datei beendet wird, da sie versucht, nicht signierten dynamisch generierten Code zu laden. Informationen zum Beheben dieses Problems finden Sie im Abschnitt "Vorkompilieren nur für die Bereitstellung" im Dokument ASP.NET Übersicht über die Vorkompilierung .

Fügen Sie zum Aktivieren der dynamischen Codesicherheit dem Abschnitt Ihrer WDAC-Richtlinie die <Rules> folgende Option hinzu:

<Rule>
    <Option>Enabled:Dynamic Code Security</Option>
</Rule>