App Control for Business und .NET

Warnung

Wenn App Control erzwungen wird, lädt .NET bestimmte COM-Objekte (Component Object Model) nicht, wenn deren Registrierungs-GUID nicht mit der vom System zur Laufzeit berechneten übereinstimmt. In diesem Fall wird dem Benutzer ein dialogfeld mit einem allgemeinen COM-Ladefehler angezeigt, aber es werden keine Ereignisse oder andere Informationen im System protokolliert. Weitere Informationen finden Sie unter App Control Admin Tipps & Bekannte Probleme: .NET lädt keine COM-Objekte mit nicht übereinstimmenden GUIDs.

.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 App Control-Benutzermodusrichtlinie kompiliert, wird zuerst überprüft, ob die ursprüngliche IL-Datei die aktuellen App Control-Richtlinien übergibt. Falls ja, legt .NET ein erweitertes NTFS-Attribut (EA) für die generierte NI-Datei fest, sodass App Control ihr auch vertrauen kann. Wenn die .NET-App ausgeführt wird, sieht App Control den EA in der NI-Datei und lässt es zu.

Der in der NI-Datei festgelegte EA gilt nur für die derzeit aktiven App-Steuerungsrichtlinien. Wenn eine der aktiven App Control-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 App Control die NI-Datei. .NET behandelt den Block ordnungsgemäß und greift auf den ursprünglichen IL-Code zurück. Wenn die IL weiterhin die neuesten App Control-Richtlinien übergibt, wird die App ohne Funktionsproblem ausgeführt. Da die IL nun zur Laufzeit kompiliert wird, können Sie eine leichte Leistungsminderung 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. Auf diese Weise wird die App-Steuerungs-EA für den gesamten Code wiederhergestellt, der die neuesten App Control-Richtlinien übergibt.

Wenn eine NI-Datei blockiert ist, wird im Ereignisprotokoll CodeIntegrity – Operational möglicherweise ein "falsch positives" Blockereignis angezeigt, wie unter App Control Admin Tips & Known Issues beschrieben.

Gehen Sie wie folgt vor, um leistungsbedingte Leistungseinbußen zu verringern, wenn die App Control EA nicht gültig ist oder fehlt:

• Vermeiden Sie es, die App-Steuerungsrichtlinien 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 App Control-Richtlinien neu generiert.
• Migrieren Sie Anwendungen zu .NET Core (.NET 6 oder höher), und aktivieren Sie natives AOT.

App-Steuerung und .NET Dynamic Code Security-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 die App-Steuerung zu umgehen. Um dieses potenzielle Sicherheitsrisiko zu beheben, enthält App Control eine Option namens Dynamic Code Security , die mit .NET funktioniert, um zu überprüfen, ob Zur Laufzeit Code geladen wurde.

Wenn Dynamic Code Security aktiviert ist, wird Ihre App Control-Richtlinie auf Bibliotheken angewendet, die .NET aus externen oder Remotequellen wie dem Internet oder einer Netzwerkfreigabe lädt. Außerdem werden Manipulationen in Code erkannt, der von .NET auf dem Datenträger generiert wurde, und das Laden von manipuliertem Code wird blockiert. Darüber hinaus werden einige .NET-Ladefeatures, die von Dynamic Code Security nicht unterstützt werden, einschließlich des Ladens von nicht signierten Assemblys, die mit System.Reflection.Emit erstellt wurden, immer blockiert.

Wenn dynamischer Code blockiert wird, wird der übergeordnete Prozess in der Regel beendet oder stürzt ab. Um dies mithilfe von ASP.NET zu verhindern, können Sie den dynamischen Code nur für die Bereitstellung vorkompilieren. Weitere Informationen finden Sie unter "Vorkompilieren nur für die Bereitstellung" in der ASP.NET Übersicht über die Vorkompilierung.

Wichtig

.NET Dynamic Code Security funktioniert im Überwachungsmodus nur auf Windows 11 24H2 und höher sowie Windows Server 2025 und höher. Es gibt keinen Überwachungsmodus für dynamic Code Security auf Windows 10 oder in früheren Versionen von Windows 11 und Windows Server. Wenn eine App Control-Richtlinie option 19 Aktiviert:Dynamische Codesicherheit für diese früheren Versionen festlegt, wird die dynamische Codesicherheitshärtung aktiviert und erzwungen , auch wenn sich die Richtlinie im Überwachungsmodus befindet. Testen Sie Ihre Apps immer gründlich, und verwenden Sie sichere Bereitstellungsmethoden, wenn Sie App-Steuerungsrichtlinien für die Produktion bereitstellen.

Dynamic Code Security entschärft potenzielle Angriffstechniken, die häufig als Angriffe zweiter Ordnung bezeichnet werden. Das bedeutet, dass der Angreifer Zugriff auf das System hat und in der Lage ist, Code auszuführen. Die Angriffe zweiter Ordnung können Versuche sein, Persistenz zu erlangen oder die Aktivitäten der Angreifer weiter zu verdecken. Obwohl Dynamic Code Security wichtig und empfohlen wird, empfiehlt Microsoft auch, die Richtlinie im Überwachungsmodus auf Systemen zu testen, auf denen Windows 11 24H2 und höher oder Windows Server 2025 und höher ausgeführt wird, bevor Sie sie erzwingen.

Code, der von Dynamic Code Security blockiert wird, wird mit der Ereignis-ID 3114 im Ereignisprotokoll CodeIntegrity – Operational protokolliert. Mit Ausnahme von Code, der mit einem der nicht unterstützten .NET-Features wie System.Reflection.Emit geladen wird, können Sie Regeln erstellen, um blockierten dynamischen Code mithilfe von Informationen aus den Ereignissen zuzulassen. Weitere Informationen finden Sie unter Verwenden des App-Steuerelement-Assistenten zum Erstellen von Regeln aus den App Control-Ereignisprotokollen.

Hinweis

.NET versucht zwei verschiedene Methoden, dynamisch generierten Code auszuführen. Wenn Ihre App Control-Richtlinie die erste Methode blockiert, versucht .NET die zweite Methode. Jeder der beiden Versuche löst ein eindeutiges 3114-Ereignis aus. Wenn ein 3114-Ereignis isoliert auftritt, kann es sicher als "falsch positiv" ignoriert werden, da es nur den ersten Versuch von .NET abdeckt, den Code auszuführen. Nur wenn zwei 3114-Ereignisse innerhalb von Millisekunden für denselben Code angezeigt werden, deutet dies auf ein tatsächliches Problem hin, das überprüft werden muss.

Um dynamische Codesicherheit zu aktivieren, fügen Sie Der App Control-Richtlinie die Option 19 – Aktiviert:Dynamische Codesicherheit hinzu, indem Sie den App-Steuerungs-Assistenten, das PowerShell-Cmdlet set-ruleoption verwenden oder indem Sie dem <Rules> Abschnitt Ihrer App Control-Richtlinien-XML Folgendes hinzufügen:

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